Utilizzare le regole di automazione

Questo documento descrive le regole di automazione, ovvero le azioni che possono essere eseguite automaticamente nella pipeline di pubblicazione. Ad esempio, puoi configurare la pipeline di distribuzione in modo che la promozione in una destinazione specifica 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

In Cloud Deploy sono disponibili le seguenti regole di automazione:

Regola Descrizione
timedPromoteReleaseRule Promuovi automaticamente da un target all'altro

in base a una pianificazione cron.
promoteReleaseRule Promuove automaticamente una release nel target indicato dopo l'esito positivo

implementazione nel target precedente della progressione.
advanceRolloutRule Fa avanzare automaticamente un'implementazione dalla fase indicata

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

il numero di volte specificato 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 e come configurare ciascuna delle regole disponibili.

Ogni regola di automazione viene configurata nell'ambito della configurazione della risorsa di automazione. Può trovarsi all'interno dello stesso file della configurazione per la pipeline di distribuzione pertinente (di solito denominato clouddeploy.yaml) o in qualsiasi file. Scopri di più sulla configurazione delle automazioni.

Le sezioni seguenti descrivono la configurazione specifica per le singole regole di automazione. Per la configurazione dell'automazione, consulta la sezione Automazione del deployment.

Configurare una regola di automazione timedPromoteReleaseRule

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

rules:
- timedPromoteReleaseRule:
    name: "[RULE_NAME]"
    schedule: "[CRON]"
    timeZone: "[TIME_ZONE]"
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dove:

  • [RULE_NAME]

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

  • [CRON]

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

    Questa pianificazione utilizza la sintassi standard cron:

    * * * * *

    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 tua regola di promozione a tempo include la seguente pianificazione: 0 9 * * 1, la tua uscita viene promossa ogni lunedì alle 9:00.

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

    • Un intervallo (0-5)
    • Un elenco (1,3,5)
    • Una funzione a gradini (ad esempio, */3 nel campo delle ore attiva ogni terza ora)

  • [TIME_ZONE]

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

  • [TO_TARGET]

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

  • [TO_PHASE]

    È il nome della fase 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 nel secondo target.

Quando configuri un'automazione promoteReleaseRule, puoi specificare una destinazione da promuovere (destinationTargetId) o @next. Quando l'implementazione termina correttamente nel target specificato nella definizione di Automation, la release viene quindi promossa al target specificato in destinationTargetId, soggetto a un intervallo di tempo di wait.

Puoi anche promuovere una release a una fase specifica del target previsto utilizzando la proprietà destinationPhase. La sezione rules mostrata qui va inserita nella definizione dell'automazione.

rules:
- promoteReleaseRule:
    name: "[RULE_NAME]"
    wait: [WAIT_TIME]
    destinationTargetId: "[TO_TARGET]"
    destinationPhase: "[TO_PHASE]"

Dove:

  • [RULE_NAME]

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

  • [WAIT_TIME]

    È il periodo di tempo, in minuti, da attendere dopo che l'uscita è pronta per la promozione prima che venga promossa. Ad esempio, 1m. Il campo m è obbligatorio.

    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

advanceRolloutRule fa avanzare 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 implementazione canary su una destinazione, con fasi di 25%, 50% e stable, puoi configurare una regola di automazione che fa avanzare automaticamente la fase a stable al termine della fase 50%.

Quando configuri un'automazione advanceRolloutRule, identifichi la fase da far avanzare da (sourcePhase). La sezione rules mostrata qui va inserita nella definizione dell'automazione.

rules:
- advanceRolloutRule:
    name: "[RULE_NAME]"
    sourcePhases: ["[START_PHASE]", "[START_PHASE]"...]
    wait: [WAIT_TIME]

Dove:

  • [RULE_NAME]

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

  • [WAIT_TIME]

    È il periodo di tempo, in minuti, da attendere per avanzare l'implementazione dopo che è pronta. Ad esempio, 1m. Il campo m è obbligatorio.

    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 avanzata automaticamente. ovvero, quando una delle fasi elencate termina correttamente, l'implementazione passa automaticamente dalla fase in questione a quella successiva.

    I nomi delle fasi sono sensibili alle maiuscole. Inoltre, i nomi di queste fasi sono facoltativi; se ometti sourcePhases, tutte le fasi dell'implementazione vengono avanzate automaticamente.

Configurare una regola di automazione repairRolloutRule

La regola repairRolloutRule ritenta un rollout non riuscito un numero specificato di volte. Se il numero di tentativi viene esaurito, questa regola può eseguire automaticamente il rollback della destinazione all'ultima release riuscita.

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

(Facoltativo) Puoi configurare l'automazione in modo che venga eseguito il rollback all'ultima release riuscita sulla destinazione. I nuovi tentativi sono facoltativi, ma devi avere un numero di nuovi tentativi o un rollback o entrambi.

La sezione rules mostrata qui va inserita nella definizione dell'automazione.

rules:
- repairRolloutRule:
    name: "[RULE_NAME]"
    phases: [PHASES_TO_REPAIR]
    jobs: [JOBS_TO_REPAIR]
    repairPhases:
    - retry:
        attempts: [NUMBER_OF_ATTEMPTS]
        wait: [WAIT_TIME]
        backoffMode: [LINEAR | EXPONENTIAL]
    - rollback:
        destinationPhase: [PHASE_NAME]

Dove:

  • [RULE_NAME]

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

  • [PHASES_TO_REPAIR]

    Indica la fase o le fasi di implementazione da riprovare. Questa opzione è facoltativa e il valore predefinito è tutte le fasi dell'implementazione.

  • [JOBS_TO_REPAIR]

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

  • [NUMBER_OF_ATTEMPTS]

    Facoltativo, il numero di tentativi di implementazione prima di considerarla non riuscita.

  • [WAIT_TIME]

    È il tempo di attesa tra un tentativo e l'altro. 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 nuovo 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 ritiri. 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 minuto e backoffMode è impostato su EXPONENTIAL, il tempo tra l'errore e il primo tentativo è 1 minuto, il tempo tra il primo e il secondo tentativo è 2 minuti e il tempo tra il secondo e il terzo tentativo è 4 minuti.

  • rollback

    (Facoltativo) Indica se eseguire o meno il rollback dell'implementazione non riuscita dopo aver esaurito tutti i tentativi.

  • [PHASE_NAME]

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

Interrompere l'esecuzione di un'automazione repairRolloutRule

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

Esempio

Di seguito è riportato un esempio di configurazione dell'automazione con un 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:
    name: "repair-rollout"
    repairPhases:
    - retry:
        attempts: 3
        wait: 1m
        backoffMode: LINEAR
    - rollback:
        destinationPhase: "stable"

In questa automazione, se un rollout non va a buon fine sulla destinazione identificata, viene riprovato fino a 3 volte, con un'attesa di un minuto tra un tentativo e l'altro. Se tutti i tentativi di ripetizione non vanno a buon fine, viene avviato un rollback creando una nuova implementazione per eseguire il deployment dell'ultima release riuscita della destinazione.

Passaggi successivi