Open JensErat opened 9 years ago
@JensErat thanks, agree. I'll create a feature branch for these changes where we can both take a stab at them.
Just wanted to leave a note that I won't tackle cleaning up the Dockerfile; after moving the container to a production host and MySQL not surviving the migration (still don't get why) I decided to package Zabbix on my own in multiple single-process containers which are easier to handle (in my opinion).
Thanks @JensErat for your help, I appreciate the suggestions you pointed out in the issue and will proceed to implement them. I am not sure if this affected your migration but note that the Dockerfile has the /var/lib/mysql
entry as a Volume. By default MySQL will keep the logs and database files inside such directory, per this link. Also according to the Docker documentation on Volumes:
Again, I am not sure if that affected your migration and I am just speculating. I think that you made the right choice when you decided to deploy a MySQL Container on its own. I think that a docker container should try to avoid having more than one process. In fact this project was conceived not as a way to run Zabbix in production but as a way to provide a Zabbix setup for developers that had to integrate with a Zabbix environment as a way to expose metrics from their applications.
Thanks again, really appreciate the effort you took to write this issue in such a detailed manner. It will not only help this project but others I am involved with. Cheers and good luck.
I persisted MySQL to a folder on the host from the start, checked for permissions after migrating (which -- thanks to Docker and virtualized UIDs -- are not an issue anyway). But something still was stuck anywhere.
Thank you for the effort with the image: at least for getting in touch with Zabbix for the first time it was definitely helpful.
I have a bunch of proposals for cleaning up the Docker file. I don't want to simply fork it again without pushing upstream, so I'm ready to discuss before doing so. If you agree with the individual changes, I'll provide a pull request at some time in the future.
Reducing the Number of Layers
Each invocation of
RUN
in a Dockerfile results in a new layer generated, which is both overhead at runtime and will persist all space that layer consumed forever. Especially, running clean-up tasks likeyum update
in an additionalRUN
command will not have the desired effect of reducing the image size, but adding another layer which lists the deleted files.The image should limit to a smallest possible number of layers, especially merging most of the
RUN yum ...
invocations to a single one with cleaning performed as last step, like(but for all the package installation steps), so temporary files and similar stuff is removed before persisting the layer.
Similarlly, multiple
ADD [src]... [target]
invocations can be merged to a single one, if all pointing to the same target.RUN chmod
for files added from the git repository should better be performed already in the repository, since permissions are adopted.Upgrading the Base System
The base system should not be upgraded unless there is very good reason. The (official) base images are updated regularly anyway, so it should not be required to run:
Installing tools not required for running the application itself is also discouraged, as making the image larger and providing a larger attack surface.
Management Tools
Are these tools required? Especially
vim
will not be. If required, the administrator can easily and quickly add it (and drop it again afterwards, or even drop the whole image).LInking Repositories
Not directly related to the Dockerfile, but to the build process: to receive security and bug fixes, the Image should be rebuild on updates of the base system. This is possible by using the "Linked Images" feature of the Index website.