Implantar o Jenkins no Modo Mestre/Agente
Arquitetura
Esta arquitetura de referência mostra como implantar o Jenkins no modo controlador/agente usando o plug-in do Jenkins Oracle Cloud Infrastructure Compute. Quando instalado em uma instância do controlador Jenkins, o plug-in permite criar instâncias do agente sob demanda no Oracle Cloud Infrastructure e remover instâncias ou recursos gratuitos automaticamente após o job de build ser concluído.
Esta arquitetura contém uma instância do controlador e duas instâncias do agente como ponto inicial de uma implantação. Você pode ajustar o número de instâncias do agente ou o tamanho da instância do controlador conforme necessário. A instância do controlador Jenkins deve ser instalada com o código de plug-in do Oracle Cloud Infrastructure.
Essa arquitetura usa uma região com um domínio de disponibilidade e uma sub-rede regional. A mesma arquitetura de referência pode ser usada em uma região com vários domínios de disponibilidade. Recomendamos o uso de uma sub-rede regional para sua implantação, independentemente do número de domínios de disponibilidade.
Essa arquitetura também contém um balanceador de carga e um gateway NAT para fornecer acesso seguro à Internet.
O diagrama a seguir ilustra essa arquitetura de referência.
Descrição da ilustração jenkins-oci.png
Como alternativa a essa arquitetura, você pode usar o Oracle Container Engine for Kubernetes (OKE). Embora seja mais simples configurar essa arquitetura do que o OKE, o OKE oferece mais flexibilidade ao dimensionar o número de agentes que você está usando.
A arquitetura tem os seguintes componentes:
- Instância do controlador do Jenkins
Essa instância de Computação virtual atua como o nó controlador. Ele monitora o estado das instâncias do agente (off-line ou on-line) e recebe respostas do resultado da tarefa dos agentes.
- Instâncias do agente do Jenkins
Essas instâncias do serviço Compute virtuais agem como nós de agente. O nó do controlador cria-os conforme necessário e eles executam quaisquer jobs conforme direcionado pelo nó do controlador.
- 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 grandes distâncias podem separá-las (entre países ou mesmo continentes).
- Rede virtual na nuvem (VCN) e sub-redes
Cada instância do serviço Compute é implantada em uma VCN que pode ser segmentada em sub-redes.
- Domínios de disponibilidade
Os domínios de disponibilidade são data centers 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 interna de domínios de disponibilidade. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.
- Domínios com falha
Um domínio de falha é um agrupamento de hardware e infraestrutura dentro de um domínio de disponibilidade. Cada domínio de disponibilidade tem três domínios de falha com energia e hardware independentes. Quando você distribui recursos entre vários domínios de falha, seus aplicativos podem tolerar falhas físicas do servidor, manutenção do sistema e falhas de energia dentro de um domínio de falha.
- Balanceador de carga
O balanceador de carga distribui o tráfego de entrada para o nó do controlador do Jenkins e fornece acesso à internet para os usuários que acessam o nó do controlador. Recomendamos o uso de um balanceador de carga de 100 Mbps porque ele será usado principalmente para estabelecer conexão com o controlador do Jenkins e o fluxo de tráfego de volta para o usuário não será pesado.
- Gateway NAT
Um gateway NAT (Network Address Translation) fornece um serviço NAT. Você não precisa escolher o tamanho do gateway
- Bastion host
O bastion host é uma instância de computação que serve como ponto de entrada seguro e controlado para a topologia de fora da nuvem. O bastion host geralmente é provisionado em uma zona desmilitarizada (DMZ). Ele permite proteger recursos confidenciais colocando-os nas redes privadas que não podem ser acessadas diretamente de fora da nuvem. A topologia tem um único ponto de entrada conhecido que você pode monitorar e auditar regularmente. Portanto, você pode evitar expor os componentes mais confidenciais da topologia sem comprometer o acesso a eles.
- Listas de segurança
Para cada sub-rede, você pode criar regras de segurança que especifiquem a origem, o destino e o tipo de tráfego que devem ser permitidos dentro e fora da sub-rede.
- Tabela de roteamento
As tabelas de roteamento virtual contêm regras para rotear o tráfego de sub-redes para destinos fora de uma VCN, geralmente por meio de gateways.
Recomendações
Seus requisitos podem ser diferentes da arquitetura descrita aqui. Use as recomendações a seguir como ponto de partida.
- Formas de Computação (controlador do Jenkins)
Essa arquitetura usa duas configurações de máquina virtual (VM) principais para o nó do controlador Jenkins. Um nó do controlador é responsável por distribuir tarefas, coletar resultados do nó do agente e monitorar nós do agente para disponibilidade.
- Formas de Computação (agente Jenkins)
Esta arquitetura usa quatro configurações de VM principais para nós do agente do Jenkins. Certifique-se de que a CPU para agentes seja maior que a do nó do controlador.
- Configurações do Compute (host Bastion)
Um Bastion host é usado para acessar qualquer nó na sub-rede privada. Recomendamos o uso da forma VM.Standard.E2.1 ou VM.Standard.E2.2.
- 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.
Selecione os blocos CIDR que não se sobrepõem a nenhuma outra rede (no Oracle Cloud Infrastructure, em seu data center local ou em outro provedor de nuvem) para a qual você pretende configurar conexões privadas.
Depois de criar um VCN, você poderá alterar, adicionar e remover seus blocos CIDR.
Ao projetar as sub-redes, considere o fluxo de tráfego e os requisitos de segurança. Anexe todos os recursos em uma camada ou função específica à mesma sub-rede, que pode servir como um limite de segurança.
Use uma sub-rede regional.
- Listas de segurança
Use listas de segurança para definir regras de entrada e saída que se aplicam à sub-rede inteira.
Essa arquitetura permite ICMP internamente para toda a sub-rede privada.
Considerações
- Desempenho
Para obter o melhor desempenho, certifique-se de que o nó do controlador do Jenkins tenha núcleos e memória suficientes. Dependendo do build ou de outras tarefas executadas por nós do agente, crie nós do agente com núcleos e memória suficientes.
- Disponibilidade
O nó do controlador Jenkins monitora os nós do agente quanto à disponibilidade e gera um novo nó conforme necessário. Em uma região com vários domínios de disponibilidade, você pode criar um modelo de implantação (no controlador do Jenkins) para nós do agente em diferentes domínios de disponibilidade.
- Custos
Dimensione as CPUs nos nós controlador e agente de acordo com a implantação de carga de trabalho esperada. Você pode alterar as formas de nó na Console; portanto, comece com uma contagem de CPU menor (de preferência duas) e escale conforme necessário. Especifique a forma do nó do agente com o modelo de Instância no nó do controlador.
- Monitorização e alertas
Configure o monitoramento e alertas sobre o uso da CPU e da memória para seus nós de controlador e agente de modo que você possa ampliar ou reduzir a configuração da VM conforme necessário.
Implantar
O código Terraform desta arquitetura de referência está disponível no GitHub. Você pode inserir o código no Oracle Cloud Infrastructure Resource Manager com um único clique, criar a pilha e implantá-la. Como alternativa, você pode fazer download do código do GitHub para o seu computador, personalizar o código e implantar a arquitetura usando a CLI do Terraform.
- Implantar usando o Oracle Cloud Infrastructure Resource Manager:
- Clique em
Se ainda não tiver efetuado sign-in, informe as credenciais da tenancy e do usuário.
- Revise e aceite os termos e condições.
- Selecione a região em que deseja implantar a pilha.
- Siga os prompts e instruções na tela para criar a pilha.
- Depois de criar a pilha, clique em Ações do Terraform e selecione Plano.
- Aguarde a conclusão do job e revise 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 Plano novamente.
- Se nenhuma outra alteração for necessária, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
- Clique em
- Implante usando a CLI do Terraform:
- Vá para GitHub.
- Baixe ou clone o código no seu computador local.
- Siga as instruções no README.
Explore Mais
- Estrutura de práticas recomendadas para o Oracle Cloud Infrastructure
- Crie um pipeline contínuo de integração e implantação usando o serviço Oracle DevOps
- Crie um pipeline de CI/CD para implantações na nuvem usando Ações do GitHub e um serviço do Oracle Cloud Infrastructure DevOps
- Configure um pipeline de CI/CD para implantações na nuvem
Log de Alterações
Este log lista apenas as alterações significativas:
| 5 de maio de 2022 | Adicionada a opção de download de versões editáveis (. SVG e . DRAWIO) do diagrama de arquitetura. |
| 10 de novembro de 2020 | Foram adicionadas etapas para implantar a arquitetura usando o Oracle Cloud Infrastructure Resource Manager. |