มีบทความมากมายเกี่ยวกับHabréเกี่ยวกับ Jenkins แต่มีเพียงไม่กี่บทความที่อธิบายตัวอย่างวิธีการทำงานของ Jenkins และตัวแทนนักเทียบท่า เครื่องมือสร้างโครงการยอดนิยมทั้งหมดเช่น
วันนี้มีวิธีแก้ไขปัญหา: Jenkins 2 ทำงานได้ดีมาก
เหตุใดฉันจึงเริ่มแก้ไขปัญหานี้
เนื่องจากเราอยู่ในบริษัท
- รันไทม์จำนวนมากที่นักพัฒนาลืมทำความสะอาด
- มีข้อขัดแย้งระหว่างรันไทม์เดียวกันเวอร์ชันต่างๆ
- นักพัฒนาทุกคนต้องการชุดส่วนประกอบที่แตกต่างกัน
มีปัญหาอื่น ๆ แต่ให้ฉันบอกคุณเกี่ยวกับวิธีการแก้ไข
เจนกินส์ในนักเทียบท่า
เนื่องจากตอนนี้ Docker ได้รับการยอมรับอย่างดีในโลกของการพัฒนา เกือบทุกอย่างจึงสามารถรันโดยใช้ Docker ได้ วิธีแก้ปัญหาของฉันคือให้ Jenkins อยู่ใน Docker และสามารถเรียกใช้คอนเทนเนอร์ Docker อื่นได้ คำถามนี้เริ่มถูกถามในปี 2013 ในบทความ “
กล่าวโดยสรุป คุณเพียงแค่ต้องติดตั้ง Docker เองในคอนเทนเนอร์ที่ใช้งานได้และติดตั้งไฟล์ /var/run/docker.sock
.
นี่คือตัวอย่าง Dockerfile ที่ใช้กับ 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 jenkins
ดังนั้นเราจึงได้คอนเทนเนอร์ Docker ที่สามารถรันคำสั่ง Docker บนเครื่องโฮสต์ได้
สร้างการตั้งค่า
ไม่นานมานี้ เจนกินส์ได้รับโอกาสอธิบายการใช้กฎเกณฑ์ของตน
ดังนั้นเรามาใส่ Dockerfile พิเศษลงในที่เก็บซึ่งจะมีไลบรารีทั้งหมดที่จำเป็นสำหรับการสร้าง ด้วยวิธีนี้ นักพัฒนาเองสามารถเตรียมสภาพแวดล้อมที่ทำซ้ำได้ และไม่ต้องขอให้ OPS ติดตั้ง Node.JS เวอร์ชันใดเวอร์ชันหนึ่งบนโฮสต์
FROM node:12.10.0-alpine
RUN npm install yarn -g
บิลด์อิมเมจนี้เหมาะสำหรับแอปพลิเคชัน Node.JS ส่วนใหญ่ จะเป็นอย่างไรหากคุณต้องการภาพสำหรับโปรเจ็กต์ JVM ที่มีเครื่องสแกนโซนาร์อยู่ภายใน คุณมีอิสระที่จะเลือกส่วนประกอบที่คุณต้องการสำหรับการประกอบ
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/
เราได้อธิบายสภาพแวดล้อมการประกอบแล้ว แต่ Jenkins เกี่ยวข้องอะไรกับมัน? และตัวแทนของ Jenkins ก็สามารถทำงานกับอิมเมจ Docker และสร้างอิมเมจภายในได้
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"
}
}
คำสั่ง agent
ใช้ทรัพย์สิน docker
โดยที่คุณสามารถระบุ:
- ชื่อของคอนเทนเนอร์ประกอบตามนโยบายการตั้งชื่อของคุณ
- อาร์กิวเมนต์ที่จำเป็นในการรันบิลด์คอนเทนเนอร์ โดยในกรณีของเรา เราจะติดตั้งไดเร็กทอรีปัจจุบันเป็นไดเร็กทอรีภายในคอนเทนเนอร์
และในขั้นตอนการสร้างเราจะระบุคำสั่งที่จะดำเนินการภายในตัวแทนการสร้างนักเทียบท่า สิ่งนี้สามารถเป็นอะไรก็ได้ ดังนั้นฉันจึงเปิดใช้แอปพลิเคชันปรับใช้โดยใช้ ansible
ด้านล่างนี้ฉันต้องการแสดง Jenkinsfile ทั่วไปที่แอปพลิเคชัน Node.JS แบบธรรมดาสามารถสร้างได้
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()
}
}
}
เกิดอะไรขึ้น
ด้วยวิธีนี้ เราจึงแก้ไขปัญหาต่อไปนี้ได้:
- เวลาการกำหนดค่าแอสเซมบลีสภาพแวดล้อมลดลงเหลือ 10 - 15 นาทีต่อโปรเจ็กต์
- สภาพแวดล้อมการสร้างแอปพลิเคชันที่ทำซ้ำได้อย่างสมบูรณ์ เนื่องจากคุณสามารถสร้างได้ด้วยวิธีนี้บนคอมพิวเตอร์ของคุณ
- ไม่มีปัญหากับข้อขัดแย้งระหว่างเครื่องมือประกอบรุ่นต่างๆ
- พื้นที่ทำงานที่สะอาดไม่อุดตันเสมอ
วิธีแก้ปัญหานั้นเรียบง่ายและชัดเจนและช่วยให้คุณได้รับประโยชน์บางประการ ใช่ เกณฑ์การเข้าร่วมเพิ่มขึ้นเล็กน้อยเมื่อเทียบกับคำสั่งง่าย ๆ สำหรับแอสเซมบลี แต่ตอนนี้มีการรับประกันว่าจะถูกสร้างขึ้นเสมอและนักพัฒนาเองก็สามารถเลือกทุกสิ่งที่จำเป็นสำหรับกระบวนการสร้างของเขาได้
คุณสามารถใช้ภาพที่ฉันรวบรวมได้
ในขณะที่เขียนบทความนี้ มีการอภิปรายเกิดขึ้นเกี่ยวกับการใช้ตัวแทนบนเซิร์ฟเวอร์ระยะไกลเพื่อไม่ให้โหลดโหนดหลักโดยใช้ปลั๊กอิน
ที่มา: will.com