I am creating my own image based on ubuntu:20.04 and some additional software (zimbra e-mail server). To install this software I need to run an interactive script once I create the container, so once I set up everything, I want to create an imagen from that fully configured container.
To do that I use the ‘docker commit’ command.
The container size is around 3GB, and my remaining disk space is around 36GB. When I run docker commit, the disk free space starts to decrease until no free space remains.
Then i get this error: Error response from daemon: Error processing tar file(exit status 1): write /opt/zimbra/data/ldap/mdb/db/data.mdb: no space left on device.
After that my normal free-space disk shows up, I guess because those temporary files have been erased when the process is cancelled.
Any suggestion? Thanks
My apologies in advance if this is a known issue
docker commit should not use more space then thesize of your container filesystem. so it could be related to your environment (special filesytem, but this is Docker Desktop so not likely) or Zimbra. Do you stop the container before committing?
docker commit would stop the container or at least pause that (I don’t remember which one because I never use it) so it can save the filesystem layer. If the process (Zimbra) inside the container starts to save something before the commit, that could cause the issue. Or if you you use Docker Desktop with emulation, but this is just a guess, so I think we need more information about your environment.
- Docker Desktop version
- Mac architecture (amd64 or arm)
- Do you use volumes attached to the container?
- Can you share the interactive script you try to run? I am not sure if it helps, but I installed Zimbra years ago without Docker when I had to dockerize everything else so it was probably for a reason.
On the other hand, you should not install anything interactively in a container and commit it. Maybe it was the reason why I could not install Zimbra in a container. Even if the software gives you only an interactive installer, you should try to understand what it does and do it non-interactively. Not all applications can be run in containers (without modifications and perfectly). I remember, Zimbra has many components, not just the mail server so you would probably end up with special privileges, capabilities, a lot of “pain” and still not guaranteed that Zimbra will run perfectly.
This can be an other reason why you should know what the interactive installer does. So I definitely don’t recommend to install Zimbra this way, but this doesn’t change the fact that the commit should work.
Thanks for your replying, rlmelek.
Yes, Zimbra is a really complicated and powerful piece of software. Theorically, the commit command should ‘pause’ the container, and in fact my console freezes if I’m connected to the container with docker exec, so I think it’s working alright.
The container is fully operated, I can send emails and also receive them. I tried without volume and with volume too.
Docker version: Docker version 20.10.17, build 100c701
Mac version: Darwin MacBook-Air-de-Hector.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
The interactive script is massive, it’s from zimbra package “install.sh”. It does MANY STUFF. You can find it here zimbra/install.sh at main · hector-medina/zimbra · GitHub
I’ve been working with this for a few days now, and creating an image from a fully configured container was my last bullet. If this doesn’t work I’m afraid I will have to change it for another open-source email server.
By the way, there is not such a thing as ‘Official docker image’ of Zimbra, maybe there is a reason for that as you said.
What a pity! I have already wasted a lot of time with this hahaha.
I have given up, honestly. Too much headache for a personal email server as a lab. I will use another email which has official docker image available
There was at least a wiki page about running Zimbra in Docker container, but the referred image is 4 years old so it looks like they have given up too.
My approach would be to take look at how other images solved the installation issue and use it as inspiration for your own image. Good thing with most Docker images is that you can find them on Github and inspect their sources
For instance, I looked at zimbra-docker/start.sh at master · jorgedlcruz/zimbra-docker · GitHub and this maintainer approaches is like this:
echo "Installing Zimbra Collaboration just the Software"
cd /opt/zimbra-install/zcs-* && ./install.sh -s < /opt/zimbra-install/installZimbra-keystrokes
echo "Installing Zimbra Collaboration injecting the configuration"
/opt/zimbra/libexec/zmsetup.pl -c /opt/zimbra-install/installZimbraScript
and the content of installZimbra-keystrokes is:
Wow!! Thanks clever!
Thanks to both of you! I haven’t solved the problem of the docker commit, but I’m quite sure I’m doing something wrong maybe.
Thank you guys! I will not give up!
I am 100% with @rimelek that its discouraged to create images using
docker commit. Its a bad practice…
The only reliable, repeatable and self-documenting approach is to create a Dockerfile and use it with
docker build to build your image.
Patch management with containers usualy is done by re-building your image, idealy whenever the base image is updated. Otherwise you end up carrying the inherited vulnerabilites of the base image for indefinit time. Imagine you would have to re-build your image manually with
docker commit every time you want to keep the os level packages updated… Sure you could just update the packages in your image, but it will lead to a bigger image size, as the previous package versions are still existing in the previous image layers.
Even though creating a Dockerfile might look like tedious work, it will save you time and nerves on the long run.