Limitações para cadeias de ferramentas e Delivery Pipeline

A migração de recursos de uma região para outra está sujeita às seguintes limitações.

1. Os pipelines clássicos não são suportados.
2. DevOps Insights não é compatível.
3. Os segredos armazenados diretamente em Toolchains ou Delivery Pipeline (propriedades do ambiente ou propriedades do acionador) não serão copiados. Um comando export-secrets é fornecido para exportar segredos para uma instância Secrets Manager substituindo os segredos armazenados por referências secretas. Referências secretas são suportadas.
4. Os segredos do gatilho do webhook do pipeline Tekton não serão copiados, pois as referências não são suportadas para segredos do gatilho do webhook. Você precisará adicionar o segredo após copiar o conjunto de ferramentas.
5. O histórico de execução, os registros e os ativos do pipeline do Tekton não serão copiados. Você pode manter os pipelines originais por algum tempo para preservar o histórico.
6. GitHub e as integrações de ferramentas Git Repos and Issue Tracking configuradas com autenticação do tipo OAuth serão automaticamente convertidas para usar a identidade OAuth do usuário que realiza a cópia (o proprietário da chave de API) em vez do usuário original. Isso simplifica a operação de cópia. Você pode reconfigurar as integrações da ferramenta após copiá-las para usar um usuário diferente.
7. Git Repos and Issue Tracking as integrações de ferramentas que usam Personal Access Tokens (PATs) para autenticação serão automaticamente convertidas para usar OAuth. Você pode reconfigurar as integrações da ferramenta após copiar para usar um PAT novamente.

Limitações para Git Repos and Issue Tracking

As seguintes limitações aplicam-se apenas se você estiver migrando Git Repos and Issue Tracking projetos.

1. Projetos pessoais não são aceitos. Se você criou um projeto em um espaço de nome pessoal, poderá mover o projeto pessoal para um grupo ou converter o espaço de nome pessoal em um grupo e, em seguida, atualizar as referências na cadeia de ferramentas com o novo URL. Recomenda-se armazenar projetos em grupos, pois eles permitem múltiplos administradores e proporcionam melhor continuidade de um projeto ao longo do tempo.
2. Os projetos são copiados usando o recurso de transferência direta GitLab, que está sujeito a certas limitações.
3. Copiar projetos grandes, ou projetos com arquivos grandes ou muitos recursos, pode levar tempo.
4. Como cada região do Git Repos and Issue Tracking é independente, os usuários dos seus projetos podem ainda não existir na região de destino. O copy-project-group comando garantirá que os usuários existam na nova região, mas pode haver conflitos de nomes de usuário com outros usuários na região de destino. Em caso de conflito de nomes de usuário, o nome de usuário na região de destino poderá ser ligeiramente alterado com a adição de um sufixo.

Avisos Importantes

Você deve revisar as seguintes notas importantes antes de iniciar a migração.

Considerações sobre faturamento

Durante a migração, você precisará criar uma nova instância Continuous Delivery na região de destino e no grupo de recursos para ativar suas cadeias de ferramentas, pipelines e projetos na região de destino. Você também pode manter os recursos originais na região de origem disponíveis para uso até que tenha feito a transição para a nova região. Se você usar o serviço Continuous Delivery com o plano Professional, saiba que será cobrado pelas duas regiões de acordo com o número de usuários autorizados configurados em cada instância. Se os custos forem uma preocupação, você poderá alterar o plano na instância Continuous Delivery da região de origem para Lite depois de fazer a transição para a nova região. Os recursos serão somente leitura se você tiver excedido os limites do plano Lite. No entanto, você pode voltar ao plano Profissional a qualquer momento, caso deseje utilizá-lo novamente. Saiba mais sobre o faturamento e os planos do Continuous Delivery.

Execuções duplicadas do pipeline

Durante a migração, você pode criar novos pipelines na região de destino. Se esses pipelines tiverem acionadores program ados para serem executados automaticamente em um cronograma ou acionadores Git configurados para serem executados automaticamente em eventos Git, como PRs ou commits, esses eventos poderão acionar execuções duplicadas do pipeline (uma no pipeline original e outra no novo pipeline). Para evitar possíveis interrupções, os pipelines copiados terão esses tipos de gatilhos desativados por padrão. Recomenda-se gerenciar esses gatilhos de forma que apenas um conjunto esteja ativado por vez. Quando estiver confortável com a transição para o novo pipeline, você poderá ativar os gatilhos nele e desativar os gatilhos no pipeline original.

Suposições codificadas

Após a migração, seus repositórios Git Repos and Issue Tracking (se aplicável) terão um URL diferente, e suas cadeias de ferramentas e pipelines terão IDs e URLs diferentes. Pode haver algumas suposições sobre o URL /ID ou o local dos seus recursos nas definições, scripts, propriedades de ambiente ou outras automações da Tekton. É sua responsabilidade atualizá-los após a migração.

macOS

Execute os seguintes comandos para instalar as dependências em macOS.

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

Outras Plataformas

• Node.js instruções de instalação
• Instruções de instalação do Terraform

CRN

IBM Cloud Os recursos são identificados de forma exclusiva por um Nome de Recurso na Nuvem(CRN). Você precisará do CRN do conjunto de ferramentas que deseja copiar. Você pode obter o CRN de uma cadeia de ferramentas de várias maneiras:

1. Localize o conjunto de ferramentas na página Automação da plataforma > Conjuntos de ferramentas, abra o conjunto de ferramentas e clique em Detalhes para ver os detalhes do conjunto de ferramentas, que mostram o CRN.
2. Localize o conjunto de ferramentas na página Lista de recursos, clique na linha do conjunto de ferramentas para expandir o painel de detalhes, que mostra o CRN.
3. Usando o ibmcloud cli, você pode listar cadeias de ferramentas e seus CRNs por meio de

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

4. Usando a API da cadeia de ferramentas.

Verificar se há segredos de cadeia de ferramentas/linha de pipeline armazenados

As cadeias de ferramentas e os pipelines da Tekton podem conter segredos, que são valores confidenciais, como chaves de API ou senhas, nos seguintes locais:

• Propriedades de integração da ferramenta, por exemplo, a propriedade Service ID API Key da integração da ferramenta Delivery Pipeline Private Worker
• Propriedades do ambiente do pipeline da Tekton
• Propriedades de acionamento do pipeline da Tekton

Existem duas maneiras de configurar segredos:

1. Armazenado diretamente na cadeia de ferramentas ou no pipeline
2. Referenciar segredos armazenados em um serviço de armazenamento de segredos, como IBM Cloud Secrets Manager ou IBM Cloud Key Protect.

A cópia de uma cadeia de ferramentas incluirá automaticamente referências secretas e essas referências permanecerão intactas na nova cadeia de ferramentas. No entanto, para minimizar o risco de vazamento de dados confidenciais, os segredos armazenados diretamente nas cadeias de ferramentas ou no pipeline não serão incluídos na cópia da cadeia de ferramentas. Você pode usar o comando export-secrets descrito na próxima seção ou inserir manualmente os segredos novamente na cadeia de ferramentas ou no pipeline copiado após a cópia. Observe, no entanto, que se você não exportar os segredos, algumas integrações de ferramentas podem não ser provisionadas com êxito ao copiar a cadeia de ferramentas se estiverem faltando os valores secretos necessários e podem precisar ser recriadas manualmente após a execução do comando.

Primeiro, verifique se seu conjunto de ferramentas ou seus pipelines Tekton contêm segredos armazenados que não são referências ao serem executados:

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

Exportar segredos armazenados da cadeia de ferramentas/pipeline para Secrets Manager

Se o seu conjunto de ferramentas ou pipelines não contiver segredos armazenados, você poderá pular esta etapa e continuar a copiar o conjunto de ferramentas. A exportação de segredos para Secrets Manager criará segredos na instância Secrets Manager e também modificará sua cadeia de ferramentas original para converter os segredos existentes em referência aos segredos recém-criados em Secrets Manager. Isso permitirá que a cadeia de ferramentas seja copiada com referências secretas intactas e é uma prática recomendada para aumentar a segurança.

Para evitar a exposição acidental de segredos, você deve revisar as permissões de IAM de sua instância Secrets Manager para garantir que somente o acesso pretendido à leitura de segredos seja concedido.

Para exportar segredos armazenados em sua cadeia de ferramentas ou pipeline para Secrets Manager, siga estas etapas:

1. Se você ainda não tiver uma instância Secrets Managercrie uma. Observe que a instância deve ser criada na conta associada à chave de API que você usará.
2. Certifique-se de que o proprietário da chave de API que você usará tenha permissão do IAM para criar segredos na instância Secrets Manager.
3. Abra a cadeia de ferramentas e Secrets Manager integração de ferramentas, crie uma política de autorização quando solicitado e, em seguida, crie a integração de ferramentas.
4. Execute o comando export-secrets para exportar os segredos:

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

5. Quando solicitado, selecione a instância Secrets Manager de sua cadeia de ferramentas para armazenar os segredos. Se você não vir sua instância listada, ela pode estar em uma conta diferente. Certifique-se de usar uma chave de API que esteja na mesma conta que a instância.
6. Quando solicitado, para cada segredo encontrado, especifique se deseja ou não copiar o segredo e o nome e o grupo no qual armazenar o segredo, ou pressione Enter para aceitar os padrões.

Você pode executar o comando quantas vezes forem necessárias para exportar todos os seus segredos.

Copiar cadeias de ferramentas

Para copiar uma cadeia de ferramentas, execute o comando copy-toolchain@ibm-cloud/cd-tools. Para ver as opções disponíveis, execute:

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

O copy-toolchain funciona primeiro traduzindo a cadeia de ferramentas em arquivos Terraform (.tf) e, em seguida, aplicando o Terraform para criar uma nova cadeia de ferramentas na região de destino. O comando exibirá a saída do Terraform e solicitará a confirmação antes de criar a cadeia de ferramentas. Você pode revisar a saída do Terraform antes de criar a nova cópia da cadeia de ferramentas.

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 recursos

Depois de copiar as cadeias de ferramentas, os pipelines do Tekton e os projetos do Git Repos and Issue Tracking (se aplicável) para uma nova região, verifique se eles foram copiados corretamente e se estão funcionando corretamente antes de desativar ou excluir os recursos originais. Observe:

• Os acionadores cronometrados e Git do pipeline Tekton não foram ativados por padrão nos pipelines copiados para evitar execuções duplicadas do pipeline entre o pipeline novo e o original. Quando estiver confortável, você poderá ativar os acionadores no novo pipeline e desativar os acionadores no pipeline original.
• Se você tiver algum acionador de pipeline Tekton do tipo webhook, será necessário reconfigurar o acionador e inserir novamente o segredo. Esse segredo não oferece suporte a referências secretas e não é copiado com o pipeline.
• Os usuários com tokens de acesso pessoal nos projetos Git Repos and Issue Tracking copiados precisarão recriar novos tokens, pois eles não foram copiados.
• As integrações de ferramentas para repositórios Git Repos and Issue Tracking terão sido convertidas para usar a identidade OAuth do usuário que realizou a cópia. Se quiser usar uma identidade diferente, faça login com esse usuário e salve novamente as integrações de ferramentas ou mude para usar tokens de acesso pessoal.
• Pode haver suposições nas definições, nos scripts, nas propriedades do ambiente ou em outras automações do Tekton sobre a ID, URL ou o local dos seus recursos. É recomendável que você as revise para garantir que os novos IDs, URLs e locais sejam usados.

Desativar recursos originais

Depois de verificar se os recursos copiados estão funcionando corretamente, você pode desativar os recursos originais para evitar conflitos ou confusão.

• Nos pipelines Tekton, é possível desativar os acionadores para evitar execuções indesejadas do pipeline e sinalizar para outros usuários que esses acionadores não devem mais ser usados.
• Para Continuous Delivery instâncias de serviço, se você estava usando o plano Professional, pode mudar para o plano Lite para evitar cobranças adicionais pelos recursos originais. Isso pode fazer com que seus recursos se tornem somente leitura se você tiver excedido os limites do plano Lite, mas você pode voltar para o Professional a qualquer momento se precisar usá-los novamente.
• Para Git Repos e projetos de rastreamento de problemas (se aplicável), você pode arquivar seus projetos originais para torná-los somente leitura e impedir que os usuários façam outras alterações e, opcionalmente, atualizar a descrição do projeto ou o leia-me para indicar onde está o novo projeto.

Mesmo que você não pretenda manter os recursos originais, talvez queira mantê-los por algum tempo como backup, caso descubra problemas posteriormente. Quando estiver confortável, você poderá excluir os recursos originais.