71–80 of 262 posts
Earlier quoted context omitted.
> Nobody distributes a Windows application that requires the user to go and install some 3rd party library before it'll work. A-hem, DirectX, VC++...?
Those things are usually included in the installer, or at least downloaded on the fly so you don't notice. So it's still self-contained from the user's point of view. Yes, sometimes they're installed globally like DirectX, so that can cause yucky interactions between applications.
I never quite understood containers and this article makes them seem kind of similar to what OSs already do. How is a container different from just installing all the dependencies along with an application? Coming from a Windows background, this is pretty common to avoid DLL hell. Nobody distributes a Windows application that requires the user to go and install some 3rd party library before it'll work. Isolation from…
Since you appear to be a Windows dev, I advise you to have a look how Windows containers introduced in Window 2016 work.
https://msdn.microsoft.com/en-us/virtualization/windowsconta...
I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some time ago. I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh, not a container though, because I also needed https, which meant I needed either a mechanism to build and update letsencrypt certs in the weird format that weechat expects, or…
Containers are a symptom of our still immature ways of building applications.
The problems you bring up would still be there without containers, but you might not notice them, until you e.g. want to bring your setup over to another machine, for example.
Or want to duplicate it somewhere else. Or want to upgrade something else on you machine that just happens to interact badly with your setup.
I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some time ago. I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh, not a container though, because I also needed https, which meant I needed either a mechanism to build and update letsencrypt certs in the weird format that weechat expects, or…
However, I do see it as positive, because its hype, regardless if good or not, has created the traction for Go and OCaml on the data center, thus eventually leading to less C code for such use cases.
So hype or not, maybe we do get some security improvements on the overall stack.
I never quite understood containers and this article makes them seem kind of similar to what OSs already do. How is a container different from just installing all the dependencies along with an application? Coming from a Windows background, this is pretty common to avoid DLL hell. Nobody distributes a Windows application that requires the user to go and install some 3rd party library before it'll work. Isolation from…
> How is a container different from just installing all the dependencies along with an application? Once the image is built, you can get another installation that is guaranteed to be identical. You can do that with VM images too, but you can not reasonably do that if you try to install multiple applications side by side in a single VM without further isolation - there are too many ways they can interact. > Isolation…
[Citation Needed]
As far as I know, this isn't the case. That's why using Nix [0] for deployment is a much saner approach than Docker. But after installation and configuration has been done, containers are a viable technology for the rest.
[0] https://blog.wearewizards.io/why-docker-is-not-the-answer-to...
The general idea isn't all that new however. Java Applications have been delivered as containers since 1995 (although the concept isn't explicitly named that way with Java applications).
Each JAR / WAR is a self-contained application that can run anywhere where there's a JVM (which is pretty much everywhere).
From a feature perspective the only real innovation of Docker-style containers probably is that those aren't limited to the JVM but are (largely) language- and runtime-agnostic.
Two paragraphs later (On containers):
"The only operating system on the server is that one host operating system and the containers talk directly to it."
I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some time ago. I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh, not a container though, because I also needed https, which meant I needed either a mechanism to build and update letsencrypt certs in the weird format that weechat expects, or…
Same here with docker. The ideas are nice as an application, but it's just a pain in the ass. LXC on the other hand is a breeze.
It is refreshing, however, being able to write, in a couple of hours, a setup script from scratch that debootstraps an install, chroots in there to configure it and launches the container via systemd-nspawn. Very few moving parts, excellent for development environments. Not yet something I trust in production, though.
I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some time ago. I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh, not a container though, because I also needed https, which meant I needed either a mechanism to build and update letsencrypt certs in the weird format that weechat expects, or…
Docker is a poorly engineered and over-hyped technology. The concept is great - and in fact, many companies have built great tooling around Linux cgroups. It lets you efficiently binpack applications on a single server - which is why 'containers' were created in the first place. The side benefit of letting you define your OS libraries, and other things, is a nice bonus, and way overblown in my opinion. Docker and its…
I remember one of the engineers giving a talk, saying that the problem they had was growing too big too quickly - they didn't have time to properly work out the base architecture in the early days.