@@ -44,7 +44,7 @@ clean:

 	-rm -rf $(BUILDDIR)/*

 docs:

-	-rm -rf $(BUILDDIR)/*

+	#-rm -rf $(BUILDDIR)/*

 	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/html

 	@echo

 	@echo "Build finished. The documentation pages are now in $(BUILDDIR)/html."

new file mode 100644

@@ -0,0 +1,16 @@

+:title: docker documentation

+:description: docker documentation

+:keywords:

+

+API's

+=============

+

+This following :

+

+.. toctree::

+  :maxdepth: 3

+

+  registry_api

+  index_search_api

+

+

new file mode 100644

@@ -0,0 +1,43 @@

+:title: Docker Index documentation

+:description: Documentation for docker Index

+:keywords: docker, index, api

+

+

+=======================

+Docker Index Search API

+=======================

+

+Search

+------

+

+.. http:get:: /v1/search

+

+   Search the Index given a search term. It accepts :http:method:`get` only.

+

+   **Example request**:

+

+   .. sourcecode:: http

+

+      GET /v1/search?q=search_term HTTP/1.1

+      Host: example.com

+      Accept: application/json

+

+   **Example response**:

+

+   .. sourcecode:: http

+

+      HTTP/1.1 200 OK

+      Vary: Accept

+      Content-Type: application/json

+

+      {"query":"search_term",

+        "num_results": 2,

+        "results" : [

+           {"name": "dotcloud/base", "description": "A base ubuntu64  image..."},

+           {"name": "base2", "description": "A base ubuntu64  image..."},

+         ]

+       }

+

+   :query q: what you want to search for

+   :statuscode 200: no error

+   :statuscode 500: server error

\ No newline at end of file

new file mode 100644

@@ -0,0 +1,473 @@

+:title: docker Registry documentation

+:description: Documentation for docker Registry and Registry API

+:keywords: docker, registry, api, index

+

+

+===================

+Docker Registry API

+===================

+

+.. contents:: Table of Contents

+

+1. The 3 roles

+===============

+

+1.1 Index

+---------

+

+The Index is responsible for centralizing information about:

+- User accounts

+- Checksums of the images

+- Public namespaces

+

+The Index has different components:

+- Web UI

+- Meta-data store (comments, stars, list public repositories)

+- Authentication service

+- Tokenization

+

+The index is authoritative for those information.

+

+We expect that there will be only one instance of the index, run and managed by dotCloud.

+

+1.2 Registry

+------------

+- It stores the images and the graph for a set of repositories

+- It does not have user accounts data

+- It has no notion of user accounts or authorization

+- It delegates authentication and authorization to the Index Auth service using tokens

+- It supports different storage backends (S3, cloud files, local FS)

+- It doesn’t have a local database

+- It will be open-sourced at some point

+

+We expect that there will be multiple registries out there. To help to grasp the context, here are some examples of registries:

+

+- **sponsor registry**: such a registry is provided by a third-party hosting infrastructure as a convenience for their customers and the docker community as a whole. Its costs are supported by the third party, but the management and operation of the registry are supported by dotCloud. It features read/write access, and delegates authentication and authorization to the Index.

+- **mirror registry**: such a registry is provided by a third-party hosting infrastructure but is targeted at their customers only. Some mechanism (unspecified to date) ensures that public images are pulled from a sponsor registry to the mirror registry, to make sure that the customers of the third-party provider can “docker pull” those images locally.

+- **vendor registry**: such a registry is provided by a software vendor, who wants to distribute docker images. It would be operated and managed by the vendor. Only users authorized by the vendor would be able to get write access. Some images would be public (accessible for anyone), others private (accessible only for authorized users). Authentication and authorization would be delegated to the Index. The goal of vendor registries is to let someone do “docker pull basho/riak1.3” and automatically push from the vendor registry (instead of a sponsor registry); i.e. get all the convenience of a sponsor registry, while retaining control on the asset distribution.

+- **private registry**: such a registry is located behind a firewall, or protected by an additional security layer (HTTP authorization, SSL client-side certificates, IP address authorization...). The registry is operated by a private entity, outside of dotCloud’s control. It can optionally delegate additional authorization to the Index, but it is not mandatory.

+

+.. note::

+

+    Mirror registries and private registries which do not use the Index don’t even need to run the registry code. They can be implemented by any kind of transport implementing HTTP GET and PUT. Read-only registries can be powered by a simple static HTTP server.

+

+.. note::

+

+    The latter implies that while HTTP is the protocol of choice for a registry, multiple schemes are possible (and in some cases, trivial):

+        - HTTP with GET (and PUT for read-write registries);

+        - local mount point;

+        - remote docker addressed through SSH.

+

+The latter would only require two new commands in docker, e.g. “registryget” and “registryput”, wrapping access to the local filesystem (and optionally doing consistency checks). Authentication and authorization are then delegated to SSH (e.g. with public keys).

+

+1.3 Docker

+----------

+

+On top of being a runtime for LXC, Docker is the Registry client. It supports:

+- Push / Pull on the registry

+- Client authentication on the Index

+

+2. Workflow

+===========

+

+2.1 Pull

+--------

+

+.. image:: /static_files/docker_pull_chart.png

+

+1. Contact the Index to know where I should download “samalba/busybox”

+2. Index replies:

+   a. “samalba/busybox” is on Registry A

+   b. here are the checksums for “samalba/busybox” (for all layers)

+   c. token

+3. Contact Registry A to receive the layers for “samalba/busybox” (all of them to the base image). Registry A is authoritative for “samalba/busybox” but keeps a copy of all inherited layers and serve them all from the same location.

+4. registry contacts index to verify if token/user is allowed to download images

+5. Index returns true/false lettings registry know if it should proceed or error out

+6. Get the payload for all layers

+

+It’s possible to run docker pull https://<registry>/repositories/samalba/busybox. In this case, docker bypasses the Index. However the security is not guaranteed (in case Registry A is corrupted) because there won’t be any checksum checks.

+

+Currently registry redirects to s3 urls for downloads, going forward all downloads need to be streamed through the registry. The Registry will then abstract the calls to S3 by a top-level class which implements sub-classes for S3 and local storage.

+

+Token is only returned when the 'X-Docker-Token' header is sent with request.

+

+Basic Auth is required to pull private repos. Basic auth isn't required for pulling public repos, but if one is provided, it needs to be valid and for an active account.

+

+API (pulling repository foo/bar):

+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+1. (Docker -> Index) GET /v1/repositories/foo/bar/images

+    **Headers**:

+        Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

+        X-Docker-Token: true

+    **Action**:

+        (looking up the foo/bar in db and gets images and checksums for that repo (all if no tag is specified, if tag, only checksums for those tags) see part 4.4.1)

+

+2. (Index -> Docker) HTTP 200 OK

+

+    **Headers**:

+        - Authorization: Token signature=123abc,repository=”foo/bar”,access=write

+        - X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]

+    **Body**:

+        Jsonified checksums (see part 4.4.1)

+

+3. (Docker -> Registry) GET /v1/repositories/foo/bar/tags/latest

+    **Headers**:

+        Authorization: Token signature=123abc,repository=”foo/bar”,access=write

+

+4. (Registry -> Index) GET /v1/repositories/foo/bar/images

+

+    **Headers**:

+        Authorization: Token signature=123abc,repository=”foo/bar”,access=read

+

+    **Body**:

+        <ids and checksums in payload>

+

+    **Action**:

+        ( Lookup token see if they have access to pull.)

+

+        If good:

+            HTTP 200 OK

+            Index will invalidate the token

+        If bad:

+            HTTP 401 Unauthorized

+

+5. (Docker -> Registry) GET /v1/images/928374982374/ancestry

+    **Action**:

+        (for each image id returned in the registry, fetch /json + /layer)

+

+.. note::

+

+    If someone makes a second request, then we will always give a new token, never reuse tokens.

+

+2.2 Push

+--------

+

+.. image:: /static_files/docker_push_chart.png

+

+1. Contact the index to allocate the repository name “samalba/busybox” (authentication required with user credentials)

+2. If authentication works and namespace available, “samalba/busybox” is allocated and a temporary token is returned (namespace is marked as initialized in index)

+3. Push the image on the registry (along with the token)

+4. Registry A contacts the Index to verify the token (token must corresponds to the repository name)

+5. Index validates the token. Registry A starts reading the stream pushed by docker and store the repository (with its images)

+6. docker contacts the index to give checksums for upload images

+

+.. note::

+

+    **It’s possible not to use the Index at all!** In this case, a deployed version of the Registry is deployed to store and serve images. Those images are not authentified and the security is not guaranteed.

+

+.. note::

+

+    **Index can be replaced!** For a private Registry deployed, a custom Index can be used to serve and validate token according to different policies.

+

+Docker computes the checksums and submit them to the Index at the end of the push. When a repository name does not have checksums on the Index, it means that the push is in progress (since checksums are submitted at the end).

+

+API (pushing repos foo/bar):

+^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+1. (Docker -> Index) PUT /v1/repositories/foo/bar/

+    **Headers**:

+        Authorization: Basic sdkjfskdjfhsdkjfh==

+        X-Docker-Token: true

+

+    **Action**::

+        - in index, we allocated a new repository, and set to initialized

+

+    **Body**::

+        (The body contains the list of images that are going to be pushed, with empty checksums. The checksums will be set at the end of the push)::

+

+        [{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”}]

+

+2. (Index -> Docker) 200 Created

+    **Headers**:

+        - WWW-Authenticate: Token signature=123abc,repository=”foo/bar”,access=write

+        - X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]

+

+3. (Docker -> Registry) PUT /v1/images/98765432_parent/json

+    **Headers**:

+        Authorization: Token signature=123abc,repository=”foo/bar”,access=write

+

+4. (Registry->Index) GET /v1/repositories/foo/bar/images

+    **Headers**:

+        Authorization: Token signature=123abc,repository=”foo/bar”,access=write

+    **Action**::

+        - Index:

+            will invalidate the token.

+        - Registry:

+            grants a session (if token is approved) and fetches the images id

+

+5. (Docker -> Registry) PUT /v1/images/98765432_parent/json

+    **Headers**::

+        - Authorization: Token signature=123abc,repository=”foo/bar”,access=write

+        - Cookie: (Cookie provided by the Registry)

+

+6. (Docker -> Registry) PUT /v1/images/98765432/json

+    **Headers**:

+        Cookie: (Cookie provided by the Registry)

+

+7. (Docker -> Registry) PUT /v1/images/98765432_parent/layer

+    **Headers**:

+        Cookie: (Cookie provided by the Registry)

+

+8. (Docker -> Registry) PUT /v1/images/98765432/layer

+    **Headers**:

+        X-Docker-Checksum: sha256:436745873465fdjkhdfjkgh

+

+9. (Docker -> Registry) PUT /v1/repositories/foo/bar/tags/latest

+    **Headers**:

+        Cookie: (Cookie provided by the Registry)

+    **Body**:

+        “98765432”

+

+10. (Docker -> Index) PUT /v1/repositories/foo/bar/images

+

+    **Headers**:

+        Authorization: Basic 123oislifjsldfj==

+        X-Docker-Endpoints: registry1.docker.io (no validation on this right now)

+

+    **Body**:

+        (The image, id’s, tags and checksums)

+

+        [{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,

+        “checksum”: “b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}]

+

+    **Return** HTTP 204

+

+.. note::

+

+     If push fails and they need to start again, what happens in the index, there will already be a record for the namespace/name, but it will be initialized. Should we allow it, or mark as name already used? One edge case could be if someone pushes the same thing at the same time with two different shells.

+

+     If it's a retry on the Registry, Docker has a cookie (provided by the registry after token validation). So the Index won’t have to provide a new token.

+

+3. How to use the Registry in standalone mode

+=============================================

+

+The Index has two main purposes (along with its fancy social features):

+

+- Resolve short names (to avoid passing absolute URLs all the time)

+   - username/projectname -> https://registry.docker.io/users/<username>/repositories/<projectname>/

+   - team/projectname -> https://registry.docker.io/team/<team>/repositories/<projectname>/

+- Authenticate a user as a repos owner (for a central referenced repository)

+

+3.1 Without an Index

+--------------------

+Using the Registry without the Index can be useful to store the images on a private network without having to rely on an external entity controlled by dotCloud.

+

+In this case, the registry will be launched in a special mode (--standalone? --no-index?). In this mode, the only thing which changes is that Registry will never contact the Index to verify a token. It will be the Registry owner responsibility to authenticate the user who pushes (or even pulls) an image using any mechanism (HTTP auth, IP based, etc...).

+

+In this scenario, the Registry is responsible for the security in case of data corruption since the checksums are not delivered by a trusted entity.

+

+As hinted previously, a standalone registry can also be implemented by any HTTP server handling GET/PUT requests (or even only GET requests if no write access is necessary).

+

+3.2 With an Index

+-----------------

+

+The Index data needed by the Registry are simple:

+- Serve the checksums

+- Provide and authorize a Token

+

+In the scenario of a Registry running on a private network with the need of centralizing and authorizing, it’s easy to use a custom Index.

+

+The only challenge will be to tell Docker to contact (and trust) this custom Index. Docker will be configurable at some point to use a specific Index, it’ll be the private entity responsibility (basically the organization who uses Docker in a private environment) to maintain the Index and the Docker’s configuration among its consumers.

+

+4. The API

+==========

+

+The first version of the api is available here: https://github.com/jpetazzo/docker/blob/acd51ecea8f5d3c02b00a08176171c59442df8b3/docs/images-repositories-push-pull.md

+

+4.1 Images

+----------

+

+The format returned in the images is not defined here (for layer and json), basically because Registry stores exactly the same kind of information as Docker uses to manage them.

+

+The format of ancestry is a line-separated list of image ids, in age order. I.e. the image’s parent is on the last line, the parent of the parent on the next-to-last line, etc.; if the image has no parent, the file is empty.

+

+GET /v1/images/<image_id>/layer

+PUT /v1/images/<image_id>/layer

+GET /v1/images/<image_id>/json

+PUT /v1/images/<image_id>/json

+GET /v1/images/<image_id>/ancestry

+PUT /v1/images/<image_id>/ancestry

+

+4.2 Users

+---------

+

+4.2.1 Create a user (Index)

+^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+POST /v1/users

+

+**Body**:

+    {"email": "sam@dotcloud.com", "password": "toto42", "username": "foobar"'}

+

+**Validation**:

+    - **username** : min 4 character, max 30 characters, all lowercase no special characters.

+    - **password**: min 5 characters

+

+**Valid**: return HTTP 200

+

+Errors: HTTP 400 (we should create error codes for possible errors)

+- invalid json

+- missing field

+- wrong format (username, password, email, etc)

+- forbidden name

+- name already exists

+

+.. note::

+

+    A user account will be valid only if the email has been validated (a validation link is sent to the email address).

+

+4.2.2 Update a user (Index)

+^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+PUT /v1/users/<username>

+

+**Body**:

+    {"password": "toto"}

+

+.. note::

+

+    We can also update email address, if they do, they will need to reverify their new email address.

+

+4.2.3 Login (Index)

+^^^^^^^^^^^^^^^^^^^

+Does nothing else but asking for a user authentication. Can be used to validate credentials. HTTP Basic Auth for now, maybe change in future.

+

+GET /v1/users

+

+**Return**:

+    - Valid: HTTP 200

+    - Invalid login: HTTP 401

+    - Account inactive: HTTP 403 Account is not Active

+

+4.3 Tags (Registry)

+-------------------

+

+The Registry does not know anything about users. Even though repositories are under usernames, it’s just a namespace for the registry. Allowing us to implement organizations or different namespaces per user later, without modifying the Registry’s API.

+

+4.3.1 Get all tags

+^^^^^^^^^^^^^^^^^^

+

+GET /v1/repositories/<namespace>/<repository_name>/tags

+

+**Return**: HTTP 200

+    {

+    "latest": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f",

+    “0.1.1”:  “b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”

+    }

+

+4.3.2 Read the content of a tag (resolve the image id)

+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+GET /v1/repositories/<namespace>/<repo_name>/tags/<tag>

+

+**Return**:

+    "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f"

+

+4.3.3 Delete a tag (registry)

+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+DELETE /v1/repositories/<namespace>/<repo_name>/tags/<tag>

+

+4.4 Images (Index)

+------------------

+

+For the Index to “resolve” the repository name to a Registry location, it uses the X-Docker-Endpoints header. In other terms, this requests always add a “X-Docker-Endpoints” to indicate the location of the registry which hosts this repository.

+

+4.4.1 Get the images

+^^^^^^^^^^^^^^^^^^^^^

+

+GET /v1/repositories/<namespace>/<repo_name>/images

+

+**Return**: HTTP 200

+    [{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”, “checksum”: “md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}]

+

+

+4.4.2 Add/update the images

+^^^^^^^^^^^^^^^^^^^^^^^^^^^

+

+You always add images, you never remove them.

+

+PUT /v1/repositories/<namespace>/<repo_name>/images

+

+**Body**:

+    [ {“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”, “checksum”: “sha256:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”} ]

+

+**Return** 204

+

+5. Chaining Registries

+======================

+

+It’s possible to chain Registries server for several reasons:

+- Load balancing

+- Delegate the next request to another server

+

+When a Registry is a reference for a repository, it should host the entire images chain in order to avoid breaking the chain during the download.

+

+The Index and Registry use this mechanism to redirect on one or the other.

+

+Example with an image download:

+On every request, a special header can be returned:

+

+X-Docker-Endpoints: server1,server2

+

+On the next request, the client will always pick a server from this list.

+

+6. Authentication & Authorization

+=================================

+

+6.1 On the Index

+-----------------

+

+The Index supports both “Basic” and “Token” challenges. Usually when there is a “401 Unauthorized”, the Index replies this::

+

+    401 Unauthorized

+    WWW-Authenticate: Basic realm="auth required",Token

+

+You have 3 options:

+

+1. Provide user credentials and ask for a token

+

+    **Header**:

+        - Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

+        - X-Docker-Token: true

+

+    In this case, along with the 200 response, you’ll get a new token (if user auth is ok):

+    If authorization isn't correct you get a 401 response.

+    If account isn't active you will get a 403 response.

+

+    **Response**:

+        - 200 OK

+        - X-Docker-Token: Token signature=123abc,repository=”foo/bar”,access=read

+

+2. Provide user credentials only

+

+    **Header**:

+        Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

+

+3. Provide Token

+

+    **Header**:

+        Authorization: Token signature=123abc,repository=”foo/bar”,access=read

+

+6.2 On the Registry

+-------------------

+

+The Registry only supports the Token challenge::

+

+    401 Unauthorized

+    WWW-Authenticate: Token

+

+The only way is to provide a token on “401 Unauthorized” responses::

+

+    Authorization: Token signature=123abc,repository=”foo/bar”,access=read

+

+Usually, the Registry provides a Cookie when a Token verification succeeded. Every time the Registry passes a Cookie, you have to pass it back the same cookie.::

+

+    200 OK

+    Set-Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=&timestamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="; Path=/; HttpOnly

+

+Next request::

+

+    GET /(...)

+    Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=&timestamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="

deleted file mode 100644

@@ -1,130 +0,0 @@

-==============

-Docker Builder

-==============

-

-.. contents:: Table of Contents

-

-1. Format

-=========

-

-The Docker builder format is quite simple:

-

-    ``instruction arguments``

-

-The first instruction must be `FROM`

-

-All instruction are to be placed in a file named `Dockerfile`

-

-In order to place comments within a Dockerfile, simply prefix the line with "`#`"

-

-2. Instructions

-===============

-

-Docker builder comes with a set of instructions:

-

-1. FROM: Set from what image to build

-2. RUN: Execute a command

-3. INSERT: Insert a remote file (http) into the image

-

-2.1 FROM

-    ``FROM <image>``

-

-The `FROM` instruction must be the first one in order for Builder to know from where to run commands.

-

-`FROM` can also be used in order to build multiple images within a single Dockerfile

-

-2.2 MAINTAINER

-    ``MAINTAINER <name>``

-

-The `MAINTAINER` instruction allow you to set the Author field of the generated images.

-This instruction is never automatically reset.

-

-2.3 RUN

-    ``RUN <command>``

-

-The `RUN` instruction is the main one, it allows you to execute any commands on the `FROM` image and to save the results.

-You can use as many `RUN` as you want within a Dockerfile, the commands will be executed on the result of the previous command.

-

-

-2.4 CMD

-    ``CMD <command>``

-

-The `CMD` instruction sets the command to be executed when running the image.

-It is equivalent to do `docker commit -run '{"Cmd": <command>}'` outside the builder.

-

-.. note::

-    Do not confuse `RUN` with `CMD`. `RUN` actually run a command and save the result, `CMD` does not execute anything.

-

-2.5 EXPOSE

-    ``EXPOSE <port> [<port>...]``

-

-The `EXPOSE` instruction sets ports to be publicly exposed when running the image.

-This is equivalent to do `docker commit -run '{"PortSpecs": ["<port>", "<port2>"]}'` outside the builder.

-

-2.6 ENV

-    ``ENV <key> <value>``

-

-The `ENV` instruction set as environment variable `<key>` with the value `<value>`. This value will be passed to all future ``RUN`` instructions.

-

-.. note::

-    The environment variables are local to the Dockerfile, they will not be set as autorun.

-

-2.7 INSERT

-

-    ``INSERT <file url> <path>``

-

-The `INSERT` instruction will download the file at the given url and place it within the image at the given path.

-

-.. note::

-    The path must include the file name.

-

-

-3. Dockerfile Examples

-======================

-

-::

-

-    # Nginx

-    #

-    # VERSION               0.0.1

-    # DOCKER-VERSION        0.2

-    

-    from      ubuntu

-    maintainer Guillaume J. Charmes "guillaume@dotcloud.com"

-    

-    # make sure the package repository is up to date

-    run echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list

-    run apt-get update

-    

-    run apt-get install -y inotify-tools nginx apache2 openssh-server

-    insert https://raw.github.com/creack/docker-vps/master/nginx-wrapper.sh /usr/sbin/nginx-wrapper

-

-::

-

-    # Firefox over VNC

-    #

-    # VERSION               0.3

-    # DOCKER-VERSION        0.2

-    

-    from ubuntu

-    # make sure the package repository is up to date

-    run echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list

-    run apt-get update

-    

-    # Install vnc, xvfb in order to create a 'fake' display and firefox

-    run apt-get install -y x11vnc xvfb firefox

-    run mkdir /.vnc

-    # Setup a password

-    run x11vnc -storepasswd 1234 ~/.vnc/passwd

-    # Autostart firefox (might not be the best way to do it, but it does the trick)

-    run bash -c 'echo "firefox" >> /.bashrc'

-    

-    expose 5900

-    cmd    ["x11vnc", "-forever", "-usepw", "-create"]

deleted file mode 100644

@@ -1,14 +0,0 @@

-:title: docker documentation

-:description: Documentation for docker builder

-:keywords: docker, builder, dockerfile

-

-

-Builder

-=======

-

-Contents:

-

-.. toctree::

-  :maxdepth: 2

-

-  basics

deleted file mode 100644

@@ -1,101 +0,0 @@

-:title: Base commands

-:description: Common usage and commands

-:keywords: Examples, Usage

-

-

-The basics

-=============

-

-Starting Docker

-

-If you have used one of the quick install paths', Docker may have been installed with upstart, Ubuntu's

-system for starting processes at boot time. You should be able to run ``docker help`` and get output.

-

-If you get ``docker: command not found`` or something like ``/var/lib/docker/repositories: permission denied``

-you will need to specify the path to it and manually start it.

-

-.. code-block:: bash

-

-    # Run docker in daemon mode

-    sudo <path to>/docker -d &

-

-

-Running an interactive shell

-

-.. code-block:: bash

-

-  # Download a base image

-  docker pull base

-

-  # Run an interactive shell in the base image,

-  # allocate a tty, attach stdin and stdout

-  docker run -i -t base /bin/bash

-

-

-Starting a long-running worker process

-

-.. code-block:: bash

-

-  # Start a very useful long-running process

-  JOB=$(docker run -d base /bin/sh -c "while true; do echo Hello world; sleep 1; done")

-

-  # Collect the output of the job so far

-  docker logs $JOB

-

-  # Kill the job

-  docker kill $JOB

-

-

-Listing all running containers

-

-.. code-block:: bash

-

-  docker ps

-

-Expose a service on a TCP port

-

-.. code-block:: bash

-

-  # Expose port 4444 of this container, and tell netcat to listen on it

-  JOB=$(docker run -d -p 4444 base /bin/nc -l -p 4444)

-

-  # Which public port is NATed to my container?

-  PORT=$(docker port $JOB 4444)

-

-  # Connect to the public port via the host's public address

-  # Please note that because of how routing works connecting to localhost or 127.0.0.1 $PORT will not work.

-  IP=$(ifconfig eth0 | perl -n -e 'if (m/inet addr:([\d\.]+)/g) { print $1 }')

-  echo hello world | nc $IP $PORT

-

-  # Verify that the network connection worked

-  echo "Daemon received: $(docker logs $JOB)"

-

-

-Committing (saving) an image

-

-Save your containers state to a container image, so the state can be re-used.

-

-When you commit your container only the differences between the image the container was created from

-and the current state of the container will be stored (as a diff). See which images you already have

-using ``docker images``

-

-.. code-block:: bash

-

-    # Commit your container to a new named image

-    docker commit <container_id> <some_name>

-

-    # List your containers

-    docker images

-

-You now have a image state from which you can create new instances.

-

-

-

-Read more about :ref:`working_with_the_repository` or continue to the complete :ref:`cli`

-

@@ -4,7 +4,7 @@

 .. _cli:

-Command Line Interface

+Overview

 ======================

 Docker Usage

@@ -24,7 +24,7 @@ Available Commands

 ~~~~~~~~~~~~~~~~~~

 .. toctree::

-   :maxdepth: 1

+   :maxdepth: 2

    command/attach

    command/build

@@ -11,6 +11,31 @@ Contents:

 .. toctree::

   :maxdepth: 3

-  basics

-  workingwithrepository

   cli

+  command/attach

+  command/build

+  command/commit

+  command/diff

+  command/export

+  command/history

+  command/images

+  command/import

+  command/info

+  command/inspect

+  command/kill

+  command/login

+  command/logs

+  command/port

+  command/ps

+  command/pull

+  command/push

+  command/restart

+  command/rm

+  command/rmi

+  command/run

+  command/search

+  command/start

+  command/stop

+  command/tag

+  command/version

+  command/wait

\ No newline at end of file

deleted file mode 100644

@@ -1,42 +0,0 @@

-.. _working_with_the_repository:

-

-Working with the repository

-============================

-

-Connecting to the repository

-

-You create a user on the central docker repository by running

-

-.. code-block:: bash

-

-    docker login

-

-

-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.

-

-

-Committing a container to a named image

-

-In order to commit to the repository it is required to have committed your container to an image with your namespace.

-

-.. code-block:: bash