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 for 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 just trigger this job if the application or deployment specifications in the demo-specs directory has 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.

Gitlab variables article

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 simply 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

Try iT yourself

Sign up for a free trial

Deploy your first container application across a distributed edge cloud. Request your free trial now to explore our solution!