4 ms·

Yes, containers are more than chroot, until you: - Want to give them their own IP addresses or networks, or - Put upper bounds on their resources, or - Get t

by nunez 4y ago

Yes, containers are more than chroot, until you: - Want to give them their own IP addresses or networks, or - Put upper bounds on their resources, or - Get tired of dealing with chroot and unshare and seccomp and probably other tools I'm forgetting, or - You want to run an arm64 container on an x86 host with minimal configuration, or... this is a really fun (and important) exercise for anyone working with containers seriously to undergo but let's not trivialize how insanely easy Docked made creating containers become.

simplotek 4y ago
> (...) but let's not trivialize how insanely easy Docked made creating containers become. So much this. Docker doesn't get the respect it deserves. I'd also mention packaging/installing/deploying applications, which Docker made so trivial and trouble-free. Docker at it's core is a masterclass of UX.
- nine_k 4y ago
  Its UX used to be... slightly suboptimal here and there. Nevertheless, it took the world by storm. IMHO it's because Docker made the few core things absurdly easy, not just low-friction, but zero-friction. That was key. The rest was important but not critical, and was built out eventually.
nine_k 4y ago
Frankly, you don't need much more for a proof of concept. Beside chroot, you basically need a namespace control utility, an iptables control utility, and a volume control utility. The "Docker in 100 lines of bash" [1] does just that. It skips the trouble of managing volumes by demanding btrfs; it could instead use stuff like tar / dd and mount to a comparable effect. This is, of course, about as fiddly, slow, and unreliable as, say, building an amplifier with discrete transistors, or building a clock with nixie tubes and 74xx chips, etc. The point is not in producing a sleek and reliable solution (though this is not ruled out), but in seeing and understanding how a thing works from inside. [1]: https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896
- gsaussy 4y ago
  Also, if you choose not to use the `iptables` command line utility and want to handle network isolation by directly chatting with the kernel over a netlink socket, then you basically have to cargo cult someone else's implementation. AFAIK the clearest documentation has been reading the Docker networking code. https://man7.org/linux/man-pages/man7/rtnetlink.7.html https://man7.org/linux/man-pages/man7/rtnetlink.7.html
laumars 4y ago
Making containers was easy long before Docker came along: - FreeBSD Jails - Solaris Zones - Proxmox (which was an abstraction over OpenVZ, back before LXC came along) In fact because of all of the above, I was a latecomer to Docker and didn't understand the appeal. What Docker changed was that it made containers "sexy", likely due to the git-like functionality. It took containers from a sysadmin world and into a developers world. But it certainly didn't make containers any easier in the process.
- lobotron 4y ago
  Yes: "What Docker changed was that it made containers "sexy", likely due to the git-like functionality. Post cloud era and all those new markets to tap into. Jails etc: like a tool hammering nails. Why, when or how to build a city is something else entirely. -but, probably git-like sexy functionality indeed. yeeha
- BiteCode_dev 4y ago
  So you mean you could take your FreeBSD Jails configuration, upload it on a well known public website like dockerhub, then get someone on Windows or Mac transparently install the image and run it with a few cmdlines ? Because docker container are called container for this reason. That comes from the boat container analogy.
  - laumars 4y ago
    Running Docker on non-Linux platforms requires a Linux VM to run in the background. It's not as cross platform as people make out. The other container technologies can be managed via code too, that code can be shared to public sites. And you can run those containers in a VM too, if you'd want. What's more, with ZFS you could not only ship the container as code, but even the container as a binary snapshot, very much like Docker's push/pull but predating Docker. Even on Linux, for a long time before Docker, you could ship container snapshots as tarballs. Also worth mentioning is that early versions of Proxmox even had (and likely still does) a friendly GUI to select which image you wanted to download, thus making even the task of image selection user friendly. This was more than 10 years ago, long before Docker's first release and something Docker Desktop still doesn't even have to this day. > Because docker container are called container for this reason. That comes from the boat container analogy. The term computer "container" predates Docker by a great many years. Containers were in widespread use on other UNIXes with Linux being late to the game. It was one of the reasons I preferred to run FreeBSD or Solaris on production in the 00s despite Linux being my desktop OS of choice. Even when Linux finally caught with containerisation, Docker was still a latecomer to Linux. Furthermore, for a long time Docker wasn't even containers (still isn't strictly that now but it at least offers more in the way of process segregation than the original implementations did). Albeit this was a limitation of the mainline Linux kernel so I don't blame Docker for that. Whereas FreeBSD Jails and Solaris Zones offered much more separation, even at a network level. If we are being picky about the term "container" (not something I normally like to do) then Docker is the least "container"-like of all containerisation technologies available. But honestly, I don't like to get hung up on jargon because it helps no-one. I only raise this because you credited the term to Docker. --- Now to be clear, I don't hate Docker. It may have it's flaws but there are aspects of it I do also really like; and thus I do use it regularly on my Linux hosts these days despite my original reluctance to move away from Jails (Jails is still much nicer if you need to do anything complicated with networking, but Docker is "good enough" for most cases). However what I really dislike is this rewriting of history where people seem to think Docker stood out as a better designed technology - either from a UX or engineering perspective. I personally think what made Docker successful was being in the right place at the right time. Linux was already a popular platform, containers were beginning to become widely known outside of the sysadmin circles but Linux (at that time) still sucked for containerisation. So it got enough hype early on to generate the snowball effect that saw it become dominant. But lets also not forget just how unstable it was, for a long time it was frequently plagued with regression bugs from one release to another. Which caused a great many sysadmins to groan whenever a new release landed. (sorry for the edits, the original post was a flow of thoughts without much consideration to readability. Hopefully I've tidied it up)
goodpoint 4y ago
docker replaced small scripts with a bloated codebase and a big attack surface.
- hinkley 4y ago
  Docker saved me from clever people who overlapped with the “it works on my machine” crowd. Regenerating from scratch every time saved a bunch of tribal knowledge from staying locked up in the heads of untrustworthy individuals. You couldn’t “forget” changes you made last Friday that don’t compose with the documented parts of the process.
  - goodpoint 4y ago
    This is like attributing the invention of phones to steve jobs and electric cars to elon musk. And I wouldn't be too surprised if somebody did it on HN.
    - hinkley 4y ago
      Who invented what doesn’t change when things came together into a coherent solution instead of a differing set of unsatisfying guidelines that nobody follows. I don’t have this conversation a lot, but I usually find a chef or puppet apologist on the other end of the conversation who doesn’t understand how people who don’t eat, breathe, and sleep system administration issues feel about that flavor of “repeatable”. That shit is crazy and we are never going back.
xorcist 4y ago
That list are good examples of things Docker makes unnecessarily hard. Anything else than what Docker provides is out of the question, and what that is is often undocumented and changes between versions. It will also clash with whatever limits and netfilter rules the system uses anyway unless you are very careful. This is actually one of the things that systemd did well. It's completely straightforward and the man pages are mostly correct. They should have just gone with that instead.
- Timon3 4y ago
  Exactly, Docker is great - until you leave the beaten path. At a previous workplace I set up a VPN solution around Wireguard and Docker. We wanted to start off by integrating one physical box into our network, where containers would be spawned with a client and a customized MAC addresses to sort them into individual VLANs, which would then be accessible through the VPN. It took a number of tries to set up correctly, especially since documentation on these areas mostly consists of reading through various issues on the Docker issue tracker. Some necessary features weren't even supported in the current Docker-Compose file versions. And best of all - 3 clients worked without a problem in parallel, any further clients were not visible in the network. No error logs or anything, just no network. Of course this wasn't using everyday features, but it would have been nice to have a bit more of an introductory guide into the subsystem. This way it felt like I was fighting against Docker more than it was helping me.
  - simplotek 4y ago
    > Some necessary features weren't even supported in the current Docker-Compose file versions. Why docker-compose? Have you tried Docker swarm mode?
    - nunez 4y ago
      personally i would skip straight to kubernetes if you start messing with swarm
      - 4y ago
tyingq 4y ago
Bocker[1] does a reasonably good job of showing the value of Docker was mostly in Docker hub. [1] https://github.com/p8952/bocker https://github.com/p8952/bocker

by nunez 4y ago

simplotek 4y ago

> (...) but let's not trivialize how insanely easy Docked made creating containers become. So much this. Docker doesn't get the respect it deserves. I'd also mention packaging/installing/deploying applications, which Docker made so trivial and trouble-free. Docker at it's core is a masterclass of UX.

nine_k 4y ago
Its UX used to be... slightly suboptimal here and there. Nevertheless, it took the world by storm. IMHO it's because Docker made the few core things absurdly easy, not just low-friction, but zero-friction. That was key. The rest was important but not critical, and was built out eventually.

nine_k 4y ago

Frankly, you don't need much more for a proof of concept. Beside chroot, you basically need a namespace control utility, an iptables control utility, and a volume control utility. The "Docker in 100 lines of bash" [1] does just that. It skips the trouble of managing volumes by demanding btrfs; it could instead use stuff like tar / dd and mount to a comparable effect. This is, of course, about as fiddly, slow, and unreliable as, say, building an amplifier with discrete transistors, or building a clock with nixie tubes and 74xx chips, etc. The point is not in producing a sleek and reliable solution (though this is not ruled out), but in seeing and understanding how a thing works from inside. [1]: https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896

gsaussy 4y ago
Also, if you choose not to use the `iptables` command line utility and want to handle network isolation by directly chatting with the kernel over a netlink socket, then you basically have to cargo cult someone else's implementation. AFAIK the clearest documentation has been reading the Docker networking code. https://man7.org/linux/man-pages/man7/rtnetlink.7.html https://man7.org/linux/man-pages/man7/rtnetlink.7.html

laumars 4y ago

Making containers was easy long before Docker came along: - FreeBSD Jails - Solaris Zones - Proxmox (which was an abstraction over OpenVZ, back before LXC came along) In fact because of all of the above, I was a latecomer to Docker and didn't understand the appeal. What Docker changed was that it made containers "sexy", likely due to the git-like functionality. It took containers from a sysadmin world and into a developers world. But it certainly didn't make containers any easier in the process.

lobotron 4y ago
Yes: "What Docker changed was that it made containers "sexy", likely due to the git-like functionality. Post cloud era and all those new markets to tap into. Jails etc: like a tool hammering nails. Why, when or how to build a city is something else entirely. -but, probably git-like sexy functionality indeed. yeeha
BiteCode_dev 4y ago
So you mean you could take your FreeBSD Jails configuration, upload it on a well known public website like dockerhub, then get someone on Windows or Mac transparently install the image and run it with a few cmdlines ? Because docker container are called container for this reason. That comes from the boat container analogy.
- laumars 4y ago
  Running Docker on non-Linux platforms requires a Linux VM to run in the background. It's not as cross platform as people make out. The other container technologies can be managed via code too, that code can be shared to public sites. And you can run those containers in a VM too, if you'd want. What's more, with ZFS you could not only ship the container as code, but even the container as a binary snapshot, very much like Docker's push/pull but predating Docker. Even on Linux, for a long time before Docker, you could ship container snapshots as tarballs. Also worth mentioning is that early versions of Proxmox even had (and likely still does) a friendly GUI to select which image you wanted to download, thus making even the task of image selection user friendly. This was more than 10 years ago, long before Docker's first release and something Docker Desktop still doesn't even have to this day. > Because docker container are called container for this reason. That comes from the boat container analogy. The term computer "container" predates Docker by a great many years. Containers were in widespread use on other UNIXes with Linux being late to the game. It was one of the reasons I preferred to run FreeBSD or Solaris on production in the 00s despite Linux being my desktop OS of choice. Even when Linux finally caught with containerisation, Docker was still a latecomer to Linux. Furthermore, for a long time Docker wasn't even containers (still isn't strictly that now but it at least offers more in the way of process segregation than the original implementations did). Albeit this was a limitation of the mainline Linux kernel so I don't blame Docker for that. Whereas FreeBSD Jails and Solaris Zones offered much more separation, even at a network level. If we are being picky about the term "container" (not something I normally like to do) then Docker is the least "container"-like of all containerisation technologies available. But honestly, I don't like to get hung up on jargon because it helps no-one. I only raise this because you credited the term to Docker. --- Now to be clear, I don't hate Docker. It may have it's flaws but there are aspects of it I do also really like; and thus I do use it regularly on my Linux hosts these days despite my original reluctance to move away from Jails (Jails is still much nicer if you need to do anything complicated with networking, but Docker is "good enough" for most cases). However what I really dislike is this rewriting of history where people seem to think Docker stood out as a better designed technology - either from a UX or engineering perspective. I personally think what made Docker successful was being in the right place at the right time. Linux was already a popular platform, containers were beginning to become widely known outside of the sysadmin circles but Linux (at that time) still sucked for containerisation. So it got enough hype early on to generate the snowball effect that saw it become dominant. But lets also not forget just how unstable it was, for a long time it was frequently plagued with regression bugs from one release to another. Which caused a great many sysadmins to groan whenever a new release landed. (sorry for the edits, the original post was a flow of thoughts without much consideration to readability. Hopefully I've tidied it up)

goodpoint 4y ago

docker replaced small scripts with a bloated codebase and a big attack surface.

hinkley 4y ago
Docker saved me from clever people who overlapped with the “it works on my machine” crowd. Regenerating from scratch every time saved a bunch of tribal knowledge from staying locked up in the heads of untrustworthy individuals. You couldn’t “forget” changes you made last Friday that don’t compose with the documented parts of the process.
- goodpoint 4y ago
  This is like attributing the invention of phones to steve jobs and electric cars to elon musk. And I wouldn't be too surprised if somebody did it on HN.
  - hinkley 4y ago
    Who invented what doesn’t change when things came together into a coherent solution instead of a differing set of unsatisfying guidelines that nobody follows. I don’t have this conversation a lot, but I usually find a chef or puppet apologist on the other end of the conversation who doesn’t understand how people who don’t eat, breathe, and sleep system administration issues feel about that flavor of “repeatable”. That shit is crazy and we are never going back.

xorcist 4y ago

That list are good examples of things Docker makes unnecessarily hard. Anything else than what Docker provides is out of the question, and what that is is often undocumented and changes between versions. It will also clash with whatever limits and netfilter rules the system uses anyway unless you are very careful. This is actually one of the things that systemd did well. It's completely straightforward and the man pages are mostly correct. They should have just gone with that instead.

Timon3 4y ago
Exactly, Docker is great - until you leave the beaten path. At a previous workplace I set up a VPN solution around Wireguard and Docker. We wanted to start off by integrating one physical box into our network, where containers would be spawned with a client and a customized MAC addresses to sort them into individual VLANs, which would then be accessible through the VPN. It took a number of tries to set up correctly, especially since documentation on these areas mostly consists of reading through various issues on the Docker issue tracker. Some necessary features weren't even supported in the current Docker-Compose file versions. And best of all - 3 clients worked without a problem in parallel, any further clients were not visible in the network. No error logs or anything, just no network. Of course this wasn't using everyday features, but it would have been nice to have a bit more of an introductory guide into the subsystem. This way it felt like I was fighting against Docker more than it was helping me.
- simplotek 4y ago
  > Some necessary features weren't even supported in the current Docker-Compose file versions. Why docker-compose? Have you tried Docker swarm mode?
  - nunez 4y ago
    personally i would skip straight to kubernetes if you start messing with swarm
    - 4y ago

tyingq 4y ago

Bocker[1] does a reasonably good job of showing the value of Docker was mostly in Docker hub. [1] https://github.com/p8952/bocker https://github.com/p8952/bocker