[cgb_]

I corrected myself for the other person to mean '[..] upgrade your docker containers'. I heavily use LXC containers (and had used openvz and vserver before that) and treat them as individual servers.

All your points about bad sysadmin practices are OS & container agnostic - they can happen on any platform, don't drag Docker into it. Sure there is a culture of 'docker run somebinaryimage [..]' but those people are the ones that do "curl | sudo bash" as well.

Your claim about non-reproducibility of Dockerfiles is bogus. The result of a Dockerfile build gives you precisely the reproducibility you desire. Every time you run a container from that image built from a Dockerfile, you'll get the same filesystem & environment.

Docker 1.6's "Content Addressable Image Identifiers" addresses your build in a year concern by allowing dockerfiles to refer to a digest to ensure you are building against exactly the image you expect (rather than the result of some build process that yum -y upgrades etc, which I think is what you were getting at).

[zobzu]

docker can totally be dragged into this. they keep selling the lie and encouraging most terrible practices and design. talk about self inflicted...

[peterwwillis]

> Every time you run a container from that image built from a Dockerfile, you'll get the same filesystem & environment

The image (and thus container) are the same. Trying to rebuild it from scratch leaves it not the same, typically because the way people put together Dockerfiles and build images does not follow a standard. And it has to do with the container culture.

Let's take a Dockerfile for the CentOS 7 version of nginx (https://github.com/CentOS/CentOS-Dockerfiles/blob/master/ngi...)

  FROM centos:centos7
  MAINTAINER The CentOS Project <[e-mail]>
  
  RUN yum -y update; yum clean all

Right off the bat I think: what the hell? Why are they doing a yum update? A yum update today may very well leave the system in a completely different state than a year ago. There's likely been some package updated in that time, which changes the state of the system. Right off the bat we're screwed.

  RUN yum -y install epel-release tar ; yum clean all
  RUN yum -y install nginx ; yum clean all

And what the hell is this?! There's no version, no build, no checksum. What the hell did we just install? If those packages change in a year, we're screwed. Not to mention 'epel-release' and 'tar' should be set as dependencies somewhere, and the type of dependencies too.

  ADD nginx.conf /etc/nginx/nginx.conf
  RUN echo "daemon off;" >> /etc/nginx/nginx.conf

Oh, cool, just use whatever the hell this config is which may or may not be different from the one that shipped with the original package. And let's just modify it for no apparent reason, too. And definitely make sure we have no way to know what version of that file we're using for this image. Lovely.

  RUN curl https://git.centos.org/sources/httpd/c7/acf5cccf4afaecf3afeb18c50ae59fd5c6504910 \
      | tar -xz -C /usr/share/nginx/html \
      --strip-components=1

The hell? We're pulling some random git sources from a git server which i'm willing to bet has no standard mirrors? On closer inspection it doesn't really look like a git server, but a host named git which hosts files whose names are a checksum, though we don't know where this is from or what exactly it refers to. If this server or file disappears, good luck knowing what in hell was being downloaded here.

  RUN sed -i -e 's/Apache/nginx/g' -e '/apache_pb.gif/d' \ 
      /usr/share/nginx/html/index.html
  
  EXPOSE 80
  
  CMD [ "/usr/sbin/nginx" ]