Hacker News Reader

Comment by jsmthrowaway | Hacker News Reader

Containers existed before Docker and will exist after Docker, and articles like these are desperate attempts to remind everyone of that in the face of Docker's unilateral destruction of the concept. I know I'm right because of comments like these that presuppose "well, if you're doing containers, use Docker, the alternatives just aren't there." Except they were, before Docker, and after Docker.

Docker is a developer tool, not a container runtime. The 'containers' it presents require you to commit a daemon on every machine, commit to a weird storage and distribution story when, you know, files of containers served in a flat directory are totally adequate, and so on. Docker made extremely complicated choices for a lot of things and now everybody wishing to advance containers has to deal with presuppositions like these, where Docker exists and the motivation for not using it is unclear to a lot of people, you included.

View on HN

Docker is a container runtime, not merely a developer tool. It was intended as such from the beginning. It is successfully used in production at large scale by a number of companies, including Uber.

The fact that you don't like Docker doesn't change any of that. If you don't like it, don't use it. But there is no justification for you to claim it is only a developer tool when it is obviously more than that.

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.

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

> 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

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

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

Thats incorrect both jails and "containers" are examples of OS level virtualization[1]. Instead of virtualizing the hardware you virtualize the operating system, ie system call table.

[1]: https://en.wikipedia.org/wiki/Operating-system-level_virtual...

So what is your alternative? Run containers your own unique way and roll your own distribution mechanism and networking to fragment yourself from the tools in the "container" space?

When "your own unique way" requires less development time and efforts and it's easier to learn for new hires, yes. That's why you hire system engineers - to write good automation.

Reply on news.ycombinator.com