develop: use relative markdown links

Unfortunately, the only reliable way to create internal links
is to use relative links to other Markdown files. This does
match the way links on GitHub work, but makes it harder to
create these links.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn 2020-04-08 15:36:28 +02:00
parent 0f3caaca6a
commit 9cd60d843e
No known key found for this signature in database
GPG Key ID: 76698F39D527CE8C
5 changed files with 58 additions and 67 deletions

View File

@ -20,7 +20,7 @@ keep image size small:
starting with a generic `ubuntu` image and installing `openjdk` as part of the
Dockerfile.
- [Use multistage builds](/develop/develop-images/multistage-build.md). For
- [Use multistage builds](develop-images/multistage-build.md). For
instance, you can use the `maven` image to build your Java application, then
reset to the `tomcat` image and copy the Java artifacts into the correct
location to deploy your app, all in the same Dockerfile. This means that your
@ -45,7 +45,7 @@ keep image size small:
```
- If you have multiple images with a lot in common, consider creating your own
[base image](/develop/develop-images/baseimages.md) with the shared
[base image](develop-images/baseimages.md) with the shared
components, and basing your unique images on that. Docker only needs to load
the common layers once, and they are cached. This means that your
derivative images use memory on the Docker host more efficiently and load more
@ -63,17 +63,17 @@ keep image size small:
## Where and how to persist application data
- **Avoid** storing application data in your container's writable layer using
[storage drivers](/storage/storagedriver/select-storage-driver.md). This increases the
[storage drivers](../storage/storagedriver/select-storage-driver.md). This increases the
size of your container and is less efficient from an I/O perspective than
using volumes or bind mounts.
- Instead, store data using [volumes](/storage/volumes.md).
- Instead, store data using [volumes](../storage/volumes.md).
- One case where it is appropriate to use
[bind mounts](/storage/bind-mounts.md) is during development,
[bind mounts](../storage/bind-mounts.md) is during development,
when you may want to mount your source directory or a binary you just built
into your container. For production, use a volume instead, mounting it into
the same location as you mounted a bind mount during development.
- For production, use [secrets](/engine/swarm/secrets.md) to store sensitive
application data used by services, and use [configs](/engine/swarm/configs.md)
- For production, use [secrets](../engine/swarm/secrets.md) to store sensitive
application data used by services, and use [configs](../engine/swarm/configs.md)
for non-sensitive data such as configuration files. If you currently use
standalone containers, consider migrating to use single-replica services, so
that you can take advantage of these service-only features.
@ -82,13 +82,13 @@ keep image size small:
## Use CI/CD for testing and deployment
- When you check in a change to source control or create a pull request, use
[Docker Hub](/docker-hub/builds/index.md) or
[Docker Hub](../docker-hub/builds/index.md) or
another CI/CD pipeline to automatically build and tag a Docker image and test
it.
- Take this even further with [Docker Engine - Enterprise](/ee/index.md) by requiring
your development, testing, and security teams to sign images before they can
be deployed into production. This way, you can be sure that before an image is
- Take this even further with by requiring your development, testing, and
security teams to [sign images](../engine/reference/commandline/trust.md)
before they are deployed into production. This way, before an image is
deployed into production, it has been tested and signed off by, for instance,
development, quality, and security teams.
@ -96,6 +96,6 @@ keep image size small:
| Development | Production |
|:--------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Use bind mounts to give your container access to your source code. | Use volumes to store container data. |
| Use Docker Desktop for Mac or Docker Desktop for Windows. | Use Docker Engine - Enterprise if possible, with [userns mapping](/engine/security/userns-remap.md) for greater isolation of Docker processes from host processes. |
| Use bind mounts to give your container access to your source code. | Use volumes to store container data. |
| Use Docker Desktop for Mac or Docker Desktop for Windows. | Use Docker Engine, if possible with [userns mapping](../engine/security/userns-remap.md) for greater isolation of Docker processes from host processes. |
| Don't worry about time drift. | Always run an NTP client on the Docker host and within each container process and sync them all to the same NTP server. If you use swarm services, also ensure that each Docker node syncs its clocks to the same time source as the containers. |

View File

@ -11,13 +11,13 @@ Most Dockerfiles start from a parent image. If you need to completely control
the contents of your image, you might need to create a base image instead.
Here's the difference:
- A [parent image](/glossary.md#parent_image) is the image that your
- A [parent image](../../glossary.md#parent_image) is the image that your
image is based on. It refers to the contents of the `FROM` directive in the
Dockerfile. Each subsequent declaration in the Dockerfile modifies this parent
image. Most Dockerfiles start from a parent image, rather than a base image.
However, the terms are sometimes used interchangeably.
- A [base image](/glossary.md#base_image) has `FROM scratch` in its Dockerfile.
- A [base image](../../glossary.md#base_image) has `FROM scratch` in its Dockerfile.
This topic shows you several ways to create a base image. The specific process
will depend heavily on the Linux distribution you want to package. We have some
@ -115,7 +115,7 @@ If you want to test it out, you can clone
There are lots of resources available to help you write your `Dockerfile`.
* There's a [complete guide to all the instructions](/engine/reference/builder.md) available for use in a `Dockerfile` in the reference section.
* There's a [complete guide to all the instructions](../../engine/reference/builder.md) available for use in a `Dockerfile` in the reference section.
* To help you write a clear, readable, maintainable `Dockerfile`, we've also
written a [`Dockerfile` best practices guide](dockerfile_best-practices.md).
* If your goal is to create a new Official Image, be sure to read up on Docker's [Official Images](/docker-hub/official_images/).
* If your goal is to create a new Official Image, be sure to read up on Docker's [Official Images](../../docker-hub/official_images.md).

View File

@ -16,7 +16,7 @@ efficient images.
Docker builds images automatically by reading the instructions from a
`Dockerfile` -- a text file that contains all commands, in order, needed to
build a given image. A `Dockerfile` adheres to a specific format and set of
instructions which you can find at [Dockerfile reference](/engine/reference/builder/).
instructions which you can find at [Dockerfile reference](../../engine/reference/builder.md).
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
@ -42,7 +42,7 @@ the running container, such as writing new files, modifying existing files, and
deleting files, are written to this thin writable container layer.
For more on image layers (and how Docker builds and stores images), see
[About storage drivers](/storage/storagedriver/).
[About storage drivers](../../storage/storagedriver/index.md).
## General guidelines and recommendations
@ -247,7 +247,7 @@ EOF
To exclude files not relevant to the build (without restructuring your source
repository) use a `.dockerignore` file. This file supports exclusion patterns
similar to `.gitignore` files. For information on creating one, see the
[.dockerignore file](/engine/reference/builder.md#dockerignore-file).
[.dockerignore file](../../engine/reference/builder.md#dockerignore-file).
### Use multi-stage builds
@ -313,14 +313,14 @@ database, and an in-memory cache in a decoupled manner.
Limiting each container to one process is a good rule of thumb, but it is not a
hard and fast rule. For example, not only can containers be
[spawned with an init process](/engine/reference/run.md#specify-an-init-process),
[spawned with an init process](../../engine/reference/run.md#specify-an-init-process),
some programs might spawn additional processes of their own accord. For
instance, [Celery](http://www.celeryproject.org/) can spawn multiple worker
processes, and [Apache](https://httpd.apache.org/) can create one process per
request.
Use your best judgment to keep containers as clean and modular as possible. If
containers depend on each other, you can use [Docker container networks](/network/index.md)
containers depend on each other, you can use [Docker container networks](../../network/index.md)
to ensure that these containers can communicate.
### Minimize the number of layers
@ -399,7 +399,7 @@ maintainable `Dockerfile`.
### FROM
[Dockerfile reference for the FROM instruction](/engine/reference/builder.md#from)
[Dockerfile reference for the FROM instruction](../../engine/reference/builder.md#from)
Whenever possible, use current official images as the basis for your
images. We recommend the [Alpine image](https://hub.docker.com/_/alpine/) as it
@ -408,7 +408,7 @@ being a full Linux distribution.
### LABEL
[Understanding object labels](/config/labels-custom-metadata.md)
[Understanding object labels](../../config/labels-custom-metadata.md)
You can add labels to your image to help organize images by project, record
licensing information, to aid in automation, or for other reasons. For each
@ -448,15 +448,15 @@ LABEL vendor=ACME\ Incorporated \
com.example.release-date="2015-02-12"
```
See [Understanding object labels](/config/labels-custom-metadata.md)
See [Understanding object labels](../../config/labels-custom-metadata.md)
for guidelines about acceptable label keys and values. For information about
querying labels, refer to the items related to filtering in
[Managing labels on objects](/config/labels-custom-metadata.md#manage-labels-on-objects).
See also [LABEL](/engine/reference/builder/#label) in the Dockerfile reference.
[Managing labels on objects](../../config/labels-custom-metadata.md#manage-labels-on-objects).
See also [LABEL](../../engine/reference/builder.md#label) in the Dockerfile reference.
### RUN
[Dockerfile reference for the RUN instruction](/engine/reference/builder.md#run)
[Dockerfile reference for the RUN instruction](../../engine/reference/builder.md#run)
Split long or complex `RUN` statements on multiple lines separated with
backslashes to make your `Dockerfile` more readable, understandable, and
@ -470,7 +470,7 @@ look out for.
Avoid `RUN apt-get upgrade` and `dist-upgrade`, as many of the "essential"
packages from the parent images cannot upgrade inside an
[unprivileged container](/engine/reference/run.md#security-configuration). If a package
[unprivileged container](../../engine/reference/run.md#security-configuration). If a package
contained in the parent image is out-of-date, contact its maintainers. If you
know there is a particular package, `foo`, that needs to be updated, use
`apt-get install -y foo` to update automatically.
@ -592,7 +592,7 @@ RUN set -o pipefail && wget -O - https://some.site | wc -l > /number
### CMD
[Dockerfile reference for the CMD instruction](/engine/reference/builder.md#cmd)
[Dockerfile reference for the CMD instruction](../../engine/reference/builder.md#cmd)
The `CMD` instruction should be used to run the software contained in your
image, along with any arguments. `CMD` should almost always be used in the form
@ -606,13 +606,13 @@ python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD
["php", "-a"]`. Using this form means that when you execute something like
`docker run -it python`, youll get dropped into a usable shell, ready to go.
`CMD` should rarely be used in the manner of `CMD ["param", "param"]` in
conjunction with [`ENTRYPOINT`](/engine/reference/builder.md#entrypoint), unless
conjunction with [`ENTRYPOINT`](../../engine/reference/builder.md#entrypoint), unless
you and your expected users are already quite familiar with how `ENTRYPOINT`
works.
### EXPOSE
[Dockerfile reference for the EXPOSE instruction](/engine/reference/builder.md#expose)
[Dockerfile reference for the EXPOSE instruction](../../engine/reference/builder.md#expose)
The `EXPOSE` instruction indicates the ports on which a container listens
for connections. Consequently, you should use the common, traditional port for
@ -627,7 +627,7 @@ the recipient container back to the source (ie, `MYSQL_PORT_3306_TCP`).
### ENV
[Dockerfile reference for the ENV instruction](/engine/reference/builder.md#env)
[Dockerfile reference for the ENV instruction](../../engine/reference/builder.md#env)
To make new software easier to run, you can use `ENV` to update the
`PATH` environment variable for the software your container installs. For
@ -694,8 +694,8 @@ $ docker run --rm test sh -c 'echo $ADMIN_USER'
### ADD or COPY
- [Dockerfile reference for the ADD instruction](/engine/reference/builder.md#add)
- [Dockerfile reference for the COPY instruction](/engine/reference/builder.md#copy)
- [Dockerfile reference for the ADD instruction](../../engine/reference/builder.md#add)
- [Dockerfile reference for the COPY instruction](../../engine/reference/builder.md#copy)
Although `ADD` and `COPY` are functionally similar, generally speaking, `COPY`
is preferred. Thats because its more transparent than `ADD`. `COPY` only
@ -746,7 +746,7 @@ auto-extraction capability, you should always use `COPY`.
### ENTRYPOINT
[Dockerfile reference for the ENTRYPOINT instruction](/engine/reference/builder.md#entrypoint)
[Dockerfile reference for the ENTRYPOINT instruction](../../engine/reference/builder.md#entrypoint)
The best use for `ENTRYPOINT` is to set the image's main command, allowing that
image to be run as though it was that command (and then use `CMD` as the
@ -803,7 +803,7 @@ exec "$@"
> This script uses [the `exec` Bash command](http://wiki.bash-hackers.org/commands/builtin/exec)
> so that the final running application becomes the container's PID 1. This
> allows the application to receive any Unix signals sent to the container.
> For more, see the [`ENTRYPOINT` reference](/engine/reference/builder.md#entrypoint).
> For more, see the [`ENTRYPOINT` reference](../../engine/reference/builder.md#entrypoint).
The helper script is copied into the container and run via `ENTRYPOINT` on
container start:
@ -836,7 +836,7 @@ $ docker run --rm -it postgres bash
### VOLUME
[Dockerfile reference for the VOLUME instruction](/engine/reference/builder.md#volume)
[Dockerfile reference for the VOLUME instruction](../../engine/reference/builder.md#volume)
The `VOLUME` instruction should be used to expose any database storage area,
configuration storage, or files/folders created by your docker container. You
@ -845,7 +845,7 @@ parts of your image.
### USER
[Dockerfile reference for the USER instruction](/engine/reference/builder.md#user)
[Dockerfile reference for the USER instruction](../../engine/reference/builder.md#user)
If a service can run without privileges, use `USER` to change to a non-root
user. Start by creating the user and group in the `Dockerfile` with something
@ -874,7 +874,7 @@ frequently.
### WORKDIR
[Dockerfile reference for the WORKDIR instruction](/engine/reference/builder.md#workdir)
[Dockerfile reference for the WORKDIR instruction](../../engine/reference/builder.md#workdir)
For clarity and reliability, you should always use absolute paths for your
`WORKDIR`. Also, you should use `WORKDIR` instead of proliferating instructions
@ -883,7 +883,7 @@ maintain.
### ONBUILD
[Dockerfile reference for the ONBUILD instruction](/engine/reference/builder.md#onbuild)
[Dockerfile reference for the ONBUILD instruction](../../engine/reference/builder.md#onbuild)
An `ONBUILD` command executes after the current `Dockerfile` build completes.
`ONBUILD` executes in any child image derived `FROM` the current image. Think
@ -917,8 +917,8 @@ These Official Images have exemplary `Dockerfile`s:
## Additional resources:
* [Dockerfile Reference](/engine/reference/builder.md)
* [Dockerfile Reference](../../engine/reference/builder.md)
* [More about Base Images](baseimages.md)
* [More about Automated Builds](/docker-hub/builds/)
* [Guidelines for Creating Official Images](/docker-hub/official_images/)
* [More about Automated Builds](../../docker-hub/builds/index.md)
* [Guidelines for Creating Official Images](../../docker-hub/official_images.md)

View File

@ -10,16 +10,15 @@ title: Manage images
The easiest way to make your images available for use by others inside or
outside your organization is to use a Docker registry, such as [Docker Hub](#docker-hub),
[Docker Trusted Registry](#docker-trusted-registry), or
by running your own [private registry](#docker-registry).
or by running your own [private registry](#docker-registry).
## Docker Hub
[Docker Hub](/docker-hub/) is a public registry managed by Docker, Inc. It
centralizes information about organizations, user accounts, and images. It
includes a web UI, authentication and authorization using organizations, CLI and
API access using commands such as `docker login`, `docker pull`, and `docker
[Docker Hub](../../docker-hub/index.md) is a public registry managed by Docker,
Inc. It centralizes information about organizations, user accounts, and images.
It includes a web UI, authentication and authorization using organizations, CLI
and API access using commands such as `docker login`, `docker pull`, and `docker
push`, comments, stars, search, and more.
## Docker Registry
@ -32,14 +31,6 @@ pull commands such as `docker pull myregistry.com/stevvooe/batman:voice`.
Docker Hub is an instance of a Docker Registry.
## Docker Trusted Registry
[Docker Trusted Registry](/datacenter/dtr/2.1/guides/index.md) is part of
Docker Enterprise Edition, and is a private, secure Docker registry which
includes features such as image signing and content trust, role-based access
controls, and other Enterprise-grade features.
## Content Trust
When transferring data among networked systems, *trust* is a central concern. In
@ -49,5 +40,5 @@ operates on. You use Docker to push and pull images (data) to a registry.
Content trust gives you the ability to both verify the integrity and the
publisher of all the data received from a registry over any channel.
See [Content trust](/engine/security/trust/index.md) for information about
See [Content trust](../../engine/security/trust/index.md) for information about
configuring and using this feature on Docker clients.

View File

@ -8,7 +8,7 @@ This page contains a list of resources for application developers who would like
## Prerequisites
Work through the learning modules in [Get started](/get-started/index.md) to understand how to build an image and run it as a containerized application.
Work through the learning modules in [Get started](../get-started/index.md) to understand how to build an image and run it as a containerized application.
## Develop new apps on Docker
@ -16,19 +16,19 @@ If you're just getting started developing a brand new app on Docker, check out
these resources to understand some of the most common patterns for getting the
most benefits from Docker.
- Use [multistage builds](/develop/develop-images/multistage-build.md){: target="_blank" class="_"} to keep your images lean
- Manage application data using [volumes](/storage/volumes.md) and [bind mounts](/storage/bind-mounts.md){: target="_blank" class="_"}
- [Scale your app](/get-started/kube-deploy.md){: target="_blank" class="_"} with kubernetes
- [Scale your app](/get-started/swarm-deploy.md){: target="_blank" class="_"} as a swarm service
- [General application development best practices](/develop/dev-best-practices.md){: target="_blank" class="_"}
- Use [multistage builds](develop-images/multistage-build.md){: target="_blank" class="_"} to keep your images lean
- Manage application data using [volumes](../storage/volumes.md) and [bind mounts](../storage/bind-mounts.md){: target="_blank" class="_"}
- [Scale your app](../get-started/kube-deploy.md){: target="_blank" class="_"} with kubernetes
- [Scale your app](../get-started/swarm-deploy.md){: target="_blank" class="_"} as a swarm service
- [General application development best practices](dev-best-practices.md){: target="_blank" class="_"}
## Learn about language-specific app development with Docker
- [Docker for Java developers](https://github.com/docker/labs/tree/master/developer-tools/java/){: target="_blank" class="_"} lab
- [Port a node.js app to Docker](https://github.com/docker/labs/tree/master/developer-tools/nodejs/porting){: target="_blank" class="_"}
- [Ruby on Rails app on Docker](https://github.com/docker/labs/tree/master/developer-tools/ruby){: target="_blank" class="_"} lab
- [Dockerize a .Net Core application](/engine/examples/dotnetcore.md){: target="_blank" class="_"}
- [Dockerize an ASP.NET Core application with SQL Server on Linux](/compose/aspnet-mssql-compose.md){: target="_blank" class="_"} using Docker Compose
- [Dockerize a .Net Core application](../engine/examples/dotnetcore.md){: target="_blank" class="_"}
- [Dockerize an ASP.NET Core application with SQL Server on Linux](../compose/aspnet-mssql-compose.md){: target="_blank" class="_"} using Docker Compose
## Advanced development with the SDK or API