
Rocket and App Container 0.2.0 Release - kelseyhightower
https://coreos.com/blog/rocket-and-appc-0.2.0/
======
Alupis
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.

------
lclarkmichalek
"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
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](https://github.com/coreos/rocket/issues/405)

~~~
lclarkmichalek
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 :)

~~~
jzxcv
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.

------
sant0sk1
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](http://thechangelog.com/138)

------
bayesianhorse
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
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 ;)

------
shykes
Here's the open specification for Docker's standard format:
[https://github.com/docker/docker/blob/master/image/spec/v1.m...](https://github.com/docker/docker/blob/master/image/spec/v1.md)

~~~
Alupis
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.

~~~
shykes
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.

~~~
Alupis
> 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.

~~~
shykes
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?

~~~
Alupis
> Docker and CoreOS might be competitors, and we might disagree on many things
> (ethics in particular)

I can't believe you, the founder and creator of Docker and Dotcloud, just
called the CoreOS team unethical.

~~~
jsprogrammer
Strictly, shykes didn't call the CoreOS team unethical. It might be implied,
but he did not "just [call]" them that.

