Live data from Hacker News

Running containers without Docker

jvns.ca

31–40 of 140 posts

Re: Running containers without Docker

#31
post #24
post #2

What is the motivation and benefit for running containers without docker? Docker is by far the more mature and adopted development tool. It also runs great on windows, macos and linux. While k8s can run containers via the rkt runtime, it's still pretty new and will probably introduce unnecessary headache and edge cases. Docker also has a head start on a vibrant ecosystem for base images. In my opinion it would be bet…

Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers without Docker. There are several motivations, all of which are perfectly valid: 1. Learning . It's fun to build things from scratch to understand how they work under the hood. 2. Bad experience . Early versions of Docker were quite buggy, and we initially struggled…

My main concern is coming across a an issue only to research it and find a "won't fix"[closed] and 100 +1s asking for it. When I have something super important in actual production this scares me way too much to trust.

Re: Running containers without Docker

#33

I've successfully used Docker in production since it was a hobby project of dotCloud. I was answering the OP's question about why anybody would ever consider not using Docker for containers, so it's ironic that I'm now responding to your comment as the followup about my personal preferences. Clever commentary trap: why not? Here's why. Oh, well, nobody's forcing you to use it.

We detached this subthread, which spends much time in meta territory, from https://news.ycombinator.com/item?id=12800653 and marked it off-topic.

Re: Running containers without Docker

#34

If someone sent me an email equivalent to this blog post, my sole recommendation would be ProxMox running OpenVZ. OpenVZ gets you 90% of the way to Docker-style containers without breaking anything for her developers.

The current version of Proxmox uses LXC instead of OpenVZ, which is interesting since it's using the same kernel containerization features that Docker uses, unlike OpenVZ which required a custom kernel.

My mistake- I thought they had the option to use KVM, LXC, or OpenVZ all at once. I see now that in adding LXC they dropped OpenVZ.

Re: Running containers without Docker

#35
post #20

The nomad[0] team was just discussing today how much effort to put into our rkt support[1] (our support for rkt lags behind our docker support). So far we don't see a lot of evidence of our users taking rkt into production over Docker, but I'm very curious if there's a significant number of users like Julia looking to avoid running docker in production. From a nomad developer standpoint, while building long command s…

Hey Michael! Could you email rkt-dev about your questions as well? Particularly around the long command strings. There are other ways to launch rkt containers besides long args. https://groups.google.com/forum/#!forum/rkt-dev

Our only question is more of a usage survey. Not sure it's our place to perform those on your mailing list. :)

So far the command line building is more pro than con. It's so nice to be able to copy & paste commands out of logs to see exactly how rkt is being run.

Re: Running containers without Docker

#36

I don't get the differentiation between "rkt" and "docker". What complexity does Docker add? Separate networking? Difficulty communicating between processes? Just trying to understand why rkt is less overhead...

One large difference is that docker has a daemon that exposes an HTTP API and acts more or less like an init for containers.

The docker daemon has historically had some stability issues as well as some security implications. Running a command line tool like rkt is a vastly smaller attack surface and less complex stack overall.

Re: Running containers without Docker

#38

The nomad[0] team was just discussing today how much effort to put into our rkt support[1] (our support for rkt lags behind our docker support). So far we don't see a lot of evidence of our users taking rkt into production over Docker, but I'm very curious if there's a significant number of users like Julia looking to avoid running docker in production. From a nomad developer standpoint, while building long command s…

As a user, I don't like have two schedulers (nomad/docker) on my nodes. I don't like having two daemons taking care of the overlay network either. And I don't like magic and things that break from time to time. We've had our fair share of broken Docker upgrades.

Re: Running containers without Docker

#39

I don't get the differentiation between "rkt" and "docker". What complexity does Docker add? Separate networking? Difficulty communicating between processes? Just trying to understand why rkt is less overhead...

A lot of it is historical. What rkt added conceptually when it was introduced was 1) a spec and test suite, 2) signed/content-addressable images and first class third party repos, 3) not running everything under a single daemon.

Since then, Docker has improved quite a bit on these so the most in your face practical differences are smaller, but there are still philosophical differences that affects it.

E.g. rkt comes out of CoreOS. CoreOS does a lot around embracing systemd to its full extent. Systemd can provide a lot of the capabilities that Docker did itself, and parts of rkt's design flows from that. E.g. restarting, querying status, capturing the logs, so in a systemd based system, Docker integrated fairly poorly in that systemd would be starting and keeping track of a Docker client rather than the process actually controlling the container, while rkt fits right in.

Again, the difference is getting smaller, and various tools like runc etc. from Docker now allows you narrow the gap even more (if you put in extra effort).

Try both, basically - they're similar enough that it's worth figuring out which "flavor" you like best.

Re: Running containers without Docker

#40
post #31
post #24

Earlier quoted context omitted.

Docker founder here. > What is the motivation and benefit for running containers without docker? I regularly hear from people who want to run containers without Docker. There are several motivations, all of which are perfectly valid: 1. Learning . It's fun to build things from scratch to understand how they work under the hood. 2. Bad experience . Early versions of Docker were quite buggy, and we initially struggled…

My main concern is coming across a an issue only to research it and find a "won't fix"[closed] and 100 +1s asking for it. When I have something super important in actual production this scares me way too much to trust.

That's where the competition will come in handy. Docker Inc has its own corporate goals. Luckily, they are decoupling the underlying components more and more.
Post reply on HN