|
LOL!
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
No worse than when the wife says It might be a little cool at the park, I'll pack an Alpaca sweater... 
It was broke, so I fixed it.
|
|
|
|
|
Is an alpaca with alopecia an unpaca.
|
|
|
|
|
Is () a Smooth Operator?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
are you some sort of Sade-ist?
Message Signature
(Click to edit ->)
|
|
|
|
|
I just thought I was oldist, but there seem to be other candidates.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
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.
|
|
|
|
|
Yah I thought I had seen a recent discussion on that The Lounge[^]
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
It's a clothing company. I wear Dockers[^] today. 
|
|
|
|
|
It's something that reduces your take-home pay.
|
|
|
|
|
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, the last time I tried it.
My article 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 too regarding Docker.
Hope that helps!
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
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
|
|
|
|
|
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 a larger framework, e.g. consulting with other users of the old version). So larger Docker images providing complete toolchains, rather than smaller images providing individual tools, is one way of controlling version proliferation across projects within the company (which certainly has been a problem the last few years).
The closed world of a Docker container (to keep terminology clear: A Docker image is similar to an executable file, with each "layer" similar to a dll, while a Doocker container is similar to a process - an instance of an image, or if you like: An instance of an executable file) means that unless a specific bug affects your program, there is no need to "maintain and patch" the image. Maybe other images are based on newer, patched-up base images, but that won't affect your older image. If you really need to update, because a patch is required for your image to run, then you will create a new Docker image, a new isolated world with that patched-up image. But that is only if your software depends on those fixes. If they don't: Keep running your old version. That's what isolation is about 
|
|
|
|
|
Interesting write-up. Thanks for taking the time.
|
|
|
|
|
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 
|
|
|
|
|
As in Lopitar's answer, you can also use a docker to remove the tail.
|
|
|
|
|
Go to the Docker challenge page and read the first article; it will all become clear.
|
|
|
|
|
Wave1[^]
Wave2[^]
Wave3[^]
I'm starting to feel, Docker is part of the human abduction plan by the aliens.
Full Reset
|
|
|
|
|
|
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!
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
