mirror of https://github.com/docker/docs.git
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:
parent
0f3caaca6a
commit
9cd60d843e
|
@ -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. |
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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`, you’ll 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. That’s because it’s 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)
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
Loading…
Reference in New Issue