
Habr on palju artikleid Jenkinsist, kuid vÀhestes neist kirjeldatakse töötava Jenkins ja Docker agentide nÀidet. KÔik populaarsed projektide koostamise tööriistad, nagu , , , ja teised, suudavad koguda kÔike konteinerites. Aga kuidas on Jenkinsiga?
TÀnaseks on probleemile olemas lahendus: Jenkins 2 oskab suurepÀraselt töötada . Artiklis tahan jagada oma kogemusi ja nÀidata, kuidas saate seda ise teha.
Miks ma hakkasin seda probleemi lahendama?
Kuna meie ettevÔttes kasutame palju erinevaid tehnoloogiaid, peab ehitusmasin hoidma erinevaid Node.JS, Gradle, Ruby, JDK ja muid versioone. Kuid tihti ei ole versioonide konflikte vÔimalik vÀltida. Jah, teate, et on olemas erinevad versioonihaldurid, nagu nvm, rvm, kuid mitte kÔik on nendega nii sujuv ja nende lahendustel on probleeme:
- suure hulga runtime-dega, mida arendajad unustavad puhastada;
- on konflikte erinevate versioonide vahel samade runtime-de vahel;
- iga arendaja vajab erinevat komponentide komplekti.
On ka teisi probleeme, kuid las ma rÀÀgin paremini lahendusest.
Jenkins Dockeris
Kuna Docker on arenduses juba kindlalt juurdunud, saab peaaegu kĂ”ike kĂ€ivitada Dockeriga. Minu lahendus on, et Jenkins oleks Dockeris ja suudaks kĂ€ivitada teisi Docker konteinerite. Selle kĂŒsimuse ĂŒle hakati mĂ”tlema juba 2013. aastal artiklis â«.
LĂŒhidalt öeldes on vajalik töö konteinerisse paigaldada ise Docker ja mountida fail /var/run/docker.sock.
Siin on nÀide Dockerfile'ist, mis saadi Jenkinsile.
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 jenkinsNii saime Docker konteineri, mis suudab tÀita Docker kÀske hostimasinatel.
Koostamise seadistamine
Hiljuti sai Jenkins vĂ”imaluse kirjeldada oma reegleid sĂŒntaks, mis vĂ”imaldab ĂŒsna lihtsalt muuta koostamis skripti ja hoida seda hoidlas.
Nii et paneme hoidlasse spetsiaalse Dockerfile'i, mis sisaldab kÔiki koostamiseks vajalikke teeke. Nii saab arendaja valmistada ette korratav keskkond ja OPS'ilt ei pea paluma, et konkreetne Node.JS versioon hosti paigaldataks.
FROM node:12.10.0-alpine
RUN npm install yarn -gSee koostamispilt sobib enamiku Node.JS rakenduste jaoks. Ja kui nÀiteks vajate JVM projekti jaoks pilti, kuhu on sisse ehitatud Sonar skanner? Te vÔite vabalt valida koostamiseks vajalikud komponendid.
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/
Oleme kirjeldanud koostamis keskkonda, kuid mis puutub Jenkinsisse? Jenkins'i agendid oskavad töötada selliste Docker piltidega ja viia lÀbi koostamist sees.
stage("Projekti koostamine") {
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"
}
}Direktiiv agent kasutab omadust docker, kus saate nÀidata:
- koostamis konteineri nimi vastavalt teie nimede poliitikale;
- argumente, mis on vajalikud koostamis konteineri kÀivitamiseks, kus meie puhul monteerime praeguse katalooge konteineri sisse.
Ja koostamise sammudes nĂ€itame, milliseid kĂ€ske tĂ€ita koostamis Docker agendi sees. See vĂ”ib olla ĂŒkskĂ”ik, nii et kĂ€ivitan ka rakenduste juurutamise ansible'i abil.
Allpool tahan nĂ€idata ĂŒldist Jenkinsfile'i, mis suudab koostada lihtsa Node.JS rakenduse.
def DOCKER_IMAGE_BRANCH = ""
def GIT_COMMIT_HASH = ""
pipeline {
options {
buildDiscarder(
logRotator(
artifactDaysToKeepStr: "",
artifactNumToKeepStr: "",
daysToKeepStr: "",
numToKeepStr: "10"
)
)
disableConcurrentBuilds()
}
agent any
stages {
stage("Valmistage ehituspilt") {
steps {
sh "docker build -f Dockerfile.build . -t project-build:${DOCKER_IMAGE_BRANCH}"
}
}
stage("Proj Loo") {
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()
}
}
}Mis on tulemuseks?
Selle meetodi abil lahendasime jÀrgmised probleemid:
- ehituskeskkonna konfiguratsiooni aeg on 10â15 minutit projekti kohta;
- tÀielikult replikeeritav rakenduse ehituskeskkond, kuna on vÔimalik koguda ka kohalikul arvutil;
- pole probleeme erinevate ehitustööriistade versioonide konfliktidega;
- alati puhas tööruum, mis ei ummista.
Lahendus iseenesest on lihtne ja ilmne ning vĂ”imaldab saavutada ainult eeliseid. Jah, sisenemise kĂŒnnis on natuke tĂ”usnud vĂ”rreldes lihtsate ehitus kĂ€skudega, kuid nĂŒĂŒd on garanteeritud, et ehitus toimub alati ja arendaja saab ise valida kĂ”ik, mis on vajalik tema ehitusprotsessile.
Samuti vÔite kasutada minu koostatud pilti . KÔik lÀhtekoodid on avatud ja asuvad aadressil .
Artikli kirjutamise kÀigus tekkis arutelu, kas kasutada agente eemalserverites, et mitte koormata pÔhikonteinerit pluginaga . Kuid sellest rÀÀgin tulevikus.
Allikas: habr.com
