Habré kohta on Jenkinsi kohta palju artikleid, kuid vähesed kirjeldavad näiteid Jenkinsi ja dokkide agentide tööst. Kõik populaarsed projekti koostamise tööriistad nagu
Tänapäeval on probleemile lahendus: Jenkins 2 on suurepärane töö
Miks ma seda probleemi lahendama hakkasin?
Kuna oleme seltskonnas
- suur hulk käitusaega, mille arendajad unustavad puhastada;
- sama käitusaja erinevate versioonide vahel on konflikte;
- Iga arendaja vajab erinevat komponentide komplekti.
Probleeme on teisigi, kuid lubage mul teile rääkida lahendusest.
Jenkins Dockeris
Kuna Docker on nüüd arendusmaailmas hästi välja kujunenud, saab Dockeri abil käivitada peaaegu kõike. Minu lahendus on see, et Jenkins on Dockeris ja saan käitada teisi Dockeri konteinereid. Seda küsimust hakati esitama juba 2013. aastal artiklis "
Lühidalt, peate lihtsalt installima Dockeri enda töötavasse konteinerisse ja ühendama faili /var/run/docker.sock
.
Siin on näide Dockerfile'ist, mis osutus Jenkinsi jaoks välja.
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
Seega saime Dockeri konteineri, mis suudab hostmasinas Dockeri käske täita.
Ehitamise seadistus
Mitte kaua aega tagasi sai Jenkins võimaluse oma reegleid kasutades kirjeldada
Nii et paneme hoidlasse spetsiaalse Dockerfile'i, mis sisaldab kõiki ehitamiseks vajalikke teeke. Nii saab arendaja ise ette valmistada korratava keskkonna ega pea paluma OPS-il installida hostile Node.JS konkreetse versiooni.
FROM node:12.10.0-alpine
RUN npm install yarn -g
See järgu pilt sobib enamiku Node.JS rakenduste jaoks. Mis siis, kui vajate näiteks JVM-projekti jaoks pilti, mille sees on Sonar skanner? Saate vabalt valida kokkupanemiseks 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/
Kirjeldasime koostekeskkonda, kuid mis on Jenkinsil sellega pistmist? Ja Jenkinsi agendid saavad selliste Dockeri piltidega töötada ja neid sisemiselt luua.
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"
}
}
Direktiiv agent
kasutab vara docker
kus saab täpsustada:
- montaažikonteineri nimi vastavalt teie nimetamispoliitikale;
- argumendid, mis on vajalikud ehituskonteineri käitamiseks, kus meie puhul ühendame praeguse kataloogi konteineri sees oleva kataloogina.
Ja juba ehitamise etappides näitame, milliseid käske Dockeri ehitusagendi sees täita. See võib olla ükskõik milline, nii et käivitan ka rakenduse juurutamise, kasutades ansible.
Allpool tahan näidata üldist Jenkinsfile'i, mida saab luua lihtsa Node.JS-i rakendusega.
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()
}
}
}
Mis juhtus?
Tänu sellele meetodile lahendasime järgmised probleemid:
- keskkonna kokkupanemise seadistamise aeg väheneb 10–15 minutini projekti kohta;
- täiesti korratav rakenduste koostamise keskkond, kuna saate selle ehitada nii oma kohalikus arvutis;
- puuduvad probleemid koostetööriistade erinevate versioonide konfliktidega;
- alati puhas tööruum, mis ei ummistu.
Lahendus ise on lihtne ja ilmne ning võimaldab teil saada mõningaid eeliseid. Jah, sisenemislävi on sõlmede lihtsate käskudega võrreldes pisut tõusnud, kuid nüüd on garantii, et see ehitatakse alati ja arendaja saab ise valida kõik, mis oma ehitusprotsessi jaoks vajalik on.
Võite kasutada ka minu kogutud pilti
Selle artikli kirjutamise ajal tekkis arutelu agentide kasutamise üle kaugserverites, et mitte laadida põhisõlme pistikprogrammi abil
Allikas: www.habr.com