როგორ შეაგროვოთ პროექტები ჯენკინსში, თუ გჭირდებათ მრავალი განსხვავებული გარემო

Habré-ზე ბევრი სტატიაა ჯენკინსის შესახებ, მაგრამ რამდენიმე აღწერს მაგალითებს, თუ როგორ მუშაობენ ჯენკინსი და დოკერ აგენტები. პროექტების შექმნის ყველა პოპულარული ინსტრუმენტი, როგორიცაა Drone.io, Bitbucket Pipeline, გიტლაბი, GitHub მოქმედებები და სხვებს შეუძლიათ შეაგროვონ ყველაფერი კონტეინერებში. მაგრამ რაც შეეხება ჯენკინსს?

დღეს არის პრობლემის გადაწყვეტა: Jenkins 2-თან მუშაობა შესანიშნავად მუშაობს დოკერის აგენტები. ამ სტატიაში მინდა გაგიზიაროთ ჩემი გამოცდილება და გაჩვენოთ, თუ როგორ შეგიძლიათ ამის გაკეთება საკუთარ თავს.

რატომ დავიწყე ამ პრობლემის მოგვარება?

რადგან კომპანიაში ვართ ციტრონიუმი იმის გამო, რომ ჩვენ ვიყენებთ მრავალ განსხვავებულ ტექნოლოგიას, უნდა შევინახოთ Node.JS, Gradle, Ruby, JDK და სხვა ვერსიები ასამბლეის მანქანაზე. მაგრამ ხშირად ვერსიების კონფლიქტების თავიდან აცილება შეუძლებელია. დიახ, მართალი იქნებით, თუ იტყვით, რომ არსებობს სხვადასხვა ვერსიის მენეჯერები, როგორიცაა nvm, rvm, მაგრამ მათთან ყველაფერი ასე გლუვი არ არის და ამ გადაწყვეტილებებს აქვს პრობლემები:

• სამუშაო დროის დიდი რაოდენობა, რომლის გაწმენდა დეველოპერებს ავიწყდებათ;
• არსებობს კონფლიქტები ერთი და იგივე გაშვების სხვადასხვა ვერსიებს შორის;
• ყველა დეველოპერს სჭირდება კომპონენტების განსხვავებული ნაკრები.

არის სხვა პრობლემები, მაგრამ გეტყვით გამოსავლის შესახებ.

ჯენკინსი დოკერში

მას შემდეგ, რაც Docker ახლა კარგად არის ჩამოყალიბებული განვითარების სამყაროში, თითქმის ყველაფრის გაშვება შესაძლებელია Docker-ის გამოყენებით. ჩემი გამოსავალი არის ჯენკინსი მყავდეს დოკერში და შემეძლოს სხვა დოკერის კონტეინერების გაშვება. ეს კითხვა ჯერ კიდევ 2013 წელს დაიწყო სტატიაში ”Docker-ს ახლა შეუძლია Docker-ში გაშვება".

მოკლედ, თქვენ უბრალოდ უნდა დააინსტალიროთ თავად Docker სამუშაო კონტეინერში და დააინსტალიროთ ფაილი /var/run/docker.sock.

აქ არის Dockerfile-ის მაგალითი, რომელიც აღმოჩნდა ჯენკინსისთვის.

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

ამრიგად, ჩვენ მივიღეთ Docker კონტეინერი, რომელსაც შეუძლია შეასრულოს Docker ბრძანებები მასპინძელ მანქანაზე.

აშენების დაყენება

ცოტა ხნის წინ ჯენკინსს მიეცა შესაძლებლობა აღეწერა თავისი წესები გამოყენებით მილსადენის синтаксиса, что позволяет достаточно просто менять скрипт сборки и хранить его в репозитории.

მაშ, მოდით, თავად საცავში ჩავდოთ სპეციალური Dockerfile, რომელიც შეიცავს ყველა ბიბლიოთეკას, რომელიც აუცილებელია build-ისთვის. ამ გზით, თავად დეველოპერს შეუძლია მოამზადოს განმეორებადი გარემო და არ მოუწევს OPS-ს სთხოვოს, დააინსტალიროს Node.JS-ის კონკრეტული ვერსია ჰოსტზე.

FROM node:12.10.0-alpine

RUN npm install yarn -g

ეს build სურათი შესაფერისია Node.JS აპლიკაციების უმეტესობისთვის. რა მოხდება, თუ, მაგალითად, გჭირდებათ სურათი JVM პროექტისთვის, რომელშიც შედის Sonar სკანერი? თქვენ თავისუფლად შეგიძლიათ აირჩიოთ კომპონენტები, რომლებიც გჭირდებათ ასამბლეისთვის.

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/

ჩვენ აღვწერეთ ასამბლეის გარემო, მაგრამ რა კავშირი აქვს მას ჯენკინსი? და ჯენკინსის აგენტებს შეუძლიათ იმუშაონ დოკერის ასეთ სურათებთან და ააშენონ ისინი შიგნით.

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

დირექტივა agent იყენებს ქონებას dockerსადაც შეგიძლიათ მიუთითოთ:

• შეკრების კონტეინერის დასახელება თქვენი დასახელების პოლიტიკის მიხედვით;
• არგუმენტები, რომლებიც საჭიროა build კონტეინერის გასაშვებად, სადაც ჩვენს შემთხვევაში ვამონტაჟებთ მიმდინარე დირექტორიას, როგორც დირექტორიაში კონტეინერის შიგნით.

და უკვე build-ის საფეხურებში ჩვენ მივუთითებთ, თუ რომელი ბრძანებები უნდა შესრულდეს Docker build აგენტის შიგნით. ეს შეიძლება იყოს ნებისმიერი, ამიტომ მე ასევე ვიწყებ აპლიკაციის განლაგებას ansible-ის გამოყენებით.

ქვემოთ მე მინდა ვაჩვენო ზოგადი Jenkinsfile, რომლის შექმნა მარტივი 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()
        }
    }

}

Რა მოხდა?

ამ მეთოდის წყალობით, ჩვენ გადავწყვიტეთ შემდეგი პრობლემები:

• გარემოს შეკრების კონფიგურაციის დრო მცირდება 10 - 15 წუთამდე თითო პროექტზე;
• სრულიად განმეორებადი აპლიკაციის აგების გარემო, რადგან თქვენ შეგიძლიათ მისი აშენება ამ გზით თქვენს ადგილობრივ კომპიუტერზე;
• არ არის პრობლემები შეკრების ხელსაწყოების სხვადასხვა ვერსიებს შორის კონფლიქტებთან დაკავშირებით;
• ყოველთვის სუფთა სამუშაო ადგილი, რომელიც არ იკეტება.

გამოსავალი თავისთავად მარტივი და აშკარაა და საშუალებას გაძლევთ მიიღოთ გარკვეული უპირატესობები. დიახ, შესვლის ბარიერი ოდნავ გაიზარდა შეკრებების მარტივ ბრძანებებთან შედარებით, მაგრამ ახლა არის გარანტია, რომ ის ყოველთვის აშენდება და თავად დეველოპერს შეუძლია აირჩიოს ყველაფერი, რაც აუცილებელია მისი მშენებლობის პროცესისთვის.

თქვენ ასევე შეგიძლიათ გამოიყენოთ ჩემს მიერ შეგროვებული სურათი ჯენკინსი + დოკერი. ყველა წყარო ღიაა და მდებარეობს აქ rmuhamedgaliev/jenkins_docker.

ამ სტატიის წერისას წარმოიშვა დისკუსია დისტანციურ სერვერებზე აგენტების გამოყენების შესახებ, რათა არ ჩაიტვირთოს ძირითადი კვანძი დანამატის გამოყენებით დოკერ-მოდული. მაგრამ ამაზე სამომავლოდ ვისაუბრებ.

წყარო: www.habr.com