Docker on Windows Server 2016 – The Journey Begins!

Posts in this series:

  1. Docker on Windows Server 2016 – The Journey Begins (this post)
  2. Docker on Windows Server 2016 – More Info, Please!
  3. Docker on Windows Server 2016 – Who Supports It?
  4. Docker on Windows Server 2016 – Azure Container Registry

I am going to try something different…firststep

I have recently started an evaluation of Docker for Windows Server at work (with the help of my teammates across multiple teams) and we are learning a lot along the way.

Typically, when I write a blog post, it is about something that I have learned, proven out, and/or put into action for some purpose or another. In this case, I am going to blog about our journey in getting Docker (for Windows Server) setup and configured within our organization so we can properly evaluate Docker within our environment and determine if this technology makes sense for us.

So it’s very possible (likely!) that these posts will not be nearly as structured as other posts (although I’m not sure how structured those posts are, either Smile). If the series of posts turn out to have any truly useful information I’ll come back after we’ve completed our evaluation and summarize what has been learned in hopes that others might find it useful as well. So, I apologize in advance if this turns out to be a series of ramblings and non-sequiturs!

Some Background

Before I get started with my initial stream-of-thought blogging I thought it might be useful to provide a bit of background as to where we’re at right now. To keep it simple, I’ll put it in the form of a list:

  • We are primarily a “Microsoft shop”, meaning we use Microsoft development tools and technologies to build software that runs on the Microsoft technology stack.
  • We deploy all custom applications on-premises. While we make use of various cloud-based applications and services we do not yet publish anything to the cloud.
  • We follow CI/CD practices making use of Visual Studio Team Services (VSTS) and Octopus Deploy.
  • We are currently evaluating Microsoft Service Fabric (on-premises) but we have not deployed any Docker containers within Service Fabric.
  • We are relatively new to Docker and have yet to utilize Docker within our environment at all.

What’s the Value?

While there are lots of reasons for implementing a technology like Docker, we’ve come up with the initial list:

  • “Zero Downtime Deployments” get a lot easier!
  • Provides us with a path toward self-hosting (today we host within IIS for web apps and services)
  • Allows our teams to be more agile/nimble (I.e. move faster)
  • Provides us with a path toward hosting in the cloud. While we’re not there yet, if our apps and services are “containerized” then moving to another hosting platform is greatly simplified.
  • Improved isolation
  • Simplified installation of 3rd party applications – assuming they can provide a Docker image.
  • Adopting new technologies gets easier because we can quickly “spin up” a container to try something out and throw it away if we don’t find value in it.
  • To a certain extent, staying viable – I.e. relevant with technology trends across the industry.

There are probably other value propositions that we’re not considering right now. I’d be curious to hear what you think in the comments section below!

So, What’s the Plan?!

Like many journeys, we need to have a plan before we head out, otherwise we don’t know where it is we’re wanting to go and we’ll likely end up wondering in circles getting nowhere!

Here is the high-level version of our plan:

  1. Get Docker Enterprise Edition (EE) for Windows Server 2016 setup and configured within our environment and setup a CI/CD process that allows us to create, publish and deploy Docker Windows containers to Windows Server 2016.
  2. Identify two complex applications (e.g. applications with web-based UIs, web services, database requirements, queuing needs, etc.) and deploy them with the new Docker processes.
  3. Make a decision as to whether Docker makes sense for us.
  4. Assuming it makes sense, create the appropriate guidance and move other products as it makes sense.

We are currently in the first step of the above plan (did I mention that we just started this journey? Smile) and have a sub-plan that looks something like this:

  1. Setup three Windows Server 2016 machines for testing within our development environment. [Done]
  2. Install Docker EE for Windows Server 2016. [Done]
  3. Create a private Docker registry. [Done]
  4. Setup a VSTS build agent on Windows Server 2016 (needed to build Docker images). [In Progress]
  5. Create a VSTS build definition that will create a Docker image and deploy it to the private Docker registry. [In Progress]
  6. Setup a deployment process that will deploy an image from the private registry onto one of the Windows 2016 servers.
  7. Configure Docker to be used in swarm mode and repeat the above steps to deploy an image to the swarm.

Since our environment is completely virtualized, it didn’t take long to have three Windows 2016 servers setup for use. So the first task was an easy one Smile 

Installing Docker EE for Windows Server 2016 was also fairly straightforward. If you follow this link you’ll see a few PowerShell commands toward the bottom that will install Docker and reboot the server. Once the server comes back up, Docker is ready to use! At least, it should be ready to use.

After Docker was installed on the three servers I ran a simple Docker command to test out the installation (on the same page as the PowerShell commands):

  docker run hello-world:nanoserver

This command worked fine on two of the three servers but failed on the third one. After a few unsuccessful attempts to resolve the issue I gave up for the day. The next morning when I came in I tried again and it was working. I have no idea what-so-ever what changed overnight, if anything, but it was working so I was chalking it up as a win! Smile Task #2 complete!

Moving on to task #3 I had no idea how to setup a private registry. However, since we wanted to stay on-premises, I started digging around and came across the Docker docs on how to deploy a registry server. Score! Not surprisingly, the Docker registry is available as an image that can be downloaded from the Docker Hub. So, pull the registry image and spin it up, right? Wrong!

Running this command on Windows Server 2016:

   docker run -d -p 5000:5000 --restart=always --name registry registry:2

Will give you this message:

image

Windows Server 2016 does not yet support Linux containers so this wasn’t an option for us.

Digging further, I was told that the Docker for Windows Server 2016 (Edge) had some preliminary support for hosting the Linux registry on Windows Server 2016. I also learned about Azure Container Registry (ACR) which is an easy-to-setup container registry within Azure.

While our current direction is to deploy products on-premises we are also aware of the benefits of hosting applications and services within the cloud. While we are not there yet we do realize that we’ll likely be there some day (probably sooner vs. later). ACR seems like a great use case for dipping our toes in the proverbial “cloud water” (does that make it rain? Smile) so we decided to give ACR a try.

I logged into my Azure account that is associated with the MSDN Enterprise subscription provided to me by my organization. Unfortunately, we went through our enterprise agreement (EA) renewal process with Microsoft a few weeks back and my MSDN and EA/Organizational accounts got mixed up and my Azure credit was not available to me!

While I figure that out, I decided to create a registry container in ACR using my personal Azure account and it was super simple to setup and configure. Once configured, I was able to login to my private registry from the command line and push an image to the registry which I was then also able to pull down from the registry. While this is on my personal Azure account it’s good enough for now for testing purposes until I get my organization accounts figured out and resolved. So let’s call task #3 done!

At the moment, I am on tasks 4 and 5 – setting up a VSTS build agent and attempting to setup a VSTS build to create and push an image to ACR. The build agent should go very quickly (based on past experience) so I’m actually working through part of #5 first – getting the Docker task to let me select my personal Azure subscription. I have not figured out how to do this yet. The task displays my organizational Azure subscriptions (even though I can’t use any of them) but I haven’t figured out how to get it to list my personal Azure subscriptions. I have an e-mail out to some folks at Microsoft and other “insiders” hoping to get some guidance. Once I figure that out I’ll setup the build agent and see how far we get.

What’s Not in the Plan?

As we get better versed on Docker for Windows Server 2016 there are other Docker-related technologies, patterns and architectural approaches that we need to learn more about, including:

  • Reliable queues and collections – these are concepts that are inherent to Service Fabric that we’d like to mimic in Docker. I’m sure there are accepted ways of accomplishing this, we just need to learn more about it.
  • Docker secrets – we think the idea of storing connection strings, URLs, credentials/tokens (for third party services), etc. in Docker secrets seems to make sense. We’re planning to explore this further once we get through the initial phase.
  • Patching images – we’re still new to this game so we’re not sure if there is a standard approach, or even need, to patch existing Docker images so we’ll need to research this one further.
  • Other things that we haven’t even thought of yet and didn’t even realize we need to know Smile

Next Steps

So, my next steps are to work with the appropriate folks within my organization to deal with my jacked-up organizational accounts so I can get my Azure subscriptions working. In the meantime, I’m hoping to figure out how to utilize a personal Azure subscription so I can continue with the testing efforts. I’ll report back on what I discover/accomplish in the next post.

So, that’s what we’re up to so far with Docker for Windows Server 2016. While we know that we’re really early in the adoption of Docker on Windows (via Windows containers) I’m hopeful that we’ll be able to build a complete CI/CD pipeline on Windows servers using Windows containers and bring value to our organization.

I’m really interested in hearing about your experiences with Docker on Windows if you’ve also chosen to start down this path. Anything I can learn from others is a huge benefit! I’m also hopeful that we’ll help a few others out along the way as well.

Until the next post…

Comments are closed.

Related Posts