Per eseguire le attività di integrazione continua e le attività personalizzate, è necessario configurare un'area di lavoro per la pipeline di Automation Pipelines.

Nell'area di lavoro della pipeline, selezionare Tipo come Docker o Kubernetes e specificare il rispettivo endpoint. Le piattaforme Docker e Kubernetes gestiscono l'intero ciclo di vita del contenitore che Automation Pipelines distribuisce per l'esecuzione dell'attività di integrazione continua (CI) o dell'attività personalizzata.

  • L'area di lavoro di Docker richiede l'endpoint host Docker, l'URL dell'immagine del generatore, il registro immagini, la directory di lavoro, la cache, le variabili di ambiente, il limite di CPU e il limite di memoria. È inoltre possibile creare un clone del repository Git.
  • L'area di lavoro Kubernetes richiede l'endpoint API Kubernetes, l'URL dell'immagine del generatore, il registro immagini, lo spazio dei nomi, la NodePort, la richiesta volume persistente (PVC), la directory di lavoro, le variabili di ambiente, il limite della CPU e il limite di memoria. È inoltre possibile creare un clone del repository Git.

La configurazione dell'area di lavoro della pipeline ha molti parametri comuni e altri parametri specifici per il tipo di area di lavoro, come descritto nella tabella seguente.

Tabella 1. Aree di lavoro, dettagli e disponibilità
Selezione Descrizione Dettagli e disponibilità
Tipo Tipo di area di lavoro. Disponibile con Docker o Kubernetes.
Endpoint host Endpoint host in cui vengono eseguite le attività di integrazione continua (CI) e personalizzate.

Disponibile nell'area di lavoro di Docker quando si seleziona l'endpoint host di Docker.

Disponibile con l'area di lavoro Kubernetes quando si seleziona l'endpoint API Kubernetes.

URL immagine generatore Nome e posizione dell'immagine del generatore. Viene creato un contenitore utilizzando questa immagine nell'host Docker e nel cluster Kubernetes. Le attività di integrazione continua (CI) e le attività personalizzate vengono eseguite in questo contenitore.

Esempio: fedora:latest

L'immagine del generatore deve avere curl o wget.

Registro immagini Se l'immagine del generatore è disponibile in un registro e il registro richiede le credenziali, è necessario creare un endpoint del Registro immagini, quindi selezionarlo qui in modo che l'immagine possa essere estratta dal registro. Disponibile con le aree di lavoro di Docker e Kubernetes.
Directory di lavoro La directory di lavoro è la posizione all'interno del contenitore in cui vengono eseguiti i passaggi dell'attività di integrazione continua (CI), nonché la posizione in cui il codice viene clonato quando un webhook Git attiva l'esecuzione di una pipeline. Disponibile con Docker o Kubernetes.
Spazio dei nomi Se non si immette uno spazio dei nomi, Automation Pipelines crea un nome univoco nel cluster Kubernetes specificato. Specifico dell'area di lavoro Kubernetes.
Proxy

Per comunicare con il pod dell'area di lavoro nel cluster Kubernetes, Automation Pipelines distribuisce una singola istanza del proxy nello spazio dei nomi codestream-proxy per ogni cluster Kubernetes. È possibile scegliere il tipo NodePort o LoadBalancer in base alla configurazione del cluster.

L'opzione selezionata dipende dalla natura del cluster Kubernetes distribuito.

  • In genere, se l'URL del server dell'API Kubernetes specificato nell'endpoint viene esposto tramite uno dei nodi primari, selezionare NodePort.
  • Se l'URL del server dell'API Kubernetes viene esposto da un bilanciamento del carico, come con Amazon EKS (Elastic Kubernetes Service), selezionare LoadBalancer.
NodePort

Automation Pipelines utilizza NodePort per comunicare con il contenitore in esecuzione all'interno del cluster Kubernetes.

Se non si seleziona una porta, Automation Pipelines utilizza una porta non attiva assegnata da Kubernetes. È necessario assicurarsi che la configurazione delle regole del firewall consenta l'ingresso nell'intervallo di porte temporanee (30000-32767).

Se si immette una porta, è necessario assicurarsi che un altro servizio nel cluster non la stia già utilizzando e che la porta sia consentita dalle regole del firewall.

Specifico dell'area di lavoro Kubernetes.
Richiesta volume persistente

Offre un modo per mantenere i file nell'area di lavoro Kubernetes durante le esecuzioni della pipeline. Quando si fornisce un nome di richiesta volume persistente, esso può archiviare i registri, gli artefatti e la cache.

Per ulteriori informazioni sulla creazione di una richiesta volume persistente, vedere la documentazione di Kubernetes all'indirizzo https://kubernetes.io/docs/concepts/storage/persistent-volumes/.

Specifico dell'area di lavoro Kubernetes.
Variabili di ambiente Le coppie chiave-valore passate qui saranno disponibili per tutte le attività di integrazione continua (CI) e le attività personalizzate in una pipeline quando viene eseguita.

Disponibile con Docker o Kubernetes.

I riferimenti alle variabili possono essere passati qui.

Le variabili di ambiente fornite nell'area di lavoro vengono passate a tutte le attività di integrazione continua (CI) e alle attività personalizzate nella pipeline.

Se le variabili di ambiente non vengono passate qui, tali variabili devono essere esplicitamente passate a ogni attività di integrazione continua (CI) e attività personalizzata nella pipeline.

Limiti CPU Limiti per le risorse CPU per il contenitore di integrazione continua (CI) o il contenitore di attività personalizzate. Il valore predefinito è 1.
Limiti di memoria Limiti di memoria per il contenitore di integrazione continua (CI) o il contenitore di attività personalizzate. L'unità è MB.
Clone Git Quando si seleziona Clone Git e un webhook Git richiama la pipeline, il codice viene clonato nell'area di lavoro (contenitore). Se non si abilita Clone Git, è necessario configurare un'altra attività di integrazione continua (CI) esplicita nella pipeline per clonare innanzitutto il codice e quindi eseguire altri passaggi come la creazione e il test.
Cache

L'area di lavoro di Automation Pipelines consente di memorizzare nella cache un set di directory o file per velocizzare le esecuzioni della pipeline successive. Esempi di queste directory sono .m2 e npm_modules. Se non è necessario memorizzare nella cache i dati tra le esecuzioni della pipeline, non è necessaria una richiesta di volume persistente.

Gli artefatti come i file o le directory nel contenitore vengono memorizzati nella cache per poter essere riutilizzati nelle esecuzioni della pipeline. Ad esempio, le cartelle node_modules o .m2 possono essere memorizzate nella cache. Cache accetta un elenco di percorsi.

Ad esempio:

workspace:
  type: K8S
  endpoint: K8S-Micro
  image: fedora:latest
  registry: Docker Registry
  path: ''
  cache:
    - /path/to/m2
    - /path/to/node_modules

Specifico per il tipo di area di lavoro.

Nell'area di lavoro di Docker, la Cache viene ottenuta utilizzando un percorso condiviso nell'host Docker per conservare i dati, gli artefatti e i registri memorizzati nella cache.

Nell'area di lavoro di Kubernetes, per consentire l'utilizzo di Cache, è necessario specificare una richiesta di volume persistente. In caso contrario, Cache non è disponibile.

Quando si utilizza un endpoint API Kubernetes nell'area di lavoro della pipeline, Automation Pipelines crea le risorse Kubernetes necessarie, come ConfigMap, Secret e Pod per eseguire l'attività di integrazione continua (CI) o l'attività personalizzata. Automation Pipelines comunica con il contenitore tramite la NodePort.

Per condividere i dati tra le esecuzioni della pipeline, è necessario fornire una richiesta volume persistente e Automation Pipelines monterà la richiesta volume persistente nel contenitore per archiviare i dati e utilizzarla per le esecuzioni della pipeline successive.

Nell'area di lavoro Kubernetes, quando si utilizza un endpoint API Kubernetes locale con l'autenticazione basata su certificato, è necessario assicurarsi che il proxy cloud sia aggiornato alla versione più recente. In caso contrario, l'autenticazione potrebbe non riuscire.