Come posso installare un pool di nodi di lavoro a più cluster?

È possibile installare gli agent su più cluster che lavorano insieme all'interno di un singolo pool di nodi di lavoro privati. Utilizzando questa configurazione, il pool di nodi di lavoro privati può gestire più esecuzioni di pipeline in parallelo e puoi rimuovere i cluster dalla rotazione di manutenzione senza disattivare il pool di nodi di lavoro.

Sebbene avere più agent sullo stesso cluster supporti più pool di nodi di lavoro, non migliora le prestazioni o la velocità di trasmissione.

Per configurare un pool di nodi di lavoro a più cluster, segui le istruzioni per installazione diretta su un cluster e registrazione di un operatore privato Delivery Pipeline per ogni cluster che partecipa al pool di nodi di lavoro. Assicurati di aggiornare il nome del nodo di lavoro per identificare il cluster su cui risiede il nodo di lavoro.

I più agent di lavoro sono ora elencati nell'interfaccia utente di integrazione del nodo di lavoro privato e i lavori sono pianificati su tali agent in base al carico del cluster al momento della richiesta di esecuzione della pipeline.

Come visualizzo lo stato dei nodi di lavoro privati su più cluster utilizzando la CLI?

Puoi utilizzare il seguente comando all'interno di uno script che attraversa tutti i cluster su cui sono installati i nodi di lavoro privati.

kubectl get workeragent -ojson | jq '.items[] | .status.versionStatus.state'

Prendi in considerazione di eseguire l'upgrade dei nodi di lavoro che restituiscono dei risultati non OK.

Quali attributi posso utilizzare per gli agenti di lavoro privati?

I seguenti attributi sono disponibili per gli agent di lavoro privato:

• NAME: il nome specificato quando è stato registrato l'agent. Questo nome viene visualizzato nella pagina di integrazione del nodo di lavoro privato.
• SERVICEID: l'ID della coda di lavoro da cui questo agent elabora richieste di lavoro.
• AGENT: un valore di OK indica che l'agente può elaborare richieste di lavoro.
• REGISTERED: un valore di Succeeded indica che l'agent è stato registrato correttamente con il servizio operatore privato regionale.
• VERSIONE: il valore OK indica se la versione dell'agent è corrente.
• AUTH: il valore OK indica se l'agent apikey è valido.
• VINCOLATO: il valore false indica che sono disponibili sufficienti risorse cluster per l'agent per eseguire le attività. Il valore True specifica che il cluster è resource-constrained.
• PAUSED: il valore false indica che l'agente è operativo e può eseguire attività. Un valore di true specifica che l'agent è in pausa e non può eseguire alcuna attività. Un motivo per cui un agent potrebbe essere sospeso è per la manutenzione del cluster.

Come faccio a impostare il mio ClusterImagePolicy in modo da poter accedere alle immagini Tekton?

Poiché gli operatori privati Delivery Pipeline dipendono dall'infrastruttura Tekton e tekton - pipelines, devono eseguire il pull delle immagini tekton-releases da icr.io (icr.io/continuous-delivery/pipeline/). Potresti dover definire uno specifico Kubernetes ClusterImagePolicy per eseguire il pull delle immagini da questi registri del contenitore. Per aggiungere il tipo ClusterImagePolicy al tuo cluster Kubernetes, devi installare diversi graficiHelm.

In che modo posso ospitare automaticamente le immagini del contenitore per il nodo di lavoro privato Delivery Pipeline ?

I vincoli di sicurezza potrebbero impeirti di eseguire il pull delle immagini dal registro del contenitore icr.io/continuous-delivery/pipeline. In tali scenari, completa la seguente procedura:

1. Esegui il provisioning delle immagini contenitore su un registro contenitore supportato.

2. Installa il file deployment.yaml per fare riferimento alle immagini contenitore in questo registro contenitore.

3. Per ogni immagine contenitore a cui si fa riferimento nel file yaml di distribuzione regolare, completa la seguente procedura:

   • Docker estrarre l'immagine in un file Docker locale.
   • Docker taggare l'immagine con il nuovo riferimento nel registro dei contenitori supportati.
   • Docker spingere questa nuova immagine.

   Puoi ottenere il file deployment yaml da https://private-worker-service.$region.devops.cloud.ibm.com/install.

4. Sostituisci il riferimento a ciascuna immagine nel file di installazione con la tag per la nuova immagine.

5. Esegui questo comando per installare il nodo di lavoro privato utilizzando il registro contenitore specifico: kubectl apply –filename updated_deployment.yaml.

6. Continuare l'installazione.

Come posso eseguire il provisioning e l'aggiornamento del file di installazione del nodo di lavoro privato per IBM Cloud® Private?

Se il pipeline worker è installato su IBM Cloud Private, è possibile utilizzare il seguente script per eseguire il provisioning e aggiornare il file di installazione del worker privato.

\#\!/bin/bash
region=${region:-"us-south"}
target_cr="mycluster.icp:8500"
install_filename="updated-private-worker-install.yaml"
curl -o $install_filename
https://private-worker-service.$region.devops.cloud.ibm.com/install
cat $install_filename | grep -e
'ghcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd' -e 'image:' \\
| sed 's/- ghcr.io/ghcr.io/g' \\
| sed 's/- image: ghcr.io/ghcr.io/g' \\
| sed 's/image: ghcr.io/ghcr.io/g' \\
| sed 's/image://g' \\
| awk '{$1=$1;print}' \\
| while read -r image ; do

echo "Processing $image"
docker pull $image
new_image_tag=$image
# if $image only have a single slash it is coming from dockerhub
number_of_slashes=$(echo $image | tr -cd '/' | wc -c)
if [ "$number_of_slashes" == "1" ]; then
new_image_tag="$target_cr/$image"
fi

# replace the sha id reference in the tag if any
new_image_tag="${new_image_tag@sha256}"
# replace ghcr.io to the target cr domain
new_image_tag="${new_image_tag/ghcr.io/$target_cr}"
docker tag $image $new_image_tag
docker push $new_image_tag
# replace the image reference in the installation.yaml file
sed -i "s~$image~$new_image_tag~g" $install_filename
done

echo "*****"
echo "Provisioning of docker images to $target_cr done."
echo "Update of the install file $install_filename done"
echo "Change the scope of the images to global before"
echo "running 'kubectl apply --filename $install_filename'
echo "to install the delivery pipeline private worker"

Questo script contiene i seguenti requisiti:

• Gli spazi dei nomi ibmcom e tekton-releases esistono attualmente sulla destinazione IBM Cloud® Private.
• Il client Docker è connesso al registro dei contenitori privati di IBM Cloud® Private. Per ulteriori informazioni sull'autenticazione per la Docker CLI, vedere Configurazione dell'autenticazione per la Docker CLI.

Dopo aver fornito le immagini del contenitore nel registro privato di IBM Cloud® Private, aggiornare l'ambito dell'immagine a globale per assicurarsi che le immagini siano accessibili da qualsiasi namespace. Per ulteriori informazioni sull'aggiornamento dell'ambito di un'immagine, vedi Modifica dell'ambito dell'immagine.

È possibile fornire agli utenti della pipeline l'accesso alle immagini di base (icr.io/continuous-delivery/pipeline/pipeline-base-image) utilizzate per l'esecuzione dei lavori della pipeline, che vengono fornite dal sito globale IBM Cloud Container Registry. Per utilizzare queste immagini, devi configurare i tuoi lavori di pipeline utilizzando la Custom Dockerimage. È inoltre necessario fare riferimento all'immagine prevista nel registro privato di IBM Cloud® Private, ad esempio: mycluster.icp:8500/icr.io/continuous-delivery/pipeline/pipeline-base-image:latest.

Posso gestire i nodi di lavoro privati utilizzando Terraform o le API?

Puoi utilizzare Terraform o le API per aggiungere, aggiornare o rimuovere le integrazioni dello strumento di lavoro privato Delivery Pipeline in una toolchain. Per ulteriori informazioni sull'utilizzo dell'integrazione dello strumento di lavoro privato Delivery Pipeline, vedi Gestione delle integrazioni dello strumento e Configurazione di Delivery Pipeline Private Worker.

Non puoi utilizzare Terraform o le API per gestire i nodi di lavoro privati Delivery Pipeline. Utilizza invece la console o la CLI per installare, registrare, configurare e aggiornare i nodi di lavoro privati. Per ulteriori informazioni su queste attività, vedi Installazione di Delivery Pipeline Private Workers.