31–40 of 65 posts
Docker lets you isolate a complete environment, not only your own application files.
Your app might be expecting database X running on port Y, a specific OS version, Kafka running, etc...
Containers allow to configure all these "boxes" easily. Your co-worker can test the application with exactly the same "system" as you. And you can deploy it in that same "system" too.
Not everyone who packages an app is willing to lock all their dependencies into a specific version.
Look at dependencies that are usually coming from the system package manager, such as OpenSSL, pandoc, libicu, the timezone database, and whatnot. Sometimes those require updates. Apps may want to pick up those updates. I understand every app packager who says, „I don’t want to cut a new release every time an OpenSSL vulnerability gets patched, or whenever some country decides to update their time zone.“
So vendors may prefer their app to pick up system-level packages rather than ship those along with the app. Docker will update those packages for you every time you build your image, and you don’t depend on the app vendor to cut a release whenever you do. At the same time, containerization helps isolate versioning conflicts that stem from those common dependencies.
It has all the dependencies it needs, there is nothing else executing, the files are laid out just the perfect way, every configuration file or environment variable just magically appears.
It's very cheap to create and get rid of this happy place in contrast to dedicating an entire VM or bare metal. It's also cheap to move containers around so you could orchestrate them on multiple hosts.
Even though they raise others, they really answer to a lot of questions around developing, deploying and monitoring software reliably. That's why it's usually worth the hussle.
Earlier quoted context omitted.
> The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up. The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemo…
I feel like I get this a lot with the NPM cli tool ... No matter how often I update my dockerfiles to the latest version, I'll always end up with a big banner warning message in my build output telling me I'm outdated 'cos it seems NPM updates (and publishes) constantly.
Likewise Docker volumes and mount points. The software gets an abstracted filesystem that's actually a "volume". Could be a chunk of local filesystem, an NFS mount, whatever. The software doesn't need to know. It just acts like it's the only software on the "system" and writes to any path that it can find. It can't corrupt any other containers also running on the same host by writing global configuration files or making "system-wide" changes because those system wide changes are contained to the container.
Docker also abstracts a ton of sysadmin/deployment type tasks. I have 1 container of app X running on host A. There's a load spike. I want a second instance of app X running on host B. Ok. Load spike is over, I want to get rid of the instance of app X on host B. Docker makes this kind of dynamic deployment/destruction automatable via APIs and there's huge libraries of software out there to do it. I don't know about the .NET packaging/deployment (NuGet, etc.) and whether that's as easily done.
It sounds like you know a lot about .NET, and I know very little. So it's entirely possible that Microsoft has solved the network and storage abstraction in ways I don't know about. In that case, if you don't NEED Docker, because you have this homogenous environment and effective isolation controls built into it, be comfortable in your lack of need.
Earlier quoted context omitted.
I feel like I get this a lot with the NPM cli tool ... No matter how often I update my dockerfiles to the latest version, I'll always end up with a big banner warning message in my build output telling me I'm outdated 'cos it seems NPM updates (and publishes) constantly.
I don't use npm all that often, but I don't think I've ever run "npm install" in a project and not gotten any warnings about outdated dependencies and security vulnerabilities in them.
Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
>And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. That's just a sing for bad communication/practices/documentation and processes, and why don't the dev's test the application on the dev/test-environment? BTW: Why can the JAVA-team even install something on the dev/test/prod-env? That's completely against the rules.
This is a good way to fix those problems with communication/practices/documentation and processes.
Earlier quoted context omitted.
> The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up. The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemo…
Is depending the container image vendor actually worse? I was under the impression that they were about as "on it" as the distro maintainers with updates. And if you wanted full control then you could just have your sysadmins manage their own base images. Then upgrading system dependencies becomes as simple as doing a regular deploy.
Becuase your solution is specific to your specific software. Then you have lads who use python who can use virtualenv, and then the ruby ones who use rbenv and then you have the CPP developers which are usually fine but on Tuesday Joe messed up the linker settings and all of a sudden we're not statically linked, thanks Joe. And then our Java team forgot to tell the sysadmins that they upgraded the JVM version. The th…
> The thing with docker is that you just get a complete package with everything delivered directly by the developer and it's very hard to mess up. The downside is: you are also, at the same time, excluding yourself from standard patch management. Whereas in ye olde times for a situation like Heartbleed or log4shell the 24/7 on-call sysop team would run a simple "apt-get upgrade openssl" and restart all affected daemo…
It also really makes a difference if you are combining some tasks and ownership in a DevOps concept where it's not just developers handing off some binary and telling the operations team "good luck eh". That classic setup mostly brings finger-pointing problems and not really much of a solution.
What a patch management concept would look like is much a more modern version of the server thing: you have some system that allows you to query all the servers "what is your current version of thing X" and if you then want to change that you build an updated machine image and deploy that to all those servers. Cattle, not pets.