Managing Platform Environments

Use the Core Platform dashboard first when you need to inspect existing infrastructure environments. Use the command-line setup steps later in this page when you are creating or bootstrapping environments.

Environments

The platform by default comes with a single organisation made up of three environments:

• pre-dev: Stage new versions of the platform before releasing to application engineers
• dev: Used for all development environments, functional testing, integrated testing, performance testing
• prod: Production

Check environment health in the dashboard

Open the dashboard and go to Infrastructure Environments. The list view shows each environment’s tier, Core Platform version, cloud platform, region, node usage, CPU usage, memory usage, and pod count.

Use this view to answer operational questions such as:

• which environments are connected
• which platform version each environment is running
• whether node, CPU, memory, or pod capacity is trending high
• which tier an environment belongs to

Filter by tier or search by infrastructure environment name when your organisation has more environments.

Drill into a cluster

Select an infrastructure environment to open the cluster detail page. The Nodes tab shows node count, node CPU, node memory, node pod usage, node status, machine type, zone, and conditions.

Use this tab before moving to kubectl when you need to quickly identify pressure on a node pool or confirm that nodes are ready.

If you need terminal access after checking the dashboard, connect with corectl:

corectl env connect <env-name>
kubectl get nodes
kubectl describe node <node-name>

Gcp init

The gcp-init tool comes bundled inside the platform docker image. From inside the image:

cd gcp-init
source .venv/bin/activiate
python gcp-init.py --help

Creating an organisation

It is expected to have a single organisation, meaning one set of environments.

Before execute core-platform-cli we use any of the commands, we need to generate some Application Default Credentials (ADC):

gcloud auth application-default login
mv $HOME/.config/gcloud/application_default_credentials.json $HOME/.config/gcloud/Platform-user.json

This will generate JSON credentials for your user account, and move them to a file called Platform-user.json in the gcloud config directory. We’ll use this file to authenticate as your user when running certain commands.

Before running root-init, we need to check some GCP permissions. Before we can initialize a “parent” (a GCP org or folder), we need the following:

• roles/viewer on the parent
• roles/resourcemanager.folderCreator on the parent
• roles/resourcemanager.projectCreator on the parent

We can now run the root-init command from within the core-platform-cli:

PARENT_FOLDER=??? # e.g. folders/12345
BILLING_ACCOUNT=??? # e.g. 01BC90-344AF2-CED391
ENV_REPO=???  # e.g. e.g. {{ github-org }}/platform-environments
PLATFORM_ADMIN_GROUP=???
GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/gcloud/Platform-user.json \
python gcp-init.py root-init \
    --parent=$PARENT_FOLDER \
    --billing-account=$BILLING_ACCOUNT \
    --github-repos=$ENV_REPO \
    --impersonators=group:$PLATFORM_ADMIN_GROUP \
    --owners=group:$PLATFORM_ADMIN_GROUP

This script is idempotent, if you encounter Cloud API failures, you can generally re-run the command and it will only create the missing resources.

Creating an environment

To be able to run the next step command (gcp-init.py env-init ...) we need to generate some new application credentials, allowing us to impersonate the env-manager service account from the previous step:

SA_EMAIL=$(jq -r .env_mgr_sa.email output-root_init.json)
gcloud auth application-default login --impersonate-service-account=$SA_EMAIL
mv $HOME/.config/gcloud/application_default_credentials.json $HOME/.config/gcloud/Platform-env-manager.json

This will generate JSON credentials for the service account, and move them to a file called Platform-env-manager.json in the gcloud config directory. We’ll use this file to authenticate as the SA when running certain commands.

We can now extract some information from output-root_init.json to use as input to the env-init command:

ENV=??? # e.g. dev-2
PLATFORM_ADMIN_GROUP=???
ENV_REPO=???  # e.g. e.g. {{ github-org }}/platform-environments
BILLING_ACCOUNT=???
SHARED_FOLDER=$(jq -r .shared_folder.name output-root_init.json)
ENVIRONMENTS_FOLDER=$(jq -r .environments_folder.name output-root_init.json)
MANAGEMENT_FOLDER=$(jq -r .management_folder.name output-root_init.json)
 
GOOGLE_APPLICATION_CREDENTIALS=$HOME/.config/gcloud/Platform-env-manager.json \
python gcp-init.py env-init \
    --shared-folder=$SHARED_FOLDER \
    --environments-folder=$ENVIRONMENTS_FOLDER \
    --management-folder=$MANAGEMENT_FOLDER \
    --github-repos=$ENV_REPO \
    --impersonators=group:$PLATFORM_ADMIN_GROUP \
    --name=$ENV \
    --owners=group:$PLATFORM_ADMIN_GROUP \
    --billing-account=$BILLING_ACCOUNT

This will attempt to initialize an environment called dev, as before, the script is idempotent and can generally be re-ran in the face of errors until it has completed.

![WARNING] If the errors are that your SA doesn’t have permissions to do something, that probably won’t be fixed by re-running

Manual Steps

DNS Delegation

See DNS Delegation and Identity Provider Login