Prepearing for GitHub certification - Build and deploy applications to Azure by using GitHub Actions

Prepearing for GitHub certification - Build and deploy applications to Azure by using GitHub Actions

How do I use GitHub Actions to deploy to Azure?

Options for triggering a CD workflow

Different options
- One option use ChatOps to trigger the workflow
Another option is to use labels in tour pull requests
Different labels can start different workflows
To use labels in workflows:

on:

  pull_request:

    types: [labeled]

Control execution with a job conditional

Often, you only want to run a workflow if some condition is true.
Can use if conditional fro this scenario
- Eg. we want to run a workflow if a stage label is added to the pull request

if: contains(github.event.pull_request.labels.*.name, 'stage')

Store credentials with GitHub Secrets

Never expose sensitive information in the workflow file.
GitHub Secrets is a secure place to store sensitive information
Example:

{% highlight yml %} steps: - name: “Login via Azure CLI” uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }} {% endhighlight %}

We use the created secret AZURE_CREDENTIALS from GitHub Secrets

Deploy to Microsoft Azure using GitHub Actions

GitHub Marketplace has several actions that help automate Azure-related tasks
Or search for a GitHub Action directly from your repositories workflow editor
Example:
- Suppose want to deploy a container-based web app to Azure Web Apps, then you can use the following actions

{% highlight yml %} Deploy-to-Azure: runs-on: ubuntu-latest needs: Build-Docker-Image name: Deploy app container to Azure steps: - name: “Login via Azure CLI” uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }}

  - uses: azure/docker-login@v1
    with:
      login-server: ${{env.IMAGE_REGISTRY_URL}}
      username: ${{ github.actor }}
      password: ${{ secrets.GITHUB_TOKEN }}

  - name: Deploy web app container
    uses: azure/webapps-container-deploy@v1
    with:
      app-name: ${{env.AZURE_WEBAPP_NAME}}
      images: ${{env.IMAGE_REGISTRY_URL}}/${{ github.repository }}/${{env.DOCKER_IMAGE_NAME}}:${{ github.sha }}

  - name: Azure logout
    run: |
      az logout {% endhighlight %}

Notice that this job depends on a previous job, Build-Docker-Image
The azure/login@v1 action needs credentials to sign in to your Azure account so that it can access the Azure resources that you want to deploy to
The same is true for the azure/docker-login@v1 action. Since you’re deploying a container image, you’ll need to sign in to your private container registry
The azure/webapps-container-deploy@v1 action performs the deployment. It depends on the two actions mentioned above

Create and delete Azure resources by using GitHub Actions

GitHub Action can automate IaC tasks on Azure
Can include these actions in your workflow
Options:
- Create a workflow with two jobs
- One that spins up resources
- One that deletes resources
- Then use a conditional to run only the job you want
Example:

jobs:

  set-up-azure-resources:

    runs-on: ubuntu-latest


    if: contains(github.event.pull_request.labels.*.name, 'spin up environment')


    ...


  destroy-azure-resources:

    runs-on: ubuntu-latest


    if: contains(github.event.pull_request.labels.*.name, 'destroy environment')


    ...

The jobs use Azure CLI to create and destroy Azure resources
Example of the steps in the `set-up-azure-resources

{% highlight yml %} steps:

name: Checkout repository uses: actions/checkout@v2
name: Azure login uses: azure/login@v1 with: creds: ${{ secrets.AZURE_CREDENTIALS }}
name: Create Azure resource group if: success() run: | az group create –location ${{env.AZURE_LOCATION}} –name ${{env.AZURE_RESOURCE_GROUP}} –subscription ${{secrets.AZURE_SUBSCRIPTION_ID}}
name: Create Azure app service plan if: success() run: | az appservice plan create –resource-group ${{env.AZURE_RESOURCE_GROUP}} –name ${{env.AZURE_APP_PLAN}} –is-linux –sku F1 –subscription ${{secrets.AZURE_SUBSCRIPTION_ID}}
name: Create webapp resource if: success() run: | az webapp create –resource-group ${{ env.AZURE_RESOURCE_GROUP }} –plan ${{ env.AZURE_APP_PLAN }} –name ${{ env.AZURE_WEBAPP_NAME }} –deployment-container-image-name nginx –subscription ${{secrets.AZURE_SUBSCRIPTION_ID}}
name: Configure webapp to use GitHub Packages if: success() run: | az webapp config container set –docker-custom-image-name nginx –docker-registry-server-password ${{secrets.GITHUB_TOKEN}} –docker-registry-server-url https://docker.pkg.github.com –docker-registry-server-user ${{github.actor}} –name ${{ env.AZURE_WEBAPP_NAME }} –resource-group ${{ env.AZURE_RESOURCE_GROUP }} –subscription ${{secrets.AZURE_SUBSCRIPTION_ID}} {% endhighlight %}

Remove artifacts, create status badges, and configure environment protections

Remove workflow artifacts from GitHub

By default, GitHub stores any build logs and uploaded artifacts for 90 days before they are deleted
This retention period can be customized based on the type of repository and the usage limits
Check out more about Usage limits, billing, and administration
Can claim used GitHub Actions storage by deleting artifacts
Two ways to delete (Both require write access to the repository):
Note: Keep in mind that once you delete an artifact, it can not be restored.

Manually delete artifacts from your repository

Can be done from Actions -> selected single workflow artifacts view
Can use Artifacts REST API to delete.

Change the default retention period

Can change the default artifact and log retention period for your repository, organization, or enterprise account
Keep in mind that changing the retention period will only apply to new artifacts and log files and does not apply to existing objects
Also and the option is to define a custom retention period for individual artifacts within the workflow file
this needs the usage of retention-days and then a value within the step with upload-artifact action

  - name: 'Upload Artifact'

    uses: actions/upload-artifact@v2

    with:

      name: my-artifact

      path: my_file.txt

      retention-days: 10

Add a workflow status badge to your repository

Add the workflow status badges to the repository README.md file
Can also be added to any web page.
By default shows statuses for default branch
Can also display badges on other branches using branch and event parameters

![example branch parameter.](https://github.com/mona/special-octo-eureka/actions/workflows/grading.yml/badge.svg?branch=my-workflow)

Can also create a status badge using GitHub
It is done through workflows section in the Actions tab

Add workflow environment protections

Two environment protection rules can be applied to workflows within public repositories, required reviewers and wait timer
- Required reviewers allow you to set a specific person or team to approve workflow jobs that reference the job’s environment.
- Wait timer can be used to delay a job for a specific amount of time after the job has been triggered.

Exercise

Exercise - Create a workflow that deploys a web app to Azure

Share this article:

Build and deploy applications to Azure by using GitHub Actions