Creating test environments dynamically with GitHub Actions

How to optimize a test pipeline so teams don’t run into concurrency problems while testing their features and modules is a recurring subject in several topics I’ve covered both in the past and recently.

I’ve even given a few talks on the subject and I have an example repository using Azure DevOps as the CI tool. You can see the slides and the video below!

The question is: How can we make several development teams able to test their features in an environment completely separate from the others, simply and quickly?

The answer is, of course, containers. When we use Kubernetes with Helm together with a CI tool, we can do a lot of things dynamically. In this article, I’m going to update my previous talk and show the same application, but running on a GitHub Actions pipeline. To make the scenario more realistic, we’re going to use Azure with Azure Kubernetes Service pulling images from a private Azure Container Registry that’s already privately integrated with the cluster. All data will be stored in a Mongo-flavored CosmosDB.

Let’s go!

Before we start#

We’re going to have to create the environment before we start showing how the dynamic part can be done. Since that’s not the point of this post, I’ll leave only the command references for what we’re going to do here, but all the necessary documentation can be found directly in each service’s docs.

First you need an account on Azure. Once you have one, install the Azure CLI, we’re going to use the command line only.

The first command will be az login to log into your account and choose which subscription will be used to create the resources. As soon as the login is done, let’s start by creating the first resource, the resource group.

1
az group create -l eastus -n ship-manager-pipeline

Now let’s create our ACR so we can store our images:

1
az acr create -n shipmanager --sku Basic -g ship-manager-pipeline

Wait until the CR is created and run the following command to enable login via username and password, that’s the only way we’ll be able to log in from our CI to build the images:

1
az acr update -n shipmanager --admin-enabled true

Now let’s move on to CosmosDB, with a single command we can create the whole structure:

1
az cosmosdb create --kind MongoDB -n ship-manager-db -g ship-manager-pipeline

This command takes a bit longer to run, so be patient. It’s important to say that, as great as it is, CosmosDB isn’t recommended for this specific case of creating databases when we have ephemeral environments like these, because it’s more complex to remove later on. But, to keep things simple, we’re going to use it and we’ll look at alternatives to this approach further ahead in the article.

Finally let’s create our AKS, which will tie all the parts together:

1
az aks create -n ship-manager -g ship-manager-pipeline \
2
--enable-addons http_application_routing \
3
--attach-acr shipmanager \
4
--vm-size Standard_B2s \
5
--generate-ssh-keys \
6
--node-count 2

This makes our AKS get created already hooked up with the ACR, so we don’t need to create a secret for each namespace with our Docker login file to pull the images, and we also don’t need to bind anything to a service account.

Get the AKS credentials with the following command:

1
az aks get-credentials -n ship-manager -g ship-manager-pipeline --admin

Remember you need kubectl installed on your machine for this command to work. If you don’t have it, use az aks install-cli to install it.

Creating the chart#

The first step to creating the pipeline is knowing how it’s going to work. Initially we’re going to work with only two environments, the first will be the production environment and the second will be the test environment.

The production environment will be published whenever a push with a v* tag happens. The test environment will be published on a push to any branch other than master or main (depending on the case).

So you can follow along, I’ve put together this example repository that contains both the application code and the actions code itself.

Tip

If you want to follow along step by step, fork the repository, but don’t forget to remove the .github folder so the actions are removed.

Before creating the pipeline files, let’s create the Helm files, so we can create our chart! Create a folder called kubernetes at the root of the repository, then create a second folder called ship-manager.

Inside the ship-manager folder create two more folders: templates and charts. Now create two files at the same level as the templates folder, one of them will be called Chart.yaml and the other values.yaml.

Now, let’s go into the charts folder. In it, create a backend folder and, inside that one, add a Chart.yaml file followed by a templates folder.

The final structure should look like this:

1
kubernetes
2
└── ship-manager
3
    ├── Chart.yaml
4
    ├── charts
5
    │   └── backend
6
    │       ├── Chart.yaml
7
    │       └── templates
8
    │
9
    ├── templates
10
    └── values.yaml

In the Chart.yaml file in the ship-manager folder we’re going to write the following:

1
apiVersion: v2
2
name: ship-manager
3
description: Chart for the ship manager app
4
version: 0.1.0

And the one in the backend folder will be this:

1
apiVersion: v2
2
name: backend
3
description: Chart for the backend part of the ship manager app
4
version: 0.1.0

What we did was create Helm’s equivalent of a package.json, that is, the file that defines the package we’re going to install in our cluster.

Helm works based on a hierarchy. What we just created here is a dependency order, that is, we just said that the application’s frontend, which is in ship-manager, depends on a backend located in the charts folder. If we created another charts folder inside backend we’d be saying that the backend depends on it and so on. This way, when we run a single command, Helm already installs all the dependencies in order for us.

Let’s create our first template. Create a frontend.yaml file inside the templates folder located in the ship-manager folder. This template is what’s actually going to be created inside the cluster. In it we’ll have all the Kubernetes resources, starting with the Deployment:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: ship-manager-frontend
5
spec:
6
  replicas: 1
7
  selector:
8
    matchLabels:
9
      app: ship-manager-frontend
10
  template:
11
    metadata:
12
      labels:
13
        app: ship-manager-frontend
14
    spec:
15
      containers:
16
        - image: {{ required "Registry is required" .Values.global.registryName }}/{{ required "Image name is required" .Values.frontend.imageName }}:{{ required "Image tag is required" .Values.global.imageTag }}
17
          name: ship-manager-frontend
18
          resources:
19
            requests:
20
              cpu: 100m
21
              memory: 128Mi
22
            limits:
23
              cpu: 250m
24
              memory: 256Mi
25
          ports:
26
            - containerPort: 8080
27
              name: http
28
          volumeMounts:
29
            - name: config
30
              mountPath: /usr/src/app/dist/config.js
31
              subPath: config.js
32
      volumes:
33
        - name: config
34
          configMap:
35
            name: frontend-config

Notice we’re using Helm placeholders to identify parts that can be changed, and that’s what makes everything possible. Creating environments and changing variables at CLI time and not after it’s been compiled means we can pass whatever values we want to those variables when creating the environment.

Then we have the other configurations:

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: ship-manager-frontend
5
spec:
6
  selector:
7
    app: ship-manager-frontend
8
  ports:
9
    - name: http
10
      port: 80
11
      targetPort: 8080
12
---
13
apiVersion: networking.k8s.io/v1beta1
14
kind: Ingress
15
metadata:
16
  name: ship-manager-frontend
17
  annotations:
18
    kubernetes.io/ingress.class: addon-http-application-routing
19
spec:
20
  rules:
21
    - host: {{ default "ship-manager-frontend" .Values.frontend.ingress.hostname }}.{{ .Values.global.dnsZone }}
22
      http:
23
        paths:
24
          - path: /
25
            backend:
26
              serviceName: ship-manager-frontend
27
              servicePort: http
28
---
29
apiVersion: v1
30
kind: ConfigMap
31
metadata:
32
  name: frontend-config
33
data:
34
  config.js: |
35
    const config = (() => {
36
      return {
37
        'VUE_APP_BACKEND_BASE_URL': 'http://{{ default "ship-manager-backend" .Values.backend.ingress.hostname }}.{{ .Values.global.dnsZone }}',
38
        'VUE_APP_PROJECT_VERSION': '{{ .Values.global.imageTag }}'
39
      }
40
    })()

Notice I’m pulling everything from .Values, this is the values.yaml file we’ll see shortly. Notice too that most of the things that can be changed and that need to be changed, like the image name, the tag, the hostname and the database, are also variables.

In cases like these, using configmaps and secrets helps a lot to keep the pipeline simple.

The final file will be:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: ship-manager-frontend
5
spec:
6
  replicas: 1
7
  selector:
8
    matchLabels:
9
      app: ship-manager-frontend
10
  template:
11
    metadata:
12
      labels:
13
        app: ship-manager-frontend
14
    spec:
15
      containers:
16
        - image: {{ required "Registry is required" .Values.global.registryName }}/{{ required "Image name is required" .Values.frontend.imageName }}:{{ required "Image tag is required" .Values.global.imageTag }}
17
          name: ship-manager-frontend
18
          resources:
19
            requests:
20
              cpu: 100m
21
              memory: 128Mi
22
            limits:
23
              cpu: 250m
24
              memory: 256Mi
25
          ports:
26
            - containerPort: 8080
27
              name: http
28
          volumeMounts:
29
            - name: config
30
              mountPath: /usr/src/app/dist/config.js
31
              subPath: config.js
32
      volumes:
33
        - name: config
34
          configMap:
35
            name: frontend-config
36
---
37
apiVersion: v1
38
kind: Service
39
metadata:
40
  name: ship-manager-frontend
41
spec:
42
  selector:
43
    app: ship-manager-frontend
44
  ports:
45
    - name: http
46
      port: 80
47
      targetPort: 8080
48
---
49
apiVersion: networking.k8s.io/v1beta1
50
kind: Ingress
51
metadata:
52
  name: ship-manager-frontend
53
  annotations:
54
    kubernetes.io/ingress.class: addon-http-application-routing
55
spec:
56
  rules:
57
    - host: {{ default "ship-manager-frontend" .Values.frontend.ingress.hostname }}.{{ .Values.global.dnsZone }}
58
      http:
59
        paths:
60
          - path: /
61
            backend:
62
              serviceName: ship-manager-frontend
63
              servicePort: http
64
---
65
apiVersion: v1
66
kind: ConfigMap
67
metadata:
68
  name: frontend-config
69
data:
70
  config.js: |
71
    const config = (() => {
72
      return {
73
        'VUE_APP_BACKEND_BASE_URL': 'http://{{ default "ship-manager-backend" .Values.backend.ingress.hostname }}.{{ .Values.global.dnsZone }}',
74
        'VUE_APP_PROJECT_VERSION': '{{ .Values.global.imageTag }}'
75
      }
76
    })()

Let’s do the same with the backend, creating a backend.yaml file in the charts/backend/templates folder:

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: ship-manager-backend
5
spec:
6
  replicas: 1
7
  selector:
8
    matchLabels:
9
      app: ship-manager-backend
10
  template:
11
    metadata:
12
      labels:
13
        app: ship-manager-backend
14
    spec:
15
      containers:
16
        - image: {{ required "Registry is required" .Values.global.registryName }}/{{ required "Image name is required" .Values.imageName }}:{{ required "Image tag is required" .Values.global.imageTag }}
17
          name: ship-manager-backend
18
          resources:
19
            requests:
20
              cpu: 100m
21
              memory: 128Mi
22
            limits:
23
              cpu: 250m
24
              memory: 256Mi
25
          ports:
26
            - containerPort: 3000
27
              name: http
28
          env:
29
            - name: DATABASE_MONGODB_URI
30
              valueFrom:
31
                secretKeyRef:
32
                  key: database_mongodb_uri
33
                  name: backend-db
34
            - name: DATABASE_MONGODB_DBNAME
35
              value: {{ default "ship-manager" .Values.global.dbName }}
36
---
37
apiVersion: v1
38
kind: Service
39
metadata:
40
  name: ship-manager-backend
41
spec:
42
  selector:
43
    app: ship-manager-backend
44
  ports:
45
    - name: http
46
      port: 80
47
      targetPort: 3000
48
---
49
apiVersion: networking.k8s.io/v1beta1
50
kind: Ingress
51
metadata:
52
  name: ship-manager-backend
53
  annotations:
54
    kubernetes.io/ingress.class: addon-http-application-routing
55
spec:
56
  rules:
57
    - host: {{ default "ship-manager-backend" .Values.ingress.hostname }}.{{ .Values.global.dnsZone }}
58
      http:
59
        paths:
60
          - path: /
61
            backend:
62
              serviceName: ship-manager-backend
63
              servicePort: http
64
---
65
apiVersion: v1
66
kind: Secret
67
metadata:
68
  name: backend-db
69
type: Opaque
70
stringData:
71
  database_mongodb_uri: {{ required "DB Connection is required" .Values.global.dbConn | quote }}

Notice I have a few functions in there too, like required, default and quote. These are native Helm functions and they save the day when we need more complex behavior.

The values file#

Just like the charts, the values.yaml file is based on a hierarchy of scopes, that is, take our structure as an example:

1
global:
2
  chave: # Acessível a todos os charts, tanto o frontend como o backend como `.Values.global.chave`
3

4
backend:
5
  chave: # Acessível somente ao frontend e ao backend, porém para o frontend será `.Values.backend.chave` e o backend usará como `.Values.chave`
6

7
frontend:
8
  chave: # Acessível pelo frontend como `.Values.frontend.chave`, mas não pelo backend
9

10
chave: # Acessível somente ao frontend como `.Values.chave`

Notice we have a scope break inside the values file. The keys that have the same name as their dependent charts will be accessed only by them and by the higher order charts, so since our frontend is the highest order chart, it has access to all the values, while the backend only has access to the keys defined under backend:.

Notice too that inside backend the scope goes through a “levelling”, that is, the scope is removed from inside backend so you don’t need to access the value as .Values.backend.chave if you’re inside the backend chart, but only as .Values.chave.

Our values file needs to have the same keys we defined inside our templates, so they’ll be these:

1
global:
2
  registryName:
3
  imageTag:
4
  dbName: ship-manager
5
  dbConn:
6
  dnsZone:
7

8
backend:
9
  imageName: ship-manager-backend
10
  ingress:
11
    hostname:
12

13
frontend:
14
  imageName: ship-manager-frontend
15
  ingress:
16
    hostname:

The keys I’m leaving blank are the ones that will either be filled in by the CLI or by the default functions.

Creating the pipeline#

To create the pipeline, we’re going to use the manual creation mode, that is, we’re going to create a .github folder and inside it a workflows folder. The first workflow will be the simplest one, production.

Inside the workflows folder let’s create a deploy-production.yml file (it can be any name, actually) and start by writing our pipeline’s name and which triggers are going to make it run.

1
name: Build and push the tagged build to production
2

3
on:
4
  push:
5
    tags:
6
      - 'v*'

Here we’re saying our action will run on every push with a v* tag, that is, v1.0.0 and even vabc. If you want to narrow down the possibilities you can use regex like v[0-9]\.[0-9]\.[0-9].

Then, let’s create our first job and define a shared variable:

1
name: Build and push the tagged build to production
2

3
on:
4
  push:
5
    tags:
6
      - 'v*'
7

8
env:
9
  IMAGE_NAME: ship-manager
10

11
jobs:
12
  build_push_image:
13
    runs-on: ubuntu-20.04

We created a job called build_push_image that’s going to run on ubuntu 20, and a shared variable that will be the image’s base name. Now let’s get to the real action, let’s start creating the steps of our job, starting with two very important ones:

1
name: Build and push the tagged build to production
2

3
on:
4
  push:
5
    tags:
6
      - 'v*'
7

8
env:
9
  IMAGE_NAME: ship-manager
10

11
jobs:
12
  build_push_image:
13
    runs-on: ubuntu-20.04
14

15
    steps:
16
      - uses: actions/checkout@v2
17

18
      - name: Set env
19
        id: tags
20
        run: echo tag=${GITHUB_REF#refs/tags/} >> $GITHUB_ENV

The first step is a checkout of our repository, it’s present in pretty much every action and it’s always the first step. The second is defining a second variable, the tag name.

By default $GITHUB_REF is either the branch name or the tag name, like /refs/heads/main or /refs/tags/v1.0.0. We have to remove the /refs/* and keep only the end, that’s why we’re using a shell substitution to add it to the global variables, but this variable only works inside this job.

Now let’s do the Docker pipeline, that is, build and push of the backend and frontend images.

1
name: Build and push the tagged build to production
2

3
on:
4
  push:
5
    tags:
6
      - 'v*'
7

8
env:
9
  IMAGE_NAME: ship-manager
10

11
jobs:
12
  build_push_image:
13
    runs-on: ubuntu-20.04
14

15
    steps:
16
      - uses: actions/checkout@v2
17

18
      - name: Set env
19
        id: tags
20
        run: echo tag=${GITHUB_REF#refs/tags/} >> $GITHUB_ENV
21

22
      - name: Set up Buildx
23
        uses: docker/setup-buildx-action@v1
24

25
      - name: Login to ACR
26
        uses: docker/login-action@v1
27
        with:
28
          # Username used to log in to a Docker registry. If not set then no login will occur
29
          username: ${{secrets.ACR_LOGIN }}
30
          # Password or personal access token used to log in to a Docker registry. If not set then no login will occur
31
          password: ${{secrets.ACR_PASSWORD }}
32
          # Server address of Docker registry. If not set then will default to Docker Hub
33
          registry: ${{ secrets.ACR_NAME }}
34

35
      - name: Build and push frontend image
36
        uses: docker/build-push-action@v2
37
        with:
38
          # Docker repository to tag the image with
39
          tags: ${{secrets.ACR_NAME}}/${{ env.IMAGE_NAME }}-frontend:latest,${{secrets.ACR_NAME}}/${{ env.IMAGE_NAME }}-frontend:${{env.tag}}
40
          labels: |
41
            image.revision=${{github.sha}}
42
            image.release=${{github.ref}}
43
          file: frontend/Dockerfile
44
          context: frontend
45
          push: true
46

47
      - name: Build and push backend image
48
        uses: docker/build-push-action@v2
49
        with:
50
          # Docker repository to tag the image with
51
          tags: ${{secrets.ACR_NAME}}/${{ env.IMAGE_NAME }}-backend:latest,${{secrets.ACR_NAME}}/${{ env.IMAGE_NAME }}-backend:${{env.tag}}
52
          labels: |
53
            image.revision=${{github.sha}}
54
            image.release=${{github.ref}}
55
          file: backend/Dockerfile
56
          context: backend
57
          push: true

Docker has 3 actions in use here. The first of them is the setup of buildx, Docker’s image build utility, the second is the login to a registry, in this case our ACR, and here we have our first secret that we’re going to create inside our repository, which will be the ACR login data.

Finally, we’re building and pushing the image and creating the latest tag and the GitHub tag name, this way we know which images are the “production” ones and which will be the test ones. We also add two labels to each image, one of them has the revision, our commit’s sha, and the other the tag name.

With that we finish our first job. The second is the part where we’re going to deploy to the cluster. The beginning is the same so I’m going to omit the content up to this point so we can focus only on this part:

1
# inicio do arquivo
2
jobs:
3
  build_push_image:
4
    # job de envio da imagem
5

6
  deploy:
7
      runs-on: ubuntu-20.04
8
      needs: build_push_image
9

10
      steps:
11
        - uses: actions/checkout@v2
12

13
        - name: Set env
14
          id: tags
15
          run: echo tag=${GITHUB_REF#refs/tags/} >> $GITHUB_ENV
16

17
        - name: Install Helm
18
          uses: Azure/setup-helm@v1
19
          with:
20
            version: v3.3.1

Notice we’re creating a relation between the two jobs with the needs key, this says the second job will only run if the first one passes. We do the checkout and copy the variable creation, then we run a simple step to install Helm on the machine.

1
# inicio do arquivo
2
jobs:
3
  build_push_image:
4
    # job de envio da imagem
5

6
  deploy:
7
      runs-on: ubuntu-20.04
8
      needs: build_push_image
9

10
      steps:
11
        - uses: actions/checkout@v2
12

13
        - name: Set env
14
          id: tags
15
          run: echo tag=${GITHUB_REF#refs/tags/} >> $GITHUB_ENV
16

17
        - name: Install Helm
18
          uses: Azure/setup-helm@v1
19
          with:
20
            version: v3.3.1
21

22
      - name: Get AKS Credentials
23
        uses: Azure/aks-set-context@v1
24
        with:
25
          creds: ${{ secrets.AZURE_CREDENTIALS }}
26
          # Resource group name
27
          resource-group: ship-manager-pipeline
28
          # AKS cluster name
29
          cluster-name: ship-manager
30

31
      - name: Run Helm Deploy
32
        run: |
33
          helm upgrade \
34
            ship-manager-prd \
35
            ./kubernetes/ship-manager \
36
            --install \
37
            --create-namespace \
38
            --namespace production \
39
            --set global.registryName=${{ secrets.ACR_NAME }} \
40
            --set global.dbConn="${{ secrets.DB_CONNECTION }}" \
41
            --set global.dnsZone=${{ secrets.DNS_NAME }} \
42
            --set global.imageTag=${{env.tag}}

Finally we’ll have the command to get the Kubernetes credentials and the Helm deploy. Notice we’re deploying to a production namespace and setting the values.yaml values through the --set flags, this makes everything easier when we need to remove the data, because we only need to remove the namespace and everything gets deleted.

The test pipeline is almost identical, the difference is that we’re setting more variables and we changed the publishing namespace and the trigger too. The other file, which I called deploy-test, ended up like this:

1
name: Build and push the tagged build to test
2

3
on:
4
  push:
5
    branches-ignore:
6
      - 'main'
7
      - 'master'
8

9
env:
10
  IMAGE_NAME: ship-manager
11

12
jobs:
13
  build_push_image:
14
    runs-on: ubuntu-20.04
15

16
    steps:
17
      - uses: actions/checkout@v2
18

19
      - name: Set env
20
        id: tags
21
        run: echo tag=${GITHUB_REF#refs/heads/} >> $GITHUB_ENV
22

23
      - name: Set up Buildx
24
        uses: docker/setup-buildx-action@v1
25

26
      - name: Login to ACR
27
        uses: docker/login-action@v1
28
        with:
29
          # Username used to log in to a Docker registry. If not set then no login will occur
30
          username: ${{secrets.ACR_LOGIN }}
31
          # Password or personal access token used to log in to a Docker registry. If not set then no login will occur
32
          password: ${{secrets.ACR_PASSWORD }}
33
          # Server address of Docker registry. If not set then will default to Docker Hub
34
          registry: ${{ secrets.ACR_NAME }}
35

36
      - name: Build and push frontend image
37
        uses: docker/build-push-action@v2
38
        with:
39
          # Docker repository to tag the image with
40
          tags: ${{ secrets.ACR_NAME }}/${{ env.IMAGE_NAME }}-frontend:${{env.tag}}
41
          labels: |
42
            image.revision=${{github.sha}}
43
          file: frontend/Dockerfile
44
          context: frontend
45
          push: true
46

47
      - name: Build and push backend image
48
        uses: docker/build-push-action@v2
49
        with:
50
          # Docker repository to tag the image with
51
          tags: ${{ secrets.ACR_NAME }}/${{ env.IMAGE_NAME }}-backend:${{env.tag}}
52
          labels: |
53
            image.revision=${{github.sha}}
54
          file: backend/Dockerfile
55
          context: backend
56
          push: true
57

58
  deploy:
59
    runs-on: ubuntu-20.04
60
    needs: build_push_image
61

62
    steps:
63
      - uses: actions/checkout@v2
64

65
      - name: Set env
66
        id: tags
67
        run: echo tag=${GITHUB_REF#refs/tags/} >> $GITHUB_ENV
68

69
      - name: Install Helm
70
        uses: Azure/setup-helm@v1
71
        with:
72
          version: v3.3.1
73

74
      - name: Get AKS Credentials
75
        uses: Azure/aks-set-context@v1
76
        with:
77
          creds: ${{ secrets.AZURE_CREDENTIALS }}
78
          # Resource group name
79
          resource-group: ship-manager-pipeline
80
          # AKS cluster name
81
          cluster-name: ship-manager
82

83
      - name: Run Helm Deploy
84
        run: |
85
          helm upgrade \
86
            ship-manager-${{env.tag}} \
87
            ./kubernetes/ship-manager \
88
            --install \
89
            --create-namespace \
90
            --namespace test-${{env.tag}} \
91
            --set global.registryName=${{ secrets.ACR_NAME }} \
92
            --set global.dbConn="${{ secrets.DB_CONNECTION }}" \
93
            --set global.dbName=ship-manager-test-${{env.tag}} \
94
            --set global.dnsZone=${{ secrets.DNS_NAME }} \
95
            --set backend.ingress.hostname=ship-manager-backend-${{env.tag}} \
96
            --set frontend.ingress.hostname=ship-manager-frontend-${{env.tag}} \
97
            --set global.imageTag=${{env.tag}}

Secrets#

Now that we have the pipelines created, let’s go to GitHub to create our secrets! Open the repository in your browser, go to the Settings tab and then secrets, then click New repository secret to create a new local secret.

Let’s create a secret called ACR_LOGIN which will be the name of our ACR, that is, shipmanager. Another one called ACR_NAME, which isn’t really a secret, because it’s our CR’s DNS, but this way we avoid having a hardcoded value in our action. This value is shipmanager.azurecr.io.

The ACR password can be obtained with an AZ CLI command: az acr credential show -n shipmanager --query "passwords[0].value" -o tsv and should be put into another secret called ACR_PASSWORD.

To get our AKS key, we’re going to need service principal access on Azure, which can be obtained with the command az ad sp create-for-rbac --sdk-auth. This command will give you back a JSON, copy the whole JSON and paste it into the secret called AZURE_CREDENTIALS.

The database connection for the secret called DB_CONNECTION can also be obtained with the command az cosmosdb keys list -n ship-manager-db -g ship-manager-pipeline --type connection-strings --query "connectionStrings[0].connectionString".

And the final secret can be obtained through a query on the AKS enabled addons list. Since we turned on HTTP Application Routing, we’ll have a DNS zone available that we can get with the command az aks show -n ship-manager -g ship-manager-pipeline --query "addonProfiles.httpApplicationRouting.config.HTTPApplicationRoutingZoneName and put into the secret called DNS_NAME.

Testing#

We commit our changes and now let’s create a tag with git tag -a v<version> -m'new version and then git push --tags so we can trigger our build. We’ll have a small delay and then an output like this:

If we look at our application after a few minutes (DNS takes a while to propagate), we’ll see we have an address just like our ingress’s (we can get the frontend address with kubectl get ing -n production). When we access it, we’ll have our application running:

Our application is on a production branch and will be accessible and updated to the newest version whenever we push with a specific tag. The same will happen when we create a new branch and push, try creating any branch and sending some code!

Conclusion and improvements#

Creating a dynamic environment isn’t simple, but it can be the difference between a team that takes forever to test its features and a team that can be much more efficient. In this example we got to 50% of what’s needed, the other important part of the pipeline is also removing your resources whenever they’re no longer in use.

For this reason, using another database instead of the same instance is much more preferable. Ideally we’d create a dependency in the backend chart pointing to a completely empty MongoDB chart, this way we can be sure this environment is totally isolated and we can remove the whole environment without any problem.

Leave your comments and maybe we can continue this series!

We could create the helm chart automatically via CLI, but it creates several files we don’t need, so we’re going to create it manually to keep things easier. ↩
It’s possible to have more values files inside the dependent charts and the rule stays the same, the difference is that the higher order chart will be changed, but this pattern makes maintenance quite complex. ↩
We can’t define the variable inside env because that key doesn’t run any kind of shell, so we can’t use value substitution or expansions. ↩
Both pieces of information can be obtained in the Azure portal. Knowing the ACR name, the login is the same and the DNS is always <name>.azurecr.io ↩

Creating test environments dynamically with GitHub Actions

Before we start#

Creating the chart#

The values file#

Creating the pipeline#

Secrets#

Testing#

Conclusion and improvements#

Footnotes#