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.
supctl(you can of course use curl directly to the APIs, but
supctlprovides a nice abstraction)
- Login to the Control Tower with
- 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
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.
In Gitlab we have registered three variables used in the script.
CONTROL_TOWER is the address of the Control Tower, e.g.
CT_PASSWORD specify credentials for a user that is allowed to create and modify the application and deployment specifications.
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
First, we download
supctl using curl and make
- apk add curl - curl -OL https://$CONTROL_TOWER/supctl - chmod +x supctl
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
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