Hoe projecten in Jenkins te verzamelen als je veel verschillende omgevingen nodig hebt

Er zijn veel artikelen op Habré over Jenkins, maar weinigen beschrijven voorbeelden van hoe Jenkins en havenagenten werken. Alle populaire tools voor het bouwen van projecten, zoals Drone.io, Bitbucket-pijplijn, GitLab, GitHub-acties en anderen, kunnen alles in containers verzamelen. Maar hoe zit het met Jenkins?

Vandaag is er een oplossing voor het probleem: Jenkins 2 is geweldig om mee te werken Docker-agenten. In dit artikel wil ik mijn ervaring delen en laten zien hoe je het zelf kunt doen.

Waarom ben ik begonnen met het oplossen van dit probleem?

Omdat we in gezelschap zijn Citroen Omdat we veel verschillende technologieën gebruiken, moeten we verschillende versies van Node.JS, Gradle, Ruby, JDK en andere op de assemblagemachine bewaren. Maar vaak zijn versieconflicten niet te vermijden. Ja, je hebt gelijk als je zegt dat er verschillende versiebeheerders zijn zoals nvm, rvm, maar niet alles verloopt zo soepel en deze oplossingen hebben problemen:

• een grote hoeveelheid runtime die ontwikkelaars vergeten op te schonen;
• er zijn conflicten tussen verschillende versies van dezelfde runtimes;
• Elke ontwikkelaar heeft een andere set componenten nodig.

Er zijn nog andere problemen, maar ik zal u vertellen over de oplossing.

Jenkins in Docker

Omdat Docker nu goed ingeburgerd is in de ontwikkelingswereld, kan bijna alles met Docker worden uitgevoerd. Mijn oplossing is om Jenkins in Docker te hebben en andere Docker-containers te kunnen draaien. Deze vraag werd in 2013 gesteld in het artikel “Docker kan nu binnen Docker worden uitgevoerd".

Kortom, u hoeft alleen maar Docker zelf in een werkende container te installeren en het bestand te mounten /var/run/docker.sock.

Hier is een voorbeeld van een Dockerfile dat voor Jenkins is gebleken.

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

We hebben dus een Docker-container die Docker-opdrachten op de hostmachine kan uitvoeren.

Bouw opstelling

Nog niet zo lang geleden kreeg Jenkins de kans om zijn regels te beschrijven met behulp van Pijpleiding syntaxis, waardoor het vrij eenvoudig is om het buildscript te wijzigen en op te slaan in de repository.

Laten we dus een speciaal Docker-bestand in de repository zelf plaatsen, dat alle bibliotheken zal bevatten die nodig zijn voor de build. Op deze manier kan de ontwikkelaar zelf een herhaalbare omgeving voorbereiden en hoeft hij OPS niet te vragen een specifieke versie van Node.JS op de host te installeren.

FROM node:12.10.0-alpine

RUN npm install yarn -g

Deze build-image is geschikt voor de meeste Node.JS-toepassingen. Wat als u bijvoorbeeld een afbeelding nodig heeft voor een JVM-project met daarin een Sonar-scanner? U bent vrij in de keuze van de onderdelen die u nodig heeft voor de montage.

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/

We hebben de assemblageomgeving beschreven, maar wat heeft Jenkins ermee te maken? En Jenkins-agenten kunnen met dergelijke Docker-images werken en deze intern bouwen.

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"
    }
}

Richtlijn agent maakt gebruik van eigendom dockerwaar u kunt opgeven:

• de naam van de montagecontainer volgens uw naamgevingsbeleid;
• argumenten die nodig zijn om de build-container uit te voeren, waarbij we in ons geval de huidige map aankoppelen als een map in de container.

En al in de build-stappen geven we aan welke commando's moeten worden uitgevoerd in de Docker-build-agent. Dit kan van alles zijn, dus ik start de implementatie van applicaties ook met behulp van ansible.

Hieronder wil ik een generiek Jenkinsbestand laten zien dat een eenvoudige Node.JS-applicatie kan bouwen.

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()
        }
    }

}

Wat is er gebeurd?

Dankzij deze methode hebben we de volgende problemen opgelost:

• De configuratietijd voor de montage van de omgeving wordt teruggebracht tot 10 - 15 minuten per project;
• een volledig herhaalbare applicatie-bouwomgeving, aangezien u deze op deze manier op uw lokale computer kunt bouwen;
• er zijn geen problemen met conflicten tussen verschillende versies van assemblagetools;
• altijd een schone werkplek die niet verstopt raakt.

De oplossing zelf is eenvoudig en voor de hand liggend en biedt u enkele voordelen. Ja, de instapdrempel is iets gestegen vergeleken met eenvoudige commando's voor assemblages, maar nu is er een garantie dat het altijd gebouwd zal worden en dat de ontwikkelaar zelf alles kan kiezen wat nodig is voor zijn bouwproces.

Je kunt ook de afbeelding gebruiken die ik heb verzameld Jenkins + Docker. Alle bronnen zijn open en bevinden zich op rmuhamedgaliev/jenkins_docker.

Tijdens het schrijven van dit artikel ontstond er een discussie over het gebruik van agents op externe servers om het masterknooppunt niet te laden met behulp van een plug-in docker-plug-in. Maar ik zal hier in de toekomst over praten.

Bron: www.habr.com