mirror of https://github.com/docker/docs.git
Update markdown language hints to work with "rouge"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
parent
8b24f7eeef
commit
14bbe621e5
|
|
@ -90,7 +90,7 @@ The NodeJS service contains the following files:
|
||||||
|
|
||||||
`my-service/Dockerfile`
|
`my-service/Dockerfile`
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM alpine
|
FROM alpine
|
||||||
COPY assets /assets
|
COPY assets /assets
|
||||||
CMD ["cp", "/assets", "/project"]
|
CMD ["cp", "/assets", "/project"]
|
||||||
|
|
@ -113,7 +113,7 @@ services:
|
||||||
|
|
||||||
`my-service/assets/Dockerfile`
|
`my-service/assets/Dockerfile`
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM NODE:9
|
FROM NODE:9
|
||||||
WORKDIR /app
|
WORKDIR /app
|
||||||
COPY package.json .
|
COPY package.json .
|
||||||
|
|
@ -252,7 +252,7 @@ is used to interpolate the variables. Therefore, we provide a utility called
|
||||||
To use the `interpolator` image, update `my-service/Dockerfile` to use the
|
To use the `interpolator` image, update `my-service/Dockerfile` to use the
|
||||||
following Dockerfile:
|
following Dockerfile:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM dockertemplate/interpolator:v0.1.5
|
FROM dockertemplate/interpolator:v0.1.5
|
||||||
COPY assets .
|
COPY assets .
|
||||||
```
|
```
|
||||||
|
|
@ -264,7 +264,7 @@ This places the interpolator image in the `/assets` folder and copies the
|
||||||
folder to the target `/project` folder. If you prefer to do this manually, use
|
folder to the target `/project` folder. If you prefer to do this manually, use
|
||||||
a Dockerfile instead:
|
a Dockerfile instead:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
WORKDIR /assets
|
WORKDIR /assets
|
||||||
CMD ["/interpolator", "-config", "/run/configuration", "-source", "/assets", "-destination", "/project"]
|
CMD ["/interpolator", "-config", "/run/configuration", "-source", "/assets", "-destination", "/project"]
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -42,7 +42,7 @@ configure this app to use our SQL Server database, and then create a
|
||||||
|
|
||||||
1. Create a `Dockerfile` within your app directory and add the following content:
|
1. Create a `Dockerfile` within your app directory and add the following content:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM microsoft/dotnet:2.1-sdk
|
FROM microsoft/dotnet:2.1-sdk
|
||||||
COPY . /app
|
COPY . /app
|
||||||
WORKDIR /app
|
WORKDIR /app
|
||||||
|
|
|
||||||
|
|
@ -75,7 +75,7 @@ this in a few different ways.
|
||||||
|
|
||||||
Next, the Dockerfile:
|
Next, the Dockerfile:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM ubuntu:latest
|
FROM ubuntu:latest
|
||||||
COPY my_first_process my_first_process
|
COPY my_first_process my_first_process
|
||||||
COPY my_second_process my_second_process
|
COPY my_second_process my_second_process
|
||||||
|
|
@ -88,7 +88,6 @@ this in a few different ways.
|
||||||
the main process) then you can use bash's job control to facilitate that.
|
the main process) then you can use bash's job control to facilitate that.
|
||||||
First, the wrapper script:
|
First, the wrapper script:
|
||||||
|
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
#!/bin/bash
|
#!/bin/bash
|
||||||
|
|
||||||
|
|
@ -110,7 +109,7 @@ this in a few different ways.
|
||||||
fg %1
|
fg %1
|
||||||
```
|
```
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM ubuntu:latest
|
FROM ubuntu:latest
|
||||||
COPY my_main_process my_main_process
|
COPY my_main_process my_main_process
|
||||||
COPY my_helper_process my_helper_process
|
COPY my_helper_process my_helper_process
|
||||||
|
|
@ -127,7 +126,7 @@ this in a few different ways.
|
||||||
and `my_second_process` files all exist in the same directory as your
|
and `my_second_process` files all exist in the same directory as your
|
||||||
Dockerfile.
|
Dockerfile.
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM ubuntu:latest
|
FROM ubuntu:latest
|
||||||
RUN apt-get update && apt-get install -y supervisor
|
RUN apt-get update && apt-get install -y supervisor
|
||||||
RUN mkdir -p /var/log/supervisor
|
RUN mkdir -p /var/log/supervisor
|
||||||
|
|
|
||||||
|
|
@ -35,12 +35,12 @@ keep image size small:
|
||||||
fragments. The first creates two layers in the image, while the second
|
fragments. The first creates two layers in the image, while the second
|
||||||
only creates one.
|
only creates one.
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
RUN apt-get -y update
|
RUN apt-get -y update
|
||||||
RUN apt-get install -y python
|
RUN apt-get install -y python
|
||||||
```
|
```
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
RUN apt-get -y update && apt-get install -y python
|
RUN apt-get -y update && apt-get install -y python
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -69,7 +69,7 @@ run it, or tag any image with the name `scratch`. Instead, you can refer to it
|
||||||
in your `Dockerfile`. For example, to create a minimal container using
|
in your `Dockerfile`. For example, to create a minimal container using
|
||||||
`scratch`:
|
`scratch`:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM scratch
|
FROM scratch
|
||||||
ADD hello /
|
ADD hello /
|
||||||
CMD ["/hello"]
|
CMD ["/hello"]
|
||||||
|
|
|
||||||
|
|
@ -171,7 +171,7 @@ To request SSH access for a `RUN` command in the `Dockerfile`, define a mount wi
|
||||||
|
|
||||||
Here is an example Dockerfile using SSH in the container:
|
Here is an example Dockerfile using SSH in the container:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
# syntax=docker/dockerfile:experimental
|
# syntax=docker/dockerfile:experimental
|
||||||
FROM alpine
|
FROM alpine
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -22,7 +22,7 @@ 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
|
Dockerfile instruction. The layers are stacked and each one is a delta of the
|
||||||
changes from the previous layer. Consider this `Dockerfile`:
|
changes from the previous layer. Consider this `Dockerfile`:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM ubuntu:18.04
|
FROM ubuntu:18.04
|
||||||
COPY . /app
|
COPY . /app
|
||||||
RUN make /app
|
RUN make /app
|
||||||
|
|
@ -270,7 +270,7 @@ frequently changed:
|
||||||
|
|
||||||
A Dockerfile for a Go application could look like:
|
A Dockerfile for a Go application could look like:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM golang:1.11-alpine AS build
|
FROM golang:1.11-alpine AS build
|
||||||
|
|
||||||
# Install tools required for project
|
# Install tools required for project
|
||||||
|
|
@ -346,7 +346,7 @@ 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):
|
Here’s an example from the [`buildpack-deps` image](https://github.com/docker-library/buildpack-deps):
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN apt-get update && apt-get install -y \
|
RUN apt-get update && apt-get install -y \
|
||||||
bzr \
|
bzr \
|
||||||
cvs \
|
cvs \
|
||||||
|
|
@ -418,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
|
> Strings with spaces must be quoted **or** the spaces must be escaped. Inner
|
||||||
> quote characters (`"`), must also be escaped.
|
> quote characters (`"`), must also be escaped.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
# Set one or more individual labels
|
# Set one or more individual labels
|
||||||
LABEL com.example.version="0.0.1-beta"
|
LABEL com.example.version="0.0.1-beta"
|
||||||
LABEL vendor1="ACME Incorporated"
|
LABEL vendor1="ACME Incorporated"
|
||||||
|
|
@ -432,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
|
from being created. This is no longer necessary, but combining labels is still
|
||||||
supported.
|
supported.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
# Set multiple labels on one line
|
# Set multiple labels on one line
|
||||||
LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12"
|
LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12"
|
||||||
```
|
```
|
||||||
|
|
||||||
The above can also be written as:
|
The above can also be written as:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
# Set multiple labels at once, using line-continuation characters to break long lines
|
# Set multiple labels at once, using line-continuation characters to break long lines
|
||||||
LABEL vendor=ACME\ Incorporated \
|
LABEL vendor=ACME\ Incorporated \
|
||||||
com.example.is-beta= \
|
com.example.is-beta= \
|
||||||
|
|
@ -478,7 +478,7 @@ 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`
|
Always combine `RUN apt-get update` with `apt-get install` in the same `RUN`
|
||||||
statement. For example:
|
statement. For example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN apt-get update && apt-get install -y \
|
RUN apt-get update && apt-get install -y \
|
||||||
package-bar \
|
package-bar \
|
||||||
package-baz \
|
package-baz \
|
||||||
|
|
@ -489,7 +489,7 @@ 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
|
subsequent `apt-get install` instructions fail. For example, say you have a
|
||||||
Dockerfile:
|
Dockerfile:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM ubuntu:18.04
|
FROM ubuntu:18.04
|
||||||
RUN apt-get update
|
RUN apt-get update
|
||||||
RUN apt-get install -y curl
|
RUN apt-get install -y curl
|
||||||
|
|
@ -498,7 +498,7 @@ RUN apt-get install -y curl
|
||||||
After building the image, all layers are in the Docker cache. Suppose you later
|
After building the image, all layers are in the Docker cache. Suppose you later
|
||||||
modify `apt-get install` by adding extra package:
|
modify `apt-get install` by adding extra package:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM ubuntu:18.04
|
FROM ubuntu:18.04
|
||||||
RUN apt-get update
|
RUN apt-get update
|
||||||
RUN apt-get install -y curl nginx
|
RUN apt-get install -y curl nginx
|
||||||
|
|
@ -516,7 +516,7 @@ 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,
|
cache-busting by specifying a package version. This is known as version pinning,
|
||||||
for example:
|
for example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN apt-get update && apt-get install -y \
|
RUN apt-get update && apt-get install -y \
|
||||||
package-bar \
|
package-bar \
|
||||||
package-baz \
|
package-baz \
|
||||||
|
|
@ -530,7 +530,7 @@ in required packages.
|
||||||
Below is a well-formed `RUN` instruction that demonstrates all the `apt-get`
|
Below is a well-formed `RUN` instruction that demonstrates all the `apt-get`
|
||||||
recommendations.
|
recommendations.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN apt-get update && apt-get install -y \
|
RUN apt-get update && apt-get install -y \
|
||||||
aufs-tools \
|
aufs-tools \
|
||||||
automake \
|
automake \
|
||||||
|
|
@ -564,7 +564,7 @@ refreshed prior to `apt-get install`.
|
||||||
|
|
||||||
Some `RUN` commands depend on the ability to pipe the output of one command into another, using the pipe character (`|`), as in the following example:
|
Some `RUN` commands depend on the ability to pipe the output of one command into another, using the pipe character (`|`), as in the following example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN wget -O - https://some.site | wc -l > /number
|
RUN wget -O - https://some.site | wc -l > /number
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
@ -577,7 +577,7 @@ If you want the command to fail due to an error at any stage in the pipe,
|
||||||
prepend `set -o pipefail &&` to ensure that an unexpected error prevents the
|
prepend `set -o pipefail &&` to ensure that an unexpected error prevents the
|
||||||
build from inadvertently succeeding. For example:
|
build from inadvertently succeeding. For example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN set -o pipefail && wget -O - https://some.site | wc -l > /number
|
RUN set -o pipefail && wget -O - https://some.site | wc -l > /number
|
||||||
```
|
```
|
||||||
> Not all shells support the `-o pipefail` option.
|
> Not all shells support the `-o pipefail` option.
|
||||||
|
|
@ -586,7 +586,7 @@ RUN set -o pipefail && wget -O - https://some.site | wc -l > /number
|
||||||
> Debian-based images, consider using the _exec_ form of `RUN` to explicitly
|
> Debian-based images, consider using the _exec_ form of `RUN` to explicitly
|
||||||
> choose a shell that does support the `pipefail` option. For example:
|
> choose a shell that does support the `pipefail` option. For example:
|
||||||
>
|
>
|
||||||
> ```Dockerfile
|
> ```dockerfile
|
||||||
> RUN ["/bin/bash", "-c", "set -o pipefail && wget -O - https://some.site | wc -l > /number"]
|
> RUN ["/bin/bash", "-c", "set -o pipefail && wget -O - https://some.site | wc -l > /number"]
|
||||||
> ```
|
> ```
|
||||||
|
|
||||||
|
|
@ -641,7 +641,7 @@ 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
|
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:
|
version bumps are easier to maintain, as seen in the following example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
ENV PG_MAJOR 9.3
|
ENV PG_MAJOR 9.3
|
||||||
ENV PG_VERSION 9.3.4
|
ENV PG_VERSION 9.3.4
|
||||||
RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && …
|
RUN curl -SL http://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgress && …
|
||||||
|
|
@ -657,7 +657,7 @@ means that even if you unset the environment variable in a future layer, it
|
||||||
still persists in this layer and its value can't be dumped. You can test this by
|
still persists in this layer and its value can't be dumped. You can test this by
|
||||||
creating a Dockerfile like the following, and then building it.
|
creating a Dockerfile like the following, and then building it.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM alpine
|
FROM alpine
|
||||||
ENV ADMIN_USER="mark"
|
ENV ADMIN_USER="mark"
|
||||||
RUN echo $ADMIN_USER > ./mark
|
RUN echo $ADMIN_USER > ./mark
|
||||||
|
|
@ -678,7 +678,7 @@ good idea. Using `\` as a line continuation character for Linux Dockerfiles
|
||||||
improves readability. You could also put all of the commands into a shell script
|
improves readability. You could also put all of the commands into a shell script
|
||||||
and have the `RUN` command just run that shell script.
|
and have the `RUN` command just run that shell script.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM alpine
|
FROM alpine
|
||||||
RUN export ADMIN_USER="mark" \
|
RUN export ADMIN_USER="mark" \
|
||||||
&& echo $ADMIN_USER > ./mark \
|
&& echo $ADMIN_USER > ./mark \
|
||||||
|
|
@ -711,7 +711,7 @@ the specifically required files change.
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
COPY requirements.txt /tmp/
|
COPY requirements.txt /tmp/
|
||||||
RUN pip install --requirement /tmp/requirements.txt
|
RUN pip install --requirement /tmp/requirements.txt
|
||||||
COPY . /tmp/
|
COPY . /tmp/
|
||||||
|
|
@ -726,7 +726,7 @@ 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
|
have to add another layer in your image. For example, you should avoid doing
|
||||||
things like:
|
things like:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
ADD http://example.com/big.tar.xz /usr/src/things/
|
ADD http://example.com/big.tar.xz /usr/src/things/
|
||||||
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
|
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
|
||||||
RUN make -C /usr/src/things all
|
RUN make -C /usr/src/things all
|
||||||
|
|
@ -734,7 +734,7 @@ RUN make -C /usr/src/things all
|
||||||
|
|
||||||
And instead, do something like:
|
And instead, do something like:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
RUN mkdir -p /usr/src/things \
|
RUN mkdir -p /usr/src/things \
|
||||||
&& curl -SL http://example.com/big.tar.xz \
|
&& curl -SL http://example.com/big.tar.xz \
|
||||||
| tar -xJC /usr/src/things \
|
| tar -xJC /usr/src/things \
|
||||||
|
|
@ -754,7 +754,7 @@ default flags).
|
||||||
|
|
||||||
Let's start with an example of an image for the command line tool `s3cmd`:
|
Let's start with an example of an image for the command line tool `s3cmd`:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
ENTRYPOINT ["s3cmd"]
|
ENTRYPOINT ["s3cmd"]
|
||||||
CMD ["--help"]
|
CMD ["--help"]
|
||||||
```
|
```
|
||||||
|
|
@ -808,7 +808,7 @@ exec "$@"
|
||||||
The helper script is copied into the container and run via `ENTRYPOINT` on
|
The helper script is copied into the container and run via `ENTRYPOINT` on
|
||||||
container start:
|
container start:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
COPY ./docker-entrypoint.sh /
|
COPY ./docker-entrypoint.sh /
|
||||||
ENTRYPOINT ["/docker-entrypoint.sh"]
|
ENTRYPOINT ["/docker-entrypoint.sh"]
|
||||||
CMD ["postgres"]
|
CMD ["postgres"]
|
||||||
|
|
|
||||||
|
|
@ -37,7 +37,7 @@ builder pattern above:
|
||||||
|
|
||||||
**`Dockerfile.build`**:
|
**`Dockerfile.build`**:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM golang:1.7.3
|
FROM golang:1.7.3
|
||||||
WORKDIR /go/src/github.com/alexellis/href-counter/
|
WORKDIR /go/src/github.com/alexellis/href-counter/
|
||||||
COPY app.go .
|
COPY app.go .
|
||||||
|
|
@ -52,7 +52,7 @@ and forget to continue the line using the `\` character, for example.
|
||||||
|
|
||||||
**`Dockerfile`**:
|
**`Dockerfile`**:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM alpine:latest
|
FROM alpine:latest
|
||||||
RUN apk --no-cache add ca-certificates
|
RUN apk --no-cache add ca-certificates
|
||||||
WORKDIR /root/
|
WORKDIR /root/
|
||||||
|
|
@ -97,7 +97,7 @@ multi-stage builds.
|
||||||
|
|
||||||
**`Dockerfile`**:
|
**`Dockerfile`**:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM golang:1.7.3
|
FROM golang:1.7.3
|
||||||
WORKDIR /go/src/github.com/alexellis/href-counter/
|
WORKDIR /go/src/github.com/alexellis/href-counter/
|
||||||
RUN go get -d -v golang.org/x/net/html
|
RUN go get -d -v golang.org/x/net/html
|
||||||
|
|
@ -136,7 +136,7 @@ example improves the previous one by naming the stages and using the name in
|
||||||
the `COPY` instruction. This means that even if the instructions in your
|
the `COPY` instruction. This means that even if the instructions in your
|
||||||
Dockerfile are re-ordered later, the `COPY` doesn't break.
|
Dockerfile are re-ordered later, the `COPY` doesn't break.
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM golang:1.7.3 AS builder
|
FROM golang:1.7.3 AS builder
|
||||||
WORKDIR /go/src/github.com/alexellis/href-counter/
|
WORKDIR /go/src/github.com/alexellis/href-counter/
|
||||||
RUN go get -d -v golang.org/x/net/html
|
RUN go get -d -v golang.org/x/net/html
|
||||||
|
|
@ -177,7 +177,7 @@ copy from a separate image, either using the local image name, a tag available
|
||||||
locally or on a Docker registry, or a tag ID. The Docker client pulls the image
|
locally or on a Docker registry, or a tag ID. The Docker client pulls the image
|
||||||
if necessary and copies the artifact from there. The syntax is:
|
if necessary and copies the artifact from there. The syntax is:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
|
COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
|
||||||
```
|
```
|
||||||
|
|
||||||
|
|
@ -185,7 +185,7 @@ COPY --from=nginx:latest /etc/nginx/nginx.conf /nginx.conf
|
||||||
|
|
||||||
You can pick up where a previous stage left off by referring to it when using the `FROM` directive. For example:
|
You can pick up where a previous stage left off by referring to it when using the `FROM` directive. For example:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM alpine:latest as builder
|
FROM alpine:latest as builder
|
||||||
RUN apk --no-cache add build-base
|
RUN apk --no-cache add build-base
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -100,7 +100,7 @@ containerized application. To avoid this, you can:
|
||||||
`curl` and `python-pip` after they are used to install the Python `requests`
|
`curl` and `python-pip` after they are used to install the Python `requests`
|
||||||
package, all in a single Dockerfile directive:
|
package, all in a single Dockerfile directive:
|
||||||
|
|
||||||
```shell
|
```dockerfile
|
||||||
RUN apt-get update && \
|
RUN apt-get update && \
|
||||||
apt-get install -y --no-install-recommends curl python-pip && \
|
apt-get install -y --no-install-recommends curl python-pip && \
|
||||||
pip install requests && \
|
pip install requests && \
|
||||||
|
|
|
||||||
|
|
@ -16,7 +16,7 @@ This PostgreSQL setup is for development-only purposes. Refer to the
|
||||||
PostgreSQL documentation to fine-tune these settings so that it is
|
PostgreSQL documentation to fine-tune these settings so that it is
|
||||||
suitably secure.
|
suitably secure.
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
#
|
#
|
||||||
# example Dockerfile for https://docs.docker.com/engine/examples/postgresql_service/
|
# example Dockerfile for https://docs.docker.com/engine/examples/postgresql_service/
|
||||||
#
|
#
|
||||||
|
|
|
||||||
|
|
@ -19,7 +19,7 @@ quick access to a test container. Make the following substitutions:
|
||||||
- With `RUN echo 'root:THEPASSWORDYOUCREATED' | chpasswd`, replace "THEPASSWORDYOUCREATED" with the password you've previously generated.
|
- With `RUN echo 'root:THEPASSWORDYOUCREATED' | chpasswd`, replace "THEPASSWORDYOUCREATED" with the password you've previously generated.
|
||||||
- With `RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config`, use `without-password` instead of `prohibit-password` for Ubuntu 14.04.
|
- With `RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config`, use `without-password` instead of `prohibit-password` for Ubuntu 14.04.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM ubuntu:16.04
|
FROM ubuntu:16.04
|
||||||
|
|
||||||
RUN apt-get update && apt-get install -y openssh-server
|
RUN apt-get update && apt-get install -y openssh-server
|
||||||
|
|
|
||||||
|
|
@ -74,7 +74,7 @@ You can also build with content trust. Before running the `docker build` command
|
||||||
you should set the environment variable `DOCKER_CONTENT_TRUST` either manually or
|
you should set the environment variable `DOCKER_CONTENT_TRUST` either manually or
|
||||||
in a scripted fashion. Consider the simple Dockerfile below.
|
in a scripted fashion. Consider the simple Dockerfile below.
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM docker/trusttest:latest
|
FROM docker/trusttest:latest
|
||||||
RUN echo
|
RUN echo
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -104,7 +104,7 @@ counter whenever you visit it.
|
||||||
|
|
||||||
4. Create a file called `Dockerfile` and paste this in:
|
4. Create a file called `Dockerfile` and paste this in:
|
||||||
|
|
||||||
```Dockerfile
|
```dockerfile
|
||||||
FROM python:3.4-alpine
|
FROM python:3.4-alpine
|
||||||
ADD . /code
|
ADD . /code
|
||||||
WORKDIR /code
|
WORKDIR /code
|
||||||
|
|
|
||||||
|
|
@ -29,7 +29,7 @@ A Docker image is built up from a series of layers. Each layer represents an
|
||||||
instruction in the image's Dockerfile. Each layer except the very last one is
|
instruction in the image's Dockerfile. Each layer except the very last one is
|
||||||
read-only. Consider the following Dockerfile:
|
read-only. Consider the following Dockerfile:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM ubuntu:18.04
|
FROM ubuntu:18.04
|
||||||
COPY . /app
|
COPY . /app
|
||||||
RUN make /app
|
RUN make /app
|
||||||
|
|
@ -163,7 +163,7 @@ Docker 1.10).
|
||||||
Now imagine that you have two different Dockerfiles. You use the first one to
|
Now imagine that you have two different Dockerfiles. You use the first one to
|
||||||
create an image called `acme/my-base-image:1.0`.
|
create an image called `acme/my-base-image:1.0`.
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM ubuntu:18.04
|
FROM ubuntu:18.04
|
||||||
COPY . /app
|
COPY . /app
|
||||||
```
|
```
|
||||||
|
|
@ -171,7 +171,7 @@ COPY . /app
|
||||||
The second one is based on `acme/my-base-image:1.0`, but has some additional
|
The second one is based on `acme/my-base-image:1.0`, but has some additional
|
||||||
layers:
|
layers:
|
||||||
|
|
||||||
```conf
|
```dockerfile
|
||||||
FROM acme/my-base-image:1.0
|
FROM acme/my-base-image:1.0
|
||||||
CMD /app/hello.sh
|
CMD /app/hello.sh
|
||||||
```
|
```
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue