Hello, this is the CAPI team's CI repo. It houses Concourse configuration settings for our CI environments.
Check it out! https://concourse.app-runtime-interfaces.ci.cloudfoundry.org/teams/capi-team/pipelines/capi
📌 This repository has gone through a complete overhaul. The old artifacts can still be found on the legacy branch.
See pipeline.yml for more details.
________________________________________________________________________
/ \ \
| | Elsa: biggest and most "real" environment |
\_ | · Long-lived |
| · HA / Multi-AZ |
| · Windows cell |
| · Encrypted database |
| · Clustered database |
| · Runtime CredHub (assisted mode) |
| . Webserver: Thin |
| · Database: MySQL |
| · Platform: GCP |
| · Blobstore: GCP blobstore |
| |
| Kiki: used for testing that db migrations are backwards compatible |
| · Short-lived |
| . Webserver: Thin |
| · Database: PostgreSQL |
| · Platform: GCP |
| · Blobstore: WebDAV |
| |
| Asha: used for testing CATS and CAPI-BARA tests on MySQL with Puma |
| · Short-lived |
| . Webserver: Puma
| · Database: MySQL |
| · Platform: GCP |
| · Blobstore: WebDAV |
| |
| Olaf: used for running CATS and CAPI-BARA tests on AWS with MySQL |
| · Short-lived |
| . Webserver: Thin |
| · Database: MySQL |
| · Platform: AWS |
| · Blobstore: S3 |
| |
| Scar: used for testing CATS and CAPI-BARA tests on PostgreSQL |
| · Short-lived |
| . Webserver: Thin |
| · Database: PostgreSQL |
| · Platform: GCP |
| · Blobstore: WebDAV |
| |
| Gyro: used for testing experimental features on GCP / PostgreSQL |
| · Short-lived |
| . Webserver: Puma |
| · Database: PostgreSQL |
| · Platform: GCP |
| · Blobstore: WebDAV |
| ___________________________________________________________________|___
| / /
\_/______________________________________________________________________/
Kiki starts with an older version of cf-deployment. It then runs the new migrations, but keeps the old Cloud Controller code. This catches any backwards-incompatible migrations. This is important because Cloud Controller instances do rolling upgrades. For example: if you write a migration that drops a table, old CC instances that depend on that table existing will crash during the rolling deploy.
This pipeline is responsible for testing, building, and releasing capi-release. For guidance on releasing CAPI, see this document.
This is where the majority of testing for capi-release components live.
- Runs unit tests for Cloud Controller and bridge components
- Builds capi-release release candidates and deploys to Elsa, Kiki, Asha, Olaf, and Scar
- Runs appropriate integration tests for each environment
- Bumps the
ci-passedbranch of capi-release - Updates release candidate in v3 docs every time
ci-passedbranch is updated.
Automatically bumps golang version for capi-release components every time a new golang-release is available. Also bumps Valkey and nginx.
Jobs responsible for cutting a capi-release.
- Bump API versions
- Update API docs
- Release capi-release
Updates the bosh deployments for all the pipeline environments (using bbl up).
Theoretically useful for destroying broken bosh deployments for all the pipeline environments. Often doesn't work because the directors are in such bad state. There are also jobs to manually release pool resources for the following environments: Elsa, Asha, and Scar.
Pipeline responsible for managing the development bosh-lite pool.
- Create new bosh-lites if there is room in the pool
- Delete released bosh-lites
Automatic certificate rotation for the long-lived environments (currently only Elsa). The goal is to prevent certificate expiration. The jobs perform a three-step CA certificate rotation according to the CredHub CA Rotation documentation. The list of CA certificates is hard-coded in the rotate_steps.yml task. When a new CA certificate is added or deleted from cf-deployment, the list needs to be updated. Each job of the pipeline is idempotent and can be retriggered in case of a failure. Note however that the order of the jobs must be preserved in case of manual intervention.
Note: Do not make the pipeline "public" in Concourse as the log shows sensitive data!
Should the rotation fail unexpectedly, you can inspect the current certificate state with the CredHub API:
credhub curl -p "/api/v1/certificates?name=/elsa-ha/cf/<certificate name>"
This command shows the certificate metadata and all certificate versions. For CA certificates, the list of signed certificates is shown which is used in the 2nd step to regenerate the child certificats. The certificate versions also contain the "transitional" flag which is created, moved and deleted in steps 1, 2 and 3, respectively.
If the certificate state is broken and cannot be repaired, the deployment and its credentials can be deleted with bosh -d cf delete-deployment. The next run of job "elsa-ha-deploy-cf" will redeploy CF from scratch.
There are a number of helpful scripts in capi-workspace for using the bosh-lite pool. Most notably, claim_bosh_lite, unclaim_bosh_lite, and print_env_info. See the commands list for a full list of useful commands for interacting with the pool.