Update markdown language hints to work with "rouge"

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2020-02-05 18:29:08 +01:00
parent 8b24f7eeef
commit 14bbe621e5
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
14 changed files with 77 additions and 78 deletions

View File

@ -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"]
``` ```

View File

@ -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

View File

@ -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,35 +88,34 @@ 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
#!/bin/bash
```bash # turn on bash's job control
#!/bin/bash set -m
# turn on bash's job control # Start the primary process and put it in the background
set -m ./my_main_process &
# Start the primary process and put it in the background # Start the helper process
./my_main_process & ./my_helper_process
# Start the helper process # the my_helper_process might need to know how to wait on the
./my_helper_process # primary process to start before it does its work and returns
# the my_helper_process might need to know how to wait on the
# primary process to start before it does its work and returns
# now we bring the primary process back into the foreground # now we bring the primary process back into the foreground
# and leave it there # and leave it there
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
COPY my_wrapper_script.sh my_wrapper_script.sh COPY my_wrapper_script.sh my_wrapper_script.sh
CMD ./my_wrapper_script.sh CMD ./my_wrapper_script.sh
``` ```
- Use a process manager like `supervisord`. This is a moderately heavy-weight - Use a process manager like `supervisord`. This is a moderately heavy-weight
approach that requires you to package `supervisord` and its configuration in approach that requires you to package `supervisord` and its configuration in
@ -127,12 +126,12 @@ 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
COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
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
CMD ["/usr/bin/supervisord"] CMD ["/usr/bin/supervisord"]
``` ```

View File

@ -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
``` ```

View File

@ -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"]

View File

@ -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

View File

@ -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.
Heres an example from the [`buildpack-deps` image](https://github.com/docker-library/buildpack-deps): Heres 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 Postgress
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"]

View File

@ -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

View File

@ -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 && \

View File

@ -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/
# #

View File

@ -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

View File

@ -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
``` ```

View File

@ -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

View File

@ -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
``` ```