Limitaciones para cadenas de herramientas y Delivery Pipeline

La migración de recursos de una región a otra está sujeta a las siguientes limitaciones.

1. Las tuberías clásicas no son compatibles.
2. DevOps Insights no es compatible.
3. Los secretos almacenados directamente en Toolchains o Delivery Pipeline (propiedades de entorno o propiedades de activador) no se copiarán. Se proporciona un comando export-secrets para exportar secretos a una Secrets Manager sustituyendo los secretos almacenados por referencias a secretos. Se admiten referencias secretas.
4. Los secretos de activación de webhooks de Tekton Pipeline no se copiarán, ya que no se admiten referencias para los secretos de activación de webhooks. Deberá añadir el secreto después de copiar la cadena de herramientas.
5. El historial de ejecución, los registros y los activos de Tekton Pipeline no se copiarán. Puede conservar las canalizaciones originales durante algún tiempo para mantener el historial.
6. GitHub y Git Repos and Issue Tracking las integraciones de herramientas configuradas con autenticación de tipo OAuth se convertirán automáticamente para utilizar la identidad OAuth del usuario que realiza la copia (el propietario de la clave API) en lugar del usuario original. Esto es para simplificar la operación de copia. Puede volver a configurar las integraciones de herramientas después de copiarlas para utilizar un usuario diferente.
7. Git Repos and Issue Tracking las integraciones de herramientas que utilizan Personal Access Tokens (PAT) para la autenticación se convertirán automáticamente para utilizar OAuth. Puede volver a configurar las integraciones de herramientas después de copiarlas para volver a utilizar un PAT.

Limitaciones de Git Repos and Issue Tracking

Las siguientes limitaciones solo se aplican si está migrando Git Repos and Issue Tracking proyectos.

1. No se admiten proyectos personales. Si ha creado un proyecto en espacio de nombres personales, puede elegir entre traslade su proyecto personal a un grupo o convierta su espacio de nombres personal en un grupo, y luego actualizar las referencias en la cadena de herramientas con la nueva URL. Se recomienda almacenar los proyectos en grupos, ya que permiten tener varios administradores y una mejor continuidad del proyecto a lo largo del tiempo.
2. Los proyectos se copian utilizando la función de transferencia directa de GitLab, que está sujeta a ciertas limitaciones.
3. Copiar proyectos grandes, o proyectos con archivos grandes o muchos recursos, puede llevar tiempo.
4. Dado que cada región de Git Repos and Issue Tracking es independiente, es posible que los usuarios de sus proyectos aún no existan en la región de destino. El copy-project-group comando garantizará que los usuarios existan en la nueva región, sin embargo, puede haber conflictos de nombres de usuario con otros usuarios en la región de destino. En caso de conflicto de nombres de usuario, el nombre de usuario en la región de destino puede modificarse ligeramente añadiendo un sufijo.

Notas importantes

Debe revisar las siguientes notas importantes antes de comenzar la migración.

Consideraciones sobre la facturación

Durante la migración, deberá crear una nueva instancia en la región de destino y un grupo de recursos para habilitar sus cadenas de herramientas, canalizaciones y proyectos en la región de destino Continuous Delivery instancia en la región de destino y un grupo de recursos para habilitar sus cadenas de herramientas, canalizaciones y proyectos en la región de destino. También es posible que desee mantener los recursos originales en la región de origen disponibles para su uso hasta que haya realizado la transición a la nueva región. Si utiliza el servicio Continuous Delivery con el plan Profesional, tenga en cuenta que se le cobrará por ambas regiones en función del número de usuarios autorizados configurados en cada instancia. Si le preocupan los costes, puede cambiar el plan en la instancia Continuous Delivery de la región de origen a Lite una vez que haya realizado la transición a la nueva región. Los recursos serán de sólo lectura si ha superado los límites del plan Lite. Sin embargo, puedes volver al plan Professional en cualquier momento si deseas volver a utilizarlo. Más información sobre facturación y planes en Continuous Delivery.

Ejecuciones duplicadas de Pipeline

Durante la migración, puede crear nuevas canalizaciones en la región de destino. Si esos pipelines tienen activadores temporizados configurados para ejecutarse automáticamente en un horario, o Git activadores configurados para ejecutarse automáticamente en Git eventos como PRs o commits, esos eventos podrían desencadenar ejecuciones duplicadas del pipeline (uno en el pipeline original y otro en el nuevo pipeline). Para evitar posibles interrupciones, los desencadenantes de este tipo estarán desactivados de forma predeterminada en las canalizaciones copiadas. Se recomienda gestionar estos desencadenantes de manera que solo haya un conjunto habilitado a la vez. Una vez que se sienta cómodo con la transición a la nueva canalización, puede habilitar los desencadenadores en ella y deshabilitar los desencadenadores en la canalización original.

Hipótesis codificadas

Después de la migración, sus repositorios Git Repos and Issue Tracking (si procede) tendrán un URL diferente, y sus cadenas de herramientas y pipelines tendrán IDs y URLs diferentes. Puede haber algunas suposiciones sobre el URL /ID o la ubicación de sus recursos en sus definiciones de Tekton, scripts, propiedades de entorno u otras automatizaciones. Es su responsabilidad actualizarlos tras la migración.

macOS

Ejecute los siguientes comandos para instalar las dependencias en macOS.

brew install node
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Otras plataformas

• Node.js instrucciones de instalación
• Instrucciones de instalación de Terraform

CRN

IBM Cloud Los recursos se identifican de forma única mediante un nombre de recurso en la nube(CRN). Necesitarás el CRN de la cadena de herramientas que deseas copiar. Hay varias formas de obtener el CRN de una cadena de herramientas:

1. Busque la cadena de herramientas en la página Automatización de la plataforma > Cadenas de herramientas, abra la cadena de herramientas y haga clic en Detalles para ver los detalles de la cadena de herramientas, donde se muestra el CRN.
2. Localice la cadena de herramientas en la página Lista de recursos, haga clic en la fila de la cadena de herramientas para expandir el panel de detalles, que muestra el CRN.
3. Con la CLI de ibmcloud, puede enumerar las cadenas de herramientas y sus CRN mediante

   ibmcloud resource service-instances --service-name toolchain --long
   

4. Uso de la API de la cadena de herramientas.

Comprobación de los secretos almacenados de la cadena de herramientas y la tubería

Las cadenas de herramientas y los pipelines de Tekton pueden contener secretos, que son valores sensibles como claves API o contraseñas, en los siguientes lugares:

• Propiedades de integración de herramientas, por ejemplo, la propiedad Service ID API Key de la integración de herramientas Delivery Pipeline Private Worker
• Propiedades del entorno del oleoducto Tekton
• Propiedades de activación del oleoducto Tekton

Hay dos formas de configurar los secretos:

1. Almacenados directamente en la cadena de herramientas o en la canalización
2. Referenciar secretos almacenados en un servicio de almacenamiento de secretos como IBM Cloud Secrets Manager o IBM Cloud Key Protect.

Al copiar una cadena de herramientas se incluirán automáticamente las referencias secretas, que permanecerán intactas en la nueva cadena de herramientas. Sin embargo, para minimizar el riesgo de filtración de datos sensibles, los secretos almacenados directamente en cadenas de herramientas o pipeline no se incluirán en la copia de la cadena de herramientas. Puede utilizar el comando export-secrets descrito en la siguiente sección o volver a introducir manualmente los secretos en la cadena de herramientas o canalización copiada tras la copia. Tenga en cuenta, sin embargo, que si no exporta los secretos, es posible que algunas integraciones de herramientas no se aprovisionen correctamente al copiar la cadena de herramientas si les faltan los valores secretos requeridos, y es posible que tengan que volver a crearse manualmente después de ejecutar el comando.

En primer lugar, compruebe si su cadena de herramientas o sus pipelines Tekton contienen secretos almacenados que no sean referencias al ejecutarlos:

npx @ibm-cloud/cd-tools export-secrets -c ${CRN} --check

Exportación de secretos almacenados de la cadena de herramientas y la tubería a Secrets Manager

Si su cadena de herramientas o pipelines no contienen secretos almacenados, puede omitir este paso y continuar con la copia de la cadena de herramientas. La exportación de secretos a Secrets Manager creará secretos en la instancia Secrets Manager y también modificará su cadena de herramientas original para convertir los secretos existentes para hacer referencia a los secretos recién creados en Secrets Manager. Esto permitirá copiar la cadena de herramientas con las referencias secretas intactas, y es una práctica recomendada para mayor seguridad.

Para evitar la exposición accidental de secretos, debe revisar los permisos de IAM de su instancia para asegurarse de que sólo se concede el acceso previsto a los secretos de lectura Secrets Manager para asegurarse de que sólo se concede el acceso previsto a los secretos de lectura.

Para exportar secretos almacenados en su cadena de herramientas o pipeline a Secrets Manager, siga estos pasos:

1. Si aún no dispone de una Secrets Managercree una. Tenga en cuenta que la instancia debe crearse en la cuenta asociada a la clave de API que vaya a utilizar.
2. Asegúrese de que el propietario de la clave de API que va a utilizar tiene permiso de IAM para crear secretos en la instancia Secrets Manager.
3. Abra la cadena de herramientas y Secrets Manager integración de herramientas, cree una política de autorización cuando se le solicite y, a continuación, cree la integración de herramientas.
4. Ejecuta el comando « export-secrets » para exportar los secretos:

   npx @ibm-cloud/cd-tools export-secrets -c ${CRN}
   

5. Cuando se le solicite, seleccione la instancia Secrets Manager de su cadena de herramientas para almacenar los secretos. Si no ve su instancia en la lista, es posible que esté en una cuenta diferente. Asegúrese de utilizar una clave de API que esté en la misma cuenta que la instancia.
6. Cuando se le solicite, especifique para cada secreto encontrado si desea copiarlo o no, así como el nombre y el grupo en el que almacenarlo, o pulse Intro para aceptar los valores predeterminados.

Puedes ejecutar el comando tantas veces como sea necesario para exportar todos tus secretos.

Copiar cadenas de herramientas

Para copiar una cadena de herramientas, ejecute el comando copy-toolchain@ibm-cloud/cd-tools. Para ver las opciones disponibles, ejecuta:

npx @ibm-cloud/cd-tools copy-toolchain -h
Usage: @ibm-cloud/cd-tools copy-toolchain [options]

Copies a toolchain, including tool integrations and Tekton pipelines, to another region or resource group.

Examples:
  export IBMCLOUD_API_KEY='...'
  npx @ibm-cloud/cd-tools copy-toolchain -c ${TOOLCHAIN_CRN} -r us-south
      Copy a toolchain to the Dallas region with the same name, in the same resource group.
  npx @ibm-cloud/cd-tools copy-toolchain -c ${TOOLCHAIN_CRN} -r eu-de -n new-toolchain-name -g new-resource-group --apikey ${APIKEY}
      Copy a toolchain to the Frankfurt region with the specified name and target resource group, using the given API key

Environment Variables:
  IBMCLOUD_API_KEY                       API key used to authenticate. Must be a user API key, with IAM permission to read and create toolchains and service-to-service authorizations in source and target
region / resource group

Basic options:
  -c, --toolchain-crn <crn>              The CRN of the source toolchain to copy
  -r, --region <region>                  The destination region of the copied toolchain (choices: "br-sao", "eu-de", "eu-gb", "jp-tok", "us-south")
  -a, --apikey <api_key>                 API key used to authenticate. Must be a user API key, with IAM permission to read and create toolchains and service-to-service authorizations in source and target
                                         region / resource group
  -n, --name <name>                      (Optional) The name of the copied toolchain (default: same name as original)
  -g, --resource-group <resource_group>  (Optional) The name or ID of destination resource group of the copied toolchain (default: same resource group as original)
  -t, --tag <tag>                        (Optional) The tag to add to the copied toolchain
  -h, --help                             Display help for command

Advanced options:
  -d, --terraform-dir <path>             (Optional) The target local directory to store the generated Terraform (.tf) files
  -D, --dry-run                          (Optional) Skip running terraform apply; only generate the Terraform (.tf) files
  -f, --force                            (Optional) Force the copy toolchain command to run without user confirmation
  -S, --skip-s2s                         (Optional) Skip creating toolchain-generated service-to-service authorizations
  -T, --skip-disable-triggers            (Optional) Skip disabling Tekton pipeline Git or timed triggers. Note: This may result in duplicate pipeline runs
  -C, --compact                          (Optional) Generate all resources in a single resources.tf file
  -v, --verbose                          (Optional) Increase log output
  -q, --quiet                            (Optional) Suppress non-essential output, only errors and critical warnings are displayed

copy-toolchain funciona traduciendo primero la cadena de herramientas a archivos Terraform (.tf) y aplicando después Terraform para crear una nueva cadena de herramientas en la región de destino. El comando mostrará la salida de Terraform y pedirá confirmación antes de crear la cadena de herramientas. Puede revisar la salida de Terraform antes de crear la nueva copia de la cadena de herramientas.

export IBMCLOUD_API_KEY='<your_api_key>'
npx @ibm-cloud/cd-tools copy-toolchain -c 'crn:v1:bluemix:public:toolchain:au-syd:a/9d5d528aa786af01ce99593a827a05f0:69e8d78b-0d1a-49ed-9a46-3b4c1bb4f24a::' -r jp-tok

npx @ibm-cloud/cd-tools copy-toolchain -c "${CRN}" -r eu-de --apikey '<your_api_key>'

export IBMCLOUD_API_KEY='<your_api_key>'
npx @ibm-cloud/cd-tools copy-toolchain -c "${CRN}" -r us-south -n 'toolchain-dallas'

for i in $(ibmcloud resource service-instances --service-name toolchain --location ca-tor --all-resource-groups -o json | jq -r '.[].crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r us-south --dry-run -f
done

for i in $(ibmcloud resource service-instances --service-name toolchain -g my-resource-group -o json | jq -r '.[].crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r eu-de -q
done

for i in $(ibmcloud resource service-instances --service-name toolchain --all-resource-groups -o json | jq -r '.[] | select(.name | startswith("test-")) | .crn'); do
    npx @ibm-cloud/cd-tools copy-toolchain -c ${i} -r jp-tok
done

$ cd output-1764102115772
$ terraform apply
var.ibmcloud_api_key
  Enter a value: {api_key}
...

Verificar los recursos

Después de copiar sus cadenas de herramientas, pipelines Tekton y proyectos Git Repos and Issue Tracking (si procede) a una nueva región, debe comprobar que se han copiado correctamente y que funcionan correctamente antes de desactivar o eliminar los recursos originales. Tenga en cuenta lo siguiente:

• La tubería Tekton **disparadores temporizados y Git ** no estaba activada por defecto en las tuberías copiadas para evitar la duplicación de tuberías entre la tubería nueva y la original. Una vez que se sienta cómodo, puede activar los activadores en el nuevo canal y desactivar los activadores en el canal original.
• Si tiene algún activador de canalización Tekton de tipo webhook, tendrá que reconfigurar el activador y volver a introducir el secreto. Este secreto no admite referencias secretas y no se copia con la tubería.
• Los usuarios con claves de acceso personales en los proyectos Git Repos and Issue Tracking copiados tendrán que volver a crear nuevas claves, ya que no se copiaron.
• Las integraciones de herramientas para repos de Git Repos and Issue Tracking se habrán convertido para utilizar la identidad de OAuth del usuario que realizó la copia. Si desea utilizar una identidad diferente, inicie sesión con ese usuario y vuelva a guardar las integraciones de herramientas, o cambie al uso de Tokens de acceso personal.
• Puede haber suposiciones en sus definiciones de Tekton, scripts, propiedades de entorno u otras automatizaciones sobre el ID, URL o la ubicación de sus recursos. Se recomienda revisarlas para asegurarse de que se utilizan los nuevos ID, URL y ubicaciones.

Desactivar recursos originales

Una vez que haya comprobado que los recursos copiados funcionan correctamente, puede desactivar los recursos originales para evitar conflictos o confusiones.

• Para los pipelines Tekton, puede desactivar sus disparadores para evitar ejecuciones no deseadas del pipeline y para señalar a otros usuarios que estos disparadores ya no deben ser utilizados.
• Para Continuous Delivery instancias de servicio, si estaba utilizando el plan Profesional, puede cambiar al plan Lite para evitar más cargos por los recursos originales. Esto puede provocar que tus recursos pasen a ser de sólo lectura si has superado los límites del plan Lite, pero puedes volver a cambiar a Professional en cualquier momento si necesitas utilizarlos de nuevo.
• Para Git Repos y proyectos de seguimiento de incidencias (si procede), puede archivar sus proyectos originales para que sean de sólo lectura y evitar que los usuarios realicen más cambios, y opcionalmente actualizar la descripción del proyecto o readme para indicar dónde se encuentra el nuevo proyecto.

Aunque no tenga intención de conservar los recursos originales, es posible que quiera guardarlos durante algún tiempo como copia de seguridad por si descubre problemas más adelante. Cuando te sientas cómodo, puedes eliminar los recursos originales.