App Container spec gains new support as a community-led effort [LWN.net]

App Container spec gains new support as a community-led effort

Posted May 7, 2015 21:31 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: App Container spec gains new support as a community-led effort by dlang
Parent article: App Container spec gains new support as a community-led effort

> the real issue is trying to decouple application run environments from the OS that they are running on, without throwing away a lot of performance (i.e. money) in the process

While this is a nice benefit, this isn't the reason I'm doing it. The problem with deploying applications that you want to know exactly what version is deployed where. Packaging is the first step but applications need to manage ports and run multiple programs which packaging alone can't do easily.

For me the real innovation with Docker is the *scripted deployment of applications* i.e. Dockerfiles. A developer can test on their local machine the exact environment as it will run in production. When a security update needs to be deployed, you kick the buildbot to generate a new image, you can test it and deploy it, replacing the old one. And rollback if it breaks.

So far I haven't found anything as nice for, for example, VM images. I at first thought Vagrantfiles could do it, but they are for controlling the VMs, there's nothing there to help with the creation of images.

So really, standardising the container format is completely uninteresting for me. Send me your Dockerfile and I'll build the image locally using whatever tool (though I guess only Docker understands Dockerfiles). I'm not at the point where I feel I can trust random images downloaded off the internet.

FWIW, I don't see anything about Rocket that resembles Dockerfiles, I hope they're not neglecting that aspect.

to post comments

App Container spec gains new support as a community-led effort

Posted May 10, 2015 3:58 UTC (Sun) by misc (subscriber, #73730) [Link] (1 responses)

> Send me your Dockerfile and I'll build the image locally using whatever
> tool (though I guess only Docker understands Dockerfiles). I'm not at the
> point where I feel I can trust random images downloaded off the internet.

I think there is much more work needed than just getting the dockerfile to reproduce a docker container. As soon as it does something like "gem install foo" or npm, pip, or yum/apt, without exactly pinning the version, you have lost. Now, distributions at least try to keep compatibility in stable releases, but based on my own experience with ruby, this is not something all upstream or developers take in account.

The problem of course is that it work well enough for people to believe that, until this is deployed at scale. That's like race condition. Rather hard to track, work most of the time until suddenly, a mysterious failure happen.

> FWIW, I don't see anything about Rocket that resembles Dockerfiles, I
> hope they're not neglecting that aspect.

You could easily replace that with ansible or puppet ( or others ). The dockerfile format, while not totally horrible, still have some problems IMHO who would make it less than ideal for large scale usage.

For one, you cannot extend it ( no macros like rpm specs, for example ). While this permit to have uniform file accross deploy, it doesn't permit to encode the best practice in a easy way.

Another issue, you cannot parse it easily. Again, something like xml, yaml or json permit to create static analyzer who permit to verify and enforce best practice. Doing so for docker mean you would have to duplicate the parser, against a spec which is (afaik ) not written. Languages like python or specialized DSL like puppet have various tools, most reusing the AST of the compiler ( bandit is one example, puppet-lint is another ). And yes, I realize that it is hard to satisfy having a easy to parse language and being extensible. But here, none is done.

The syntax itself is inspired of one of the most annoying design decision of the rpm specs file, reusing the shell as the mechanism of construction of the system. Note that I said annoying, not bad, because I think you do not have the choice on this. But having specs files as shell scripts with macros make then hard to parse, prevent having nice things like "being able to fully revert a rpm" due to %post being in shell. And arguably make repeatable build harder.

Do not get me wrong, I am quite they didn't had the choice for that, given the legacy we have in term of build scripts all over the place. But like haskell do not have the choice to offer IO functions but explicitly tell this will cause issues, I wonder how much the requirement for running shell snippet could have been reduced.

App Container spec gains new support as a community-led effort

Posted May 12, 2015 7:32 UTC (Tue) by kleptog (subscriber, #1183) [Link]

> I think there is much more work needed than just getting the dockerfile to reproduce a docker container. As soon as it does something like "gem install foo" or npm, pip, or yum/apt, without exactly pinning the version, you have lost.

True. However, most such tools do provide the ability to fix versions and that does work. And you now have a sensible way of building an image against an own hosted PyPI or Apt repository. You still get the benefit of having a single build and being able test in multiple places.

> The dockerfile format, while not totally horrible, still have some problems IMHO who would make it less than ideal for large scale usage.

The Dockerfile format isn't great, it has some nasty corners but it doesn't require any help from the container. The Puppet DSL is nice, but the agent is enormously heavyweight (IMHO) and has versioning issues of its own. Ansible doesn't necessarily require an agent but I find its use of YAML makes things fairly hard to read (but that might get better with practice). There's definitely some innovation required in this area.

Still, I've managed to get several people to write Dockerfiles for various things while I've never really gotten people to write much in the way of Puppet files. So they're doing something right.