Does anyone use 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).
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.
[1] https://github.com/coreos/rkt/blob/master/Documentation/tryi...
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!
- Laptop Kubernetes, minikube, can use rkt with a single flag https://github.com/kubernetes/minikube#using-rkt-container-e...
- BlaBlaCar rkt in prod and moving to Kubernetes
- Container Linux by CoreOS services like kubelet and etcd now run using rkt and download docker images from quay.io
- GKE ContainerVM is looking to use rkt for Kubelet mount management