mirror of https://github.com/docker/docs.git
				
				
				
			touch-up Markdown formatting and highlighting
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
		
							parent
							
								
									8e71348370
								
							
						
					
					
						commit
						195c6983df
					
				|  | @ -22,8 +22,8 @@ A Docker image consists of read-only layers each of which represents a | |||
| Dockerfile  instruction. The layers are stacked and each one is a delta of the | ||||
| changes from the previous layer. Consider this `Dockerfile`: | ||||
| 
 | ||||
| ```conf | ||||
| FROM ubuntu:15.04 | ||||
| ```Dockerfile | ||||
| FROM ubuntu:18.04 | ||||
| COPY . /app | ||||
| RUN make /app | ||||
| CMD python /app/app.py | ||||
|  | @ -31,7 +31,7 @@ CMD python /app/app.py | |||
| 
 | ||||
| Each instruction creates one layer: | ||||
| 
 | ||||
| - `FROM` creates a layer from the `ubuntu:15.04` Docker image. | ||||
| - `FROM` creates a layer from the `ubuntu:18.04` Docker image. | ||||
| - `COPY` adds files from your Docker client's current directory. | ||||
| - `RUN` builds your application with `make`. | ||||
| - `CMD` specifies what command to run within the container. | ||||
|  | @ -270,8 +270,8 @@ frequently changed: | |||
| 
 | ||||
| A Dockerfile for a Go application could look like: | ||||
| 
 | ||||
| ``` | ||||
| FROM golang:1.9.2-alpine3.6 AS build | ||||
| ```Dockerfile | ||||
| FROM golang:1.11-alpine AS build | ||||
| 
 | ||||
| # Install tools required for project | ||||
| # Run `docker build --no-cache .` to update dependencies | ||||
|  | @ -346,12 +346,14 @@ review. Adding a space before a backslash (`\`) helps as well. | |||
| 
 | ||||
| Here’s an example from the [`buildpack-deps` image](https://github.com/docker-library/buildpack-deps): | ||||
| 
 | ||||
|     RUN apt-get update && apt-get install -y \ | ||||
| ```Dockerfile | ||||
| RUN apt-get update && apt-get install -y \ | ||||
|   bzr \ | ||||
|   cvs \ | ||||
|   git \ | ||||
|   mercurial \ | ||||
|   subversion | ||||
| ``` | ||||
| 
 | ||||
| ### Leverage build cache | ||||
| 
 | ||||
|  | @ -416,7 +418,7 @@ The following examples show the different acceptable formats. Explanatory commen | |||
| > Strings with spaces must be quoted **or** the spaces must be escaped. Inner | ||||
| > quote characters (`"`), must also be escaped. | ||||
| 
 | ||||
| ```conf | ||||
| ```Dockerfile | ||||
| # Set one or more individual labels | ||||
| LABEL com.example.version="0.0.1-beta" | ||||
| LABEL vendor1="ACME Incorporated" | ||||
|  | @ -430,14 +432,14 @@ to combine all labels into a single `LABEL` instruction, to prevent extra layers | |||
| from being created. This is no longer necessary, but combining labels is still | ||||
| supported. | ||||
| 
 | ||||
| ```conf | ||||
| ```Dockerfile | ||||
| # Set multiple labels on one line | ||||
| LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12" | ||||
| ``` | ||||
| 
 | ||||
| The above can also be written as: | ||||
| 
 | ||||
| ```conf | ||||
| ```Dockerfile | ||||
| # Set multiple labels at once, using line-continuation characters to break long lines | ||||
| LABEL vendor=ACME\ Incorporated \ | ||||
|       com.example.is-beta= \ | ||||
|  | @ -476,26 +478,31 @@ know there is a particular package, `foo`, that needs to be updated, use | |||
| Always combine `RUN apt-get update` with `apt-get install` in the same `RUN` | ||||
| statement. For example: | ||||
| 
 | ||||
|         RUN apt-get update && apt-get install -y \ | ||||
| ```Dockerfile | ||||
| RUN apt-get update && apt-get install -y \ | ||||
|     package-bar \ | ||||
|     package-baz \ | ||||
|     package-foo | ||||
| 
 | ||||
| ``` | ||||
| 
 | ||||
| Using `apt-get update` alone in a `RUN` statement causes caching issues and | ||||
| subsequent `apt-get install` instructions fail. For example, say you have a | ||||
| Dockerfile: | ||||
| 
 | ||||
|         FROM ubuntu:14.04 | ||||
|         RUN apt-get update | ||||
|         RUN apt-get install -y curl | ||||
| ```Dockerfile | ||||
| FROM ubuntu:18.04 | ||||
| RUN apt-get update | ||||
| RUN apt-get install -y curl | ||||
| ``` | ||||
| 
 | ||||
| After building the image, all layers are in the Docker cache. Suppose you later | ||||
| modify `apt-get install` by adding extra package: | ||||
| 
 | ||||
|         FROM ubuntu:14.04 | ||||
|         RUN apt-get update | ||||
|         RUN apt-get install -y curl nginx | ||||
| ```Dockerfile | ||||
| FROM ubuntu:18.04 | ||||
| RUN apt-get update | ||||
| RUN apt-get install -y curl nginx | ||||
| ``` | ||||
| 
 | ||||
| Docker sees the initial and modified instructions as identical and reuses the | ||||
| cache from previous steps. As a result the `apt-get update` is _not_ executed | ||||
|  | @ -509,10 +516,12 @@ intervention. This technique is known as "cache busting". You can also achieve | |||
| cache-busting by specifying a package version. This is known as version pinning, | ||||
| for example: | ||||
| 
 | ||||
|         RUN apt-get update && apt-get install -y \ | ||||
| ```Dockerfile | ||||
| RUN apt-get update && apt-get install -y \ | ||||
|     package-bar \ | ||||
|     package-baz \ | ||||
|     package-foo=1.3.* | ||||
| ``` | ||||
| 
 | ||||
| Version pinning forces the build to retrieve a particular version regardless of | ||||
| what’s in the cache. This technique can also reduce failures due to unanticipated changes | ||||
|  | @ -521,7 +530,8 @@ in required packages. | |||
| Below is a well-formed `RUN` instruction that demonstrates all the `apt-get` | ||||
| recommendations. | ||||
| 
 | ||||
|     RUN apt-get update && apt-get install -y \ | ||||
| ```Dockerfile | ||||
| RUN apt-get update && apt-get install -y \ | ||||
|     aufs-tools \ | ||||
|     automake \ | ||||
|     build-essential \ | ||||
|  | @ -535,6 +545,7 @@ recommendations. | |||
|     ruby1.9.1-dev \ | ||||
|     s3cmd=1.1.* \ | ||||
|  && rm -rf /var/lib/apt/lists/* | ||||
| ``` | ||||
| 
 | ||||
| The `s3cmd` argument specifies a version `1.1.*`. If the image previously | ||||
| used an older version, specifying the new one causes a cache bust of `apt-get | ||||
|  | @ -630,10 +641,12 @@ variables specific to services you wish to containerize, such as Postgres’s | |||
| Lastly, `ENV` can also be used to set commonly used version numbers so that | ||||
| version bumps are easier to maintain, as seen in the following example: | ||||
| 
 | ||||
|     ENV PG_MAJOR 9.3 | ||||
|     ENV PG_VERSION 9.3.4 | ||||
|     RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && … | ||||
|     ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH | ||||
| ```Dockerfile | ||||
| ENV PG_MAJOR 9.3 | ||||
| ENV PG_VERSION 9.3.4 | ||||
| RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && … | ||||
| ENV PATH /usr/local/postgres-$PG_MAJOR/bin:$PATH | ||||
| ``` | ||||
| 
 | ||||
| Similar to having constant variables in a program (as opposed to hard-coding | ||||
| values), this approach lets you change a single `ENV` instruction to | ||||
|  | @ -699,9 +712,11 @@ the specifically required files change. | |||
| 
 | ||||
| For example: | ||||
| 
 | ||||
|     COPY requirements.txt /tmp/ | ||||
|     RUN pip install --requirement /tmp/requirements.txt | ||||
|     COPY . /tmp/ | ||||
| ```Dockerfile | ||||
| COPY requirements.txt /tmp/ | ||||
| RUN pip install --requirement /tmp/requirements.txt | ||||
| COPY . /tmp/ | ||||
| ``` | ||||
| 
 | ||||
| Results in fewer cache invalidations for the `RUN` step, than if you put the | ||||
| `COPY . /tmp/` before it. | ||||
|  | @ -712,16 +727,20 @@ delete the files you no longer need after they've been extracted and you don't | |||
| have to add another layer in your image. For example, you should avoid doing | ||||
| things like: | ||||
| 
 | ||||
|     ADD http://example.com/big.tar.xz /usr/src/things/ | ||||
|     RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things | ||||
|     RUN make -C /usr/src/things all | ||||
| ```Dockerfile | ||||
| ADD http://example.com/big.tar.xz /usr/src/things/ | ||||
| RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things | ||||
| RUN make -C /usr/src/things all | ||||
| ``` | ||||
| 
 | ||||
| And instead, do something like: | ||||
| 
 | ||||
|     RUN mkdir -p /usr/src/things \ | ||||
| ```Dockerfile | ||||
| RUN mkdir -p /usr/src/things \ | ||||
|     && curl -SL http://example.com/big.tar.xz \ | ||||
|     | tar -xJC /usr/src/things \ | ||||
|     && make -C /usr/src/things all | ||||
| ``` | ||||
| 
 | ||||
| For other items (files, directories) that do not require `ADD`’s tar | ||||
| auto-extraction capability, you should always use `COPY`. | ||||
|  | @ -736,16 +755,22 @@ default flags). | |||
| 
 | ||||
| Let's start with an example of an image for the command line tool `s3cmd`: | ||||
| 
 | ||||
|     ENTRYPOINT ["s3cmd"] | ||||
|     CMD ["--help"] | ||||
| ```Dockerfile | ||||
| ENTRYPOINT ["s3cmd"] | ||||
| CMD ["--help"] | ||||
| ``` | ||||
| 
 | ||||
| Now the image can be run like this to show the command's help: | ||||
| 
 | ||||
|     $ docker run s3cmd | ||||
| ```bash | ||||
| $ docker run s3cmd | ||||
| ``` | ||||
| 
 | ||||
| Or using the right parameters to execute a command: | ||||
| 
 | ||||
|     $ docker run s3cmd ls s3://mybucket | ||||
| ```bash | ||||
| $ docker run s3cmd ls s3://mybucket | ||||
| ``` | ||||
| 
 | ||||
| This is useful because the image name can double as a reference to the binary as | ||||
| shown in the command above. | ||||
|  | @ -784,23 +809,31 @@ exec "$@" | |||
| The helper script is copied into the container and run via `ENTRYPOINT` on | ||||
| container start: | ||||
| 
 | ||||
|     COPY ./docker-entrypoint.sh / | ||||
|     ENTRYPOINT ["/docker-entrypoint.sh"] | ||||
|     CMD ["postgres"] | ||||
| ```Dockerfile | ||||
| COPY ./docker-entrypoint.sh / | ||||
| ENTRYPOINT ["/docker-entrypoint.sh"] | ||||
| CMD ["postgres"] | ||||
| ``` | ||||
| 
 | ||||
| This script allows the user to interact with Postgres in several ways. | ||||
| 
 | ||||
| It can simply start Postgres: | ||||
| 
 | ||||
|     $ docker run postgres | ||||
| ```bash | ||||
| $ docker run postgres | ||||
| ``` | ||||
| 
 | ||||
| Or, it can be used to run Postgres and pass parameters to the server: | ||||
| 
 | ||||
|     $ docker run postgres postgres --help | ||||
| ```bash | ||||
| $ docker run postgres postgres --help | ||||
| ``` | ||||
| 
 | ||||
| Lastly, it could also be used to start a totally different tool, such as Bash: | ||||
| 
 | ||||
|     $ docker run --rm -it postgres bash | ||||
| ```bash | ||||
| $ docker run --rm -it postgres bash | ||||
| ``` | ||||
| 
 | ||||
| ### VOLUME | ||||
| 
 | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue