It's a shame AppC is going away[0]. OCI is pretty much just a formalization of what Docker already does, so we're stuck with (IMO) implementation details like layers as part of the core image spec.
AppC has layers[0]. In fact, an ACI is just a layer.
While layers are codified into the OCI specification, the manifest system is flexible and allows for future extension. The main goal of OCI is to provide a specification for what is already widely deployed without introducing too many new concepts.
It's really cool to see this stuff emerging, and the CoreOS folks put out some good info at kubecon. We're currently running k8s on the docker engine like probably just about everyone, but for the same reasons as just about everyone we're interested in seeing the development of standard runtimes for containers and orchestration. Having said that, I'm not sure I'm all in on this idea of "pod sandboxes" as the environment in which application components are grouped. I may just need to wrap my head around it, but after getting comfortable with the cluster as the sandbox for applications composed of pods I guess I haven't grasped the utility of the additional abstraction.
So,a normal Kubernetes user will never know about rkt pod sandboxes and Kubernetes pods will just work as expected. Only you won't have all of these weird "pause" containers everywhere.
Thanks, that makes sense. I always thought of the pause container as "being" the pod in the networking sense, so if the pod sandbox simply replaces that I guess they could have just called it a pod.
I'm stating to really get into containers. They make sense and can keep sane environments; keeping you away from dependency hell (at the expense of potential security issues if you don't have tools that regularly scan and tell you when packages within containers have security issues).
Unfortunately, the orchestration formats are all over the place. Kubernetes, DC/OS and Docker-compose all have their own json schema. DC/OS doesn't even support docker container volumes. Rancher can take docker-compose, and it looks like it can deploy those apps on K8s/DCOS, however I haven't messed with it enough to see if that actually works.
Rkt just adds even another container format. What once seemed like a nice one-stop isolated application that you could run anywhere is becoming more complicated and more tightly coupled to the underlying container engine and orchestration system you chose to use.
rkt is not a new container format. It is a thing that executes container images and implements all of the current formats including OCI, Docker Images, and appc. No other container engine can download and execute all of those formats today.
For users using rkt + Kubernetes they can execute Docker Images just like normal.
using rkt on platforms other than coreos is hard... or maybe harder than docker.
a lot of us first try these things on our desktop and then attempt to put them in production.
for example, the mucking about SELinux on fedora is a recipe for disaster.
my request would be to package it better. its not a bad idea to use the new snap package (like docker).
and a page with docker cmd <-> rkt cmd would be very welcome!
"In parallel to the image format, OCI is developing the so-called runtime-spec for describing the runtime execution environment that container engines should provide."
I thought the run-time spec was formalized and that we were waiting on the OCI image format to be standardized. Is that not the case? This was from a recent conversation I had with someone at CoreOS.
Yeah, we're in the process of moving some of our services from docker to rkt. We're about 1/2 way done and all new ones are being deployed on rkt.
We've been hit by to many regressions docker versions and issues with docker daemon that required us to restart docker and all the containers on a host. One systemd unit -> rkt container -> our service is just such a better failure domain.
We're currently running containers outside of explicit container orchestration like k8 or docker compose. But in the future we'll be moving some of our elastic workloads to k8 and in the long term almost everything but services that rely on persistent data on lock disk (where network block device doesn't cut it).
Rkt really is missing good on-boarding / Getting Started instructions. I don't have time to figure out all the details and I really want to know how to do the following things:
1. Create Dockerfile like equivalents for Rkt images
2. Share and publish Rkt images.
3. Consume Rkt images in a Kube cluster that already supports Docker on AWS.
The Dockerfile is my biggest issue with Docker. I really don't like to write shell scripts in there, but there are caching benefits (thanks to the limitations of Docker) to inline everything in there.
Although the idea is to have an endless chain of dependent images with small Dockerfiles on each step, the reality is different.
I recently needed a monolithic image of having Nginx, Node.js, and Phusion Passenger, just merging the Dockerfiles doesn't work as each has a cleanup step that ruins things for the next one.
I know it's great to have everything self-contained (pun intended) in a single Dockerfile - it's much easier to diff and display on Docker Hub, but this promotes bad practices without a doubt!
Using rkt with kubernetes, yes. This article gives some meaningful insight. There's been a lot of hoop jumping, but rkt has several critical features that make it the right fit for us.
This integration is about 90% complete and will completed going into 2017.