Updated Solutions to Classic Challenges
A personal website dedicated to helping IT professionals review where we've been, where we are, and maybe where we are headed.
In a previous post, I wrote about setting up SQL Server 2019 via Docker container on Windows 10. Microsoft has championed the fact that they support more than just Windows. I decided to put that to the test and try running SQL Server 2019 on on Mac OS X using Docker. I figure Docker is Docker on pretty much everywhere it’s running, so this should be a piece of cake.
Read MoreOne of the big announcements from the Microsoft Ignite Conference was SQL Server 2019 being made available for public preview. Public preview means the software isn’t very far from being made generally available (GA) to everyone as a finished product. IT Pros who support SQL Server typically take a look at the new version to investigate features and understand how the software might fit into their environment. In this post I show an easy way for IT pros to try using SQL Server 2019 on a Windows 10 computer running Docker.
Read More
Today, ran across an error that I was previously unfamiliar with when running VMware workstation. The error occurred on my Windows 10 laptop with Workstation 14. The error read "VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard." and was displayed as attempted to power on the VM.
A quick google search took me to a vmware KB article (https://kb.vmware.com/s/article/2146361) that lists the cause as "This issue occurs because Device Guard or Credential Guard is incompatible with Workstation." The fix, however, leads to a more general cause - VMware Workstation isn't compatible with Hyper-V. When reading through the fix, the advice starts with instructions for explicitly disabling the "device guard" feature. But then later on, the instructions state to uninstall the Hyper-V role completely. A few more google searches led me to discussion groups where people see issues running the two hypervisors on the same pc. It seems odd in 2018 that this would be an issue, but it seems to be true.
There was a time when I would have done this as I generally prefer the way Workstation handles vms and networking to hyper-v on a laptop. The problem here is that Docker for Windows 10 uses Hyper-V. So the decision isn't just VMware Workstation or Hyper-V, it's VMware workstation vs. Hyper-V AND Docker. Since I'm doing more with learning containers, I elected to not use VMware workstation.
I decided to install Docker on my Windows 8.1 laptop. I’ll also install it on a server in the future and see how easy it is to move containers around. There are lots of moving parts to a full-on container infrastructure, but I’m starting w/ the most basic of building blocks – Docker itself.
The Docker website has instructions for installing the software on the three main platforms out there – Linux, Mac OS X, and Windows. I followed the Windows Instructions. At the time of this writing, version 1.9.0a is the most recent installer. http://docs.docker.com/windows/started/
The first thing that got my attention was the fact that it’s really a small ecosystem that gets installed. The parts consist of:
Docker Client for Windows
Docker Toolbox management tool and ISO
Oracle VM VirtualBox
Git MSYS-git UNIX tools
Device Driver Install for Virtual Box…
At this point the install is supposedly good to go. One difference between the Docker instructions and my install, was a missing virtual box icon on my machine. Otherwise, all seemed fine when I executed the Docker Quickstart Terminal.
… And then .. It’s ready! A quick glance at the IP shows that it’s not on the same network as my laptop. My guess is that there’s some kind of Nat Translation happening behind the scenes.
The instructions on the Docker website remind users that the command prompt for the environment is part of a bash sell, and that they aren’t in Windows anymore. It’s a nice touch and while some might pick up on it, others might not.
The instructions then direct the user to verify the installation by running the command “docker run hello-world.” As they go on to explain, it’s a simple command, but it verifies a lot of important functions:
1. The Docker client contacted the Docker daemon.
2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
(Assuming it was not already locally available.)
3. The Docker daemon created a new container from that image which runs the
executable that produces the output you are currently reading.
4. The Docker daemon streamed that output to the Docker client, which sent it
to your terminal.
Beginning to end the Docker for Windows package took me 15-20 minutes to install, and I was starting with only a conceptual idea of the product. It’s surprisingly simple to setup the core software. Over the next few weeks, I’ll explore other topics such as exploring the various software images available, creating my own image(s), and moving images around between my local machine and AWS (and possibly other public cloud providers).