deleted file mode 100644

@@ -1,2 +0,0 @@

-# these are generated by the md/md2man-all.sh script

-man*

deleted file mode 100644

@@ -1,5 +0,0 @@

-FROM fedora:20

-MAINTAINER ipbabble <emailwhenry@redhat.com>

-# Update and install pandoc

-RUN yum -y update; yum clean all;

-RUN yum -y install pandoc;

deleted file mode 100644

@@ -1,206 +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

-

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

-    

-**sudo 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**

-or

-**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 he 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, latest is assumed. If the used

- tag does not exist, an error is returned.

-

-**MAINTAINER**

- --The MAINTAINER instruction sets the Author field for the generated images.

-

-**RUN**

- --RUN has two forms:

- **RUN <command>**

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

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

- --The above is executable form.

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

-

-**CMD**

- --CMD has three forms:

-  **CMD ["executable", "param1", "param2"]** This is the preferred form, the

-  exec form.

-  **CMD ["param1", "param2"]** This command provides default parameters to

-  ENTRYPOINT)

-  **CMD command param1 param2** This command is run as a shell.

-  --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 of the CMD, the <command> executes in /bin/sh -c:

-  **FROM ubuntu**

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

-  If you run <command> wihtout a shell, then you must express the command as a

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

-

-**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 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 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 <src> <dest>** The ADD instruction copies new files from <src> and adds them

-  to the filesystem of the container at path <dest>.  <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.  <dest> is the absolute path to

-  which the source is copied inside the target container.  All new files and

-  directories are created with mode 0755, with uid and gid 0.

-

-**ENTRYPOINT**

- --**ENTRYPOINT** has two forms: ENTRYPOINT ["executable", "param1", "param2"]

- (This is like an exec, and is the preferred form.) ENTRYPOINT command param1

- param2 (This is running as a shell.) 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**

- The USER instruction sets the username or UID that is used when running the

- image.

-

-**WORKDIR**

- -- **WORKDIR /path/to/workdir**

- The WORKDIR instruction sets the working directory for the **RUN**, **CMD**, and **ENTRYPOINT** 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 the image, which is 

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

- build. The trigger is executed in the context of the downstream build, as

- if it had been inserted immediately after the FROM instruction in the

- downstream Dockerfile.  Any build instruction can be registered as a

- trigger.  This is useful if you are building an image to be

- used as a base for building other images, for example an application build

- environment or a daemon to be customized with a user-specific

- configuration.  For example, if your image is a reusable python

- application builder, it requires application source code to be

- added in a particular directory, and might require a build script

- to be 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.io Dockerfile documentation.

deleted file mode 100644

@@ -1,71 +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.

-

-# File List

-

-    docker.md

-    docker-attach.md

-    docker-build.md

-    docker-commit.md

-    docker-cp.md

-    docker-diff.md

-    docker-events.md

-    docker-export.md

-    docker-history.md

-    docker-images.md

-    docker-import.md

-    docker-info.md

-    docker-inspect.md

-    docker-kill.md

-    docker-load.md

-    docker-login.md

-    docker-logs.md

-    docker-port.md

-    docker-ps.md

-    docker-pull.md

-    docker-push.md

-    docker-restart.md

-    docker-rmi.md

-    docker-rm.md

-    docker-run.md

-    docker-save.md

-    docker-search.md

-    docker-start.md

-    docker-stop.md

-    docker-tag.md

-    docker-top.md

-    docker-wait.md

-    Dockerfile

-    md2man-all.sh

-

-# Generating man pages from the Markdown files

-

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

-container. Using the supplied Dockerfile, Docker will create a Fedora based 

-container and isolate the Pandoc installation. This is a seamless process, 

-saving you from dealing with Pandoc and dependencies on your own computer.

-

-## Building the Fedora / Pandoc image

-

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

-

-Using this Dockerfile, create a Docker image tagged `fedora/pandoc`:

-

-    docker build  -t fedora/pandoc .

-

-## Utilizing the Fedora / Pandoc image

-

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

-

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

-    -w /pandoc -i fedora/pandoc /pandoc/md/md2man-all.sh

-

-The Pandoc Docker container will process the Markdown files and generate

-the man pages inside the `docker/contrib/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]

-(http://docs.docker.io/use/working_with_volumes/).

deleted file mode 100644

@@ -1,58 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-attach - Attach to a running container

-

-# SYNOPSIS

-**docker attach** **--no-stdin**[=*false*] **--sig-proxy**[=*true*] CONTAINER

-

-# DESCRIPTION

-If you **docker run** a container in detached mode (**-d**), you can reattach to

-the detached container with **docker attach** using the container's ID or name.

-

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

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

-container, or `CTRL-\` to get a stacktrace of the Docker client when it quits.

-When you detach from a container the exit code will be returned to

-the client.

-

-# OPTIONS

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

-When set to true, do not attach to stdin. The default is *false*.

-

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

-When set to true, proxify all received signal to the process (even in non-tty

-mode). 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.io source material and internal work.

deleted file mode 100644

@@ -1,117 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-build - Build an image from a Dockerfile source at PATH

-

-# SYNOPSIS

-**docker build** [**--no-cache**[=*false*]] [**-q**|**--quiet**[=*false*]]

- [**--rm**] [**-t**|**--tag**=TAG] 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

-

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

-   When set to true, suppress verbose build output. Default is *false*.

-

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

-   When true, remove intermediate containers that are created during the

-build process. The default is true.

-

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

-   The name to be applied to the resulting image on successful completion of

-the build. `tag` in this context means the entire image name including the 

-optional TAG after the ':'.

-

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

-   When set to true, do not use a cache when building the image. The

-default is *false*.

-

-# EXAMPLES

-

-## Building an image using a Dockefile 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 `ADD` instruction

-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 arbtrary:

-

-    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.io source material and internal work.

deleted file mode 100644

@@ -1,34 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-commit - Create a new image from the changes to an existing

-container

-

-# SYNOPSIS

-**docker commit** **-a**|**--author**[=""] **-m**|**--message**[=""]

-CONTAINER [REPOSITORY[:TAG]]

-

-# DESCRIPTION

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

-

-# OPTIONS

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

-   Author name. (eg. "John Hannibal Smith <hannibal@a-team.com>"

-

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

-   Commit message

-

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

-

-# HISTORY

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

-based on docker.io source material and in

deleted file mode 100644

@@ -1,24 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-cp - Copy files/folders from the PATH to the HOSTPATH

-

-# SYNOPSIS

-**docker cp** CONTAINER:PATH HOSTPATH

-

-# DESCRIPTION

-Copy files/folders from the containers filesystem to the host

-path. Paths are relative to the root of the filesystem. Files

-can be copied from a running or stopped container.

-

-# EXAMPLE

-An important shell script file, created in a bash shell, is copied from

-the exited container to the current dir on the host:

-

-    # docker cp c071f3c3ee81:setup.sh .

-

-# HISTORY

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

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

-

deleted file mode 100644

@@ -1,44 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-diff - Inspect changes on a container's filesystem

-

-# SYNOPSIS

-**docker diff** CONTAINER

-

-# DESCRIPTION

-Inspect changes on a container's filesystem. You can use the full or

-shortened container ID or the container name set using

-**docker run --name** option.

-

-# EXAMPLE

-Inspect the changes to on a nginx container:

-

-    # docker diff 1fdfd1f54c1b

-    C /dev

-    C /dev/console

-    C /dev/core

-    C /dev/stdout

-    C /dev/fd

-    C /dev/ptmx

-    C /dev/stderr

-    C /dev/stdin

-    C /run

-    A /run/nginx.pid

-    C /var/lib/nginx/tmp

-    A /var/lib/nginx/tmp/client_body

-    A /var/lib/nginx/tmp/fastcgi

-    A /var/lib/nginx/tmp/proxy

-    A /var/lib/nginx/tmp/scgi

-    A /var/lib/nginx/tmp/uwsgi

-    C /var/log/nginx

-    A /var/log/nginx/access.log

-    A /var/log/nginx/error.log

-

-

-# HISTORY

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

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

-

-

deleted file mode 100644

@@ -1,46 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-events - Get real time events from the server

-

-**docker events** **--since**=""|*epoch-time*

-

-# DESCRIPTION

-Get event information from the Docker daemon. Information can include historical

-information and real-time information.

-

-# OPTIONS

-**--since**=""

-Show previously created events and then stream. This can be in either

-seconds since epoch, or date string.

-

-# EXAMPLES

-

-## Listening for Docker events

-

-After running docker events a container 786d698004576 is started and stopped

-(The container name has been shortened in the output below):

-

-    # docker events

-    [2014-04-12 18:23:04 -0400 EDT] 786d69800457: (from whenry/testimage:latest) start

-    [2014-04-12 18:23:13 -0400 EDT] 786d69800457: (from whenry/testimage:latest) die

-    [2014-04-12 18:23:13 -0400 EDT] 786d69800457: (from whenry/testimage:latest) stop

-

-## Listening for events since a given date

-Again the output container IDs have been shortened for the purposes of this document:

-

-    # docker events --since '2014-04-12'

-    [2014-04-12 18:11:28 -0400 EDT] c655dbf640dc: (from whenry/testimage:latest) create

-    [2014-04-12 18:11:28 -0400 EDT] c655dbf640dc: (from whenry/testimage:latest) start

-    [2014-04-12 18:14:13 -0400 EDT] 786d69800457: (from whenry/testimage:latest) create

-    [2014-04-12 18:14:13 -0400 EDT] 786d69800457: (from whenry/testimage:latest) start

-    [2014-04-12 18:22:44 -0400 EDT] 786d69800457: (from whenry/testimage:latest) die

-    [2014-04-12 18:22:44 -0400 EDT] 786d69800457: (from whenry/testimage:latest) stop

-    [2014-04-12 18:23:04 -0400 EDT] 786d69800457: (from whenry/testimage:latest) start

-    [2014-04-12 18:23:13 -0400 EDT] 786d69800457: (from whenry/testimage:latest) die

-    [2014-04-12 18:23:13 -0400 EDT] 786d69800457: (from whenry/testimage:latest) stop

-

-# HISTORY

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

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

deleted file mode 100644

@@ -1,26 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-export - Export the contents of a filesystem as a tar archive to

-STDOUT.

-

-# SYNOPSIS

-**docker export** CONTAINER

-

-# DESCRIPTION

-Export the contents of a container's filesystem using the full or shortened

-container ID or container name. The output is exported to STDOUT and can be

-redirected to a tar file.

-

-# EXAMPLE

-Export the contents of the container called angry_bell to a tar file

-called test.tar:

-

-    # docker export angry_bell > test.tar

-    # ls *.tar

-    test.tar

-

-# HISTORY

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

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

deleted file mode 100644

@@ -1,32 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-history - Show the history of an image

-

-# SYNOPSIS

-**docker history** **--no-trunc**[=*false*] [**-q**|**--quiet**[=*false*]]

- IMAGE

-

-# DESCRIPTION

-

-Show the history of when and how an image was created.

-

-# OPTIONS

-

-**--no-trunc**=*true*|*false*

-   When true don't truncate output. Default is false

-

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

-   When true only show numeric IDs. Default is false.

-

-# EXAMPLE

-    $ sudo docker history fedora

-    IMAGE          CREATED          CREATED BY                                      SIZE

-    105182bb5e8b   5 days ago       /bin/sh -c #(nop) ADD file:71356d2ad59aa3119d   372.7 MB

-    73bd853d2ea5   13 days ago      /bin/sh -c #(nop) MAINTAINER Lokesh Mandvekar   0 B

-    511136ea3c5a   10 months ago                                                    0 B

-

-# HISTORY

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

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

deleted file mode 100644

@@ -1,99 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-images - List the images in the local repository

-

-# SYNOPSIS

-**docker images**

-[**-a**|**--all**=*false*]

-[**--no-trunc**[=*false*]

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

-[**-t**|**--tree**=*false*]

-[**-v**|**--viz**=*false*]

-[NAME]

-

-# DESCRIPTION

-This command lists the images stored in the local Docker repository.

-

-By default, intermediate images, used during builds, are not listed. Some of the

-output, e.g. image ID, is truncated, for space reasons. However the truncated

-image ID, and often the first few characters, are enough to be used in other

-Docker commands that use the image ID. The output includes repository, tag, image

-ID, date created and the virtual size.

-

-The title REPOSITORY for the first title may seem confusing. It is essentially

-the image name. However, because you can tag a specific image, and multiple tags

-(image instances) can be associated with a single name, the name is really a

-repository for all tagged images of the same name. For example consider an image

-called fedora. It may be tagged with 18, 19, or 20, etc. to manage different

-versions.

-

-# OPTIONS

-

-**-a**, **--all**=*true*|*false*

-   When set to true, also include all intermediate images in the list. The

-default is false.

-

-**--no-trunc**=*true*|*false*

-   When set to true, list the full image ID and not the truncated ID. The

-default is false.

-

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

-   When set to true, list the complete image ID as part of the output. The

-default is false.

-

-**-t**, **--tree**=*true*|*false*

-   When set to true, list the images in a tree dependency tree (hierarchy)

-format. The default is false.

-

-**-v**, **--viz**=*true*|*false*

-   When set to true, list the graph in graphviz format. The default is

-*false*.

-

-# EXAMPLES

-

-## Listing the images

-

-To list the images in a local repository (not the registry) run:

-

-    docker images

-

-The list will contain the image repository name, a tag for the image, and an

-image ID, when it was created and its virtual size. Columns: REPOSITORY, TAG,

-IMAGE ID, CREATED, and VIRTUAL SIZE.

-

-To get a verbose list of images which contains all the intermediate images

-used in builds use **-a**:

-

-    docker images -a

-

-## List images dependency tree hierarchy

-

-To list the images in the local repository (not the registry) in a dependency

-tree format, use the **-t** option.

-

-    docker images -t

-

-This displays a staggered hierarchy tree where the less indented image is

-the oldest with dependent image layers branching inward (to the right) on

-subsequent lines. The newest or top level image layer is listed last in

-any tree branch.

-

-## List images in GraphViz format

-

-To display the list in a format consumable by a GraphViz tools run with

-**-v**. For example to produce a .png graph file of the hierarchy use:

-

-    docker images --viz | dot -Tpng -o docker.png

-

-## Listing only the shortened image IDs

-

-Listing just the shortened image IDs. This can be useful for some automated

-tools.

-

-    docker images -q

-

-# HISTORY

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

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

deleted file mode 100644

@@ -1,39 +0,0 @@

-% DOCKER(1) Docker User Manuals

-% William Henry

-% APRIL 2014

-# NAME

-docker-import - Create an empty filesystem image and import the contents

-of the tarball into it.

-

-# SYNOPSIS

-**docker import** URL|- [REPOSITORY[:TAG]]

-

-# DESCRIPTION

-Create a new filesystem image from the contents of a tarball (`.tar`,

-`.tar.gz`, `.tgz`, `.bzip`, `.tar.xz`, `.txz`) into it, then optionally tag it.

-

-# EXAMPLES

-

-## Import from a remote location

-

-    # docker import http://example.com/exampleimage.tgz example/imagerepo

-

-## Import from a local file

-

-Import to docker via pipe and stdin:

-

-    # cat exampleimage.tgz | docker import - example/imagelocal

-

-## Import from a local file and tag

-

-Import to docker via pipe and stdin:

-

-    # cat exampleimageV2.tgz | docker import - example/imagelocal:V-2.0

-

-## Import from a local directory

-

-    # tar -c . | docker import - exampleimagedir

-

-# HISTORY

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

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