Deploy and Manage Container App with Service Fabric

In this lab we will Deploy and Manage Container App to Azure Container Services

DevOps MPP Course Source

Working with Containers

Pre-requisites:

Lab Tasks:

  • Create a Service Fabric Cluster on Windows via the Azure Portal
  • Create a Linux cluster using an ARM Template
  • Integrate Operations Management Suite (OMS) and Service Fabric for Monitoring
  • Perform Backup and Restore on a Service Fabric Application deployed to a local cluster

Estimated Lab Time:

  • approx. 90 minutes

Task 1: Create a Service Fabric Cluster on Windows via the Azure Portal

  1. Click on Code and then click on the project name and select New repository, to create a new repo using the following values
  • Type: Git
  • Repository name: Cntr1VSTSrepo (or something like that)
  • Add a README to describe your repository: check the box
  • .gitignore: None

  1. Create a folder C:\Dockerfile on the local drive and copy the files you used in the earlier lab Working with Containers

    If you already have this folder and files present from earlier you do not need to re-create them. If you do not have it from earlier, follow the steps in the earlier lab task in the section Task 3: Build a new Container Image > Create a container image using the docker build file, steps 1 to 4, to create these two files.

  2. Go to the repo and click Upload files, then add the files you have copied to your local drive in step two above.

    • Dockerfile
    • Index.html

  3. Accept all other defaults and click Commit

  4. View the files within the repo in VSTS and verify the content displays fine.

Task 2: Create a Linux cluster using an ARM Template

It is possible, and sometimes preferable and easier to use the VS2017 agent available in VSTS, however we will be deploying a container to the build agent and as such, we will configure a dedicated machine. We will use an Azure virtual machine. However, it is possible to also use your local environment, if you have a Windows 10 machine.

In general, building on a local machine and verifying your work when checking in files before, committing to a master branch can be very useful and efficient.

To enable your build agent perform the following three sections.

1) Create an Azure Virtual machine to use as the build agent

We need to create an Azure Virtual machine that will act as our VSTS build agent, if you haven’t already done you can do so now.

- Create an Azure IaaS virtual machine using the following settings
  - Image = **Windows Server 2016 Datacenter – with Containers** (we use this as nested virtualization is required to be able to deploy containers to the build agent)
  - Name=**WS2016CntrsBA (or something like that)**
  - VM disk type = **HDD**
  - Username = **< any user name >**
  - Password = **< any qualifying password >**
  - Subscription = **< Your Azure subscription >**
  - Resource Group = **ws2016cntrsBA_rg (or something like that)**
  - Location = **< your nearest data center location >**
  - Size = **DS1_V2**
  - Settings = **accept the remaining default settings and deploy the virtual machine**
- Wait for the virtual machine to deploy, and once it is complete sign in and verify the docker commands run successfully.
- You may also optionally install Visual Studio 2017 Community Edition. This is a free edition. This is not strictly required to be the build agent, but if you encounter issues, it may assist with troubleshooting.

2) Create a Personal Access Token (PAT)

We need to create a PAT for our build agent to be able to access the VSTS account and project.

  - In your VSTS project, click on your account icon in the top right i.e. and select Security
  - In the Personal access tokens window click Add and enter the following details
  - Description: < some description i.e. PAT for local build agent)
  - Expires: < default >
  - Accounts: < default value >
  - Authorized Scopes: All scopes

Copy the highlighted Token now and pastes it somewhere you can access it. It should look something like the below

**4avrb33twjq3f5wlqbkx7jzimmzt6h7ktyybbdojtu32x7yd3t2q**

If you close the window before you copy the token, you will need to repeat steps 1 -3 here to obtain a new token.

3) Install and configure the agent.

We now need to download and configure the agent on the local machine. The following steps can be carried out on your build agent.

1. Access your VSTS account from within the build agent, i.e. the azure virtual machine. This just makes it easier to directly install and configure the build agent on the build agent directly.

2. In VSTS, open your build definition by going to your project i.e. Cntr1Proj (or whatever you have called it) and click Builds, then click on the Settings icon in the top ribbon and select Agent queues.

3. Click Download Agent, and in the Get agent dialogue, click Download and save the agent to the default location. Leave the Get agent dialogue open, as you will copy the commands you need to run from here.

4. Open PowerShell as an administrator and go to the root of the drive using the command cd\

5. Return to the Get agent window, copy the first command listed and paste it into PowerShell and run it i.e. 

    ```
    Mkdir agent ; cd agent
    ```
    This just creates a folder C:\agent and enters that folder

6. Copy the second command in the Get agent dialogue and paste it into PowerShell, it should look something like this

    ```
    Add-Type -AssemblyName System.IO.Compression.FileSystem ; [System.IO.Compression.ZipFile]::ExtractToDirectory("$HOME\Downloads\vsts-agent-win7-x64-2.119.1.zip", "$PWD")
    ```

    Ensure you copy the command from the window and not this document, as the file version will change over time and the get agent dialogue command will have the latest version.`

7. Open a command prompt window, go to the folder C:\Agent and run the command
.\config.cmd,

8. Enter the following values when prompted
    - Connect:
      - Enter server URL: https://<your VSTS account>.visualstudio.com
      - Enter authentication type (press enter for PAT): < press Enter >
      - Enter personal access token: < Paste the value you obtained in the Crate a Personal Access token section earlier i.e. it should look something like 4avrb33twjq3f5wlqbkx7jzimmzt6h7ktyybbdojtu32x7yd3t2q >

    - Register Agent:
      - Enter agent pool (press enter for default): <Accept default by pressing Enter >
      - Enter agent name (press enter for <your machine name>): <Accept default by pressing Enter >
      - Enter work folder (press enter for _work) ><Accept default by pressing Enter >
      - Enter run agent as service? (Y/N) (press enter for N) > Y
      - Enter User account to use for the service (press enter for NT AUTHORITY\NETWORK SERVICE): <Enter the value NT Authority\SYSTEM >

    Note: If you use the default account, i.e. the NT Authority\Network Service account, it will not have sufficient Log on as Service permissions to successfully complete the VSTS build tasks and you will receive an error when you go to build. You could also modify the service account settings for VSTS Agent <accountname>.<machinename> in the Services.msc, and modifying the Log on as a Service setting there.

    - You should receive several successful messages as it installs and configures the agent settings.

9. In VSTS, go to the **Agent queues** again and then the **Default**.

10. View the **Agents for the pool Default** and verify your machine is listed and has a State of Online. This can also be accessed via the **Settings** icon > **Agent queues**

11. Click on **Manage Pools and under **All Pools** go to **Default**

12. Ensure your build agent is listed and Enabled, with a **State of Online**. This can also be accessed via the S**ettings** icon > **Agent Pools**

13. Spend a moment to click around the various options and settings available in the agent pool.

Task 3: Integrate Operations Management Suite (OMS) and Service Fabric for Monitoring

Note: As releases and updates occur frequently in VSTS, there may be some differences in the steps below and what appears in the VSTS environment. Where discrepancies occur you should try to adhere to the main configuration points below and accept the default values where possible.

  1. Go to Build and Release and click on Builds and then click on + New definition

  2. Under Select a Template choose Empty and give the build a name, something like cntrs1 build

  3. In the Default agent queue drop down choose Default

    Note: Some agent queue options are

    • Default value will allow you run against a local build agent in these steps, but the agent needs to be installed and configured to use this. If it is not installed it will return an error.
    • Hosted – legacy build agent potion based around VS2013 and VS2015
    • Hosted VS2017 - this has Docker compose tools installed and can be an easy option requiring no configuration on your part. It is worth testing to see if it does meet your needs but It will not always suit your requirements. You can see a list of the configurations on the page https://www.visualstudio.com/en-us/docs/build/concepts/agents/hosted
  4. Click on Get Sources and choose
    • From: This project
    • Repository: the repo you created earlier i.e. cntr1vstsrepo
    • Accept the remaining defaults

  5. Click on Add Task and add the task Docker two times, we will use one to build the image and the second to push an image to your repository.

  6. Open the first Docker task to configure the Docker Build Task using the below settings
    • Display name: Build an image
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < choose your azure subscription > (You also need to Authorize your subscription once selected)
    • Azure Container registry: acr12 (or the name you called your Azure Container service when you created it earlier)
    • Action: Build an Image
    • Dockerfile: < default >
    • Build Arguments: < default >
    • Use Default Build Context: check the box
    • Image Name: acr12.azurecr.io/iiscntr1:$(Build.BuildId) (where the first argument is the container service repo name and image you pushed to your Azure Container Registry service earlier)
    • Qualify Image Name: < default >
    • Include Source Tags: < default >
    • Include Latest Tag: check the box
  7. Open the second Docker task and configure it to push the image
    • Display name: Push an image
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < choose your azure subscription >
    • Azure Container registry: acr12 (or the name you called your Azure Container service when you created it earlier, you may need to refresh the field by clicking the refresh icon beside the drop down box, before the registry option becomes available.)
    • Action: Push an image
    • Image Name: acr12.azurecr.io/iiscntr1:$(Build.BuildId) (where the first argument is the image you created earlier in the build task, tagged with the repo name to allow you to push it to your Azure Container Registry)
    • Qualify Image Name: < default > (If you do not tag the image as we have done in the previous step, this defaults to the docker registry)
    • Additional Image Name: < default >
    • Include Source Tags: < default >
    • Include Latest Tag: check the box
  8. Add another Task Publish Build Artifacts and use the following configuration
    • Display name: Publish Build Artifact drop 1
    • Path to Publish: $(Build.SourcesDirectory)/README.md
    • Artifact Name: drop1
    • Artifact Type: Server Note: This is required for the release which we will define later to succeed. (VSTS expects always at least one artifact published from a build, and we are dropping in a readme.md as an artifact into the source directory form the build to ensure that there is an artifact item present. If there are no artifact items, the release will fail.)

  9. Click on Triggers and choose Enable to enable the Continuous Integration trigger. This will trigger a CI build when any change in the repo branch occurs.

  10. Configure the build agent, by going to your Build definition, clicking on Process and click on the settings icon beside the Default agent queue drop down box. Ensure Default is selected.

  11. Save and Queue the build.

  12. To simulate a code check-in, to trigger the continuous integration build, trigger the build by going to your repo and editing the Index.html, by modifying the text from

    <title>my html page in a container </title>
to something like
<title>my html page in a container drop 1</title>

  13. Commit the changes to trigger the build.

    Note: You could also just click the queue build option, but this method is simulating a CI build based on code check-in.

  14. Return to the build definitions and open the build to view the command line build progress output in the build Console. Time taken to complete will depend on you build agent, using Hosted VS2017 can take approximately 10 minutes for a build to run as it waits to connect and gets queued to access an available build agent. If using the local environment, it may take approx. 2 to 3 minutes, using an Azure virtual machine will take approx. 3 – 5 minutes to complete.

  15. Verify the build runs successfully for both the build an image and push an image tasks.

    Note: You may receive errors on your first few runs as you iron out configuration issues. This is normal. You should view the build progress as it runs and identify any errors, and iterate your build definition, each time modifying your VSTS repository file, index.html, to trigger a new build. You can view each build in the build summary page. It may take several runs to get the build and push working successfully.

  16. Go to you Azure Container registry and verify the container image is present from the build that was just run. You can click down into the repo and see various image versions present after multiple runs of the build.

Task 5: Perform Backup and Restore on a Service Fabric Application deployed to a local cluster

  1. In VSTS and your project go to Releases and click on + New definition

  2. In the Create a release definition dialogue choose the Empty template option

  3. Choose the project and build definition you created earlier and click Create

  4. In the definition pane under the Environment tab, change the Environment 1 default name to Test

  5. In the Task catalog dialogue, add Docker task three times

  6. Configure the first Docker task to run the container with the following details
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < Your Azure Subscription >
    • Azure Container Registry: acr12 (or the name of your Azure Container Registry)
    • Action: Run an Image
    • Image Name: acr12.azurecr.io/iiscntr1:$(Build.BuildId) (where the first argument is the repo name and image you pushed to your Azure Container Registry service earlier)
    • Container Name: iiscntr1 (or the name you specified earlier)
    • Ports: 80:80
    • Environment Variables: < default >
    • Working Directory: < default >
    • Entry point Override: < default >
    • Command: < default >
    • Run in background: Check the checkbox
    • Restart Policy:No
  7. Configure the second Docker task as per the below
    • Container Registry Type: Azure Container Registry
    • Azure Subscription: < Your Azure Subscription >
    • Azure Container Registry: acr12 (or the name of your Azure Container Registry)
    • Action: Run a Docker command
    • Command: stop iiscntr1 < i.e. stop and the name of the container you created earlier >
    • Uncheck the Enable checkbox – this is to allow us test the first task before enabling.
    • Edit the title, by clicking the pencil at the top of the window beside the task name, and call the task Stop an Image
    • Accept the default values for the remainder of the items.
  8. Configure the third Docker task as per the below
    • Container Registry Type: Azure Container Registry
    • Azure Subscription:** < Your Azure Subscription >**
    • Azure Container Registry: acr12 (or the name of your Azure Container Registry)
    • Action: Run a Docker command
    • Command:rm iiscntr1 < i.e. rm and the name of the container you created earlier >
    • Uncheck the Enable checkbox – this is to allow us test the first task before enabling.
    • Edit the title, by clicking the pencil at the top of the window beside the task name, and call the task Remove an Image
    • Accept the default values for the remainder of the items.

  9. Go to the Triggers tab and check the Continuous Deployment checkbox and choose your build artifact, i.e. cntrs1 build, in the Set trigger on artifact source for the master branch

  10. Ensure all the tasks added are under the Run on Agent, task.

  11. To add a build agent that will run this deployment, click the link Run in Agent

  12. In the Run on Agent window on the right hand side, in the Deployment queue section, select default, from the drop down list.

  13. Save the Release definition, by clicking Save

  14. Click on Deploy, and select the environment i.e. Test. This will run just the release definition, and not the previously defined build definition.

  15. If it completes successfully, It should deploy the iicntrs1 container image to the build agent, you can verify that by viewing the docker ps command output on the build agent, and verifying the container is up and running. You can also get the IP address using Docker Inspect < container ID > and opening a browser, to verify the page displays successfully.

    You can also view the Logs tab content in the VSTS release definition, it will contain all the command line output and details from the deployment.

    Also, when editing the release definition, be sure you are editing the actual release definition and not a past definition that has already been run, i.e. which have the default label of Release-1, -2, -3, 4 etc. If you edit these releases, and save the changes, that will not affect the general definition. Right click on the release definition as defined under the Release Definitions pane, and choose edit, them Save your changes here. Otherwise, you may think you are editing the release definition but are actually editing a previous run of the definition.

  16. You should run this a couple of times and verify it runs successfully, each time checking the Logs, and various configuration options.

Summary

In this lab you completed the following tasks:

  • Create an ACS Cluster
  • Deploy App to ACS Cluster using Docker-Compose
  • Monitor an ACS Cluster
  • Scale the cluster