Pré-requisitos

Antes de instalar um trabalhador privado, certifique-se de que tenha uma conta do IBM Cloud® para criar chaves de autenticação. É necessário possuir a versão de kubectl mais recente instalada no computador desktop do Administrador. Além disso, é necessário dispor de um cluster do Kubernetes (versão 1.15 ou superior) com acesso administrativo para instalar um worker privado.

• Configurações de cluster Kubernetes sugeridas:

  • IBM Cloud Kubernetes Service versão 1.21 ou superior para executar cargas de trabalho de forma isolada no IBM Cloud Public.
  • Red Hat® OpenShift® on IBM Cloud® versão 4.9 ou posterior.

• Acesso à rede:

  • Entrada: Não obrigatório.

  • O acesso à rede de saída utiliza (TCP:443), em que a região corresponde à localização do pipeline de entrega e pode ser au-syd (Sydney, Austrália), eu-de (Frankfurt, Alemanha), eu-gb (Londres, Reino Unido), jp-tok (Tóquio, Japão), us-south (Dallas, EUA), us-east (Washington, DC, EUA), br-sao (São Paulo) ou ca-tor (Toronto, Canadá). Por exemplo, para a região de Frankfurt, especifique https://private-worker-service.eu-de.devops.cloud.ibm.com (TCP:443). Para acesso à rede ao terminal global para validação da chave de API, use https://iam.cloud.ibm.com (TCP:443).

• Permissões para extrair imagens do icr.io. Os trabalhadores privados requerem a infraestrutura de tekton-pipelines e devem ser capazes de extrair imagens de tekton-releases do icr.io para concluir a instalação do trabalhador privado.

  Para extrair imagens do registro de contêineres icr.io, talvez seja necessário definir um Kubernetes ClusterImagePolicy específico.

Como os trabalhadores privados não são compatíveis com os Pipelines d Red Hat OpenShift, recomenda-se que você não os instale em um cluster com pipelines d Red Hat OpenShift.

Instalando um trabalhador privado do Delivery Pipeline

Para instalar um trabalhador privado, é necessário ter acesso de nível de Administrador a um cluster. A instalação do trabalhador privado pode ser concluída apenas por meio da linha de comando, uma vez que nenhuma interface gráfica do usuário está disponível.

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"

Registrando um trabalhador privado do 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, Austrália)
  * `eu-de` (Frankfurt, Alemanha)
  * `eu-gb` (Londres, Reino Unido)
  * `jp-tok` (Tóquio, Japão)
  * `us-south` (Dallas, EUA)
  * `us-east` (Washington, D.C., EUA)
  * `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

Configurando o Delivery Pipeline Private Worker para usar terminais privados

Por padrão, os trabalhadores privados usam terminais públicos para comunicação. Um administrador de cluster pode atualizar a configuração do trabalhador privado para usar terminais privados para que a comunicação entre o trabalhador privado e o serviço IBM Cloud® Continuous Delivery não use a Internet pública.

1. Obtenha o nome do agente que está instalado no cluster:

kubectl get workeragents -n default

2. Mude o apiUrl para esse agente:

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

Em que {REGION} é o local do pipeline da cadeia de ferramentas. Os terminais privados estão disponíveis nas regiões a seguir:

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

Deve-se ter uma conta IBM Cloud ativada para VRF para usar este recurso.

3. Opcional. Para retornar ao uso de terminais públicos para o agente, digite o comando a seguir:

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

Configurando o Delivery Pipeline Trabalhador Privado para usar os terminais de link Satellite

Por padrão, os trabalhadores privados usam terminais públicos para comunicação. Um administrador de cluster pode atualizar a configuração do trabalhador privado para usar os terminais de link Satellite para que a comunicação entre o trabalhador privado e o serviço Continuous Delivery vá através de terminais de link Satellite.

1. Criar um terminal de link da nuvem Satellite para o serviço IBM Cloud® Continuous Delivery e configurar FQDN e Service indication name para usar o seguinte valor:

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

Em que {REGION} é o local do pipeline da cadeia de ferramentas.

2. Crie um configmap no espaço de nomes do trabalhador privado que mapeia os terminais públicos para os terminais de 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)>

Você pode adicionar endpoints ao configmap, como esses endpoints padrão do link Satellite.

Atualizando a instalação do trabalhador privado do Delivery Pipeline

Caso o trabalhador privado seja relatado como inativo, deve-se atualizar a instalação.

Para verificar a versão do seu worker privado, digite um dos seguintes 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 atualizar a instalação do trabalhador privado, conclua as etapas a seguir:

1. Execute o comando de instalação novamente.
2. Registre o trabalhador privado em seu cluster Kubernetes novamente.

Você pode reutilizar o apikey que você usou para o trabalhador privado existente.

Para obter mais informações sobre Delivery Pipeline Private Workers, consulte Solução de problemas para Delivery Pipeline Private Workers e FAQs para Pipeline Private Workers.