Requisitos previos

Antes de instalar un trabajador privado, asegúrese de que dispone de una cuenta de IBM Cloud® para crear las claves de autenticación. Necesita la última versión de kubectl instalada en el ordenador local del administrador. Además, para instalar un trabajador privado, debe disponer de un clúster Kubernetes (versión 1.15 o superior) con acceso administrativo.

• Configuraciones del clúster de Kubernetes sugeridas:

  • IBM Cloud Kubernetes Service Versión 1.21 o superior para ejecutar cargas de trabajo de forma aislada en IBM Cloud Public.
  • Red Hat® OpenShift® on IBM Cloud® versión 4.9 o posterior.

• Acceso a la red:

  • Entrada: No necesaria.

  • El acceso a la red saliente utiliza cuando (TCP:443) la región coincide con la ubicación del canal de entrega y es ( au-syd Sídney, Australia), eu-de (Fráncfort, Alemania), eu-gb (Londres, Reino Unido), jp-tok (Tokio, Japón), us-south (Dallas, EE. UU.), us-east (Washington D. C., EE. UU.), br-sao (São Paulo) o ca-tor (Toronto, Canadá). Por ejemplo, para la región de Frankfurt, especifique https://private-worker-service.eu-de.devops.cloud.ibm.com (TCP:443). Para el acceso de red al punto final global para la validación de la clave de API, utilice https://iam.cloud.ibm.com (TCP:443).

• Permisos para extraer imágenes de icr.io. Los trabajadores privados requieren la infraestructura de conductos de tekton y deben poder extraer imágenes de releases de tekton de icr.io para llevar a cabo una instalación de nodo trabajador privado.

  Para extraer imágenes del registro de contenedores icr.io, es posible que tenga que definir un Kubernetes ClusterImagePolicy específico.

Dado que los trabajadores privados no son compatibles con los Pipelines de Red Hat OpenShift, se recomienda no instalarlos en un clúster con pipelines de Red Hat OpenShift.

Instalación de un trabajador privado de Delivery Pipeline

Para instalar un trabajador privado, debe tener acceso de nivel de administrador a un clúster. La instalación del trabajador privado sólo se puede completar a través de la línea de mandatos, ya que no hay ninguna interfaz gráfica de usuario 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"

Registro de un trabajador privado de 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` (Sídney, Australia)
  * `eu-de` (Fráncfort, Alemania)
  * `eu-gb` (Londres, Reino Unido)
  * `jp-tok` (Tokio, Japón)
  * `us-south` (Dallas, EE. UU.)
  * `us-east` (Washington D. C., EE. UU.)
  * `ca-tor` (Toronto, Canadá)
  * `br-sao` (São Paulo, Brasil)

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

  * Frankfurt `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

Configuración del Trabajador privado de Delivery Pipeline para utilizar puntos finales privados

De forma predeterminada, los trabajadores privados utilizan puntos finales públicos para la comunicación. Un administrador de clúster puede actualizar la configuración del trabajador privado para que utilice puntos finales privados para que la comunicación entre el trabajador privado y el servicio de IBM Cloud® Continuous Delivery no utilice la Internet pública.

1. Obtenga el nombre del agente que está instalado en el clúster:

kubectl get workeragents -n default

2. Cambie el apiUrl para dicho agente:

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

Siendo {REGION} la ubicación del conducto de la cadena de herramientas. Los puntos finales privados están disponibles en las regiones siguientes:

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

Debe tener una cuenta de IBM Cloud habilitada para VRF para poder utilizar esta característica.

3. Opcional. Para volver a utilizar puntos finales públicos para el agente, escriba el mandato siguiente:

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

Configuración de Delivery Pipeline Private Worker para utilizar puntos finales de enlace de Satellite

De forma predeterminada, los trabajadores privados utilizan puntos finales públicos para la comunicación. Un administrador de clúster puede actualizar la configuración de trabajador privado para utilizar los puntos finales de enlace de Satellite para que la comunicación entre el trabajador privado y el servicio Continuous Delivery pase por los puntos finales de enlace de Satellite.

1. Cree un punto final de enlace de Satellite de nube para el servicio IBM Cloud® Continuous Delivery y establezca FQDN y Service indication name para utilizar el valor siguiente:

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

Siendo {REGION} la ubicación del conducto de la cadena de herramientas.

2. Cree un configmap en el espacio de nombres de trabajador privado que correlacione los puntos finales públicos con los puntos finales de enlace de 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)>

Puede añadir puntos finales al configmap, como estos puntos finales de enlace predeterminados Satellite.

Actualización de la instalación de Delivery Pipeline Private Worker

Si se informa de que el trabajador privado está inactivo, deberá actualizar la instalación.

Para ver la versión de tu worker privado, escribe uno de los siguientes comandos :

• 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

Para actualizar la instalación de su trabajador privado, siga estos pasos:

1. Ejecute el mandato de instalación nuevamente.
2. Registre el trabajador privado en su clúster de Kubernetes otra vez.

Puede reutilizar el apikey que ha utilizado para el trabajador privado existente.

Para obtener más información sobre Delivery Pipeline Private Workers, consulte Solución de problemas para Delivery Pipeline Private Workers y Preguntas frecuentes para Pipeline Private Workers.