>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
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.
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.
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.
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.
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:
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".
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.
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.
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
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.
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.
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.
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.
They seem to favor reusing existing tools a little bit more, instead of reinventing an ecosystem in a bubble...
I love docker but it feels like they are going too fast to do things in a more modular and plugable way.
They could explore extending systemd or having foss tools that match each other or have at least the minimum support for features that are put forward but only properly supported in their SaaS offering... Anyway, I just hope we get more stability and replaceable parts in this field! :)
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