It's a primitive that can be composed into other things. It's a better primitive for many cases than VMs are.
If you're fretting about containers/not-containers, you're below the value line. What matters is application code that provides value. If you're thinking about how it gets launched and managed, you're losing time to someone who doesn't have to.
Disclosure: I work for Pivotal, we have a fairly close interest in this topic through PivotalCF.
We use a mix of providers for different things, and I actually love DigitalOcean because of your focus on making it super-easy to run basic Linux servers at reasonable cost.
I will say, I know all of those folks relatively well and they are all really really really good humans who I believe in and love.
I really like CoreOS and rkt. At my company we're building our next generation infra on CoreOS and Kubernetes with Docker. We'd like to switch from Docker to rkt eventually. The two things blocking this for us are:
1. rkt is focused on production usage (which is good) but is completely lacks a development workflow akin to Docker Compose and Docker for Mac. (Kubernetes is not a suitable alternative to Docker Compose, before someone suggests it.) Since rkt doesn't use a client/server model like Docker, having a seamless experience with a VM like Docker for Mac where the client on the host is just sending requests to the server will require some work, or a different approach altogether. Yes, we could use rkt only for deployment and develop with Docker, but that complicates our stack in a way that just doesn't provide the benefit to justify it yet.
2. Integration in Kubernetes at the same level of maturity as Docker. As mentioned in that reddit thread, "rktnetes" is currently described as a "work in progress." I remember somewhat recently that official Kubernetes release notes introducing rkt support literally linked to a Google Doc filled with issues. Kubernetes itself has very bad documentation, so linking to a Google Doc isn't a huge surprise, but it still shows that rkt support is still very early. It will happen, certainly, but it's not there yet.
[0] https://github.com/kubernetes/minikube
[1] https://github.com/kubernetes/minikube/pull/511
disclosure: I work on minikube at google
Why not? I have been contemplating this exact thing right before I came to procrastinate on HN.
A few of my local development workflows are using minikube[1]. Kubernetes within minikube is a lot like docker-compose. The only use case I have for docker-compose is pycharm integraion[2], but someone will probably make it work with minikube one day. There is a tool to convert from docker-compose to kubernetes[3].
1. https://github.com/kubernetes/minikube
2. https://www.jetbrains.com/help/pycharm/2016.1/docker-compose.html
3. https://github.com/kelseyhightower/compose2kubeI tried to get docker to work for a CI pipeline and it failed miserably. Consistent lock-ups and just generically slow operation when spinning up and deleting 100s of containers per hour forced me to move to lxc which works extremely well for a CI type workload. Not that surprising considering TravisCI and CircleCI behind the scenes are using lxc as well. Volume mounts, networking, sandboxing and just general stability all work without surprises in lxc but to this day I have no idea what the proper patterns are for sharing host level mounts properly inside docker containers.
I really hope rkt becomes the default container substrate. From first principles and fundamentals perspective rkt is the right solution.
I saw v1.14 is tagged as 'f26' in Fedora's package builder so I'm not sure when this will be getting released there. F24 is currently offering rkt v1.0.
Loved the `rkt gc` command. Really excited to try this out with Kubernetes now [2]
1 - https://github.com/coreos/rkt/blob/master/Documentation/tryi...