Estas multaj artikoloj pri Habré pri Jenkins, sed malmultaj priskribas ekzemplojn pri kiel funkcias Jenkins kaj docker-agentoj. Ĉiuj popularaj projekto-konstruaj iloj kiel , , , kaj aliaj, povas kolekti ĉion en ujoj. Sed kio pri Jenkins?
Hodiaŭ ekzistas solvo al la problemo: Jenkins 2 bonege laboras kun . En ĉi tiu artikolo mi volas dividi mian sperton kaj montri kiel vi povas fari ĝin mem.
Kial mi komencis solvi ĉi tiun problemon?
Ĉar ni estas en kompanio Ĉar ni uzas multajn malsamajn teknologiojn, ni devas konservi malsamajn versiojn de Node.JS, Gradle, Ruby, JDK kaj aliajn sur la kunigmaŝino. Sed ofte versiokonfliktoj ne povas esti evititaj. Jes, vi pravos, se vi diras, ke ekzistas diversaj versio-administrantoj kiel nvm, rvm, sed ne ĉio estas tiel glata ĉe ili kaj ĉi tiuj solvoj havas problemojn:
- granda kvanto da rultempo, kiun programistoj forgesas purigi;
- ekzistas konfliktoj inter malsamaj versioj de la samaj rultempoj;
- Ĉiu programisto bezonas malsaman aron da komponantoj.
Estas aliaj problemoj, sed mi rakontu al vi pri la solvo.
Jenkins en Docker
Ĉar Docker nun estas bone establita en la evolua mondo, preskaŭ io ajn povas ruliĝi per Docker. Mia solvo estas havi Jenkins en Docker kaj povi ruli aliajn Docker-ujojn. Ĉi tiu demando komencis esti demandita reen en 2013 en la artikolo "".
Resume, vi nur bezonas instali Docker mem en funkcianta ujo kaj munti la dosieron /var/run/docker.sock.
Jen ekzemplo Dockerfile, kiu rezultis por Jenkins.
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 jenkinsTiel, ni ricevis Docker-ujon, kiu povas ekzekuti Docker-komandojn sur la gastiga maŝino.
Konstrua aranĝo
Antaŭ nelonge Jenkins ricevis la ŝancon priskribi ĝiajn regulojn uzante sintakso, kiu faciligas ŝanĝi la konstruskripton kaj konservi ĝin en la deponejo.
Do ni metu specialan Dockerfile en la deponejon mem, kiu enhavos ĉiujn bibliotekojn necesajn por la konstruo. Tiel, la programisto mem povas prepari ripeteblan medion kaj ne devos peti OPS instali specifan version de Node.JS sur la gastiganto.
FROM node:12.10.0-alpine
RUN npm install yarn -gĈi tiu konstrubildo taŭgas por plej multaj Node.JS-aplikoj. Kio se, ekzemple, vi bezonas bildon por JVM-projekto kun Sonar-skanilo inkluzivita ene? Vi rajtas elekti la komponantojn, kiujn vi bezonas por kunigo.
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/
Ni priskribis la kunigmedion, sed kion Jenkins devas fari kun ĝi? Kaj Jenkins-agentoj povas labori kun tiaj Docker-bildoj kaj konstrui ilin interne.
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"
}
}Direktivo agent uzas proprieton dockerkie vi povas specifi:
- la nomo de la kunigujo laŭ via nompolitiko;
- argumentoj bezonataj por ruli la konstruujon, kie en nia kazo ni muntas la nunan dosierujon kiel dosierujon ene de la ujo.
Kaj jam en la konstruaj paŝoj ni indikas kiajn komandojn ekzekuti ene de la konstrua agento de Docker. Ĉi tio povas esti io ajn, do mi ankaŭ lanĉas aplikaĵon per ansible.
Malsupre mi volas montri senmarkan Jenkinsfile, kiun simpla aplikaĵo Node.JS povas konstrui.
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()
}
}
}Kio okazis?
Danke al ĉi tiu metodo, ni solvis la jenajn problemojn:
- media asemblea agorda tempo estas reduktita al 10 - 15 minutoj por projekto;
- tute ripetebla aplikaĵa konstrumedio, ĉar vi povas konstrui ĝin tiel sur via loka komputilo;
- ne estas problemoj kun konfliktoj inter malsamaj versioj de kunigiloj;
- ĉiam pura laborspaco, kiu ne ŝtopiĝas.
La solvo mem estas simpla kaj evidenta kaj permesas vin akiri iujn avantaĝojn. Jes, la enira sojlo iom altiĝis kompare kun simplaj komandoj por asembleoj, sed nun estas garantio, ke ĝi ĉiam estos konstruita kaj la programisto mem povas elekti ĉion, kio estas necesa por sia konstruprocezo.
Vi ankaŭ povas uzi la bildon, kiun mi kolektis . Ĉiuj fontoj estas malfermitaj kaj troviĝas ĉe .
Dum la verkado de ĉi tiu artikolo, ekestis diskuto pri uzado de agentoj en foraj serviloj por ne ŝargi la majstran nodon per kromaĵo. . Sed mi parolos pri tio estonte.
fonto: www.habr.com