fmichaelobrien
commented
2 years ago Closed fmichaelobrien closed 5 months ago
fmichaelobrien
commented
2 years ago fmichaelobrien
commented
5 months ago 20240406: Closing issue during retrofit/rebase of this TEF V1 based/modified repo to TEF V4 standards This issue may participate in the LZ refactor after rebase Query on all issues related to the older V1 version via the tag https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/labels/2024-pre-tef-v4
TBD - procedure to add a new L1 client (dev/prod/uat (ideally automated, for now yaml adjustment procedure
see also onboarding workloads https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/164 doc https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/163 hub/spoke VPC peering https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/146 example TF install https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/97
Requirements
Currently the TF repo is not configured for workload onboarding / L1 client pipelining beyond the example folder/project deployments in the main branch. We can manually add a set of 3 workload projects across the LZ for a particular client/identities but this should be automated as an adjustment to the 3 environment folders that will need adjustments to bring in a new L1 client. I am currently working on the manual procedure in prep of automating it.
How: For now use a apply/undo script like https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/blob/main/writeids.sh
or add a separate terraform yaml to apply over the existing system
There is no current workload service VPC off any of prod/nonprod - add one based on the traffic generator at https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/blob/main/docs/google-cloud-landingzone-traffic-generation.md
Add a variable reference to the 3 project owners - IAM Cloud Identity
Add the missing folder structure and associated network/firewall yamls for the “dev” folder
Yaml - Add project reference for each of 3 folders (dev, uat, prod) - see https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/blob/main/environments/prod/prod-network.auto.tfvars#L29
Yaml - add L1 org to folder structure https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/blob/main/environments/common/common.auto.tfvars#L36
For the naming standard - there are currently 16 attributes used in naming the present system detailed at https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/132. For the future system a workload bootstrap/modify/delete script/pipeline will both automate and add attributes for the particular workload/team in https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/issues/164
Discussion Define L1 as a completely separate folder - a business unit or even at the level of regional offices, an L2 would be a business/project client under that (they would shared the VPC of the L1 or as a dev client have their own peered VPC (if they need something different than their inherited K8S PaaS shared VPC for example - or a serverless endpoint not in the parent VPC).
We have 2 dimensions: 1 - different divisions + sub teams + projects per team 2 - serverless FaaS/SaaS/PaaS/IaaS workloads per team ( where teams need out of the box PaaS all the way to custom serverless and IaaS VPC's of their own)
See the org/folder/project diagram at https://github.com/GoogleCloudPlatform/pbmm-on-gcp-onboarding/blob/main/docs/architecture.md#high-level-organizational-structure The grey workload folder root should be a forest instead of a single tree (between the shared perimiter/audit/management/security folders)