Questa pagina è stata tradotta dall'API Cloud Translation.

Convalida le app in base ai criteri aziendali in una pipeline CI

Se la tua organizzazione utilizza Policy Controller per gestire i criteri nei cluster Google Kubernetes Engine (GKE) Enterprise Edition, puoi convalidare la configurazione di deployment di un'app nella relativa pipeline di integrazione continua (CI). Questo tutorial mostra come ottenere questo risultato. La convalida dell'app è utile se sei uno sviluppatore che crea una pipeline CI per un'app o un ingegnere di piattaforma che crea un modello di pipeline CI per più team di app.

Questa pagina è rivolta agli amministratori IT e agli operatori che vogliono assicurarsi che tutte le risorse in esecuzione sulla piattaforma cloud soddisfino i requisiti di conformità fornendo e mantenendo l'automazione per le attività di applicazioni e che gestiscono il ciclo di vita dell'infrastruttura tecnica sottostante. A scopri di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento per i contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

I criteri sono una parte importante della sicurezza e della conformità di un dell'organizzazione. Policy Controller consente alla tua organizzazione di gestire questi criteri in modo descrittivo e centralizzato per tutti i cluster. In qualità di sviluppatore, puoi sfruttare la natura dichiarativa e centralizzata di queste norme. Puoi utilizzare queste caratteristiche per verificare la conformità della tua app a questi criteri il prima possibile nel flusso di lavoro di sviluppo. Informazioni sulle violazioni delle norme nella pipeline CI anziché durante la distribuzione presenta due vantaggi principali: consente la sicurezza e questo restringe il ciclo di feedback, riducendo i tempi e i costi necessari correggere tali violazioni.

Questo tutorial utilizza Cloud Build come strumento di CI e un repository GitHub di esempio contenente criteri per le dimostrazioni.

Risorse

Questo tutorial utilizza diversi strumenti Kubernetes. In questa sezione viene spiegato che cosa e come interagiscono tra loro e se è possibile sostituirli con qualcos'altro.

Gli strumenti utilizzati in questo tutorial includono i seguenti:

Policy Controller: si basa sul progetto open source Open Policy Agent - Gatekeeper. Policy Controller applica i criteri relativi agli oggetti creati in un cluster Kubernetes (ad esempio, impedisce l'utilizzo di un'opzione specifica o impone l'utilizzo di un'etichetta specifica). Questi criteri sono chiamati vincoli. I vincoli sono definiti come risorse personalizzate Kubernetes. Policy Controller è disponibile come parte della versione Google Kubernetes Engine (GKE) Enterprise, ma puoi utilizza Open Policy Agent - Gatekeeper anziché Policy Controller per la tua implementazione.
GitHub: In questo tutorial utilizziamo GitHub per ospitare i repository Git: uno per un di esempio e una che contiene i vincoli per Policy Controller. Per semplicità, i due repository sono due diverse cartelle in un unico repository Git. In realtà, si tratta di diversi repository. Puoi utilizzare qualsiasi soluzione Git.
Cloud Build: Cloud Build è la soluzione CI di Google Cloud. In questo tutorial lo utilizziamo per eseguire i test di convalida. Sebbene i dettagli dell'implementazione possano variare da un sistema CI all'altro, i concetti descritti in questo tutorial possono essere utilizzati con qualsiasi sistema CI basato su contenitori.
Kustomize: Kustomize è uno strumento di personalizzazione per le configurazioni di Kubernetes. Funziona prendendo le configurazioni "di base" e applicandovi le personalizzazioni. Ti consente di avere un approccio DRY (Don't Repeat Yourself) alle configurazioni di Kubernetes. Con Kustomize, gli elementi comuni a tutti gli ambienti vengono mantenuti nelle configurazioni di base e creare personalizzazioni per ambiente. In questo tutorial, manteniamo le configurazioni di Kustomize nel repository dell'app e "costruiamo" (ad esempio, applichiamo le personalizzazioni) le configurazioni nella pipeline CI. Puoi utilizzare i concetti delineati in questo tutorial con qualsiasi strumento che produca configurazioni Kubernetes pronte per essere applicate a un cluster (ad esempio il comando helm template).
Kpt: Kpt è uno strumento per creare flussi di lavoro per le configurazioni Kubernetes. Kpt ti consente di recuperare, visualizzare, personalizzare, aggiornare, convalidare e applicare le configurazioni Kubernetes. Poiché funziona con i file Git e YAML, è compatibile con la maggior parte degli strumenti esistenti dell'ecosistema Kubernetes. In questo tutorial utilizziamo kpt nella pipeline CI per recuperare i vincoli dal repository anthos-config-management-samples e per convalidare le configurazioni di Kubernetes in base a questi vincoli.

Pipeline

La pipeline CI utilizzata in questo tutorial è mostrata nel seguente diagramma:

Pipeline CI per Policy Controller

La pipeline viene eseguita in Cloud Build e i comandi vengono eseguiti in un contenente una copia del repository di app di esempio. La pipeline inizia generando le configurazioni Kubernetes finali con Kustomize. Poi, recupera i vincoli in base ai quali eseguire la convalida repository anthos-config-management-samples utilizzando kpt. Infine, utilizza kpt per convalidare le configurazioni di Kubernetes rispetto a questi vincoli. Per completare questo ultimo passaggio, utilizziamo una specifica funzione di configurazione chiamata gatekeeper che esegue questa convalida. In questo tutorial, attiverai la pipeline CI manualmente, ma in realtà dovresti configurarla per essere eseguita dopo un git push nel tuo repository Git.

Obiettivi

Esegui una pipeline CI per un'app di esempio con Cloud Build.
Osserva che la pipeline non funziona a causa di una violazione delle norme.
Modifica il repository dell'app di esempio in modo che sia conforme alle norme.
Esegui di nuovo la pipeline CI.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Cloud Build
Versione Enterprise di Google Kubernetes Engine (GKE)

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza Calcolatore prezzi.

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando il le risorse che hai creato. Per ulteriori dettagli, consulta la sezione Pulizia.

Prima di iniziare

Seleziona o crea un progetto Google Cloud. Nella console Google Cloud, vai alla pagina Gestisci risorse:

Vai a Gestisci risorse
Abilita la fatturazione per il tuo progetto.
Per eseguire i comandi elencati in questo tutorial, apri Cloud Shell:

Vai a Cloud Shell
In Cloud Shell, esegui gcloud config get-value project.

Se il comando non restituisce l'ID del progetto appena selezionato, configura Cloud Shell per utilizzare il progetto:
```
gcloud config set project PROJECT_ID
```
Sostituisci PROJECT_ID con l'ID progetto.

In Cloud Shell, abilita l'API Cloud Build richiesta:

gcloud services enable cloudbuild.googleapis.com

Convalida le configurazioni dell'app di esempio

In questa sezione eseguirai una pipeline CI con Cloud Build per un'app di esempio il repository che forniamo. Questa pipeline convalida la configurazione Kubernetes disponibile nel repository di app di esempio in base ai vincoli disponibili in un repository anthos-config-management-samples.

Per convalidare le configurazioni dell'app:

In Cloud Shell, clona il repository dell'app di esempio:

git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git

Esegui la pipeline CI con Cloud Build. I log della build vengono visualizzati direttamente in Cloud Shell.

cd anthos-config-management-samples/ci-app/app-repo
gcloud builds submit .

La pipeline che esegui è definita nel seguente file.

steps:
- id: 'Prepare config'
  # This step builds the final manifests for the app
  # using kustomize and the configuration files
  # available in the repository.
  name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: '/bin/sh'
  args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
- id: 'Download policies'
  # This step fetches the policies from the Anthos Config Management repository
  # and consolidates every resource in a single file.
  name: 'gcr.io/kpt-dev/kpt'
  entrypoint: '/bin/sh'
  args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git/ci-app/acm-repo/cluster@main constraints
                  && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
- id: 'Validate against policies'
  # This step validates that all resources comply with all policies.
  name: 'gcr.io/kpt-fn/gatekeeper:v0.2'
  args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']

In Policy Controller, i vincoli sono istanze di un vincolo modelli di machine learning. I modelli di vincolo contengono Il codice Rego utilizzato per implementare la classe. di blocco. Per funzionare, la funzione gcr.io/kpt-fn/gatekeeper ha bisogno sia del modello di vincolo sia delle definizioni di vincolo. Il repository dei criteri di esempio contiene entrambi, ma in realtà possono essere memorizzati in luoghi diversi. Usa il comando kpt pkg get in base alle esigenze scaricare sia i modelli che i vincoli.

Questo tutorial utilizza gcr.io/kpt-fn/gatekeeper con Cloud Build per verificare le risorse, ma puoi utilizzare altre due alternative:

Utilizza la funzione gcr.io/kpt-fn/gatekeeper con kpt:

kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2

Utilizza lo strumento a riga di comando gator:

gator test -f hydrated-manifests/kpt-manifests.yaml

Dopo alcuni minuti, osserva che la pipeline ha esito negativo e restituisce il seguente errore:

[...]
Step #2 - "Validate against policies": [error] apps/v1/Deployment/nginx-deployment : Deployment objects should have an 'owner' label indicating who created them.
Step #2 - "Validate against policies": violatedConstraint: deployment-must-have-owner
Finished Step #2 - "Validate against policies"
2022/05/11 18:55:18 Step Step #2 - "Validate against policies" finished
2022/05/11 18:55:19 status changed to "ERROR"
ERROR
ERROR: build step 2 "gcr.io/kpt-fn/gatekeeper:v0.2" failed: exit status 1
2022/05/11 18:55:20 Build finished with ERROR status

Il vincolo violato dalla configurazione è definito nel seguente file. È una risorsa personalizzata di Kubernetes chiamata K8sRequiredLabels.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: deployment-must-have-owner
spec:
  match:
    kinds:
      - apiGroups: ["apps"]
        kinds: ["Deployment"]
  parameters:
    labels:
      - key: "owner"
    message: "Deployment objects should have an 'owner' label indicating who created them."

Per il modello di vincolo corrispondente a questo vincolo, consulta requiredlabels.yaml su GitHub.

Crea autonomamente la configurazione completa di Kubernetes e osserva che l'etichetta owner è effettivamente mancante. Per creare la configurazione:
```
kubectl kustomize config/prod
```

Correggi l'app per renderla conforme alle norme aziendali

In questa sezione, correggerai la violazione delle norme utilizzando Kustomize:

In Cloud Shell, aggiungi una sezione commonLabels al file di kustomization di base:
```
cat <<EOF >> config/base/kustomization.yaml
commonLabels:
  owner: myself
EOF
```
Crea la configurazione completa di Kubernetes e verifica che l'etichetta owner sia ora presente:
```
kubectl kustomize config/prod
```

Esegui di nuovo la pipeline CI con Cloud Build:

gcloud builds submit .

Ora la pipeline riesce con il seguente output:

[...]
Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0"
Step #2 - "Validate against policies": [PASS] "gcr.io/kpt-fn/gatekeeper:v0"
[...]

Esegui la pulizia

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini elimini anche tutto il lavoro svolto nel progetto.
Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un appspot.com URL, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, il riuso dei progetti può aiutarti a non superare i limiti di quota.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi

Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.