CloudTruth Integration: GitLab CI/CD Pipelines

If you’re managing one or more GitLab CI/CD pipelines, chances are you’re managing many different environments from development to production. Each of these environments (such as staging or production) typically requires its own configuration files maintained in separate repos.

Wouldn’t it be nice to have one single source of truth for environment-specific configurations that each environment could access? Using CloudTruth, you can! With CloudTruth’s GitLab pipeline integration, you can be sure to access configurations specific to each environment within GitLab pipelines.

To demonstrate CloudTruth’s GitLab pipeline integration, stay tuned to see how GitLab pipelines can access centralized configuration files containing variables using the CloudTruth API Key token.

GitLab and Configuration Files

A GitLab repository (repo) may contain dozens of applications or services with several environments requiring tens of separate configuration files based on the different environments.

Supporting multiple configuration files in a GitLab repo becomes a challenge when you intend to deploy changes to specific environments. You’ll soon find yourself overwhelmed. On top of that, you must also maintain role-based access control to ensure only the appropriate people get access to specific environmental configurations.

Introducing GitLab Environment-Specific Variables

To solve the problem of managing many different configuration files in GitLab pipelines across different environments, CloudTruth provides access to its variables via the CloudTruth CLI.

These variables are not exposed directly within the GitLab repo. Instead, they’re stored outside of GitLab within CloudTruth. You then access them within a GitLab pipeline using the CloudTruth API.

For example, let’s say you already have a GitLab pipeline set up with different environments like development, testing, and production. You must ensure the pipeline can access various secrets, host configurations, and more by the environment. Using CloudTruth Parameters and a CloudTruth API Access token, you can make it happen.

💡 According to project or environment, all the environment variables are declared in CloudTruth managed organizations as CloudTruth parameters.

Once you’ve defined the CoudTruth API access token within the GitLab repo’s CI/CD variables as something like CLOUDTRUTH_API_KEY, you’re home free. At this point, you simply need to install the CloudTruth CLI where you then can get access to all configurations available within your CloudTruth organization.

Below is a sample GitLab pipeline configuration you can use to access CloudTruth variables. You can see once you’ve installed the CloudTruth CLI, you can then add dynamic CloudTruth variables to GitLab pipeline environment files.

You can then access environment-specific configurations via environment files to then refer to values in downstream stages with job artifacts, as shown in the below code.

💡 Alternatively, you can use the CloudTruth parameter export command to create a GitLab .env file.

Install CloudTruth CLI:
  stage: build
  script:
	- curl -sL https://github.com/cloudtruth/cloudtruth-cli/releases/latest/download/install.sh | sh
	- cloudtruth -V
   
# Adds CloudTruth Values to build.env file to be passed with artifacts.reports.dotenv
	- echo "FLASK_RUN_PORT=$(cloudtruth --project MyFirstProject --env default parameters get FLASK_RUN_PORT)" >> build.env
	- echo "FLASK_MESSAGE=$(cloudtruth --project MyFirstProject --env default parameters get FLASK_MESSAGE)" >> build.env
 
# Passes environment variables between stages
  artifacts:
	reports:
  	dotenv: build.env

Using CloudTruth Variables:
  stage: test
  script:
	- echo $FLASK_RUN_PORT
	- echo $FLASK_MESSAGE
  dependencies:
	- "Install CloudTruth CLI"

Conclusion

CloudTruth solves the problem of managing multiple configurations with its GitLab pipeline integration. If you’re using GitLab pipelines, dig deeper and see how CloudTruth can help you save time and ensure a standardized, secure deployment process.