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.
"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?
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.
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 :)
There are certainly a few ways this could work; for example, since Rocket currently uses a generic CAS backend to store assets, and is designed to expect multiple simultaneous invocations (using filesystem locking etc), it's feasible for an external service to be pulling down images out of band that Rocket could then consume.
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.
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 ;)
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.
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.
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.
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.
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.
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.
> The reason the specification document isn't moving very fast is simply that it's stable
Say's who? To my knowledge, nobody has attempted to build a container platform using the docker spec. For all anyone knows, there's large gaping logic holes needing to be filled. It's simply untested and unproven.
> and already deployed at large scale, via Docker's implementation.
I think you mean to say "Docker is deployed", because again, nobody has tried to implement the docker spec as-of yet.
The docker team spent so long actively avoiding introducing any sort of standardized container specification out of fear someone would come along and eat docker's lunch, that it's hard to believe miraculously overnight you were able to develop a rock-solid specification that clearly addresses all scenarios and is extensible for any 3rd party to implement cleanly.
The docker spec technically has zero implementations, since it was only created (overnight) as an afterthought after your "implementation" was already completed. If anything, the docker spec is an (untested) implementation of docker.
As-of today, the App Container Specification has 3 times more implementations than the docker spec, has far greater adoption, has been refined more significantly over multiple iterations, and has accepted far more community input into it's development.
Let's be genuine here shykes. Your purpose in this thread is to get people talking about docker and cast some shade on the CoreOS team. The very thing you got so upset about when they first announced Rocket and the App Container Specification.
I'm not sure what to reply in the face of so much bile. Hacker News used to be the home of people who built cool stuff and wanted to show it to each other. Now it's the home of people like you. Docker and CoreOS might be competitors, and we might disagree on many things (ethics in particular), but at least we're both building things and sharing them with others. That's our contribution to this community. What's yours?
I have no foot in either game here (not sure about the parent commenter to this response), so hopefully you'll take this as a suggestion and not an attack... You are being part of the problem here. HN can only maintain the kind of relationship with commenters and posters that you talk about if as someone in the tech industry, you don't attack your competitors. Doing so brings you to the same standing as the kinds of people commenting that you say are ruining the site.
I've seen you post several times all in regards to this CoreOS stuff and NONE of it has been constructive. I think you need to take a step back and understand that HN is a public facing site and that the things you say here have a very real impact on how people view you and your product. Essentially you are harming your company by posting things like this.
Take CoreOS going their separate way as a teachable moment rather than an attack on you (even if behind the scenes it was?) and learn from it. Move on and build a great product by seeing your weak points from your competitors and learning, not by posting bile that you so willingly claim against others. If what you are building is as amazing as you want other people to believe; show them through your actions and by building an amazing piece of software. There's plenty of room for competition in a quickly emerging market. Essentially, if you can't say anything good then you are only harming yourself.
Yet. If we steal enough of the MPAA's thunder they might lobby congress for some new laws... In 10 years a whole new generation will be arguing on the internet about the morality of stealing ones thunder.
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.
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.
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/
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.
His parent was shykes comment, so I think he was referring to the sample JSON document posted in the docker spec file, which docker calls a schema even though it's clearly not.
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.
> 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.