Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use smaller base image #19

Open
LordMike opened this issue Jan 5, 2017 · 3 comments
Open

Use smaller base image #19

LordMike opened this issue Jan 5, 2017 · 3 comments

Comments

@LordMike
Copy link

LordMike commented Jan 5, 2017

Hey,

I was just about to try this out (I still will), and I noticed the use of the debian base image. Would it be possible to utilize a smaller image?

I could foresee a number of issues, such as monitoring using standard utilities (curl, wget, ping, openssl), but I hope it would be kind of simple :).

Mike.

@rohit01
Copy link
Owner

rohit01 commented Jan 6, 2017

Fundamentally, I agree with your suggestion. Ideally, we should build docker images using a smaller base like alpine Linux.
In this case, I feel it would make little difference in the final image size. The reason being many packages being installed while building the image (see Dockerfile).

I could foresee a number of issues, such as monitoring using standard utilities (curl, wget, ping, openssl), but I hope it would be kind of simple :).

What issues?

@LordMike
Copy link
Author

LordMike commented Jan 6, 2017

Issues like you need a load of packages that, as you say, would defeat the purpose of the smaller image. With nagios, you're basically encouraged to create commands that utilize standard functions and tools in linux, such as curl, wget or anything building on openssl etc.

Making a small image would potentially take a lot of time as one would have to select out all the different tools a user might use.. On the other hand.. In the docker spirit, the user should create their own image based on this with just the tools they need.

Would it be possible to not leave build tools in the image?

I've seen a lot of projects leave tools in it (git, build-essentials etc.), but haven't really seen anybody clean up or transfer artifacts over a "clean" image...

@rohit01
Copy link
Owner

rohit01 commented Jan 6, 2017

Size is the primary reason for having 3 image variants - shinken (541 MB), shinken_thruk (681 MB) and shinken_thruk_graphite (790 MB). This is after keeping only essential packages in the image.

I agree, it could be improved further. My basic idea was to help people get started with monitoring systems as the learning curve is very high. I have not yet run these images in production.

I would highly appreciate if you could transform your ideas into a pull request. I will happily review and merge them :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants