Skip to content

Latest commit

 

History

History
150 lines (96 loc) · 6.96 KB

Application.md

File metadata and controls

150 lines (96 loc) · 6.96 KB

Application Onboarding


Required Information

Common

  1. Naming convention for project-id : <client-code><environment-code><region-code><data-classification>-<project-owner>-<user defined string>

    *Notice the 2 "-" before and after <project-owner>

    • client-code (2 characters)
    • environment-code (1 character) : "e" - experimentation, "d" - dev, "u" - preprod, "p" - prod
    • region-code (1 character) : "m" projects are always a global/multi-region resource
    • data-classification (1 character): "u" or "a" or "b"
    • project-owner: string (total project-id string length cannot exceed 30 characters)
    • user defined string: string (total project-id string length cannot exceed 30 characters):
  2. Billing Account ID to be associated with this project

Experimentation

  1. user, group or serviceAccount email with editor role at project level

    user or group has to exist in a Google Cloud Identity (any existing domain)

Dev, PreProd, Prod

  1. Host Project ID (with a Shared VPC) that exist to connect this workload/service project

1. Create tier34 Monorepo

  • For Experimentation, you do not require this step as all packages are deploy in a single monorepo gcp-experimentation-tier1.

  • For Dev, PreProd and Prod, follow the "Create New Deployment Monorepo" section in Repositories.md to create one gcp-<x-project-id>-tier34 monorepos.

!!! You need to replace the environment-code of the project-id with character "x" as this repo will contain the configuration for all environments. This only applies to the repo name. Do not use x as the environment code for your project-id in the setters.yaml as this will trigger a Gatekeeper validation error: admission webhook "validation.gatekeeper.sh" denied the request!!!

2. Build the Application's Project

You will build the application's project by adding packages to the tier2 monorepo.

At a high level, the process below needs to be completed for each package :

  1. Setup your change, follow step 1 of Changing.md
  2. Add a Package, follow step 2A of Changing.md
  3. Generate hydrated files, follow step 3 of Changing.md.
  4. Publish changes to repository, follow step 4 of Changing.md.
  5. Once the PR is merged, note the new tag version or commit SHA. It will be required in the next section.
  6. Synchronize and promote configuration, follow step 5 of Changing.md.

Package Details

!!! It's important that all of the steps listed above are completed for each package before proceeding with the next package. !!!

  1. The client project setup package

    • For Experimentation, you do not require this package.

    • For Dev, PreProd and Prod, you deploy this package inside the gcp-<client-name>-tier2 repo.

      • Package details (When executing step 2A):

        export TIER='tier2'
        
        export REPO_URI='https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit.git'
        
        export PKG_PATH='solutions/client-project-setup'
        
        # the version to get, located in the package CHANGELOG.md, use 'main' if not available
        export VERSION=''
        
        # replace <x-project-id> with project-id with character "x" as the environment code
        export LOCAL_DEST_DIRECTORY='projects/<x-project-id>'

        !!! You need to replace the environment-code of the project-id with character "x" as this folder will contain the configuration for all environments. This only applies to the folder name. Do not use x as the environment code for your project-id in the setters.yaml as this will trigger a Gatekeeper validation error: admission webhook "validation.gatekeeper.sh" denied the request !!!

      • Customization:

        # replace <x-project-id> with project-id with character "x" as the environment code
        export FILE_TO_CUSTOMIZE='projects/<x-project-id>/client-project-setup/setters.yaml'
  2. The client project package:

    • For Experimentation, you deploy this package inside the gcp-experimentation-tier1 repo.

      • Package details (When executing step 2A):

        export TIER='tier1'
        
        export REPO_URI='https://github.com/GoogleCloudPlatform/pubsec-declarative-toolkit.git'
        
        export PKG_PATH='solutions/experimentation/client-project'
        
        # the version to get, located in the package CHANGELOG.md, use 'main' if not available
        export VERSION=''
        
        export LOCAL_DEST_DIRECTORY='projects/<project-id>'
      • Customization:

        export FILE_TO_CUSTOMIZE='projects/<project-id>/client-project/setters.yaml'
    • For Dev, PreProd and Prod, you do not require this package.

  3. Repo-sync secrets

    • For Experimentation, you don't need to execute this step.

    • For Dev, PreProd and Prod

      • You now need to add the git-creds secret to the <project-id>-tier3 and <project-id>-tier4 namespaces that have been created by the client project setup package. This secret has to allow read access to the tier34 Azure DevOps monorepo. It is used by the configsync operator.

        !!! The secrets needs to be populated on each config controlle cluster (Dev, PreProd and Prod) !!!

      1. Export the necessary variables

        export NAMESPACE=<project-id>-tier3
        export GIT_USERNAME=<git username> # For Azure Devops, this is the name of the Organization
        export TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      2. Create git-creds secret with the required value to access the git repositories

        kubectl create secret generic git-creds --namespace=${NAMESPACE} --from-literal=username=${GIT_USERNAME} --from-literal=token=${TOKEN}
      3. Repeat for <project-id>-tier4

      4. Repeat for all other environments

THE END

Congratulations! You have completed the deployment of a client's project as per SSC implementation.