Implementar um app no Kubernetes
Continuous Delivery será descontinuado nas seguintes regiões em 12 de fevereiro de 2027: au-syd, ca-mon, ca-tor, us-east. O Code Risk Analyzer e o DevOps Insights também serão descontinuados em todas as regiões nessa data. No entanto, se uma região não tiver uso ativo desses recursos, os recursos dessa região poderão ser descontinuados mais cedo e deixar de aceitar novas instâncias. Saiba mais
Neste tutorial, você aprenderá a criar uma cadeia de ferramentas aberta, utilizando diferentes estratégias de implementação. Também verá como implementar cadeias de ferramentas no serviço do IBM Cloud® Continuous Delivery e como desenvolver e implementar um aplicativo da web simples (aplicativo) utilizando cadeias de ferramentas.
Este tutorial é baseado em navegador. Você também pode criar uma cadeia de ferramentas aberta semelhante no Terraform, conforme mostrado no exemplo do IBM Cloud provedor Terraform ibm-cd-toolchain-simple-helm.
Neste tutorial, são utilizadas estratégias de implementação cujo destino de implementação é o Kubernetes. A cadeia de ferramentas utilizada neste tutorial implementa práticas padrão do DevOps, como varredura de código, testes de aceitação, repositórios Git, além de recursos de integração contínua e entrega contínua. Depois de criar um cluster Kubernetes e uma cadeia de ferramentas, altere o código do aplicativo e envie a mudança por push para o repositório Git Repos and Issue Tracking. Ao enviar mudanças por push para o repositório, o pipeline de entrega baseado em Tekton automaticamente constrói e implementa o código.
O Tekton é uma estrutura de código aberto, independente de fornecedor e nativa do Kubernetes que você pode usar para criar, testar e implantar aplicativos. A Tekton fornece um conjunto de componentes compartilhados para a criação de sistemas de integração e entrega contínuas. Como um projeto de código aberto, o Tekton é gerenciado pela Continuous Delivery Foundation. O objetivo é modernizar a entrega contínua, fornecendo especificações do setor para pipelines, fluxos de trabalho e outros blocos de construção. O Tekton permite a construção, o teste e a implementação em vários provedores de nuvem ou sistemas não locais, removendo os detalhes de implementação subjacentes. Os pipelines do Tekton são construídos no Continuous Delivery
O modelo usado neste tutorial funciona com o plano Standard ou Lite do Kubernetes. Com o plano Standard, é possível acessar o aplicativo por meio do nome DNS. No plano Lite, é possível acessar o aplicativo utilizando nodeport.
É possível usar uma estratégia de implementação, de maneira controlada, para atualizar um aplicativo em um ambiente de produção. O uso de uma estratégia de implementação pode oferecer os seguintes benefícios:
- Evitar o tempo de inatividade do aplicativo.
- Permitir o teste de novas funções em ambientes de produção sem que os clientes sejam afetados.
- Limitar o impacto dos problemas de produção a um subconjunto de usuários.
- Em caso de problemas, permite voltar rapidamente para a versão anterior.
Há muitas estratégias de implementação possíveis disponíveis. Em geral, elas dependem da execução de várias instâncias do aplicativo e do gerenciamento das formas de atualização das várias instâncias. É possível configurar previamente as estratégias de implementação comuns a seguir no Continuous Delivery:
- Básico
- Para implementar a nova liberação, interrompe e atualiza simultaneamente todas as instâncias em execução, causando tempo de inatividade. Para a reversão, é necessário implantar a versão anterior novamente, o que causa mais tempo de inatividade. Embora essa estratégia seja simples, rápida e não exija muitos recursos de tempo de execução, ela é a mais arriscada e causa tempo de inatividade. A estratégia de implementação Básica não é recomendada para aplicativos críticos que devem estar altamente disponíveis.
- Atualização contínua
- Semelhante à estratégia Básica, esta estratégia de implementação é simples, rápida e não exige muitos recursos de tempo de execução. No entanto, como cada instância em execução é desativada e atualizada individualmente, evitando tempo de inatividade, o retrocesso requer que a liberação anterior seja implementada novamente. Essa abordagem mais demorada pode causar problemas se a versão atual do aplicativo em produção estiver danificada.
- Implementação azul-verde
- Cria dois ambientes de produção separados e permanentes (azul e verde), sendo que apenas um desses ambientes recebe o tráfego por vez. A liberação atual permanece sempre implementada no ambiente inativo e o tráfego muda para ela após a conclusão da implementação, sem nenhum tempo de inatividade. Como é necessário alternar apenas o tráfego para o ambiente inalterado, o retrocesso não causa tempo de inatividade. Como essa estratégia requer dois ambientes de produção completos, são exigidos mais recursos. No entanto, com essa estratégia é possível utilizar fluxos de Desenvolvedor mais potentes, permitindo testar novas versões de aplicativos no ambiente de produção antes que o tráfego de clientes seja autorizado. A implementação azul-verde também permite um retrocesso mais rápido.
- Liberação Canary
- Implementa uma nova liberação em paralelo com o ambiente de produção original (semelhante à opção azul-verde), sem tempo de inatividade. O volume de tráfego enviado para a instância atualizada e para a instância original é gerenciado, de forma que, durante a implementação, a nova versão fica disponível apenas para um subconjunto controlado de usuários. Aos poucos, há um aumento gradativo do tráfego enviado para a nova versão, até que todo o volume seja enviado para essa versão e, nesse ponto, é possível interromper o ambiente de produção antigo. Para acelerar o retrocesso durante a implementação, é possível rotear todo o tráfego para o ambiente de produção original. Como essa estratégia requer dois ambientes de produção completos somente durante a implementação, o uso geral de recursos é menor do que na implementação azul-verde. A estratégia de implementação da liberação Canary é a mais lenta em relação à mudança de uma liberação anterior para uma liberação atual do software que está sendo implementado. Com as implementações Canary, as organizações podem testar, lado a lado, duas versões de software diferentes no ambiente de produção.
Antes de Iniciar
Antes de iniciar este tutorial, certifique-se de que os recursos a seguir estejam disponíveis:
-
Um IBM Cloud conta. Dependendo de seu tipo de conta da IBM Cloud, o acesso a determinados recursos pode ser limitado. Dependendo dos limites do plano da conta, é possível que alguns recursos exigidos por determinadas estratégias de implementação não estejam disponíveis. Para obter mais informações sobre as contas IBM Cloud, consulte Configuração da sua conta IBM Cloud e Atualização da sua conta.
-
Um cluster Kubernetes e uma chave de API. Para criar esses recursos, é possível utilizar a IU ou a CLI. O cluster pode levar algum tempo para ser provisionado. Durante sua criação, o cluster passa pelos estágios Deploying, Pending e Ready. Para obter mais informações sobre os clusters Kubernetes, consulte Clusters Kubernetes. Embora seja possível usar as implementações Contínua e Azul-verde para os planos Lite, deve-se criar um cluster Kubernetes para os planos Standard.
-
Uma instância do serviço Continuous Delivery.
-
Opcional. Segredos que são armazenados em uma área segura de gerenciamento de segredos e gerenciados centralmente a partir de um único local. Para obter mais informações sobre como fazer a escolha dentre as várias ofertas de gerenciamento de segredos e proteção de dados, consulte Gerenciando segredos do IBM Cloud. Se você ainda não tem uma instância do provedor de área segura de gerenciamento de segredos de sua escolha, crie uma.
-
Opcional. Um namespace, criado utilizando a linha de comandos de registro do contêiner. Para criar um namespace, digite o seguinte comando:
ibmcloud cr namespace-add <my namespace>Como alternativa, é possível criar um namespace na página Container Registry. Para obter mais informações sobre a criação de um namespace neste local, consulte o serviço IBM Cloud Container Registry.
Criar a cadeia de ferramentas
Nesta etapa, você criará uma cadeia de ferramentas para Desenvolver um aplicativo Kubernetes. O cluster Kubernetes de destino é configurado durante a preparação da cadeia de ferramentas, utilizando a chave de API do IBM Cloud e o nome do cluster Kubernetes. Essas opções podem ser alteradas posteriormente, atualizando a configuração do Delivery Pipeline. Qualquer código mesclado na ramificação do repositório Git de destino será automaticamente construído, validado e implementado no cluster Kubernetes.
Para criar uma cadeia de ferramentas para Desenvolver um aplicativo Kubernetes, clique em
Como alternativa, no IBM Cloud console, clique no ícone de menu 
> Automação da plataforma > Cadeias de ferramentas. Na página Cadeias de ferramentas,
clique em Criar uma cadeia de ferramentas. Na página Create a Toolchain (Criar uma cadeia de ferramentas ), clique em Develop a Kubernetes app (Desenvolver um aplicativo ).
Configure o nome e a região da cadeia de ferramentas
Revise as informações padrão para as configurações da cadeia de ferramentas. O nome da cadeia de ferramentas as identifica em IBM Cloud. Certifique-se de que o nome da cadeia de ferramentas seja exclusivo dentro de suas cadeias de ferramentas para a mesma região e grupo de recursos no IBM Cloud.
A região da cadeia de ferramentas pode ser diferente da região de cluster e registro.
Selecione a estratégia de implementação
A cadeia de ferramentas cria um Pipeline de implementação contínua para a implementação da imagem do Docker do aplicativo no IBM Cloud® Kubernetes Service. Selecione a estratégia de implementação que deseja utilizar. Dependendo da estratégia de implementação escolhida (Contínua, Azul-verde ou Canary), pode ser necessário fornecer mais detalhes.
-
Clique na estratégia de implementação que deseja utilizar para a cadeia de ferramentas.
estratégias seguras de implantação de aplicativosEstratégias de implantação -
Clique em Continuar.
Configurar o repositório de código-fonte do aplicativo
Na etapa Aplicativo, por padrão, são exibidas as opções recomendadas para o repositório de código-fonte do aplicativo. Para visualizar todas as opções disponíveis para a integração do Git subjacente, clique em Opções avançadas. Por padrão, a cadeia de ferramentas usa a mostra padrão, que clona o aplicativo de amostra como um repositório Git Repos and Issue Tracking hospedado pela IBM
É possível alterar o nome do repositório do aplicativo. A região do repositório permanece a mesma da cadeia de ferramentas.
O modelo de cadeia de ferramentas fornece um aplicativo NodeJS de amostra. Caso queira vincular um repositório de Aplicativos existente à cadeia de ferramentas, selecione Trazer um aplicativo próprio e especifique a URL do repositório. A cadeia de ferramentas suporta a vinculação apenas a repositórios Git Repos and Issue Tracking existentes.
Por padrão, o modelo do repositório de aplicativo é clonado para a organização de Git Repos and Issue Tracking. Para alterar a organização, ative as Opções avançadas e especifique o proprietário do repositório.
Configurar o repositório de inventário
O repositório de inventário registra os detalhes dos artefatos construídos pelas cadeias de ferramentas de integração contínua. Você pode criar um novo repositório de inventário que seja um clone do modelo de repositório de inventário ou usar um repositório de inventário existente que você compartilha entre cadeias de ferramentas.
Por padrão, o modelo do repositório de inventário é clonado para sua organização de Git Repos and Issue Tracking. Para alterar a organização, selecione Opções avançadas e especifique o proprietário do repositório.
Armazenamento seguro de segredos
Várias ferramentas contidas nessa cadeia de ferramentas requerem segredos, como uma chave de API do IBM Cloud. Você deve armazenar com segurança todos os segredos em uma área segura e fazer referência a eles de acordo com as exigências da cadeia de ferramentas.
Com o IBM Cloud, é possível escolher entre várias ofertas de gerenciamento de segredos e de proteção de dados, que ajudam a proteger seus dados sensíveis, centralizando o segredo. Na etapa Segredos, é possível especificar quais integrações de áreas seguras de segredos devem ser incluídas ou removidas da cadeia de ferramentas. Para obter mais informações sobre a inclusão e remoção de integrações de área segura, incluindo pré-requisitos e sobre o uso de dicas, consulte Gerenciando segredos do IBM Cloud.
Ao usar as sugestões de um modelo, a cadeia de ferramentas é preenchida automaticamente com segredos pré-configurados; não é necessário selecionar manualmente os segredos das integrações de áreas seguras conectadas à cadeia de ferramentas.
Este tutorial usa o IBM Secrets Manager como área segura de segredos.
O IBM Secrets Manager armazena e aplica com segurança os segredos, como chaves de API , assinaturas de imagens ou credenciais HashiCorp que fazem parte da cadeia de ferramentas.
Para obter mais informações sobre como gerenciar seus segredos em IBM Key Protect ou HashiCorp,, consulte Segredos.
Configurar o destino de implementação
Configure o cluster de Kubernetes de destino no qual implementar o aplicativo. Depois que o aplicativo passa pelas fases de construção, teste e varredura, o pipeline implementa a imagem do aplicativo construído no cluster Kubernetes de destino. Agora, a implementação está pronta para o teste de aceitação ou de integração.
Caso a chave de API tenha o acesso necessário, os campos a seguir serão carregados automaticamente, utilizando a chave de API que foi criada, recuperada a partir de uma área segura ou especificada manualmente. Se a chave de API for válida, os valores da região de registro do Contêiner e da região de Cluster do namespace, o nome, o namespace e o grupo de recursos serão preenchidos automaticamente. Todos um desses campos podem ser atualizados para que correspondam à configuração.
-
Nome do aplicativo: o nome do aplicativo. O nome do aplicativo padrão é
hello-containers. -
Chave de API do IBM Cloud: a chave de API utilizada para interação com a ferramenta da CLI do
ibmcloudem várias tarefas. Use um dos métodos a seguir para especificar a chave API que deseja utilizar:- Clique no ícone de chave para importar uma chave de API existente a partir de uma área segura de segredos de sua escolha.
- Copie e cole uma chave de API existente.
- Clique em Novo para criar uma chave de API.
- Gere um novo
api-key, caso não haja uma chave de API existente.
É possível salvar imediatamente a chave de API gerada em uma área segura de segredos existente de sua escolha.
O aplicativo é implementado utilizando a estratégia de implementação especificada. O exemplo a seguir mostra os detalhes para uma implementação Contínua ou Azul-verde.
Se você selecionou a estratégia de implementação Canary, deverá especificar detalhes adicionais do destino da implementação.
-
Tamanho da etapa Canary: define o volume de tráfego a ser redirecionado para a nova liberação da implementação Canary.
-
Intervalo da etapa Canary: define o intervalo de tempo entre cada teste Canary a ser movido para a nova liberação da implementação Canary.
Incluir integrações de ferramentas opcionais
Você pode adicionar a integração da ferramenta IBM Cloud® DevOps Insights à sua cadeia de ferramentas sem nenhuma configuração adicional.
DevOps Insights é incluído na cadeia de ferramentas criada. Não é necessário fornecer nenhuma etapa de configuração para o DevOps Insights. O pipeline de integração contínua usa automaticamente a instância do DevOps Insights que está incluída na cadeia de ferramentas.O DevOps Insights agrega os dados de código, teste, construção e implementação, oferecendo visibilidade quanto à velocidade e qualidade de todas as equipes e liberações.
Clique em Continuar.
Concluir a configuração da cadeia de ferramentas
Na página Resumo, clique em Criar. Várias etapas são executadas automaticamente para configurar sua cadeia de ferramentas.
É possível configurar as integrações individuais da cadeia de ferramentas após a criação do pipeline.
Explorar sua nova cadeia de ferramentas
Depois de criar sua cadeia de ferramentas, todas as integrações de ferramentas que fazem parte dela são exibidas em um diagrama.
Explorar os pipelines
É possível explorar os pipelines para entender o fluxo da cadeia de ferramentas e as diferentes operações que são executadas em cada um deles. A cadeia de ferramentas recém-criada contém três pipelines:
- Pipeline de solicitação pull: executado quando um desenvolvedor mescla as mudanças de sua ramificação de desenvolvimento à ramificação principal ou a qualquer outra ramificação no repositório. O pipeline de solicitação pull executa o Teste de unidade e as Varreduras estáticas no código-fonte do aplicativo.
- Pipeline de integração contínua: executado ao mesclar uma mudança na ramificação principal do repositório de Código-fonte do aplicativo. O pipeline de integração contínua executa o Teste de unidade, a Cobertura de código e Varreduras estáticas no Código-fonte do aplicativo, a verificação do CIS e a verificação da Lista de materiais (BOM). O pipeline de entrega contínua também gera os artefatos de construção binários e os transfere por upload para o IBM Cloud® Kubernetes Service, conforme configurado na cadeia de ferramentas. Além disso, o pipeline de integração contínua gera os metadados dos artefatos de construção, armazenando-os no repositório de Inventário.
- Pipeline de implementação contínua: implementa artefatos de construção no ambiente de implementação. Para conferir se a implementação do aplicativo foi bem-sucedida, o pipeline executa a verificação de funcionamento. Este pipeline deve ser acionado manualmente após a conclusão bem-sucedida do pipeline de integração contínua. Dependendo da estratégia de implementação selecionada, mais acionadores podem ser incluídos no pipeline de integração contínua.
Executar a solicitação pull e os pipelines de integração contínua.
Para iniciar o pipeline de solicitação pull, crie uma solicitação de mesclagem no repositório do aplicativo:
- Na página de visão geral da cadeia de ferramentas, na placa Repositórios, clique no repositório do apps
compliance-app-<timestamp>. - No repositório principal, crie uma ramificação.
- Atualize parte do código no aplicativo de nó de amostra ou no arquivo leia-me e salve essas mudanças.
- Envie a solicitação de mesclagem.
- Na página de visão geral da cadeia de ferramentas, na placa Repositórios, clique no repositório
pr-pipelinepara iniciar o pipeline de solicitação pull. A solicitação de mesclagem correspondente em seu repositório de aplicativo permanecerá no estado pendente até que o pipeline de solicitação pull seja concluído com êxito. - Após a conclusão bem-sucedida, é possível selecionar o pipeline de solicitação pull para explorar as etapas concluídas.
Para iniciar o pipeline de integração contínua, mescle a solicitação de mesclagem de integração contínua no repositório de aplicativos:
- Acesse a solicitação de mesclagem.
- Faça a mesclagem da solicitação para que as mudanças sejam copiadas para a ramificação principal do repositório de aplicativos. O pipeline de integração contínua é acionado automaticamente.
- Na página de visão geral da cadeia de ferramentas de integração contínua, na placa Repositórios, clique no repositório
ci-pipelinepara iniciar o pipeline de integração contínua. - Após a execução bem-sucedida do pipeline de integração contínua, é possível clicar na execução de pipeline para explorar as etapas concluídas.
Prática de deslocamento para a esquerda
No mundo do desenvolvimento seguro de aplicativos, o shift-left é uma prática que previne e encontra problemas como defeitos e vulnerabilidades de segurança e executa verificações de conformidade no início do processo de entrega do software. Essa prática de mover as verificações de qualidade para o início do ciclo de desenvolvimento inclui as seguintes práticas:
- Execução de verificações, no código ou no próprio dispositivo, que não precisam da imagem de construção e podem ser feitas desde os primeiros estágios de implementação. Essas verificações impedem que códigos fora de conformidade sejam mesclados à ramificação principal do repositório. Como as evidências não são coletadas do pipeline de pull requests, seu objetivo é mudar as verificações de conformidade mais cedo no processo de desenvolvimento.
- Todas as verificações são executadas em cada execução de pipeline. Se uma verificação anterior falhar, o pipeline prosseguirá para a verificação seguinte. Para avaliar se há alguma falha na execução, verifique a última etapa do pipeline, na qual há um avaliador de pipeline.
Os resultados de testes de unidade e das varreduras de vulnerabilidade são publicados na instância do DevOps Insights na cadeia de ferramentas. Para revisar esses resultados, clique no ladrilho do DevOps Insights na cadeia de ferramentas e acesse a página do Painel de qualidade.
Para avaliar a existência de possíveis falhas na execução do pipeline, consulte a etapa final do pipeline, que possui um avaliador de pipeline.
Explorar o pipeline de entrega contínua
Os pipelines de solicitação pull e de integração contínua são comuns em todas as estratégias de implementação. O design do pipeline de entrega contínua e as mudanças de implementação são baseados na estratégia de implementação selecionada anteriormente neste tutorial
Este tutorial demonstra o funcionamento da estratégia de implementação contínua, utilizando o aplicativo de amostra.
Explore a implementação Contínua
A opção de implementação contínua usada neste tutorial demonstra como utilizar uma estratégia de implementação com o Serviço do Continuous Delivery para execução da carga de trabalho de produção no Kubernetes. O pipeline de entrega contínua fornece dois acionadores para a implementação contínua. Um pipeline de entrega contínua pode ser iniciado de uma das seguintes maneiras:
- Acionamento manual do pipeline de entrega contínua.
- Acionamento automático do pipeline de entrega contínua após cada ação de
Mergeno repositório de inventário. Após a mesclagem, deve-se acionar manualmente a execução do pipeline de entrega contínua.
Há um acionador do Git Repos and Issue Tracking configurado para acionar um pipeline de entrega contínua automático, mas que, por padrão, fica desativado. É possível habilitar esse acionador após promover uma mudança pela primeira vez.
Como a estratégia de implementação contínua atualiza gradativamente todas as instâncias de produção com a nova versão do software, não há nenhum tempo de inatividade. No entanto, a estratégia de implementação de retrocesso requer a reimplementação da liberação anterior, o que pode demorar algum tempo.
Após a conclusão bem-sucedida do pipeline de entrega contínua, é possível localizar a URL do aplicativo na etapa perform deployment do pipeline de entrega contínua.
Próximas etapas
Para remover o aplicativo de amostra executado no Kubernetes, você deve limpar o cluster Kubernetes:
-
Vá para a página inicial do Kubernetes Cluster.
-
Selecione o cluster no qual o aplicativo de amostra está em execução.
-
Clique em Painel do Kubernetes.
-
No local em que o aplicativo de amostra está sendo executado, selecione namespace.
Kubernetes espaço de nomes -
Exclua as implementações, os serviços e os ingressos relacionados listados no namespace selecionado.
Procurando ajuda?
IBM Cloud o assistente de IA da IBM, que é alimentado pela watsonx, foi projetado para ajudá-lo a aprender sobre como trabalhar na IBM Cloud e criar soluções com o catálogo de produtos e serviços disponíveis. Consulte Obter ajuda do assistente de IA.
Para obter mais opções de suporte, consulte Obtendo ajuda e suporte para o Continuous Delivery.