CI/CD tools and Avassa: how to build a successful integration

All our customers have already invested in CI/CD for their cloud applications and we aim to be a very good citizen in those environments. This article describes in detail what is needed to make Avassa part of the continuous delivery for the distributed edge case, where applications are deployed to hundreds or even thousands of edge sites, rather than to the cloud.

We will use Gitlab as an example. The same principles are applicable to other CI/CD systems.

In short, there are three steps needed to deploy a new version of an application in an Avassa system.

1. Get supctl (you can of course use curl directly to the APIs, but supctl provides a nice abstraction)
2. Login to the Control Tower with supctl
3. Push the new or updated application and deployment specifications

Gitlab runner config

All code for this can be found here. The Gitlab CI configuration for the deploy job looks like this:

deploy:
  stage: deploy
  image: python:3-alpine
  only:
    changes:
      - demo-specs/*
  script:
    # Install curl and download supctl
    - apk add curl
    - curl -OL https://$CONTROL_TOWER/supctl
    - chmod +x supctl

    # Login to the control tower, use Gitlab CI/CD variables
    - echo "$CT_PASSWORD" | ./supctl --host=$CONTROL_TOWER do login $CT_USER > /dev/null

    # Push changes
    - ./supctl replace applications theater-room-manager < demo-specs/theater-room-manager.app.yml
    - ./supctl replace application-deployments theater-room-manager-deployment < demo-specs/theater-room-manager.dep.yml

Supctl is a python script, so we base our job on the python:3-alpine image.

We will only trigger this job if the application or deployment specifications in the demo-specs directory have changed.

In the rest of the article, we will walk through each step of this example and explain how they fit together.

Gitlab variables

In Gitlab we have registered three variables used in the script. CONTROL_TOWER is the address of the Control Tower, e.g. api.demo.the-company.avassa.net.

CT_USER and CT_PASSWORD specify credentials for a user that is allowed to create and modify the application and deployment specifications.

NOTE: CT_PASSWORD is masked, which means that Gitlab will scrub its content from the CI/CD logs. For demo reasons, we didn’t mask the CONTROL_TOWER and CT_USER variables.

Getting supctl

First, we download supctl using curl and make supctl executable.

    - apk add curl
    - curl -OL https://$CONTROL_TOWER/supctl
    - chmod +x supctl

Login

Then we use supctl to login with the credentials provided through Gitlab CI/CD variables.

    # Login to the control tower, use Gitlab CI/CD variables
    - echo "$CT_PASSWORD" | ./supctl --host=$CONTROL_TOWER do login $CT_USER > /dev/null

Push specifications

Finally, we simply use supctl replace to replace the application and deployment specifications with the new versions from the repository. If it’s the first time running, replace will merely create the specifications.

    # Push changes
    - ./supctl replace applications theater-room-manager < demo-specs/theater-room-manager.app.yml
    - ./supctl replace application-deployments theater-room-manager-deployment < demo-specs/theater-room-manager.dep.yml