[{"content":"Introdução\rO Jenkins é uma das ferramentas de automação mais populares e poderosas, amplamente utilizada para integrar e implantar projetos de software de forma contínua. Embora seja possível iniciar rapidamente o Jenkins usando um simples comando Docker, essa configuração básica é semelhante a um \u0026ldquo;Hello World\u0026rdquo; em programação: útil para começar, mas insuficiente para ambientes de produção.\nNeste post, vamos além do básico. O objetivo aqui é guiá-lo com algumas técnicas para uma arquitetura robusta e escalável para o Jenkins, utilizando Docker e Docker Compose. Vamos explorar conceitos fundamentais, como o isolamento de máquinas, e configurar um ambiente mais próximo da realidade. Ao final, você terá uma estrutura sólida, pronta para ser adaptada e expandida conforme suas próprias necessidades.\nSe você está pronto para sair do básico e construir um ambiente de CI/CD profissional, siga adiante!\n\u0026ldquo;Ambiente mais próximo da realidade\u0026rdquo; não significa ambiente de produção. Utilize este post como um guia de referência, e não como uma solução pronta.\rPré-Requisitos\rAntes de mergulharmos nos detalhes técnicos, é essencial garantir que alguns pré-requisitos estejam atendidos:\nLinux (No meu caso, uso Windows como SO principal, entáo utilizo um virtualizador como WSL, Virtualbox, VmWare, etc\u0026hellip;) Docker Conceitos principais\rCom os pré-requisitos definidos, podemos agora explorar os conceitos principais que orientarão a configuração do Jenkins.\nIsolamento\rA primeira boa prática de utilização do Jenkins é não realizar tudo em uma mesma máquina. Tanto por uma questão de segurança quanto de escalabilidade, é recomendado o uso de, no mínimo, duas máquinas.\nA primeira máquina é a que chamamos normalmente de controller. Ela é a máquina principal, sendo responsável principalmente pela interface, configurações e controle de execução de jobs.\nAs demais máquinas são chamadas de nodes. Estas máquinas são responsáveis pela execução de todos os jobs.\nConfiguração das máquinas\rTanto o controller quanto os nodes precisam ser configurados dentro de um sistema operacional.\nInstalar os pré-requisitos, criar pastas, e definir permissões de usuário são alguns exemplos. Além disso, vamos aproveitar para realizar, neste momento, algumas configurações do Jenkins que só surtirão efeito na inicialização ou reinicialização.\nUsaremos as imagens do Jenkins e o Docker Compose para esta fase.\nConfigurações do Jenkins\rCom o Jenkins em execução, precisamos realizar as configurações para o ambiente funcionar:\nCredenciais de acesso Configuração da comunicação entre o controller e o node Estas configurações não serão feitas manualmente. Utilizaremos o plugin Configuration as Code para automatizar este processo.\nEstrutura básica\rEntendidos os conceitos que serão aplicados, é hora de começar a definir a estrutura básica do projeto.\nEsta é a estrutura básica. Este modelo será utilizado em posts futuros.\n. └── demo/ ├── casc/ #Configuração do Jenkins as code │ └── *.yaml ├── plugins/ │ └── plugins.txt #Lista de plugins ├── scripts/ │ └── *.groovy #Scripts de inicialização do jenkins ├── ssh #Chave pública e privada ├── docker-compose.yaml ├── Dockerfile ├── start.sh └── stop.sh Dockerfile\rDentro dessa estrutura, o Dockerfile desempenha um papel central. Vamos examiná-lo em detalhes:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 FROM jenkins/jenkins:lts RUN mkdir -p $JENKINS_HOME/.ssh RUN chown -R jenkins:jenkins $JENKINS_HOME/.ssh RUN touch $JENKINS_HOME/.ssh/known_hosts RUN chmod 600 $JENKINS_HOME/.ssh/known_hosts COPY --chown=jenkins:jenkins ./ssh/jenkins_key $JENKINS_HOME/.ssh/jenkins_key RUN chmod 600 $JENKINS_HOME/.ssh/jenkins_key COPY --chown=jenkins:jenkins ./scripts/ /usr/share/jenkins/ref/init.groovy.d/ COPY --chown=jenkins:jenkins ./plugins/plugins.txt /usr/share/jenkins/ref/plugins.txt RUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt RUN mkdir -p $JENKINS_HOME/casc_configs RUN chown -R jenkins:jenkins $JENKINS_HOME/casc_configs COPY --chown=jenkins:jenkins ./casc/* $JENKINS_HOME/casc_configs/ ENV CASC_JENKINS_CONFIG=\u0026#34;$JENKINS_HOME/casc_configs/\u0026#34; ENV JAVA_OPTS=\u0026#34;-Djenkins.install.runSetupWizard=false\u0026#34; Um resumo do conteúdo do Dockerfile:\nlinhas 3 a 8: Criação do diretório .ssh e a cópia da chave privada armazenada na pasta ssh do projeto. linha 10: Cópia dos scripts Groovy armazenada na pasta scripts do projeto. linhas 12 e 13: Cópia da lista de plugins e a instalação dos plugins na imagem. linhas 15 a 17: Criação da pasta do plugin JCasC e cópia dos arquivos de configuração da pasta casc (Configuration as Code) do projeto. linha 20: Define a variável de ambiente CASC_JENKINS_CONFIG para configurar a pasta padrão onde o Jenkins irá recuperar estes arquivos. linha 21: Configuração da variável de ambiente JAVA_OPTS informando que não é necessária a execução do Wizard de instalação. docker-compose.yaml\rDepois de configurar o Dockerfile, precisamos orquestrar os serviços com o docker-compose.yaml:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 version: \u0026#39;3.7\u0026#39; volumes: jenkins_data: name: jenkins_data services: jenkins: container_name: jenkins_master build: . ports: - 8080:8080 - 50000:50000 volumes: - jenkins_data:/var/jenkins_home/ - /var/run/docker.sock:/var/run/docker.sock ssh-agent: container_name: jenkins_agent image: jenkins/ssh-agent environment: - JENKINS_AGENT_SSH_PUBKEY=${JENKINS_AGENT_SSH_PUB} depends_on: - jenkins Não há muito segredo no docker-compose. O serviço jenkins executa a imagem oficial do Jenkins, com as principais portas mapeadas, e o serviço ssh-agent que será o node de execução dos pipelines.\nNa linha 19 configuramos a variável de ambiente JENKINS_AGENT_SSH_PUBKEY para informar a chave pública gerada.\nplugins.txt\rAgora que os serviços estão configurados, vamos definir os plugins essenciais no arquivo plugins.txt:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 cloudbees-folder build-timeout credentials timestamper ws-cleanup pipeline-milestone-step pipeline-input-step pipeline-stage-step pipeline-graph-analysis pipeline-rest-api pipeline-stage-view pipeline-build-step pipeline-model-api pipeline-model-extensions pipeline-stage-tags-metadata pipeline-model-definition ssh-credentials ssh-slaves config-file-provider workflow-aggregator configuration-as-code executors.groovy\rSeguindo as recomendações no início do artigo, é necessário ajustar os executores do Jenkins, o que faremos no script executors.groovy:\n1 2 import jenkins.model.* Jenkins.instance.setNumExecutors(0) // Recommended to not run builds on the built-in node ssh-agent.yaml\rPor fim, precisamos configurar a comunicação segura entre o controller e os nodes, usando o ssh-agent.yaml:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 credentials: system: domainCredentials: - credentials: - basicSSHUserPrivateKey: scope: SYSTEM id: ssh_agent_key username: description: \u0026#34;SSH passphrase with private key file. Private key provided\u0026#34; privateKeySource: directEntry: privateKey: \u0026#34;${readFile:${JENKINS_HOME}/.ssh/jenkins_key}\u0026#34; jenkins: nodes: - permanent: launcher: ssh: credentialsId: \u0026#34;ssh_agent_key\u0026#34; host: \u0026#34;jenkins_agent\u0026#34; port: 22 sshHostKeyVerificationStrategy: \u0026#34;nonVerifyingKeyVerificationStrategy\u0026#34; name: \u0026#34;jenkins_agent\u0026#34; numExecutors: 2 remoteFS: \u0026#34;/tmp\u0026#34; retentionStrategy: \u0026#34;always\u0026#34; Aqui, configuramos o jenkins pelo plugin configuration as code:\nLinhas 1 a 12: Criação de uma credencial do jenkins do tipo SSH Username with private key com a chave privada. Linhas 13 a 25: Criamos a configuração do node Start up\rCom todas as configurações em ordem, é hora de colocar tudo em prática e iniciar o ambiente. Vamos utilizar o script start.sh para automatizar a execução do docker-compose (especialmente útil para execuções repetidas):\n1 2 3 4 5 6 7 8 9 10 #!/bin/sh work_path=$(pwd) echo $work_path sh $work_path/stop.sh ssh-keygen -t rsa -f $work_path/ssh/jenkins_key -N \u0026#34;\u0026#34; -C \u0026#34;jenkins\u0026#34; export JENKINS_AGENT_SSH_PUB=$(cat $work_path/ssh/jenkins_key.pub) echo $JENKINS_AGENT_SSH_PUB docker-compose up --build -d Em resumo, o script start.sh:\nExecuta o script stop.sh para garantir a limpeza de arquivos criados em execuções anteriores. Gera as chaves públicas e privadas Cria a variável de ambiente JENKINS_AGENT_SSH_PUB utilizada no docker-compose.yaml Executa o docker-compose E o script stop.sh:\nDeleta as chaves da pasta ssh Para o serviço Remove os containers Remove os volumes criados Execução\r1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 [+] Building 51.1s (18/18) FINISHED docker:default =\u0026gt; [jenkins internal] load build definition from Dockerfile 0.0s =\u0026gt; =\u0026gt; transferring dockerfile: 855B 0.0s =\u0026gt; [jenkins internal] load .dockerignore 0.0s =\u0026gt; =\u0026gt; transferring context: 2B 0.0s =\u0026gt; [jenkins internal] load metadata for docker.io/jenkins/jenkins:lts 0.0s =\u0026gt; [jenkins internal] load build context 0.0s =\u0026gt; =\u0026gt; transferring context: 4.15kB 0.0s =\u0026gt; [jenkins 1/13] FROM docker.io/jenkins/jenkins:lts 0.0s =\u0026gt; CACHED [jenkins 2/13] RUN mkdir -p /var/jenkins_home/.ssh 0.0s =\u0026gt; CACHED [jenkins 3/13] RUN chown -R jenkins:jenkins /var/jenkins_home/.ssh 0.0s =\u0026gt; CACHED [jenkins 4/13] RUN touch /var/jenkins_home/.ssh/known_hosts 0.0s =\u0026gt; CACHED [jenkins 5/13] RUN chmod 600 /var/jenkins_home/.ssh/known_hosts 0.0s =\u0026gt; [jenkins 6/13] COPY --chown=jenkins:jenkins ./ssh/jenkins_key /var/jenkins_home/.ssh/jenkins_key 0.1s =\u0026gt; [jenkins 7/13] RUN chmod 600 /var/jenkins_home/.ssh/jenkins_key 1.8s =\u0026gt; [jenkins 8/13] COPY --chown=jenkins:jenkins ./scripts/ /usr/share/jenkins/ref/init.groovy.d/ 0.2s =\u0026gt; [jenkins 9/13] COPY --chown=jenkins:jenkins ./plugins/plugins.txt /usr/share/jenkins/ref/plugins.txt 0.1s =\u0026gt; [jenkins 10/13] RUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt 40.7s =\u0026gt; [jenkins 11/13] RUN mkdir -p /var/jenkins_home/casc_configs 1.9s =\u0026gt; [jenkins 12/13] RUN chown -R jenkins:jenkins /var/jenkins_home/casc_configs 2.7s =\u0026gt; [jenkins 13/13] COPY --chown=jenkins:jenkins ./casc/* /var/jenkins_home/casc_configs/ 0.5s =\u0026gt; [jenkins] exporting to image 2.8s =\u0026gt; =\u0026gt; exporting layers 2.8s =\u0026gt; =\u0026gt; writing image sha256:0bde8aac40a647cb9663b5b21d72d25a8eb607719a22bbe0ad9ea67e8e97890d 0.0s =\u0026gt; =\u0026gt; naming to docker.io/library/jenkins-jenkins 0.0s [+] Running 3/3 ✔ Volume \u0026#34;jenkins_data\u0026#34; Created 0.0s ✔ Container jenkins_master Started 0.4s ✔ Container jenkins_agent Started 0.3s Concluões\rO exemplo deste artigo está disponível aqui. Está muito longe de um ambiente produtivo de execução, mas para serve como uma base para meus testes quando preciso de um ambiente local de execução.\nAté a próxima!\nReferências\rhttps://github.com/jenkinsci/docker/blob/master/README.md#install-plugins https://github.com/jenkinsci/docker-ssh-agent?tab=readme-ov-file#running-with-the-ssh-build-agents-plugin https://www.jenkins.io/doc/book/security/controller-isolation/ https://plugins.jenkins.io/configuration-as-code/\nFoto de Chilli Charlie na Unsplash\n","date":"2024-08-15T00:00:00Z","image":"https://www.sitedoricardo.com.br/p/getting-started-with-jenkins-and-docker/chilli-charlie-6Lh4FyFdCxI-unsplash_hu5459c0360c2b0cb7a147d2df0eb350ca_855871_120x120_fill_q75_box_smart1.jpg","permalink":"https://www.sitedoricardo.com.br/pt-br/p/introdu%C3%A7%C3%A3o-com-jenkins-e-docker/","title":"Introdução com Jenkins e Docker"},{"content":"Introdução\rVamos entender os principais tipos de jobs existentes e vamos criar um pipeline básico de build de aplicação.\nSetup Ambiente\rVocê pode utilizar meu repositório com o setup criado até agora com algumas melhorias.\nExecute o comando ./run.sh dentro da pasta 01_jenkins\nCenário\rComo exemplo, vamos usar o Spring Boot Pet Clinic para demonstrar como criar um pipeline que simplesmente irá realizar o checkout do código e compilar.\nTools no Jenkins\rSe você fosse realizar essa atividade no terminal de comando, você faria a seguinte sequência:\n1 2 3 git clone https://github.com/spring-projects/spring-petclinic.git cd spring-petclinic mvn clean package Você precisa do git para checkout da aplicação, o maven para compilar, e como é uma aplicação é em Java, precisa de uma jdk para compilar.\nPara o Jenkins, todos estes itens são tratados como ferramentas. As configurações estão localizadas em Jenkins \u0026gt; Gerenciar Jenkins \u0026gt; Global Tool Configuration.\nUtilizando o Global Tool Configuration do Jenkins proporciona um nível de flexibilidade para a instalação de várias ferramentas, além de padronizá-las entre as máquinas executoras do jenkins.\nOs Tipos de Jobs\rOs existem vários jobs no jenkins uma instalação padrão contém os seguintes jobs:\nFreestyle: Este é o modelo de job mais antigo do jenkins. Ele é o modo \u0026ldquo;low code\u0026rdquo; para criação de jobs. Pipeline: Tipo de job para execuções mais complexas, onde precisa de um nível de flexibilidade maior que o Freestyle. Neste tipo de job, os processos dos jobs são tratados como código, seguindo o princípio Pipeline as Code. Ainda há duas subdivisões no modo de desenvolvimento do Pipeline: temos o Declarative Pipeline e o Scripted Pipeline. Enquanto no primeiro você está limitado a uma estrutura pré-defininda, no segundo você pode utilizar de todas as funcionalidades da linguagem de programação Groovy. Mais detalhes em https://www.jenkins.io/doc/book/pipeline/syntax/#compare Múltiplas Configurações: É um job Freestyle com um mecanismo para executar várias vezes de acordo com parametrizações. Por exemplo: Imagine que você precise fazer um job que irá testar em um ambiente Linux e um ambiente Windows os browsers Firefox e Chrome. Você parametriza no job os ambientes (Linux, Windows), os browsers (Firefox e Chrome) e o Jenkins fará a combinação de todas as possibilidades para executar o job (Linux-Chrome, Linux-Firefox, Windows-Chorme, Windows-Firefox) Folder: Tipo especial de job para organização de Jobs em uma estrutura de Pastas. Github Organization: Realiza um scan no seu repositório a partir de alguns critérios para executar um job padrão. Multibranch Pipeline: Realiza um scan em um repositório e o jenkins gera automaticamente um job para cada branch encontrada. Criando um pipeline\rSelecione Novo Job, digite o nome do job e clique em pipeline e depois em Salvar:\nDentro da seção Pipeline, cole o seguinte código: 1pipeline{ 2 agent any 3 stages { 4 stage(\u0026#39;SCM Ckeckout\u0026#39;){ 5 steps{ 6 checkout([ 7 $class: \u0026#39;GitSCM\u0026#39;, 8 branches: [[name: \u0026#34;*/main\u0026#34;]], 9 doGenerateSubmoduleConfigurations: false, 10 extensions: [], 11 submoduleCfg: [], 12 userRemoteConfigs: [[ 13 url: \u0026#34;https://github.com/spring-projects/spring-petclinic.git\u0026#34; 14 ]] 15 ]) 16 } 17 } 18 stage(\u0026#39;Build\u0026#39;){ 19 steps{ 20\twithMaven( 21 globalMavenSettingsConfig: \u0026#34;mavenDefaultConfig\u0026#34;, 22 jdk: \u0026#39;openjdk9\u0026#39;, 23 maven: \u0026#39;maven3\u0026#39;, 24 mavenLocalRepo: \u0026#34;/usr/share/maven/.m2\u0026#34;, 25 options: [artifactsPublisher(disabled: true)]) { 26\tsh \u0026#34;mvn clean package\u0026#34; 27 } 28 } 29 } 30 } 31}\nAo clicar em Construir agora o job será executado.\nExplicando cada linha, temos:\nA linha 1 define que estamos codificando um pipeline declarativo. Sendo assim, existe uma estrutura básica a ser seguida; A linha 2* define que iremos executar este pipeline em qualquer máquina disponível (agent any). Um agent é qualquer máquina reconhecida pelo jenkins para executar os jobs; A linha 3 define o bloco de stages e na linha 4 já declaramos o primeiro stage chamado \u0026ldquo;SCM Checkout\u0026rdquo;. Em seguida, a linha 5 contém o bloco steps. Somente após seguir esta estrutura podemos realmente informar o que desejamos automatizar; As linhas 6 a 15 definem o comando checkout. Nele contém informações como por exemplo o tipo do repositório, a url do repositório e a branch. Particularmente, prefiro este comando ao invés do git pela quantidade de funcionalidades disponíveis; As linhas 18 e 19 definem um novo bloco de stage chamado \u0026ldquo;Build\u0026rdquo;; As linhas 20 a 25 definem todas as configurações do maven que iremos utilizar: Utilizar os settings chamado mavenDefaultConfig, informando a referencia da ferramenta instalada openjdk9 como a jdk a ser executada e com a versão do maven definida na ferramenta chamada maven3. Aqui ainda informamos aonde está localizado o diretório .m2 do maven e que ao executar o comando, quero ignorar a geração do fingerprint. Finalmente, na linha 26 executamos o maven (mvn clean package) utilizando o comando sh; Usando o Snippet generator\rVocê não precisa saber todos esses comandos de cabeça, uma funcionalidade do jenkins é poder construir esses trechos de código em formato wizard. Para isto, utilizamos o link Pipeline Syntax\nVocê pode selecionar no combo sample step o comando desejado e preencher com as informações necessárias. Ao clicar no botão Generate Pipeline Script ele irá gerar toda a linha de código necessária:\nFinalização\rTentei mostrar todos os \u0026ldquo;caminhos\u0026rdquo; que aprendi ao longo do tempo sobre como aprender a criar pipelines no Jenkins. Como toda a adaptação, a documentação no começo vai parecer confusa e com certeza, algumas partes faltam documentação. Porém, as necessidades principais estão bem estruturadas no site oficial.\nPor enquanto, nosso job só faz o checkout e o build. Nos próximos artigos vamos realizar incrementos para montar uma estrutura automatizada de build completa.\nAbraços\nPhoto by Markus Spiske on Unsplash\n","date":"2020-06-23T02:46:15-03:00","image":"https://www.sitedoricardo.com.br/p/markus-spiske-C0koz3G1I4I-unsplash_hu06f55c9ebd05e613a0389ac4e7442e07_567251_120x120_fill_box_smart1_3.png","permalink":"https://www.sitedoricardo.com.br/pt-br/p/entendendo-os-tipos-de-jobs/","title":"Entendendo os tipos de jobs"},{"content":"Introdução\rNo artigo anterior foi apresentado como criar uma stack básica de desenvolvimento com o Jenkins. Agora vamos avaliar alguns desafios que surgiram e como melhorá-los.\nExlusão de containers\rUsando o comando docker-compose down removemos todos so recursos criados pelo comando docker-compose up e o arquivo docker-compose.yml. Porém, os volumes criados não são automaticamente removidos. Depois de executar muitas vezes os comandos, teremos o seguinte cenário:\nVocê pode remover os volumes individualmente com o comando docker volume rm [id container] ou removendo todos os volumes não utilizados com o comando docker volume prune.\nJenkins - Configuration as Code\rA partir de agora vamos tratar todas as configurações como código. Para isto, precisamos de uma estrutura de diretórios organizadas da seguinte maneira:\n1 2 3 4 5 6 +-- wsl2-docker-devops/ #Pasta principal +-- 01_jenkins/ #Todos os arquivos referente as configurações do jenkins +-- plugins/ #Referencias aos arquivos de configuração de plugins +-- plugins.txt #Arquivo com os nomes dos plugins a serem instalados +-- docker-compose.yml #Configurações da aplicação +-- Dockerfile #Construção da imagem. Vamos alterar o arquivo docker-compose.yml com novas informações:\n1 2 3 4 5 6 7 8 9 10 11 version: \u0026#34;3.4\u0026#34; volumes: jenkins_data: name: jenkins_data services: jenkins: build: . ports: - \u0026#34;8080:8080\u0026#34; volumes: - jenkins_data:/var/jenkins_home:rw E vamos criar o arquivo Dockerfile:\n1 2 3 4 FROM jenkins/jenkins:lts COPY ./plugins/plugins.txt /usr/share/jenkins/ref/plugins.txt RUN /usr/local/bin/install-plugins.sh \u0026lt; /usr/share/jenkins/ref/plugins.txt ENV JAVA_OPTS=\u0026#34;-Djenkins.install.runSetupWizard=false\u0026#34; E um arquivo de texto plugins.txt: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 cloudbees-folder build-timeout credentials timestamper ws-cleanup ant pipeline-milestone-step pipeline-input-step pipeline-stage-step pipeline-graph-analysis pipeline-rest-api pipeline-stage-view pipeline-build-step pipeline-model-api pipeline-model-extensions pipeline-stage-tags-metadata pipeline-model-declarative-agent pipeline-model-definition github-api git github github-branch-source ssh-credentials ssh-slaves build-user-vars-plugin matrix-auth pam-auth ldap email-ext mailer Ao executar o comando docker-compose up \u0026amp; dentro do diretório 01_jenkins, ao acessar a página http://localhost:8080 irá aparecer a tela inicial do jenkins, sem nenhuma configuração manual:\nAtravés de um único comando, você construiu a imagem com os plugins e subiu o jenkins sem nenhuma interação! :wink:\nDetalhe das Configurações\rDocker-compose\rDentro do docker-compose.yaml definimos um Volume com um nome customizado chamado jenkins_data\nvolumes:\rjenkins_data:\rname: jenkins_data\rEste nome de volume será utilizado dentro do serviço do jenkins, referenciando o caminho /var/jenkins_home:\nvolumes:\r- jenkins_data:/var/jenkins_home:rw\rIsto faz com que o volume criado tenha o nome jenkins_data e agora não importa quantas vezes você realize os comandos docker-compose up e docker-compose down, haverá somente 1 volume criado:\nO último trecho é a configuração de build, onde indica que há um dockerfile e que ele devemos realizar a compilação do container, no caso de não existir:\nservices:\rjenkins: build: .\rDockerfile\rNo Dockerfile , temos a configuração e execução do trecho que instala os plugins do jenkins:\nCOPY ./plugins/plugins.txt /usr/share/jenkins/ref/plugins.txt\rRUN /usr/local/bin/install-plugins.sh \u0026lt; /usr/share/jenkins/ref/plugins.txt\rA imagem oficial do Jenkins contém um script chamado install-plubins.sh onde realiza automaticamente o download e a instalação dos plugins listados no arquivo plugins.txt. Este script também instala os plugins dependentes, caso tenha algum.\nPor fim, o último comando define o modo de inicialização do jenkins:\nENV JAVA_OPTS=\u0026quot;-Djenkins.install.runSetupWizard=false\u0026quot;\rO padrão de inicialização do jenkins segue o seguinte formato:\njava \u0026lt;JAVA_OPTS\u0026gt; -jar jenkins.war \u0026lt;JENKINS_OPTS\u0026gt;\ronde:\nJAVA_OPTS - Parâmetros da JVM\nJENKINS_OPTS - Parâmetros de inicialização do Jenkins\nO parâmetro -Djenkins.install.runSetupWizard=false pula o Wizard de instalação do jenkins, porém deixa o jenkins sem nenhuma autenticação.\nNunca, nunca utilize as configurações deste modo em produção. Este Setup é somente para uso local e estudos. Futuramente iremos tratar de assuntos relacionados a execução do jenkins em produção.\nCriando usuário Admin\rComo estamos tratando as configurações como código, precisamos de um script inicial para criar o usuário admin. Para isto, vamos criar uma pasta groovy e criar o arquivo setup-users.groovy\n1 2 3 4 5 6 7 8 +-- wsl2-docker-devops/ # Pasta principal +-- 01_jenkins/ # Todos os arquivos referente as configurações do jenkins +-- plugins/ # Referencias aos arquivos de configuração de plugins +-- plugins.txt # Arquivo com os nomes dos plugins a serem instalados +-- groovy/ # Referencias aos arquivos de configuração do Jenkins +-- setup-users.groovy # Script para criação de usuários +-- docker-compose.yml # Configurações da aplicação +-- Dockerfile # Construção da imagem. 1 2 3 4 5 6 7 8 9 10 11 12 13 import jenkins.model.* import hudson.security.* def instance = Jenkins.getInstance() def hudsonRealm = new HudsonPrivateSecurityRealm(false) hudsonRealm.createAccount(\u0026#34;admin\u0026#34;,\u0026#34;password\u0026#34;) instance.setSecurityRealm(hudsonRealm) instance.save() def strategy = new GlobalMatrixAuthorizationStrategy() strategy.add(Jenkins.ADMINISTER, \u0026#34;admin\u0026#34;) instance.setAuthorizationStrategy(strategy) E vamos adicionar o mapeamento desta pasta no dockerfile:\n1 2 3 4 5 6 7 8 9 10 11 12 version: \u0026#34;3.4\u0026#34; volumes: jenkins_data: name: jenkins_data services: jenkins: build: . ports: - \u0026#34;8080:8080\u0026#34; volumes: - ./groovy:/var/jenkins_home/init.groovy.d - jenkins_data:/var/jenkins_home:rw Executando novamente docker-compose up \u0026amp; no terminal e acessando http://localhost:8080 teremos a tela de login do jenkins:\nAcessando com login admin e senha password temos acesso ao jenkins!\nGrande parte dos itens programáveis dentro do jenkins são realizados utilizando groovy como linguagem de programação. Dentro do jenkins existem alguns pontos de extensão onde podemos executar scripts groovy personalizados. Um ponto de extensão fica na inicialização do Jenkins, criando arquivos dentro da pasta init.groovy.d. Todos os scripts desta pasta serão executados.\nO script setup-users.groovy cria o usuário admin e utilizamos o sistema de permissão de matriz para definirmos como administrador do jenkins.\nVocê pode ver o usuário criado acessando a base interna de usuários (Jenkins \u0026raquo; Gerenciar Jenkins \u0026raquo; Gerenciar Usuários) e as atribuições de administrador em Configurar Segurança Global (Jenkins \u0026raquo; Gerenciar Jenkins \u0026raquo; configurar Segurança Global).\n!User Configurations](docker_jenkins_07.png) Nos próximos artigos veremos como criar um job e as configurações necessárias para compilar uma aplicação em java.\nCaso tenha alguma dúvida, ou uma sugestão, entre em contato.\nAbraços!\nJenkins Logo by Jenkins Artwork\n","date":"2020-06-11T02:46:15-03:00","image":"https://www.sitedoricardo.com.br/p/formal_jenkins_hu5dfca79aafb6aea109328e4323073d5a_68093_120x120_fill_box_smart1_3.png","permalink":"https://www.sitedoricardo.com.br/pt-br/p/melhorando-as-configura%C3%A7%C3%B5es-com-jenkins-e-docker/","title":"Melhorando as configurações com Jenkins e Docker"},{"content":"Introdução\rO Jenkins é uma ferramenta de automação que facilita o build, deploy com a execução de processos automatizados no ciclo de desenvolvimento de software.\nApesar de sua idade e com várias ferramentas concorrentes atuando no mesmo setor, continua sendo muito popular entre as empresas que adotam práticas de entrega contínua de software.\nEste é um conjunto de artigos com o intuito de demonstrar alguns exemplos de como utilizar, configurar e personalizar o jenkins para conhecer suas características técnicas e sua infraestrutura.\nAo mesmo tempo, o jenkins não será o único foco, mas sim grande parte do conjunto de ferramentas que auxilia o desenvolvimento, testes e algumas vezes até a utilização em ambientes mais complexos.\nCriando o Ambiente\rPor muito tempo sempre que estudava alguma ferramenta, ou tecnologia instalava direto no meu notebook. Para quem trabalha na área, sabe que com o passar do tempo seu Sistema Operacional começa a ficar lento e não existe outra solução a não ser formatar a máquina.\nSe você é um usuário de Windows (como eu) sabe que os problemas se tornam exponenciais. A solução de virtualização como Docker, Hyper-V, Virtualbox, Vagrant\u0026hellip; na maioria das vezes funcionam, mas quando não aparece problemas de lentidão, aparece problemas de incompatibilidade de versões no Windows.\nSe você usa Windows 10 Home multiplique os problemas por 1000x :weary:\nPorém com o WSL2 as coisas melhoraram.\nWSL2?\rConforme a microsoft diz em seu site:\nO WSL 2 é uma nova versão da arquitetura do Subsistema do Windows para Linux que capacita o Subsistema do Windows para Linux a executar binários ELF64 Linux no Windows. As metas principais dele são aumentar o desempenho do sistema de arquivos e adicionar compatibilidade completa com a chamada do sistema.\nDocker\rDocker no Windows Home Edition\u0026hellip; existem vários \u0026ldquo;workarounds\u0026rdquo; na internet mostrando como fazer\u0026hellip; Já testei e funcionam, porém as versões do docker-machine são muitas vezes antigas.\nPorém, recentemente houve o lançamento do Docker Desktop com Suporte a Windows Home (link).\nAgora sim!\nWSL2 + Linux\rResumidamente você tem que:\nRealizar um update do Windows 10 para uma versão compatível com o docker desktop Instalar o WSL2 Instalar docker desktop Instalar um sistema operacional linux (Não é obrigatório, mas ajuda muito!) Existem vários sites que podem te ajudar nesta etapa:\nDocker Desktop WSL 2 backend Install WSL \u0026amp; update to WSL 2 Eu gostei desse aqui, porque além de uma explicação prática, o link ensina a montar o ambiente de desenvolvimento (segui esse tutorial e estou bem contente com os resultados).\nJenkins + Docker + WSL2\rAgora com o ambiente básico montado, podemos prosseguir com o básico da criação do ambiente o jenkins.\nCrie um arquivo docker-compose.yml:\n1 2 3 4 5 6 version: \u0026#34;3.4\u0026#34; services: jenkins: image: jenkins/jenkins:lts ports: - \u0026#34;8080:8080\u0026#34; Em seguida, execute no terminal (Neste momento, recomenda-se usar o Windows Terminal com o Ubuntu conforme descritos nos links anteriores):\ndocker-compose up \u0026amp;\rApós algum tempo irá aparecer esta mensagem:\nAcesse http://localhost:8080 e informe o código:\nSelecione \u0026ldquo;Install suggested plugins\u0026rdquo;\nCrie o Usuário Admin:\nDefina o nome da Url (explicaremos mais tarde o motivo de existir esta configuração):\nJenkins Configurado!\nUma outra alternativa é acompanhar através da interface do Docker Desktop:\nHello World\rNada mais tradicional do que criar um job de Hello World, para isto, clique em Novo Job, selecione um projeto Freestyle:\nNa próxima tela, no bloco Build selecione Executar shell\nNa caixa de seleção, digite echo 'Hello World', e após clicar em Salvar, seu primeiro job estará criado.\nClique em Construir agora e seu job irá executar. Após algum tempo, seu job estará executado e gerado a primeira execução:\nAo clicar no link do job #1, você verá os detalhes, e ao clicar em Saída do Console você verá o resultado da execução.\nVocê pode desligar seu container agora com o comando docker-compose stop.\nConhecendo o funcionamento do Jenkins\rO Job acima é bem simples, mas serve de exemplo para explicar algumas características do jenkins e também do WSL2. Se você for no Docker Desktop e acessar o menu Inspect você verá a seguinte informação. (Podemos confirmar também com o comando docker volumes ls)\nDica: Acessando os pontos de montagem do Docker pelo windows\rTodos os pontos de montagem do docker podem ser acessados diretamente pelo windows quando você utiliza o WSL2. Ao acessar o caminho \\\\wsl2$ você verá as imagens:\nNo meu caso, tenho 3 imagens:\nUbuntu: Este é o sistema operacional linux que instalei pelo Windows Store; docker-desktop: Este é a imagem do docker daemon rodando; docker-desktop-data: esta é a imagem onde estão as imagens baixadas e os volumes.; E navegando no caminho \\\\wsl$\\docker-desktop-data\\mnt\\wsl\\docker-desktop-data\\data\\docker\\volumes\\fe5caa110558530e6bd64b8e3b112c545387cbb2b0a7fbdf067f3505647a6f7d\\_data você terá acesso ao conteúdo do volume do docker :wink: :\n\u0026ldquo;/img/2020/06\u0026rdquo; \u0026ldquo;18_jenkins.png\u0026rdquo; \u0026ldquo;Mount Point\u0026rdquo; \u0026ldquo;Mount Point\u0026rdquo; \u0026gt;\nCaracterísticas do Jenkins\rRealizamos todos esses passos para explicar algumas características básicas em relação ao funcionamento do jenkins:\nCaracterística 1: Conceito de jobs\rO Job é a unidade básica de execução de tarefas do Jenkins. Ele é o responsável por orquestrar a execução de todos os comandos necessários para se fazer uma determinada ação, como por exemplo, compilar uma aplicação. Imagine o Job como um Shell Script gigante para executar alguma coisa!\nPorém ao contrário de um Shell Script, um Job contém algumas estruturas para organização das atividades, chamadas de steps. Cada Step é uma atividade com um propósito definido, por exemplo, os passos para se compilar uma aplicação pode ser:\nBaixar o código fonte; Compilar a aplicação; Copiar o artefato compilado para uma outra pasta; Enviar um email informando o sucesso da compilação; Característica 2: Plugins\rO Jenkins não serve de nada sem os plugins. A estrutura de plugins é o que proporciona a flexibilidade e a dinâmica necessária para diversos cenários de utilização do jenkins. Os plugins controlam, por exemplo:\nA integração com diversos provedores de autenticação; A estrutura de Roles de usuários; Os modos de acionamento dos Jobs; Integração com várias outras ferramentas (Jira, slack, google chat, github, etc..); Customização de layout; \u0026hellip;. A lista é gigante, e se houver a necessidade, você pode criar seu próprio plugin. (Um dia você irá precisar :lol:)\nCaracterística 3: Filesystem\rO Jenkins não trabalha com banco de dados. Todas as informações, configurações, job e plugins são armazenados em arquivos no disco. A maioria são arquivos xml. O jenkins durante sua execução acessa a variável de ambiente JENKINS_HOME onde está o caminho dos arquivos internos. Lembra do volume criado quando geramos o Docker? Ela é justamente a pasta apontada pelo JENKINS_HOME.\nPor trabalhar com filesystem, há cuidados adicionais em relação a infraestrutura a ser criada, controle de acesso , alta disponibilidade e principalmente sobre a segurança.\nFinalização\rEste foi um texto inicial de como criar um ambiente de desenvolvimento para qualquer tipo de aplicação, porém aqui focamos na ferramenta do Jenkins. Nos próximos artigos, iremos entrar em mais detalhes do funcionamento de toda esta estrutura.\nCaso tenha alguma dúvida, ou uma sugestão, entre em contato.\nAbraços!\nPhoto by Tian Kuan on Unsplash\n","date":"2019-09-12T01:46:15-03:00","image":"https://www.sitedoricardo.com.br/p/tian-kuan-9AxFJaNySB8-unsplash_original_hu656df110342dcbbe5039aff47d8ac6b0_77005_120x120_fill_q75_box_smart1.jpg","permalink":"https://www.sitedoricardo.com.br/pt-br/p/windows--jenkins--docker/","title":"Windows + Jenkins + Docker"},{"content":"Olá Mundo!!!\rSe você leu isso, é que o site está no ar. 👍\n🎉\n","date":"2019-09-12T00:00:00Z","image":"https://www.sitedoricardo.com.br/p/im-alived/excavator_hua543d5175ea7410e792fb1275b608214_681042_120x120_fill_q75_box_smart1.jpg","permalink":"https://www.sitedoricardo.com.br/pt-br/p/estou-vivo/","title":"Estou vivo!"}]