@@ -80,7 +80,7 @@ sudo mkdir -m 755 dev

 # effectively: febootstrap-minimize --keep-zoneinfo --keep-rpmdb --keep-services "$target"

 #  locales

 sudo rm -rf usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive}

-#  docs

+#  docs and man pages

 sudo rm -rf usr/share/{man,doc,info,gnome/help}

 #  cracklib

 sudo rm -rf usr/share/cracklib

@@ -10,7 +10,7 @@ shift

 	# effectively: febootstrap-minimize --keep-zoneinfo --keep-rpmdb --keep-services "$target"

 	#  locales

 	rm -rf usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive}

-	#  docs

+	#  docs and man pages

 	rm -rf usr/share/{man,doc,info,gnome/help}

 	#  cracklib

 	rm -rf usr/share/cracklib

@@ -280,24 +280,11 @@ aws cloudfront  create-invalidation --profile docs.docker.com --distribution-id

 aws cloudfront  create-invalidation --profile docs.docker.com --distribution-id $DISTRIBUTION_ID --invalidation-batch '{"Paths":{"Quantity":1, "Items":["/v1.1/reference/api/docker_io_oauth_api/"]},"CallerReference":"6Mar2015sventest1"}'

 ```

-### Generate the man pages for Mac OSX

+### Generate the man pages 

-When using Docker on Mac OSX the man pages will be missing by default. You can manually generate them by following these steps:

+For information on generating man pages (short for manual page), see [the man

+page directory](https://github.com/docker/docker/tree/master/docker) in this

+project.

-1. Checkout the docker source. You must clone into your `/Users` directory because Boot2Docker can only share this path

-   with the docker containers.

-        $ git clone https://github.com/docker/docker.git

-		

-2. Build the docker image.

-   

-        $ cd docker/docs/man

-        $ docker build -t docker/md2man .

-3. Build the man pages.

-

-        $ docker run -v /Users/<path-to-git-dir>/docker/docs/man:/docs:rw -w /docs -i docker/md2man /docs/md2man-all.sh

-

-4. Copy the generated man pages to `/usr/share/man`

-

-        $ cp -R man* /usr/share/man/

deleted file mode 100644

@@ -1,7 +0,0 @@

-FROM golang:1.3

-RUN mkdir -p /go/src/github.com/cpuguy83

-RUN mkdir -p /go/src/github.com/cpuguy83 \

-    && git clone -b v1 https://github.com/cpuguy83/go-md2man.git /go/src/github.com/cpuguy83/go-md2man \

-    && cd /go/src/github.com/cpuguy83/go-md2man \

-    && go get -v ./...

-CMD ["/go/bin/go-md2man", "--help"]

deleted file mode 100644

@@ -1,329 +0,0 @@

-% DOCKERFILE(5) Docker User Manuals

-% Zac Dover

-% May 2014

-# NAME

-

-Dockerfile - automate the steps of creating a Docker image

-

-# INTRODUCTION

-

-The **Dockerfile** is a configuration file that automates the steps of creating

-a Docker image. It is similar to a Makefile. Docker reads instructions from the

-**Dockerfile** to automate the steps otherwise performed manually to create an

-image. To build an image, create a file called **Dockerfile**.

-

-The **Dockerfile** describes the steps taken to assemble the image. When the

-**Dockerfile** has been created, call the `docker build` command, using the

-path of directory that contains **Dockerfile** as the argument.

-

-# SYNOPSIS

-

-INSTRUCTION arguments

-

-For example:

-

-  FROM image

-

-# DESCRIPTION

-

-A Dockerfile is a file that automates the steps of creating a Docker image. 

-A Dockerfile is similar to a Makefile.

-

-# USAGE

-

-  docker build .

-

-  -- Runs the steps and commits them, building a final image.

-  The path to the source repository defines where to find the context of the

-  build. The build is run by the Docker daemon, not the CLI. The whole

-  context must be transferred to the daemon. The Docker CLI reports

-  `"Sending build context to Docker daemon"` when the context is sent to the

-  daemon.

-

-  ```

-  docker build -t repository/tag .

-  ```

-

-  -- specifies a repository and tag at which to save the new image if the build

-  succeeds. The Docker daemon runs the steps one-by-one, committing the result

-  to a new image if necessary, before finally outputting the ID of the new

-  image. The Docker daemon automatically cleans up the context it is given.

-

-  Docker re-uses intermediate images whenever possible. This significantly

-  accelerates the *docker build* process.

-

-# FORMAT

-

-  `FROM image`

-

-  `FROM image:tag`

-

-  -- The **FROM** instruction sets the base image for subsequent instructions. A

-  valid Dockerfile must have **FROM** as its first instruction. The image can be any

-  valid image. It is easy to start by pulling an image from the public

-  repositories.

-

-  -- **FROM** must be the first non-comment instruction in Dockerfile.

-

-  -- **FROM** may appear multiple times within a single Dockerfile in order to create

-  multiple images. Make a note of the last image ID output by the commit before

-  each new **FROM** command.

-

-  -- If no tag is given to the **FROM** instruction, Docker applies the 

-  `latest` tag. If the used tag does not exist, an error is returned.

-

-**MAINTAINER**

-  -- **MAINTAINER** sets the Author field for the generated images.

-

-**RUN**

-  -- **RUN** has two forms:

-

-  ```

-  # the command is run in a shell - /bin/sh -c

-  RUN <command>

-

-  # Executable form

-  RUN ["executable", "param1", "param2"]

-  ```

-

-

-  -- The **RUN** instruction executes any commands in a new layer on top of the current

-  image and commits the results. The committed image is used for the next step in

-  Dockerfile.

-

-  -- Layering **RUN** instructions and generating commits conforms to the core

-  concepts of Docker where commits are cheap and containers can be created from

-  any point in the history of an image. This is similar to source control.  The

-  exec form makes it possible to avoid shell string munging. The exec form makes

-  it possible to **RUN** commands using a base image that does not contain `/bin/sh`.

-

-  Note that the exec form is parsed as a JSON array, which means that you must

-  use double-quotes (") around words not single-quotes (').

-

-**CMD**

-  -- **CMD** has three forms:

-

-  ```

-  # Executable form

-  CMD ["executable", "param1", "param2"]`

-

-  # Provide default arguments to ENTRYPOINT

-  CMD ["param1", "param2"]`

-

-  # the command is run in a shell - /bin/sh -c

-  CMD command param1 param2

-  ```

-

-  -- There can be only one **CMD** in a Dockerfile. If more than one **CMD** is listed, only

-  the last **CMD** takes effect.

-  The main purpose of a **CMD** is to provide defaults for an executing container.

-  These defaults may include an executable, or they can omit the executable. If

-  they omit the executable, an **ENTRYPOINT** must be specified.

-  When used in the shell or exec formats, the **CMD** instruction sets the command to

-  be executed when running the image.

-  If you use the shell form of the **CMD**, the `<command>` executes in `/bin/sh -c`:

-

-  Note that the exec form is parsed as a JSON array, which means that you must

-  use double-quotes (") around words not single-quotes (').

-

-  ```

-  FROM ubuntu

-  CMD echo "This is a test." | wc -

-  ```

-

-  -- If you run **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 form of **CMD**. All additional parameters must be individually expressed

-  as strings in the array:

-

-  ```

-  FROM ubuntu

-  CMD ["/usr/bin/wc","--help"]

-  ```

-

-  -- To make the container run the same executable every time, use **ENTRYPOINT** in

-  combination with **CMD**. 

-  If the user specifies arguments to `docker run`, the specified commands

-  override the default in **CMD**.

-  Do not confuse **RUN** with **CMD**. **RUN** runs a command and commits the result.

-  **CMD** executes nothing at build time, but specifies the intended command for

-  the image.

-

-**LABEL**

-  -- `LABEL <key>[=<value>] [<key>[=<value>] ...]`

-  The **LABEL** instruction adds metadata to an image. A **LABEL** is a

-  key-value pair. To include spaces within a **LABEL** value, use quotes and

-  backslashes as you would in command-line parsing.

-

-  ```

-  LABEL "com.example.vendor"="ACME Incorporated"

-  ```

-

-  An image can have more than one label. To specify multiple labels, separate

-  each key-value pair by a space. 

-  

-  Labels are additive including `LABEL`s in `FROM` images. As the system

-  encounters and then applies a new label, new `key`s override any previous

-  labels with identical keys.

-

-  To display an image's labels, use the `docker inspect` command.

-

-**EXPOSE**

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

-  The **EXPOSE** instruction informs Docker that the container listens on the

-  specified network ports at runtime. Docker uses this information to

-  interconnect containers using links, and to set up port redirection on the host

-  system.

-

-**ENV**

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

-  The **ENV** instruction sets the environment variable <key> to

-  the value `<value>`. This value is passed to all future 

-  RUN, **ENTRYPOINT**, and **CMD** instructions. This is

-  functionally equivalent to prefixing the command with `<key>=<value>`.  The

-  environment variables that are set with **ENV** persist when a container is run

-  from the resulting image. Use `docker inspect` to inspect these values, and

-  change them using `docker run --env <key>=<value>`.

-

-  Note that setting "`ENV DEBIAN_FRONTEND noninteractive`" may cause

-  unintended consequences, because it will persist when the container is run

-  interactively, as with the following command: `docker run -t -i image bash`

-

-**ADD**

-  -- **ADD** has two forms:

-

-  ```

-  ADD <src> <dest>

-

-  # Required for paths with whitespace

-  ADD ["<src>",... "<dest>"]

-  ```

-

-  The **ADD** instruction copies new files, directories

-  or remote file URLs to the filesystem of the container at path `<dest>`.

-  Multiple `<src>` resources may be specified but if they are files or directories

-  then they must be relative to the source directory that is being built

-  (the context of the build). The `<dest>` is the absolute path, or path relative

-  to **WORKDIR**, into which the source is copied inside the target container.

-  All new files and directories are created with mode 0755 and with the uid 

-  and gid of **0**.

-

-**COPY**

-  -- **COPY** has two forms:

-

-  ```

-  COPY <src> <dest>

-

-  # Required for paths with whitespace

-  COPY ["<src>",... "<dest>"]

-  ```

-

-  The **COPY** instruction copies new files from `<src>` and

-  adds them to the filesystem of the container at path <dest>. The `<src>` must be

-  the path to a file or directory relative to the source directory that is

-  being built (the context of the build) or a remote file URL. The `<dest>` is an

-  absolute path, or a path relative to **WORKDIR**, into which the source will

-  be copied inside the target container. All new files and directories are

-  created with mode **0755** and with the uid and gid of **0**.

-

-**ENTRYPOINT**

-  -- **ENTRYPOINT** has two forms:

-

-  ```

-  # executable form

-  ENTRYPOINT ["executable", "param1", "param2"]`

-

-  # run command in a shell - /bin/sh -c

-  ENTRYPOINT command param1 param2

-  ```

-

-  -- An **ENTRYPOINT** helps you configure a

-  container that can be run as an executable. When you specify an **ENTRYPOINT**,

-  the whole container runs as if it was only that executable.  The **ENTRYPOINT**

-  instruction adds an entry command that is not overwritten when arguments are

-  passed to docker run. This is different from the behavior of CMD. This allows

-  arguments to be passed to the entrypoint, for instance `docker run <image> -d`

-  passes the -d argument to the **ENTRYPOINT**.  Specify parameters either in the

-  **ENTRYPOINT** JSON array (as in the preferred exec form above), or by using a **CMD**

-  statement.  Parameters in the **ENTRYPOINT** are not overwritten by the docker run

-  arguments.  Parameters specifies via **CMD** are overwritten by docker run

-  arguments.  Specify a plain string for the **ENTRYPOINT**, and it will execute in

-  `/bin/sh -c`, like a **CMD** instruction:

-

-  ```

-  FROM ubuntu

-  ENTRYPOINT wc -l -

-  ```

-

-  This means that the Dockerfile's image always takes stdin as input (that's

-  what "-" means), and prints the number of lines (that's what "-l" means). To

-  make this optional but default, use a **CMD**:

-

-  ```

-  FROM ubuntu

-  CMD ["-l", "-"]

-  ENTRYPOINT ["/usr/bin/wc"]

-  ```

-

-**VOLUME**

-  -- `VOLUME ["/data"]`

-  The **VOLUME** instruction creates a mount point with the specified name and marks

-  it as holding externally-mounted volumes from the native host or from other

-  containers.

-

-**USER**

-  -- `USER daemon`

-  Sets the username or UID used for running subsequent commands.

-

-  The **USER** instruction can optionally be used to set the group or GID. The

-  followings examples are all valid:

-  USER [user | user:group | uid | uid:gid | user:gid | uid:group ]

-

-  Until the **USER** instruction is set, instructions will be run as root. The USER

-  instruction can be used any number of times in a Dockerfile, and will only affect

-  subsequent commands.

-

-**WORKDIR**

-  -- `WORKDIR /path/to/workdir`

-  The **WORKDIR** instruction sets the working directory for the **RUN**, **CMD**,

-  **ENTRYPOINT**, **COPY** and **ADD** Dockerfile commands that follow it. It can

-  be used multiple times in a single Dockerfile. Relative paths are defined

-  relative to the path of the previous **WORKDIR** instruction. For example:

-

-  ```

-  WORKDIR /a

-  WORKDIR b

-  WORKDIR c

-  RUN pwd

-  ```

-

-  In the above example, the output of the **pwd** command is **a/b/c**.

-

-**ONBUILD**

-  -- `ONBUILD [INSTRUCTION]`

-  The **ONBUILD** instruction adds a trigger instruction to an image. The

-  trigger is executed at a later time, when the image is used as the base for

-  another build. Docker executes the trigger in the context of the downstream

-  build, as if the trigger existed immediately after the **FROM** instruction in

-  the downstream Dockerfile.

-

-  You can register any build instruction as a trigger. A trigger is useful if

-  you are defining an image to use as a base for building other images. For

-  example, if you are defining an application build environment or a daemon that

-  is customized with a user-specific configuration.  

-  

-  Consider an image intended as a reusable python application builder. It must

-  add application source code to a particular directory, and might need a build

-  script called after that. You can't just call **ADD** and **RUN** now, because

-  you don't yet have access to the application source code, and it is different

-  for each application build.

-

-  -- Providing application developers with a boilerplate Dockerfile to copy-paste

-  into their application is inefficient, error-prone, and

-  difficult to update because it mixes with application-specific code.

-  The solution is to use **ONBUILD** to register instructions in advance, to

-  run later, during the next build stage.

-

-# HISTORY

-*May 2014, Compiled by Zac Dover (zdover at redhat dot com) based on docker.com Dockerfile documentation.

-*Feb 2015, updated by Brian Goff (cpuguy83@gmail.com) for readability

deleted file mode 100644

@@ -1,33 +0,0 @@

-Docker Documentation

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

-

-This directory contains the Docker user manual in the Markdown format.

-Do *not* edit the man pages in the man1 directory. Instead, amend the

-Markdown (*.md) files.

-

-# Generating man pages from the Markdown files

-

-The recommended approach for generating the man pages is via a Docker

-container using the supplied `Dockerfile` to create an image with the correct

-environment. This uses `go-md2man`, a pure Go Markdown to man page generator.

-

-## Building the md2man image

-

-There is a `Dockerfile` provided in the `docker/docs/man` directory.

-

-Using this `Dockerfile`, create a Docker image tagged `docker/md2man`:

-

-    docker build -t docker/md2man .

-

-## Utilizing the image

-

-Once the image is built, run a container using the image with *volumes*:

-

-    docker run -v /<path-to-git-dir>/docker/docs/man:/docs:rw \

-    -w /docs -i docker/md2man /docs/md2man-all.sh

-

-The `md2man` Docker container will process the Markdown files and generate

-the man pages inside the `docker/docs/man/man1` directory using

-Docker volumes. For more information on Docker volumes see the man page for

-`docker run` and also look at the article [Sharing Directories via Volumes]

-(https://docs.docker.com/use/working_with_volumes/).

deleted file mode 100644

@@ -1,70 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% Docker Community

-% JUNE 2014

-# NAME

-docker-attach - Attach to a running container

-

-# SYNOPSIS

-**docker attach**

-[**--help**]/

-[**--no-stdin**[=*false*]]

-[**--sig-proxy**[=*true*]]

-CONTAINER

-

-# DESCRIPTION

-The **docker attach** command allows you to attach to a running container using

-the container's ID or name, either to view its ongoing output or to control it

-interactively.  You can attach to the same contained process multiple times

-simultaneously, screen sharing style, or quickly view the progress of your

-daemonized process.

-

-You can detach from the container (and leave it running) with `CTRL-p CTRL-q`

-(for a quiet exit) or `CTRL-c` which will send a `SIGKILL` to the container.

-When you are attached to a container, and exit its main process, the process's

-exit code will be returned to the client.

-

-It is forbidden to redirect the standard input of a `docker attach` command while

-attaching to a tty-enabled container (i.e.: launched with `-t`).

-

-# OPTIONS

-**--help**

-  Print usage statement

-

-**--no-stdin**=*true*|*false*

-   Do not attach STDIN. The default is *false*.

-

-**--sig-proxy**=*true*|*false*

-   Proxy all received signals to the process (non-TTY mode only). SIGCHLD, SIGKILL, and SIGSTOP are not proxied. The default is *true*.

-

-# EXAMPLES

-

-## Attaching to a container

-

-In this example the top command is run inside a container, from an image called

-fedora, in detached mode. The ID from the container is passed into the **docker

-attach** command:

-

-    # ID=$(sudo docker run -d fedora /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

-

-# HISTORY

-April 2014, Originally compiled by William Henry (whenry at redhat dot com)

-based on docker.com source material and internal work.

-June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

deleted file mode 100644

@@ -1,215 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% Docker Community

-% JUNE 2014

-# NAME

-docker-build - Build a new image from the source code at PATH

-

-# SYNOPSIS

-**docker build**

-[**--help**]

-[**-f**|**--file**[=*PATH/Dockerfile*]]

-[**--force-rm**[=*false*]]

-[**--no-cache**[=*false*]]

-[**--pull**[=*false*]]

-[**-q**|**--quiet**[=*false*]]

-[**--rm**[=*true*]]

-[**-t**|**--tag**[=*TAG*]]

-[**-m**|**--memory**[=*MEMORY*]]

-[**--memory-swap**[=*MEMORY-SWAP*]]

-[**-c**|**--cpu-shares**[=*0*]]

-[**--cpu-period**[=*0*]]

-[**--cpu-quota**[=*0*]]

-[**--cpuset-cpus**[=*CPUSET-CPUS*]]

-[**--cpuset-mems**[=*CPUSET-MEMS*]]

-[**--cgroup-parent**[=*CGROUP-PARENT*]]

-

-PATH | URL | -

-

-# DESCRIPTION

-This will read the Dockerfile from the directory specified in **PATH**.

-It also sends any other files and directories found in the current

-directory to the Docker daemon. The contents of this directory would

-be used by **ADD** commands found within the Dockerfile.

-

-Warning, this will send a lot of data to the Docker daemon depending

-on the contents of the current directory. The build is run by the Docker 

-daemon, not by the CLI, so the whole context must be transferred to the daemon. 

-The Docker CLI reports "Sending build context to Docker daemon" when the context is sent to 

-the daemon.

-

-When a single Dockerfile is given as the URL, then no context is set.

-When a Git repository is set as the **URL**, the repository is used

-as context.

-

-# OPTIONS

-**-f**, **--file**=*PATH/Dockerfile*

-   Path to the Dockerfile to use. If the path is a relative path then it must be relative to the current directory. The file must be within the build context. The default is *Dockerfile*.

-

-**--force-rm**=*true*|*false*

-   Always remove intermediate containers, even after unsuccessful builds. The default is *false*.

-

-**--no-cache**=*true*|*false*

-   Do not use cache when building the image. The default is *false*.

-

-**--help**

-  Print usage statement

-

-**--pull**=*true*|*false*

-   Always attempt to pull a newer version of the image. The default is *false*.

-

-**-q**, **--quiet**=*true*|*false*

-   Suppress the verbose output generated by the containers. The default is *false*.

-

-**--rm**=*true*|*false*

-   Remove intermediate containers after a successful build. The default is *true*.

-

-**-t**, **--tag**=""

-   Repository name (and optionally a tag) to be applied to the resulting image in case of success

-

-**-m**, **--memory**=*MEMORY*

-  Memory limit

-

-**--memory-swap**=*MEMORY-SWAP*

-  Total memory (memory + swap), '-1' to disable swap.

-

-**-c**, **--cpu-shares**=*0*

-  CPU shares (relative weight).

-

-  By default, all containers get the same proportion of CPU cycles. You can

-  change this proportion by adjusting the container's CPU share weighting

-  relative to the weighting of all other running containers.

-

-  To modify the proportion from the default of 1024, use the **-c** or

-  **--cpu-shares** flag to set the weighting to 2 or higher.

-

-  The proportion is only applied when CPU-intensive processes are running.

-  When tasks in one container are idle, the other containers can use the

-  left-over CPU time. The actual amount of CPU time used varies depending on

-  the number of containers running on the system.

-

-  For example, consider three containers, one has a cpu-share of 1024 and

-  two others have a cpu-share setting of 512. When processes in all three

-  containers attempt to use 100% of CPU, the first container would receive

-  50% of the total CPU time. If you add a fourth container with a cpu-share

-  of 1024, the first container only gets 33% of the CPU. The remaining containers

-  receive 16.5%, 16.5% and 33% of the CPU.

-

-  On a multi-core system, the shares of CPU time are distributed across the CPU

-  cores. Even if a container is limited to less than 100% of CPU time, it can

-  use 100% of each individual CPU core.

-

-  For example, consider a system with more than three cores. If you start one

-  container **{C0}** with **-c=512** running one process, and another container

-  **{C1}** with **-c=1024** running two processes, this can result in the following

-  division of CPU shares:

-

-      PID    container    CPU    CPU share

-      100    {C0}         0      100% of CPU0

-      101    {C1}         1      100% of CPU1

-      102    {C1}         2      100% of CPU2

-

-**--cpu-period**=*0*

-  Limit the CPU CFS (Completely Fair Scheduler) period.

-

-  Limit the container's CPU usage. This flag causes the kernel to restrict the

-  container's CPU usage to the period you specify.

-

-**--cpu-quota**=*0*

-  Limit the CPU CFS (Completely Fair Scheduler) quota. 

-

-  By default, containers run with the full CPU resource. This flag causes the

-kernel to restrict the container's CPU usage to the quota you specify.

-

-**--cpuset-cpus**=*CPUSET-CPUS*

-  CPUs in which to allow execution (0-3, 0,1).

-

-**--cpuset-mems**=*CPUSET-MEMS*

-  Memory nodes (MEMs) in which to allow execution (-1-3, 0,1). Only effective on

-  NUMA systems.

-

-  For example, if you have four memory nodes on your system (0-3), use `--cpuset-mems=0,1`

-to ensure the processes in your Docker container only use memory from the first

-two memory nodes.

-

-**--cgroup-parent**=*CGROUP-PARENT*

-  Path to `cgroups` under which the container's `cgroup` are created.

-

-  If the path is not absolute, the path is considered relative to the `cgroups` path of the init process.

-Cgroups are created if they do not already exist.

-

-# EXAMPLES

-

-## Building an image using a Dockerfile located inside the current directory

-

-Docker images can be built using the build command and a Dockerfile:

-

-    docker build .

-

-During the build process Docker creates intermediate images. In order to

-keep them, you must explicitly set `--rm=false`.

-

-    docker build --rm=false .

-

-A good practice is to make a sub-directory with a related name and create

-the Dockerfile in that directory. For example, a directory called mongo may

-contain a Dockerfile to create a Docker MongoDB image. Likewise, another

-directory called httpd may be used to store Dockerfiles for Apache web

-server images.

-

-It is also a good practice to add the files required for the image to the

-sub-directory. These files will then be specified with the `COPY` or `ADD`

-instructions in the `Dockerfile`.

-

-Note: If you include a tar file (a good practice), then Docker will

-automatically extract the contents of the tar file specified within the `ADD`

-instruction into the specified target.

-

-## Building an image and naming that image

-

-A good practice is to give a name to the image you are building. There are

-no hard rules here but it is best to give the names consideration. 

-

-The **-t**/**--tag** flag is used to rename an image. Here are some examples:

-

-Though it is not a good practice, image names can be arbitrary:

-

-    docker build -t myimage .

-

-A better approach is to provide a fully qualified and meaningful repository,

-name, and tag (where the tag in this context means the qualifier after 

-the ":"). In this example we build a JBoss image for the Fedora repository 

-and give it the version 1.0:

-

-    docker build -t fedora/jboss:1.0

-

-The next example is for the "whenry" user repository and uses Fedora and

-JBoss and gives it the version 2.1 :

-

-    docker build -t whenry/fedora-jboss:V2.1

-

-If you do not provide a version tag then Docker will assign `latest`:

-

-    docker build -t whenry/fedora-jboss

-

-When you list the images, the image above will have the tag `latest`.

-

-So renaming an image is arbitrary but consideration should be given to 

-a useful convention that makes sense for consumers and should also take

-into account Docker community conventions.

-

-

-## Building an image using a URL

-

-This will clone the specified Github repository from the URL and use it

-as context. The Dockerfile at the root of the repository is used as

-Dockerfile. This only works if the Github repository is a dedicated

-repository.

-

-    docker build github.com/scollier/Fedora-Dockerfiles/tree/master/apache

-

-Note: You can set an arbitrary Git repository via the `git://` schema.

-

-# HISTORY

-March 2014, Originally compiled by William Henry (whenry at redhat dot com)

-based on docker.com source material and internal work.

-June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

deleted file mode 100644

@@ -1,59 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% Docker Community

-% JUNE 2014

-# NAME

-docker-commit - Create a new image from a container's changes

-

-# SYNOPSIS

-**docker commit**

-[**-a**|**--author**[=*AUTHOR*]]

-[**--help**]

-[**-c**|**--change**[= []**]]

-[**-m**|**--message**[=*MESSAGE*]]

-[**-p**|**--pause**[=*true*]]

-CONTAINER [REPOSITORY[:TAG]]

-

-# DESCRIPTION

-Using an existing container's name or ID you can create a new image.

-

-# OPTIONS

-**-a**, **--author**=""

-   Author (e.g., "John Hannibal Smith <hannibal@a-team.com>")

-

-**-c** , **--change**=[]

-   Apply specified Dockerfile instructions while committing the image

-   Supported Dockerfile instructions: `CMD`|`ENTRYPOINT`|`ENV`|`EXPOSE`|`ONBUILD`|`USER`|`VOLUME`|`WORKDIR`

-

-**--help**

-  Print usage statement

-

-**-m**, **--message**=""

-   Commit message

-

-**-p**, **--pause**=*true*|*false*

-   Pause container during commit. The default is *true*.

-

-# EXAMPLES

-

-## Creating a new image from an existing container

-An existing Fedora based container has had Apache installed while running

-in interactive mode with the bash shell. Apache is also running. To

-create a new image run `docker ps` to find the container's ID and then run:

-

-    # docker commit -m="Added Apache to Fedora base image" \

-      -a="A D Ministrator" 98bd7fc99854 fedora/fedora_httpd:20

-

-## Apply specified Dockerfile instructions while committing the image

-If an existing container was created without the DEBUG environment

-variable set to "true", you can create a new image based on that

-container by first getting the container's ID with `docker ps` and

-then running:

-

-    # docker commit -c="ENV DEBUG true" 98bd7fc99854 debug-image

-

-# HISTORY

-April 2014, Originally compiled by William Henry (whenry at redhat dot com)

-based on docker.com source material and in

-June 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

-July 2014, updated by Sven Dowideit <SvenDowideit@home.org.au>

-Oct 2014, updated by Daniel, Dao Quang Minh <daniel at nitrous dot io>

deleted file mode 100644

@@ -1,70 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% Docker Community

-% JUNE 2014

-# NAME

-docker-cp - Copy files or folders from a container's PATH to a HOSTDIR

-or to STDOUT.

-

-# SYNOPSIS

-**docker cp**

-[**--help**]

-CONTAINER:PATH HOSTDIR|-

-

-# DESCRIPTION

-

-Copy files or folders from a `CONTAINER:PATH` to the `HOSTDIR` or to `STDOUT`. 

-The `CONTAINER:PATH` is relative to the root of the container's filesystem. You

-can copy from either a running or stopped container. 

-

-The `PATH` can be a file or directory. The `docker cp` command assumes all

-`PATH` values start at the `/` (root) directory. This means supplying the

-initial forward slash is optional; The command sees

-`compassionate_darwin:/tmp/foo/myfile.txt` and

-`compassionate_darwin:tmp/foo/myfile.txt` as identical.

-

-The `HOSTDIR` refers to a directory on the host. If you do not specify an

-absolute path for your `HOSTDIR` value, Docker creates the directory relative to

-where you run the `docker cp` command. For example, suppose you want to copy the

-`/tmp/foo` directory from a container to the `/tmp` directory on your host. If

-you run `docker cp` in your `~` (home) directory on the host:

-

-		$ docker cp compassionate_darwin:tmp/foo /tmp

-

-Docker creates a `/tmp/foo` directory on your host. Alternatively, you can omit

-the leading slash in the command. If you execute this command from your home directory:

-

-		$ docker cp compassionate_darwin:tmp/foo tmp

-

-Docker creates a `~/tmp/foo` subdirectory.  

-

-When copying files to an existing `HOSTDIR`, the `cp` command adds the new files to

-the directory. For example, this command:

-

-		$ docker cp sharp_ptolemy:/tmp/foo/myfile.txt /tmp

-

-Creates a `/tmp/foo` directory on the host containing the `myfile.txt` file. If

-you repeat the command but change the filename:

-

-		$ docker cp sharp_ptolemy:/tmp/foo/secondfile.txt /tmp

-

-Your host's `/tmp/foo` directory will contain both files:

-

-		$ ls /tmp/foo

-		myfile.txt secondfile.txt

-		

-Finally, use '-' to write the data as a `tar` file to STDOUT.

-