Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running containers without Docker

jvns.ca

Post reply on HN
Print view View original

51–60 of 140 posts

Re: Running containers without Docker

#51

Post by throw2016 »

I think when it comes to containers HN has been guilty of a shocking lack of scrutiny and unilaterally hyping Docker.

For example Docker was based on LXC till 0.9 but was so successful in hype and misdirection of the project it's based on that till today most commentators here do not seem to have a proper idea of the LXC project and whatever ideas they have are negative. How did this come to be?

I don't know how healthy it is for open source if the HN community lets VC funded projects essentially hijack open source projects in this way and allow misconceptions to grow about them. For the record LXC has always been a full scale container manager and was and remains a much simpler way to use containers than Docker.

Most of the big problems holding back containers like security, isolation, multi-tenancy are kernel side and not container manager side or ecosystem side and will be solved kernel side. Similarly most of the features of containers that are usable today are also thanks to kernel side.

Yet the folks who work on kernel namespaces, aufs, overlayfs and other container used technologies receive no rewards or even recognition while companies like Docker completely reliant on their work suck up the attention and hype. How is this sustainable?

How many know the author of Aufs or Overlayfs? How much support have these projects received and how do these projects sustain themselves.

How many know that cgroups were not namespaced, the issues this created for containers and that they recently got namespaced? How many know about the fantastic advantages but also pitfalls of user namespaces? Isn't this the kind of 'container discussion' we should we having on HN instead of Docker or vendor focussed discussions?

And thanks to the lack of scrutiny, Dockers complex use case of containers has passed unexamined and worse been conflated to containers. This has only increased technical debt for users just stepping in and runs the risk of putting users off containers due to the inherent complexity.

Re: Running containers without Docker

#52

Post by fnj »

icebraining wrote: post #18
secstate wrote: post #16

Earlier quoted context omitted.

Docker was originally built on top of LXC. It is now becoming more flexible with what is underneath, but there's a reason you need a VM running in the background on macOS to use Docker. Docker is tool to interact with LXC (and hopefully other container systems).

Docker doesn't use LXC anymore[1]. The reason you need a VM is to get the Linux kernel, not LXC, and the reason you need that is because the macOS kernel (Darwin) doesn't have the necessary containerization features. On FreeBSD, for example, Docker runs natively, without a VM. [1] https://www.infoq.com/news/2014/03/docker_0_9

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.

Re: Running containers without Docker

#53

Post by girvo »

We followed this idea at my workplace! It worked wonderfully; we slowly containerised every project we have, then deployed the containers as "dumb" "programs". Yesterday I began the orchestration step, and everything has gone extremely smoothly. Altogether this has taken about 12 months of on-and-off work, maybe a man-month all up.

Re: Running containers without Docker

#54

Post by sciurus »

> I think that just using containers by itself will force us to be disciplined about how we package and run services (you have to install all the stuff the service needs inside the container, otherwise the service will not work!). > > There’s no way for it to silently depend on the host configuration, because its filesystem is totally separate from the host’s filesystem.

I don't buy this, at least as presented. /etc/awesome/blah.xml does not spontaneously come into existence on a host on its own. No matter if you're building a docker image, a VM image, or managing long-lived hosts via a configuration management tool, you have to specify that /etc/awesome/blah.xml is created and has certain contents.

It sounds like the author is working on a poorly structured and documented puppet codebase, where all the dependencies of services aren't clear. Presumably if they can figure them out in order to build working docker images, they could also figure them out and then refactor the Puppet code to make it more maintainable.

At that point they could use their puppet code to generate their docker images, which fits nicely into the "horizontal change" philosophy.

Re: Running containers without Docker

#55

Post by sysexit »

shykes wrote: post #50
atombender wrote: post #41

Earlier quoted context omitted.

You missed another, big reason: "Fewer, simpler moving parts" is the main reason I would prefer if Kubernetes could run without Docker as a container runtime. At the moment, Kubelet needs to control the Docker daemon (a somewhat brittle relationship), and a bunch of concepts — from networking to volume management — could be simplified by making the container runtime more K8s-specific and less general-purpose. A tight…

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 to build primarily on Docker, or switches to containerd

Kubernetes has 3 container runtimes at the moment: Docker, Rocket, and the new remote runtime which allows you to plug in a separate server using a protobuf interface. There is a lot of focus on the remote runtime now. The CRI-O project for example is implementing a remote runtime that allows any OCI conformant runtime to be plugged into Kubernetes.

Re: Running containers without Docker

#56

Post by tonyhb »

fnj wrote: post #52
icebraining wrote: post #18

Earlier quoted context omitted.

Docker doesn't use LXC anymore[1]. The reason you need a VM is to get the Linux kernel, not LXC, and the reason you need that is because the macOS kernel (Darwin) doesn't have the necessary containerization features. On FreeBSD, for example, Docker runs natively, without a VM. [1] https://www.infoq.com/news/2014/03/docker_0_9

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.

xhyve and bhyve virtualization built into the BSD kernels. docker for mac now runs a tiny linux vm directly on osx

Re: Running containers without Docker

#57

Post by Naomarik »

nzoschke wrote: post #49
apeace wrote: 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 think you dozed off there...

Re: Running containers without Docker

#58

Post by orthecreedence »

schmichael wrote: post #36
random567 wrote: post #32

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.

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).

Re: Running containers without Docker

#59

Post by tonyhb »

moondev wrote: post #43
zzzcpan wrote: post #30

Earlier quoted context omitted.

It installs fine, it just doesn't work. There is an issue on github with the same errors as I saw, where they discuss not fixing it, because of how uncommon the system is.

Can you link it here? I'm just curious. I run docker on trusty all the time

Me too. Never seen an error.

Re: Running containers without Docker

#60

Post by 2trill2spill »

fnj wrote: post #52
icebraining wrote: post #18

Earlier quoted context omitted.

Docker doesn't use LXC anymore[1]. The reason you need a VM is to get the Linux kernel, not LXC, and the reason you need that is because the macOS kernel (Darwin) doesn't have the necessary containerization features. On FreeBSD, for example, Docker runs natively, without a VM. [1] https://www.infoq.com/news/2014/03/docker_0_9

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 operating system doesn't have a feature that does not mean a different operating system does not have that feature.

[1] https://www.freebsd.org/doc/handbook/linuxemu.html

Post reply on HN