He creado una cadena de herramientas y el servicio Delivery Pipeline no se inicia. ¿Por qué no se completa la inicialización del conducto?

Es posible que necesite configurar y guardar la integración de herramientas de GitHub de nuevo.

La integración de herramientas de GitHub en su cadena de herramientas podría estar mal configurada, lo que impide que la inicialización del conducto se complete.

Se ha producido un problema que hace fallar la integración de herramientas de GitHub.

Vuelva a configurar y guardar la integración de herramientas:

1. En la consola IBM Cloud, haga clic en el icono Menú > Automatización de la plataforma > Cadenas de herramientas. En la página Cadenas de herramientas, pulse la cadena de herramientas que ha creado para abrir la página Visión general. Como alternativa, en la página Detalles de la app, pulse el nombre de la cadena de herramientas.
2. En la página Visión general de la cadena de herramientas, en la tarjeta Repositorios, localice la integración de la herramienta GitHub.
3. Pulse el menú para acceder a las opciones de configuración, actualice los valores y pulse Guardar integración.
4. En la tarjeta Interconexiones de entrega, pulse la integración de herramientas de Delivery Pipeline para ver la configuración de la interconexión.

¿Por qué no se crea el conducto correctamente cuando creo una cadena de herramientas a partir de la plantilla que estoy escribiendo?

Es posible que el conducto no tenga recursos, como trabajos y etapas, debido a un error en la definición de pipeline.yaml.

Cuando intento crear una cadena de herramientas a partir de una plantilla que estoy escribiendo, recibo el siguiente mensaje de error en la página Conducto:

This pipeline was created, but might be missing jobs, stages, or other resources. You can use this pipeline, or if you prefer, you can delete it and create another pipeline.

Por lo general, este problema se debe a un error en la definición de pipeline.yaml.

Para depurar este error, puede utilizar cualquiera de los métodos siguientes:

• Utilice la interfaz de usuario del conducto para crear un conducto de ejemplo que replique el conducto que está intentando crear con la plantilla. Añada /yaml al URL de conducto para generar un archivo pipeline.yaml similar que se puede utilizar para buscar diferencias obvias. Por ejemplo, https://cloud.ibm.com/devops/pipelines/<your pipeline id>/yaml?env_id=<your region>.

• Utilice el mecanismo de creación de cadena de herramientas de modalidad autónoma. En la página Crear una cadena de herramientas, abra el depurador y evalúe la expresión window.Testflags = {nocreate: 1}. Cuando pulsa Crear una cadena de herramientas en esta modalidad, la cadena de herramientas no se crea. En su lugar, la información que se pasa a la API se devuelve a la consola, donde puede revisarla.

He intentado ejecutar un conducto, ¿por qué recibo un error sobre el acceso al repositorio (repo) Git?

El conducto utiliza una señal de acceso para clonar el repositorio Git. Si esta señal de acceso no es válida, el propietario de la integración de Git no puede acceder al repositorio Git.

Las integraciones de Git soportadas incluyen las integraciones de herramientas de GitHub, GitLab, Bitbucket o Git Repos and Issue Tracking.

Al intentar ejecutar un conducto, aparece el siguiente mensaje de error:

The access token for this git repository is no longer valid. Please reconfigure the git integration to ensure the integration owner has access to this repository.

La señal de acceso que el conducto utiliza para clonar el repositorio Git ya no es válida. Este problema puede ocurrir porque se ha invalidado la señal. La señal de acceso también puede no ser válida si el propietario de la integración de Git ha perdido el acceso al repositorio debido a cambios de permisos.

Vuelva a configurar y guardar la integración de Git:

1. En la consola IBM Cloud, haga clic en el icono Menú > Automatización de la plataforma > Cadenas de herramientas. En la página de Cadena de herramientas, pulse la cadena de herramientas que contiene la integración Git que desea actualizar para abrir su página de Visión general. Como alternativa, en la página Detalles de la app, pulse el nombre de la cadena de herramientas.
2. En la página Visión general de la cadena de herramientas, en la tarjeta Repositorios, localice la integración de la herramienta Git.
3. Pulse el menú para acceder a las opciones de configuración, seleccione la cuenta de Git autorizada para el propietario de integración de Git y pulse Guardar integración.
4. Ejecute el conducto de nuevo.

He intentado desplegar en Kubernetes utilizando Delivery Pipeline, ¿por qué obtengo un error sobre un objeto no válido?

La imagen base del conducto 1.0 incluye kubectl v1.14.2. Es posible que reciba un error si el clúster de Kubernetes al que se conecta ejecuta una versión más reciente de Kubernetes.

Al intentar desplegar en Kubernetes utilizando Delivery Pipeline, recibo el mensaje de error siguiente:

error:SchemaeError(io.k8s.api.core.v1.SecretProjection): invalid object doesn't have additional properties

Por lo general, este problema se produce cuando la versión del mandato kubectl de la imagen base del conducto es incompatible con la versión de Kubernetes que se ejecuta en el clúster.

Para resolver este problema, puede utilizar cualquiera de los métodos siguientes:

• Utilice una versión más reciente de la imagen base del conducto, que incluya la versión más actual publicada de kubectl cuando se cree. Para obtener información sobre cómo especificar la versión de imagen más reciente, consulte Especificación de la versión de la imagen.

• Asegúrese de que el trabajo de conducto ejecuta la versión correcta de kubectl. Por ejemplo, añada las líneas siguientes al principio del trabajo de conducto para ejecutar kubectl v1.14.2:

  curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/linux/amd64/kubectl
  chmod +x ./kubectl
  sudo mv ./kubectl /usr/local/bin/kubectl

Si ejecuta kubectl v1.14.2 desde una imagen base de conducto 1.0, la opción sudo no estará disponible. Sustituya la línea sudo por el mandato siguiente para añadir kubectl a la vía de acceso (path):

   mkdir ~/.bin && export PATH=~/.bin:$PATH && mv ./kubectl ~/.bin/kubectl

Para obtener más información sobre cómo acceder a la versión exacta de kubectl que necesita, consulte Instalar y configurar kubectl.

He intentado ejecutar un conducto, pero ¿por qué obtengo un error 403 de IBM Cloud Container Registry?

El conducto de IBM Cloud® Container Registry envía a y extrae de imágenes del IBM Cloud Container Registry. El plan de servicio IBM Cloud Container Registry determina la cantidad de almacenamiento y tráfico de pulls que puedes utilizar para tus imágenes privadas.

Al intentar ejecutar un conducto, aparece el siguiente mensaje de error:

Failed to pull image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": rpc error: code = Unknown desc = failed to pull and unpack image "us.icr.io/sdl-ns/achilles:a100-p203-6-20190717161046-78fbc8a3a0fbc8571d887e57499642e0326e7035": failed to copy: httpReaderSeeker: failed open: unexpected status code https://us.icr.io/v2/sdl-ns/achilles/blobs/sha256:365b19774a508fd998bc636981cb9869a406786ad811e51937fa6fb089c86005: 403 Forbidden

Es posible que haya superado su límite de cuota de tráfico de extracción, que impide recuperar la imagen de Docker.

Revise sus límites de cuota y uso para almacenar y extraer imágenes. Elimine restricciones relacionadas con el almacenamiento utilizado y cambie de planes de servicio o límites de cuota para permanecer dentro de los límites de cuota dados.

He intentado compilar mi app en un trabajo de conducto único, ¿por qué no lo he logrado?

Se necesitan 4 GB de memoria (no de almacén de archivos) para compilar la app en un trabajo de conducto único.

Cuando intento compilar mi app en un trabajo de conducto único, el trabajo de compilación falla mostrando un error inesperado.

La app requiere más de 4 GB de memoria para compilar en un trabajo de conducto único.

Para compilar la app en un trabajo de conducto único:

1. Cree un trabajador privado de IBM Cloud® Continuous Delivery.
2. Configure el trabajo de compilación para que utilice el trabajador privado.

¿Por qué Delivery Pipeline no se puede comunicar a través de un cortafuegos?

La configuración del cortafuegos impide que Delivery Pipeline se comunique con entornos que están detrás del cortafuegos.

Cuando intento utilizar Delivery Pipeline, no puedo comunicarme a través del cortafuegos.

El cortafuegos debe configurarse de modo que permita que Delivery Pipeline se comunique con entornos que están detrás de un cortafuegos.

Puede actualizar las configuraciones del cortafuegos de modo que permita que Delivery Pipeline acceda a recursos que están detrás del cortafuegos. Utilice la CIS lista de permitidos y los rangos de subredes para su región específica.

¿Por qué he recibido una notificación que indica que se han corregido las referencias de repositorio en mis definiciones o desencadenantes de interconexión?

Ha cambiado, añadido o eliminado integraciones de repositorio de la cadena de herramientas, lo que ha invalidado las referencias a las integraciones almacenadas en las definiciones o los desencadenantes de la interconexión.

Cuando cambio, añado o elimino integraciones de repositorio de la cadena de herramientas, veo iconos de advertencia y errores de validación en la configuración de la interconexión.

En determinados casos, al cambiar, añadir o eliminar integraciones de repositorio desde la cadena de herramientas, se pueden invalidar algunas de las referencias a dichas integraciones almacenadas en las definiciones o los desencadenantes de la interconexión.

Si hay alguna integración de repositorio coincidente en la cadena de herramientas, la interconexión trata de actualizar automáticamente estas referencias para corregir las referencias de integración que ya no son válidas. Se visualiza una notificación en la interfaz de usuario con uno de los mensajes siguientes:

• Repository reference fixed in the following triggers: [list of triggers]
• Repository reference fixed in the following definitions: [list of definitions]

Si ve una de estas notificaciones, pero no se muestra ninguna advertencia ni error en la configuración, no es necesario realizar ninguna otra acción. Si siguen apareciendo advertencias o errores, es posible que tenga que volver a actualizar o crear el desencadenante o la definición.

¿Por qué se agota el tiempo de espera de mi canalización cuando intenta conectarse a puntos finales privados IBM Cloud Object Storage?

Cuando ejecutas una canalización, las solicitudes al IBM Cloud Object Storage que utilizan un punto final privado caducan sin respuesta. Este tiempo de espera puede hacer que falle la canalización.

IBM Cloud Object Storage Los puntos finales privados no son accesibles desde todos los tipos IBM Cloud de clústeres. No se puede acceder a los puntos finales IBM Cloud Object Storage privados desde trabajadores privados que se ejecutan en clústeres dentro de una red privada virtual IBM Cloud® Virtual Private Cloud (VPC).

Reemplace cualquier s3.private.*IBM Cloud Object Storage punto final por s3.direct.* puntos finales. s3.direct.* Los puntos finales son puntos finales directos que se comunican con IBM Cloud Object Storage desde cualquier tipo IBM Cloud de clúster.

¿Por qué falla mi conducto con un error relacionado con las propiedades seguras?

PipelineRuns Falla con un error cuando alguna de las propiedades seguras de la canalización no se resuelve al inicio de la ejecución de la canalización.

Los pipelines que no pueden recuperar un valor secreto de un almacén de secretos o de Secrets Manager, Key Protect, o HashiCorp Vault, fallan con un mensaje de error que indica qué propiedades no se pueden resolver. Las anomalías de resolución se pueden producir incluso si las propiedades no se utilizan directamente en la ejecución desencadenada. Por ejemplo, se pueden producir anomalías de resolución si la vía de acceso al secreto en el almacén ya no es válida, el almacén de secretos es inaccesible o para problemas de autorización.

Si sus canalizaciones contienen propiedades seguras que no se resuelven actualmente, actualice estas propiedades para que hagan referencia a secretos válidos y recuperables que se encuentren en Secrets Manager, Key Protect o HashiCorp Vault.

Asegúrese de que la interconexión especifica sólo aquellas propiedades seguras que son necesarias para la finalización satisfactoria de un PipelineRun desencadenado como propiedades desencadenantes de interconexión, en lugar de como propiedades de entorno de nivel de interconexión. Utilice las propiedades de entorno de nivel de interconexión sólo cuando sea necesario.

¿Por qué mi interconexión notifica un error al captar la definición de interconexión?

Aparece un error en la Delivery Pipeline página relacionado con la obtención de la definición del proceso. Alternativamente, el error aparece al intentar activar un PipelineRun.

Existen varias razones por las que se puede producir una anomalía al captar la definición de una interconexión. Por ejemplo, si la definición está definida en un repositorio de gran tamaño, la solicitud de obtención de la definición puede demorarse debido a un retraso en la clonación del repositorio de gran tamaño antes de construir la definición. Otro ejemplo es cuando una entrada de definición está dirigida a una rama o vía de acceso que ya no existe en el repositorio.

Intente resolver el problema utilizando una de las opciones siguientes:

• Vuelva a cargar la página para iniciar una nueva solicitud para captar la definición. Si esto falla repetidamente, continúe con las opciones siguientes.
• Valide que todas las ramas y vías de acceso a las que se hace referencia en las entradas de definición coincidan con los recursos que existen en el repositorio.
• Reduzca el tamaño del repositorio que contiene la definición de Tekton. Elimine los archivos innecesarios del repositorio y actualice .gitignore para excluir la carga de archivos innecesarios.
• Incluya sólo los archivos mínimos necesarios de la definición de conducto; no seleccione como destino todo el repositorio. Mueva todos los archivos relacionados con la definición Tekton a una subcarpeta de su repositorio y, a continuación, edite la entrada de definición en su Delivery Pipeline configuración para dirigir la ruta a la subcarpeta. Esta opción reduce el tiempo necesario para clonar los archivos de definición del repositorio.
• Para definiciones Tekton de gran tamaño, considere la posibilidad de dividir la definición en varias carpetas o varios repositorios. A continuación, actualice las entradas de definición en su Delivery Pipeline para que apunten a las carpetas o repos necesarios.

El límite calculado para el tamaño de la definición de la interconexión es de 1 MB. Si se genera algún error al guardar o ejecutar la interconexión, es posible que sea necesario reducir el tamaño de la definición de la interconexión o dividirla entre varias interconexiones.

¿Por qué mi conducto no se puede conectar a un clúster Red Hat OpenShift on IBM Cloud ?

Los pipelines que intentan oc login no pueden iniciar sesión en el clúster de destino que ejecuta Red Hat OpenShift on IBM Cloud la versión 4.13 y posteriores.

El problema se debe a un cambio introducido en la versión 4.13 de Red Hat OpenShift on IBM Cloud.

Para solucionar el problema, utilice el siguiente proceso:

ibmcloud login --apikey "${IBMCLOUD_API_KEY}" -r "${REGION}" -g "${RESOURCE_GROUP}"
ibmcloud oc cluster config --cluster "${CLUSTER_NAME}" --endpoint private --admin
kubectl config current-context
oc version
oc get pods -A  # To verify connection

¿Por qué falla mi pipeline al ejecutar un comando de clonación Git?

Los Tekton Pipelines que utilizan la tarea de comando ' git-clone-repo ' pueden fallar y mostrar el siguiente error:

Clone was not successful. Code 128 - Retrying shortly...
fatal: destination path '.' already exists and is not an empty directory.

El problema se debe a un cambio de rendimiento en la infraestructura de los trabajadores del oleoducto de gestión pública.

Para resolver este problema:

• Localice las definiciones tekton en Configuración para su pipeline y encuentre la entrada para ' git ' en Ruta. Haga clic en el enlace del repositorio para abrirlo. Navegue hasta ' git/task-clone-repo.yaml y, dentro de ese archivo, busque el paso ' clone-repo '. Consulte el ejemplo del catálogo Tekton para obtener el código más reciente como referencia.
• Añada rm -rf "lost+found" a la definición antes de la llamada a git clone. Esto garantiza que el directorio para la clonación esté vacío.
• Vuelva a ejecutar la interconexión.

¿Por qué mi pipeline no se inicia en los trabajadores gestionados cuando se ejecuta desde una cuenta de prueba?

Los pipelines clásicos que se ejecutan desde una cuenta de prueba no se inician debido al siguiente error:

This type of account is not entitled to use managed workers. Private workers can be used instead or to gain access managed worker capability the account must be upgraded to a paid plan.

Este comportamiento se debe a una revisión de los permisos de las cuentas de prueba.

Pruebe las opciones siguientes para resolver este problema:

• Ejecute sus canalizaciones utilizando un trabajador privado que se ejecute en su propio clúster.
• Actualice su cuenta de prueba a una cuenta de Pago según uso con un plan Lite.

¿Por qué mi pipeline no se activa para eventos pull request de repositorios bifurcados?

Por defecto, los pipelines no responden a eventos pull request de repositorios bifurcados

Este comportamiento es por diseño para evitar la ejecución inadvertida de tuberías.

Para permitir que las canalizaciones se ejecuten en eventos de repositorios bifurcados, haga lo siguiente:

• Tekton Pipelines: En la ventana de activación Git, activa el conmutador Include pull request events from forks
• Pipelines clásicos: En la pestaña Entrada de la configuración de la etapa, activa el conmutador ' Include pull request events from forks

¿Por qué a veces veo ExceededNodeResources en los eventos Pod de mi pipeline run?

A veces, cuando una tarea tarda más de lo esperado en iniciarse, se pueden ver ExceededNodeResources mensajes con un reason valor de en la vista de eventos del pod de la tarea en la página pipelineRun de detalles.

Esto suele ocurrir si una tarea está intentando utilizar un volumen ya montado en un nodo que está sobrecargado. Esto también puede ocurrir cuando el clúster está sobrecargado y puede tardar en aparecer un nuevo nodo durante un evento de autoescalado del clúster.

Es probable que estos mensajes sean mensajes operativos normales de su Kubernetes clúster. Para este tipo de mensajes no suele ser necesaria la intervención del usuario. Se producen cuando se produce un evento de autoescalado que libera recursos para su uso o cuando los recursos pasan a estar disponibles posteriormente. De este modo, la cadena procede una vez que el módulo está programado. Esencialmente, la canalización espera a que los recursos necesarios estén disponibles a través del autoescalado u otros medios, permitiendo que el pod se despliegue y que la canalización continúe.

¿Por qué me encuentro con errores de red cuando utilizo un Docker o Podman sidecar?

Al ejecutar un canal de Tekton con un Docker sidecar Podman o, observo uno o varios de los siguientes síntomas:

• Tiempos de espera de conexión intermitentes
• Las solicitudes/respuestas grandes fallan, mientras que las pequeñas tienen éxito
• Los servicios funcionan correctamente a nivel local, pero fallan en el clúster
• TLS fallos en el apretón de manos

Hay una incompatibilidad de MTU entre el demonio Docker y la red del host. El daemon DockerPodman interno crea su propia red puente con un MTU predeterminado de 1500, pero es posible que la interfaz de red del pod solo admita 1450 bytes debido a la encapsulación de superposición. Es este desajuste el que provoca los fallos en la red.

Actualice la definición del canal para establecer explícitamente el mtu valor para Docker de la siguiente manera:

• Docker: com.docker.network.driver.mtu: 1400
• Podman: podman network create --opt mtu=1400 o, en algunos casos, establecer --network=host