8 ms·

Docker 1.2.0, with restart policies

187 points by julien421 12y ago

abraham_s 12y ago
Any idea when AWS Elastic BeanStalk will start supporting this version?
waffle_ss 12y ago
This is excellent news. The lack of a container restart policy was the main reason why I was spending a bunch of time learning CoreOS and fleet. Trying to get CoreOS installed on VPS providers is a huge pain[0], and fleet and etcd are technically not labelled as production-ready (only CoreOS used as a base OS is)[1], so I'm really glad I can go back to vanilla Docker. [0]: http://serverfault.com/a/620513/85897 http://serverfault.com/a/620513/85897 [1]: https://coreos.com/blog/stable-release/ https://coreos.com/blog/stable-release/
- deleted 12y ago
  [deleted]
- deleted 12y ago
  [deleted]
- Alupis 12y ago
  > I was wasting a bunch of time learning CoreOS I'm pretty sure CoreOS and Docker are different solutions to different problems. So... one is not really inter-changeable with another, and thus you were not "wasting" your time. So, perhaps you didn't understand the problem you were trying to solve? Docker is about application environment isolation/portability (not! virtualization! -- there is no security provided here), where CoreOS is about scaling and HA.
  - waffle_ss 12y ago
    You're right, "wasting" was really harsh - edited. I do think it's a valuable skill to have and I didn't waste my time, I just spent it. However, right now I don't have a Mesos-type of cluster with a bunch of horizontally scalable services that would truly benefit from CoreOS, Consul, etc. I've got three basic services that are going to be pinned to specific boxes. I don't need an elastic scaling solution right now - I just need container restarting, and I'll handle provisioning and upgrades myself with Ansible. Basically I don't have cattle right now, I have kittens. I had been looking for a way to manage my containers with the usual supervisors - supervisord, systemd, etc., but didn't see any resources on anyone else doing it. After I started adding systemd on the host to manage container restarts, and a playbook for managing Docker daemon upgrades, I started to feel like I was re-inventing CoreOS, so I gravitated towards it. CoreOS also has other benefits like being a minimal Docker host and providing the distributed configuration with etcd so it seemed like a good idea. But to fit within that paradigm I had to start re-wiring my images to be horizontally scalable. Then I ran into the problem of how hard it was to just get CoreOS installed on Linode, and got frustrated. I didn't mean to knock CoreOS or anything, I'm just saying this solved a use case problem I've been having. I'm sure if I spent more time with CoreOS I would have gotten everything working correctly, but at this point I'm just trying to run my multi-host Docker application in a stable way without doing the whole horizontally scalable cluster thing.
  - nl 12y ago
    there is no security provided here Actually there is plenty of security[1]. It may not be "as secure" as a traditional virtualization platform, but that doesn't mean Docker/containers don't have plenty of capabilities (ha!) to offer in terms of security. You need to understand what they offer, but the old "Docker isn't secure" thing is not more truthful than "Docker is a security solution". Security is a continuum, and Docker has some very interesting security uses. I've already linked to [1], but I'd encourage all to read it. [1] http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applications-in-linux-containers http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applica...
- toomuchtodo 12y ago
  Etcd isn't consisdered production grade?
  - omglol 12y ago
    Well, Docker just slapped a "1.0" sticker on and called itself "production ready" when it clearly wasn't (features like in this 1.2 release are kind of mandatory for any serious deployments).
    - cpuguy83 12y ago
      You could already do these things outside of dockerland via the host-integration stuff (ie, systemd to handle restarts/monitoring). 1.0 was/is about API stability, engine stability, full ecosystem with Docker Hub, and enterprise support.
      - fidlefodl 12y ago
        Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.
        cpuguy83 12y ago
        FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc. So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.
        mattes 12y ago
        > it will get the same IP as well. Not for me. Just tested it.
- lsllc 12y ago
  Try Vultr, they support CoreOS (and FreeBSD!). https://coreos.com/docs/running-coreos/cloud-providers/vultr/ https://coreos.com/docs/running-coreos/cloud-providers/vultr...
shykes 12y ago
Hi all, no World-changing features in this one, but we believe that over time, relentless incremental improvements can make a huge difference. This week we are freezing all feature merges and focusing on refactoring, code cleanup and generally repaying as much technical debt as possible. We are also considering a gradual slowdown of the release cadence (we currently cut a release every month), to give more time for QA. Even though we work hard to keep master releasable at all times and run every merge through the full test suite, in practice there can never be enough real-world testing before a release. An 8-week cycle (which is roughly what Linux does) would allow us to freeze the release 1-2 weeks in advance and do more aggressive QA.
- nathankleyn 12y ago
  You guys are doing a fantastic job, anything that can give you a bit more of a breather between releases and increase quality is something I'm certain the community will embrace.
- omglol 12y ago
  This seems to be the real 1.0 release...
- prudhvis 12y ago
  Are you kidding?. Ability to modify /etc/hosts and specifying exact Capabilities is awesome. Thanks for the great work. I for one waited very long for this :)
  - simonebrunozzi 12y ago
    Hi Solomon! I agree with prudhvis here - I think this is quite a nice add! Keep up the good work!
  - darklajid 12y ago
    Now that needs to be possible in docker build: https://github.com/docker/docker/issues/1916 https://github.com/docker/docker/issues/1916 That said, yes this release looks interesting!
jijojv 12y ago
Writable `/etc/hosts`, `/etc/resolv.conf` is huge - no more local dns hacks.
- shykes 12y ago
  Yeah that one was super-high on the request list, there were 3 competing patches before we finally got it right.
  - knite 12y ago
    Why is this not supported during docker build? I'm not very familiar with the --privileged flag - isn't that only related to sharing on the host? Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.
    - shykes 12y ago
      I think it is supported. The feature we are discussing allows the container to change its own resolv/host files, from the inside. I'm pretty sure that works from build also. But it's possible that I missed one of the patches (a sign of healthy autonomy and trust between maintainers).
      - knite 12y ago
        Hm...this sounds like a bit of a disconnect from the 1.2 announcement post, which says: "Note, however, that changes to these files are not saved during a docker build and so will not be preserved in the resulting image. The changes will only “stick” in a running container." If I do RUN echo "127.0.0.1 somehost" >> /etc/hosts or COPY container_hosts /etc/hosts, according to the announcement wording, this will not persist in my image. If this is incorrect, could you clarify what isn't saved during docker build? If this is correct, why is docker build unable to retain these changes?
        shykes 12y ago
        Ah, you are correct. Every container can now modify its own /etc/resolv.conf and /etc/hosts, but these changes are not kept when a new image is committed from the filesystem of that container. Even if they were committed, the runtime would overwrite them when creating a new container (Docker continues to inject initial values into these files to provide a predictable networking environment to the application). Now, in its current implementation "docker build" commits an intermediary image after each build step. These intermediary images are used by the build cache, to speed up successive builds. These intermediary images are created in exactly the same way as every other image - which means the same rules apply for /etc/resolv.conf and /etc/hosts. An unfortunate side effect is that changes to these files are not shared between build steps. We can solve this in a future version (or even a hotfix if necessary). A relatively quick stopgap would be for "docker build" to copy these files across build steps. The long-term solution is to no longer commit a full-blown intermediary image at each build step, but instead to use a snapshotting facility more tailored to the needs of the build caching system. While we're at it we can make sure it preserves /etc/hosts and /etc/resolv.conf. Sorry for the inconvenience, I hope the explanation helps.
charford 12y ago
Any update on when the OS X version will be available? I'm only seeing version 1.1.2 here: https://github.com/boot2docker/osx-installer/releases https://github.com/boot2docker/osx-installer/releases
- tachion 12y ago
  And anything related to FreeBSD Jail support? :)
  - Alupis 12y ago
    Docker != Jails (not in any way, shape, nor form). Please stop trying to make Docker into everything it's not.
    - scott_karana 12y ago
      Docker currently uses LXC. Isn't it reasonable to suggest porting it to other jail-solutions?
      - Alupis 12y ago
        Well, simplifying here, but Docker is more-or-less a fancy wrapper for LXC. FreeBSD Jails do a lot more than just make applications portable -- they provide security and isolation between applications (like a super chroot). Jails can be used to safely provide application hosting for various clients while Docker should only be used for your applications (jails prevent clients from messing with the host system nor each other, while Docker applications can, making it not secure for a multiple-client hosted system -- but then again, it was not designed to do that). So, no, it's not reasonable to want to "port" Docker to anything since Docker is it's own thing. It would be more reasonable to port docker to FreeBSD (it it weren't already) than to say to "port" it to a Jail, or request it operate like a Jail (unless you got those features into LXC first, which LXC isn't, and therefore it wont). ~ A better (but admittedly over-simplified) comparison would be Jails are closer to application virtualization and Docker is closer to application portability. Very different problems they are solving.
troym 12y ago
Maybe a bit off-topic. I haven't found a satisfactory solution to having communicating containers across multiple hosts. There seems to be quite a few solutions in the making (libswarm, geard, etc). How are other people solving this (in production, beyond two or three hosts)?
- Alupis 12y ago
  CoreOS seems to do what you are asking.
- cpuguy83 12y ago
  https://github.com/cpuguy83/docker-grand-ambassador https://github.com/cpuguy83/docker-grand-ambassador https://github.com/progrium/ambassadord https://github.com/progrium/ambassadord
  - troym 12y ago
    Interesting, thanks! FWIW, ambassadord has consul integration and that's something I've wanted.
- ivix 12y ago
  I simply expose ports (or do --net=host) and communicate between hosts in the normal fashion. Unless you don't trust your host I don't see the problem with that.
frik 12y ago
How to deal with persistent storage (e.g. databases) in Docker 1.2? is this info up-to-date? http://stackoverflow.com/questions/18496940/how-to-deal-with-persistent-storage-e-g-databases-in-docker http://stackoverflow.com/questions/18496940/how-to-deal-with...
- cpuguy83 12y ago
  Yes, no changes here.
- alexandre_m 12y ago
  Check Flocker https://github.com/ClusterHQ/flocker https://github.com/ClusterHQ/flocker
- hipsters_unite 12y ago
  Mountable volumes and data containers works for us in staging atm, you can easily spin up single task dockers to pull that out, tar it up and send to S3 as a backup regime as well.
antocv 12y ago
Oh this is juuuust great. /sarcasm. So now docker is taking on the work of what systemd and other daemon-managers are supposed to solve? Looking forward to docker run --restart on-failure ubuntu /bin/bash exit -1 When you include a --restart "feature" you know for sure you have don goofed. But anyway, the rest of the stuff looks like pure candy. Great job!
- knickle 12y ago
  1) Then don't use it in your scripts. 2) Restart policies are exposed in the API, so daemon managers can leverage this feature to hook in their own restart policies in a consistent, supported way.
- sciurus 12y ago
  There's definitely feature overlap, and there are still problems running docker via systemd as show by the existence of workarounds like https://github.com/ibuildthecloud/systemd-docker https://github.com/ibuildthecloud/systemd-docker
IanCal 12y ago
I'm not sure about how I feel about this (edit - restart policies). It's cool, but seems to ignore what the OTP part of erlang development learned. They've already gone to "X number of restarts = failure" but with no time involved. There's also no hierarchy, which is where you really start to get the benefits. While great, I worry that this is a part-solution that will delay the implementation of a proper one.
- michaelneale 12y ago
  You can happily use containers supervised by systemd in a hierarchy like any other process if you like.
- cpuguy83 12y ago
  1) We do degrade restarts over time. 2) There is hierarchy (so it will start linked containers).
  - IanCal 12y ago
    Perhaps I'm being a bit harsh. > 1) We do degrade restarts over time. Is this adjustable? X restarts in Y seconds? I feel this is something that could be quite application specific. > 2) There is hierarchy (so it will start linked containers). So if A has a link to B, will A be restarted if B is restarted? I'd be aiming to build hierarchies with restart strategies like these: http://www.erlang.org/doc/design_principles/sup_princ.html http://www.erlang.org/doc/design_principles/sup_princ.html
    - cpuguy83 12y ago
      1) I know you can specify the number of restarts, not sure yo can specify the gradual decay of the restarts 2) No, this is not the goal of the restart policies. I think this would be best implemented by something watching the docker event stream.
LunaSea 12y ago
Is it possible yet to build and "RUN" multiple sublayers inside the same Dockerfile ?

187 points by julien421 12y ago

Any idea when AWS Elastic BeanStalk will start supporting this version?

This is excellent news. The lack of a container restart policy was the main reason why I was spending a bunch of time learning CoreOS and fleet. Trying to get CoreOS installed on VPS providers is a huge pain[0], and fleet and etcd are technically not labelled as production-ready (only CoreOS used as a base OS is)[1], so I'm really glad I can go back to vanilla Docker. [0]: http://serverfault.com/a/620513/85897 http://serverfault.com/a/620513/85897 [1]: https://coreos.com/blog/stable-release/ https://coreos.com/blog/stable-release/

deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
Alupis 12y ago
> I was wasting a bunch of time learning CoreOS I'm pretty sure CoreOS and Docker are different solutions to different problems. So... one is not really inter-changeable with another, and thus you were not "wasting" your time. So, perhaps you didn't understand the problem you were trying to solve? Docker is about application environment isolation/portability (not! virtualization! -- there is no security provided here), where CoreOS is about scaling and HA.
- waffle_ss 12y ago
  You're right, "wasting" was really harsh - edited. I do think it's a valuable skill to have and I didn't waste my time, I just spent it. However, right now I don't have a Mesos-type of cluster with a bunch of horizontally scalable services that would truly benefit from CoreOS, Consul, etc. I've got three basic services that are going to be pinned to specific boxes. I don't need an elastic scaling solution right now - I just need container restarting, and I'll handle provisioning and upgrades myself with Ansible. Basically I don't have cattle right now, I have kittens. I had been looking for a way to manage my containers with the usual supervisors - supervisord, systemd, etc., but didn't see any resources on anyone else doing it. After I started adding systemd on the host to manage container restarts, and a playbook for managing Docker daemon upgrades, I started to feel like I was re-inventing CoreOS, so I gravitated towards it. CoreOS also has other benefits like being a minimal Docker host and providing the distributed configuration with etcd so it seemed like a good idea. But to fit within that paradigm I had to start re-wiring my images to be horizontally scalable. Then I ran into the problem of how hard it was to just get CoreOS installed on Linode, and got frustrated. I didn't mean to knock CoreOS or anything, I'm just saying this solved a use case problem I've been having. I'm sure if I spent more time with CoreOS I would have gotten everything working correctly, but at this point I'm just trying to run my multi-host Docker application in a stable way without doing the whole horizontally scalable cluster thing.
- nl 12y ago
  there is no security provided here Actually there is plenty of security[1]. It may not be "as secure" as a traditional virtualization platform, but that doesn't mean Docker/containers don't have plenty of capabilities (ha!) to offer in terms of security. You need to understand what they offer, but the old "Docker isn't secure" thing is not more truthful than "Docker is a security solution". Security is a continuum, and Docker has some very interesting security uses. I've already linked to [1], but I'd encourage all to read it. [1] http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applications-in-linux-containers http://www.slideshare.net/jpetazzo/is-it-safe-to-run-applica...
toomuchtodo 12y ago
Etcd isn't consisdered production grade?
- omglol 12y ago
  Well, Docker just slapped a "1.0" sticker on and called itself "production ready" when it clearly wasn't (features like in this 1.2 release are kind of mandatory for any serious deployments).
  - cpuguy83 12y ago
    You could already do these things outside of dockerland via the host-integration stuff (ie, systemd to handle restarts/monitoring). 1.0 was/is about API stability, engine stability, full ecosystem with Docker Hub, and enterprise support.
    - fidlefodl 12y ago
      Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.
      - cpuguy83 12y ago
        FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc. So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.
        mattes 12y ago
        > it will get the same IP as well. Not for me. Just tested it.
lsllc 12y ago
Try Vultr, they support CoreOS (and FreeBSD!). https://coreos.com/docs/running-coreos/cloud-providers/vultr/ https://coreos.com/docs/running-coreos/cloud-providers/vultr...

shykes 12y ago

Hi all, no World-changing features in this one, but we believe that over time, relentless incremental improvements can make a huge difference. This week we are freezing all feature merges and focusing on refactoring, code cleanup and generally repaying as much technical debt as possible. We are also considering a gradual slowdown of the release cadence (we currently cut a release every month), to give more time for QA. Even though we work hard to keep master releasable at all times and run every merge through the full test suite, in practice there can never be enough real-world testing before a release. An 8-week cycle (which is roughly what Linux does) would allow us to freeze the release 1-2 weeks in advance and do more aggressive QA.

nathankleyn 12y ago
You guys are doing a fantastic job, anything that can give you a bit more of a breather between releases and increase quality is something I'm certain the community will embrace.
omglol 12y ago
This seems to be the real 1.0 release...
prudhvis 12y ago
Are you kidding?. Ability to modify /etc/hosts and specifying exact Capabilities is awesome. Thanks for the great work. I for one waited very long for this :)
- simonebrunozzi 12y ago
  Hi Solomon! I agree with prudhvis here - I think this is quite a nice add! Keep up the good work!
- darklajid 12y ago
  Now that needs to be possible in docker build: https://github.com/docker/docker/issues/1916 https://github.com/docker/docker/issues/1916 That said, yes this release looks interesting!

jijojv 12y ago

Writable `/etc/hosts`, `/etc/resolv.conf` is huge - no more local dns hacks.

shykes 12y ago
Yeah that one was super-high on the request list, there were 3 competing patches before we finally got it right.
- knite 12y ago
  Why is this not supported during docker build? I'm not very familiar with the --privileged flag - isn't that only related to sharing on the host? Edits to /etc/hosts in a container don't affect the host, so it seems like everything should Just Work.
  - shykes 12y ago
    I think it is supported. The feature we are discussing allows the container to change its own resolv/host files, from the inside. I'm pretty sure that works from build also. But it's possible that I missed one of the patches (a sign of healthy autonomy and trust between maintainers).
    - knite 12y ago
      Hm...this sounds like a bit of a disconnect from the 1.2 announcement post, which says: "Note, however, that changes to these files are not saved during a docker build and so will not be preserved in the resulting image. The changes will only “stick” in a running container." If I do RUN echo "127.0.0.1 somehost" >> /etc/hosts or COPY container_hosts /etc/hosts, according to the announcement wording, this will not persist in my image. If this is incorrect, could you clarify what isn't saved during docker build? If this is correct, why is docker build unable to retain these changes?
      - shykes 12y ago
        Ah, you are correct. Every container can now modify its own /etc/resolv.conf and /etc/hosts, but these changes are not kept when a new image is committed from the filesystem of that container. Even if they were committed, the runtime would overwrite them when creating a new container (Docker continues to inject initial values into these files to provide a predictable networking environment to the application). Now, in its current implementation "docker build" commits an intermediary image after each build step. These intermediary images are used by the build cache, to speed up successive builds. These intermediary images are created in exactly the same way as every other image - which means the same rules apply for /etc/resolv.conf and /etc/hosts. An unfortunate side effect is that changes to these files are not shared between build steps. We can solve this in a future version (or even a hotfix if necessary). A relatively quick stopgap would be for "docker build" to copy these files across build steps. The long-term solution is to no longer commit a full-blown intermediary image at each build step, but instead to use a snapshotting facility more tailored to the needs of the build caching system. While we're at it we can make sure it preserves /etc/hosts and /etc/resolv.conf. Sorry for the inconvenience, I hope the explanation helps.

charford 12y ago

Any update on when the OS X version will be available? I'm only seeing version 1.1.2 here: https://github.com/boot2docker/osx-installer/releases https://github.com/boot2docker/osx-installer/releases

tachion 12y ago
And anything related to FreeBSD Jail support? :)
- Alupis 12y ago
  Docker != Jails (not in any way, shape, nor form). Please stop trying to make Docker into everything it's not.
  - scott_karana 12y ago
    Docker currently uses LXC. Isn't it reasonable to suggest porting it to other jail-solutions?
    - Alupis 12y ago
      Well, simplifying here, but Docker is more-or-less a fancy wrapper for LXC. FreeBSD Jails do a lot more than just make applications portable -- they provide security and isolation between applications (like a super chroot). Jails can be used to safely provide application hosting for various clients while Docker should only be used for your applications (jails prevent clients from messing with the host system nor each other, while Docker applications can, making it not secure for a multiple-client hosted system -- but then again, it was not designed to do that). So, no, it's not reasonable to want to "port" Docker to anything since Docker is it's own thing. It would be more reasonable to port docker to FreeBSD (it it weren't already) than to say to "port" it to a Jail, or request it operate like a Jail (unless you got those features into LXC first, which LXC isn't, and therefore it wont). ~ A better (but admittedly over-simplified) comparison would be Jails are closer to application virtualization and Docker is closer to application portability. Very different problems they are solving.

troym 12y ago

Maybe a bit off-topic. I haven't found a satisfactory solution to having communicating containers across multiple hosts. There seems to be quite a few solutions in the making (libswarm, geard, etc). How are other people solving this (in production, beyond two or three hosts)?

Alupis 12y ago
CoreOS seems to do what you are asking.
cpuguy83 12y ago
https://github.com/cpuguy83/docker-grand-ambassador https://github.com/cpuguy83/docker-grand-ambassador https://github.com/progrium/ambassadord https://github.com/progrium/ambassadord
- troym 12y ago
  Interesting, thanks! FWIW, ambassadord has consul integration and that's something I've wanted.
ivix 12y ago
I simply expose ports (or do --net=host) and communicate between hosts in the normal fashion. Unless you don't trust your host I don't see the problem with that.

frik 12y ago

How to deal with persistent storage (e.g. databases) in Docker 1.2? is this info up-to-date? http://stackoverflow.com/questions/18496940/how-to-deal-with-persistent-storage-e-g-databases-in-docker http://stackoverflow.com/questions/18496940/how-to-deal-with...

cpuguy83 12y ago
Yes, no changes here.
alexandre_m 12y ago
Check Flocker https://github.com/ClusterHQ/flocker https://github.com/ClusterHQ/flocker
hipsters_unite 12y ago
Mountable volumes and data containers works for us in staging atm, you can easily spin up single task dockers to pull that out, tar it up and send to S3 as a backup regime as well.

antocv 12y ago

Oh this is juuuust great. /sarcasm. So now docker is taking on the work of what systemd and other daemon-managers are supposed to solve? Looking forward to docker run --restart on-failure ubuntu /bin/bash exit -1 When you include a --restart "feature" you know for sure you have don goofed. But anyway, the rest of the stuff looks like pure candy. Great job!

knickle 12y ago
1) Then don't use it in your scripts. 2) Restart policies are exposed in the API, so daemon managers can leverage this feature to hook in their own restart policies in a consistent, supported way.
sciurus 12y ago
There's definitely feature overlap, and there are still problems running docker via systemd as show by the existence of workarounds like https://github.com/ibuildthecloud/systemd-docker https://github.com/ibuildthecloud/systemd-docker

IanCal 12y ago

I'm not sure about how I feel about this (edit - restart policies). It's cool, but seems to ignore what the OTP part of erlang development learned. They've already gone to "X number of restarts = failure" but with no time involved. There's also no hierarchy, which is where you really start to get the benefits. While great, I worry that this is a part-solution that will delay the implementation of a proper one.

michaelneale 12y ago
You can happily use containers supervised by systemd in a hierarchy like any other process if you like.
cpuguy83 12y ago
1) We do degrade restarts over time. 2) There is hierarchy (so it will start linked containers).
- IanCal 12y ago
  Perhaps I'm being a bit harsh. > 1) We do degrade restarts over time. Is this adjustable? X restarts in Y seconds? I feel this is something that could be quite application specific. > 2) There is hierarchy (so it will start linked containers). So if A has a link to B, will A be restarted if B is restarted? I'd be aiming to build hierarchies with restart strategies like these: http://www.erlang.org/doc/design_principles/sup_princ.html http://www.erlang.org/doc/design_principles/sup_princ.html
  - cpuguy83 12y ago
    1) I know you can specify the number of restarts, not sure yo can specify the gradual decay of the restarts 2) No, this is not the goal of the restart policies. I think this would be best implemented by something watching the docker event stream.

LunaSea 12y ago

Is it possible yet to build and "RUN" multiple sublayers inside the same Dockerfile ?