Rocket and App Container 0.2.0 Release

https://coreos.com/blog/rocket-and-appc-0.2.0/

151 33 12 years ago

Alupis5• 12 years ago

Very exciting to see multiple App Container Spec implementations showing up this quickly!

This last week has also seen the emergence of two different implementations of the spec: jetpack (a FreeBSD/Jails-based executor) and libappc (a C++ library for working with app containers). The authors of both projects have provided extremely helpful feedback and pull requests to the spec, and it is great to see these early implementations develop!

I think this is really telling of a great (and necessary) thing. Standardizing a container specification was long overdue; a standard and portable app container spec will really propel containerization to the next level.

shykes5• 12 years ago

Here's the open specification for Docker's standard format: https://github.com/docker/docker/blob/master/image/spec/v1.m...

Alupis5• 12 years ago

Curious why you think it's OK to try stealing the thunder of CoreOS' announcement?

Based on me and your previous encounters, I'd wager you would flip your lid if they did the same to you.

The Docker "standard" format was brewed up overnight immediately following the App Container Specification announcement and has had only spelling fixes since then. I'm not aware of any other implementations of the Docker format other than Docker itself.

lclarkmichalek3• 12 years ago

Let's not start this war in this article please. What else do you think shykes wants, other than to make ACI impossible to discuss outside a Docker context? We can still have our regular scheduled ACI vs Docker flamewars, but let's not derail _every_ thread with them, thanks.

shykes5• 12 years ago

My understanding is that Docker's lack of an open specification was advertised as a primary motivation for rocket. So it seemed relevant to point out efforts by Docker to provide such a specification.

The reason the specification document isn't moving very fast is simply that it's stable and already deployed at large scale, via Docker's implementation.

jsprogrammer2• 12 years ago

I don't see any thunder being stolen here.

michaelcampbell• 12 years ago

Curious why you think it's OK to try stealing the thunder of CoreOS' announcement?

Because "thunder" isn't a protected resource or asset?

alexatkeplar• 12 years ago

Your "Image JSON Schema" section isn't a JSON Schema - it's an example JSON plus a set of textual descriptions only readable by humans. Versioned machine-readable JSON Schema is the way to go for specs. This is a great guide to get started: http://spacetelescope.github.io/understanding-json-schema/

philips• 12 years ago

Yea, I absolutely want to make the spec a schema once we get further along. We would have done it from the beginning but it makes discussing the spec a lot harder since it raises the bar from "I understand JSON syntax" to "I understand JSON and JSON Schema". In any case I am a huge JSON schema fan, we use it in a number of APIs to make client bindings code generated. For example: https://github.com/coreos/fleet/blob/master/schema/v1.json

Update: Sorry, I thought you were taking a look at the appc spec, would appreciate your feedback on appc too.

jlhawn• 12 years ago

Hi. I'm the original author of the aforementioned docker image spec document.

Sorry for the confusion. I had not known that "JSON Schema" was a commonly used term like this.

Thank you for bringing this to my attention. I've just opened a pull request on the docker github repo to use a different word for the title of this section [1]. In the context of docker images, the term "Image JSON" is commonly used to mean the image metadata JSON file. This section was titled "Image JSON Schema" not to say that it is a "JSON Schema". Rather, I used the word "Schema" more generically here to mean that this section is an outline/description for the format of this file.

I also agree that this thread is not an appropriate place to discuss the docker image format. If you have any feedback or questions related to it, please open an issue on the github repository, ping me, and I'll gladly help.

[1] https://github.com/docker/docker/pull/10333

druiid2• 12 years ago

We've been investigating beginning usage of containerization instead of just virtualization. The responses here and in other threads about the CoreOS announcement that you have made have completely turned me away from wanting to work with your technology. This is the kind of behavior in the tech community that I find abhorrent. Even competitors have something to learn from and offer. Rocket or just plain LXC are now my first choices.

tameir• 12 years ago

Solomon, in case it's not clear why people are upset, I'll spell it out:

1) You're lashing out at the very community that supports you. Instead of listening, seeing problems, and changing, you constantly dump the blame on your users and partners for the sake of your ego. If there's a communication problem you need to realize it's your fault and your responsibility to remedy it. Your users aren't being paid millions to make Docker work. You are.

2) This spec is clearly half-assed and intended to shut people up, not actually move anything forward. You and I know that nobody is going to do anything with this spec, because there's no reason to think it won't be broken by a change in Docker core tomorrow.

I don't even think a spec is necessary here: what Docker needs is options. By which, I mean Docker needs to be sliced up into small enough, simple enough pieces that you don't need some huge slapped-together ad-hoc spec to take Docker apart and adapt the guts to your needs.

This isn't an open specification, this is a bible from the Docker gods dictating the container commandments, which are subject to change when Zeus gets pissed. Please know the difference. Worse, at the end of the "spec" is an apology of its existence, making it clear that the intention isn't to listen to people but to tell them how it is.

3) I know this puts Docker in a tough place as a business, but everyone's getting the impression you're forsaking the early adopters and hackers that got Docker off the ground in the first place. This is somewhat ironic: you reminisce about the good ol' days of HN when it was about hackers building things, when it seems the company's goals have shifted away from actually building things to shutting up the proles and supporting enterprise interests like locking everything down and keeping things stable because big bucks are paying to keep it that way. If that's where Docker wants to go, your perogative, but I don't know why you're surprised that the grassroots hackers you're abandoning are turning on you.

shykes5• 11 years ago

Hi Tameir, thanks for taking the time for a thoughtful response. I disagree with many of your points and would like to offer a different perspective, could I interest you in a civil email conversation? You can reach me anytime at solomon@docker.com.

bsaul• 12 years ago

As much as i love the fact that a successful's company's founder takes the time to answer personnaly about his technology on HN, i've noticed that your recent interventions here had counter-productive effects.

You should probably ask other people ( external to your company) to double check what you're about to publish and post, because it can sometimes be very hard to be objective, and correctly guess how people are going to react.

Note : i don't have anything to do with coreos or docker or any kind of related tech.

lclarkmichalek3• 12 years ago

"we've taken care to implement these lifecycle-related subcommands without introducing additional daemons or databases" oh I love you rocket. I mean, I'd be scared to implement that myself (FS based concurrency control always seems hellish), but I guess that's the joy of ACI; I can just use another implementation if you scare me too much.

Reading the signing and verification stuff, the section on "Distributing Images via Meta Discovery" reminded me of my personal dream: bittorrent based distribution. How hard would this be? Seeing as the ACI tarballs seem to be just stored on disk, would it simply be a case of telling my bittorrent client to dump all my ACIs in some folder and then getting rocket to look there? Or is there a need to write some kind of rocket plugin for that kind of thing?

robszumski• 12 years ago

Bitorrent was mentioned in the original blog post as a nice to have feature in the future:

Image distribution. Discovery of container images should be simple and facilitate a federated namespace, and distributed retrieval. This opens the possibility of alternative protocols, such as BitTorrent, and deployments to private environments without the requirement of a registry.

There is an open issue if you want to help out or follow along: https://github.com/coreos/rocket/issues/405

lclarkmichalek3• 12 years ago

Subscribed, though I was thinking of it rather more generically: how hard would it be to have some service that magically puts images in the correct place, and have rocket look there? The idea of rocket having a bittorrent client on board rather scares me :)

sant0sk1• 12 years ago

We just published a conversation with Alex Polvi (CoreOS CEO) all about Rocket and the App Container Spec. Check it out if you want to hear more:

http://thechangelog.com/138

bayesianhorse• 12 years ago

Another announcement about containers went largely unnoticed: Ubuntu released Ubuntu Core, a Ubuntu variant optimized for cloud and IoT security. But the documentation and developer adoption seems to be behind CoreOs currently.

I haven't done anything with CoreOs yet, but from my personal feeling I'd prefer Ubuntu over something that is based on Gentoo. I may be completely wrong on this though.

therealmarv• 12 years ago

I also not a guru but I've been locking on Ubuntu Core and it seems even more simplistic than Core OS. The great thing on Core OS is the etcd (for exchanging key values across clusters) and fleet (for managing e.g. containers on systemd and etcd). So Core OS has better management tools for things like Docker. Ubuntu Core is missing both parts and it seems better for embedded systems than for cluster management IMHO. And many people are using Ubuntu INSIDE the container. CoreOS is a good minimal layer... no need to have Ubuntu there... also Ubuntu Core does not have tools like apt-get ;)

damm• 11 years ago

If you are 100% Containers (Rocket, Docker, etc) the Base OS matters the least. From that you should be concerned about security upgrades to the base OS.

But having another layer of complexity where people run half Docker Half Snowflake will eventually burn you like running MongoDB with MySQL on the same ec2 instance.

Rocket and App Container 0.2.0 Release

Related Stories