

Rkt 0.5.4 – Repository authentication, port forwarding and more - agonzalezro
https://coreos.com/blog/rkt-0.5.4/

======
lclarkmichalek
That auth configuration format looks awesome. So glad we're moving beyond the
clusterfuck that is docker authentication

------
secure
I like rkt’s focus on deployment issues that Docker currently still has — as
an example, rkt verifies signatures by default.

As another example, rkt intends to work better with systemd/kubernetes, but
AIUI that’s still on the roadmap and not actually implemented.

Looking forward to when CoreOS actually recommends running rkt in production
:).

~~~
chimeracoder
> As another example, rkt intends to work better [than Docker] with
> systemd/kubernetes, but AIUI that’s still on the roadmap and not actually
> implemented.

Could you elaborate on this? Do you mean working better with systemd as a
process supervisor or as a runtime?

Many people don't know this, but it's already possible to use systemd as a
runtime for Docker containers[0], which is about as integrated as I can
imagine[1]. Though admittedly, the Docker daemon and runtime do not play well
with process supervision (of any kind, including systemd)[2].

Last I checked, CoreOS had posted to the systemd mailing list announcing their
plans to integrate with nspawn, though I don't think that's been released yet.

[0] This is the best-kept secret of both Docker and systemd. I recently
conducted a workshop on "Docker Without Docker" \- in other words, how to run
Docker containers without even having the Docker runtime installed (using pure
systemd).

[1] And, depending on your use case, I'd recommend giving it a shot - there
are a number of things that systemd provides that Docker still does not. On
the other hand, Docker has a large ecosystem, and the tools for building
initial container images are very accessible.

[2] At least as of recently, you can use 'exec mode' to specify the initial
process (PID 1) _inside_ a container running under Docker, but systemd still
does not have access to the actual process on the host, which makes it
cumbersome to monitor - the CoreOS documentation tells you to do something
like this for Docker + systemd: [https://github.com/ChimeraCoder/znc-kibana-
playbooks/blob/ma...](https://github.com/ChimeraCoder/znc-kibana-
playbooks/blob/master/znc.service)

~~~
amouat
> [0] This is the best-kept secret of both Docker and systemd. I recently
> conducted a workshop on "Docker Without Docker" \- in other words, how to
> run Docker containers without even having the Docker runtime installed
> (using pure systemd).

Could you expand on this? I'm curious as to what you mean/how you did this.

~~~
chimeracoder
Sure. These are the slides for my talk, which includes some of the code
examples that we walked through: [https://chimeracoder.github.io/docker-
without-docker/#1](https://chimeracoder.github.io/docker-without-docker/#1)

Consider Git. Git exists solely on the filesystem. If you want, you can read
git repos by inflating the ZLIB-compressed objects yourself, and create git
repos by compressing objects, hashing them, and storing them in right
locations the exact same way that Git does.

It's a lot of work, and the Git toolchain exists so you don't have to type
insanely long bash one-liners just to read your commit history. But it's kind
of cool to know that >95% of Git is really just 'syntactic sugar' around
functionality that's also provided by other command-line tools[0].

I'll wave my hands a bit, but in short: containerization uses features
implemented at the kernel level, and in fact, until recently, Docker and
systemd both built on top of LXC (Docker has switched created their own
libcontainer).

If you take a running Docker container and dump it, you'll get a root
filesystem. You could chroot(8) inside this root filesystem, but as we know,
containerization is more powerful than chroot. Once you've dumped the
container, systemd doesn't need to know that it was once a Docker container -
it'll just look for whatever binary is located at /sbin/init and run that (or
run whatever command you tell it to run instead. Just like your actual OS -
which is not a coincidence!).

One advantage to using systemd instead of the Docker daemon/runtime is that
systemd is capable of running itself inside a container, whereas running init
systems inside Docker containers is tricky and not recommended[1]. Futhermore,
systemd is smart enough to know when it's running inside a container and when
it's not, so the container init system plays nicely with the host init system
- things like integrated system logs and networking.

Newer versions of systemd actually allow you to _pull_ Docker images from the
Docker hub directly, so you can even use systemd to replace `docker pull` as
well as `docker run`.

[0] There's a tiny, tiny portion of Git which is home-grown, but most of the
features it builds on (SHA, zlib, diff) are easily replaced by other command-
line tools.

[1] While it's supported, the primary use case of Docker is for running
application processes:
[https://github.com/docker/docker/issues/2170](https://github.com/docker/docker/issues/2170)

~~~
amouat
Ah, that's a really great explanation - thanks.

I guess you lose all of the Docker metadata, links and volumes though?

You should turn this into blog post if you have time - I'd upvote it anyway!

~~~
chimeracoder
> I guess you lose all of the Docker metadata, links and volumes though?

You only need links at runtime, so they're not part of the frozen image _per
se_ ; they exist as part of a running container. Put another way, systemd
handles container networking, so you don't need the environment variables that
Docker injects when making links, because the containers can talk to each
other already[0].

Volumes - if you mount external volumes with -v /foo:/bar, you can do the same
with systemd. I'm actually not too sure about named volumes in Docker, since I
almost never use them (it's way easier to reason about volumes when I control
where they are located on the host).

> You should turn this into blog post if you have time - I'd upvote it anyway!

Thanks - I'm actually working on that! Consider these slides a preview. :)

------
karmakaze
Have to check this out. Of all the container buzzness around, I like their
spin--no spin, just get the job done filling in all the blanks.

