Preparing your Microservice for Production
Although we’ve primarily been showing off local volume mounting for development and testing purposes, most customers don’t want to do local volume mounting in production, and instead want to copy all source code and dependencies directly into the container. This enables more isolation simplifies release management so that deployment is as easy as stopping and starting containers without having to manually sync or replace source code on the host virtual machine. To prepare your microservice for production, there are a set of common steps, you’ll take:
Add any Dependencies
You’ll want to ensure that all required packages, tools, and dependencies that aren’t already in the base image are copied or downloaded as part of the Dockerfile definition when creating the Docker image. If some of those tools or dependencies won’t change every time you build, consider instead including them in a base image instead of copying them every time you build your Docker image. For our product catalog microservice, we can add NuGet package dependencies into the image by adding a RUN command to restore NuGet packages.
Optimize your Source Code
You’ll also want to ensure you’re optimizing your code for production. What this means is we want to do the opposite of the tasks we did for development, such as switching from debug to release, turning off debugging or changing trace settings, or removing debug-only environment variables. For ASP.NET Core 1.0, we can use the dotnet pack (currently dnu pack) and publish features and choose between static or dynamic compilation.
Web applications also typically have a set of client-side performance optimizations, such as minifying JavaScript, compiling CoffeeScript, or bundling and minifying LESS/SASS into CSS files. These are typically done using Grunt or Gulp task runners, and can either be done as a step before creating your Docker image or as part of the process for building your Docker image, meaning they could run inside the container itself when you execute the Docker Build command.
JavaScript Task Runners
Grunt (https://gruntjs.com) and Gulp (https://Gulpjs.com) are two popular client-side task runners that provide a huge ecosystem of reusable plug-ins to automate client side tasks. The tasks can be chained together in a workflow as well. For example, if you have 1,000 PNG images you need stored in AWS or Azure, you can run a task to optimize the PNGs and create responsive versions of them for different devices. You can then upload them to AWS S3 or Azure Blob storage using prebuilt plug-ins.
Although we’ve gotten the code ready for production, that doesn’t mean the code works correctly, or is high-performing, or can handle load. We’ll look at a full suite of tests for measuring code quality as part of a continuous delivery pipeline in Chapter 6.
Enable Dynamic Configuration
Your microservice should be able to run host-agnostic, meaning it can run in dev, staging, and production. You could have a number of different configuration settings like a connection string to a database, a feature flag to show or hide product recommendations, or a diagnostic setting to capture information or warnings. Each of these settings can be set when the container is created, or dynamically changed versus being hard-coded to a set value. In the Chapter 5, “Service Orchestration and Connectivity,” we’ll discuss different options for service discovery, like Consul or Zookeeper, that provide a more dynamic way to retreive configuration settings or connection strings.
Ensure You Test Your “Production-Ready” Microservice
Although we will cover the different types of tests in Chapter 6, and how to integrate testing into the continuous integration process, the key point is to make sure that you are testing the microservice and Docker image as much as possible to the way it will run in production.