ProHoster > Blog > Administración > Como recoller proxectos en Jenkins se necesitas moitos ambientes diferentes

Como recoller proxectos en Jenkins se necesitas moitos ambientes diferentes

Como recoller proxectos en Jenkins se necesitas moitos ambientes diferentes

Hai moitos artigos sobre Habré sobre Jenkins, pero poucos describen exemplos de como funcionan Jenkins e os axentes docker. Todas as ferramentas populares de construción de proxectos como Drone.io, Bitbucket Pipeline, GitLab, Accións de GitHub e outros, poden recoller todo en contedores. Pero que pasa con Jenkins?

Hoxe hai unha solución ao problema: Jenkins 2 é excelente para traballar Axentes Docker. Neste artigo quero compartir a miña experiencia e mostrar como podes facelo ti mesmo.

Por que comecei a resolver este problema?

Xa que estamos en compañía Citronio Como usamos moitas tecnoloxías diferentes, temos que manter diferentes versións de Node.JS, Gradle, Ruby, JDK e outras na máquina de ensamblaxe. Pero moitas veces non se poden evitar os conflitos de versións. Si, terás razón se dis que hai varios xestores de versións como nvm, rvm, pero non todo é tan sinxelo con eles e estas solucións teñen problemas:

  • unha gran cantidade de tempo de execución que os desenvolvedores esquecen limpar;
  • hai conflitos entre diferentes versións dos mesmos tempos de execución;
  • Cada programador necesita un conxunto diferente de compoñentes.

Hai outros problemas, pero déixeme falar da solución.

Jenkins en Docker

Dado que Docker está agora ben establecido no mundo do desenvolvemento, case calquera cousa pódese executar usando Docker. A miña solución é ter Jenkins en Docker e poder executar outros contedores Docker. Esta pregunta comezou a facerse en 2013 no artigo "Docker agora pode executarse dentro de Docker«.

En resumo, só precisa instalar o propio Docker nun contedor que funcione e montar o ficheiro /var/run/docker.sock.

Aquí tes un exemplo de Dockerfile que resultou para Jenkins.

FROM jenkins/jenkins:lts

USER root

RUN apt-get update && 

apt-get -y install apt-transport-https 
     ca-certificates 
     curl 
     gnupg2 
     git 
     software-properties-common && 
curl -fsSL https://download.docker.com/linux/$(. /etc/os-release; echo "$ID")/gpg > /tmp/dkey; apt-key add /tmp/dkey && 
add-apt-repository 
   "deb [arch=amd64] https://download.docker.com/linux/$(. /etc/os-release; echo "$ID") 
   $(lsb_release -cs) 
   stable" && 
apt-get update && 
apt-get -y install docker-ce && 
usermod -aG docker jenkins

RUN curl -L https://github.com/docker/compose/releases/download/1.25.0/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose && chmod +x /usr/local/bin/docker-compose 

RUN apt-get clean autoclean && apt-get autoremove —yes && rm -rf /var/lib/{apt,dpkg,cache,log}/

USER jenkins

Así, temos un contedor Docker que pode executar comandos Docker na máquina host.

Configuración de compilación

Non hai moito Jenkins tivo a oportunidade de describir as súas regras usando Oleoduto sintaxe, o que fai que sexa moi doado cambiar o script de compilación e almacenalo no repositorio.

Entón, imos poñer un Dockerfile especial no propio repositorio, que conterá todas as bibliotecas necesarias para a compilación. Deste xeito, o propio desenvolvedor pode preparar un ambiente repetible e non terá que pedirlle a OPS que instale unha versión específica de Node.JS no host.

FROM node:12.10.0-alpine

RUN npm install yarn -g

Esta imaxe de compilación é adecuada para a maioría das aplicacións Node.JS. E se, por exemplo, necesitas unha imaxe para un proxecto JVM cun escáner Sonar incluído no seu interior? Vostede é libre de escoller os compoñentes que precisa para a montaxe.

FROM adoptopenjdk/openjdk12:latest

RUN apt update 
    && apt install -y 
        bash unzip wget

RUN mkdir -p /usr/local/sonarscanner 
    && cd /usr/local/sonarscanner 
    && wget https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-3.3.0.1492-linux.zip 
    && unzip sonar-scanner-cli-3.3.0.1492-linux.zip 
    && mv sonar-scanner-3.3.0.1492-linux/* ./ 
    && rm sonar-scanner-cli-3.3.0.1492-linux.zip 
    && rm -rf sonar-scanner-3.3.0.1492-linux 
    && ln -s /usr/local/sonarscanner/bin/sonar-scanner /usr/local/bin/sonar-scanner

ENV PATH $PATH:/usr/local/sonarscanner/bin/
ENV SONAR_RUNNER_HOME /usr/local/sonarscanner/bin/

Describimos o ambiente de montaxe, pero que ten que ver Jenkins con el? E os axentes de Jenkins poden traballar con tales imaxes de Docker e crealas internamente. 

stage("Build project") {
    agent {
        docker {
            image "project-build:${DOCKER_IMAGE_BRANCH}"
            args "-v ${PWD}:/usr/src/app -w /usr/src/app"
            reuseNode true
            label "build-image"
        }
    }
    steps {
        sh "yarn"
        sh "yarn build"
    }
}

Directiva agent utiliza a propiedade dockeronde podes especificar:

  • o nome do contedor de montaxe segundo a súa política de nomenclatura;
  • argumentos necesarios para executar o contenedor de compilación, onde no noso caso montamos o directorio actual como un directorio dentro do contenedor.

E xa nos pasos de compilación indicamos que comandos executar dentro do axente de compilación Docker. Isto pode ser calquera cousa, polo que tamén lanzo a implementación de aplicacións usando ansible.

A continuación quero mostrar un ficheiro Jenkins xenérico que pode construír unha aplicación simple Node.JS.

def DOCKER_IMAGE_BRANCH = ""
def GIT_COMMIT_HASH = ""

pipeline { 
    options {
        buildDiscarder(
            logRotator(
                artifactDaysToKeepStr: "",
                artifactNumToKeepStr: "",
                daysToKeepStr: "",
                numToKeepStr: "10"
            )
        )
        disableConcurrentBuilds()
    }

    agent any

    stages {

        stage("Prepare build image") {
            steps {
                sh "docker build -f Dockerfile.build . -t project-build:${DOCKER_IMAGE_BRANCH}"
            }
        }

        stage("Build project") {
            agent {
                docker {
                    image "project-build:${DOCKER_IMAGE_BRANCH}"
                    args "-v ${PWD}:/usr/src/app -w /usr/src/app"
                    reuseNode true
                    label "build-image"
                }
            }
            steps {
                sh "yarn"
                sh "yarn build"
            }
        }

    post {
        always {
            step([$class: "WsCleanup"])
            cleanWs()
        }
    }

}

Que pasou?

Grazas a este método, resolvemos os seguintes problemas:

  • o tempo de configuración da montaxe do ambiente redúcese a 10 - 15 minutos por proxecto;
  • un entorno de compilación de aplicacións completamente repetible, xa que podes crealo deste xeito no teu ordenador local;
  • non hai problemas con conflitos entre diferentes versións de ferramentas de montaxe;
  • sempre un espazo de traballo limpo que non se atasca.

A solución en si é sinxela e obvia e permítelle obter algunhas vantaxes. Si, o limiar de entrada aumentou un pouco en comparación cos comandos simples para as montaxes, pero agora hai a garantía de que sempre se construirá e o propio desenvolvedor pode escoller todo o que sexa necesario para o seu proceso de construción.

Tamén podes usar a imaxe que recollín Jenkins + Docker. Todas as fontes están abertas e localizadas en rmuhamedgaliev/jenkins_docker.

Ao escribir este artigo, xurdiu unha discusión sobre o uso de axentes en servidores remotos para non cargar o nodo mestre usando un complemento docker-plugin. Pero disto falarei no futuro.

Fonte: www.habr.com

Engadir un comentario