Prérequis

Avant d'installer un agent privé, assurez-vous de disposer d'un compte IBM Cloud® permettant de créer des clés d'authentification. Vous avez besoin de la dernière version de kubectl installée sur l'ordinateur de bureau de l'administrateur. Vous devez également disposer d'un cluster Kubernetes (version 1.15 ou supérieure) avec un accès administrateur pour installer un worker privé.

• Configurations de cluster Kubernetes suggérées :

  • IBM Cloud Kubernetes Service 1.21, version 1 ou supérieure, pour exécuter des charges de travail de manière isolée sur IBM Cloud Public.
  • Red Hat® OpenShift® on IBM Cloud® version 4.9 ou ultérieure.

• Accès réseau :

  • Entrant: non requis.

  • L'accès au réseau sortant utilise lorsque (TCP:443) la région correspond à l'emplacement du pipeline de livraison et qu'il s'agit soit de ( au-syd Sydney, Australie), eu-de (Francfort, Allemagne), eu-gb (Londres, Royaume-Uni), jp-tok (Tokyo, Japon), us-south (Dallas, États-Unis), us-east (Washington DC, États-Unis), br-sao (São Paulo) ou ca-tor (Toronto, Canada). Par exemple, pour la région de Francfort, spécifiez https://private-worker-service.eu-de.devops.cloud.ibm.com (TCP:443). Pour l'accès réseau au noeud final global pour la validation de la clé d'API, utilisez https://iam.cloud.ibm.com (TCP:443).

• Autorisations d'extraction d'images depuis icr.io. Les agents privés ont besoin de l'infrastructure de tekton-pipelines et doivent pouvoir extraire des images tekton-releases à partir de icr.io pour terminer l'installation de l'agent privé.

  Pour extraire des images du registre de conteneurs icr.io, vous devrez peut-être définir une adresse spécifique Kubernetes ClusterImagePolicy.

Les workers privés n'étant pas compatibles avec les pipelines d' Red Hat OpenShift, il est recommandé de ne pas les installer sur un cluster hébergeant des pipelines d' Red Hat OpenShift.

Installation d'un agent privé Delivery Pipeline

Pour installer un agent privé, vous devez disposer d'un accès de niveau administrateur à un cluster. L'installation de l'agent privé ne peut être effectuée qu'à l'aide de la ligne de commande car aucune interface graphique n'est disponible.

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"

Enregistrement d'un agent privé 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, Australie)
  * `eu-de` (Francfort, Allemagne)
  * `eu-gb` (Londres, Royaume-Uni)
  * `jp-tok` (Tokyo, Japon)
  * `us-south` (Dallas, États-Unis)
  * `us-east` (Washington DC, États-Unis)
  * `ca-tor` (Toronto, CA)
  * `br-sao` (São Paulo, Brésil)

   $ 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"

  *  Francfort `eu-de`
  *  Londres `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

Configuration de Delivery Pipeline Private Worker pour l'utilisation de nœuds finaux privés

Par défaut, les private workers utilisent des nœuds finaux publics pour la communication. Un administrateur de cluster peut mettre à jour la configuration du private worker pour utiliser des nœuds finaux privés afin que la communication entre le private worker et le service IBM Cloud® Continuous Delivery n'utilise pas l'Internet public.

1. Récupérez le nom de l'agent installé sur le cluster :

kubectl get workeragents -n default

2. Modifiez le apiUrl pour cet agent:

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

Où {REGION} est l'emplacement du pipeline de la chaîne d'outils. Des nœuds finaux privés sont disponibles dans les régions suivantes :

*  Dallas `us-south`
* Washington `us-east`
*  Francfort `eu-de`
*  Londres `eu-gb`

Vous devez disposer d'un compte VRF activé IBM Cloud pour utiliser cette fonction.

3. Optionnel. Pour revenir à l'utilisation de nœuds finaux publics pour l'agent, entrez la commande suivante :

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

Configuration de l'agent privé Delivery Pipeline pour utiliser les noeuds finaux de lien Satellite

Par défaut, les private workers utilisent des nœuds finaux publics pour la communication. Un administrateur de cluster peut mettre à jour la configuration de l'agent privé pour utiliser les noeuds finaux de liaison Satellite de sorte que la communication entre l'agent privé et le service Continuous Delivery passe par les noeuds finaux de liaison Satellite.

1. Créez un noeud final de lien Satellite de cloud pour le service IBM Cloud® Continuous Delivery et définissez FQDN et Service indication name pour utiliser la valeur suivante:

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

Où {REGION} est l'emplacement du pipeline de la chaîne d'outils.

2. Créez une mappe de configuration dans l'espace de nom de l'agent privé qui mappe les noeuds finaux publics aux noeuds finaux de lien 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)>

Vous pouvez ajouter des points d'extrémité à la carte de configuration, comme ces points d'extrémité de lien par défaut Satellite.

Mise à jour de l'installation d'un agent privé Delivery Pipeline

Si l'agent privé est signalé comme inactif, vous devez mettre à jour l'installation.

Pour afficher la version de votre worker privé, saisissez l'une des commandes suivantes :

• 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

Pour mettre à jour l'installation de votre agent privé, procédez comme suit :

1. Exécutez à nouveau la commande d'installation.
2. Enregistrez l'agent privé à nouveau sur votre cluster Kubernetes.

Vous pouvez réutiliser le apikey que vous avez utilisé pour l'agent privé existant.

Pour plus d'informations sur les travailleurs privés Delivery Pipeline, voir Dépannage pour les travailleurs privés Delivery Pipeline et FAQ pour les travailleurs privés des pipelines.