كيفية جمع المشاريع في جنكينز إذا كنت بحاجة إلى العديد من البيئات المختلفة

هناك العديد من المقالات عن حبري حول جينكينز، لكن القليل منها يصف أمثلة على كيفية عمل جينكينز ووكلاء الرصيف. جميع أدوات بناء المشاريع الشائعة مثل Drone.io, خط أنابيب بيتبوكت, GitLab, إجراءات جيثب وغيرهم، يمكنهم جمع كل شيء في حاويات. ولكن ماذا عن جينكينز؟

يوجد اليوم حل للمشكلة: يعمل Jenkins 2 بشكل رائع وكلاء عامل الميناء. في هذه المقالة أريد أن أشارك تجربتي وأبين كيف يمكنك القيام بذلك بنفسك.

لماذا بدأت في حل هذه المشكلة؟

وبما أننا في الشركة السترونيوم نظرًا لأننا نستخدم العديد من التقنيات المختلفة، يتعين علينا الاحتفاظ بإصدارات مختلفة من Node.JS وGradle وRuby وJDK وغيرها على جهاز التجميع. ولكن في كثير من الأحيان لا يمكن تجنب تعارضات الإصدارات. نعم، ستكون على حق إذا قلت أن هناك العديد من مديري الإصدارات مثل nvm وrvm، ولكن ليس كل شيء على ما يرام معهم وهذه الحلول بها مشاكل:

• قدر كبير من وقت التشغيل الذي ينسى المطورون تنظيفه؛
• هناك تعارضات بين إصدارات مختلفة من نفس أوقات التشغيل؛
• يحتاج كل مطور إلى مجموعة مختلفة من المكونات.

هناك مشاكل أخرى، لكن دعني أخبرك بالحل.

جنكينز في دوكر

نظرًا لأن Docker أصبح الآن راسخًا في عالم التطوير، فيمكن تشغيل أي شيء تقريبًا باستخدام Docker. الحل الذي أقترحه هو أن يكون Jenkins في Docker وأن يكون قادرًا على تشغيل حاويات Docker الأخرى. بدأ طرح هذا السؤال في عام 2013 في المقال "يمكن الآن تشغيل Docker داخل Docker".

باختصار، تحتاج فقط إلى تثبيت 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 العمل مع صور 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حيث يمكنك تحديد:

• اسم حاوية التجميع وفقًا لسياسة التسمية الخاصة بك؛
• الوسائط اللازمة لتشغيل حاوية البناء، حيث نقوم في حالتنا بتركيب الدليل الحالي كدليل داخل الحاوية.

وبالفعل في خطوات الإنشاء، نشير إلى الأوامر التي سيتم تنفيذها داخل وكيل بناء 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 دقيقة لكل مشروع؛
• بيئة إنشاء تطبيق قابلة للتكرار تمامًا، حيث يمكنك إنشاءها بهذه الطريقة على جهاز الكمبيوتر المحلي الخاص بك؛
• لا توجد مشاكل في التعارض بين الإصدارات المختلفة لأدوات التجميع؛
• دائمًا مساحة عمل نظيفة لا تتعرض للانسداد.

الحل في حد ذاته بسيط وواضح ويتيح لك الحصول على بعض المزايا. نعم، ارتفع عتبة الدخول قليلاً مقارنة بأوامر التجميع البسيطة، ولكن يوجد الآن ضمان بأنه سيتم بناؤه دائمًا ويمكن للمطور نفسه اختيار كل ما هو ضروري لعملية البناء الخاصة به.

يمكنك أيضًا استخدام الصورة التي جمعتها جنكينز + دوكر. جميع المصادر مفتوحة وتقع في rmuhamedgaliev/jenkins_docker.

أثناء كتابة هذا المقال، نشأ نقاش حول استخدام الوكلاء على الخوادم البعيدة حتى لا يتم تحميل العقدة الرئيسية باستخدام مكون إضافي عامل ميناء المساعد. لكنني سأتحدث عن هذا في المستقبل.

المصدر: www.habr.com