Docker Notes

Russell Bateman
September 2016
last update:

Quick Docker notes in preparation for beginning to make use of this technology.


Docker links

The Docker file

Here's a Docker (configuration) file example and some comments on its content. 

dockerfile FROM debian:jessie
MAINTAINER Daniel Alan Miller dalanmiller@rethinkdb.com
RUN apt-key adv --keyserver pgp.mit.edu --recv-keys 1614552E5765227AEC39EFCFA7E00EF33A8F2399
RUN echo "deb http://download.rethinkdb.com/apt jessie main" > /etc/apt/sources.list.d/rethinkdb.list
ENV RETHINKDBPACKAGEVERSION 2.0.4~0jessie
RUN apt-get update \ && apt-get install -y rethinkdb=$RETHINKDBPACKAGEVERSION \ && rm -rf /var/lib/apt/lists/*
VOLUME ["/data"]
WORKDIR /data
CMD ["rethinkdb", "--bind", "all"]
EXPOSE 28015 29015 8080
  1. FROM —pulls (includes) dependencies from other Docker image configurations.

  2. MAINTAINER —comment on whose Docker configuration this is.

  3. RUN —defines command to run from within the Docker container once it's created and begun to run. If your image comes with Python, this could be in Python.

  4. ENV —sets an environment variable and exports it in the container.

  5. VOLUME —defines a path in the container that Docker exposes to the host system (the host running Docker) and mapped using the -v argument when launching that container.

  6. WORKDIR —changes the current working directory of the container in case more commands are to be run (in that location).

  7. CMD —runs commands in the format:
    CMD [ [ [ "executable" ] "argument" ] "more arguments" ]
    Ideally, there should only be one instance of CMD. Otherwise, see ENTRYPOINT:
    dockerfile ENTRYPOINT [ "/swarm" ] CMD [ "--help" ]
  8. EXPOSE —expose the listed ports for mapping to the host via the -p option when launching a container.

Docker best practices
  1. Automate everything. Don't assume that the host server will around for a long time. Build in the proper automation for recovering a Docker instance including data on the local filesytem. In a proper Docker environment, hosting hardware/software must be replaced with new instances upon failure and Docker-hosted services must not skip a beat.
  2. Orchestrate containers. Application code must not assume that the executing container will live forever. It must assume that an application will always exist, because that's the purpose anyway, but not rely on (especially a) hardware instance. For example, a database must mount an external—never a local—volume for data files.