kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity

a little re-writing

Browse source 
Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>
This commit is contained in:
Sven Dowideit 2015-02-12 13:48:12 +10:00
parent 6009f2eac4
commit 3c9d45e213
2 changed files with 42 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

52
docs/sources/articles/dockerfile_best-practices.md
View file

@ -291,26 +291,32 @@ auto-extraction capability, you should always use `COPY`.
### [`ENTRYPOINT`](https://docs.docker.com/reference/builder/#entrypoint)
The best use for `ENTRYPOINT` is as the main command.
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
default flags).
Let's start with an example, of an image for the cli tool `s3cmd`:
Let's start with an example of an image for the command line tool `s3cmd`:
ENTRYPOINT ["s3cmd"]
CMD ["--help"]
Now people who consume this image can easily run commands via syntax like the
following:
Now the image can be run like this to show the command's help:
$ docker run scmd ls s3://mybucket
$ docker run s3cmd
This is nice because the image name can double as a refernce to the binary as
Or using the right parameters to execute a command:
$ docker run s3cmd ls s3://mybucket
This is useful because the image name can double as a reference to the binary as
shown in the command above.
People also often use `ENTRYPOINT` is as a helper script.
The `ENTRYPOINT` instruction can also be used in combination with a helper
script, allowing it to function in a similar way to the command above, even
when starting the tool may require more than one step.
For example, let’s look at the `Dockerfile` for the
[Postgres Official Image](https://github.com/docker-library/postgres).
It refers to the following script:
For example, the [Postgres Official Image](https://registry.hub.docker.com/_/postgres/)
uses the following script as its `ENTRYPOINT`:
```bash
#!/bin/bash
@ -329,12 +335,34 @@ fi
exec "$@"
```
That script then gets copied into the container and run via `ENTRYPOINT` on
container startup:
> **Note**:
> 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.
> See the [`ENTRYPOINT`](https://docs.docker.com/reference/builder/#ENTRYPOINT)
> help for more details.
The helper script is copied into the container and run via `ENTRYPOINT` on
container start:
COPY ./docker-entrypoint.sh /
ENTRYPOINT ["/docker-entrypoint.sh"]
This script allows the user to interact with Postgres in several ways.
It can simply start Postgres:
$ docker run postgres
Or, it can be used to run Postgres and pass parameters to the server:
$ docker run postgres postres --help
Lastly, it could also be used to start a totally different tool, such Bash:
$ docker run --rm -it postgres bash
### [`VOLUME`](https://docs.docker.com/reference/builder/#volume)
The `VOLUME` instruction should be used to expose any database storage area,

3
docs/sources/reference/builder.md
View file

@ -626,8 +626,7 @@ ENTRYPOINT ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]
If you need to write a starter script for a single executable, you can ensure that
the final executable receives the Unix signals by using `exec` and `gosu`
(see [the Dockerfile best practices](/articles/dockerfile_best-practices/#entrypoint)
for more details):
commands:
```bash
#!/bin/bash