The Security-Minded Container Engine by CoreOS: rkt Hits 1.0
coreos.com
coreos.com
I haven't been following the OCI at all, but could somebody shed some light as to why the runtime is the most important part to standardize? Also, any insight as to whether or not the container image format should be standardized?
I have code on my laptop and I need to package it for many environments:
A development VM A CI service Pushed and stored at rest in a registry Run on multiple runtime services like AWS ECS and Lambda
It would be really nice if one image worked everywhere. Having to rebuild is at the very least inefficient, but sometimes disastrous if a different dependency or language version sneaks in.
The Docker image format and registry API is becoming ubiquitous. We have also been using tarballs for builds for decades.
Does it need to be standardized? Probably not.
But it would be nice if we can do a better job of cooperating this generation than we did with VM images.
Ironically this was specifically to accomodate the ACI format pushed by CoreOS, which is completely incompatible with Docker images. We designed OCI and runc to allow both Docker and ACI to target a common format and low-level runtime. The reasoning was "let's deliver a solid building blick which everybody can use instead of boiling the ocean with a giant over-reaching spec".
“I believe in the rkt model,” said Lennart Poettering, systemd lead developer. “Integrating container and service management, so that there’s a 1:1 mapping between containers and host services is an excellent idea. Resource management, introspection, life-cycle management of containers and services – all that tightly integrated with the OS; that’s how a container manager should be designed.”
Unless Docker finds a way of moving up the stack they are going to have a hard time defending their current valuation. Their current efforts provides close to zero monetizable value.
[1]: https://www.docker.com/products/docker-universal-control-pla...
Fleet, Mesos, swarm and kubernetes are effectively different implementation details too.
Operating these things as infrastructure services with high SLAs is a money making business.
I hope there are other ways to make this stuff a good business because CoreOS, Docker, Hashicorp, and Mesosphere et al are doing pretty darn excellent engineering.
Also, is there a PPA planned for Ubuntu, or plans to get it into Debian soon, now that it has reached 1.0?
Eventually you realise that Dockerfiles are fine and dandy, but this mechanism isn't really needed and it can be an obstacle. You realise that a good package manager is your real friend. So now I use wonderful xbps-install from Void Linux to create a complete rootfs + actool to make an ACI file and that's it. A basic webserver can work as a repo for your xbps packages and your ACI images. No need to use Docker Hub or Quay, etc.
How are the tools for managing your rkt deployments? Since Hashicorp supports it, I'm starting to think that I would be better off using their tooling to abstract myself from the specific container implementation.
So I should have been more clear, you can specify rkt today, but many things wont work, a lot of things have improved for the upcoming 1.2 k8s release but still not perfect. hence what I meant by "released", something that is can be viewed as a complete replacement for the docker runtime.
a simple thing that was missing was managing /etc/resolv.conf (see rkt 1.0 release notes that this was added so now kubernetes can take advantage of it going forward).
Without it, one either has to jump through some hoops (not impossible) to manage it yourself or your system just wont work (i.e. trying using GCE metadata server from within GCE without being setup for GCE's dns server).
It looks like it already supports a bunch of different ARM targets[0].
[0]: https://github.com/appc/spec/blob/3972f6a1b657f38e30100d2a7e...