Pular para o conteúdo principal

Configurar um pipeline CI/CD para implantações na nuvem

 A entrega rápida de software é essencial para executar seus aplicativos na nuvem de forma eficiente. O Jenkins é um produto popular para automatizar os pipelines de integração contínua (CI) e de entrega e implantação contínuas (CD) para cargas de trabalho no Oracle Cloud.

Arquitetura

Nesta arquitetura de referência, o Jenkins é hospedado no Oracle Cloud Infrastructure para centralizar a automação de build e dimensionar a implantação usando o Oracle Cloud Infrastructure Registry e Container Engine for Kubernetes. O GitHub é usado para gerenciar código-fonte.

O GitHub fornece integração de web hook, para que o Jenkins comece a executar builds e testes automatizados após cada check-in de código. Um aplicativo Web de amostra é implantado como parte do pipeline CI/CD, que os usuários finais podem acessar no cluster do Container Engine for Kubernetes. Para simplificar o processo, o Terraform é usado para automação de infraestrutura.

O diagrama a seguir ilustra essa arquitetura de referência.



Esta arquitetura tem os seguintes componentes:
  • Região

    Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, chamados domínios de disponibilidade. As regiões são independentes de outras regiões e vastas distâncias podem separá-las (entre países ou mesmo continentes).

  • Domínios de disponibilidade

    Os domínios de disponibilidade são centros de dados independentes e independentes em uma região. Os recursos físicos em cada domínio de disponibilidade são isolados dos recursos nos outros domínios de disponibilidade, o que fornece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura, como energia ou resfriamento, ou a rede de domínios de disponibilidade interna. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.

  • Rede virtual na nuvem (VCN) e sub-redes

    O Jenkins é executado em uma instância do serviço Compute de máquina virtual (VM) implantada em um VCN que você pode segmentar em sub-redes. O Jenkins é hospedado na sub-rede pública regional A e o Container Engine for Kubernetes é implantado na sub-rede pública regional B.

  • Instância de computação

    O Jenkins está implantado em uma VM da instância do serviço Compute. O cluster do Container Engine for Kubernetes também executa seus nós em instâncias do serviço Compute.

  • Container Engine for Kubernetes

    O Container Engine for Kubernetes é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos em contêiner na nuvem. Você especifica os recursos do serviço Compute que seus aplicativos exigem e o Container Engine for Kubernetes provisiona-os no Oracle Cloud Infrastructure em uma tenancy existente.

  • Registro

    Registro é um registro gerenciado pela Oracle que permite simplificar o desenvolvimento do workflow de produção. O Registro facilita para você, como desenvolvedor, armazenar, compartilhar e gerenciar artefatos de desenvolvimento, como imagens do Docker.

  • Jenkins

    O Jenkins é um servidor de automação de código-fonte aberto que permite que os desenvolvedores criem, testem e implantem software de forma confiável. O Jenkins suporta o modo mestre/agente, em que a carga de trabalho dos projetos de construção é delegada a vários nós do agente pelo mestre. Uma única instalação do Jenkins pode hospedar vários projetos ou fornecer ambientes diferentes para builds e testes.

Recomendações

Seus requisitos podem ser diferentes da arquitetura descrita aqui. Usar as recomendações a seguir como ponto inicial.

  • Formas do Compute

    Esta arquitetura usa uma imagem do SO Oracle Linux com a forma VM.Standard2.1 para hospedar o servidor Jenkins e OS nós de cluster Container Engine for Kubernetes. Se o aplicativo precisar de mais memória ou núcleos, você poderá escolher uma forma diferente.

  • VCN

    Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar a sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

    Após criar um VCN, você pode alterar, adicionar e remover seus blocos CIDR.

    Esta arquitetura usa um VCN público para hospedar o Container Engine for Kubernetes. Você também pode usar um VCN privado. Nesse caso, use um gateway NAT para conceder ao cluster acesso pela internet pública.

  • Jenkins

    Esta arquitetura implanta o Jenkins em uma instância do serviço Compute. Um nó mestre do Jenkins é usado para criar o pipeline CI/CD. Se você tiver vários pipelines para criar e executar em paralelo, poderá usar um nó do agente do Jenkins para desenvolver mais pipelines.

  • Container Engine for Kubernetes

    Esta arquitetura implanta o cluster do Container Engine for Kubernetes. OS nós de trabalho são implantados em um SO Oracle Linux do VM.Standard2.1. Essa arquitetura usa três nós de trabalho no cluster, mas você pode criar até 1000 nós em cada cluster.

  • Registro

    Esta arquitetura implanta o Registro como um registro Docker privado para uso interno. As imagens do Docker são enviadas e extraídas do Registro. Você também pode usar o Registro como um registro público do Docker, permitindo que qualquer usuário com acesso à Internet e conhecimento do URL apropriado extraia imagens de repositórios públicos no Oracle Cloud.

Considerações

  • Escalabilidade

    Você pode ampliar seu aplicativo atualizando o número de nós de trabalho no cluster do Container Engine for Kubernetes, dependendo da carga. Você também pode ampliar, reduzindo o número de nós de trabalho no cluster. Ao criar um serviço no cluster, você pode criar um balanceador de carga para distribuir tráfego entre os nós designados a esse serviço. Para o Jenkins, você pode usar o nó mestre do Jenkins para criar mais agentes para vários pipelines.

  • Disponibilidade do aplicativo

    Os domínios de falha fornecem a melhor resiliência dentro de um único domínio de disponibilidade. Você pode implantar instâncias do serviço Compute que executam as mesmas tarefas em vários domínios de disponibilidade. Esse design remove um único ponto de falha introduzindo redundância.

  • Capacidade de gerenciamento

    Essa arquitetura usa um exemplo de aplicativo Web hospedado no GitHub para controle de origem. O registro é usado no pipeline de build para armazenar a imagem de build do Docker para o aplicativo.

  • Segurança

    Use políticas para restringir quem pode acessar os recursos do Oracle Cloud Infrastructure que sua empresa tem e como.

    O Container Engine for Kubernetes é integrado ao Oracle Cloud Infrastructure Identity and Access Management (IAM), que fornece autenticação fácil com a funcionalidade de identidade nativa do Oracle Cloud Infrastructure.

Implantar

O código necessário para implantar essa arquitetura de referência está disponível no GitHub. Você pode extrair o código para o Oracle Cloud Infrastructure Resource Manager com um único clique, criar a pilha e implantá-la. Como alternativa, faça download do código do GitHub para seu computador, personalize-o e implante a arquitetura usando a CLI do Terraform.

  • Implante usando o Oracle Cloud Infrastructure Resource Manager:
    1. Clique em Implantar no Oracle Cloud

      Se você ainda não tiver efetuado sign-in, informe as credenciais da tenancy e do usuário.

    2. Analise e aceite os termos e as condições.
    3. Selecione a região onde você deseja disponibilizar a pilha.
    4. Siga os prompts na tela e as instruções para criar a pilha.
    5. Depois de criar a pilha, clique em Ações do Terraform e selecione Plano.
    6. Aguarda até que o job seja concluído e revisa o plano.

      Para fazer alterações, retorne à página Detalhes da Pilha, clique em Editar Pilha e faça as alterações necessárias. Em seguida, execute a ação do Plano novamente.

    7. Se não forem necessárias mais alterações, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
  • Implante usando a CLI do Terraform:
    1. Vá para o GitHub.
    2. Faça download ou clone o código no computador local.
    3. Siga as instruções em README.md.

Comentários

Postagens mais visitadas deste blog

VISÃO GLOBAL - sobre IDoc O IDoc é um objeto SAP que transporta dados de uma transação comercial de um sistema para outro na forma de mensagem eletrônica.  IDoc é um acrônimo para  I  ntermediate  Doc  ument.  O objetivo de um IDoc é transferir dados ou informações do SAP para outros sistemas e vice-versa.  A transferência do SAP para o sistema não SAP é feita via subsistemas EDI (Electronic Data Interchange), enquanto para a transferência entre dois sistemas SAP, o ALE é usado. O IDoc pode ser acionado no sistema SAP ou no subsistema EDI. Isso depende da direção na qual o IDoc é enviado e é chamado como IDoc de entrada e IDoc de saída de acordo.  No caso de fluxo de saída, o IDoc é acionado no SAP por meio do controle de mensagens do documento, que é então enviado ao subsistema EDI. EDI converte os dados do IDoc em XML ou formato equivalente e, em seguida, envia os dados para o sistema parceiro através da Internet. Para o fluxo de entrad...

Saída de mercadorias (MIGO_GI)

Saída Logística - Administração de Materiais - Administração de Estoques - Movimento mercadoria (MIGO) - Saída de mercadorias (MIGO_GI) - Saída de mercadorias (MB1A) Uma saída de mercadoria (SM) é a retirada de material do estoque, seja para consumo ou expedição para um cliente. Tipo de movimento - 201 – Consumo de mercadoria para centro de custos vindo do depósito - 221 – Consumo de mercadoria para projeto vindo do depósito - 261 – Consumo para ordem vindo do depósito - 281 – Consumo para diagrama de rede vindo do depósito - 541 – Subcontratação: remessa dos componentes de livre utilizável para fornecedor - 551 – Retirada para sucata de livre utilizável As opções da transação MIGO_GI são: Saída e Estorno. Campos a serem preenchidos para Saída de Mercadoria: - Selecionar “Saída de mercadorias” - Entrar com os dados dos itens a serem retirados do depósito: o Material o Quantidade o Centro o Depósito o Centro de Custo (obrigatório dependendo do tipo de saída) Campos...

Veja como solucionar o erro 'Não permite retransmissão' em iPhones, iPads e iPods

Você tentou enviar e-mails do seu UOL Mail por um iPhone, iPad ou iPod, mas recebeu a mensagem  O destinatário foi rejeitado pelo servidor porque ele não permite retransmissão ? Isso indica que existe algum erro na configuração do SMTP. Essa configuração junto com a configuração IMAP são os responsáveis por receber e enviar e-mails usando o gerenciador de contas dos aparelhos da Apple.  Clique aqui e verifique o passo a passo ilustrado para fazer essas configurações .  Se você já configurou seu aparelho, mas o erro persiste, é necessário verificar alguns dados.  Um erro comum, por exemplo, é esquecer de corrigir o campo  Nome do Host  que contém o link SMTP. É necessário colocar a letra "s" após o smtp, ficando:  smtps.uol.com.br . Vá em  Ajuste s, selecione  Mail, Contatos, Calendário . Selecione a conta do UOL que você configurou e clique em  Conta . Verifique se o Servidor de Correio de Saída está com o link  smtps.uol...