mirror of https://github.com/docker/cli.git
Update to double-dash everywhere
These were found using `git grep -nE '[^-a-zA-Z0-9<>]-[a-zA-Z0-9]{2}'` (fair warning: _many_ false positives there). Docker-DCO-1.1-Signed-off-by: Andrew Page <admwiggin@gmail.com> (github: tianon)
This commit is contained in:
parent
fb3a8f17c3
commit
6f6214866a
|
@ -79,7 +79,7 @@ complete -c docker -A -f -n '__fish_seen_subcommand_from build' -s t -l tag -d '
|
|||
complete -c docker -f -n '__fish_docker_no_subcommand' -a commit -d "Create a new image from a container's changes"
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from commit' -s a -l author -d 'Author (eg. "John Hannibal Smith <hannibal@a-team.com>"'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from commit' -s m -l message -d 'Commit message'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from commit' -l run -d 'Config automatically applied when the image is run. (ex: -run=\'{"Cmd": ["cat", "/world"], "PortSpecs": ["22"]}\')'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from commit' -l run -d 'Config automatically applied when the image is run. (ex: --run=\'{"Cmd": ["cat", "/world"], "PortSpecs": ["22"]}\')'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from commit' -a '(__fish_print_docker_containers all)' -d "Container"
|
||||
|
||||
# cp
|
||||
|
@ -202,7 +202,7 @@ complete -c docker -A -f -n '__fish_seen_subcommand_from run' -l expose -d 'Expo
|
|||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -s h -l hostname -d 'Container host name'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -s i -l interactive -d 'Keep stdin open even if not attached'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -l link -d 'Add link to another container (name:alias)'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -l lxc-conf -d 'Add custom lxc options -lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -l lxc-conf -d 'Add custom lxc options --lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -s m -l memory -d 'Memory limit (format: <number><optional unit>, where unit = b, k, m or g)'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -s n -l networking -d 'Enable networking for this container'
|
||||
complete -c docker -A -f -n '__fish_seen_subcommand_from run' -l name -d 'Assign a name to the container'
|
||||
|
|
|
@ -174,7 +174,7 @@ __docker_subcommand () {
|
|||
(ps)
|
||||
_arguments '-a[Show all containers. Only running containers are shown by default]' \
|
||||
'-h[Show help]' \
|
||||
'-before-id=-[Show only container created before Id, include non-running one]:containers:__docker_containers' \
|
||||
'--before-id=-[Show only container created before Id, include non-running one]:containers:__docker_containers' \
|
||||
'-n=-[Show n last created containers, include non-running one]:n:(1 5 10 25 50)'
|
||||
;;
|
||||
(tag)
|
||||
|
|
|
@ -193,7 +193,7 @@ well.
|
|||
|
||||
When used in the shell or exec formats, the ``CMD`` instruction sets
|
||||
the command to be executed when running the image. This is
|
||||
functionally equivalent to running ``docker commit -run '{"Cmd":
|
||||
functionally equivalent to running ``docker commit --run '{"Cmd":
|
||||
<command>}'`` outside the builder.
|
||||
|
||||
If you use the *shell* form of the CMD, then the ``<command>`` will
|
||||
|
@ -235,7 +235,7 @@ override the default specified in CMD.
|
|||
``EXPOSE <port> [<port>...]``
|
||||
|
||||
The ``EXPOSE`` instruction exposes ports for use within links. This is
|
||||
functionally equivalent to running ``docker commit -run '{"PortSpecs":
|
||||
functionally equivalent to running ``docker commit --run '{"PortSpecs":
|
||||
["<port>", "<port2>"]}'`` outside the builder. Refer to
|
||||
:ref:`port_redirection` for detailed information.
|
||||
|
||||
|
|
|
@ -52,7 +52,7 @@ Sometimes this can use a more complex value string, as for ``-v``::
|
|||
Strings and Integers
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Options like ``-name=""`` expect a string, and they can only be
|
||||
Options like ``--name=""`` expect a string, and they can only be
|
||||
specified once. Options like ``-c=0`` expect an integer, and they can
|
||||
only be specified once.
|
||||
|
||||
|
@ -94,7 +94,7 @@ daemon and client. To run the daemon you provide the ``-d`` flag.
|
|||
|
||||
To force Docker to use devicemapper as the storage driver, use ``docker -d -s devicemapper``.
|
||||
|
||||
To set the DNS server for all Docker containers, use ``docker -d -dns 8.8.8.8``.
|
||||
To set the DNS server for all Docker containers, use ``docker -d --dns 8.8.8.8``.
|
||||
|
||||
To run the daemon with debug output, use ``docker -d -D``.
|
||||
|
||||
|
@ -305,7 +305,7 @@ by using the ``git://`` schema.
|
|||
-m, --message="": Commit message
|
||||
-a, --author="": Author (eg. "John Hannibal Smith <hannibal@a-team.com>"
|
||||
--run="": Configuration changes to be applied when the image is launched with `docker run`.
|
||||
(ex: -run='{"Cmd": ["cat", "/world"], "PortSpecs": ["22"]}')
|
||||
(ex: --run='{"Cmd": ["cat", "/world"], "PortSpecs": ["22"]}')
|
||||
|
||||
.. _cli_commit_examples:
|
||||
|
||||
|
@ -335,9 +335,9 @@ run ``ls /etc``.
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ docker run -t -name test ubuntu ls
|
||||
$ docker run -t --name test ubuntu ls
|
||||
bin boot dev etc home lib lib64 media mnt opt proc root run sbin selinux srv sys tmp usr var
|
||||
$ docker commit -run='{"Cmd": ["ls","/etc"]}' test test2
|
||||
$ docker commit --run='{"Cmd": ["ls","/etc"]}' test test2
|
||||
933d16de9e70005304c1717b5c6f2f39d6fd50752834c6f34a155c70790011eb
|
||||
$ docker run -t test2
|
||||
adduser.conf gshadow login.defs rc0.d
|
||||
|
@ -358,7 +358,7 @@ Say you have a Dockerfile like so:
|
|||
CMD ["/usr/sbin/sshd -D"]
|
||||
...
|
||||
|
||||
If you run that, make some changes, and then commit, Docker will merge the environment variable and exposed port configuration settings with any that you specify in the -run= option. This is a change from Docker 0.8.0 and prior where no attempt was made to preserve any existing configuration on commit.
|
||||
If you run that, make some changes, and then commit, Docker will merge the environment variable and exposed port configuration settings with any that you specify in the --run= option. This is a change from Docker 0.8.0 and prior where no attempt was made to preserve any existing configuration on commit.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
@ -366,14 +366,14 @@ If you run that, make some changes, and then commit, Docker will merge the envir
|
|||
$ docker run -t -i me/foo /bin/bash
|
||||
foo-container$ [make changes in the container]
|
||||
foo-container$ exit
|
||||
$ docker commit -run='{"Cmd": ["ls"]}' [container-id] me/bar
|
||||
$ docker commit --run='{"Cmd": ["ls"]}' [container-id] me/bar
|
||||
...
|
||||
|
||||
The me/bar image will now have port 22 exposed, MYVAR env var set to 'foobar', and its default command will be ["ls"].
|
||||
|
||||
Note that this is currently a shallow merge. So, for example, if you had specified a new port spec in the -run= config above, that would have clobbered the 'EXPOSE 22' setting from the parent container.
|
||||
Note that this is currently a shallow merge. So, for example, if you had specified a new port spec in the --run= config above, that would have clobbered the 'EXPOSE 22' setting from the parent container.
|
||||
|
||||
Full -run example
|
||||
Full --run example
|
||||
.................
|
||||
|
||||
The ``--run`` JSON hash changes the ``Config`` section when running ``docker inspect CONTAINERID``
|
||||
|
@ -384,7 +384,7 @@ not overridden in the JSON hash will be merged in.
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo docker commit -run='
|
||||
$ sudo docker commit --run='
|
||||
{
|
||||
"Entrypoint" : null,
|
||||
"Privileged" : false,
|
||||
|
@ -516,16 +516,16 @@ Show events in the past from a specified time
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo docker events -since 1378216169
|
||||
$ sudo docker events --since 1378216169
|
||||
[2013-09-03 15:49:29 +0200 CEST] 4386fb97867d: (from 12de384bfb10) die
|
||||
[2013-09-03 15:49:29 +0200 CEST] 4386fb97867d: (from 12de384bfb10) stop
|
||||
|
||||
$ sudo docker events -since '2013-09-03'
|
||||
$ sudo docker events --since '2013-09-03'
|
||||
[2013-09-03 15:49:26 +0200 CEST] 4386fb97867d: (from 12de384bfb10) start
|
||||
[2013-09-03 15:49:29 +0200 CEST] 4386fb97867d: (from 12de384bfb10) die
|
||||
[2013-09-03 15:49:29 +0200 CEST] 4386fb97867d: (from 12de384bfb10) stop
|
||||
|
||||
$ sudo docker events -since '2013-09-03 15:49:29 +0200 CEST'
|
||||
$ sudo docker events --since '2013-09-03 15:49:29 +0200 CEST'
|
||||
[2013-09-03 15:49:29 +0200 CEST] 4386fb97867d: (from 12de384bfb10) die
|
||||
[2013-09-03 15:49:29 +0200 CEST] 4386fb97867d: (from 12de384bfb10) stop
|
||||
|
||||
|
@ -829,7 +829,7 @@ text output:
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo docker inspect -format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
|
||||
$ sudo docker inspect --format='{{range $p, $conf := .NetworkSettings.Ports}} {{$p}} -> {{(index $conf 0).HostPort}} {{end}}' $INSTANCE_ID
|
||||
|
||||
Find a Specific Port Mapping
|
||||
............................
|
||||
|
@ -844,7 +844,7 @@ we ask for the ``HostPort`` field to get the public address.
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo docker inspect -format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' $INSTANCE_ID
|
||||
$ sudo docker inspect --format='{{(index (index .NetworkSettings.Ports "8787/tcp") 0).HostPort}}' $INSTANCE_ID
|
||||
|
||||
Get config
|
||||
..........
|
||||
|
@ -856,7 +856,7 @@ to convert config object into JSON
|
|||
|
||||
.. code-block:: bash
|
||||
|
||||
$ sudo docker inspect -format='{{json .config}}' $INSTANCE_ID
|
||||
$ sudo docker inspect --format='{{json .config}}' $INSTANCE_ID
|
||||
|
||||
|
||||
.. _cli_kill:
|
||||
|
@ -1151,7 +1151,7 @@ image is removed.
|
|||
--volumes-from="": Mount all volumes from the given container(s)
|
||||
--entrypoint="": Overwrite the default entrypoint set by the image
|
||||
-w, --workdir="": Working directory inside the container
|
||||
--lxc-conf=[]: Add custom lxc options -lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"
|
||||
--lxc-conf=[]: Add custom lxc options --lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"
|
||||
--sig-proxy=true: Proxify all received signal to the process (even in non-tty mode)
|
||||
--expose=[]: Expose a port from the container without publishing it to your host
|
||||
--link="": Add link to another container (name:alias)
|
||||
|
@ -1171,7 +1171,7 @@ See :ref:`port_redirection` for more detailed information about the ``--expose``
|
|||
``-p``, ``-P`` and ``--link`` parameters, and :ref:`working_with_links_names` for
|
||||
specific examples using ``--link``.
|
||||
|
||||
Known Issues (run -volumes-from)
|
||||
Known Issues (run --volumes-from)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* :issue:`2702`: "lxc-start: Permission denied - failed to mount"
|
||||
|
@ -1199,7 +1199,7 @@ error. Docker will close this file when ``docker run`` exits.
|
|||
|
||||
This will *not* work, because by default, most potentially dangerous
|
||||
kernel capabilities are dropped; including ``cap_sys_admin`` (which is
|
||||
required to mount filesystems). However, the ``-privileged`` flag will
|
||||
required to mount filesystems). However, the ``--privileged`` flag will
|
||||
allow it to run:
|
||||
|
||||
.. code-block:: bash
|
||||
|
@ -1211,7 +1211,7 @@ allow it to run:
|
|||
none 1.9G 0 1.9G 0% /mnt
|
||||
|
||||
|
||||
The ``-privileged`` flag gives *all* capabilities to the container,
|
||||
The ``--privileged`` flag gives *all* capabilities to the container,
|
||||
and it also lifts all the limitations enforced by the ``device``
|
||||
cgroup controller. In other words, the container can then do almost
|
||||
everything that the host can do. This flag exists to allow special
|
||||
|
@ -1313,7 +1313,7 @@ This example shows 5 containers that might be set up to test a web application c
|
|||
2. Start a pre-prepared ``riakserver`` image, give the container name ``riak`` and expose port ``8098`` to any containers that link to it;
|
||||
3. Start the ``appserver`` image, restricting its memory usage to 100MB, setting two environment variables ``DEVELOPMENT`` and ``BRANCH`` and bind-mounting the current directory (``$(pwd)``) in the container in read-only mode as ``/app/bin``;
|
||||
4. Start the ``webserver``, mapping port ``443`` in the container to port ``1443`` on the Docker server, setting the DNS server to ``dns.dev.org``, creating a volume to put the log files into (so we can access it from another container), then importing the files from the volume exposed by the ``static`` container, and linking to all exposed ports from ``riak`` and ``app``. Lastly, we set the hostname to ``web.sven.dev.org`` so its consistent with the pre-generated SSL certificate;
|
||||
5. Finally, we create a container that runs ``tail -f access.log`` using the logs volume from the ``web`` container, setting the workdir to ``/var/log/httpd``. The ``-rm`` option means that when the container exits, the container's layer is removed.
|
||||
5. Finally, we create a container that runs ``tail -f access.log`` using the logs volume from the ``web`` container, setting the workdir to ``/var/log/httpd``. The ``--rm`` option means that when the container exits, the container's layer is removed.
|
||||
|
||||
|
||||
.. _cli_save:
|
||||
|
|
|
@ -80,7 +80,7 @@ through network connections or shared volumes because the container is
|
|||
no longer listening to the commandline where you executed ``docker
|
||||
run``. You can reattach to a detached container with ``docker``
|
||||
:ref:`cli_attach`. If you choose to run a container in the detached
|
||||
mode, then you cannot use the ``-rm`` option.
|
||||
mode, then you cannot use the ``--rm`` option.
|
||||
|
||||
Foreground
|
||||
..........
|
||||
|
@ -94,7 +94,7 @@ configurable::
|
|||
|
||||
-a=[] : Attach to ``stdin``, ``stdout`` and/or ``stderr``
|
||||
-t=false : Allocate a pseudo-tty
|
||||
-sig-proxy=true: Proxify all received signal to the process (even in non-tty mode)
|
||||
--sig-proxy=true: Proxify all received signal to the process (even in non-tty mode)
|
||||
-i=false : Keep STDIN open even if not attached
|
||||
|
||||
If you do not specify ``-a`` then Docker will `attach everything
|
||||
|
@ -112,7 +112,7 @@ as well as persistent standard input (``stdin``), so you'll use ``-i
|
|||
Container Identification
|
||||
------------------------
|
||||
|
||||
Name (-name)
|
||||
Name (--name)
|
||||
............
|
||||
|
||||
The operator can identify a container in three ways:
|
||||
|
@ -122,7 +122,7 @@ The operator can identify a container in three ways:
|
|||
* Name ("evil_ptolemy")
|
||||
|
||||
The UUID identifiers come from the Docker daemon, and if you do not
|
||||
assign a name to the container with ``-name`` then the daemon will
|
||||
assign a name to the container with ``--name`` then the daemon will
|
||||
also generate a random string name too. The name can become a handy
|
||||
way to add meaning to a container since you can use this name when
|
||||
defining :ref:`links <working_with_links_names>` (or any other place
|
||||
|
@ -137,7 +137,7 @@ container ID out to a file of your choosing. This is similar to how
|
|||
some programs might write out their process ID to a file (you've seen
|
||||
them as PID files)::
|
||||
|
||||
-cidfile="": Write the container ID to the file
|
||||
--cidfile="": Write the container ID to the file
|
||||
|
||||
Network Settings
|
||||
----------------
|
||||
|
@ -145,7 +145,7 @@ Network Settings
|
|||
::
|
||||
|
||||
-n=true : Enable networking for this container
|
||||
-dns=[] : Set custom dns servers for the container
|
||||
--dns=[] : Set custom dns servers for the container
|
||||
|
||||
By default, all containers have networking enabled and they can make
|
||||
any outgoing connections. The operator can completely disable
|
||||
|
@ -154,9 +154,9 @@ networking. In cases like this, you would perform I/O through files or
|
|||
STDIN/STDOUT only.
|
||||
|
||||
Your container will use the same DNS servers as the host by default,
|
||||
but you can override this with ``-dns``.
|
||||
but you can override this with ``--dns``.
|
||||
|
||||
Clean Up (-rm)
|
||||
Clean Up (--rm)
|
||||
--------------
|
||||
|
||||
By default a container's file system persists even after the container
|
||||
|
@ -165,9 +165,9 @@ final state) and you retain all your data by default. But if you are
|
|||
running short-term **foreground** processes, these container file
|
||||
systems can really pile up. If instead you'd like Docker to
|
||||
**automatically clean up the container and remove the file system when
|
||||
the container exits**, you can add the ``-rm`` flag::
|
||||
the container exits**, you can add the ``--rm`` flag::
|
||||
|
||||
-rm=false: Automatically remove the container when it exits (incompatible with -d)
|
||||
--rm=false: Automatically remove the container when it exits (incompatible with -d)
|
||||
|
||||
|
||||
Runtime Constraints on CPU and Memory
|
||||
|
@ -193,8 +193,8 @@ Runtime Privilege and LXC Configuration
|
|||
|
||||
::
|
||||
|
||||
-privileged=false: Give extended privileges to this container
|
||||
-lxc-conf=[]: Add custom lxc options -lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"
|
||||
--privileged=false: Give extended privileges to this container
|
||||
--lxc-conf=[]: Add custom lxc options --lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"
|
||||
|
||||
By default, Docker containers are "unprivileged" and cannot, for
|
||||
example, run a Docker daemon inside a Docker container. This is
|
||||
|
@ -203,16 +203,16 @@ but a "privileged" container is given access to all devices (see
|
|||
lxc-template.go_ and documentation on `cgroups devices
|
||||
<https://www.kernel.org/doc/Documentation/cgroups/devices.txt>`_).
|
||||
|
||||
When the operator executes ``docker run -privileged``, Docker will
|
||||
When the operator executes ``docker run --privileged``, Docker will
|
||||
enable to access to all devices on the host as well as set some
|
||||
configuration in AppArmor to allow the container nearly all the same
|
||||
access to the host as processes running outside containers on the
|
||||
host. Additional information about running with ``-privileged`` is
|
||||
host. Additional information about running with ``--privileged`` is
|
||||
available on the `Docker Blog
|
||||
<http://blog.docker.io/2013/09/docker-can-now-run-within-docker/>`_.
|
||||
|
||||
An operator can also specify LXC options using one or more
|
||||
``-lxc-conf`` parameters. These can be new parameters or override
|
||||
``--lxc-conf`` parameters. These can be new parameters or override
|
||||
existing parameters from the lxc-template.go_. Note that in the
|
||||
future, a given host's Docker daemon may not use LXC, so this is an
|
||||
implementation-specific configuration meant for operators already
|
||||
|
@ -260,7 +260,7 @@ ENTRYPOINT (Default Command to Execute at Runtime
|
|||
|
||||
::
|
||||
|
||||
-entrypoint="": Overwrite the default entrypoint set by the image
|
||||
--entrypoint="": Overwrite the default entrypoint set by the image
|
||||
|
||||
The ENTRYPOINT of an image is similar to a ``COMMAND`` because it
|
||||
specifies what executable to run when the container starts, but it is
|
||||
|
@ -274,12 +274,12 @@ runtime by using a string to specify the new ``ENTRYPOINT``. Here is an
|
|||
example of how to run a shell in a container that has been set up to
|
||||
automatically run something else (like ``/usr/bin/redis-server``)::
|
||||
|
||||
docker run -i -t -entrypoint /bin/bash example/redis
|
||||
docker run -i -t --entrypoint /bin/bash example/redis
|
||||
|
||||
or two examples of how to pass more parameters to that ENTRYPOINT::
|
||||
|
||||
docker run -i -t -entrypoint /bin/bash example/redis -c ls -l
|
||||
docker run -i -t -entrypoint /usr/bin/redis-cli example/redis --help
|
||||
docker run -i -t --entrypoint /bin/bash example/redis -c ls -l
|
||||
docker run -i -t --entrypoint /usr/bin/redis-cli example/redis --help
|
||||
|
||||
|
||||
EXPOSE (Incoming Ports)
|
||||
|
@ -290,16 +290,16 @@ providing the ``EXPOSE`` instruction to give a hint to the operator
|
|||
about what incoming ports might provide services. The following
|
||||
options work with or override the ``Dockerfile``'s exposed defaults::
|
||||
|
||||
-expose=[]: Expose a port from the container
|
||||
--expose=[]: Expose a port from the container
|
||||
without publishing it to your host
|
||||
-P=false : Publish all exposed ports to the host interfaces
|
||||
-p=[] : Publish a container's port to the host (format:
|
||||
ip:hostPort:containerPort | ip::containerPort |
|
||||
hostPort:containerPort)
|
||||
(use 'docker port' to see the actual mapping)
|
||||
-link="" : Add link to another container (name:alias)
|
||||
--link="" : Add link to another container (name:alias)
|
||||
|
||||
As mentioned previously, ``EXPOSE`` (and ``-expose``) make a port
|
||||
As mentioned previously, ``EXPOSE`` (and ``--expose``) make a port
|
||||
available **in** a container for incoming connections. The port number
|
||||
on the inside of the container (where the service listens) does not
|
||||
need to be the same number as the port exposed on the outside of the
|
||||
|
@ -308,16 +308,16 @@ have an HTTP service listening on port 80 (and so you ``EXPOSE 80`` in
|
|||
the ``Dockerfile``), but outside the container the port might be 42800.
|
||||
|
||||
To help a new client container reach the server container's internal
|
||||
port operator ``-expose``'d by the operator or ``EXPOSE``'d by the
|
||||
port operator ``--expose``'d by the operator or ``EXPOSE``'d by the
|
||||
developer, the operator has three choices: start the server container
|
||||
with ``-P`` or ``-p,`` or start the client container with ``-link``.
|
||||
with ``-P`` or ``-p,`` or start the client container with ``--link``.
|
||||
|
||||
If the operator uses ``-P`` or ``-p`` then Docker will make the
|
||||
exposed port accessible on the host and the ports will be available to
|
||||
any client that can reach the host. To find the map between the host
|
||||
ports and the exposed ports, use ``docker port``)
|
||||
|
||||
If the operator uses ``-link`` when starting the new client container,
|
||||
If the operator uses ``--link`` when starting the new client container,
|
||||
then the client container can access the exposed port via a private
|
||||
networking interface. Docker will set some environment variables in
|
||||
the client container to help indicate which interface and port to use.
|
||||
|
@ -329,7 +329,7 @@ The operator can **set any environment variable** in the container by
|
|||
using one or more ``-e`` flags, even overriding those already defined by the
|
||||
developer with a Dockefile ``ENV``::
|
||||
|
||||
$ docker run -e "deep=purple" -rm ubuntu /bin/bash -c export
|
||||
$ docker run -e "deep=purple" --rm ubuntu /bin/bash -c export
|
||||
declare -x HOME="/"
|
||||
declare -x HOSTNAME="85bc26a0e200"
|
||||
declare -x OLDPWD
|
||||
|
@ -341,13 +341,13 @@ developer with a Dockefile ``ENV``::
|
|||
|
||||
Similarly the operator can set the **hostname** with ``-h``.
|
||||
|
||||
``-link name:alias`` also sets environment variables, using the
|
||||
``--link name:alias`` also sets environment variables, using the
|
||||
*alias* string to define environment variables within the container
|
||||
that give the IP and PORT information for connecting to the service
|
||||
container. Let's imagine we have a container running Redis::
|
||||
|
||||
# Start the service container, named redis-name
|
||||
$ docker run -d -name redis-name dockerfiles/redis
|
||||
$ docker run -d --name redis-name dockerfiles/redis
|
||||
4241164edf6f5aca5b0e9e4c9eccd899b0b8080c64c0cd26efe02166c73208f3
|
||||
|
||||
# The redis-name container exposed port 6379
|
||||
|
@ -361,12 +361,12 @@ container. Let's imagine we have a container running Redis::
|
|||
|
||||
|
||||
Yet we can get information about the Redis container's exposed ports
|
||||
with ``-link``. Choose an alias that will form a valid environment
|
||||
with ``--link``. Choose an alias that will form a valid environment
|
||||
variable!
|
||||
|
||||
::
|
||||
|
||||
$ docker run -rm -link redis-name:redis_alias -entrypoint /bin/bash dockerfiles/redis -c export
|
||||
$ docker run --rm --link redis-name:redis_alias --entrypoint /bin/bash dockerfiles/redis -c export
|
||||
declare -x HOME="/"
|
||||
declare -x HOSTNAME="acda7f7b1cdc"
|
||||
declare -x OLDPWD
|
||||
|
@ -383,7 +383,7 @@ variable!
|
|||
|
||||
And we can use that information to connect from another container as a client::
|
||||
|
||||
$ docker run -i -t -rm -link redis-name:redis_alias -entrypoint /bin/bash dockerfiles/redis -c '/redis-stable/src/redis-cli -h $REDIS_ALIAS_PORT_6379_TCP_ADDR -p $REDIS_ALIAS_PORT_6379_TCP_PORT'
|
||||
$ docker run -i -t --rm --link redis-name:redis_alias --entrypoint /bin/bash dockerfiles/redis -c '/redis-stable/src/redis-cli -h $REDIS_ALIAS_PORT_6379_TCP_ADDR -p $REDIS_ALIAS_PORT_6379_TCP_PORT'
|
||||
172.17.0.32:6379>
|
||||
|
||||
VOLUME (Shared Filesystems)
|
||||
|
@ -393,7 +393,7 @@ VOLUME (Shared Filesystems)
|
|||
|
||||
-v=[]: Create a bind mount with: [host-dir]:[container-dir]:[rw|ro].
|
||||
If "container-dir" is missing, then docker creates a new volume.
|
||||
-volumes-from="": Mount all volumes from the given container(s)
|
||||
--volumes-from="": Mount all volumes from the given container(s)
|
||||
|
||||
The volumes commands are complex enough to have their own
|
||||
documentation in section :ref:`volume_def`. A developer can define one
|
||||
|
|
Loading…
Reference in New Issue