Update links and host integration documentation

This commit is contained in:
Michael Crosby 2013-10-30 11:59:05 -07:00
parent 3362aaa4df
commit a4d97a4e80
2 changed files with 57 additions and 117 deletions

View File

@ -14,12 +14,16 @@ Building a redis container to link as a child of our web application.
Building the redis container
----------------------------
We will use a pre-build version of redis from the index under
the name ``crosbymichael/redis``. If you are interested in the
Dockerfile that was used to build this container here it is.
Lets build a redis image with the following Dockerfile.
.. code-block:: bash
git clone https://github.com/antirez/redis.git
cd redis
git checkout 2.6
# Save this Dockerfile to the root of the redis repository.
# Build redis from source
# Make sure you have the redis source code checked out in
# the same directory as this Dockerfile
@ -34,7 +38,6 @@ Dockerfile that was used to build this container here it is.
ADD . /redis
RUN (cd /redis && make)
RUN (cd /redis && make test)
RUN mkdir -p /redis-data
VOLUME ["/redis-data"]
@ -43,6 +46,9 @@ Dockerfile that was used to build this container here it is.
ENTRYPOINT ["/redis/src/redis-server"]
CMD ["--dir", "/redis-data"]
# docker build our new redis image from source
docker build -t redis-2.6 .
We need to ``EXPOSE`` the default port of 6379 so that our link knows what ports
to connect to our redis container on. If you do not expose any ports for the
@ -54,31 +60,28 @@ Run the redis container
.. code-block:: bash
docker run -d -e PASSWORD=docker -name redis crosbymichael/redis --requirepass=docker
docker run -d -e PASSWORD=docker -name redis redis-2.6 --requirepass docker
This will run our redis container using the default port of 6379 and using docker
as password to secure our service. By specifying the ``-name`` flag on run
we will assign the name ``redis`` to this container.
We can issue all the commands that you would expect; start, stop, attach, using the name.
The name also allows us to link other containers into this one. If you do not specify a
name on docker run, docker will automatically generate a name for your container.
This will run our redis container wit the password docker
to secure our service. By specifying the ``-name`` flag on run
we will assign the name ``redis`` to this container. If we do not specify a name for
our container via the ``-name`` flag docker will automatically generate a name for us.
We can issue all the commands that you would expect; start, stop, attach, using the name for our container.
The name also allows us to link other containers into this one.
Linking redis as a child
------------------------
Next we can start a new web application that has a dependency on redis and apply a link
to connect both containers. If you noticed when running our redis service we did not use
the ``-p`` option to publish the redis port to the host system. Redis exposed port 6379
but we did not publish the port. This allows docker to prevent all network traffic to
the redis container except when explicitly specified within a link. This is a big win
for security.
to connect both containers. If you noticed when running our redis server we did not use
the ``-p`` flag to publish the redis port to the host system. Redis exposed port 6379 via the Dockerfile
and this is all we need to establish a link.
Now lets start our web application with a link into redis.
.. code-block:: bash
docker run -t -i -link /redis:db -name webapp ubuntu bash
docker run -t -i -link redis:db -name webapp ubuntu bash
root@4c01db0b339c:/# env
@ -101,22 +104,25 @@ Now lets start our web application with a link into redis.
When we inspect the environment of the linked container we can see a few extra environment
variables have been added. When you specified ``-link /redis:db`` you are telling docker
to link the container named ``/redis`` into this new container with the alias ``db``.
variables have been added. When you specified ``-link redis:db`` you are telling docker
to link the container named ``redis`` into this new container with the alias ``db``.
Environment variables are prefixed with the alias so that the parent container can access
network and environment information from the child.
network and environment information from the containers that are linked into it.
.. code-block:: bash
# The name of the child container
DB_NAME=/webapp/db
# The default protocol, ip, and port of the service running in the container
DB_PORT=tcp://172.17.0.8:6379
# A specific protocol, ip, and port of various services
DB_PORT_6379_TCP=tcp://172.17.0.8:6379
DB_PORT_6379_TCP_PROTO=tcp
DB_PORT_6379_TCP_ADDR=172.17.0.8
DB_PORT_6379_TCP_PORT=6379
# Get environment variables of the container
DB_ENV_PASSWORD=dockerpass

View File

@ -13,113 +13,47 @@ You can use your Docker containers with process managers like ``upstart``,
Introduction
------------
If you want a process manager to manage your containers you will need to run
the docker daemon with the ``-r=false`` so that docker will not automatically
restart your containers when the host is restarted.
When you have finished setting up your image and are happy with your
running container, you may want to use a process manager to manage
it. To help with this, we provide a simple image: ``creack/manager:min``
it. When your run ``docker start -a`` docker will automatically attach
to the process and forward all signals so that the process manager can
detect when a container stops and correctly restart it.
This image takes the container ID as parameter. We also can specify
the kind of process manager and metadata like *Author* and
*Description*. The output will will be text suitable for a
configuration file, echoed to stdout. It is up to you to create the
.conf file (for `upstart
<http://upstart.ubuntu.com/cookbook/#job-configuration-file>`_) or
.service file (for `systemd
<http://0pointer.de/public/systemd-man/systemd.service.html>`_) and
put it in the right place for your system.
Here are a few sample scripts for systemd and upstart to integrate with docker.
Usage
-----
Sample Upstart Script
---------------------
.. code-block:: bash
docker run creack/manager:min [OPTIONS] <container id>
description "Redis container"
author "Me"
start on filesystem and started lxc-net and started docker
stop on runlevel [!2345]
respawn
exec docker start -a 0a7e070b698b
.. program:: docker run creack/manager:min
.. cmdoption:: -a="<none>"
Author of the image
.. cmdoption:: -d="<none>"
Description of the image
.. cmdoption:: -t="upstart"
Type of manager requested: ``upstart`` or ``systemd``
Example Output
..............
Sample systemd Script
---------------------
.. code-block:: bash
docker run creack/manager:min -t="systemd" b28605f2f9a4
[Unit]
Description=<none>
Author=<none>
After=docker.service
[Unit]
Description=Redis container
Author=Me
After=docker.service
[Service]
Restart=always
ExecStart=/usr/bin/docker start -a b28605f2f9a4
ExecStop=/usr/bin/docker stop -t 2 b28605f2f9a4
[Service]
Restart=always
ExecStart=/usr/bin/docker start -a 0a7e070b698b
ExecStop=/usr/bin/docker stop -t 2 0a7e070b698b
[Install]
WantedBy=local.target
[Install]
WantedBy=local.target
Development
-----------
The image ``creack/manager:min`` is a ``busybox`` base with the
compiled binary of ``manager.go`` as the :ref:`Entrypoint
<entrypoint_def>`. It is meant to be light and fast to download.
If you would like to change or add things, you can download the full
``creack/manager`` repository that contains ``creack/manager:min`` and
``creack/manager:dev``.
The Dockerfiles and the sources are available in
`/contrib/host_integration
<https://github.com/dotcloud/docker/tree/master/contrib/host_integration>`_.
Upstart
-------
Upstart is the default process manager. The generated script will
start the container after the ``docker`` daemon. If the container
dies, it will respawn. Start/Restart/Stop/Reload are
supported. Reload will send a SIGHUP to the container.
Example (``upstart`` on Debian)
...............................
.. code-block:: bash
CID=$(docker run -d creack/firefo-vnc)
docker run creack/manager:min -a 'Guillaume J. Charmes <guillaume@dotcloud.com>' -d 'Awesome Firefox in VLC' $CID > /etc/init/firefoxvnc.conf
You can now ``start firefoxvnc`` or ``stop firefoxvnc`` and if the container
dies for some reason, upstart will restart it.
Systemd
-------
In order to generate a systemd script, we need to use the ``-t``
option. The generated script will start the container after docker
daemon. If the container dies, it will respawn.
``Start/Restart/Reload/Stop`` are supported.
Example (``systemd`` on Fedora)
...............................
.. code-block:: bash
CID=$(docker run -d creack/firefo-vnc)
docker run creack/manager:min -t systemd -a 'Guillaume J. Charmes <guillaume@dotcloud.com>' -d 'Awesome Firefox in VLC' $CID > /usr/lib/systemd/system/firefoxvnc.service
You can now run ``systemctl start firefoxvnc`` or ``systemctl stop
firefoxvnc`` and if the container dies for some reason, ``systemd``
will restart it.