Prerequisiti

Prima di installare un nodo di lavoro privato, assicurati di avere un account IBM Cloud® per creare le chiavi di autenticazione. È necessaria l'ultima versione di kubectl installata sul computer desktop dell'amministratore. Inoltre, per installare un worker privato è necessario disporre di un cluster Kubernetes (versione 1.15 o successiva) con diritti di amministratore.

• Configurazioni del cluster Kubernetes suggerite:

  • IBM Cloud Kubernetes Service versione 1.21 o superiore per eseguire carichi di lavoro in modo isolato su IBM Cloud Public.
  • Red Hat® OpenShift® on IBM Cloud® versione 4.9 o successiva.

• Accesso alla rete:

  • In entrata: non richiesto.

  • L'accesso alla rete in uscita utilizza (TCP:443), dove la regione corrisponde alla posizione della pipeline di distribuzione ed è una delle seguenti: au-syd (Sydney, Australia), eu-de (Francoforte, Germania), eu-gb (Londra, Regno Unito), jp-tok (Tokyo, Giappone), us-south (Dallas, Stati Uniti), us-east (Washington DC, Stati Uniti), br-sao (San Paolo) o ca-tor (Toronto, Canada). Ad esempio, per la regione Francoforte, specifica https://private-worker-service.eu-de.devops.cloud.ibm.com (TCP:443). Per l'accesso alla rete all'endpoint globale per la convalida della chiave API, utilizza https://iam.cloud.ibm.com (TCP:443).

• Autorizzazioni per eseguire il pull delle immagini da icr.io. I worker privati richiedono l'infrastruttura tekton-pipelines e devono poter scaricare le immagini tekton-releases da icr.io per completare l'installazione dei worker privati.

  Per estrarre le immagini dal registro dei contenitori icr.io, potrebbe essere necessario definire uno specifico Kubernetes ClusterImagePolicy.

Poiché i lavoratori privati non sono compatibili con le pipeline di Red Hat OpenShift, si consiglia di non installarli su un cluster con le pipeline di Red Hat OpenShift.

Installazione di un nodo di lavoro privato Delivery Pipeline

Per installare un nodo di lavoro privato, devi avere accesso a un cluster a livello di amministratore. L'installazione del nodo di lavoro privato può essere completata solo tramite la riga di comando poiché non è disponibile alcuna interfaccia utente grafica.

kubectl apply --filename "https://private-worker-service.{REGION}.devops.cloud.ibm.com/install"

kubectl apply --filename "https://private-worker-service.{REGION}.devops.cloud.ibm.com/install?private=true"

Registrazione di un nodo di lavoro privato Delivery Pipeline

$ ibmcloud iam service-id-create {worker-pool-name} -d "{worker-pool-description}"
Creating service ID {worker-pool-name} bound to current account as username@domain.com...OK
Service ID {worker-pool-name} is created successfully
Name           {worker-pool-name}
Description    {worker-pool-description}
CRN            crn:v1:bluemix:public:iam-identity::a/8d63fb1cc5e99e86dd7229dddff75fef::serviceid:ServiceId-38ffff31-3ea3-4ecc-9732-190f7a993097
Bound To       crn:v1:bluemix:public:::a/8d63fb1cc5e99e86dd7229dddff75fef:::
Version        1-6df15bde97b6e87f583a557f8731888f
Locked         false
UUID         ServiceId-38ffff31-3ea3-4ecc-9732-190f7a993097

$ ibmcloud iam service-api-key-create {worker-api-key-name} (SERVICE\_ID\_NAME|SERVICE\_ID\_UUID) \[-d, --description DESCRIPTION\] \[--file OUT_FILE\]
Creating API key  {worker-api-key-name} of service
SERVICE\_ID\_NAME as username@domain.com...
OK
Service API key {worker-api-key-name} is created
Successfully saved API key information to FILE
Please preserve the API key! It cannot be retrieved after it's created.
Name           {worker-api-key-name}
Description    Description
Bound To       crn:v1:bluemix:public:iam-identity::a/2cac145ae78048679b129009cfe8c7f9::serviceid:ServiceId-9a6a14e5-5811-4c2c-9131-0e1d4bb7dfe1
Created At     2019-07-04T10:51+0000
API Key        doJX9kORc4q5PRkH19H3lePDwYRAKNWk4XlIuEBrriOD
Locked         false
UUID           ApiKey-c1ee0fb5-90f2-476e-a260-a796e6d7f5f7

$ kubectl create secret generic {WORKER_NAME}-auth -n default --from-literal=apikey={API_KEY} && kubectl apply --filename "https://private-worker-service.{REGION}.devops.cloud.ibm.com/install/worker?serviceId={SERVICE_ID}&name={WORKER_NAME}"
workeragent.devops.cloud.ibm.com/worker-name created
secret/worker-name-auth created

  * `au-syd` (Sydney, Australia)
  * `eu-de` (Francoforte, Germania)
  * `eu-gb` (Londra, Regno Unito)
  * `jp-tok` (Tokyo, Giappone)
  * `us-south` (Dallas, Stati Uniti)
  * `us-east` (Washington DC, Stati Uniti)
  * `ca-tor` (Toronto, Canada)
  * `br-sao` (San Paolo, Brasile)

   $ kubectl create secret generic {WORKER_NAME}-auth -n default --from-literal=apikey={API_KEY} && kubectl apply --filename "https://private-worker-service.{REGION}.devops.cloud.ibm.com/install/worker?serviceId={SERVICE_ID}&name={WORKER_NAME}&private=true"

  * Francoforte `eu-de`
  * Londra `eu-gb`
  * Dallas `us-south`
  * Washington DC `us-east`

$ kubectl get workeragents
NAME           SERVICEID     AGENT   REGISTERED   VERSION   AUTH   CONSTRAINED   PAUSED
<worker_name>  <ServiceId>   OK      Succeeded    OK        OK     false         false

Configurazione del nodo di lavoro privato Delivery Pipeline per utilizzare gli endpoint privati

Per impostazione predefinita, i nodi di lavoro privati utilizzano endpoint pubblici per la comunicazione. Un amministratore del cluster può aggiornare la configurazione del nodo di lavoro privato per utilizzare gli endpoint privati in modo che la comunicazione tra il nodo di lavoro privato e il servizio IBM Cloud® Continuous Delivery non utilizzi l'internet pubblico.

1. Ottenere il nome dell'agente che è installato sul cluster:

kubectl get workeragents -n default

2. Modificare apiUrl per tale agente:

kubectl patch workeragent {WORKER_NAME} --type='merge' -p '{"spec": {"apiUrl":"https://private-worker-service.private.{REGION}.devops.cloud.ibm.com"}}'

Dove {REGION} è l'ubicazione della pipeline della toolchain. Gli endpoint privati sono disponibili nelle seguenti regioni:

* Dallas `us-south`
* Washington `us-east`
* Francoforte `eu-de`
* Londra `eu-gb`

Per utilizzare questa funzione è necessario disporre di un account IBM Cloud abilitato al VRF.

3. Facoltativo. Per tornare all'utilizzo degli endpoint pubblici per l'agente, immettere il comando seguente:

kubectl patch workeragent {WORKER_NAME} -n default --type='merge' -p '{"spec": {"apiUrl":"https://private-worker-service.{REGION}.devops.cloud.ibm.com"}}'

Configurazione del nodo di lavoro privato Delivery Pipeline per utilizzare gli endpoint del link Satellite

Per impostazione predefinita, i nodi di lavoro privati utilizzano endpoint pubblici per la comunicazione. Un amministratore del cluster può aggiornare la configurazione del nodo di lavoro privato per utilizzare gli endpoint di collegamento Satellite in modo che le comunicazioni tra il nodo di lavoro privato e il servizio Continuous Delivery passino attraverso gli endpoint di link Satellite.

1. Crea un endpoint di collegamento Satellite cloud per il servizio IBM Cloud® Continuous Delivery e imposta FQDN e Service indication name per utilizzare il seguente valore:

private-worker-service.{REGION}.devops.cloud.ibm.com

Dove {REGION} è l'ubicazione della pipeline della toolchain.

2. Creare una configmap nello spazio dei nomi del nodo di lavoro privato che associa gli endpoint pubblici agli endpoint del link Satellite:

apiVersion: v1
kind: ConfigMap
metadata:
   name: pipelineworker-url-map
data:
   iam.cloud.ibm.com: <default IAM satellite link endpoint for your satellite location>
   private-worker-service.{REGION}.devops.cloud.ibm.com: <satellite link endpoint created in step 1)>

È possibile aggiungere endpoint alla configmap, ad esempio questi endpoint predefiniti del collegamento Satellite.

Aggiornamento dell'installazione del nodo di lavoro privato Delivery Pipeline

Se il nodo di lavoro privato viene segnalato come inattivo, devi aggiornare l'installazione.

Per visualizzare la versione del tuo nodo di lavoro privato, immetti uno dei seguenti comandi:

• IBM Cloud Kubernetes Service: kubectl -n tekton-pipelines describe deploy private-worker-agent | grep Image
• Red Hat® OpenShift® on IBM Cloud®: kubectl -n openshift-operators describe deploy private-worker-agent-controller-manager | grep Image

Per aggiornare la tua installazione del nodo di lavoro privato, completa la seguente procedura:

1. Esegui nuovamente il comando di installazione,
2. Registra il nodo di lavoro privato sul tuo cluster Kubernetes nuovamente.

Puoi riutilizzare il apikey che hai usato per il nodo di lavoro privato esistente.

Per ulteriori informazioni sui lavoratori privati di Delivery Pipeline, vedere Risoluzione dei problemi per i lavoratori privati di Delivery Pipeline e Domande frequenti per i lavoratori privati delle condutture.