Passa al contenuto principale

Gestione dell'infrastruttura

Gestisci il team di piattaforma. Un nuovo team di sviluppo viene onboardato e ha bisogno della propria landing zone nel cloud — VPC, subnet, security group, le primitive di sempre. Vuoi un XR per team. Reviewabile in git, componibile e identico tra tutti i cloud che supporti.

Cosa stai costruendo​

Un XR XLandingZone (prefisso X per la convenzione di naming) che prende un nome di team e una region. La Composition riconcilia le primitive di rete (VPC, subnet, security group) per quel team nel cloud di tua scelta, con default sensati cotti dentro. Aggiungere un nuovo team è un solo file YAML; cancellarne uno fa il rollback di tutto.

Passi suggeriti​

  1. Leggi prima il Pattern di setup di un Provider. Ogni provider in questo journey segue la stessa forma in tre passi — install, ProviderConfig, MR — e ne caberai almeno uno. ClusterProviderConfig vs ProviderConfig per-team è il punto decisionale che conta.
  2. Scegli un cloud e percorri una MR bucket end to end: provider-aws, provider-gcp o provider-azure. Il bucket è usa-e-getta — le credenziali e il ClusterProviderConfig che metti su sono ciò che riuserai.
  3. Su Aruba si applica la stessa forma una volta che provider-aruba atterra in 3XX — CRD Aruba VPC / subnet / security-group, cablati attraverso lo stesso flusso di install + ClusterProviderConfig.
  4. Sostituisci il bucket con le primitive della landing zone. Sfoglia le CRD del provider sul Crossplane Marketplace — ogni versione pubblicata elenca i kind che spedisce e i campi che accettano. VPC, subnet, security group, route table, IAM role — scegli ciò di cui la tua landing zone ha bisogno.
  5. Avvolgi le primitive in un XRD + Composition. Riusa il pattern da Definisci un'Application: un input XR (nome del team + region), diverse MR composte sotto.
  6. Pacchettizza la landing zone come Configuration così altri cluster — staging, prod — installano la stessa forma con un solo comando.

Stretch goal​

  • ProviderConfig per-team che referenziano Secret per-team, così il blast radius resta dentro l'account cloud di un solo team.
  • Composition multi-cloud: un singolo XR LandingZone che sceglie AWS, GCP, Azure o Aruba in base a un input cloud. function-go-templating è la leva di solito.
  • Esponi il drift su .status con function-auto-ready così una subnet cancellata appare come una landing zone non-Ready in kubectl get.

Riferimenti​