{"action":"created","issue":{"url":"https://api.github.com/repos/docker/docker/issues/18724","labels_url":"https://api.github.com/repos/docker/docker/issues/18724/labels{/name}","comments_url":"https://api.github.com/repos/docker/docker/issues/18724/comments","events_url":"https://api.github.com/repos/docker/docker/issues/18724/events","html_url":"https://github.com/docker/docker/issues/18724","id":122595968,"number":18724,"title":"Proposal: System-level containers","user":{"login":"cpuguy83","id":799078,"avatar_url":"https://avatars.githubusercontent.com/u/799078?v=3","gravatar_id":"","url":"https://api.github.com/users/cpuguy83","html_url":"https://github.com/cpuguy83","followers_url":"https://api.github.com/users/cpuguy83/followers","following_url":"https://api.github.com/users/cpuguy83/following{/other_user}","gists_url":"https://api.github.com/users/cpuguy83/gists{/gist_id}","starred_url":"https://api.github.com/users/cpuguy83/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cpuguy83/subscriptions","organizations_url":"https://api.github.com/users/cpuguy83/orgs","repos_url":"https://api.github.com/users/cpuguy83/repos","events_url":"https://api.github.com/users/cpuguy83/events{/privacy}","received_events_url":"https://api.github.com/users/cpuguy83/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/docker/docker/labels/kind/enhancement","name":"kind/enhancement","color":"E8CAAF"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":15,"created_at":"2015-12-16T20:37:20Z","updated_at":"2015-12-30T08:41:20Z","closed_at":null,"body":"### Problem\r\nA lot of people want to run system-level services, and even docker plugins in containers.\r\nThis means these services need to be started before any other container.\r\n\r\nAn example of this is RancherOS, which currently runs 2 daemons, one for system services and one for user services.... this is to ensure startup order and protection of \"system\" containers from accidental removal.\r\n\r\nThere are also cases like the swarm-agent, where when the agent is run in a container, swarm will hide that from the default `ps` output.\r\n\r\n### Proposed solution\r\nIn the past we've talked about having a plugin loading API, which would essentially be fancy containers... this may be a bit drastic at this point.\r\nWhat I propose is adding a new bool flag `--system` (or `HostConfig.System` in the API) which does exactly 2 things:\r\n\r\n1. Makes sure the container will startup before non-system containers\r\n2. Hides the container from `docker ps` output, though will be visible in `docker ps -a`. Along with this there can also be a filter to show only system containers.\r\n\r\nIt is important to limit the scope to just these two things and nothing fancy or magical.\r\nTo start a system service you'd use the same exact UX/API as a normal container, if you want a volume, then set a volume, if you want API access mount the socket, if you need privileged use `--privileged`\r\nA containerized volume plugin might use this like so:\r\n `docker run -d --system -v /var/myPlugin:/var/data:shared cpuguy83/myAwesomeVolumePlugin`\r\nAgain, nothing fancy.\r\n\r\n***Note that the name of the flag is the best I can come up with, not married to it. Also does not neccessarily have to be a boolean, but I think this helps to limit the scope***"},"comment":{"url":"https://api.github.com/repos/docker/docker/issues/comments/167958135","html_url":"https://github.com/docker/docker/issues/18724#issuecomment-167958135","issue_url":"https://api.github.com/repos/docker/docker/issues/18724","id":167958135,"user":{"login":"jainvipin","id":9005681,"avatar_url":"https://avatars.githubusercontent.com/u/9005681?v=3","gravatar_id":"","url":"https://api.github.com/users/jainvipin","html_url":"https://github.com/jainvipin","followers_url":"https://api.github.com/users/jainvipin/followers","following_url":"https://api.github.com/users/jainvipin/following{/other_user}","gists_url":"https://api.github.com/users/jainvipin/gists{/gist_id}","starred_url":"https://api.github.com/users/jainvipin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jainvipin/subscriptions","organizations_url":"https://api.github.com/users/jainvipin/orgs","repos_url":"https://api.github.com/users/jainvipin/repos","events_url":"https://api.github.com/users/jainvipin/events{/privacy}","received_events_url":"https://api.github.com/users/jainvipin/received_events","type":"User","site_admin":false},"created_at":"2015-12-30T08:41:20Z","updated_at":"2015-12-30T08:41:20Z","body":"+1\r\n\r\n- `docker rm` behavior: accidental removal of these containers can be damaging. Say, I want to remove all app-containers, for which I am used to doing `docker rm -f $(docker ps -aq)` - it might also remove all non system/infra containers. Perhaps the long-term answer would be to have ACLs as suggested by @duglin. It would be best to not show these containers in `docker ps` output all together unless explicitly asked for.\r\n\r\n- starting a infra container later: it is best if order behavior is decoupled from whether it shows up in `docker ps`, etc. because I can think of starting a system/infra service afterwards (like how I can do it with systemd)"}}