7 ms·
> Using an appropriate base image (debian for dev, alpine for production). Seems to me like this is a good way to introduce subtle differences between dev and
by shocks 9y ago
> Using an appropriate base image (debian for dev, alpine for production).
Seems to me like this is a good way to introduce subtle differences between dev and prod.
I'd just use the same base images for everything. Consistency is king.
- Already__Taken 9y agoEspecially these two, with alpines different c compiler for everything. Perhaps dev on a debian base and production on of one of those single binary only containers.
- eddd 9y agoI don't think alpine solves the process reaping problem. The only base image suitable for production I found so far is: https://github.com/phusion/baseimage-docker https://github.com/phusion/baseimage-docker
- rmurri 9y agoCorrect me if I'm wrong, but wouldn't just running a container with --init also reap zombie processes generically?
- Sinaptika 9y agoProcess reaping and signal forwarding are solved by using tini. You can call if from inside the container, by installing it and then changing the entrypoint/cmd. You can also specify it in your docker run/docker create command by adding "--init" I haven't seen the phusion base images in production in almost a year. Usually when an organization gets more experience in building images, they use better solutions then phusion images. tldr Don't use Phusion base images. If you need ssh and logrotate and etc, use lxd or a vm.
- eddd 9y agoI am not currently running docker on prod (but I am about to) you Sir pointed me to a good direction. Thank you!
- praveenweb 9y agoIf you are not concerned about the size of your production image and if your modules don't compile with alpine builds, you can stick to the same debian base image. Or you can use alpine for dev if you are not concerned about debugging too much. I would say it boils down to use cases and priorities.