We've been using containers rather heavily in our infrastructure for a few years now (neither rocket, nor docker) and we've developed our own toolset to handle the container images, and to manage the containers.
Even though although it kind of deprecates a lot of our work, I really see the value in having a standard that can be used with different container runtimes, and I'll be looking at migrating our internal format to the app container specs. Having tools like this to handle migrations makes a lot of sense to me. We can continue developing our tools, without marrying a specific backend.
We wrote a blog post about running docker containers on it too a while ago: https://blog.terminal.com/docker-without-containers-pulldock...
We're running on (mostly) raw lxc, with networking via openvswitch, cgroups, yada yada. so I don't think it's applicable to us at this point
A containerized world makes a lot of sense, but it still seems like a really young ecosystem. It's really the 'wild west'at this point.
To be honest, I'd rather back an accepted standard, then a specific implementation.
Don't get me wrong, Tools like this are super valuable, and generally make my day to day life easier
Interesting move by CoreOS here to create what will likely be a false dichotomy for docker in the public sphere (as an indicator of their openness). If you truly believe docker is fundamentally flawed you'd be doing your users a disservice writing this. If its transitionary, create your own docker fork/binary instead of a public scene to try to force dockers hand. Lots of fragmentation to come, which sucks because the ecosystem is so important.
As a user, it would be fantastic to run my App Container images on Docker hosts, and Docker images on Rocket hosts.
If only I could move my virtual machine images this easily and avoid high switching costs between platforms.
Shykes > just do it in your own project and let the best project win ... you have to choose one or the other
Bullshit. If it's open, let the best idea win. If this is a bad idea, then let the community examine it and it will lose on the merits.
Don't force me into a false dichotomy.
So are you suggesting docker should merge and maintain support for a container spec they weren't involved with which, was created because docker is "fundamentally flawed"?
I'm sure the pull-request author knew that this would do nothing more than cause fuss in the community. Shykes comment seems to me like it was a response to what seems like a hardly legitimate PR and much like a PR stunt.
Docker has 722 contributors on github, I'm sure the community will discuss and decide what to do with this while I watch this battle play out and work with both products.
Don't get me wrong, I think it's great the coreos guys are trying to make a bridge between the two projects, but so far, I don't see a need for this.
I really hope this lands and something constructive can come out of it. There is a lot more that can be gained by these communities working together and not promoting divisiveness.
Adding a PR with working code was simply to show that adding this feature is something that is possible. It is OK if nothing from this implementation gets merged.
Gained by who though? These are for-profit enterprises and there are real-money gains involved in controlling the spec. For better or worse, CoreOS controls the App Container spec and make no mistake that the primary reason they want it in Docker is because it benefits them. This of course does not exclude the possibility that users benefit.
Still, I'm of the opinion that all of this fighting behind the scenes (which, if you've been paying attention, this is) is kind of bad for everyone and a waste of resources.
But I think that this VC-backed model might not be beneficial for OS as a business in the mid-long term. The race to $0 is greatly accelerated.
However, after reading "This is a simple functional PR..." in the blog post, I was surprised to see the PR adds over 38k lines of code. Seems like that will take a while to review.
Don't get me wrong, I totally see how this is good for Rocket, just be honest and admit the "fundamentally flawed" argument was mainly smoke and mirrors to justify a defensive-offensive move by a VC-backed, for-profit company launched against another VC-backed, for-profit company.
Again nothing wrong with that, it's business and in fact a good move but in my eyes CoreOS lost quite some trust when they tried to potray Rocket as a selfless act of kindness towards the community that needed to be saved.
There are things in the App Container spec that we would like to see in Docker, this is why we put in the work to make a spec, write the code to make it work and start a technical discussion. This has been the goal since the beginning. The problems that exist in the current Docker Engine that we would like to address are technical and real:
1) We believe in having a decentralized and user controlled signing mechanism. In the appc specification and rocket we use the DNS federated namespace. See the `rkt trust` subcommand and the signing section of the ACI spec.
2) We believe that image IDs should be backed by a cryptographic identity. It should be possible for a user to say: "run container `sha512-abed`" and have the result be identical on every machine because it is backed by a cryptographic hash.
In rocket another thing we wanted to do was enable running the download/import steps outside of being a root user. For example today you can download and import an image from disk in the native ACI format with rkt. And in the next release `rkt fetch` will be runnable as a user in the same unix group as `/var/lib/rkt/`.
Not sure I want containers to be successful (unless of course the main business is building and marketing containers). I want my problem solved but whether they are solved with containers, mocks, jails, VMs, and so on doesn't matter as much.
As container runtimes Rocket and Docker have different design goals though. As one example, Rocket is designed to be a standalone tool that can run without a daemon and works with existing init systems like upstart, systemd and sysv. We needed this standalone property because on CoreOS containers are our package manager and the daemon can get in the way of doing that correctly.
It is ok that Docker and Rocket have different design goals and both can exist for different purposes. But, I think we can share and converge on an image format that can be used by multiple implementations that includes cryptographically verifiable images, simple hosting on object stores and the use of a federated DNS based namespace for container names.
The federated nature of image identity that CoreOS is pushing for is a direct challenge to the special status that Docker has given index.docker.io, and that they have been strongly resisting attempts to change.
I don't care much if Rocket or Docker "wins", but I really hope the App Container federated approach does.
