WTH Is Docker??
-
I keep seeing "Docker" all over the CP.. What is Docker and why should I care?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
it's a pair of purpose designed clippers to remove the tails from lambs so the shi poo doesn't stick to their tail. Saves them from "fly strike" which (particularly in Aus & NZ) happens when flies lay eggs in the stuck poo from which which maggots emerge to basically eat the lambs ass; while not every lamb will get this, those that do will suffer in pain and eventually (many months to years) will eventually die a horrible death. PETA of course insists the practice is cruel, and lambs should be allowed to retain the much increased chance to experience lingering painful diseases.
Message Signature (Click to edit ->)
-
I keep seeing "Docker" all over the CP.. What is Docker and why should I care?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Docker is a tale, you can attach it to your waist and then connect it to computer to control the computer using your mind just like the Avatar controls the Pandoran animals :laugh: :laugh: :laugh:
-
it's a pair of purpose designed clippers to remove the tails from lambs so the shi poo doesn't stick to their tail. Saves them from "fly strike" which (particularly in Aus & NZ) happens when flies lay eggs in the stuck poo from which which maggots emerge to basically eat the lambs ass; while not every lamb will get this, those that do will suffer in pain and eventually (many months to years) will eventually die a horrible death. PETA of course insists the practice is cruel, and lambs should be allowed to retain the much increased chance to experience lingering painful diseases.
Message Signature (Click to edit ->)
Bloody oath, mate. :)
-
Docker is a tale, you can attach it to your waist and then connect it to computer to control the computer using your mind just like the Avatar controls the Pandoran animals :laugh: :laugh: :laugh:
As in Lopitar's answer, you can also use a docker to remove the tail.
-
I keep seeing "Docker" all over the CP.. What is Docker and why should I care?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I keep seeing "Docker" all over the CP.. What is Docker and why should I care?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
I keep seeing "Docker" all over the CP.. What is Docker and why should I care?
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Really? docker - Google Search[^] Enterprise Container Platform | Docker[^] Docker (software) - Wikipedia[^] And you're not even the first to ask :sigh: Should you care? Hell yes! If only to be up-to-date with the latest developments in software, your bread and butter. I actually can't believe you (and others) didn't already do a five minute read-up years ago when it became hot :doh: Although if you're doing UI development it may not be that applicable :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
An attempt at a short answer: It's a "container" that specifies the OS and the applications that you want to run. As such, it's much easier, faster, and much much smaller to ship the "container" rather than an entire VM image, because all you're really "shipping" is the specification for what the container contains. Hence the whale with a bunch of containers on its back logo. Why? Because on the first run, when you "launch" the container, it will download all the pieces that you specified and run various configuration/setup scripts. When it's done, you now have a VM with the specified OS and applications that you can "talk to", as in, many Docker apps are servers -- there's no UI. Longer version: It makes it really easy to test stuff, because you can reset the VM back to its original state at any time. From my very limited experience, it works best with Linux and Linux apps because Linux natively doesn't include all the UI bloat that Windows does. You don't interface with the apps in a container through a UI, you interface with them through a terminal app like PuTTY or WinSCP for file management, or if the apps in the container provide a web API, you go that route. And the cool thing is, the applications running in the container are completely isolated from the host machine. Sure, something malicious might blow away the VM, but your host machine is safe. Furthermore, unless you do something really dumb, the only apps that run in the container are the ones specified in the container configuration file -- so you know what you're putting into it. And the really really cool thing is that once the container is initialized, you can launch multiple instances of the VM fast and isolated from each other. Because scripting languages like Python are easily specified as "I want to install Python version x.xx", it makes it really easy to create containers with custom code. And, one of the reasons I think Microsoft has put a lot of effort into getting some of its servers and frameworks to run under Linux is because they are easily containerized with the Linux OS. But Docker for Windows [truly sucks](https://marcclifton.wordpress.com/2017/11/18/my-docker-for-windows-experience/), the last time I tried it. [My article](https://www.codeproject.com/Articles/1186568/Create-a-Dockerized-Python-Fiddle-Web-App) might help too, if you want an example of how this stuff is set up to do something useful and talk to Windows. Of course there are [other really good articles on CP](https://ww
Ironically, most current Linux distros (those that use systemd, which is pretty much all of them) already have a built-in container management system (systemd-nspawn) and don't actually need Docker. It's pretty snazzy to dig into.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Really? docker - Google Search[^] Enterprise Container Platform | Docker[^] Docker (software) - Wikipedia[^] And you're not even the first to ask :sigh: Should you care? Hell yes! If only to be up-to-date with the latest developments in software, your bread and butter. I actually can't believe you (and others) didn't already do a five minute read-up years ago when it became hot :doh: Although if you're doing UI development it may not be that applicable :)
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
In 7 years as a developer I never shipped anything that required any kind of toy like that. There isn't only the web - in fact there is a definite lack of low level programmers because everyone and their dogs launch themselves on the latest trends, as if programming was a popularity contest, rather than doing the hard stuff.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
In 7 years as a developer I never shipped anything that required any kind of toy like that. There isn't only the web - in fact there is a definite lack of low level programmers because everyone and their dogs launch themselves on the latest trends, as if programming was a popularity contest, rather than doing the hard stuff.
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
In 7 years as a developer I never shipped anything that required any kind of toy like that.
Neither did I to be honest, but it's good knowing what's out there even if you're not using it. As I said, you don't need Docker if you're doing UI development, or low level, as you said, but surely you know about Rust when you're a C(++) developer even if you're not using it? (And just in case you don't, Rust should be THE new and easy replacement for C, or so I'm told, I don't do C(++)). I once worked with a web developer who never heard of Node.js. I find that absolutely amazing (and not in a good way) that some people care so little about their trade that they miss such industry changing tools. Especially as a consultant I can't imagine coming to a client and not knowing about Node.js or Docker, I'd be out of a job in no time!
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
den2k88 wrote:
In 7 years as a developer I never shipped anything that required any kind of toy like that.
Neither did I to be honest, but it's good knowing what's out there even if you're not using it. As I said, you don't need Docker if you're doing UI development, or low level, as you said, but surely you know about Rust when you're a C(++) developer even if you're not using it? (And just in case you don't, Rust should be THE new and easy replacement for C, or so I'm told, I don't do C(++)). I once worked with a web developer who never heard of Node.js. I find that absolutely amazing (and not in a good way) that some people care so little about their trade that they miss such industry changing tools. Especially as a consultant I can't imagine coming to a client and not knowing about Node.js or Docker, I'd be out of a job in no time!
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
Sander Rossel wrote:
Rust should be THE new and easy replacement for C,
:laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh: :laugh:
GCS d-- s-/++ a- C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
-
An attempt at a short answer: It's a "container" that specifies the OS and the applications that you want to run. As such, it's much easier, faster, and much much smaller to ship the "container" rather than an entire VM image, because all you're really "shipping" is the specification for what the container contains. Hence the whale with a bunch of containers on its back logo. Why? Because on the first run, when you "launch" the container, it will download all the pieces that you specified and run various configuration/setup scripts. When it's done, you now have a VM with the specified OS and applications that you can "talk to", as in, many Docker apps are servers -- there's no UI. Longer version: It makes it really easy to test stuff, because you can reset the VM back to its original state at any time. From my very limited experience, it works best with Linux and Linux apps because Linux natively doesn't include all the UI bloat that Windows does. You don't interface with the apps in a container through a UI, you interface with them through a terminal app like PuTTY or WinSCP for file management, or if the apps in the container provide a web API, you go that route. And the cool thing is, the applications running in the container are completely isolated from the host machine. Sure, something malicious might blow away the VM, but your host machine is safe. Furthermore, unless you do something really dumb, the only apps that run in the container are the ones specified in the container configuration file -- so you know what you're putting into it. And the really really cool thing is that once the container is initialized, you can launch multiple instances of the VM fast and isolated from each other. Because scripting languages like Python are easily specified as "I want to install Python version x.xx", it makes it really easy to create containers with custom code. And, one of the reasons I think Microsoft has put a lot of effort into getting some of its servers and frameworks to run under Linux is because they are easily containerized with the Linux OS. But Docker for Windows [truly sucks](https://marcclifton.wordpress.com/2017/11/18/my-docker-for-windows-experience/), the last time I tried it. [My article](https://www.codeproject.com/Articles/1186568/Create-a-Dockerized-Python-Fiddle-Web-App) might help too, if you want an example of how this stuff is set up to do something useful and talk to Windows. Of course there are [other really good articles on CP](https://ww
Interesting explanation. So, essentially, you end up with yet another instance of a Windows VM that you have to maintain and patch. I'm assuming Windows licensing gets in the way too? I'm still not sensing much benefit when compared to full/regular VMs. Maybe for Linux, but apps hosted on Windows?
-
Interesting explanation. So, essentially, you end up with yet another instance of a Windows VM that you have to maintain and patch. I'm assuming Windows licensing gets in the way too? I'm still not sensing much benefit when compared to full/regular VMs. Maybe for Linux, but apps hosted on Windows?
Most Windows software is GUI based, and the only graphical user interface that you can make with Docker is a web iterface. So almost all of MS software is useless in a Docker environment. You can make Docker images running programs with a 1970-style command line user interface, such as compilers, MSbuild and similar tools. These are typically freely available, such as in the vs_buildtools package, with "no" licensing restrictions. (There is a license agreement, but none of the restrictions is likely to affect you, whatever you use it for.) So for all practical purposes, Windows licensing is not an issue. The disadvantage of a free package is that there is no support - earlier today, when I asked MS support for a list of the IDs of the modules in the vs_buildtools package, I was told to raise a support case, paid for at a case-by-case basis, expected cost around 300 Euro. I turned that "offer" down, and later today I found the URL listing the IDs. I am happy that I didn't pay MS 300 Euro to provide a URL to one of their web pages! Essentially, Docker images create closed environments where the only interface to the outer world are IP based protocols, such as SSH, HTTP etc. They are sort of nice when you live in a command-line oriented world - so *nix geeks love them. The isolation is also sort of nice, as long as you do not expect any non-IP interface to the outer world. But if you change a single detail, such as updating the compiler version, you have to create another closed world, containing that compiler version. On the other hand... We have had a long discussion whether to make "one tool, one Docker image" or "one complete set of tools one docker image". In the first alternative, the build script is essentially interpreted outside Docker, each Dockerized tool being invoked more or less like another executable. In the second alternative, the build script is essentially passed to the command interpreter of a running Docker container, and the various tools in the container is invoked in turn, inside the container. In our company, we have essentially gone for the second alternative, because it allows us centralized control over the entire tool chain. We offer the developers a unified set of tools, rather than a pick-and-choose development environment. If some project insists on, say, a newer compiler version, it requires us to update an entire tool chain, which is not a five-minute job. (Well, technically it might, but we will force it to be something that is considered in
-
Most Windows software is GUI based, and the only graphical user interface that you can make with Docker is a web iterface. So almost all of MS software is useless in a Docker environment. You can make Docker images running programs with a 1970-style command line user interface, such as compilers, MSbuild and similar tools. These are typically freely available, such as in the vs_buildtools package, with "no" licensing restrictions. (There is a license agreement, but none of the restrictions is likely to affect you, whatever you use it for.) So for all practical purposes, Windows licensing is not an issue. The disadvantage of a free package is that there is no support - earlier today, when I asked MS support for a list of the IDs of the modules in the vs_buildtools package, I was told to raise a support case, paid for at a case-by-case basis, expected cost around 300 Euro. I turned that "offer" down, and later today I found the URL listing the IDs. I am happy that I didn't pay MS 300 Euro to provide a URL to one of their web pages! Essentially, Docker images create closed environments where the only interface to the outer world are IP based protocols, such as SSH, HTTP etc. They are sort of nice when you live in a command-line oriented world - so *nix geeks love them. The isolation is also sort of nice, as long as you do not expect any non-IP interface to the outer world. But if you change a single detail, such as updating the compiler version, you have to create another closed world, containing that compiler version. On the other hand... We have had a long discussion whether to make "one tool, one Docker image" or "one complete set of tools one docker image". In the first alternative, the build script is essentially interpreted outside Docker, each Dockerized tool being invoked more or less like another executable. In the second alternative, the build script is essentially passed to the command interpreter of a running Docker container, and the various tools in the container is invoked in turn, inside the container. In our company, we have essentially gone for the second alternative, because it allows us centralized control over the entire tool chain. We offer the developers a unified set of tools, rather than a pick-and-choose development environment. If some project insists on, say, a newer compiler version, it requires us to update an entire tool chain, which is not a five-minute job. (Well, technically it might, but we will force it to be something that is considered in
