|
Ah, finally some positive vibes 
|
|
|
|
|
Docker makes more sense with Linux as a target, as you have distros like Alpine that have been designed to be really minimal (a base Alpine image is 5MB). I reworked an old Windows server (very old - it was running Server 2003 R2!!) of ours, which had web server, Git & Mercurial repo access, Redmine, MediaWiki into a set of 5 docker images totalling somewhere around 100MB in size. By separating each application into a separate container, I can update each of them without worrying about breaking the others through some common dependency. docker-compose makes it pretty easy to build, connect and run a set of containers that are menat to run in unison.
But for distributing desktop apps? Doesn't make too much sense just yet, especially with Windows, unless you have a large, involved environment you want to make available... However... something like Windows Sandbox is a stepping stone towards using containers or containerisation trechnology for running desktop applications.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Thanks, useful information
|
|
|
|
|
Depending on what the application does, you might be able to skip the docker/containers and go to "server-less" or Function As A Server solutions which can be done with .net/core code.
|
|
|
|
|
Aha, going to try that! thanks
|
|
|
|
|
We are in the process of introducing Docker, now that we are moving a lot of development activity over to Linux. Our Linux build nodes will essentially have no utilities or tools at the OS level, everything will be put into Docker images. Since Windows Docker may run Linux containers, and everything is in the container, you can run it on your Windows desktop (assuming that you have a 64 bit Windows 10 Pro or other version that can run Hyper-V).
We are going to run our build nodes under Linux, but the developers may run the same Docker images on their desktops. In the Docker world, there are two schools: One school is to wrap a single tool into a container, so a build script using five different tools would run in the OS, and activate the five images one by one. The other school says to put the complete build environment, all required tools including a command shell, into one huge container, and run the script in (or give commands interactively to) the shell inside the container. We have selected the second approach. So nothing depends on the host OS; the scripts (or interactive commands) are identical on the Linux build nodes and on the Windows desktop.
Docker on Windows have a significant startup time, regardless of whether we are in Linux or Windows mode. Once the container is running, there are not any significant delays. The system is stable; we haven't had much problems (none that I can remember, that wasn't caused by our own inexperience!). Installation went without problems. Our experience is with Windows Pro; the implementation is somewhat different on Windows Server.
In our first step, the images are of Linux flavor, running Linux tools. We may be going on to the next step: Making Windows flavor containers, running Windows tools. But since Docker in suitable only for command-line tools (and optionally X11, but X11 is virtually unknown in Windows), you are limited to those tools having a decent CLI. That is rather strict limitation in a Windows environment; lots of good tools require a GUI. For any given non-trivial development task, you are likely to want to use at least one GUI tool, so you can't put the entire tool set into a container but must do part of the job in containers, par of it outside.
What are our reasons for going into Docker?
Our build nodes run jobs for a multitude of projects, requiring different tool versions, library versions and what have you. You can never know what state the previous job on the same node left behind, which tool versions it used.
So for a number of years we have (in Windows) had this utility that switches between software configurations: Every job presents a list of the software versions it requires, and if not in place, the utility takes care of switching to the requested version(s). Depending on the tool, that could be to move a symbolic link, change the order in $PATH, ... and in the worst case: Uninstall the current version and install the requested one, before the job continues.
This reconfiguration can take significant time. Also, some tools cause lots of trouble, e.g. they refuse to run via a symbolic link. Or installers for plugins or librarires insisting on installing in the newest version of the main tool, no matter what the links and paths and whatever says is the currently active one. When we resort to uninstall/install, the installer must be able to run silently, and not all of them are. And so on and so on... For being frank: I am sick of it!
With a (partial) move to Linux, we start with blank sheets and can rethink it all. We will put everything in containers, so that the previous run on the same node leaves a "blank" machine, with no traces of any software version. The next job picks up its Docker image, which is ready built, ready to run.
Also, we have had some "disciplinary" problems under Windows: Projects have "secretly" (from the build scripts) installed software not declared in their toolbox, so the build configuration is not controlled; builds cannot be perfectly reproduced. This can also cause problems for the next job: Uninstall is sometimes very version dependent, and the toolbox utility doesn't know how to uninstall an unknown version. Or, it may try to move a symbolic link to another version, but the "secret" version wasn't installed to a symbolic link ... and so on.
In principle, a build running a script in a Docker container may install any software available on the net. But once the container terminates, the installation is gone; it must be repeated every time the image is run, you cannot preserve the current state of the container for the next run (you could, in principle, dump it to a file outside the container, but that is not very realistic).
So we expect to be able to maintain a far better discipline by use of Docker. This comes in from another angle as well:
Small, the Dockerfile single-tool Docker images usually start out with an OS base image, and all the rest is specified in that Dockerfile. Many complex images do it the same way, going all the way from the OS up to the complete tool set in a single Dockerfile. Some of our tools are updated every two week or so (those are our own internal ones), so every two weeks you build yet another version of a huge image, for all the different tool sets that includes the updated one. The building takes quite some time, the registry is filled up with lots of huge images, and the common use of image cache, file space for common layer, and common use of the same memory segment is lost, because they are not common any more.
We will make a quite strictly managed tree structure of images: All the (comparatively) stable tools go at the lower layers, creating another base image. On this base, we put layers of semi-stable tools, making a larger base image. Here we do some branching: We make one second-level image for C/C++ development, another one for Python tasks, a third one for documentation, ... On top of each of these we put furher layers, with less stable tool versions. Still they can be used as base images for an image that adds those updated-biweekly tools. When those tools are updated, we select the appropriate third-level base image; the Dockerfile only includes the updated utility, and builds in a few seconds. It requires very little extra disk space, and all the layers below are shared with a great number of other users.
When someone comes asking for an update of a lower layer, that could affect all other users of it as a base image - the entire subtree of higher images, and we will make sure that the update is in accordance with the future plans of all those projects. Maybe they will suggest "Why don't you update xxx as well, so we combine that into a single update?" So before a project requests a tool update, they know that it is a heavier project, and will request it only if they have a real need for it. (In the Windows environment, we haven't been strict on this; we have been too much willing to accept yet another tool version just because someone argued that 'the new version is better', without giving details). We expect to have far less version proliferation with our tree of (base) images.
IF we introduce the Windows flavor of Docker images, we will follow the same principles, for the same reasons.
|
|
|
|
|
Wow, that's more of an article than a reply.
One of my colleagues is already building Docker Linux containers for a small board controller, these are tiny, only about 3 Mb. Hence my bosses enthousiasm I think, he probably thinks Windows containers will be that size too, but this will obviously be disappointing to him ...
Thanks for taking the time to reply!
|
|
|
|
|
One thing to keep in mind is that the base image is immutable and is shared among all Docker services on the machine that use the same base image.
So if you had 5 services that consisted solely of 1mb executables, and they all used the same Windows Nano base image, you'd only use up about 405MB of disk space. The images built on top of the base image are just stored as a set of diffs from the base image. Though I think if you ask Docker how big each image is, it'll report 401MB - the size of the base image plus the diff - so unless you know about the immutable bit, it'll look like you're using up more space than you actually are.
This can make Hello World apps look huge, but you keep in mind you're only going to have one copy of that base image shared across all apps that use it, it's not so bad. If you take care to ensure that all of your apps and services use the same base image, it can be a pretty sane way to deploy your apps to servers, because you'll get the benefits of having your apps completely self-contained without needing to install each one in its own VM.
The massive Hello World isn't as much of an issue on the Linux side of things if you build on top of an Alpine Linux image. I've packaged up a few server apps written in Go, which statically links everything into a single executable, and my whole image (base + diff) was under 10 megabytes.
|
|
|
|
|
Jealous, jealous of you Linux guys
|
|
|
|
|
Maybe Microsoft will put together a really tiny Windows Docker base image. What's smaller than nano? Windows Server Muon, maybe?
|
|
|
|
|
When Houdini used a trapdoor in every performance, was it a stage he was going through?
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!
|
|
|
|
|
Read quickly, before the answer disappears! It may been when he took a rest from his computer-phase by relaxing in the leisure-domain.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Was it his brother who did saw the ladies?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I don't follow the chain of your logic
Message Signature
(Click to edit ->)
|
|
|
|
|
You are too tied up with yourself.
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!
|
|
|
|
|
And when David Copperfield disappears in a puff of smoke, is this just a phase change?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It's so hard to escape these off-the-cuff remarks.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Quote: Can you imagine hanging over a straight drop -- and staring down 245 feet into the gaping maw of an underwater tunnel?
[^]
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
Yes, I can imagine it, and I pray that I will never experience it.
|
|
|
|
|
the Chinese like to build glass bridges over canyons
now decide: ya wanna go with OSS, or Made in China?
Message Signature
(Click to edit ->)
|
|
|
|
|
|
yeah heard about that. Would freak me out big time.
one thing I can't do is heights (even without the effects), tall buildings I can't even get close to the windows. (planes though don't bother me, even little ones and wild banking.)
Message Signature
(Click to edit ->)
|
|
|
|
|
Open source? Look at the guys sitting next to you when you ride that thing. I would expect to see Isaac Newton having the time of his life and Albert Einstein who is explaining to him what gravity actually is.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
BillWoodruff wrote: Let us pray
Praying for Win10 are we?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
You prefer less eyes inspecting the code? 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
