Deploying Dockerized .NET Apps Without Being a DevOps Guru
This is a guest post by Julie Lerman. She is a Docker Captain, published author, Microsoft Regional Director and a long-time Microsoft MVP who now counts her years as a coder in decades. She makes her living as a coach and consultant to software teams around the world. You can follow Julie on her blog at thedatafarm.com/blog, or on Twitter at @julielerman.
.NET Developers who use Visual Studio have access to a great extension to help them create Docker images for their apps. The Visual Studio Tools for Docker simplify the task of developing and debugging apps destined for Docker images. But what happens when you are ready to move from debugging in Visual Studio to deploying your image to a container in the cloud?
This blog post will demonstrate first using the tooling to publish a simple ASP.NET Core API in an image to the Docker hub, and then creating a Linux virtual machine in Azure to host the API. It will also engage Docker Compose and Microsoft SQL Server for Linux in a Docker container, along with a Docker Volume for persistence. The goal is to create a simple test environment and a low-stress path to getting your first experience with publishing an app in Docker.
Using the Docker Tools to aid in building and debugging the API is the focus of a series of articles that were published in the April, May and June 2019 issues of MSDN Magazine. So I’ll provide only a high level look at the solution.
Overview of the Sample App
The API allows me to track the names of Docker Captains. It’s not a real-world solution, but enough to give me something to work with. You can download the solution from github.com/julielerman/dockercaptains. I’ll provide a few highlights here.
public class Captain
{
public int CaptainId { get; set; }
public string Name { get; set; }
}
The API leverages Entity Framework Core (EF Core) for its data persistence. This requires a class that inherits from the EF Core DbContext. My class, CaptainContext, specifies a DbSet to work from and defines a bit of seed data for the database.
Enabling a Dynamic Connection String
The startup.cs file uses ASP.NET Core’s dependency injection to configure a SQL Server provider for the CaptainContext. There is also code to read a connection string from an environment variable within the Docker container and update a password placeholder that’s less visible to prying eyes.
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
var conn = Configuration[“ConnectionStrings:CaptainDB”];
conn = connectionstring.Replace(“ENVPW”, Configuration[“DB_PW”]);
services.AddDbContext<CaptainContext>(options => options.UseSqlServer(conn));
}
The VS Tools generated a Dockerfile and I only made one change to the default — adding the CaptainDB connection string ENV variable with its ENVPW placeholder:
ENV ConnectionStrings:CaptainDB “Server=db;Database=CaptainDB;User=sa;Password=ENVPW;”
ASP.NET Core can discover Docker environment variables when running in a Docker container.
Orchestrating with a docker-compose file
Finally comes the docker-compose.yml file. This sets up a service for the API image, another for the database server image and a volume for persisting the data.
version: ‘3.4’
services:
dataapidocker:
image: ${DOCKER_REGISTRY-}dataapidocker
build:
context: .
dockerfile: DataAPIDocker/Dockerfile
environment:
– DB_PW
depends_on:
– db
ports:
– 80:80
db:
image: mcr.microsoft.com/mssql/server
volumes:
– mssql-server-julie-data:/var/opt/mssql/data
environment:
SA_PASSWORD: “${DB_PW}”
ACCEPT_EULA: “Y”
ports:
– “1433:1433″
volumes:
mssql-server-julie-data: {}
Notice that I’m declaring the DB_PW environment variable in the API’s service definition and referencing it in the db’s service definition.
There’s also an .env file in the solution where the value of DB_PW is hidden.
DB_PW=P@ssword1
Docker will read that file by default. I go into more detail about the .env file on my blog.
I got this solution set up and running from within Visual Studio on my development machine. And I love that even when the debugger publishes the app to a local container, I can still debug while it’s running in that container. That’s a super-power of the tools extension.
Using the Tools to Publish to Docker Hub
Once I was happy with my progress, I wanted to get this demo running in the cloud. Although I can easily use the CLI to push and pull, I love that the Docker Tools in VS can handle this part. The Dockerfile created by the tool has instructions for a multi-stage build. When you target Visual Studio to a release build, the tools will build the release image described in the Dockerfile. Publishing will rebuild that release image and publish it to your destination registry.
You can see my full solution in the screenshot below. My API project is called DataAPIDocker. Notice there is also a docker-compose project. This was created by the Docker Tools. But it is the DataAPIDocker project that will be published first into an image and then to a repository.
This will present a Publish page where you can choose to create a New Profile. A publish profile lets you define where to publish your app and also predefine any needed credentials. Creating a profile begins with selecting from a list of targets; for publishing a Docker image, select Container Registry. That option then gives you predefined registries to choose, such as Azure Container Registry, Docker Hub, or a custom registry – which could be an instance of Docker Trusted Registry.
I’ll choose Docker Hub and click Publish.
The last step is to provide your Docker Hub repository name. If you don’t already have docker.config set up with your credentials, then you also need to supply your password.
After creating a profile, it gets stored in the Visual Studio project.
You’ll be returned to the Publish overview page with this profile selected, where you can edit the default “latest” tag name. Click the Publish button to trigger the Docker Tools to do their job.
A window will open up showing the progress of the docker push command run by the tools.
After the push is complete you can open the repository to see your new repository which by default is public.
Setting up an Azure Linux VM to Host the Containers
Now that the image is hosted in the cloud, you can turn your sights to hosting a container instance for running the app. Since my Visual Studio Subscription includes credits on Azure, I’ll use those. I will create a Linux Virtual Machine on Azure with Docker and Docker Compose, then run an instance of my new image along with a SQL Server and a data volume.
I found two interesting paths for doing this at the command line. One was by using the Azure CLI at the command line in Windows, macOS or Linux. It is so much easier than doing it through the Azure Portal.
I found this doc to be really helpful as I was doing this for the first time. The article walks you through installing the Azure CLI, logging into Azure, creating a Linux VM with Docker already installed then installing Docker Compose. Keep in mind that this will create a default machine using “Standard DS1 v2 (1 vcpus, 3.5 GB memory)” setup. That VM size has an estimated cost of about $54 (USD) per month.
Alternatively, you can use Docker Machine, a Docker tool for installing Docker on virtual hosts and managing the hosts. This path is a little more automated but it does require that you use bash and that you start by using the Azure CLI to log into your Azure account using the command az login.
Once that’s done, you can use parameters of docker-machine to tell it you’re creating this in Azure, specify your subscription, ssh username, port and size of the machine to create. The last uses standard Azure VM size names.
I found it interesting to use the Azure CLI workflow which was educational and then consider the docker-machine workflow as a shortcut version.
Since I was still working on my Windows machine, and don’t have the Windows Subsystem for Linux installed there, I opened up Visual Studio Code and switched my terminal shell to use bash. That let me use docker-machine without issue.I also have the Azure Login extension in VS Code, so I was already logged in to Azure.
I first had to get the subscription ID of my Azure Account which I did using the CLI. Then I plugged the id into the docker-machine command:
docker-machine create -d azure
–azure-subscription-id [this is where I pasted my subscript id]
–azure-ssh-user azureuser
–azure-open-port 80
–azure-size “Standard_DS1_v2″
mylinuxvm
There are more settings you can apply, such as defining the resource and location. The output from this command will pause, providing you with details for how to allow docker-machine authorization to the VM by plugging a provided code into a browser window. Once that’s done the command will continue its work and the output will forge ahead.
When it’s finished, you’ll see the message “Docker is up and running!” (on the new VM), Followed by a very important message to configure a shell on the VM by running:
“C:Program FilesDockerDockerResourcesbindocker-machine.exe” env mylinuxvm
Recall that I’m doing these tasks on Windows, so docker-machine is ensuring that I know where to find the executable. After performing this task, I can see the machine up and running in the Azure Portal. This lets me inspect other default configuration choices made because I didn’t specify them in the docker-machine command.
By default, all of the needed ports are set up for access such as 80 for http and 22 for ssh.
Re-Creating Docker-Compose and .env on the VM
We only need two files on this machine: the docker-compose.yml and the .env file.
Docker-machine allows you to easily ssh into the VM in order for your command line commands to execute on that machine.
docker-machine ssh mylinuxvm
Then you can use a linux editor such as nano to re-create the two files.
nano docker-compose.yml
And you can paste the contents of your docker-compose file into there. This is the docker-compose file in my solution for the sample app. However, there are two edits you’ll need to make.
The original file depends on a variable supplied by the VS Docker Tools for the registry location. Change the value of image to point to your Docker Hub image: image: julielerman/dataapidocker:formylinuxvmYou’ll also need to change the version of docker-compose specified at the top of the file to 2.0 since you’re moving from hosting on Windows to hosting on Linux.
In nano, you can save the docker-compose file with ^O. Then exit nano and run it again to create the .env file using the command:
nano .env
Paste the key value pair environment variable from the app and save the .env file.
Running the Container
I still had to install docker-compose on the new machine. Docker is nice enough to feed you the command for that if you try to run docker-compose before installing it.
sudo apt install docker-compose
Then I was able to run my containers with: sudo docker-compose up
One important thing I learned: The VS Docker tooling doesn’t define port mapping for the API service in docker-compose. That’s hidden in a docker-compose.override.yml file used by the debugger. If you look at the docker-compose file listed earlier in this article, you’ll see that I added it myself. Without it, when you try to browse to the API, you will get a Connection refused error.
My ASP.NET Core API is now running and I can browse to it at public IP address specified for the VM. The HTTP Get of my Captains controller returns a list of the captains seeded in the database.
DevOps are for Devs, Too
As a developer who is often first in line to claim “I don’t do DevOps”, I was surprised at how simple it turned out to be to deploy the app I had created. So often I have allowed my development machine to be a gate that defined the limitations of my expertise. I can build the apps and watch them work on my development machine but I’ve usually left deployment to someone else.
While I have ventured into the Azure Portal frequently, the fact that the Docker Tools and the Azure CLI made it so simple to create the assets I needed for deploying the app made me wonder why I’d waited so long to try that out. And in reality, I didn’t have to deploy the app, just an image and then a docker-compose file. That the Docker Machine made it even easier to create those cloud assets was something of a revelation.
Part of this workflow leveraged the Docker Tools for Visual Studio on Windows. But because I spend a lot of time in Visual Studio Code on my MacBook, I now have the confidence to explore using the Docker CLI for publishing the image to Docker Hub. After that I can just repeat the Docker Machine path to create the Azure VM where I can run my containers.
If you want to learn more, these posts and articles are a great place to start:
5 Things to Try with Docker Desktop WSL 2 Tech Preview Video Series: Modernizing .NET Apps for Developers EF Core in a Docker Containerized App (3 part series in MSDN Magazine)Julie’s blog posts on docker-compose and publishing Docker images to Azure
Get Started with Docker Desktop
How to Deploy Dockerized .NET Apps Without Being a DevOps Guru by #Docker Captain @julielermanClick To Tweet
The post Deploying Dockerized .NET Apps Without Being a DevOps Guru appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/
