Jenkins no Kubernetes Engine

Neste tópico, você aprende usar as práticas recomendadas para usar o Jenkins com o Google Kubernetes Engine. Para implementar essa solução, consulte como configurar o Jenkins no Kubernetes Engine.

Com o Jenkins, um servidor de automação de código aberto, é possível orquestrar os pipelines de criação, teste e implantação de maneira flexível. O Kubernetes Engine é uma versão hospedada do Kubernetes, um poderoso gerenciador de cluster e de sistema de orquestração de contêineres.

Quando é preciso configurar um canal de entrega contínua (CD, na sigla em inglês), a implantação do Jenkins no Kubernetes Engine oferece benefícios importantes em relação a uma implantação padrão baseada em VM:

  • Quando o processo de compilação usa contêineres, um host virtual pode executar jobs em diferentes sistemas operacionais.

  • O Kubernetes Engine oferece executores temporários, permitindo que cada compilação seja executada em um ambiente limpo, idêntico às compilações anteriores.

    • Como esses executores são temporários, o cluster do Kubernetes Engine só é utilizado quando as compilações estão em execução, disponibilizando recursos para outras tarefas de cluster, como jobs de processamento em lote.

    • Os executores de compilação são iniciados em alguns segundos.

  • O Kubernetes Engine usa o Balanceador de carga global do Google para rotear o tráfego da Web para sua instância. O balanceador de carga processa a terminação SSL e fornece um endereço IP global que encaminha os usuários para o front-end da Web em um dos caminhos mais rápidos do ponto de presença mais próximo dos usuários por meio da rede backbone do Google.

Para mais detalhes sobre o Jenkins no Kubernetes Engine, assista ao Next 2018 no YouTube:

Como implantar o mestre do Jenkins com o Helm

Use o Helm para implantar o Jenkins no repositório Gráficos (conteúdo dos links em inglês). O Helm é um gerenciador de pacotes que pode ser usado para configurar e implantar aplicativos do Kubernetes.

Para orientações sobre como configurar o Jenkins para o Kubernetes Engine, consulte Como configurar Jenkins para Kubernetes Engine.

A imagem a seguir descreve a arquitetura da implantação do Jenkins em um cluster Kubernetes de vários nós.

Arquitetura do Jenkins e Kubernetes

Implante o Jenkins Master em um namespace no cluster do Kubernetes. Os namespaces permitem criar cotas para a implantação do Jenkins, bem como separar logicamente o Jenkins de outras implantações dentro do cluster.

Criar os serviços Jenkins

O Jenkins fornece dois serviços que o cluster precisa acessar. Implante esses serviços separadamente para serem gerenciados e nomeados individualmente.

  • Um serviço NodePort exposto externamente na porta 8080 que permite que pods e usuários externos acessem a interface do usuário do Jenkins. Esse tipo de serviço pode ser carregado por um balanceador de carga HTTP.

  • Um serviço ClusterIP particular interno na porta 50000 que os executores do Jenkins usam para se comunicar com o Jenkins Master dentro do cluster.

As seções a seguir mostram as definições de serviço de exemplo.

---
  kind: Service
  apiVersion: v1
  metadata:
    name: jenkins-ui
    namespace: jenkins
  spec:
    type: NodePort
    selector:
      app: master
    ports:
      - protocol: TCP
        port: 8080
        targetPort: 8080
        name: ui
---
  kind: Service
  apiVersion: v1
  metadata:
    name: jenkins-discovery
    namespace: jenkins
  spec:
    selector:
      app: master
    ports:
      - protocol: TCP
        port: 50000
        targetPort: 50000
        name: slaves

Criar a implantação do Jenkins

Implante o mestre do Jenkins como uma implantação com uma contagem de réplicas de 1 (conteúdo dos links em inglês). Isso garante que haja um único Jenkins Master em execução no cluster em todos os momentos. Se os dados do pod do Jenkins Master ou o nó em execução forem encerrados, o Kubernetes reiniciará o pod em outro lugar do cluster.

É importante definir solicitações e limites como parte da implantação do Helm para que o contêiner tenha uma certa quantidade de recursos de CPU e memória dentro do cluster antes de ser programado. Caso contrário, o mestre pode deixar de funcionar por privação da CPU ou memória.

O volume inicial do Jenkins armazena arquivos de configuração XML e arquivos JAR de plug-in que compõem a configuração. Esses dados são armazenados em um disco permanente gerenciado pelo cluster do GKE e manterão os dados nas reinicializações do Jenkins. Para alterar o tamanho do disco permanente, edite o valor Persistence.Size ao instalar o Jenkins com Helm.

Conectar ao Jenkins

Uma vez que o pod do Jenkins foi criado, é possível criar um balanceador de carga de endpoint para se conectar a ele de fora do Cloud Platform. Considere as seguintes práticas recomendadas.

  • Use um recurso de entrada do Kubernetes para um balanceador de carga L7 fácil de configurar com terminação SSL.

  • Forneça certificados SSL ao balanceador de carga usando os segredos do Kubernetes. Use tls.cert e tls.key e faça referência a esses valores na configuração de recursos de entrada.

Configurar o Jenkins

Proteger o Jenkins

Depois de se conectar ao Jenkins pela primeira vez, é importante torná-lo seguro imediatamente. Siga o tutorial de configuração de segurança padrão do Jenkins para um procedimento simples que utiliza um banco de dados interno de usuários. Essa configuração não requer mais infraestrutura e oferece a capacidade de bloquear usuários anônimos.

Instalar plug-ins

Instale os seguintes plug-ins para aprimorar as interações entre o Jenkins e o Kubernetes Engine.

  • Com o plug-in do Kubernetes, é possível usar contas do serviço Kubernetes para autenticação e criação de configurações do executor rotuladas com diferentes imagens de base. O plug-in cria um pod quando um executor é necessário e o destrói quando um job termina.

  • O plug-in Google Authenticated Source permite usar as credenciais da conta de serviço ao acessar os serviços do Cloud Platform, como o Cloud Source Repositories.

Para adicionar mais plug-ins usando o gráfico Helm, edite a lista de plug-ins no arquivo de valores que você transmite para os comandos de instalação ou upgrade do Helm.

Personalizar a imagem do agente do Docker do Jenkins

Ao criar um modelo de pod, forneça uma imagem do Docker atual ou criar uma imagem personalizada que tenha instalada a maioria das dependências de tempo de compilação. Usar uma imagem personalizada pode diminuir o tempo total de compilação e criar ambientes de compilação mais consistentes.

A imagem do Docker personalizada instala e configura o agente escravo do Jenkins JNLP. O agente JNLP é um software que se comunica com o mestre do Jenkins para coordenar a execução dos jobs do Jenkins e informar o status do job.

Uma opção é adicionar FROM jenkins/jnlp-slave à configuração de imagem. Por exemplo, se o processo de compilação do aplicativo depender do ambiente de execução do Go, será possível criar o seguinte Dockerfile para ampliar a imagem existente com suas próprias dependências e criar artefatos.

FROM jenkins/jnlp-slave
RUN apt-get update && apt-get install -y golang

Em seguida, crie e faça o upload da imagem para o repositório do Container Registry do projeto executando os seguintes comandos.

docker build -t gcr.io/[PROJECT]/my-jenkins-image .
gcloud docker -- push gcr.io/[PROJECT]/my-jenkins-image

Ao criar um modelo de pod, configure o campo Imagem do Docker para a string a seguir, em que [PROJECT] é substituído pelo nome do projeto, e [IMAGE_NAME] pelo nome da imagem.

gcr.io/[PROJECT]/[IMAGE_NAME]

O exemplo acima garante que o ambiente de execução da linguagem do Go seja pré-instalado quando o job do Jenkins for iniciado.

Criar imagens do Docker no Jenkins

O Cloud Build pode ser usado nos seus jobs do Jenkins para criar imagens do Docker sem precisar hospedar seu próprio daemon do Docker. Seu job do Jenkins precisa ter credenciais de conta de serviço disponíveis que tenham o papel cloudbuild.builds.editor.

Para um exemplo de arquivo Jenkins Pipeline, veja este repositório GitHub.

Kaniko é outra opção para usuários que buscam construir contêineres dentro de clusters. Kaniko não exige que um daemon do Docker esteja presente para criar e enviar imagens para um registro remoto.

Para um exemplo de como usar Kaniko no Jenkins, veja este repositório do GitHub.

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…