Utilizzare le regole di automazione

Questo documento descrive le regole di automazione, ovvero azioni che è possibile intraprendere automaticamente sulla pipeline di distribuzione. 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.
advanceRolloutRule Avanza automaticamente un'implementazione dal modello

phase 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.

Le seguenti sezioni descrivono la configurazione specifica per una singola automazione le regole del caso. Vedi Automatizzare il deployment per configurare l'automazione stessa.

Configurare una regola di automazione promoteReleaseRule

La regola promoteReleaseRule promuove la release dopo un'implementazione riuscita in un obiettivo. 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 in una fase specifica del target previsto, utilizzando la proprietà destinationPhase.

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

Dove:

  • [RULE_NAME]

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

  • [WAIT_TIME]

    È la quantità di tempo, in minuti, di attesa prima che la release sia pronta per prima che venga promossa. Ad esempio, 1m. L'attributo m è obbligatorio.

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

  • [TO_TARGET]

    targetId del target da 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 in cui vuoi eseguire la promozione, 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 i deployment canary. Ad esempio, se hai una strategia di deployment canary configurati in un target, con fasi 25%, 50% e stable, potresti configura una regola di automazione che avanza automaticamente nella fase a stable al termine della fase 50%.

Quando configuri un'automazione advanceRolloutRule, identifica la fase da cui vuoi procedere (sourcePhase).

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 di distribuzione dei container.

  • [WAIT_TIME]

    La quantità di tempo, in minuti, che occorre attendere per far avanzare l'implementazione dopo il sia pronto per l'implementazione. Ad esempio, 1m. m è obbligatorio.

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

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

    Indica la fase o le fasi da cui l'implementazione viene avanzata automaticamente. Vale a dire che, quando una delle fasi elencate viene completata correttamente, l'implementazione viene avanzano automaticamente da quella fase a quella successiva.

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

Configurazione di una regola di automazione repairRolloutRule in corso...

La regola repairRolloutRule esegue nuovamente un'implementazione non riuscita un numero specificato di volte. Se il numero di nuovi tentativi è esaurito, la regola può automaticamente eseguire il rollback 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 e configurare fasi o job specifici, o entrambi, per riprovare. Se a ogni nuovo tentativo 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 o entrambi.

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]

    Indica il nome che vuoi assegnare a questa regola. Questo nome deve essere univoco all'interno di distribuzione dei container.

  • [PHASES_TO_REPAIR]

    Indica la fase o le fasi di implementazione da 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 a intervalli di un minuto. L'unità di tempo (in questo caso m) è obbligatoria.

    Se mode è linear, l'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 un pensionamento e l'altro. Se LINEAR, il tempo tra i tentativi è costante, pari a WAIT_TIME. Se EXPONENTIAL, il tempo tra un nuovo tentativo e l'altro raddoppia con ogni nuovi tentativi successivi. 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]

    Indica il nome di una fase specifica a cui vuoi eseguire il rollback. Se ometti toPhase, il rollback viene impostato sulla fase stable per impostazione predefinita.

Interrompere l'esecuzione di un'automazione repairRolloutRule

Se esegui uno dei seguenti comandi durante l'implementazione, L'automazione di repairRolloutRule è stata interrotta:

Esempio

Di seguito è riportato un esempio di configurazione di 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 sul target identificato, l'implementazione viene Riprova per 3 volte, con un minuto di attesa tra un nuovo tentativo 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