DevOps with Github Actions and Azure App Service Container

Steve Chow
4 min readMay 20, 2021

--

As GitHub Action has been released quite a while ago and recently i have been embarking on this journey to automate the end to end flow from commit to release into Azure App Service container with .NET Core Web API using GitHub Actions.

It was a challenge to me as Azure DevOps pipeline have the classic editor to drag and drop the different tasks into the continuous integration pipeline.

Above diagram is the POC that i went through when i setup GitHub Actions and Azure App Service Container.

Based on the diagram, this is the reference steps from 1 to 10 :

  1. Developer creates or modifies .NET Core Web API Project
  2. Developer commits and push the code to dev-branch
  3. Github Actions triggers the Build on the project
  4. Github Actions push the image to dev ACR
  5. Github Actions updates the image on Dev App Service Container
  6. Developer creates a pull request after the Dev successfully built and tested.
  7. Team lead reviews the pull request and merge to master-branch
  8. Github Actions triggers the push to uat ACR
  9. Github Actions updates the image on UAT App Service Container

Prerequisite :

  • Azure App Service Linux Container
  • Azure Container Registry
  • Github Repository
  • Web API source code (you can create a sample project from VS)

Assuming that all you have created all the prerequisites, you can start the next few steps to create the DevOps process on GitHub.

Step 1 : Sample Docker file for Web API Project

Step 2: Create new branch from the Master

I am using Github Desktop on the creation of new branch, you have the alternatives to use git command.

Select New Branch on the drop down from the Current branch.

After new branch has been created, and you can create GitHub Actions on the dev-branch

Step 3: Create github actions

Go to the Actions tab on the repository and create New Workflow.

you can choose skip and set up a workflow yourself.

In order to trigger on particular branch, you can define the triggers at the first part of the entire yaml.

name: WEB-API Triggeron:  
push:
branches:
- dev-branch-trigger

Subsequently you can perform the actions on the particular push on the dev-branch like for example :

  1. Build the web api project
- name: Restore dependencies      
run: dotnet restore "webapi.csproj"
- name: Build
run: dotnet build --no-restore "webapi.csproj"

2. Push to ACR

In order to setup the secrets in GitHub. Go to the settings of the repo in GitHub and click on Secrets :

- name: Azure Container Registry Login      
uses: Azure/docker-login@v1
with:
# Container registry username
username: <<input your acr user name>>
# Container registry password
password: ${{ secrets.AZURE_ACR_PASSWORD }}
# Container registry server url
login-server: <<your acr>>.azurecr.io
- name: Build the Docker image
run: |
docker build . --file "<<your directory>>/Dockerfile" --tag <<your acr>>.azurecr.io/<<image name>>:${{ github.sha }}
docker push <<your acr>>.azurecr.io/<<image name>>:${{ github.sha }}

3. Update Azure App Service Linux Container

- name: 'Login via Azure CLI'      
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIAL }}
- uses: azure/webapps-deploy@v2
with:
app-name: '<<app service name>>'
images: '<<your acr>>.azurecr.io/<<image name>>:${{ github.sha }}'

After you have setup the GitHub Actions in the dev-branch, you can repeat the steps above on the master-branch. Once the developer commits and push the code to dev-branch, it will trigger the build and deploy to Azure App Service Container automatically and before the team lead decided to merge it to master-branch, they can review the pull request and decide on the merge.

The full GitHub Actions :

Thanks to Marcus for the sharing and it helps a lot in setting the entire GitHub Actions. You can refer here for the reference.

Deploy Blazor WebAssembly on Azure Storage Static Website with GitHub Action | by Marcus Tee | Marcus Tee Anytime | May, 2021 | Medium

PS : This is purely my experimental project and you should not use it for production purposes.

--

--

Steve Chow
Steve Chow

No responses yet