Developer lab for Azure Container Services, including SQL Server 2017 on Linux on Docker and a very basic microservice. Developed for presentation at Azure Global Boot Camp 2018.
Switch branches/tags
Nothing to show
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Failed to load latest commit information.
DockerDemo
.gitignore
Azure Bootcamp 2018 - Containers.pptx
Azure Bootcamp 2018 - InventoryDB.sql
Azure Bootcamp 2018 - Workshop.docx
Azure Bootcamp 2018 - Workshop.pdf
README.md

README.md

Azure Bootcamp 2018

Contents

Prereqs ........................................................................... 1

Getting started ................................................................... 1

Workshop 1 – Inventory “microservice” on Docker ................................... 4

Run a SQL Server container ........................................................ 4

Get an API going .................................................................. 4

Add Docker Support ................................................................ 5

Take a copy of the DB and reset ................................................... 7

Add docker-compose support ........................................................ 8

Workshop 2 – Push the Inventory microservice to ACS ............................... 8

Deploy an ACS cluster ............................................................. 8

Set up your Docker Hub account .................................................... 9

Make a release build of the microservice API ...................................... 9

Push your images to Docker Hub .................................................... 10

Set up the KubeCtl tool ........................................................... 11

Deploy our microservice to ACS .................................................... 12

Workshop 3 – Make your own Container Registry (ACR) ............................... 13

Prereqs

Don’t worry if you don’t have all of these yet!

  • Docker for Windows
  • SQL Server 2017 Docker image.
  • Azure CLI for PowerShell.
  • SQL Server Management Studio.
  • Postman.

Getting started

You can do this while Bernard is talking if necessary.

Make sure that you have enabled shared access across your drives:

  • Get the SQL Server 2017 image – might take a little while: $ docker pull microsoft/mssql-server-linux:2017-latest

  • Confirm download:

    $ docker images

Workshop 1 – Inventory “microservice” on Docker

We’re going to build an extremely simple microservice (hence the quotation marks) using Docker for Windows, Docker Compose and SQL Server 2017 on Docker. Then we’re going to populate it using Postman.

Run a SQL Server container

  1. Run the SQL image – create a container (change the port if you have a default SQL Server instance running on your machine already):
    $ docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=P@ssw0rd" - p 14 33 :1433 --name sql1 -d microsoft/mssql-server-linux:2017-latest
  1. Verify the container is running:
    $ docker ps
    $ docker container ls
  1. Log in to the DB server:
  2. Run the SQL script to create the InventoryDB: https://gist.github.com/bernardoleary/faf1e515d40f38db7fcf2aeb29bb4a3b Populate the InventoryDB with some stuff manually if you like.

Get an API going

  1. Get the code for the demo solution: $ git clone

  2. Take a look at Startup.cs – especially if you have not used dotnet core much in the past, note the baked-in IoC management (IServiceCollection). Also note the database connection details.

  3. Run the solution and browse to the DB controller:

  4. Now we can populate the DB using Postman:

    {"id":4,"name":"pineapples","quantity":20000}
    [http://localhost:53346/api/database](http://localhost:53346/api/database)
    Content-Type application/json
  1. Note that this solution is not running as a container – it is on IIS Express – but the database is on a container.

Add Docker Support

  1. Now add “Docker Support” to the dotnet core project: Target Linux (because our SQL Server container is running on Linux also): This will add another project to your solution called “docker-compose”. Note that your debug options have changed to “Docker” only (“IISExpress” is gone). Also a file called “Dockerfile” has been added to your dotnet core project.
  2. Run the Docker-ised solution in debug mode. What happens when you try to reach http://localhost:/api/values? What happens when you try to reach http://localhost: /api/database?
  3. Go to your PowerShell prompt and run:
$ docker image ls

This will list all images – note that there are two new images there now – one for your application and one for microsoft/aspnetcore. Docker has downloaded the microsoft/aspnetcore image because it is required to run our dotnet core web application – this is specified in the Dockerfile (take a look).

  1. Now list your running containers: $ docker image ls You should see there are two containers running – one is out SQL DB, the other is our dotnet core web application.

    Why can the web-app not see the DB? Remember that Docker is like a miniature datacentre running on your PC – complete with networks. You can inspect the networks and see what containers are running on them:

$ docker network ls

$ docker network inspect Unless it is told to, Docker will not put containers on the same network – hence why our containers aren’t able to see each other.

Take a copy of the DB and reset

  1. Because Docker images are stateless, when we create a container from one it will spawn from scratch (a blank DB server) – so to avoid having to recreate the DB, we take a copy of the running container and commit it as an image – like this (get the container ID by running a “$ docker ps”):
$ docker image ls
  1. Stop debugging and clear out all containers:
$ docker stop $(docker ps -a -q)
$ docker rm $(docker ps -a -q)

Check that no containers are running:

$ docker ps

Add docker-compose support

  1. Open the file named docker-compose.yml. Note that only our web-app’s container is listed. We need to start the inventory container at the same time using docker-compose so that they containers are on the same network. Add the highlighted lines to the docker file:
    version: '3'
    services:
    dockerdemo.api:
    image: dockerdemoapi
    build:
    context:.
    dockerfile: DockerDemo.Api/Dockerfile
    dockerdemodb:
    image: inventorydb
  1. Open Startup.cs and change the following line of code: Environment.GetEnvironmentVariable("SQLSERVER_HOST") ?? " dockerdemodb";
  2. Run the solution in debug mode again and try to reach the “/api/database” endpoint. Run a “$ docker ps” to see that you have your two containers running. The API container can now look up the hostname dockerdemodb and get back that container’s IP address. Same goes for any other container we run as part of this solution using docker-compose.

Workshop 2 – Push the Inventory microservice to ACS

We’re going to make a Docker Hub account, push our Docker images to Docker Hub and finally we’ll launch them to Kubernetes on Azure (ACS).

Deploy an ACS Kubernetes cluster

  1. Open PowerShell and login to Azure:
    $ az login

Set our subscription ID:

$ az account set --subscription “<subscription id>”
  1. Create a new Resource Group for this workshop, which we’ll put the K8s (K8s is short for Kubernetes) cluster on – note, the Resource Group must be in eastus or another region that support K8s on ACS:
    $ az group create -l eastus - n ABC- K8s
  1. Create our K8s cluster – this will take about 10 - to- 15 minutes:
    $ az acs create -n ABC-Kube-Cluster -d ABC-Kube -g ABC-K8s --generate-ssh-keys --
    orchestrator-type kubernetes --agent-count 1 --agent-vm-size Standard_D1_v

Once you see the “Running ..” prompt you should be able to see the cluster deploying on the Azure portal.

Set up your Docker Hub account

  1. Go to https://hub.docker.com and sign-up – too easy!

Make a release build of the microservice API

  1. Go back to VS and change your build mode to “Release” and re-run our microservice. Note that once the build/run is completed that there is a new tag in our dockerdemoapi image tagged “latest”. Previously we only had one image in the repo, with a “dev” tag:
  2. Test that the microservice works by changing our docker-compose.yml and docker- compose.override.yml file subtly to match our new images and running “$ docker-compose up” and/or running the release build in VS:
docker-compose.override.yml
version: '3'
services:
dockerdemoapi:
environment:
- ASPNETCORE_ENVIRONMENT=Development
ports:
- "80"
docker-compose.yml
version: '3'
services:
dockerdemoapi:
image: <your docker hub namespace>/dockerdemoapi
build:
context:.
dockerfile: DockerDemo.Api/Dockerfile
dockerdemodb:
image: <your docker hub namespace>/inventorydb
  1. Using the Docker “ps” and “commit” commands, make copies of your images that are prefixed with the namespace that you have created for your Docker Hub profile. Docker Hub namespace – my one is “abcdockerdemo”. Commit command to make images that are prefixed with your Docker Hub namespace:

Push your images to Docker Hub

  1. Login to Docker:
    $ docker login
  1. Push your images to Docker Hub:
    $ docker push <your docker hub namespace>/dockerdemoapi:latest
    $ docker push <your docker hub namespace>/inventorydb:latest

You should be able to see your new repos on Docker Hub when you have finished.

Set up the KubeCtl tool

  1. Make a folder called “kubectl” under your “C:\” then run:
    $ az acs kubernetes install-cli --install-location=C:\kubectl\kubectl.exe
  1. Put kubectl on your PATH.
  2. Get the key that will enable you to interact directly with ACS from the command line:
    $ az acs kubernetes get-credentials --resource-group=ABC-K8s --name=ABC-Kube-Cluster

You should see the output as follows:

    Merged "k8s-kubemgmt" as current context in C:\Users\bernardo\.kube\config
  1. Start the kubectl proxy:
    $ kubectl proxy
You should see output as follows: “Starting to serve on 127.0.0.1:8001”
Browse to [http://localhost:8001/ui](http://localhost:8001/ui)

Deploy our microservice to ACS

  1. Add a deployment file that we will use to upload to Kubernetes – I called mine dockerdemo.yml:
apiVersion: extensions/v1beta
kind: Deployment
metadata:
name: abcdockerdemo-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: abcdockerdemo
spec:
containers:
- name: dockerdemoapi
image: <your docker hub namespace>/dockerdemoapi:latest
ports:
- containerPort: 80
- name: inventorydb
image: <your docker hub namespace>/inventorydb:latest
ports:
- containerPort: 1433
  1. Deploy to ACS:
$ kubectrl apply -f dockerdemo.yml

You should be able to see the Kubernetes pods, etc, deploying via the UI – the images are being pulled from Docker Hub: 16. Request a load balancer setup so that we can expose the API on the internet:

    $ kubectl

Get the list of running services, as shown above – you should see that there is an IP address being applied to the “dockerdemo-deployment” (as above). This takes a little while to apply.

$ kubectl get services
  1. All going well you should be able to see a result in our “/api/values” and “/api/database” endpoints.

Workshop 3 – Make your own Container Registry (ACR)

We’re going to make our own container registry on ACR, push our images to it and connect our ACS instance to it...