Utilizzare le regole di automazione

Questo documento descrive le regole di automazione, ovvero le azioni che possono essere eseguite automaticamente nella pipeline di distribuzione. Ad esempio, puoi configurare la pipeline di distribuzione in modo che la promozione a un target specifico avvenga automaticamente, nelle giuste circostanze.

Puoi utilizzare solo le regole di automazione integrate in Cloud Deploy. Le regole di automazione disponibili sono elencate in questo documento.

Regole di automazione disponibili

Le seguenti regole di automazione sono disponibili in Cloud Deploy:

Regola Descrizione
timedPromoteReleaseRule Promuovi automaticamente da un target al successivo

in base a una pianificazione cron.
promoteReleaseRule Promuove automaticamente una release nel target indicato dopo il

completamento dell'implementazione nel target precedente nella progressione.
advanceRolloutRule Porta automaticamente un'implementazione dalla

fase indicata alla fase successiva.
repairRolloutRule Riprova automaticamente il job o i job non riusciti nell'implementazione un

numero specificato di volte ed esegui il rollback se tutti i tentativi non vanno a buon fine.

Configurare le regole di automazione

La configurazione di ogni regola di automazione dipende dalla regola specifica. Questa sezione descrive la configurazione comune a tutte le regole, nonché come configurare ciascuna delle regole disponibili.

Ogni regola di automazione viene configurata come parte della configurazione della risorsa di automazione. Può trovarsi nello stesso file della configurazione della pipeline di distribuzione pertinente (in genere denominato clouddeploy.yaml) o in qualsiasi file tu voglia. Scopri di più sulla configurazione delle automazioni.

Le sezioni seguenti descrivono la configurazione specifica delle singole regole di automazione. Per la configurazione dell'automazione stessa, consulta Automatizzare il deployment.

Configurare una regola di automazione timedPromoteReleaseRule

La regola timedPromoteReleaseRule consente di pianificare quando promuovere una release dal target o dai target selezionati al target successivo nella progressione o a un target specifico. Quando configuri un'automazione timedPromoteReleaseRule, specifichi quando promuovere la release, in base a una pianificazione cron.

rules:
- timedPromoteReleaseRule:
    id: "[RULE_ID]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dove:

  • [RULE_ID]

    È un nome che vuoi assegnare a questa regola. Questo nome deve essere univoco all'interno della risorsa di automazione.

  • [CRON]

    È la pianificazione cron che specifica quando promuovere la release. Utilizza questa pianificazione per specificare la data e l'ora in cui vuoi promuovere la release.

    Questa pianificazione utilizza la sintassi cron standard:

    * * * * *

    In questa pianificazione...

    • La prima posizione è il minuto (0-59).
    • La seconda posizione è l'ora (0-23).
    • La terza posizione è il giorno del mese (1-31).
    • La quarta posizione è il mese (1-12).
    • La quinta posizione è il giorno della settimana (0-6, da domenica a sabato)

    Ad esempio, se la regola di promozione programmata include la seguente pianificazione: 0 9 * * 1, la release viene promossa ogni lunedì alle 9:00.

    Puoi anche utilizzare le funzionalità standard della pianificazione cron, ad esempio:

    • Un intervallo (0-5)
    • Un elenco (1,3,5)
    • Una funzione di passaggio (ad esempio, */3 nel campo delle ore attiva ogni tre ore)

  • [TIME_ZONE]

    È il fuso orario che vuoi utilizzare per pianificare la promozione, in formato IANA.

  • [TO_TARGET]

    È il targetId del target a cui promuovere o @next per promuovere automaticamente la release al target successivo dopo il target specificato nella selector.targets property in questa configurazione di automazione. Questo è facoltativo; il valore predefinito è @next.

  • [TO_PHASE]

    È il nome della fase a cui vuoi promuovere, ad esempio canary-25 o stable. Questa proprietà è facoltativa; se la ometti, la release viene promossa alla prima fase del target.

Configurare una regola di automazione promoteReleaseRule

La regola promoteReleaseRule promuove la release dopo un'implementazione riuscita in un target. Ad esempio, se hai tre target, puoi configurare questa regola in modo che, quando la release viene implementata correttamente nel primo target, venga promossa automaticamente al secondo target.

Quando configuri un'automazione promoteReleaseRule, puoi specificare un target a cui promuovere (destinationTargetId) o @next. Al termine dell'implementazione nel target specificato nella definizione di Automation, la release viene promossa al target specificato in destinationTargetId, soggetto a un intervallo di tempo di wait.

Puoi anche promuovere una release a una fase specifica nel target previsto utilizzando la proprietà destinationPhase. La sezione rules mostrata qui si trova all'interno della tua definizione di automazione.

rules:
- promoteReleaseRule:
    id: "[RULE_ID]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dove:

  • [RULE_ID]

    È un nome che vuoi assegnare a questa regola. Questo nome deve essere univoco all'interno della risorsa di automazione.

  • [WAIT_TIME]

    È il tempo, in minuti, di attesa dopo che la release è pronta per la promozione prima che venga promossa. Ad esempio, 1m. La m è obbligatoria.

    Il valore predefinito è 0, ovvero nessun tempo di attesa. Il valore massimo è 20160m (o 14 giorni).

  • [TO_TARGET]

    È il targetId del target a cui promuovere.

    Può anche essere @next, che promuove automaticamente la release al target successivo dopo il target specificato nella proprietà selector.targets in questa configurazione di automazione. Questo è il valore predefinito se ometti il valore da destinationTargetId.

  • [TO_PHASE]

    È il nome della fase a cui vuoi promuovere, ad esempio canary-25 o stable. Questa proprietà è facoltativa; se la ometti, la release viene promossa alla prima fase del target.

Configurare una regola di automazione advanceRolloutRule

La regola advanceRolloutRule porta automaticamente l'implementazione alla fase successiva dopo il completamento di una fase. Questa regola di automazione è utile per i deployment canary. Ad esempio, se hai configurato una strategia di deployment canary su un target, con fasi di 25%, 50% e stable, puoi configurare una regola di automazione che porta automaticamente la fase a stable al termine della fase 50%.

Quando configuri un'automazione advanceRolloutRule, identifichi la fase da cui portare avanti (sourcePhase). La sezione rules mostrata qui si trova all'interno della tua definizione di automazione.

rules:
- advanceRolloutRule:
    id: "[RULE_ID]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Dove:

  • [RULE_ID]

    È un nome che vuoi assegnare a questa regola. Questo nome deve essere univoco all'interno della risorsa di automazione.

  • [WAIT_TIME]

    È il tempo, in minuti, di attesa per portare avanti l'implementazione dopo che è pronta. Ad esempio, 1m. La m è obbligatoria.

    Il valore predefinito è 0, ovvero nessun tempo di attesa. Il valore massimo è 20160m (o 14 giorni).

  • ["[START_PHASE]", "[START_PHASE]"...]

    È la fase o le fasi da cui l'implementazione viene portata avanti automaticamente. Ovvero, al termine di una delle fasi elencate, l'implementazione viene portata avanti automaticamente da quella fase alla fase successiva.

    I nomi delle fasi sono sensibili alle maiuscole. Inoltre, questi nomi di fase sono facoltativi; se ometti sourcePhases, tutte le fasi dell'implementazione vengono portate avanti automaticamente.

Configurare una regola di automazione repairRolloutRule

La regola repairRolloutRule riprova un'implementazione non riuscita un numero specificato di volte. Se questo numero di tentativi viene esaurito, questa regola può eseguire automaticamente il rollback del target all'ultima release riuscita.

Quando configuri un'automazione repairRolloutRule, puoi specificare il numero di volte in cui riprovare l'implementazione e il tempo di attesa tra i tentativi. Puoi anche configurare fasi o job specifici, o entrambi, per riprovare. Se ogni tentativo non va a buon fine, l'implementazione non riesce. Se un tentativo va a buon fine, l'automazione si interrompe e l'implementazione riesce.

Facoltativamente, puoi configurare l'automazione in modo che esegua il rollback all'ultima release riuscita sul target. I tentativi sono facoltativi, ma devi avere un certo numero di tentativi o un rollback, o entrambi.

La sezione rules mostrata qui si trova all'interno della tua definizione di automazione.

rules:
- repairRolloutRule:
    id: "[RULE_ID]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]
        disableRollbackIfRolloutPending: [true | false]

Dove:

  • [RULE_ID]

    È un nome che vuoi assegnare a questa regola. Questo nome deve essere univoco all'interno della risorsa di automazione.

  • [PHASES_TO_REPAIR]

    È la fase o le fasi di implementazione da riprovare. Questo è facoltativo e il valore predefinito sono tutte le fasi dell'implementazione.

  • [JOBS_TO_REPAIR]

    È il job o i job da riprovare. Questo è facoltativo e il valore predefinito sono tutti i job.

  • [NUMBER_OF_ATTEMPTS]

    Facoltativo, il numero di volte in cui riprovare l'implementazione prima di considerarla non riuscita.

  • [WAIT_TIME]

    È il tempo di attesa tra i tentativi. Ad esempio, 1m per un intervallo di un minuto. L'unità di tempo (m in questo caso) è obbligatoria.

    Se mode è linear, questo intervallo è lo stesso per ogni tentativo. Se mode è exponential, l'intervallo aumenta ogni volta. (Per una descrizione più dettagliata, consulta mode.)

  • backoffMode

    LINEAR o EXPONENTIAL, che indica se aumentare o meno il tempo tra i tentativi. Se LINEAR, il tempo tra i tentativi è costante, pari a WAIT_TIME. Se EXPONENTIAL, il tempo tra i tentativi raddoppia a ogni tentativo successivo. Il valore predefinito è LINEAR.

    Ad esempio, se WAIT_TIME è 1 m e backoffMode è impostato su EXPONENTIAL, il tempo tra l'errore e il primo tentativo è di 1 minuto, il tempo tra il primo e il secondo tentativo è di 2 minuti e il tempo tra il secondo e il terzo tentativo è di 4 minuti.

  • rollback

    Facoltativo, indica se eseguire o meno il rollback dell'implementazione non riuscita dopo che tutti i tentativi sono stati esauriti.

  • [PHASE_NAME]

    È il nome di una fase specifica a cui vuoi eseguire il rollback. Se ometti toPhase, il rollback viene eseguito per impostazione predefinita alla fase stable.

  • disableRollbackIfRolloutPending:

    Se impostato su true, l'operazione di rollback viene interrotta se è in attesa un'implementazione sul target.

Interrompere l'esecuzione di un'automazione repairRolloutRule

Se esegui uno dei seguenti comandi sull'implementazione, l'automazione repairRolloutRule viene interrotta:

Esempio

Di seguito è riportato un esempio di configurazione di automazione con una repairRolloutRule:

apiVersion: deploy.cloud.google.com/v1
kind: Automation
metadata:
  name: regular-repair/regular
description: repair regular rollouts
suspended: false
serviceAccount: (REDACTED)
selector:
  targets:
  - id: t1
rules:
- repairRolloutRule:
    id: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

In questa automazione, se un'implementazione non riesce sul target identificato, viene riprovata fino a 3 volte, con un'attesa di un minuto tra un tentativo e l'altro. Se tutti i tentativi non vanno a buon fine, viene avviato un rollback creando una nuova implementazione per eseguire il deployment della release riuscita più recente del target in quel target.

Passaggi successivi