DO: Read this best practices doc instead of/in addition to this wiki.
DO: Put apt-get update and install commands in the same RUN line, so that the update gets run again each time you add something new to install.
```
RUN apt-get -y update && apt-get install -y fortune \
    git \
    python-pip
```
DO: Make sure all directory paths in ADD and COPY commands end in a / so that you copy the file to the directory, rather than creating a file with that name.
```
COPY ./requirements.txt /tmp/
```
DO: Use the --pull flag with the docker build command if you want to pull the latest version of your base image (the image identified on the FROM line at the top of the file).
```
docker build -f Dockerfile -t my-container --pull .
```
DON'T: Expect that --no-cache will pull the most recent version of the base image; it will still use cache for the FROM line.
DO: Include only the dependencies that you need for your container to function.
DO: Include inline comments when the need for a dependency or an instruction in your Dockerfile is not obvious.
DON'T: Include dependencies only used for occasional debugging, etc. In a pinch, these dependencies can be installed adhoc as needed, and do not need to be included every time you build a container.
DO: Use COPY when copying a file from the host machine, to a location on the container.
DON'T: Use ADD, unless you know that it is necessary, and COPY is not sufficient.
DO: Pin everything that you can pin to avoid unexpected changes in dependencies.
DON'T: Expect that when something is not pinned that you are always getting the most recent version of a dependency. Instead, you may get the newest version X on day 1, and on day 2, when version Y is released, you may still be installing version X from cache. The only way to know what version you are getting is to pin. Alternatively, if you want to build the newest version every time, you can bust the cache using --no-cache.
```
docker build -f Dockerfile -t my-container --no-cache .
```
DON'T: Assume that a container that builds and runs in one context will build the same on every machine. Depending on what is cached where, your resulting container could look very different. This is why it is important to regularly verify the functionality of the container with a fresh --no-cache build.
DO: Use the docker images command to test the size of images before and after you a) change a dockerfile, b) add new external dependencies, c) add a significant about of code to the codebase. Sometimes, a single dependency can increase the image size by hundreds of megabytes. The larger the image, the longer it is going to take to build from scratch, push to ECR, deploy to ECS etc., and in the past we have experienced issues with network traffic becoming a bottleneck when several large images are being pulled from ECR at the same time.

el-ethan/docker-does.md

Good example:

Less good example: