Does everything really need to be Docker these days? Specially "network stuff". I mean, it really makes me want to go and grow potatoes instead doing any "IT"
“docker pull”, deploy, and one can move on to the next whatever. You can deploy this to a Synology NAS, a Raspberry Pi, or Heroku with a few clicks (or even an appropriately configured router that supports containers if you’re not running something providing this functionality natively).
(DevOps/infra monkey before moving to infosec, embrace the container concept)
If running an OS that supports docker...
Provided you already turned off everything that can interfere with this stuff, including IPv6, any security like SELinux, grsecurity and friends, and you let it administer your netfilter firewall for you. Don't forget to check if you accidentally exposed some redis instance to the public Internet.
(And yes, I have embraced the concept and work daily with similar things, albeit in a larger scale. Let's just not kid ourselves it's easier than it is though. Just because an out of the box deploy goes sideways doesn't mean you are dumb.)
Not quite. My point was that the complexity of Docker is, in many cases, worth it because it hides a lot of the complexity of running software. Yes, you trade one problem for another, but the nice thing about Docker is, if you really go all in on it, the knowledge of how to use it transfers to pretty much any software you want to run.
For example, I wanted to run a JVM-based service the other day. Having never done this before, spinning it up with Docker took two minutes—I didn't have to figure out JDK vs runtime, which version I needed to install, etc. And yet, if I want to configure it past the defaults in the future, the image exposes several environment variables that make it easy.
Not sure what to make of this. Networking was specifically called out as an example.
But there are stories to share about the storage layer too. Lots of driver specific things that leak through that abstraction.
One may use Docker for a lot of things but ease of operations is not one of them. There's a reason both Red Hat and Ubuntu had to make up their own formats, neither of which is trivial to use, but there was just no way they could have done it with Docker instead. They're unlikely both wrong here.
Makes trying new stuff a way less troublesome.
No worries, just specify the previous version in my launch script, literally changing a couple of digits, and I'm back up and running in seconds.
I'm sure I could get it done using apt, but it was literally changing some numbers in a script and rerunning it.
As someone who just wants things to work, Docker has made things significantly better.
Give me raw source code or binaries and a configuration file in /etc or $HOME any day of the week.
Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl.
One illustrative example: OpenSSL has divergent naming and versioning schemes across different versions of distributions that use the same Debian package manager. So you either build your packages at least four or five times, Dockerize, or statically link OpenSSL. That’s just for dpkg based distros too! Then there is RPM, APK, and several others I can’t recall right now.
BTW Windows has a bit of the same disease and being from one company has a lot less of an excuse. OS standardization and dependency standardization is very hard to get right, especially at scale.
Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.
Best thing after sliced bread is apps/software packed in single GO binary. Runs everywhere, you only need to rsync/scp it to million of other places and it "acts" (usually) as normal Linux program/daemon
The Go approach is just static linking. Rust often does the same though it’s not always the default like in Go, and you can do the same with C and C++ for all but libc with a bit of makefile hacking.
Statically linking the world is the alternative approach to containers.
That's not an accurate description of the main motivation for Docker. It's a nice secondary benefit, sure.
But the main use case was probably convenience. It's a very quick way for Mac and Windows users to get a small Linux VM up and running, and utilize the copious amount of software written for it.
These days it's mostly standard, for better or worse. There are a handful vendor independent ways to distribute software but this works with most cloud vendors. Is it good? Probably not, but few industry standards are.
At a certain point you need to start defining the environment regardless of OS, and docker works as a tool that handles environment definition for literally any program (same thing works for ruby, java, python, etc). It handles more complex environment definition than packages, but is lighter than a VM. It's a middle ground, which is a great compromise for some cases and not for others.
Varying use cases and lots of flexibility is also the reason why linux is never going to just standardize the ecosystem and say "ok, there is only 1 openSSL package now." Some people see the ability to have a version of linux that is completely bonkers in versioning as a strength, akin to how some places have old windows 95 computers they still run because newer versions don't work properly. On linux, you could have old 1995 packages from a specific app, but the rest modern secure packages.
It was to solve the age old "it runs on my machine".
Open to being wrong but when docker hit the scene I remember that being touted left and right.
Yes, a dpkg is built for a distribution, and not only that but a specific version of a distribution. So they tend to get re-built a lot. But this is something buildhosts do. What you upload is the package source.
If you want to distribute a package to work on "Linux" in general, then you can't build it for a specific distribution. Then you bundle all the shared libraries and other dependencies. (Or make a static build, but for various reasons this is less common.) Do not try to rely on the naming scheme of openssl, or anything else really. This is what most games do, and the firefox tarball, and most other commercical software for Linux.
There are of course downsides to this. You have to build a new package if your openssl has a security issue, for example. But that's how most software is distributed on most other operating systems, including Windows. This is also how Docker images are built.
The alternative is to build packages for a specific distribution and release, and as stated above, that takes a bit of integration work.
There are issues with both alternatives, but they should not be confused.
Maybe, but that will never happen because the ecosystem got here by being open enough that people could be dissatisfied with existing stuff and make their own thing, and to a remarkable degree things are intercompatible. It's always been like this; just because there are 20 people working on distro A and 20 people working on distro B doesn't mean combining them would get 40 people working on distro AB. (In practice, attempting it would probably result in the creation of distros C-F as dissidents forked off.)
> Docker took off because there is no Linux. There are 50 different slightly incompatible OSes. So the best way to distribute software is to basically tar up the entire filesystem and distribute that. Dependency management has failed because there’s just too much sprawl.
I think I agree with you; part of the problem is that people treat "Linux" as an OS, when it's a piece that's used by many OSs that appear similar in some ways.
> Apple macOS is the only OS you can ship software for without statically linking or bundling everything and be reasonably sure it will work… as long as you are not going back more than two or three versions.
...but then by the same exact logic as the previous point, I think this falls apart; macOS isn't the only OS you can target as a stable system. In fact, I would argue that there are a lot of OSs where you can target version N and have your software work on N+1, N+2, and likely even more extreme removes. Last I looked, for example, Google's GCP SDK shipped a .deb that was built against Ubuntu 16.04 specifically because that let them build a single package that worked on everything from that version forward. I have personally transplanted programs from RHEL 5 to (CentOS) 7 and they just worked. Within a single OS, this is perfectly doable.
I much prefer this over the old method of canned deployment where you ran a script and prayed it didn’t hose the host too badly.
My view is this:
There is a myriad of amazing toolage out there that the everyday person could greatly benefit from in their day-to-day life. A lot of that has a very high barrier to entry for technical knowledge. By simplifying this setup down to a simple Docker compose file I believe that I have allowed the lay person to play and experiment in the freedom of their own home with technology they may have otherwise been eyeing.
but the whole project here is to wrap up a bunch of other projects in a way that makes them easy to install and configure with minimal fuss. docker is perfect for that. if you want to be fussy and complain about the tools other people choose, then projects like this probably aren't much interest to you.
Earnestly interested in your take.
Yeah, you can easily pull and run things but you have no idea how or what it does and when things break whole idea is pull it again and run.
I have nothing against containers.. real system ones (LXC for example)
The concept of separating runtime (X or Y) from data storage is not unique to containers; it's a best practice in software design called separation of concerns. This separation makes applications more modular, easier to scale, and allows for better resource optimization.
The "pull it again and run" mentality is a simplification. While containers do promote immutability, where if something goes wrong you can restart from a known good state, it's not the only way to troubleshoot issues. The idea is to have a consistent environment, but it doesn't prevent you from debugging or understanding the internals.
Lastly, while there are differences between application containers (like Docker) and system containers (like LXC), they both leverage Linux kernel features to provide isolation. It's more about the use case and preference than one being "real" and the other not.
And by default logs are stored in a json format in a single file per container, grepping `docker logs` feels slower than grepping a file. And the option to read logs for n last hours is incredibly slow -- I think it reads file from the beginning until it reaches the desired timestamp
I've recently come across a talk related to running openstack in kubernetes. Which sounded like a crazy idea, openstack needs to do all kinds of things not allowed by default for containers, e.g. create network interfaces and insert kernel modules. But people still did it for some reason -- on of them was that it's easier to find someone with k8 experience than with openstack one. And they liked the self-healing properties of k8.
I don't know what the bottom line is
I’m by no means a docker evangelist, but it does work and it simplifies deployment and management quite a bit.
The sound of someone who hasn't used Nix.
It's crazy to me that people push it so much given this issue, aren't VPNs even more common in corporate settings, especially with remote work nowadays?
I find it easier to just spin up a full VM than deal with docker's sensitivities, and it feels a bit ridiculous to run a VM and then setup docker within it instead of just having appropriate VM images.
While I can see it does at times make it more difficult to do certain things with the proper permissions, know how and set up there is nothing it cannot do.
I tried running a docker based setup for a year on my homeserver, thinking that using it for some time would help me get over my instinctive revulsion towards software that makes Docker the only way to use it, the way that forcing myself to use Python had helped me get over disdain for it back during the early days of the transition from 2 to 3. Didn't help at all, it was still a pita to rely on. Went back to proper installs, couldn't be happier.