Table of Contents
- System tests setup guide for Google services
- Before you begin
- Install steps
- Recreating service accounts
- Project structure
This guides describes how to configure Google Cloud to run systems tests. In particular, the necessary service accounts are created, but not only that.
- You must have Google Cloud account with permissions to create new projects.
- You must have AWS account with permissions to create new roles.
- You must be logged into the CLI for both services -
aws
andgcloud
.
It's suggested to create a new project to run systems tests, because some system tests require very high privileges.
-
Create a new project and gcloud configuration to host our service (optional, you can use an existing project and gcloud configuration.)
export PROJECT_ID=<my-project-id> gcloud projects create "$PROJECT_ID" export CONFIG_ACCOUNT="$(gcloud config get-value account)" export CONFIG_ZONE="$(gcloud config get-value compute/zone)" export CONFIG_REGION="$(gcloud config get-value compute/region)" # create a new gcloud configuration for the project, not cessary if running in the cloud shell. gcloud config configurations create "$PROJECT_ID" gcloud config set project "$PROJECT_ID" gcloud config set account "$CONFIG_ACCOUNT" gcloud config set compute/zone "$CONFIG_ZONE" gcloud config set compute/region "$CONFIG_REGION" gcloud beta billing projects link "$PROJECT_ID" --billing-account=`gcloud beta billing accounts list --format='value(ACCOUNT_ID)' --limit 1`
-
Copy one of your existing environments as a base for your environment. Subsequent commands will only be run in this environment, so you can change your working directory.
export CURRENT_ENV_NAME="$(ls terraform/envs/ | head -n 1)" export ENV_NAME=<my-env-name> cp -r "terraform/envs/${CURRENT_ENV_NAME}" "terraform/envs/${ENV_NAME}" cd "terraform/envs/${ENV_NAME}"
-
Update the project ID in the locals section
locals { project_id = "<my-project-id>" }
-
(Optional) If you do not plan to use some service accounts, you can comment on this service account.
-
To create all resources in the environment, run:
terraform init terraform apply
After the operation is completed, you will see a summary with the number of created resources and the name of the bucket with the service accounts keys.
Apply complete! Resources: 0 added, 0 changed, 0 destroyed. Outputs: service_account_bucket_name = mik-laj-system-tests-system-tests-vosdwoos
-
Now you can verify the correct creation of the service account keys.
export SERVICE_ACCOUNT_BUCKET=service_account_bucket_name gsutil ls "gs://${SERVICE_ACCOUNT_BUCKET}/service-accounts/"
To delete all resources used by the service account and then create them again, you can use
the terraform taint
command. This command marks a resource as tainted, forcing a destroy and recreate
on the next plan/apply.
terraform taint module.campaign_manager_airflow
terraform apply
The goal of this structure is to keep terraform workspaces small and use and supporting test development for many services at the same time. Individual services do not share resources, so all resources for a one service can be deleted and restored without affecting others. The structure also supports independent development by creating separate environments.
The resources for testing each service are in a separate module
campaign_manager_airflow
dataflow_viewe_test
gcp-*
modules
There are also additional ones
service_accounts_setup
- creates a bucket and KMS keys needed to securely store service account keys.service_account_entrypted_on_gcs
- creates a service account and stores the service account key on the GCS.
There are two defined development environments:
mik-laj
- private development environment managed by Kamil Breguła.polidea
-production-like environment where all service accounts are created. Some service accounts may have granted special permission by third parties, so all service accounts cannot be deleted because some system tests will stop working.