Minimal image for Deployment to production

[so0k]

I notice all the official images (except slim) include build-essentials.

This is great for development - for production it may however be required to reduce the attack surface.

Regarding slim, I couldn't find the tags on the docker hub? It still builds from source, even though it removes the build-essential packages, is this really necessary?

For production, would it be possible to create a Dockerfile which deploys using the rpm packages?

for example:

FROM debian:wheezy

RUN echo "deb http://packages.erlang-solutions.com/debian wheezy contrib" >> /etc/apt/sources.list \
    && wget http://packages.erlang-solutions.com/debian/erlang_solutions.asc \
    && apt-key add erlang_solutions.asc \
    && apt-get update && apt-get install -y \
    erlang \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

Are there any disadvantages from this approach?

[c0b]

we had such a discussion in docker-library/official-images#1075 @msaraiva already made a Minimal Erlang/OTP image based on Alpine Linux you may want to try it?
https://hub.docker.com/r/msaraiva/erlang/

[c0b]

Are there any disadvantages from this approach?

support to latest erlang/otp release could be lagged behind; building from source code gives us flexibility to keep closer with upstream
https://github.com/erlang/otp/releases (OTP-18.1.5 & OTP-17.5.6.6 )

Look at package download page from erlang solutions, I can't figure out which patch version of 18.1 was that built from? in some cases that may not matter, and we can do it if interests arise with maintaining an esl variant
https://www.erlang-solutions.com/resources/download.html
https://packages.debian.org/source/sid/erlang
https://packages.gentoo.org/packages/dev-lang/erlang

I think most of the programming language official images to include build-essentials is to keep developer friendly, for study purpose; and I haven't heard anyone using that in production deployment.
https://hub.docker.com/_/python/

[so0k]

thanks for clarification, but it should be highlighted more that these are not meant for production

[c0b]

if you ever used official docker images in other programming languages like these, I never heard any of these ever used in production deployment; while that doesn't hurt if we can clarify; PR(s) are welcome 💯

https://hub.docker.com/_/python/
https://hub.docker.com/_/ruby/
https://hub.docker.com/_/java/

[so0k]

I realize that now, and you're correct that it's certainly not clarified on
many of the official images - I guess it should, which is an issue I should
look clarification for on the official images repo.

I'm going to go on a rant here:

As far as I can read about the Docker project, the main advantage of Docker
is supposed to be the guarantee that the same artifacts ran in on a
developer laptop, in test suites, in staging are also used in production.
As far as I can see - all guides recommend official images as opposed to
maintaining your own set of images.

Moreover, at this point, only the Official images are audited by Nautilus
for vulnerabilities - making it even more important to base your builds on
them.

Given the situation highlighted in this issue, it seems the build/compile
steps would need to be split from the packing steps (for example,
statically compiling golang binaries and packing them in scratch
containers, the usage of UniKernels or Dockerception: see
https://github.com/jamiemccrindle/dockerception)

and, if this is the case, this needs to happen at every step to fulfill the
dev/prod paritity promised by the Docker project.

On Fri, Dec 11, 2015 at 12:59 AM, Mr C0B notifications@github.com wrote:

if you ever used official docker images in other programming languages
like these, I never heard any of these ever used in production deployment;
while that doesn't hurt if we can clarify; PR(s) are welcome [image:
💯]

https://hub.docker.com/_/python/
https://hub.docker.com/_/ruby/
https://hub.docker.com/_/java/

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

[c0b]

I just realized that I didn't put slim versions with the official images 💤
please check out this PR docker-library/official-images#1386

[tsloughter]

For production you should not be using these images :).

You don't need most Erlang apps for production most likely, so building a release that is only the applications you need is the best way to go.

I use these images through circleci2.0 to build the release tarball and then use that to build a docker image, with ADD <releasename>.tar.gz to get a minimal image.