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
Šodien problēmai ir risinājums: Jenkins 2 lieliski strādā ar
Kāpēc es sāku risināt šo problēmu?
Tā kā mēs esam uzņēmumā
- 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ā “
Ī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
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 docker
kur 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
Rakstot šo rakstu, radās diskusija par aģentu izmantošanu attālos serveros, lai neielādētu galveno mezglu, izmantojot spraudni
Avots: www.habr.com