Live data from Hacker News

Running containers without Docker

jvns.ca

61–70 of 140 posts

Re: Running containers without Docker

#61

Earlier quoted context omitted.

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.

Also, not sure if this is still the case, but Docker's daemon ran as root on the host. Any vulnerability has the potential to give root on the host machine to an attacker. I don't think this has ever happened, but rkt's approach of using a process per container just makes much more sense in a security context (and for containerization in general).

The daemon needs superuser privileges to do its business, but your containers are not running as root. That lives behind the --privileged option and has ample guidance in the documentation against using it.

Re: Running containers without Docker

#62
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.

Just curious: Which issue(s) are you talking about?

Re: Running containers without Docker

#63

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…

Well, I for one encourage more rkt support in Nomad, it's very awesome!

Re: Running containers without Docker

#64
So, in general, tools like Docker are crap because they're like the Apple iPod equivalent of old standard Unix-style tools: bloated monolithic slapped together crap that's crammed with non-extensible non-intuitive extras, designed for people who don't want to know anything about how the sausage is made. But if you do want to do fancy production things, it's nice to have a tool that thousands of people have used for thousands of different things, and bake in all the weird fixes for weird problems over thousands of iterations of testing and bug-fixing.

However. If what you want is to simply understand what's going on under the hood, this is a great way to do it. The only thing better that I would recommend is to actually make your own Docker. It's not that difficult, you're basically just slapping together some system calls and execvp()ing some other standard tools, which is what Docker does, and you don't need to support any of the extra fancy features. But you gain an intimate understanding of what could be going on when stuff in production is breaking.

Re: Running containers without Docker

#65

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…

I for one am definitely looking to replace Docker in production with Rkt. Just waiting for Rkt support in higher-level components (Kubernetes in my case) to mature a bit more.

Re: Running containers without Docker

#66
post #55
post #50

Earlier quoted context omitted.

I would categorize that under 5: competition . Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms. Personally I think the long-term solution is for kubernetes to adopt containerd - it's the small, stable, rock-solid container runtime that…

> Kubernetes started out as an extension/modification of Docker, and over time Docker has evolved some of the same features as its kub-based competitors. The result is an uncomfortable integration between partially competing platforms. That's quite inaccurate. It's is like saying that OpenStack started out as an extension to KVM. Both had very different (original) scopes. > Whether the Kubernetes community continues…

All of the early Kubernetes resources I can find describe it as involving Docker. Was running it without Docker really a thing early on?

Re: Running containers without Docker

#67
post #52

Earlier quoted context omitted.

If MacOS doesn't have certain linux kernel features, neither does FreeBSD. How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference.

> How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference. FreeBSD can run 64 bit and 32 bit Linux binaries via it's Linux emulator[1]. Plus FreeBSD has had containers since FreeBSD 4 which was released in March of 2000, except containers on FreeBSD are called jails. > If MacOS doesn't have certain linux kernel features, neither does FreeBSD. Just because one opera…

Jails are considerably different than containers. Jails are more like chroot jails on linux instead.

Edit: My viewpoint was focused more on the composability aspect of containers. But I stand corrected otherwise.

Re: Running containers without Docker

#68
post #45

I have to say: before I began to read through, I was already convinced the author's idea was not a good one. But by the time I finished, she convinced me that it was a good plan in her situation. There are lots of great tools in the Docker/container ecosystem these days, but I can see the argument that a major infrastructure migration should be done in incremental steps. Using containers as simply a Puppet replacemen…

Convox founder here. Thanks for the shout out! We are indeed building a private Heroku like platform so you don't have to. It's a simple of layer around AWS so it doesn't add extra craziness some other approaches do. As for the OP, her approach is spot on! Containerizing your app is the first step in future proofing it. Doing so correctly will remove layers and therefore simplify things. You now are looking at a pack…

I hate nagios as much as the next op, but what is so magical about containers that your services will no longer require an outage alerting mechanism?

Re: Running containers without Docker

#69

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.

> docker has a daemon that exposes an HTTP API

This API has to enabled explicitly. Docker daemon works by using a unix socket instead ( "/var/run/docker.sock" ).

> acts more or less like an init for containers

There is Docker daemon and there is Docker CLI. Both have separate scopes.

Re: Running containers without Docker

#70

Earlier quoted context omitted.

> How can Docker run on FreeBSD when FreeBSD has no cgroups? I think you misread/misinterpreted your reference. FreeBSD can run 64 bit and 32 bit Linux binaries via it's Linux emulator[1]. Plus FreeBSD has had containers since FreeBSD 4 which was released in March of 2000, except containers on FreeBSD are called jails. > If MacOS doesn't have certain linux kernel features, neither does FreeBSD. Just because one opera…

Jails are considerably different than containers. Jails are more like chroot jails on linux instead. Edit: My viewpoint was focused more on the composability aspect of containers. But I stand corrected otherwise.

No, jails are basically containers. Docker on FreeBSD uses jails for isolation -- see the wiki page at https://wiki.freebsd.org/Docker
Post reply on HN