
Getting Started with rkt - philips
http://blog.codeship.com/getting-started-rkt/
======
jzelinskie
>You can store rkt images in CoreOS’ Quay service.

Just a minor correction: Quay stores Docker images and server-side coverts
them to ACI when first requested and caches the results. This is because appc
only has a proposal for uploading. If you're interested in providing feedback:
[https://github.com/appc/acpush](https://github.com/appc/acpush)

~~~
lukebond
Thanks! I'll fix it

------
orthecreedence
I'm excited for rkt. The first time I spun up docker, it complained about the
daemon not running. Huh? Ok, spun up the daemon (root, of course) and now the
main docker commands work.

Wait, I have to run a daemon as root to run my containers, which all are also
going to be run under the same root process? Alarm bells are ringing.

Having a tool that runs containers in isolated processes is much more
appealing to me, and seems much more correct and true to the very nature of
containerization.

~~~
justincormack
Containers are isolated processes, and don't need root. Docker needs root to
give them elevated privileges if you require this, and to set up iptables and
so on.

~~~
pawadu
Please don't shrug this off so easily. With a vulnerability in the Docker
daemon (an no software is 100% free of bugs) he is in more danger than before
containerization.

~~~
scaryclam
This 1000 times. It's also an issue being a single failure point more
generally. If the daemon doesn't perform, it can affect every single container
running on the system. Competing systems that use a less monolithic approach
are very, very welcome.

------
e12e
Nice overview. I'm curious about the need for (some) acbuild commands to run
as root, though. Does anyone know if this is just in order to be able to call
chroot? The example linked in the article doesn't go into detail:

[https://github.com/lukebond/demo-
api/blob/master/appc.sh](https://github.com/lukebond/demo-
api/blob/master/appc.sh)

I can't see why building an image file would require root -- all in all it's
just about writing some kind of archive to disk, isn't it? A cursory glance at
the rkt-project documentation didn't get me any closer than the equivalent of
"some sub-commands require root".

~~~
ecnahc515
It's only the run that requires root subcommand and its because it uses
systemd nspawn to run the command inside the image your building. Not ideal
but it's how it works for now.

------
BinaryIdiot
Interesting. I didn't know much about rkt but this was helpful. I like the
fact that it's based around existing tools (bash commands, bash scripts
instead of a proprietary Dockerfile is nice). Though I'm guessing there will
be little to no support for Windows?

Either way this is interesting. I've been using Docker but I could see using
this down the road.

~~~
Mic92
Maybe the spec can be adopted by other operating systems. A Freebsd port was
developed before docker gained support for Freebsd:

[https://github.com/appc/spec/#what-are-some-
implementations-...](https://github.com/appc/spec/#what-are-some-
implementations-of-the-spec)

------
daurnimator
> rkt follows the appc spec and uses a combination of HTTPS and HTML meta tags
> via a discovery URL.

Why in the world would you pick this as a discovery mechanism.

This means that any took that wants to do appc discovery needs to know how to
parse HTML.

~~~
philips
This discovery method is inspired by the way Go does package name delegation.
It is really trivial to do.

We have gotten feedback that people would prefer to use a well-known URL. At
the time we started building appc the well-known URL stuff seemed to not be
getting much traction but this has seemed to change over the last few months.
See this issue:
[https://github.com/appc/spec/issues/160](https://github.com/appc/spec/issues/160)

Overall, I think this sort of delegation and naming is really important
despite the shortcomings of particular methods. I hope that as the Open
Containers Initiative proceeds that we are able to make this part of the
standard. If email can do name delegation to hosting providers our server
software certainly should too.

~~~
jsprogrammer
It's an excellent hack, but it also just feels so wrong, at least in some
cases. Most users (of a URL) won't care about the tags, so why send them?
Maybe User-Agent differentiation is an answer? Define a string which indicates
the type of response that rkt is looking for?

Are there any examples of publicly standardized User-Agents?

At least it would allow one to take meta tags to specialized binaries out of
their webpage markup. Well known URLs is a decent compromise, but potentially
breaks existing applications and extends across all applications.

------
jaequery
rkt seems a little too inelegant for my likings. wish they had similar
buildfiles or cli syntax as docker. even then, i'm not sure what benefit it'd
bring over docker.

~~~
philips
If you think of rkt as an analogy to `apt-get` I think it makes a bit more
sense.

apt-get has methods for downloading and installing software over the internet.
Similarly, rkt has methods for downloading and running container images.

And like apt-get rkt doesn't build packages but relies on a spec and a build
system.

rkt also avoids being an init system. This allows for rkt to be used with
existing init systems for things like system services, daemons, etc. It also
means that you can use rkt containers alongside your "normal" init tooling.

------
gnud
I thought this was going to be about Racket...

