Utilizzare le regole di automazione

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

In Cloud Deploy sono disponibili le seguenti regole di automazione:

Regola Descrizione
promoteReleaseRule Promuove automaticamente una release nel target indicato dopo il completamento

nel target precedente della progressione.
timedPromoteReleaseRule Promuovi automaticamente da un target all'altro

in base a una pianificazione cron.
advanceRolloutRule Avanza automaticamente un'implementazione dall'indicazione

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

numero di volte specificato e esegue 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. In questa sezione viene descritta la configurazione che tutte le regole hanno in comune, nonché come configurare ciascuna delle regole disponibili.

Ogni regola di automazione viene configurata nell'ambito della configurazione della risorsa di automazione. Può trovarsi nello stesso file della configurazione della pipeline di importazione pertinente (in genere denominata clouddeploy.yaml) o in qualsiasi file che preferisci. 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 stessa, consulta Automatizzare il deployment.

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 di promozione (destinationTargetId) o @next. Quando l'implementazione viene completata correttamente nel target specificato nella definizione di Automation, la release viene promossa al target specificato in destinationTargetId, in base a un intervallo di tempo di wait.

Puoi anche promuovere una release a una fase specifica nel target previsto utilizzando la proprietà destinationPhase. La stanza 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, che deve trascorrere prima che la release sia pronta per la promozione. 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 successivo target dopo il target specificato nella proprietà selector.targets in questa configurazione dell'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 nel target.

Configurare una regola di automazione timedPromoteReleaseRule

La regola timedPromoteReleaseRule ti consente di pianificare quando promuovere una release dal target o 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 importazione.

  • [CRON]

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

    Questa pianificazione utilizza la sintassi standard di cron:

    * * * * *

    In questo programma…

    • 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 tua uscita viene promossa ogni lunedì alle 9:00.

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

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

  • [TIME_ZONE]

    È il fuso orario da utilizzare per la pianificazione della promozione, in formato IANA.

  • [TO_TARGET]

    È il targetId del target a cui eseguire la promozione o @next per promuovere automaticamente la release al target successivo dopo quello specificato in selector.targets property in questa configurazione di automazione. Questo valore è 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 nel target.

Configurare una regola di automazione advanceRolloutRule

advanceRolloutRule avanza 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 un target, con fasi 25%, 50% e stable, puoi configurare una regola di automazione che avanzi automaticamente alla fase stable al termine della fase 50%.

Quando configuri un'automazione advanceRolloutRule, identifichi la fase da avanzare (sourcePhase). La stanza rules mostrata qui viene 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 importazione.

  • [WAIT_TIME]

    È il periodo di tempo, in minuti, da attendere per avanzare con l'implementazione dopo che è stata completata. 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 viene avanzata automaticamente l'implementazione. In altre parole, quando una delle fasi elencate viene completata correttamente, l'implementazione viene avanzata automaticamente dalla fase in questione 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 avanzate automaticamente.

Configurare una regola di automazione repairRolloutRule

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

Quando configuri un'automazione repairRolloutRule, puoi specificare quante volte ripetere l'implementazione e il tempo di attesa tra le ripetizioni. Puoi anche configurare fasi o job specifici, o entrambi, per riprovare. Se ogni nuovo tentativo non va a buon fine, l'implementazione non va a buon fine. Se un nuovo tentativo va a buon fine, l'automazione si interrompe e l'implementazione va a buon fine.

Facoltativamente, puoi configurare l'automazione in modo da eseguire il rollback all'ultima release riuscita sul target. Anche i nuovi tentativi sono facoltativi, ma devi avere un certo numero di nuovi tentativi o un rollback oppure entrambi.

La stanza 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 importazione.

  • [PHASES_TO_REPAIR]

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

  • [JOBS_TO_REPAIR]

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

  • [NUMBER_OF_ATTEMPTS]

    (Facoltativo) Il numero di volte per cui ripetere l'implementazione prima di considerarla non riuscita.

  • [WAIT_TIME]

    È il tempo di attesa tra i tentativi di ripetizione. 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, per indicare se aumentare o meno il tempo tra un ritiro e l'altro. Se LINEAR, il tempo tra i tentativi è costante, pari a WAIT_TIME. Se EXPONENTIAL, il tempo tra i tentativi raddoppia con ogni tentativo successivo. Il valore predefinito è LINEAR.

    Ad esempio, se WAIT_TIME è 1m 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) Se eseguire o meno il rollback dell'implementazione non riuscita dopo aver esaurito tutti i tentativi di nuovo tentativo.

  • [PHASE_NAME]

    È il nome di una fase specifica a cui vuoi eseguire il rollback. Se ometti toPhase, il rollback predefinito è la fase stable.

Interrompere l'esecuzione di un'automazione repairRolloutRule

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

Esempio

Di seguito è riportato un esempio di configurazione di un'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'implementazione non va a buon fine nel target identificato, viene eseguita nuovamente fino a 3 volte, con un'attesa di un minuto tra un tentativo di ripetizione e l'altro. Se tutti i tentativi di nuovo tentativo non vanno a buon fine, viene avviato un rollback creando una nuova implementazione per eseguire il deployment della release di destinazione più recente andata a buon fine nel target.

Passaggi successivi