mirror of
https://github.com/clearlinux/docker.git
synced 2026-10-03 23:38:24 +00:00
Merge branch 'master' of https://github.com/dotcloud/docker
This commit is contained in:
Kyle Conroy
@@ -165,7 +165,7 @@ Initial version
|
||||
Docker Remote API Client Libraries
|
||||
==================================
|
||||
|
||||
These libraries have been not tested by the Docker Maintainers for
|
||||
These libraries have not been tested by the Docker Maintainers for
|
||||
compatibility. Please file issues with the library owners. If you
|
||||
find more library implementations, please list them in Docker doc bugs
|
||||
and we will add the libraries here.
|
||||
|
||||
@@ -356,7 +356,8 @@ Start a container
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"Binds":["/tmp:/tmp"]
|
||||
"Binds":["/tmp:/tmp"],
|
||||
"LxcConf":{"lxc.utsname":"docker"}
|
||||
}
|
||||
|
||||
**Example response**:
|
||||
|
||||
@@ -15,7 +15,7 @@ To list available commands, either run ``docker`` with no parameters or execute
|
||||
|
||||
$ sudo docker
|
||||
Usage: docker [OPTIONS] COMMAND [arg...]
|
||||
-H=[tcp://127.0.0.1:4243]: tcp://host:port to bind/connect to or unix://path/to/socket to use
|
||||
-H=[unix:///var/run/docker.sock]: tcp://host:port to bind/connect to or unix://path/to/socket to use
|
||||
|
||||
A self-sufficient runtime for linux containers.
|
||||
|
||||
|
||||
@@ -10,4 +10,50 @@
|
||||
|
||||
Usage: docker attach CONTAINER
|
||||
|
||||
Attach to a running container
|
||||
Attach to a running container.
|
||||
|
||||
You can detach from the container again (and leave it running) with
|
||||
``CTRL-c`` (for a quiet exit) or ``CTRL-\`` to get a stacktrace of
|
||||
the Docker client when it quits.
|
||||
|
||||
To stop a container, use ``docker stop``
|
||||
|
||||
To kill the container, use ``docker kill``
|
||||
|
||||
Examples:
|
||||
---------
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ID=$(sudo docker run -d ubuntu /usr/bin/top -b)
|
||||
$ sudo docker attach $ID
|
||||
top - 02:05:52 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
|
||||
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
|
||||
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
|
||||
Mem: 373572k total, 355560k used, 18012k free, 27872k buffers
|
||||
Swap: 786428k total, 0k used, 786428k free, 221740k cached
|
||||
|
||||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
||||
1 root 20 0 17200 1116 912 R 0 0.3 0:00.03 top
|
||||
|
||||
top - 02:05:55 up 3:05, 0 users, load average: 0.01, 0.02, 0.05
|
||||
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
|
||||
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
|
||||
Mem: 373572k total, 355244k used, 18328k free, 27872k buffers
|
||||
Swap: 786428k total, 0k used, 786428k free, 221776k cached
|
||||
|
||||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
||||
1 root 20 0 17208 1144 932 R 0 0.3 0:00.03 top
|
||||
|
||||
|
||||
top - 02:05:58 up 3:06, 0 users, load average: 0.01, 0.02, 0.05
|
||||
Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie
|
||||
Cpu(s): 0.2%us, 0.3%sy, 0.0%ni, 99.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
|
||||
Mem: 373572k total, 355780k used, 17792k free, 27880k buffers
|
||||
Swap: 786428k total, 0k used, 786428k free, 221776k cached
|
||||
|
||||
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
|
||||
1 root 20 0 17208 1144 932 R 0 0.3 0:00.03 top
|
||||
^C$
|
||||
$ sudo docker stop $ID
|
||||
|
||||
|
||||
@@ -2,12 +2,13 @@
|
||||
:description: Copy files/folders from the containers filesystem to the host path
|
||||
:keywords: cp, docker, container, documentation, copy
|
||||
|
||||
===========================================================
|
||||
============================================================================
|
||||
``cp`` -- Copy files/folders from the containers filesystem to the host path
|
||||
===========================================================
|
||||
============================================================================
|
||||
|
||||
::
|
||||
|
||||
Usage: docker cp CONTAINER:RESOURCE HOSTPATH
|
||||
|
||||
Copy files/folders from the containers filesystem to the host path. Paths are relative to the root of the filesystem.
|
||||
Copy files/folders from the containers filesystem to the host
|
||||
path. Paths are relative to the root of the filesystem.
|
||||
|
||||
@@ -30,7 +30,7 @@
|
||||
-volumes-from="": Mount all volumes from the given container.
|
||||
-entrypoint="": Overwrite the default entrypoint set by the image.
|
||||
-w="": Working directory inside the container
|
||||
|
||||
-lxc-conf=[]: Add custom lxc options -lxc-conf="lxc.cgroup.cpuset.cpus = 0,1"
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 194 KiB |
@@ -1,16 +0,0 @@
|
||||
:title: Overview
|
||||
:description: Docker documentation summary
|
||||
:keywords: concepts, documentation, docker, containers
|
||||
|
||||
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
Contents:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
../index
|
||||
manifesto
|
||||
@@ -1,129 +0,0 @@
|
||||
:title: Manifesto
|
||||
:description: An overview of Docker and standard containers
|
||||
:keywords: containers, lxc, concepts, explanation
|
||||
|
||||
.. _dockermanifesto:
|
||||
|
||||
Docker Manifesto
|
||||
----------------
|
||||
|
||||
Docker complements LXC with a high-level API which operates at the
|
||||
process level. It runs unix processes with strong guarantees of
|
||||
isolation and repeatability across servers.
|
||||
|
||||
Docker is a great building block for automating distributed systems:
|
||||
large-scale web deployments, database clusters, continuous deployment
|
||||
systems, private PaaS, service-oriented architectures, etc.
|
||||
|
||||
- **Heterogeneous payloads** Any combination of binaries, libraries,
|
||||
configuration files, scripts, virtualenvs, jars, gems, tarballs, you
|
||||
name it. No more juggling between domain-specific tools. Docker can
|
||||
deploy and run them all.
|
||||
- **Any server** Docker can run on any x64 machine with a modern linux
|
||||
kernel - whether it's a laptop, a bare metal server or a VM. This
|
||||
makes it perfect for multi-cloud deployments.
|
||||
- **Isolation** docker isolates processes from each other and from the
|
||||
underlying host, using lightweight containers.
|
||||
- **Repeatability** Because containers are isolated in their own
|
||||
filesystem, they behave the same regardless of where, when, and
|
||||
alongside what they run.
|
||||
|
||||
.. image:: images/lego_docker.jpg
|
||||
:target: http://bricks.argz.com/ins/7823-1/12
|
||||
|
||||
What is a Standard Container?
|
||||
.............................
|
||||
|
||||
Docker defines a unit of software delivery called a Standard
|
||||
Container. The goal of a Standard Container is to encapsulate a
|
||||
software component and all its dependencies in a format that is
|
||||
self-describing and portable, so that any compliant runtime can run it
|
||||
without extra dependency, regardless of the underlying machine and the
|
||||
contents of the container.
|
||||
|
||||
The spec for Standard Containers is currently work in progress, but it
|
||||
is very straightforward. It mostly defines 1) an image format, 2) a
|
||||
set of standard operations, and 3) an execution environment.
|
||||
|
||||
A great analogy for this is the shipping container. Just like Standard
|
||||
Containers are a fundamental unit of software delivery, shipping
|
||||
containers are a fundamental unit of physical delivery.
|
||||
|
||||
Standard operations
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Just like shipping containers, Standard Containers define a set of
|
||||
STANDARD OPERATIONS. Shipping containers can be lifted, stacked,
|
||||
locked, loaded, unloaded and labelled. Similarly, standard containers
|
||||
can be started, stopped, copied, snapshotted, downloaded, uploaded and
|
||||
tagged.
|
||||
|
||||
|
||||
Content-agnostic
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Just like shipping containers, Standard Containers are
|
||||
CONTENT-AGNOSTIC: all standard operations have the same effect
|
||||
regardless of the contents. A shipping container will be stacked in
|
||||
exactly the same way whether it contains Vietnamese powder coffee or
|
||||
spare Maserati parts. Similarly, Standard Containers are started or
|
||||
uploaded in the same way whether they contain a postgres database, a
|
||||
php application with its dependencies and application server, or Java
|
||||
build artifacts.
|
||||
|
||||
Infrastructure-agnostic
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Both types of containers are INFRASTRUCTURE-AGNOSTIC: they can be
|
||||
transported to thousands of facilities around the world, and
|
||||
manipulated by a wide variety of equipment. A shipping container can
|
||||
be packed in a factory in Ukraine, transported by truck to the nearest
|
||||
routing center, stacked onto a train, loaded into a German boat by an
|
||||
Australian-built crane, stored in a warehouse at a US facility,
|
||||
etc. Similarly, a standard container can be bundled on my laptop,
|
||||
uploaded to S3, downloaded, run and snapshotted by a build server at
|
||||
Equinix in Virginia, uploaded to 10 staging servers in a home-made
|
||||
Openstack cluster, then sent to 30 production instances across 3 EC2
|
||||
regions.
|
||||
|
||||
|
||||
Designed for automation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Because they offer the same standard operations regardless of content
|
||||
and infrastructure, Standard Containers, just like their physical
|
||||
counterpart, are extremely well-suited for automation. In fact, you
|
||||
could say automation is their secret weapon.
|
||||
|
||||
Many things that once required time-consuming and error-prone human
|
||||
effort can now be programmed. Before shipping containers, a bag of
|
||||
powder coffee was hauled, dragged, dropped, rolled and stacked by 10
|
||||
different people in 10 different locations by the time it reached its
|
||||
destination. 1 out of 50 disappeared. 1 out of 20 was damaged. The
|
||||
process was slow, inefficient and cost a fortune - and was entirely
|
||||
different depending on the facility and the type of goods.
|
||||
|
||||
Similarly, before Standard Containers, by the time a software
|
||||
component ran in production, it had been individually built,
|
||||
configured, bundled, documented, patched, vendored, templated, tweaked
|
||||
and instrumented by 10 different people on 10 different
|
||||
computers. Builds failed, libraries conflicted, mirrors crashed,
|
||||
post-it notes were lost, logs were misplaced, cluster updates were
|
||||
half-broken. The process was slow, inefficient and cost a fortune -
|
||||
and was entirely different depending on the language and
|
||||
infrastructure provider.
|
||||
|
||||
Industrial-grade delivery
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
There are 17 million shipping containers in existence, packed with
|
||||
every physical good imaginable. Every single one of them can be loaded
|
||||
on the same boats, by the same cranes, in the same facilities, and
|
||||
sent anywhere in the World with incredible efficiency. It is
|
||||
embarrassing to think that a 30 ton shipment of coffee can safely
|
||||
travel half-way across the World in *less time* than it takes a
|
||||
software team to deliver its code from one datacenter to another
|
||||
sitting 10 miles away.
|
||||
|
||||
With Standard Containers we can put an end to that embarrassment, by
|
||||
making INDUSTRIAL-GRADE DELIVERY of software a reality.
|
||||
@@ -21,3 +21,4 @@ Contents:
|
||||
running_ssh_service
|
||||
couchdb_data_volumes
|
||||
postgresql_service
|
||||
mongodb
|
||||
|
||||
@@ -0,0 +1,100 @@
|
||||
:title: Building a Docker Image with MongoDB
|
||||
:description: How to build a Docker image with MongoDB pre-installed
|
||||
:keywords: docker, example, package installation, networking, mongodb
|
||||
|
||||
.. _mongodb_image:
|
||||
|
||||
Building an Image with MongoDB
|
||||
==============================
|
||||
|
||||
.. include:: example_header.inc
|
||||
|
||||
The goal of this example is to show how you can build your own
|
||||
docker images with MongoDB preinstalled. We will do that by
|
||||
constructing a Dockerfile that downloads a base image, adds an
|
||||
apt source and installs the database software on Ubuntu.
|
||||
|
||||
Creating a ``Dockerfile``
|
||||
+++++++++++++++++++++++++
|
||||
|
||||
Create an empty file called ``Dockerfile``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
touch Dockerfile
|
||||
|
||||
Next, define the parent image you want to use to build your own image on top of.
|
||||
Here, we’ll use `Ubuntu <https://index.docker.io/_/ubuntu/>`_ (tag: ``latest``)
|
||||
available on the `docker index <http://index.docker.io>`_:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
FROM ubuntu:latest
|
||||
|
||||
Since we want to be running the latest version of MongoDB we'll need to add the
|
||||
10gen repo to our apt sources list.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Add 10gen official apt source to the sources list
|
||||
RUN apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10
|
||||
RUN echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | tee /etc/apt/sources.list.d/10gen.list
|
||||
|
||||
Then, we don't want Ubuntu to complain about init not being available so we'll
|
||||
divert /sbin/initctl to /bin/true so it thinks everything is working.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Hack for initctl not being available in Ubuntu
|
||||
RUN dpkg-divert --local --rename --add /sbin/initctl
|
||||
RUN ln -s /bin/true /sbin/initctl
|
||||
|
||||
Afterwards we'll be able to update our apt repositories and install MongoDB
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Install MongoDB
|
||||
RUN apt-get update
|
||||
RUN apt-get install mongodb-10gen
|
||||
|
||||
To run MongoDB we'll have to create the default data directory (because we want it to
|
||||
run without needing to provide a special configuration file)
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Create the MongoDB data directory
|
||||
RUN mkdir -p /data/db
|
||||
|
||||
Finally, we'll expose the standard port that MongoDB runs on (27107) as well as
|
||||
define an ENTRYPOINT for the container.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
EXPOSE 27017
|
||||
ENTRYPOINT ["usr/bin/mongod"]
|
||||
|
||||
Now, lets build the image which will go through the ``Dockerfile`` we made and
|
||||
run all of the commands.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker build -t <yourname>/mongodb .
|
||||
|
||||
Now you should be able to run ``mongod`` as a daemon and be able to connect on
|
||||
the local port!
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Regular style
|
||||
MONGO_ID=$(docker run -d <yourname>/mongodb)
|
||||
|
||||
# Lean and mean
|
||||
MONGO_ID=$(docker run -d <yourname>/mongodb --noprealloc --smallfiles)
|
||||
|
||||
# Check the logs out
|
||||
docker logs $MONGO_ID
|
||||
|
||||
# Connect and play around
|
||||
mongo --port <port you get from `docker ps`>
|
||||
|
||||
Sweet!
|
||||
@@ -93,7 +93,7 @@ To install the right package for CentOS, we’ll use the instructions from the
|
||||
# Enable EPEL for Node.js
|
||||
RUN rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
|
||||
# Install Node.js and npm
|
||||
RUN yum install -y npm-1.2.17-5.el6
|
||||
RUN yum install -y npm
|
||||
|
||||
To bundle your app’s source code inside the docker image, use the ``ADD``
|
||||
command:
|
||||
@@ -137,7 +137,7 @@ Your ``Dockerfile`` should now look like this:
|
||||
# Enable EPEL for Node.js
|
||||
RUN rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
|
||||
# Install Node.js and npm
|
||||
RUN yum install -y npm-1.2.17-5.el6
|
||||
RUN yum install -y npm
|
||||
|
||||
# Bundle app source
|
||||
ADD . /src
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
:title: Welcome to the Docker Documentation
|
||||
:title: Docker Documentation
|
||||
:description: An overview of the Docker Documentation
|
||||
:keywords: containers, lxc, concepts, explanation
|
||||
|
||||
Welcome
|
||||
=======
|
||||
.. image:: static_files/dockerlogo-h.png
|
||||
|
||||
.. image:: concepts/images/dockerlogo-h.png
|
||||
Introduction
|
||||
------------
|
||||
|
||||
``docker``, the Linux Container Runtime, runs Unix processes with
|
||||
strong guarantees of isolation across servers. Your software runs
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
@@ -2,12 +2,15 @@
|
||||
:description: Please note this project is currently under heavy development. It should not be used in production.
|
||||
:keywords: Docker, Docker documentation, requirements, virtualbox, vagrant, git, ssh, putty, cygwin, linux
|
||||
|
||||
**These instructions have changed for 0.6. If you are upgrading from an earlier version, you will need to follow them again.**
|
||||
|
||||
.. _ubuntu_linux:
|
||||
|
||||
Ubuntu Linux
|
||||
============
|
||||
|
||||
**Please note this project is currently under heavy development. It should not be used in production.**
|
||||
**Please note this project is currently under heavy development. It should not be used in production.**
|
||||
|
||||
|
||||
Right now, the officially supported distribution are:
|
||||
|
||||
@@ -35,8 +38,8 @@ Dependencies
|
||||
**Linux kernel 3.8**
|
||||
|
||||
Due to a bug in LXC, docker works best on the 3.8 kernel. Precise
|
||||
comes with a 3.2 kernel, so we need to upgrade it. The kernel we
|
||||
install comes with AUFS built in. We also include the generic headers
|
||||
comes with a 3.2 kernel, so we need to upgrade it. The kernel you'll install when following these steps
|
||||
comes with AUFS built in. We also include the generic headers
|
||||
to enable packages that depend on them, like ZFS and the VirtualBox
|
||||
guest additions. If you didn't install the headers for your "precise"
|
||||
kernel, then you can skip these headers for the "raring" kernel. But
|
||||
@@ -56,14 +59,18 @@ it is safer to include them if you're not sure.
|
||||
Installation
|
||||
------------
|
||||
|
||||
Docker is available as a Ubuntu PPA (Personal Package Archive),
|
||||
`hosted on launchpad <https://launchpad.net/~dotcloud/+archive/lxc-docker>`_
|
||||
which makes installing Docker on Ubuntu very easy.
|
||||
Docker is available as a Debian package, which makes installation easy.
|
||||
|
||||
*Please note that these instructions have changed for 0.6. If you are upgrading from an earlier version, you will need
|
||||
to follow them again.*
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Add the PPA sources to your apt sources list.
|
||||
sudo apt-get install python-software-properties && sudo add-apt-repository ppa:dotcloud/lxc-docker
|
||||
# Add the Docker repository key to your local keychain
|
||||
sudo sh -c "curl https://get.docker.io/gpg | apt-key add -"
|
||||
|
||||
# Add the Docker repository to your apt sources list.
|
||||
sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
|
||||
|
||||
# Update your sources
|
||||
sudo apt-get update
|
||||
@@ -101,30 +108,22 @@ have AUFS filesystem support enabled, so we need to install it.
|
||||
sudo apt-get update
|
||||
sudo apt-get install linux-image-extra-`uname -r`
|
||||
|
||||
**add-apt-repository support**
|
||||
|
||||
Some installations of Ubuntu 13.04 require ``software-properties-common`` to be
|
||||
installed before being able to use add-apt-repository.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo apt-get install software-properties-common
|
||||
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
Docker is available as a Ubuntu PPA (Personal Package Archive),
|
||||
`hosted on launchpad <https://launchpad.net/~dotcloud/+archive/lxc-docker>`_
|
||||
which makes installing Docker on Ubuntu very easy.
|
||||
Docker is available as a Debian package, which makes installation easy.
|
||||
|
||||
|
||||
Add the custom package sources to your apt sources list.
|
||||
*Please note that these instructions have changed for 0.6. If you are upgrading from an earlier version, you will need
|
||||
to follow them again.*
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# add the sources to your apt
|
||||
sudo add-apt-repository ppa:dotcloud/lxc-docker
|
||||
# Add the Docker repository key to your local keychain
|
||||
sudo sh -c "curl http://get.docker.io/gpg | apt-key add -"
|
||||
|
||||
# Add the Docker repository to your apt sources list.
|
||||
sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
|
||||
|
||||
# update
|
||||
sudo apt-get update
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
:description: This guide will setup a new virtualbox virtual machine with docker installed on your computer.
|
||||
:keywords: Docker, Docker documentation, virtualbox, vagrant, git, ssh, putty, cygwin
|
||||
|
||||
**Vagrant installation is temporarily out of date, it will be updated for 0.6 soon.**
|
||||
|
||||
.. _install_using_vagrant:
|
||||
|
||||
Using Vagrant (Mac, Linux)
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
:description: Docker's tutorial to run docker on Windows
|
||||
:keywords: Docker, Docker documentation, Windows, requirements, virtualbox, vagrant, git, ssh, putty, cygwin
|
||||
|
||||
**Vagrant installation is temporarily out of date, it will be updated for 0.6 soon.**
|
||||
|
||||
.. _windows:
|
||||
|
||||
Using Vagrant (Windows)
|
||||
@@ -47,6 +49,8 @@ This should open a cmd prompt window.
|
||||
|
||||
Alternatively, you can also use a Cygwin terminal, or Git Bash (or any other command line program you are usually using). The next steps would be the same.
|
||||
|
||||
.. _launch_ubuntu:
|
||||
|
||||
Launch an Ubuntu virtual server
|
||||
-------------------------------
|
||||
|
||||
@@ -166,3 +170,27 @@ You are now ready for the docker’s “hello world” example. Run
|
||||
All done!
|
||||
|
||||
Now you can continue with the :ref:`hello_world` example.
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
VM does not boot
|
||||
````````````````
|
||||
|
||||
.. image:: images/win/ts_go_bios.JPG
|
||||
|
||||
If you run into this error message "The VM failed to remain in the 'running'
|
||||
state while attempting to boot", please check that your computer has virtualization
|
||||
technology available and activated by going to the BIOS. Here's an example for an HP
|
||||
computer (System configuration / Device configuration)
|
||||
|
||||
.. image:: images/win/hp_bios_vm.JPG
|
||||
|
||||
|
||||
Docker is not installed
|
||||
```````````````````````
|
||||
|
||||
.. image:: images/win/ts_no_docker.JPG
|
||||
|
||||
If you run into this error message "The program 'docker' is currently not installed",
|
||||
try deleting the docker folder and restart from :ref:`launch_ubuntu`
|
||||
|
||||
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
@@ -10,7 +10,7 @@ This documentation has the following resources:
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
concepts/index
|
||||
Introduction <index>
|
||||
installation/index
|
||||
use/index
|
||||
examples/index
|
||||
@@ -19,6 +19,3 @@ This documentation has the following resources:
|
||||
api/index
|
||||
terms/index
|
||||
faq
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
:title: Base Image Creation
|
||||
:description: How to create base images
|
||||
:keywords: Examples, Usage, base image, docker, documentation, examples
|
||||
|
||||
.. _base_image_creation:
|
||||
|
||||
Base Image Creation
|
||||
===================
|
||||
|
||||
So you want to create your own :ref:`base_image_def`? Great!
|
||||
|
||||
The specific process will depend heavily on the Linux distribution you
|
||||
want to package. We have some examples below, and you are encouraged
|
||||
to submit pull requests to contribute new ones.
|
||||
|
||||
Getting Started
|
||||
...............
|
||||
|
||||
In general, you'll want to start with a working machine that is
|
||||
running the distribution you'd like to package as a base image, though
|
||||
that is not required for some tools like Debian's `Debootstrap
|
||||
<https://wiki.debian.org/Debootstrap>`_, which you can also use to
|
||||
build Ubuntu images.
|
||||
|
||||
It can be as simple as this to create an Ubuntu base image::
|
||||
|
||||
$ sudo debootstrap raring raring > /dev/null
|
||||
$ sudo tar -C raring -c . | sudo docker import - raring
|
||||
a29c15f1bf7a
|
||||
$ sudo docker run raring cat /etc/lsb-release
|
||||
DISTRIB_ID=Ubuntu
|
||||
DISTRIB_RELEASE=13.04
|
||||
DISTRIB_CODENAME=raring
|
||||
DISTRIB_DESCRIPTION="Ubuntu 13.04"
|
||||
|
||||
There are more example scripts for creating base images in the
|
||||
Docker Github Repo:
|
||||
|
||||
* `BusyBox <https://github.com/dotcloud/docker/blob/master/contrib/mkimage-busybox.sh>`_
|
||||
* `CentOS
|
||||
<https://github.com/dotcloud/docker/blob/master/contrib/mkimage-centos.sh>`_
|
||||
* `Debian
|
||||
<https://github.com/dotcloud/docker/blob/master/contrib/mkimage-debian.sh>`_
|
||||
@@ -33,6 +33,8 @@ Running an interactive shell
|
||||
|
||||
# Run an interactive shell in the ubuntu image,
|
||||
# allocate a tty, attach stdin and stdout
|
||||
# To detach the tty without exiting the shell,
|
||||
# use the escape sequence Ctrl-p + Ctrl-q
|
||||
sudo docker run -i -t ubuntu /bin/bash
|
||||
|
||||
Why ``sudo``?
|
||||
@@ -41,7 +43,7 @@ Why ``sudo``?
|
||||
The ``docker`` daemon always runs as root, and since ``docker``
|
||||
version 0.5.2, ``docker`` binds to a Unix socket instead of a TCP
|
||||
port. By default that Unix socket is owned by the user *root*, and so,
|
||||
by default, you can access it with ``sudo``.
|
||||
by default, you can access it with ``sudo``.
|
||||
|
||||
Starting in version 0.5.3, if you create a Unix group called *docker*
|
||||
and add users to it, then the ``docker`` daemon will make the
|
||||
@@ -56,6 +58,8 @@ you don't need to add ``sudo`` to all the client commands.
|
||||
sudo groupadd docker
|
||||
|
||||
# Add the ubuntu user to the docker group
|
||||
# You may have to logout and log back in again for
|
||||
# this to take effect
|
||||
sudo gpasswd -a ubuntu docker
|
||||
|
||||
# Restart the docker daemon
|
||||
|
||||
+112
-21
@@ -4,13 +4,13 @@
|
||||
|
||||
.. _dockerbuilder:
|
||||
|
||||
==================
|
||||
Dockerfile Builder
|
||||
==================
|
||||
======================
|
||||
Dockerfiles for Images
|
||||
======================
|
||||
|
||||
**Docker can act as a builder** and read instructions from a text
|
||||
Dockerfile to automate the steps you would otherwise make manually to
|
||||
create an image. Executing ``docker build`` will run your steps and
|
||||
``Dockerfile`` to automate the steps you would otherwise take manually
|
||||
to create an image. Executing ``docker build`` will run your steps and
|
||||
commit them along the way, giving you a final image.
|
||||
|
||||
.. contents:: Table of Contents
|
||||
@@ -35,6 +35,8 @@ build succeeds:
|
||||
Docker will run your steps one-by-one, committing the result if necessary,
|
||||
before finally outputting the ID of your new image.
|
||||
|
||||
When you're done with your build, you're ready to look into :ref:`image_push`.
|
||||
|
||||
2. Format
|
||||
=========
|
||||
|
||||
@@ -48,9 +50,9 @@ The Dockerfile format is quite simple:
|
||||
The Instruction is not case-sensitive, however convention is for them to be
|
||||
UPPERCASE in order to distinguish them from arguments more easily.
|
||||
|
||||
Docker evaluates the instructions in a Dockerfile in order. **The first
|
||||
instruction must be `FROM`** in order to specify the base image from
|
||||
which you are building.
|
||||
Docker evaluates the instructions in a Dockerfile in order. **The
|
||||
first instruction must be `FROM`** in order to specify the
|
||||
:ref:`base_image_def` from which you are building.
|
||||
|
||||
Docker will ignore **comment lines** *beginning* with ``#``. A comment
|
||||
marker anywhere in the rest of the line will be treated as an argument.
|
||||
@@ -68,7 +70,9 @@ building images.
|
||||
|
||||
The ``FROM`` instruction sets the :ref:`base_image_def` for subsequent
|
||||
instructions. As such, a valid Dockerfile must have ``FROM`` as its
|
||||
first instruction.
|
||||
first instruction. The image can be any valid image -- it is
|
||||
especially easy to start by **pulling an image** from the
|
||||
:ref:`using_public_repositories`.
|
||||
|
||||
``FROM`` must be the first non-comment instruction in the
|
||||
``Dockerfile``.
|
||||
@@ -102,11 +106,50 @@ control.
|
||||
3.4 CMD
|
||||
-------
|
||||
|
||||
``CMD <command>``
|
||||
CMD has three forms:
|
||||
|
||||
The ``CMD`` instruction sets the command to be executed when running
|
||||
the image. This is functionally equivalent to running ``docker commit
|
||||
-run '{"Cmd": <command>}'`` outside the builder.
|
||||
* ``CMD ["executable","param1","param2"]`` (like an *exec*, preferred form)
|
||||
* ``CMD ["param1","param2"]`` (as *default parameters to ENTRYPOINT*)
|
||||
* ``CMD command param1 param2`` (as a *shell*)
|
||||
|
||||
There can only be one CMD in a Dockerfile. If you list more than one
|
||||
CMD then only the last CMD will take effect.
|
||||
|
||||
**The main purpose of a CMD is to provide defaults for an executing
|
||||
container.** These defaults can include an executable, or they can
|
||||
omit the executable, in which case you must specify an ENTRYPOINT as
|
||||
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":
|
||||
<command>}'`` outside the builder.
|
||||
|
||||
If you use the *shell* form of the CMD, then the ``<command>`` will
|
||||
execute in ``/bin/sh -c``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
FROM ubuntu
|
||||
CMD echo "This is a test." | wc -
|
||||
|
||||
If you want to **run your** ``<command>`` **without a shell** then you
|
||||
must express the command as a JSON array and give the full path to the
|
||||
executable. **This array form is the preferred format of CMD.** Any
|
||||
additional parameters must be individually expressed as strings in the
|
||||
array:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
FROM ubuntu
|
||||
CMD ["/usr/bin/wc","--help"]
|
||||
|
||||
If you would like your container to run the same executable every
|
||||
time, then you should consider using ``ENTRYPOINT`` in combination
|
||||
with ``CMD``. See :ref:`entrypoint_def`.
|
||||
|
||||
If the user specifies arguments to ``docker run`` then they will
|
||||
override the default specified in CMD.
|
||||
|
||||
.. note::
|
||||
Don't confuse ``RUN`` with ``CMD``. ``RUN`` actually runs a
|
||||
@@ -121,7 +164,7 @@ the image. This is functionally equivalent to running ``docker commit
|
||||
The ``EXPOSE`` instruction sets ports to be publicly exposed when
|
||||
running the image. This is functionally equivalent to running ``docker
|
||||
commit -run '{"PortSpecs": ["<port>", "<port2>"]}'`` outside the
|
||||
builder.
|
||||
builder. Take a look at :ref:`port_redirection` for more information.
|
||||
|
||||
3.6 ENV
|
||||
-------
|
||||
@@ -186,16 +229,55 @@ The copy obeys the following rules:
|
||||
directories in its path. All new files and directories are created
|
||||
with mode 0755, uid and gid 0.
|
||||
|
||||
.. _entrypoint_def:
|
||||
|
||||
3.8 ENTRYPOINT
|
||||
--------------
|
||||
|
||||
``ENTRYPOINT ["/bin/echo"]``
|
||||
ENTRYPOINT has two forms:
|
||||
|
||||
The ``ENTRYPOINT`` instruction adds an entry command that will not be
|
||||
overwritten when arguments are passed to docker run, unlike the
|
||||
* ``ENTRYPOINT ["executable", "param1", "param2"]`` (like an *exec*,
|
||||
preferred form)
|
||||
* ``ENTRYPOINT command param1 param2`` (as a *shell*)
|
||||
|
||||
There can only be one ``ENTRYPOINT`` in a Dockerfile. If you have more
|
||||
than one ``ENTRYPOINT``, then only the last one in the Dockerfile will
|
||||
have an effect.
|
||||
|
||||
An ``ENTRYPOINT`` helps you to configure a container that you can run
|
||||
as an executable. That is, when you specify an ``ENTRYPOINT``, then
|
||||
the whole container runs as if it was just that executable.
|
||||
|
||||
The ``ENTRYPOINT`` instruction adds an entry command that will **not**
|
||||
be overwritten when arguments are passed to ``docker run``, unlike the
|
||||
behavior of ``CMD``. This allows arguments to be passed to the
|
||||
entrypoint. i.e. ``docker run <image> -d`` will pass the "-d" argument
|
||||
to the entrypoint.
|
||||
entrypoint. i.e. ``docker run <image> -d`` will pass the "-d"
|
||||
argument to the ENTRYPOINT.
|
||||
|
||||
You can specify parameters either in the ENTRYPOINT JSON array (as in
|
||||
"like an exec" above), or by using a CMD statement. Parameters in the
|
||||
ENTRYPOINT will not be overridden by the ``docker run`` arguments, but
|
||||
parameters specified via CMD will be overridden by ``docker run``
|
||||
arguments.
|
||||
|
||||
Like a ``CMD``, you can specify a plain string for the ENTRYPOINT and
|
||||
it will execute in ``/bin/sh -c``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
FROM ubuntu
|
||||
ENTRYPOINT wc -l -
|
||||
|
||||
For example, that Dockerfile's image will *always* take stdin as input
|
||||
("-") and print the number of lines ("-l"). If you wanted to make
|
||||
this optional but default, you could use a CMD:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
FROM ubuntu
|
||||
CMD ["-l", "-"]
|
||||
ENTRYPOINT ["/usr/bin/wc"]
|
||||
|
||||
|
||||
3.9 VOLUME
|
||||
----------
|
||||
@@ -205,14 +287,23 @@ to the entrypoint.
|
||||
The ``VOLUME`` instruction will add one or more new volumes to any
|
||||
container created from the image.
|
||||
|
||||
3.10 WORKDIR
|
||||
--------------
|
||||
3.10 USER
|
||||
---------
|
||||
|
||||
``USER daemon``
|
||||
|
||||
The ``USER`` instruction sets the username or UID to use when running
|
||||
the image.
|
||||
|
||||
3.11 WORKDIR
|
||||
------------
|
||||
|
||||
``WORKDIR /path/to/workdir``
|
||||
|
||||
The ``WORKDIR`` instruction sets the working directory in which
|
||||
the command given by ``CMD`` is executed.
|
||||
|
||||
|
||||
4. Dockerfile Examples
|
||||
======================
|
||||
|
||||
|
||||
@@ -13,8 +13,8 @@ Contents:
|
||||
:maxdepth: 1
|
||||
|
||||
basics
|
||||
workingwithrepository
|
||||
port_redirection
|
||||
builder
|
||||
workingwithrepository
|
||||
baseimages
|
||||
port_redirection
|
||||
puppet
|
||||
|
||||
|
||||
@@ -3,6 +3,8 @@
|
||||
:keywords: Usage, basic port, docker, documentation, examples
|
||||
|
||||
|
||||
.. _port_redirection:
|
||||
|
||||
Port redirection
|
||||
================
|
||||
|
||||
|
||||
@@ -28,12 +28,18 @@ repositories. You can host your own Registry too! Docker acts as a
|
||||
client for these services via ``docker search, pull, login`` and
|
||||
``push``.
|
||||
|
||||
Top-level, User, and Your Own Repositories
|
||||
------------------------------------------
|
||||
.. _using_public_repositories:
|
||||
|
||||
Public Repositories
|
||||
-------------------
|
||||
|
||||
There are two types of public repositories: *top-level* repositories
|
||||
which are controlled by the Docker team, and *user* repositories
|
||||
created by individual contributors.
|
||||
created by individual contributors. Anyone can read from these
|
||||
repositories -- they really help people get started quickly! You could
|
||||
also use :ref:`using_private_repositories` if you need to keep control
|
||||
of who accesses your images, but we will only refer to public
|
||||
repositories in these examples.
|
||||
|
||||
* Top-level repositories can easily be recognized by **not** having a
|
||||
``/`` (slash) in their name. These repositories can generally be
|
||||
@@ -46,28 +52,6 @@ created by individual contributors.
|
||||
* User images are not checked, it is therefore up to you whether or
|
||||
not you trust the creator of this image.
|
||||
|
||||
Right now (version 0.5), private repositories are only possible by
|
||||
hosting `your own registry
|
||||
<https://github.com/dotcloud/docker-registry>`_. To push or pull to a
|
||||
repository on your own registry, you must prefix the tag with the
|
||||
address of the registry's host, like this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Tag to create a repository with the full registry location.
|
||||
# The location (e.g. localhost.localdomain:5000) becomes
|
||||
# a permanent part of the repository name
|
||||
sudo docker tag 0u812deadbeef localhost.localdomain:5000/repo_name
|
||||
|
||||
# Push the new repository to its home location on localhost
|
||||
sudo docker push localhost.localdomain:5000/repo_name
|
||||
|
||||
Once a repository has your registry's host name as part of the tag,
|
||||
you can push and pull it like any other repository, but it will
|
||||
**not** be searchable (or indexed at all) in the Central Index, and
|
||||
there will be no user name checking performed. Your registry will
|
||||
function completely independently from the Central Index.
|
||||
|
||||
Find public images available on the Central Index
|
||||
-------------------------------------------------
|
||||
|
||||
@@ -105,6 +89,7 @@ If your username does not exist it will prompt you to also enter a
|
||||
password and your e-mail address. It will then automatically log you
|
||||
in.
|
||||
|
||||
.. _container_commit:
|
||||
|
||||
Committing a container to a named image
|
||||
---------------------------------------
|
||||
@@ -117,16 +102,45 @@ your container to an image within your username namespace.
|
||||
# for example docker commit $CONTAINER_ID dhrp/kickassapp
|
||||
sudo docker commit <container_id> <username>/<repo_name>
|
||||
|
||||
.. _image_push:
|
||||
|
||||
Pushing a container to its repository
|
||||
-------------------------------------
|
||||
Pushing an image to its repository
|
||||
----------------------------------
|
||||
|
||||
In order to push an image to its repository you need to have committed
|
||||
your container to a named image (see above)
|
||||
|
||||
Now you can commit this image to the repository
|
||||
Now you can commit this image to the repository designated by its name
|
||||
or tag.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# for example docker push dhrp/kickassapp
|
||||
sudo docker push <username>/<repo_name>
|
||||
|
||||
.. _using_private_repositories:
|
||||
|
||||
Private Repositories
|
||||
--------------------
|
||||
|
||||
Right now (version 0.5), private repositories are only possible by
|
||||
hosting `your own registry
|
||||
<https://github.com/dotcloud/docker-registry>`_. To push or pull to a
|
||||
repository on your own registry, you must prefix the tag with the
|
||||
address of the registry's host, like this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Tag to create a repository with the full registry location.
|
||||
# The location (e.g. localhost.localdomain:5000) becomes
|
||||
# a permanent part of the repository name
|
||||
sudo docker tag 0u812deadbeef localhost.localdomain:5000/repo_name
|
||||
|
||||
# Push the new repository to its home location on localhost
|
||||
sudo docker push localhost.localdomain:5000/repo_name
|
||||
|
||||
Once a repository has your registry's host name as part of the tag,
|
||||
you can push and pull it like any other repository, but it will
|
||||
**not** be searchable (or indexed at all) in the Central Index, and
|
||||
there will be no user name checking performed. Your registry will
|
||||
function completely independently from the Central Index.
|
||||
|
||||
Vendored
+3
-1
@@ -213,7 +213,9 @@
|
||||
}
|
||||
|
||||
// attached handler on click
|
||||
$('.sidebar > ul > li > a').not(':last').click(function(){
|
||||
// Do not attach to first element or last (intro, faq) so that
|
||||
// first and last link directly instead of accordian
|
||||
$('.sidebar > ul > li > a').not(':last').not(':first').click(function(){
|
||||
|
||||
var index = $.inArray(this.href, openmenus)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user