Microsoft: Your Linux Docker containers are now OURS to command Microsoft has taken its first baby steps toward integrating Windows with the Docker application containerization tech that's caught fire in the Linux world, with the release of Docker client software that runs on Windows desktops. The client doesn't let you run Windows applications in containers. Microsoft is still working …
"Now, how's WinSock & POSIX coming along?"
Hold on, give them a chance - they've only just figured out how to do virtual desktops which apparently will be a Big Thing in Windows 10. Thats only about 25 years after they first appeared in an X Windows window manager.
A this point, the Windows version sounds very preliminary and not for the faint of heart. Meanwhile, Docker is in Ubuntu 14.04, which means installation there is a matter of a couple of mouse clicks in the Software Centre. If anyone just wants to play with Docker (as opposed to working on doing the port), then they are probably far better off installing Ubuntu (or other distro of your choice) and using that.
I'm presently working on something which isn't related to Docker, but it's instructive because it's also a cross platform project. It's a C library for Python. Developing for Linux was simple - write and debug. The compiler and build tools simply installed and worked without problem, the compiler and Python documentation was quite good, and all I had to worry about was my own C code.
Now it's all working (both 32 and 64 bit versions), so the port to Windows should be a simple re-compile, right? Wrong! To make a long story short, there after followed many long hours of struggling with the poor MS documentation and deciphering of MS marketing gibberish into plain language, useless compiler error messages, a trip back in time into 1980s compiler archaeology (VS 2010 is only C89? WTF!???), #ifdefs and macros to get around Microsoft's non-standard take on things (as in they admit themselves it's non-standard), and a dawning realization that their limited library implementation means that the Windows version is going to have to settle for not having all the features present in the Linux version. So much for 'C' language portability. It only really works if the people writing the compiler actually want to be portable.
The Docker stuff mentioned in the article is in Go rather than C and thus there's no need to use one of Microsoft's compilers, but I imagine that many new and innovative frustrations of other sorts await anyone who temps fate with being on the bleeding edge of this porting effort. If that's the sort of thing that appeals to you, then fill your boots. If not, the path of least resistance for Docker adventurers is going to be using Linux.
' but if you're familiar with the process on Linux, you should have no trouble'
If you have been using the process on Linux then why on earth would you be looking to run a limited version on Windows, especially when two articles across from this was how you need to put on a patch to stop users getting full Admin rights in Windows.
"especially when two articles across from this was how you need to put on a patch to stop users getting full Admin rights in Windows."
Just like the get admin hole in the Norks version of Linux also on the same page?
Linux has a far worse history than Windows for this kind of thing - 151 known privilege escalation vulnerabilities found so far in the Linux kernel alone - and 20 in the past year - and that's without even considering a complete Linux distribution:
http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
http://www.cvedetails.com/vulnerability-list/vendor_id-33/product_id-47/year-2014/opgpriv-1/Linux-Linux-Kernel.html
Windows Server 2012 in comparison only had 12 privilege escalation vulnerabilities in the past year.
At least to me is that MS are doing this, in the past they would have gone off and reinvented the wheel, called their implementation the only one worthwhile for enterprise and people would have gone with it.
Just goes to show how far the Linux world has come that MS wants to be involved and involved by co-operation not intimidation, may not be my cup of tea, but it is good to see IMHO.
I haven't had any experience with Docker as, alas, I mostly work with MS products these days. This is happily soon to change, though. I did a quick dig through the Docker web site and hoped that someone might answer a question. The diagram comparing VMs with "Dockerized" apps seems to directly compare the hypervisor with the Docker Engine. This would seem to imply that the containers would be kept separate in all ways as VMs are (at least in principle), but the documentation indicates there is a way to tie Docker containers together. This looks like it is a typical development tool in that it puts ease of use ahead of basic security concerns. Am I missing something here?
The linking is done through networking, in much the same way that you could set up two VM's on their own isolated network within a hypervisor. It just says "these containers need to talk to each other over the network".
For example, you may have a container running MySQL which wants to listen on port 3306. By default, no traffic can get to this port. If you used the -p switch, any traffic directed at the host on the port you choose could be directed at this 3306 port. But if you didn't want the MySQL to be visible to the world, and only wanted it to be visible to another container (such as the one your application is in) you could link the two containers together using the --link switch.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
