--cgroup-parent is coming to Docker 1.6.0

[hany]

Seems like docker/docker#11428 was merged and will be available in Docker 1.6.0, which addresses docker/docker#6791. I'm curious how this impacts this project?

[ibuildthecloud]

I need to test this, but I believe cgroup parent doesn't work as you would think with systemd. Hopefully I'm wrong.

[luebken]

As 1.6 is released: any chance you've tested this?

[ibuildthecloud]

I'll test once Docker 1.6 lands in CoreOS alpha. I assume that will be in the next day or so.

[nickvth]

Someone has an example with --cgroup-parent and systemd?

[ibuildthecloud]

Sorry to report the --cgroup-parent does nothing but rename the scope on systemd. For systemd it's a useless feature. In Docker 1.7 it will hopefully change. More info here https://github.com/docker/libcontainer/pull/549 but it won't address what systemd-docker does.

There is a separate PR in Docker 1.7 https://github.com/docker/docker/pull/10427 that will actually make systemd-docker work much much better. Ironically it disables the use of the systemd cgroup manager but this allows us to launch Docker containers in systemd that doesn't involve manually changing cgroups.

[nickvth]

@ibuildthecloud thanks for the answer, i will check later when docker 1.7 is available.

[vaibhavkhanduja]

I have docker 1.6 installed

docker --version Docker version 1.6.0, build 4749651

but I don't see option of -cgroup-parent, can somebody help me with an example too.

ocker --version Docker version 1.6.0, build 4749651 vagrant@vagrant-ubuntu-trusty-64:/vagrant/example$ docker Usage: docker [OPTIONS] COMMAND [arg...]

A self-sufficient runtime for linux containers.

Options: --api-cors-header= Set CORS headers in the remote API -b, --bridge= Attach containers to a network bridge --bip= Specify network bridge IP -D, --debug=false Enable debug mode -d, --daemon=false Enable daemon mode --default-ulimit=[] Set default ulimits for containers --dns=[] DNS server to use --dns-search=[] DNS search domains to use -e, --exec-driver=native Exec driver to use --fixed-cidr= IPv4 subnet for fixed IPs --fixed-cidr-v6= IPv6 subnet for fixed IPs -G, --group=docker Group for the unix socket -g, --graph=/var/lib/docker Root of the Docker runtime -H, --host=[] Daemon socket(s) to connect to -h, --help=false Print usage --icc=true Enable inter-container communication --insecure-registry=[] Enable insecure registry communication --ip=0.0.0.0 Default IP when binding container ports --ip-forward=true Enable net.ipv4.ip_forward --ip-masq=true Enable IP masquerading --iptables=true Enable addition of iptables rules --ipv6=false Enable IPv6 networking -l, --log-level=info Set the logging level --label=[] Set key=value labels to the daemon --log-driver=json-file Containers logging driver --mtu=0 Set the containers network MTU -p, --pidfile=/var/run/docker.pid Path to use for daemon PID file --registry-mirror=[] Preferred Docker registry mirror -s, --storage-driver= Storage driver to use --selinux-enabled=false Enable selinux support --storage-opt=[] Set storage driver options --tls=false Use TLS; implied by --tlsverify --tlscacert=~/.docker/ca.pem Trust certs signed only by this CA --tlscert=~/.docker/cert.pem Path to TLS certificate file --tlskey=~/.docker/key.pem Path to TLS key file --tlsverify=false Use TLS and verify the remote -v, --version=false Print version information and quit

Commands: attach Attach to a running container build Build an image from a Dockerfile commit Create a new image from a container's changes cp Copy files/folders from a container's filesystem to the host path create Create a new container diff Inspect changes on a container's filesystem events Get real time events from the server exec Run a command in a running container export Stream the contents of a container as a tar archive history Show the history of an image images List images import Create a new filesystem image from the contents of a tarball info Display system-wide information inspect Return low-level information on a container or image kill Kill a running container load Load an image from a tar archive login Register or log in to a Docker registry server logout Log out from a Docker registry server logs Fetch the logs of a container port Lookup the public-facing port that is NAT-ed to PRIVATE_PORT pause Pause all processes within a container ps List containers pull Pull an image or a repository from a Docker registry server push Push an image or a repository to a Docker registry server rename Rename an existing container restart Restart a running container rm Remove one or more containers rmi Remove one or more images run Run a command in a new container save Save an image to a tar archive search Search for an image on the Docker Hub start Start a stopped container stats Display a stream of a containers' resource usage statistics stop Stop a running container tag Tag an image into a repository top Lookup the running processes of a container unpause Unpause a paused container version Show the Docker version information wait Block until a container stops, then print its exit code

Run 'docker COMMAND --help' for more information on a command.

[nickvth]

@vaibhavkhanduja

docker run --help

Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

Run a command in a new container

-a, --attach=[] Attach to STDIN, STDOUT or STDERR --add-host=[] Add a custom host-to-IP mapping (host:ip) -c, --cpu-shares=0 CPU shares (relative weight) --cap-add=[] Add Linux capabilities --cap-drop=[] Drop Linux capabilities --cgroup-parent= Optional parent cgroup for the container --cidfile= Write the container ID to the file --cpuset-cpus= CPUs in which to allow execution (0-3, 0,1) -d, --detach=false Run container in background and print container ID

[pikeas]

Ping re: https://github.com/docker/docker/pull/10427, which is now merged. How does this affect (the necessity of) systemd-docker?

[ibuildthecloud]

It doesn't make it not required but it will make it such that it will work almost perfectly with no cgroup hackery. But this means you have to disable systemd integration on a systemd system.

[ibuildthecloud]

Post 1.7 release I will update systemd-docker to use cgroup-parent combined with disabling systemd integration.

[pikeas]

@ibuildthecloud That sounds great. A pair of followup questions:

1) I'm not super familiar with systemd. What are the consequences/pros/cons of disabling systemd integration? 2) What are your thought's on @ibukanov's comment on https://github.com/docker/docker/issues/6791:

A simpler solution then using @ibuildthecloud's systemd-docker is to start a docker container in the background in ExecStartPre via run -d container or start container and then using ExecStart=/usr/bin/docker logs -f container. This way systemd, before starting any dependent units, waits until docker run -d or docker start returns and that happens only when the container is started. Then the logs command sends the initial startup logs to systemd and journal and then continue to do so as the new logs arrive until the container stops.

With this approach one also needs to put -/usr/bin/docker stop container both to ExecStop and ExecStopPost. The latter ensures that if /usr/bin/docker logs dies before the container terminates, then systemd still stops the container. Note that by just using ExecStopPost without ExecStop one will not get the termination logs into the journal as systemctl stop will kill the logs command before ExecStopPost stops the container.

[ibotty]

I am not @ibuildthecloud, but that simpler solution is simplistic, in that the container is still not supervised at all. The big command streaming the logs to stdout is now docker logs and not docker run, but that's most of the difference.

[pikeas]

@ibuildthecloud Docker 1.7 has been out for a bit, still planning to update systemd-docker?

[ibukanov]

@ibotty I use that docker run -d followed by docker log trick as it allows to properly express container dependencies and make sure, for example, that if B needs A due to --link=A or --net=container:A, then restarting A either from docker or systemd also restarts B after docker starts A. Surely it does not allow for systemd to manage the container, but at least it ensures reliable startup and running.

[TimWolla]

@ibuildthecloud Any update on this issue?