Swap "grep -q" with "grep > /dev/null" so that "go help" doesn't balk when the pipe closes unexpectedly (since "grep -q" closes the pipe the second it finds a match)
With two additional commands, this procedure will work for Ubuntu 13.10 using the image stackbrew/ubuntu:13.10.
1) change /etc/pam.d/sshd, pam_loginuid line 'required' to 'optional'
2) echo LANG=\"en_US.UTF-8\" > /etc/default/locale
Whether or not the "busybox" image downloads and runs properly at the end of the build, we don't want to have the script return a failing exit code, especially since at that point, Docker is successfully installed, and we're just tooting our own horn for good measure.
The 1.7 API docs show the ability to pass Privileged
when creating a container. This is not supported as.
Privileged is now part of hostConfig and can only be
passed when starting a container.
This fixes the documentation issue.
On previous version, glob pattern will be expanded to actual file
names when writing setting to etc/apt/apt.conf.d/no-cache.
This patch fixes to quote to work cache clean command properly.
An additional flag to limit the networking MTU is required in three Compute Engine zones for reliable networking from inside the docker container. Added a warning to that effect to the QuickStart guide.
Since commit c91c365, when starting the docker daemon without an
existing /var/lib/docker directory, it fails with:
2013/12/18 23:39:36 Unable to canonicalize root (%!s(*string=0xc210077c80)): lstat /var/lib/docker: no such file or directory
Move the symlink checking code to engine.New after the root dir has been
created.
When pulling from a registry we get a compressed tar archive, so
we need to wrap the stream in the right kind of compress reader.
Unfortunately go doesn't have an Xz decompression method, but I
don't think any docker layers use that atm anyway.
Only necessary if distro policy dictates that the path deviate from the paths already listed in utils/utils.go - please refrain from using it otherwise.
Along with the kernel requirement, you need a working copy of lxc. When trying to start using "/docker -d", received error 'initapi: exec: "lxc-start": executable file not found in $PATH'
The TestLookupImage test seems to use a layer that contains
/etc/postgres/postgres.conf, but not e.g. /etc/postgres.
To handle this we ensure that the parent directory always
exists, and if not we create it.
Previously the introduction link pointed to www.docker.io. That
did not seem to make a lot of sense to me so instead I pointed it
at:
http://www.docker.io/learn_more/
e.g.:
```
docker -d -bip "10.10.0.1/16"
```
If set and valid, use provided in place of trial and error from pre-defined array in network.go.
Mutually exclusive of -b option.
The default gnu tar format has no sub-second precision mtime support,
and the golang tar writer currently doesn't support that either.
This means if we export the changes from a container we will not
get zeron in the sub-second precision field when the change is applied.
This means we can't compare that to the original without getting a
spurious change. So, we detect this case by treating a case where the
seconds match and either of the two nanoseconds are zero as equal.
Rather than calling out to tar we use the golang tar parser
to directly extract the tar files. This has two major advantages:
1) We're able to replace an existing directory with a file in the
new layer. This currently breaks with the external tar, since
it refuses to recursively remove the destination directory in
this case, and there are no options to make it do that.
2) We avoid extracting the whiteout files just to later remove them.
Drop capabilities in dockerinit instead of with lxc utils, since
libvirt-lxc doesn't support it.
This will also be needed for machine container mode, since dockerinit
needs CAP_SYS_ADMIN to setup /dev/console correctly.
* Jobs return an integer status instead of a string
* Status convention mimics unix process execution: 0=success, 1=generic error, 127="no such command"
* Stdout and Stderr support multiple thread-safe data receivers and ring buffer filtering
1. The AUR package is called docker-git, not lxc-docker-git.
2. According to the official community package, docker depends on
sqlite.
3. 02ef8ec (Update archlinux.rst as packages have changed, 2013-12-06)
updated the installation instructions, but left behind residual
wording about the AUR package not being officially supported; the
community repository is officially supported.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
* Unify version checking code into version.go
* Make 'version' available as a job in the engine
* Use simplified version checking code when setting user agent for registry client.
This reverts commit c81bb20f5b.
After re-reading the documentation: "The Recommends field should list packages that would be found together with this one in all but unusual installations."
Thus, "Recommends" is an acceptable place for this dep, and anyone disabling that gets to keep the pieces.
The main crux of why this needs to be reverted is because it breaks Debian completely because "lxc" and "cgroup-bin" can't be installed concurrently.
The return status for inactive users was being checked
too early in the process, so I moved it from just after
the handling of POST /v1/users/ to after getting the
response from GET /v1/users/
The docker package has been added into the Arch Linux community repo, this means that the package names and installation instructions have slightly changed.
This reverts commit c81bb20f5b.
After re-reading the documentation: "The Recommends field should list packages that would be found together with this one in all but unusual installations."
Thus, "Recommends" is an acceptable place for this dep, and anyone disabling that gets to keep the pieces.
The main crux of why this needs to be reverted is because it breaks Debian completely because "lxc" and "cgroup-bin" can't be installed concurrently.
RequestFactory is no longer a singleton (can be different for different instances of Registry)
Registry now has an indexEndpoint member
Registry methods that needed the indexEndpoint parameter no longer do so
Registry methods will only use token auth where applicable if basic auth is not enabled.
This commit improves upon the PortMapper and PortAllocator classes by changing
their internal data structures for port allocations to use a string rather than
a single integer. This string holds the network interface address as well as the
port number. This solves a previous problem where a port would be incorrectly
reported as being in use because it had been allocated for a different interface.
I've also added a basic test case for the PortMapper class, and extended the
existing test case for PortAllocator. In the case of PortMapper, this is done
by handing it a stub function for creating proxies rather than an actual
implementation.
Since cgroup-bin is only "recommended" by the lxc package on Ubuntu, but is necessary for having the proper cgroups mounted for Docker to function, this makes some sense for us to add separately.
Fixes#2990
Allow the user to set DOCKER_NOWARN_KERNEL_VERSION=1 to disable the
warning for RHEL 6.5 and other distributions that don't exhibit the
panics described in https://github.com/dotcloud/docker/issues/407.
This makes it a lot easier to script with docker instances as one can
ask for details about running instances more easily without having to
have additional JSON processing tools installed.
dotcloud/docker#734
If a command during build fails, `docker build` now returns with
the exit code of that command.
This makes it necessary to change the build api endpoint to
return a json object stream.
* Added sample Volumes parameter to container create API.
* Added PortBindings and PublishAllPorts parameter to container start API
* Added note to container start about Binds needed to be declared as Volumes during container create.
* Volume exports ./bundles instead of root directory
* Documents build using docker-docs instead of docker:docs
* Bundles directory is created before running build or docs
* Jobs return an integer status instead of a string
* Status convention mimics unix process execution: 0=success, 1=generic error, 127="no such command"
* Stdout and Stderr support multiple thread-safe data receivers and ring buffer filtering
This code was resulting in a call for
/v1/images/<namespace>/<repository>/ancestry which the Registry
doesn't understand. Furthermore, it was masking the original
error.
lxc-docker-nightly installs latest build. Removed go from dependencies, as it is not needed in lxc-docker and lxc-docker-nightly. The -git package will flag go as a dependency upon installation.
If two clients simultaneously try to pull the same tag, there was a race
whereby one would succeed and the second would generate an error. Now,
the second simply waits for the first to complete.
Hi guys, it just might be me, but clicking the AMI from http://cloud-images.ubuntu.com/locator/ec2/ is broken to me. So I just did it via the normal Create Instance Wizard.
I just though some people might have the same issue.
Sorry if my markdown for links is screwed up, I went by the examples, since I'm used to the `[]()` traditional one.
Cheers.
On systems that supports reflinking (i.e. btrfs) this means the dummy
backend is much faster at copying files and will be sharing file data in
a CoW fashion.
On my (btrfs) system this makes "docker run ubuntu echo hello world" go
from about 3 seconds to about 1 second. Not instant, but clearly better.
cp --reflink=auto is availible since coreutils 7.5 (around 2009), so this
seems pretty ok to rely on.
cp is also better at preserving file metadata than tar, so for instance
it will copy xattrs.
This change makes docker compute container size correctly.
The old code isn't taking hard links into account. Containers could
seem like they're up to 1-1.5x larger than they really were.
This change makes docker compute layer size correctly.
The old code isn't taking hard links into account. Layers could
seem like they're up to 1-1.5x larger than they really were.
This moves Driver.Size() to Differ.DiffSize(), removing the empty
implementations in devmapper and dummy, and renaming the one in aufs.
Then we fall back to a container.Changes() implementation in the non-aufs
case.
We place the actual image/containers in the "rootfs" directory, which
allows us to have other data in the toplevel directory in the mount.
For starters, this means the "lost+found" directory from mkfs will
not always be in your container/image.
Secondly, we can create a file "id" in the toplevel dir which is not
visible from the container. This is useful because it allows us to map
back from the device fs to the container if something goes wrong with
the devicemapper metadata.
This is the proposed fix for #2506. It provides a more complete message
with regards to name collisions including informing of the opposing
containers ID.
I have included a test to ensure that the correct short id is displayed
to make the message easier to understand.
Finish container cleanup before setting the state to stopped.
Otherwise, for an application that exits quickly, a call to Restart
can allow Start to be called again before cleanup is done, resulting in
overritten data in the Container struct.
In the dind environment running on a Fedora host, the lxc utils get
confused by the /sys/fs/cgroup/cpuacct,cpu cgroup mount and lxc-start
fails trying to access the wrong cgroup directory.
Each arg to docker run should be placed in a separate string.
Otherwise, when starting the command via exec.Cmd, the command is
interpreted as "echo test", which can't be found.
It makes no sense to use the aufs or devicemapper drivers for volumes.
The aufs one is perhaps not a big problem, but the devicemapper one
certainly is. It will be unnecessarily using a dm
blockdevice-over-loopback with a limited size base FS.
This just hardcodes the driver to be the dummy, perhaps in the future
we can have other drivers that make sense for the volumes.
This adds a generic Status call in the Driver api and
implements if for the devicemapper backend.
The status is an array of key/value strings rather than a map so that
we can guarantee some static order of the docker info output.
This adds 3 tests:
Verify that ChangesDirs() returns nothing when run on a copy of the
same directory.
Verify that various mutations of a directory get reported with the
right changes.
Verify that ExportChanges() + ApplyLayer() of the above mutation gets
an identical directory.
Unfortunately the last test is disabled because it fails in multiple
ways atm. But I want to get it in so that we can fix it.
For people who toggle drivers we want to save the driver used
to create a container so that if the driver changes we can skip
loading the container and it should not show up in docker ps
I found that the original example wasn't starting the docker container when docker is started. So, I modified it using information I found from https://groups.google.com/forum/#!msg/docker-user/OWz8EOpiXuo/L_uxGFQuYlkJ
Also, upstart wasn't starting docker if it wasn't running ahead of time. So, I added a change to the docker upstart script to solve this.
When getting the private port used by a container using
`docker port` returns 0.0.0.0:49353, stript just the portnumber of the address with awk to used it in the rest of the example code.
This replaces the current version with the latest version from the
dm branch. Advantages in this version:
We only scan each directory tree once, which means less i/o and less chance
of container changes inbetween the two scans causing inconsistencies.
We avoid comparing some fields for change detection:
* Inode
* size-in-blocks
These can change during a copy operation (e.g. in the dummy backend)
without needing to actually reflect a change in content or metadata.
* Ctime
Any copy operation will create a new Ctime value, and there is no
API to change it to the "source" value.
* size for directories
The size of a directory doesn't have to be the same just because you
recreated the same content as another director. Internal details in
the filesystem may make these different with no "real" change.
- Remove the overrides config.vm.box and config.vm.box_url and use
the same values for all providers.
- Use the same private key path for all providers. It is still possible
to set a different private key path through the environment variable
SSH_PRIVKEY_PATH if desired (your AWS key may be different from your
Virtualbox key).
- Allow the environment variable AWS_INSTANCE_TYPE to specify the
instance type of instead of hard coding the AWS instance type as
't1.micro'. 't1.micro' is still the default if unspecified.
- Use the same environment variables for keys as the Amazon provided EC2
API tools. This allows people who already have the EC2 tools set up
correctly to use 'vagrant up' with less environment configuration
than before.
- Rewrite the provisioning code. The goal is to be idempotent and to
correctly install docker for all providers instead of just virtualbox.
It will conditionally install the virtualbox guest additions if
virtualbox is the provider.
- Update the AWS install documentation to reflect the changes.
Iptables interprets "-d 0.0.0.0" as "-d 0.0.0.0/32", not /0. This
results in the DNAT rule never matching any traffic if not bound
to a specific host IP.
Fixes#2598
lxc-start requires / to be mounted private, otherwise the changes
it does inside the container (both mounts and unmounts) will propagate
out to the host.
We work around this by starting up lxc-start in its own namespace where
we set / to rshared.
Unfortunately go can't really execute any code between clone and exec,
so we can't do this in a nice way. Instead we have a horrible hack that
use the unshare command, the shell and the mount command...
There is no need to have this be writable, and there is a chance
that e.g. atime updates will cause writes to the image which is
bad for disk use wrt sharing between all containers.
As per the thin provisioning docs for creating the pool:
$data_block_size gives the smallest unit of disk space that can be
allocated at a time expressed in units of 512-byte sectors.
$data_block_size must be between 128 (64KB) and 2097152 (1GB) and a
multiple of 128 (64KB). $data_block_size cannot be changed after the
thin-pool is created. People primarily interested in thin provisioning
may want to use a value such as 1024 (512KB). People doing lots of
snapshotting may want a smaller value such as 128 (64KB).
The switch from 512 (which we used before) to 128 (recommended above
for lots of snapshoting) means a simple container creation (based on the
mattdm/fedora:f19 image) adds 1 MB of diskspace rather than 3.6.
This seems more in tune with how docker is typically used.
We were leaking the temporary directory that we create in TarFilter,
because the "tmpDir, err := ioutil.TempDir()" call overrides the
tmpDir in the outer scope with a new locally scoped variable.
This means tmpDir is always "" when the cleanup function is called.
Also, we did not call the atExit() function if CmdStream had an
error early on.
On errors in CmdStream(),
This separates out the DeviceSet logic a bit better from the raw
device mapper operations.
devicemapper: Serialize addess to the devicemapper deviceset
This code is not safe to run in multiple threads at the same time,
and neither is libdevmapper.
DeviceMapper: Move deactivate into UnmountDevice
This way the deactivate is atomic wrt othe device mapper operations
and will not fail with EBUSY if someone else starts a devicemapper
operation inbetween unmount and deactivate.
devmapper: Fix loopback mounting regression
Some changes were added to attach_loop_device which added
a perror() in a place that caused it to override errno so that
a later errno != EBUSY failed. This fixes that and cleans up
the error reporting a bit.
devmapper: Build on old kernels without LOOP_CTL_GET_FREE define
When running the test inside a docker container we sometimes are left with
leftover device nodes for device mapper devices that no longer exist.
We were panic:ing in this case, but with this change we just remove such
nodes.
This is a better fix for futimes() on kernels not supporting O_PATH.
The previous fix broke when copying a device, as it tried to open it
and got and error.
Older kernel can't handle O_PATH in open() so this will
fail on dirs and symlinks. For dirs wa can fallback to
the normal Utimes, but for symlinks there is not much to do
but ignore their timestamps.
This creates a container by copying the corresponding files
from the layers into the containers. This is not gonna be very useful
on a developer setup, as there is no copy-on-write or general diskspace
sharing. It also makes container instantiation slower.
However, it may be useful in deployment where we don't always have a lot
of containers running (long-running daemons) and where we don't
do a lot of docker commits.
Change the comparison to better handle files that are copied during
container creation but not actually changed:
* Inode - this will change during a copy
* ctime - this will change during a copy (as we can't set it back)
* blocksize - this will change for sparse files during copy
* size for directories - this can change anytime but doesn't
necessarily reflect an actual contents change
* Compare mtimes at microsecond precision (as this is what utimes has)
There are some changes here that make the file metadata better match
the layer files:
* Set the mode of the file after the chown, as otherwise the per-group/uid
specific flags and e.g. sticky bit is lost
* Use lchown instead of chown
* Delay mtime updates to after all other changes so that later file
creation doesn't change the mtime for the parent directory
* Use Futimes in combination with O_PATH|O_NOFOLLOW to set mtime on symlinks
Rather than scan the files in the old directory twice to detect the
deletions we now scan both directories twice and then do all the
diffing on the in-memory structure.
This is more efficient, but it also lets us diff more complex things
later that are not exact on-disk trees.
The init layer needs to be topmost to make sure certain files
are always there (for instance, the ubuntu:12.10 image wrongly
has /dev/shm being a symlink to /run/shm, and we need to override
that). However, previously the devmapper code implemented the
init layer by putting it in the base devmapper device, which meant
layers above it could override these files (so that ubuntu:12.10
broke).
So, instead we put the base layer in *each* images devmapper device.
This is "safe" because we still have the pristine layer data
in the layer directory. Also, it means we diff the container
against the image with the init layer applied, so it won't show
up in diffs/commits.
lxc-start requires / to be mounted private, otherwise the changes
it does inside the container (both mounts and unmounts) will propagate
out to the host.
We work around this by starting up lxc-start in its own namespace where
we set / to rprivate.
Unfortunately go can't really execute any code between clone and exec,
so we can't do this in a nice way. Instead we have a horrible hack that
use the unshare command, the shell and the mount command...
Right now this does nothing but add a new layer, but it means
that all DeviceMounts are paired with DeviceUnmounts so that we
can track (and cleanup) active mounts.
I currently need this to get the tests running, otherwise it will
mount the docker.test binary inside the containers, which doesn't
work due to the libdevmapper.so dependency.
We wrap the "real" DeviceSet for each test so that we get only
a single device-mapper pool and loopback mounts, but still
separate out the IDs in the tests. This makes the test run
much faster.
This wraps an existing DeviceSet and just adds a prefix to all ids in
it. This will be useful for reusing a single DeviceSet for all the tests
(but with separate ids)
There are a few changes:
* Callers can specify if they want recursive behaviour or not
* All file listings to tar are sent on stdin, to handle long lists better
* We can pass in a list of filenames which will be created as empty
files in the tarball
This is exactly what we want for the creation of layer tarballs given
a container fs, a set of files to add and a set of whiteout files to create.
To do diffing we just compare file metadata, so this relies
on things like size and mtime/ctime to catch any changes.
Its *possible* to trick this by updating a file without
changing the size and setting back the mtime/ctime, but
that seems pretty unlikely to happen in reality, and lets
us avoid comparing the actual file data.
Without this there is really no way to map back from the device-mapper
devices to the actual docker image/container ids in case the json file
somehow got lost
This supports creating images from layers and mounting them
for running a container.
Not supported yet are:
* Creating diffs between images/containers
* Creating layers for new images from a device-mapper container
This interface matches the device-mapper implementation (DeviceSetDM)
but is free from any dependencies. This allows core docker code
to refer to a DeviceSet without having an explicit dependency on
the devmapper package.
This is important, because the devmapper package has external
dependencies which are not wanted in the docker client app, as it
needs to run with minimal dependencies in the docker image.
In some builds the main docker binary is not statically linked,
and as such not usable in as the .dockerinit binary, for those
cases we look for a separately shipped docker-init binary and
use that instead.
This is a module that uses the device-mapper create CoW snapshots
You instantiate a DeviceSetDM object on a specified root (/var/lib/docker),
and it will create a subdirectory there called "loopback". It will
contain two sparse files which are loopback mounted into
a thin-pool device-mapper device called "docker-pool".
We then create a base snapshot in the pool with an empty filesystem
which can be used as a base for docker snapshots. It also keeps track
of the mapping between docker image ids and the snapshots in the pool.
Typical use of is something like (without error checking):
devices = NewDeviceSetDM("/var/lib/docker")
devices.AddDevice(imageId, "") // "" is the base image id
devices.MountDevice(imageId, "/mnt/image")
... extract base image to /mnt/image
devices.AddDevice(containerId, imageId)
devices.MountDevice(containerId, "/mnt/container")
... start container at /mnt/container
This is a better fix for futimes() on kernels not supporting O_PATH.
The previous fix broke when copying a device, as it tried to open it
and got and error.
Older kernel can't handle O_PATH in open() so this will
fail on dirs and symlinks. For dirs wa can fallback to
the normal Utimes, but for symlinks there is not much to do
but ignore their timestamps.
This creates a container by copying the corresponding files
from the layers into the containers. This is not gonna be very useful
on a developer setup, as there is no copy-on-write or general diskspace
sharing. It also makes container instantiation slower.
However, it may be useful in deployment where we don't always have a lot
of containers running (long-running daemons) and where we don't
do a lot of docker commits.
Change the comparison to better handle files that are copied during
container creation but not actually changed:
* Inode - this will change during a copy
* ctime - this will change during a copy (as we can't set it back)
* blocksize - this will change for sparse files during copy
* size for directories - this can change anytime but doesn't
necessarily reflect an actual contents change
* Compare mtimes at microsecond precision (as this is what utimes has)
There are some changes here that make the file metadata better match
the layer files:
* Set the mode of the file after the chown, as otherwise the per-group/uid
specific flags and e.g. sticky bit is lost
* Use lchown instead of chown
* Delay mtime updates to after all other changes so that later file
creation doesn't change the mtime for the parent directory
* Use Futimes in combination with O_PATH|O_NOFOLLOW to set mtime on symlinks
Rather than scan the files in the old directory twice to detect the
deletions we now scan both directories twice and then do all the
diffing on the in-memory structure.
This is more efficient, but it also lets us diff more complex things
later that are not exact on-disk trees.
The init layer needs to be topmost to make sure certain files
are always there (for instance, the ubuntu:12.10 image wrongly
has /dev/shm being a symlink to /run/shm, and we need to override
that). However, previously the devmapper code implemented the
init layer by putting it in the base devmapper device, which meant
layers above it could override these files (so that ubuntu:12.10
broke).
So, instead we put the base layer in *each* images devmapper device.
This is "safe" because we still have the pristine layer data
in the layer directory. Also, it means we diff the container
against the image with the init layer applied, so it won't show
up in diffs/commits.
lxc-start requires / to be mounted private, otherwise the changes
it does inside the container (both mounts and unmounts) will propagate
out to the host.
We work around this by starting up lxc-start in its own namespace where
we set / to rprivate.
Unfortunately go can't really execute any code between clone and exec,
so we can't do this in a nice way. Instead we have a horrible hack that
use the unshare command, the shell and the mount command...
Right now this does nothing but add a new layer, but it means
that all DeviceMounts are paired with DeviceUnmounts so that we
can track (and cleanup) active mounts.
I currently need this to get the tests running, otherwise it will
mount the docker.test binary inside the containers, which doesn't
work due to the libdevmapper.so dependency.
We wrap the "real" DeviceSet for each test so that we get only
a single device-mapper pool and loopback mounts, but still
separate out the IDs in the tests. This makes the test run
much faster.
This wraps an existing DeviceSet and just adds a prefix to all ids in
it. This will be useful for reusing a single DeviceSet for all the tests
(but with separate ids)
There are a few changes:
* Callers can specify if they want recursive behaviour or not
* All file listings to tar are sent on stdin, to handle long lists better
* We can pass in a list of filenames which will be created as empty
files in the tarball
This is exactly what we want for the creation of layer tarballs given
a container fs, a set of files to add and a set of whiteout files to create.
To do diffing we just compare file metadata, so this relies
on things like size and mtime/ctime to catch any changes.
Its *possible* to trick this by updating a file without
changing the size and setting back the mtime/ctime, but
that seems pretty unlikely to happen in reality, and lets
us avoid comparing the actual file data.
Without this there is really no way to map back from the device-mapper
devices to the actual docker image/container ids in case the json file
somehow got lost
This supports creating images from layers and mounting them
for running a container.
Not supported yet are:
* Creating diffs between images/containers
* Creating layers for new images from a device-mapper container
This interface matches the device-mapper implementation (DeviceSetDM)
but is free from any dependencies. This allows core docker code
to refer to a DeviceSet without having an explicit dependency on
the devmapper package.
This is important, because the devmapper package has external
dependencies which are not wanted in the docker client app, as it
needs to run with minimal dependencies in the docker image.
In some builds the main docker binary is not statically linked,
and as such not usable in as the .dockerinit binary, for those
cases we look for a separately shipped docker-init binary and
use that instead.
This is a module that uses the device-mapper create CoW snapshots
You instantiate a DeviceSetDM object on a specified root (/var/lib/docker),
and it will create a subdirectory there called "loopback". It will
contain two sparse files which are loopback mounted into
a thin-pool device-mapper device called "docker-pool".
We then create a base snapshot in the pool with an empty filesystem
which can be used as a base for docker snapshots. It also keeps track
of the mapping between docker image ids and the snapshots in the pool.
Typical use of is something like (without error checking):
devices = NewDeviceSetDM("/var/lib/docker")
devices.AddDevice(imageId, "") // "" is the base image id
devices.MountDevice(imageId, "/mnt/image")
... extract base image to /mnt/image
devices.AddDevice(containerId, imageId)
devices.MountDevice(containerId, "/mnt/container")
... start container at /mnt/container
+ Update ADD to use the image cache, based on a hash of the added content
* Add error message for empty Dockerfile
#### Documentation
- Fix outdated link to the "Introduction" on www.docker.io
+ Update the docs to get wider when the screen does
- Add information about needing to install LXC when using raw binaries
* Update Fedora documentation to disentangle the docker and docker.io conflict
* Add a note about using the new `-mtu` flag in several GCE zones
+ Add FrugalWare installation instructions
+ Add a more complete example of `docker run`
- Fix API documentation for creating and starting Privileged containers
- Add missing "name" parameter documentation on "/containers/create"
* Add a mention of `lxc-checkconfig` as a way to check for some of the necessary kernel configuration
- Update the 1.8 API documentation with some additions that were added to the docs for 1.7
#### Hack
- Add missing libdevmapper dependency to the packagers documentation
* Update minimum Go requirement to a hard line at Go 1.2+
* Many minor improvements to the Vagrantfile
+ Add ability to customize dockerinit search locations when compiling (to be used very sparingly only by packagers of platforms who require a nonstandard location)
+ Add coverprofile generation reporting
- Add `-a` to our Go build flags, removing the need for recompiling the stdlib manually
* Update Dockerfile to be more canonical and have less spurious warnings during build
- Fix some miscellaneous `docker pull` progress bar display issues
* Migrate more miscellaneous packages under the "pkg" folder
* Update TextMate highlighting to automatically be enabled for files named "Dockerfile"
* Reorganize syntax highlighting files under a common "contrib/syntax" directory
* Update install.sh script (https://get.docker.io/) to not fail if busybox fails to download or run at the end of the Ubuntu/Debian installation
* Add support for container names in bash completion
#### Packaging
+ Add an official Docker client binary for Darwin (Mac OS X)
* Remove empty "Vendor" string and added "License" on deb package
+ Add a stubbed version of "/etc/default/docker" in the deb package
#### Runtime
* Update layer application to extract tars in place, avoiding file churn while handling whiteouts
- Fix permissiveness of mtime comparisons in tar handling (since GNU tar and Go tar do not yet support sub-second mtime precision)
* Reimplement `docker top` in pure Go to work more consistently, and even inside Docker-in-Docker (thus removing the shell injection vulnerability present in some versions of `lxc-ps`)
+ Update `-H unix://` to work similarly to `-H tcp://` by inserting the default values for missing portions
- Fix more edge cases regarding dockerinit and deleted or replaced docker or dockerinit files
* Update container name validation to include '.'
- Fix use of a symlink or non-absolute path as the argument to `-g` to work as expected
* Update to handle external mounts outside of LXC, fixing many small mounting quirks and making future execution backends and other features simpler
* Update to use proper box-drawing characters everywhere in `docker images -tree`
* Move MTU setting from LXC configuration to directly use netlink
* Add `-S` option to external tar invocation for more efficient spare file handling
+ Add arch/os info to User-Agent string, especially for registry requests
+ Add `-mtu` option to Docker daemon for configuring MTU
- Fix `docker build` to exit with a non-zero exit code on error
+ Add `DOCKER_HOST` environment variable to configure the client `-H` flag without specifying it manually for every invocation
## 0.7.2 (2013-12-16)
#### Runtime
+ Validate container names on creation with standard regex
* Increase maximum image depth to 127 from 42
* Continue to move api endpoints to the job api
+ Add -bip flag to allow specification of dynamic bridge IP via CIDR
- Allow bridge creation when ipv6 is not enabled on certain systems
* Set hostname and IP address from within dockerinit
* Drop capabilities from within dockerinit
- Fix volumes on host when symlink is present the image
- Prevent deletion of image if ANY container is depending on it even if the container is not running
* Update docker push to use new progress display
* Use os.Lstat to allow mounting unix sockets when inspecting volumes
- Adjust handling of inactive user login
- Add missing defines in devicemapper for older kernels
- Allow untag operations with no container validation
- Add auth config to docker build
#### Documentation
* Add more information about Docker logging
+ Add RHEL documentation
* Add a direct example for changing the CMD that is run in a container
* Update Arch installation documentation
+ Add section on Trusted Builds
+ Add Network documentation page
#### Other
+ Add new cover bundle for providing code coverage reporting
* Separate integration tests in bundles
* Make Tianon the hack maintainer
* Update mkimage-debootstrap with more tweaks for keeping images small
* Use https to get the install script
* Remove vendored dotcloud/tar now that Go 1.2 has been released
## 0.7.1 (2013-12-05)
#### Documentation
+ Add @SvenDowideit as documentation maintainer
+ Add links example
+ Add documentation regarding ambassador pattern
+ Add Google Cloud Platform docs
+ Add dockerfile best practices
* Update doc for RHEL
* Update doc for registry
* Update Postgres examples
* Update doc for Ubuntu install
* Improve remote api doc
#### Runtime
+ Add hostconfig to docker inspect
+ Implement `docker log -f` to stream logs
+ Add env variable to disable kernel version warning
+ Add -format to `docker inspect`
+ Support bind-mount for files
- Fix bridge creation on RHEL
- Fix image size calculation
- Make sure iptables are called even if the bridge already exists
- Fix issue with stderr only attach
- Remove init layer when destroying a container
- Fix same port binding on different interfaces
-`docker build` now returns the correct exit code
- Fix `docker port` to display correct port
-`docker build` now check that the dockerfile exists client side
-`docker attach` now returns the correct exit code
- Remove the name entry when the container does not exist
#### Registry
* Improve progress bars, add ETA for downloads
* Simultaneous pulls now waits for the first to finish instead of failing
- Tag only the top-layer image when pushing to registry
- Fix issue with offline image transfer
- Fix issue preventing using ':' in password for registry
#### Other
+ Add pprof handler for debug
+ Create a Makefile
* Use stdlib tar that now includes fix
* Improve make.sh test script
* Handle SIGQUIT on the daemon
* Disable verbose during tests
* Upgrade to go1.2 for official build
* Improve unit tests
* The test suite now runs all tests even if one fails
* Refactor C in Go (Devmapper)
- Fix OSX compilation
## 0.7.0 (2013-11-25)
#### Notable features since 0.6.0
* Storage drivers: choose from aufs, device-mapper, or vfs.
* Standard Linux support: docker now runs on unmodified Linux kernels and all major distributions.
* Links: compose complex software stacks by connecting containers to each other.
* Container naming: organize your containers by giving them memorable names.
* Advanced port redirects: specify port redirects per interface, or keep sensitive ports private.
* Offline transfer: push and pull images to the filesystem without losing information.
* Quality: numerous bugfixes and small usability improvements. Significant increase in test coverage.
## 0.6.7 (2013-11-21)
#### Runtime
* Improve stability, fixes some race conditons
* Skip the volumes mounted when deleting the volumes of container.
* Fix layer size computation: handle hard links correctly
* Use the work Path for docker cp CONTAINER:PATH
* Fix tmp dir never cleanup
* Speedup docker ps
* More informative error message on name collisions
* Fix nameserver regex
* Always return long id's
* Fix container restart race condition
* Keep published ports on docker stop;docker start
* Fix container networking on Fedora
* Correctly express "any address" to iptables
* Fix network setup when reconnecting to ghost container
* Prevent deletion if image is used by a running container
* Lock around read operations in graph
#### RemoteAPI
* Return full ID on docker rmi
#### Client
+ Add -tree option to images
+ Offline image transfer
* Exit with status 2 on usage error and display usage on stderr
* Do not forward SIGCHLD to container
* Use string timestamp for docker events -since
#### Other
* Update to go 1.2rc5
+ Add /etc/default/docker support to upstart
## 0.6.6 (2013-11-06)
#### Runtime
@@ -9,7 +214,7 @@
+ Add lock around write operations in graph
* Check if port is valid
* Fix restart runtime error with ghost container networking
+ Added some more colors and animals to increase the pool of generated names
+ Add some more colors and animals to increase the pool of generated names
* Fix issues in docker inspect
+ Escape apparmor confinement
+ Set environment variables using a file.
@@ -163,7 +368,7 @@
* Improve network performance for VirtualBox
* Revamp install.sh to be usable by more people, and to use official install methods whenever possible (apt repo, portage tree, etc.)
Want to hack on Docker? Awesome! Here are instructions to get you started. They are probably not perfect, please let us know if anything feels
wrong or incomplete.
Want to hack on Docker? Awesome! Here are instructions to get you
started. They are probably not perfect, please let us know if anything
feels wrong or incomplete.
## Reporting Issues
When reporting [issues](https://github.com/dotcloud/docker/issues)
on Github please include your host OS ( Ubuntu 12.04, Fedora 19, etc... )
and the output of `docker version` along with the output of `docker info` if possible.
This information will help us review and fix your issue faster.
## Build Environment
For instructions on setting up your development environment, please see our dedicated [dev environment setup docs](http://docs.docker.io/en/latest/contributing/devenvironment/).
For instructions on setting up your development environment, please
# see https://git.fedorahosted.org/cgit/lvm2.git/refs/tags for release tags
# note: we can't use "git clone -b" above because it requires at least git 1.7.10 to be able to use that on a tag instead of a branch and we only have 1.7.9.5
# Compile and install lvm2
RUNcd /usr/local/lvm2 && ./configure --enable-static_link && make device-mapper && make install_device-mapper
# see https://git.fedorahosted.org/cgit/lvm2.git/tree/INSTALL
# Install Go
run curl -s https://go.googlecode.com/files/go1.2rc3.src.tar.gz | tar -v -C /usr/local -xz
return"",fmt.Errorf("Login: Account is not Active. Please check your e-mail for a confirmation link.")
}
return"",fmt.Errorf("Login: Account is not Active. Please see the documentation of the registry %s for instructions how to activate it.",serverAddress)
t.Fatalf("Error parsing volume flags, `-v /hostTmp:/containerTmp -v /hostVar:/containerVar` should mount-bind /hostTmp into /containeTmp and /hostVar into /hostContainer. Received %v",hostConfig.Binds)
t.Fatalf("Error parsing volume flags, `-v /hostTmp:/containerTmp:ro -v /hostVar:/containerVar:rw` should mount-bind /hostTmp into /containeTmp and /hostVar into /hostContainer. Received %v",hostConfig.Binds)
t.Fatalf("Error parsing volume flags, `-v /hostTmp:/containerTmp -v /containerVar` should mount-bind only /hostTmp into /containeTmp. Received %v",hostConfig.Binds)
The initial Docker upstart script will not work because it runs on `127.0.0.1`, which is not accessible to the host machine. Instead, we need to change the script to connect to `0.0.0.0`. To do this, modify `/etc/init/docker.conf` to look like this:
```
description "Docker daemon"
start on filesystem and started lxc-net
stop on runlevel [!2345]
respawn
script
/usr/bin/docker -d -H=tcp://0.0.0.0:4243/
end script
```
Once that's done, you need to set up a SSH tunnel between your host machine and the vagrant machine that's running Docker. This can be done by running the following command in a host terminal:
(The first 4243 is what your host can connect to, the second 4243 is what port Docker is running on in the vagrant machine, and the 2222 is the port Vagrant is providing for SSH. If VirtualBox is the VM you're using, you can see what value "2222" should be by going to: Network > Adapter 1 > Advanced > Port Forwarding in the VirtualBox GUI.)
Note that because the port has been changed, to run docker commands from within the command line you must run them like this:
```
sudo docker -H 0.0.0.0:4243 < commands for docker >
We expect that there will be multiple registries out there. To help to grasp the context, here are some examples of registries:
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.
@@ -37,7 +38,10 @@ We expect that there will be multiple registries out there. To help to grasp the
- 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).
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
We expect that there will be multiple registries out there. To help to grasp the context, here are some examples of registries:
@@ -46,10 +48,6 @@ We expect that there will be multiple registries out there. To help to grasp the
-**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):
@@ -57,12 +55,16 @@ We expect that there will be multiple registries out there. To help to grasp the
- 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).
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
@@ -76,21 +78,33 @@ On top of being a runtime for LXC, Docker is the Registry client. It supports:
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)
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.
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.
It's possible to run:
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.
..code-block::bash
Token is only returned when the 'X-Docker-Token' header is sent with request.
Basic Authis 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.
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):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -159,7 +173,9 @@ API (pulling repository foo/bar):
**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).
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):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -241,10 +257,11 @@ API (pushing repos foo/bar):
2.3 Delete
----------
If you need to delete something from the index or registry, we need a nice clean way to do that. Here is the workflow.
If you need to delete something from the index or registry, we need a nice
clean way to do that. Here is the workflow.
1. Docker contacts the index to request a delete of a repository “samalba/busybox” (authentication required with user credentials)
2. If authentication works and repository is valid, “samalba/busybox” is marked as deleted and a temporary token is returned
1. Docker contacts the index to request a delete of a repository ``samalba/busybox`` (authentication required with user credentials)
2. If authentication works and repository is valid, ``samalba/busybox`` is marked as deleted and a temporary token is returned
3. Send a delete request to the registry for the repository (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 deletes the repository and everything associated to it.
@@ -316,24 +333,40 @@ The Index has two main purposes (along with its fancy social features):
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...).
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
Docker Inc.
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.
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...).
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).
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.
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.
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
==========
@@ -343,16 +376,22 @@ The first version of the api is available here: https://github.com/jpetazzo/dock
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 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.
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
..code-block::bash
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
---------
@@ -397,7 +436,9 @@ PUT /v1/users/<username>
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.
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
@@ -409,7 +450,10 @@ GET /v1/users
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.
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
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.
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
^^^^^^^^^^^^^^^^^^^^^
@@ -488,17 +535,20 @@ Return 202 OK
======================
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.
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 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.
@@ -508,7 +558,8 @@ On the next request, the client will always pick a server from this list.
6.1 On the Index
-----------------
The Index supports both “Basic” and “Token” challenges. Usually when there is a “401 Unauthorized”, the Index replies this::
The Index supports both “Basic” and “Token” challenges. Usually when there is a
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.::
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
@@ -12,12 +12,58 @@ To list available commands, either run ``docker`` with no parameters or execute
$ sudo docker
Usage: docker [OPTIONS] COMMAND [arg...]
-H=[unix:///var/run/docker.sock]: tcp://host:port to bind/connect to or unix://path/to/socket to use
-H=[unix:///var/run/docker.sock]: tcp://[host[:port]] to bind/connect to or unix://[/path/to/socket] to use. When host=[0.0.0.0], port=[4243] or path=[/var/run/docker.sock] is omitted, default values are used.
A self-sufficient runtime for linux containers.
...
.._cli_daemon:
``daemon``
----------
::
Usage of docker:
-D=false: Enable debug mode
-H=[unix:///var/run/docker.sock]: tcp://[host[:port]] to bind or unix://[/path/to/socket] to use. When host=[0.0.0.0], port=[4243] or path=[/var/run/docker.sock] is omitted, default values are used.
-api-enable-cors=false: Enable CORS headers in the remote API
-b="": Attach containers to a pre-existing network bridge; use 'none' to disable container networking
-bip="": Use the provided CIDR notation address for the dynamically created bridge (docker0); Mutually exclusive of -b
-d=false: Enable daemon mode
-dns="": Force docker to use specific DNS servers
-g="/var/lib/docker": Path to use as the root of the docker runtime
-icc=true: Enable inter-container communication
-ip="0.0.0.0": Default IP address to use when binding container ports
-iptables=true: Disable docker's addition of iptables rules
-mtu=1500: Set the containers network mtu
-p="/var/run/docker.pid": Path to use for daemon PID file
-r=true: Restart previously running containers
-s="": Force the docker runtime to use a specific storage driver
-v=false: Print version information and quit
The Docker daemon is the persistent process that manages containers. Docker uses the same binary for both the
daemon and client. To run the daemon you provide the ``-d`` flag.
To force Docker to use devicemapper as the storage driver, use ``docker -d -s devicemapper``.
To set the DNS server for all Docker containers, use ``docker -d -dns 8.8.8.8``.
To run the daemon with debug output, use ``docker -d -D``.
The docker client will also honor the ``DOCKER_HOST`` environment variable to set
the ``-H`` flag for the client.
::
docker -H tcp://0.0.0.0:4243 ps
# or
export DOCKER_HOST="tcp://0.0.0.0:4243"
docker ps
# both are equal
.._cli_attach:
``attach``
@@ -34,11 +80,12 @@ To list available commands, either run ``docker`` with no parameters or execute
You can detach from the container again (and leave it running) with
``CTRL-c`` (for a quiet exit) or ``CTRL-\`` to get a stacktrace of
the Docker client when it quits.
the Docker client when it quits. When you detach from the container's
process the exit code will be returned to the client.
To stop a container, use ``docker stop``
To stop a container, use ``docker stop``.
To kill the container, use ``docker kill``
To kill the container, use ``docker kill``.
.._cli_attach_examples:
@@ -88,35 +135,68 @@ Examples:
Usage: docker build [OPTIONS] PATH | URL | -
Build a new container image from the source code at PATH
-t="": Repository name (and optionally a tag) to be applied to the resulting image in case of success.
-t="": Repository name (and optionally a tag) to be applied
to the resulting image in case of success.
-q=false: Suppress verbose build output.
-no-cache: Do not use the cache when building the image.
-rm: Remove intermediate containers after a successful build
When a single Dockerfile is given as URL, then no context is set. When a git repository is set as URL, the repository is used as context
The files at ``PATH`` or ``URL`` are called the "context" of the build. The
build process may refer to any of the files in the context, for example when
using an :ref:`ADD <dockerfile_add>` instruction. When a single ``Dockerfile``
is given as ``URL``, then no context is set. When a Git repository is set as
``URL``, then the repository is used as the context
$ sudo docker run -t -i -rm -volumes-from web -w /var/log/httpd busybox tail -f access.log
This example shows 5 containers that might be set up to test a web application change:
1. Start a pre-prepared volume image ``static-web-files`` (in the background) that has CSS, image and static HTML in it, (with a ``VOLUME`` instruction in the ``Dockerfile`` to allow the web server to use those files);
2. Start a pre-prepared ``riakserver`` image, give the container name ``riak`` and expose port ``8098`` to any containers that link to it;
3. Start the ``appserver`` image, restricting its memory usage to 100MB, setting two environment variables ``DEVELOPMENT`` and ``BRANCH`` and bind-mounting the current directory (``$(pwd)``) in the container in read-only mode as ``/app/bin``;
4. Start the ``webserver``, mapping port ``443`` in the container to port ``1443`` on the Docker server, setting the DNS server to ``dns.dev.org``, creating a volume to put the log files into (so we can access it from another container), then importing the files from the volume exposed by the ``static`` container, and linking to all exposed ports from ``riak`` and ``app``. Lastly, we set the hostname to ``web.sven.dev.org`` so its consistent with the pre-generated SSL certificate;
5. Finally, we create a container that runs ``tail -f access.log`` using the logs volume from the ``web`` container, setting the workdir to ``/var/log/httpd``. The ``-rm`` option means that when the container exits, the container's layer is removed.
.._cli_save:
``save``
---------
::
Usage: docker save image > repository.tar
Streams a tarred repository to the standard output stream.
Contains all parent layers, and all tags + versions.
.._cli_search:
``search``
@@ -710,7 +1192,7 @@ to the newly created container.
::
Usage: docker start [OPTIONS] NAME
Usage: docker start [OPTIONS] CONTAINER
Start a stopped container
@@ -761,7 +1243,7 @@ The main process inside the container will receive SIGTERM, and after a grace pe
``version``
-----------
Show the version of the docker client, daemon, and latest released version.
Show the version of the Docker client, daemon, and latest released version.
@@ -42,11 +42,10 @@ This following command will build a development environment using the Dockerfile
..code-block::bash
sudo docker build -t docker .
sudo make build
If the build is successful, congratulations! You have produced a clean build of docker, neatly encapsulated in a standard build environment.
If the build is successful, congratulations! You have produced a clean build of
docker, neatly encapsulated in a standard build environment.
Step 4: Build the Docker Binary
@@ -56,10 +55,23 @@ To create the Docker binary, run this command:
..code-block::bash
sudo docker run -privileged -v `pwd`:/go/src/github.com/dotcloud/docker docker hack/make.sh binary
sudo make binary
This will create the Docker binary in ``./bundles/<version>-dev/binary/``
Using your built Docker binary
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The binary is available outside the container in the directory
``./bundles/<version>-dev/binary/``. You can swap your host docker executable
with this binary for live testing - for example, on ubuntu:
..code-block::bash
sudo service docker stop ; sudo cp $(which docker)$(which docker)_ ; sudo cp ./bundles/<version>-dev/binary/docker-<version>-dev $(which docker);sudo service docker start
..note:: Its safer to run the tests below before swapping your hosts docker binary.
Step 5: Run the Tests
---------------------
@@ -68,10 +80,15 @@ To execute the test cases, run this command:
..code-block::bash
sudo docker run -privileged -v `pwd`:/go/src/github.com/dotcloud/docker docker hack/make.shtest
sudo make test
Note: if you're running the tests in vagrant, you need to specify a dns entry in the command: `-dns 8.8.8.8`
Note: if you're running the tests in vagrant, you need to specify a dns entry in
the command (either edit the Makefile, or run the step manually):
..code-block::bash
sudo docker run -dns 8.8.8.8 -privileged -v `pwd`:/go/src/github.com/dotcloud/docker docker hack/make.sh test
If the test are successful then the tail of the output should look something like this
@@ -113,15 +130,24 @@ You can run an interactive session in the newly built container:
..code-block::bash
sudo docker run -privileged -i -t docker bash
sudo make shell
# type 'exit' to exit
# type 'exit' or Ctrl-D to exit
Extra Step: Build and view the Documentation
--------------------------------------------
..note:: The binary is available outside the container in the directory ``./bundles/<version>-dev/binary/``. You can swap your host docker executable with this binary for live testing - for example, on ubuntu: ``sudo service docker stop ; sudo cp $(which docker) $(which docker)_ ; sudo cp ./bundles/<version>-dev/binary/docker-<version>-dev $(which docker);sudo service docker start``.
If you want to read the documentation from a local website, or are making changes
to it, you can build the documentation and then serve it by:
..code-block:: bash
sudo make docs
# when its done, you can point your browser to http://yourdockerhost:8000
# type Ctrl-C to exit
**Need More Help?**
If you need more help then hop on to the `#docker-dev IRC channel <irc://chat.freenode.net#docker-dev>`_ or post a message on the `Docker developer mailinglist <https://groups.google.com/d/forum/docker-dev>`_.
If you need more help then hop on to the `#docker-dev IRC channel <irc://chat.freenode.net#docker-dev>`_ or post a message on the `Docker developer mailinglist <https://groups.google.com/d/forum/docker-dev>`_.
Docker monitors one process in each running container and the container lives or dies with that process.
By introducing CFEngine inside Docker containers, we can alleviate a few of the issues that may arise:
* It is possible to easily start multiple processes within a container, all of which will be managed automatically, with the normal ``docker run`` command.
* If a managed process dies or crashes, CFEngine will start it again within 1 minute.
* The container itself will live as long as the CFEngine scheduling daemon (cf-execd) lives. With CFEngine, we are able to decouple the life of the container from the uptime of the service it provides.
How it works
------------
CFEngine, together with the cfe-docker integration policies, are installed as part of the Dockerfile. This builds CFEngine into our Docker image.
The Dockerfile's ``ENTRYPOINT`` takes an arbitrary amount of commands (with any desired arguments) as parameters.
When we run the Docker container these parameters get written to CFEngine policies and CFEngine takes over to ensure that the desired processes are running in the container.
CFEngine scans the process table for the ``basename`` of the commands given to the ``ENTRYPOINT`` and runs the command to start the process if the ``basename`` is not found.
For example, if we start the container with ``docker run "/path/to/my/application parameters"``, CFEngine will look for a process named ``application`` and run the command.
If an entry for ``application`` is not found in the process table at any point in time, CFEngine will execute ``/path/to/my/application parameters`` to start the application once again.
The check on the process table happens every minute.
Note that it is therefore important that the command to start your application leaves a process with the basename of the command.
This can be made more flexible by making some minor adjustments to the CFEngine policies, if desired.
Usage
-----
This example assumes you have Docker installed and working.
We will install and manage ``apache2`` and ``sshd`` in a single container.
There are three steps:
1. Install CFEngine into the container.
2. Copy the CFEngine Docker process management policy into the containerized CFEngine installation.
3. Start your application processes as part of the ``docker run`` command.
Building the container image
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The first two steps can be done as part of a Dockerfile, as follows.
There's a great StackOverflow answer `showing the differences <http://stackoverflow.com/questions/16047306/how-is-docker-io-different-from-a-normal-virtual-machine>`_.
Do I lose my data when the container exits?
...........................................
@@ -129,6 +134,53 @@ Not at all! Any data that your application writes to disk gets preserved
in its container until you explicitly delete the container. The file
system for the container persists even after the container halts.
How far do Docker containers scale?
...................................
Some of the largest server farms in the world today are based on containers.
Large web deployments like Google and Twitter, and platform providers such as
Heroku and dotCloud all run on container technology, at a scale of hundreds of
thousands or even millions of containers running in parallel.
How do I connect Docker containers?
...................................
Currently the recommended way to link containers is via the `link` primitive.
You can see details of how to `work with links here
1. Go to `Google Cloud Console <https://cloud.google.com/console>`_ and create a new Cloud Project with `Compute Engine enabled <https://developers.google.com/compute/docs/signup>`_.
2. Download and configure the `Google Cloud SDK <https://developers.google.com/cloud/sdk/>`_ to use your project with the following commands:
7. If running in zones: us-central1-a, europe-west1-1, and europe-west1-b, the docker daemon must be started with the `-mtu` flag. Without the flag, you may experience intermittent network pauses.
`See this issue <https://code.google.com/p/google-compute-engine/issues/detail?id=57>`_ for more details.
..code-block::bash
docker -d -mtu 1460
8. Start a new container:
..code-block::bash
docker-playground:~$ sudo docker run busybox echo'docker on GCE \o/'
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.