Hacker News Reader

Comment by no_wizard | Hacker News Reader

What I’ve always failed to Understand is how FreeBSD jails[0] never got very popular (discounting the fact that FreeBSD isn’t very popular on the whole from what I can tell) but Docker is huge. I personally think jails are superior in implementation in that it requires no other abstractions on top of the OS.

The only thing I can surmise is that Docker might have a better secure default, but improvements to Jails could emulate that, and following best practices as well should. Beyond that I’m still baffled how this didn’t take to the mainstream.

[0] https://www.freebsd.org/doc/handbook/jails.html

View on HN

This happened because docker, in addition to an isolation system, also bundled a user friendly interface to a per-app persistent filesystem. No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies.

Docker gives you a very simple way to not think about that (at least until your massive container that bundles ancient versions of a dozen different CVE-filled libraries bites you in the ass down the road).

It's not novel. It's not even particularly elegant. But Docker users don't want elegance; most of them just don't want to think about how to configure a production environment to work like their development environment, so we get the old joke: "It works on my machine!" "Then we'll ship your machine"...and so we got docker.

Yes, this is exactly right. Dependency management is a hard problem, and with Docker you only have to get it right once. I think Docker wouldn't exist if Amazon had shipped a way to build and test an AMI locally.

There is already a solutions such as Guix and Nix, but then people aren't willing to learn a new language that allows expressing dependencies.

Docker solves dependencies in same way a disk image does, you save the image and it should look the same way each time you look at it. The Dockerfile is not a reproducible though, you just list steps iteratively to generate an image, but it doesn't guarantee to produce the same result. I saw multiple times scenario that docker image built fine for one person and didn't work for another.

The main reason for it is that majority of Dockerfiles rely on network to build the image and files received (or even your apt-get command) might produce different results for different people.

Recently I saw example where even a docker image built on build system didn't work on deployments system. Both machines of course were x86_64. Turned out that one of dependencies enabled compile optimizations for the CPU it was built on. You could argue that it isn't Docker's fault, but isn't its promise to provide reproducible builds?

Agreed. Nix and Guix actually solve the dependency problem, Docker allows you to work around it. But a work around is better than nothing.

Well, but my point there isn't nothing, there are alternatives, which can (or at least nix can) generate docker or OCI containers.

Docker is trying to sell itself as something more than it is, in reality it is just an overglorified zip file.

> I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies.

Static linking solves a lot of these deployment issues. But I guess people are worried about duplicating libraries and security vulnerabilities. So we end up with Docker which has these problems, but even worse.

Can't easily statically link a big complex application written in a dynamic language.

That's a reason to avoid dynalangs. Otoh, java and .net have ears and assemblies

Depends on the language, doesn't it? Many Scheme implementations have "unexec".

Yep, never underestimate a good interface. I can do most of what ZFS does with dm-crypt, llvm, etc but that’s a handful of interfaces to learn. ZFS includes it all. (Probably a bad analogy but it gets the idea across).

> No matter how many people sing the praises of isolation and security to Docker, I will continue to suspect that almost all of its adopters use it because packaging software with dependencies is hard, poorly understood, terribly tooled (looking at you, Python), and even more poorly executed in the vast majority of projects and companies.

Here is a quote from Eberhard Wolff's _A Practical Guide to Continuous Delivery_:

"It is laborious to install a real application including all components. Of course, it is even more laborious to automate this process... When an installation crashes, it has to be restarted. In such a scenario the system is in a state where some parts have already been installed. Just to start the installation again can create problems. The script usually expects to find the system in a state without any installed software... This problems is also the reason why updates to a new software version are problematic. In such a case there is already an old version of the software installed on the system that has to be updated. This means that files might already be present and have to be overwritten. The script has to implement the necessary logic for this. In addition, superfluous elements that are not required anymore for the new version have to be deleted. If this does not happen, problems can arise with the new installation because old values might still be read out and used. However, it is very laborious to cover and automate all update paths that occur in practice."

If a self-professed expert that writes books on the subject does not realize that package managers exist, and proposes that the only alternatives for software installation are either hand-hacked shell scripts or Docker, what do you think the average developer knows?

To be fair to Wolff, it's not uncommon for deb and rpm packages of complex daemons (e.g. postgres) to include shell scripts - postinst, preinst, etc - that makes changes to the system, and which do have to be coded in such a way to handle re-execution after partial failure. Taking my /var/cache/apt/ directory as a (poor) sample, about 1/3 of packages had such scripts.

that libc update spawned a wealth of dependency solutions. And 'dll hell' of course

In my experience even the best of package managers are fundamentally ill suited for deployments because of assumptions about use cases.

Can you elaborate?

But they are popular...

Jails and chroots are used heavily in iOS and Android. I would say its one of the fundamental differences between mobile apps and desktop apps.

Its not enough though. You need docker to handle the DNS, routing, port forwarding etc. if you want to emulate a pocket cloud on a dev machine. I suppose the networking aspect could be done for jails as well but docker and docker-compose just seem more polished in this regard.

I interpreted the above comment to be about general purpose computers, not mobile.

> You need docker to handle the DNS, routing, port forwarding etc.

If you do IPv6, there is no need for all of these layers of IPv4 overlay network crap.

IPv6 saves you from setting up DNS on each instance and will do load balancing?

Depends on what you use DNS for. Because the /64 space is so large, and you have a very large, very flexible subnet above that, you can set up an address assignment scheme for non-public facing nodes where you do not need DNS, and you can integrate that scheme with your load balancer. See Coffeen's _IPv6 Address Planning_ for ideas.

That seems like a lot of work and you're ultimately not going to be able to use this in full deployment. Docker models and maps tobcloud infrastructure quite nicely and that's a reason it popular.

Docker is convenient. You can just download the docker binary and type "docker run postgres" and have a container running Postgres. What's the equivalent for FreeBSD jails?

There is no equivalent of course. I guess people are confused on what jails are. Jails, Solaris Zones, lxc, runC, chroot with namespaces and cgroups are all similar technology that are not solving the same problems as Docker. Docker just uses containers underneath to address specific package management problems. Projects that try to do the same are actually just package managers, like nix and guix.

Docker is a turn key solution to three different problems (build, package, run). A lot of people know of alternatives that cover only the run part and then they wonder why their particular solution didn't become as popular.

Also I think many people think it is very complicated to setup database, I just run it yesterday on OS X the command issues were:

    nix-env -iA nixpkgs.postgresql_11
    initdb ~/data
    pg_ctl -D ~/data start
    createdb

First command installs the database, second one populates database files, this one starts the database, last command is optional and it creates a database for your user name.

Chef habitat

Because Docker has better dev marketing. Some sizable portion of developers actually believe Docker invented containers.

This, pretty much. Nearly everything written about Docker basically treats it as synonymous with containers. This is also incredibly annoying if you're already familiar with the general concepts of containers and actually want to read something about Docker in particular.

Jails are more like runC, container tech behind Docker.

I've tried a few times to get jails working but always stumbled over something. Last time it was inbound connections for a server. After several hours I gave up. There's iocage now, but this was well before that. And iocage still has issues.

Docker I could get up an running in less than an hour and it just worked.

I'm smiling reading your comment, having fought with jails/iocage and networking in the past. The counterpoint is that you likely didn't have inbound connection problems with Docker because it seems to quite effectively bypass all of the iptables rules on the host.

I didn't dig too deep into it, but I had iptables rules set up to only allow inbound 22 and 443, but all of the exposed ports on the containers were still externally available.

I was just going to post about jails but you beat me to it.

better marketing I would assume.

I am still waiting all the docker fans to acknowledge bhyve[1]

[1] - https://bhyve.org

Reply on news.ycombinator.com