Kā apkopot projektus Dženkinsā, ja jums ir nepieciešamas daudzas dažādas vides

Kā apkopot projektus Dženkinsā, ja jums ir nepieciešamas daudzas dažādas vides

Par Habrē ir daudz rakstu par Dženkinsu, taču tikai daži apraksta Dženkinsa un dokera aģentu darba piemērus. Visi populārie projektu veidošanas rīki, piemēram Drone.io, Bitbucket cauruļvads, GitLab, GitHub darbības un citi, var savākt visu konteineros. Bet kā ar Dženkinsu?

Šodien problēmai ir risinājums: Jenkins 2 lieliski strādā ar Dokera aģenti. Šajā rakstā es vēlos dalīties savā pieredzē un parādīt, kā jūs varat to izdarīt pats.

Kāpēc es sāku risināt šo problēmu?

Tā kā mēs esam uzņēmumā Citronijs Tā kā mēs izmantojam daudzas dažādas tehnoloģijas, mums ir jāsaglabā dažādas Node.JS, Gradle, Ruby, JDK un citu versijas montāžas mašīnā. Taču bieži vien no versiju konfliktiem nevar izvairīties. Jā, jums būs taisnība, ja sakāt, ka ir dažādi versiju pārvaldnieki, piemēram, nvm, rvm, bet ar tiem ne viss ir tik gludi un šiem risinājumiem ir problēmas:

  • liels izpildlaika apjoms, ko izstrādātāji aizmirst notīrīt;
  • pastāv konflikti starp dažādām viena un tā paša izpildlaika versijām;
  • Katram izstrādātājam ir nepieciešams atšķirīgs komponentu komplekts.

Ir arī citas problēmas, bet es pastāstīšu par risinājumu.

Dženkinss filmā Docker

Tā kā Docker tagad ir labi nostiprinājies izstrādes pasaulē, gandrīz jebko var palaist, izmantojot Docker. Mans risinājums ir izveidot Dženkinsu programmā Docker un var palaist citus Docker konteinerus. Šo jautājumu sāka uzdot tālajā 2013. gadā rakstā “Docker tagad var darboties programmā Docker".

Īsāk sakot, jums vienkārši jāinstalē pats Docker darba konteinerā un jāpievieno fails /var/run/docker.sock.

Šeit ir Dockerfile piemērs, kas izrādījās Dženkinsam.

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

Tādējādi mēs ieguvām Docker konteineru, kas var izpildīt Docker komandas resursdatorā.

Būvējuma iestatīšana

Pirms neilga laika Dženkinsam bija iespēja aprakstīt savus noteikumus, izmantojot Cauruļvads sintakse, kas ļauj diezgan viegli mainīt būvēšanas skriptu un saglabāt to repozitorijā.

Tātad pašā repozitorijā ievietosim īpašu Dockerfile, kurā būs visas būvēšanai nepieciešamās bibliotēkas. Tādā veidā izstrādātājs pats var sagatavot atkārtojamu vidi un viņam nebūs jālūdz OPS instalēt konkrētu Node.JS versiju resursdatorā.

FROM node:12.10.0-alpine

RUN npm install yarn -g

Šis būvējuma attēls ir piemērots lielākajai daļai Node.JS lietojumprogrammu. Ko darīt, ja, piemēram, jums ir nepieciešams attēls JVM projektam ar iebūvētu Sonar skeneri? Jūs varat brīvi izvēlēties montāžai nepieciešamās sastāvdaļas.

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/

Mēs aprakstījām montāžas vidi, bet kāds Dženkinsam ar to sakars? Un Jenkins aģenti var strādāt ar šādiem Docker attēliem un izveidot tos iekšēji.

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

direktīva agent izmanto īpašumu dockerkur var norādīt:

  • montāžas konteinera nosaukums saskaņā ar jūsu nosaukumu piešķiršanas politiku;
  • argumenti, kas nepieciešami, lai palaistu būvēšanas konteineru, kur mūsu gadījumā mēs pievienojam pašreizējo direktoriju kā direktoriju konteinera iekšpusē.

Un jau būvēšanas soļos mēs norādām, kuras komandas izpildīt Docker veidošanas aģentā. Tas var būt jebkas, tāpēc es arī palaižu lietojumprogrammu izvietošanu, izmantojot ansible.

Tālāk es vēlos parādīt vispārīgu Jenkinsfile, ko var izveidot vienkārša Node.JS lietojumprogramma.

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

}

Kas notika?

Pateicoties šai metodei, mēs atrisinājām šādas problēmas:

  • vides montāžas konfigurācijas laiks tiek samazināts līdz 10 - 15 minūtēm vienam projektam;
  • pilnībā atkārtojama lietojumprogrammu veidošanas vide, jo šādā veidā varat to izveidot savā lokālajā datorā;
  • nav problēmu ar konfliktiem starp dažādām montāžas instrumentu versijām;
  • vienmēr ir tīra darba vieta, kas neaizsērē.

Pats risinājums ir vienkāršs un acīmredzams, un tas ļauj iegūt dažas priekšrocības. Jā, ieejas slieksnis ir nedaudz cēlies, salīdzinot ar vienkāršām komandām komplektiem, taču tagad ir garantija, ka tas vienmēr tiks uzbūvēts un pats izstrādātājs var izvēlēties visu, kas nepieciešams viņa veidošanas procesam.

Varat arī izmantot manis savākto attēlu Dženkinss + Dokers. Visi avoti ir atvērti un atrodas plkst rmuhamedgaliev/jenkins_docker.

Rakstot šo rakstu, radās diskusija par aģentu izmantošanu attālos serveros, lai neielādētu galveno mezglu, izmantojot spraudni docker-spraudnis. Bet par to es runāšu nākotnē.

Avots: www.habr.com

Pievieno komentāru