다양한 환경이 필요한 경우 Jenkins에서 프로젝트를 수집하는 방법

Habré에는 Jenkins에 대한 기사가 많이 있지만 Jenkins와 Docker 에이전트가 작동하는 방식에 대한 예를 설명하는 기사는 거의 없습니다. 다음과 같은 모든 인기 있는 프로젝트 빌드 도구 드론.io, 비트버킷 파이프라인, GitLab, GitHub 작업 그리고 다른 사람들은 모든 것을 용기에 담을 수 있습니다. 하지만 젠킨스는 어떻습니까?

오늘날 문제에 대한 해결책이 있습니다. Jenkins 2는 작업에 탁월합니다. 도커 에이전트. 이 기사에서는 내 경험을 공유하고 스스로 할 수 있는 방법을 보여주고 싶습니다.

왜 이 문제를 해결하기 시작했습니까?

우리는 회사에 있기 때문에 시트로늄 우리는 다양한 기술을 사용하기 때문에 Node.JS, Gradle, Ruby, JDK 등의 다양한 버전을 어셈블리 시스템에 유지해야 합니다. 그러나 버전 충돌을 피할 수 없는 경우가 많습니다. 예, nvm, rvm과 같은 다양한 버전 관리자가 있다고 말하면 옳을 것입니다. 그러나 모든 것이 그렇게 순조롭게 진행되는 것은 아니며 이러한 솔루션에는 문제가 있습니다.

• 개발자가 정리하는 것을 잊어버린 많은 양의 런타임;
• 동일한 런타임의 서로 다른 버전 간에 충돌이 있습니다.
• 모든 개발자에게는 서로 다른 구성 요소 세트가 필요합니다.

다른 문제도 있는데 해결 방법을 알려드리겠습니다.

도커의 젠킨스

Docker는 이제 개발 환경에서 잘 자리잡았기 때문에 Docker를 사용하면 거의 모든 것을 실행할 수 있습니다. 내 솔루션은 Docker에 Jenkins를 두고 다른 Docker 컨테이너를 실행할 수 있게 하는 것입니다. 이 질문은 2013년에 “이제 Docker 내에서 Docker를 실행할 수 있습니다.".

즉, 작업 컨테이너에 Docker 자체를 설치하고 파일을 마운트하기만 하면 됩니다. /var/run/docker.sock.

다음은 Jenkins용으로 나온 Dockerfile의 예입니다.

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 컨테이너가 생겼습니다.

빌드 설정

얼마 전 Jenkins는 다음을 사용하여 규칙을 설명할 기회를 얻었습니다. 관로 구문을 사용하면 빌드 스크립트를 변경하고 저장소에 저장하는 것이 매우 쉽습니다.

이제 빌드에 필요한 모든 라이브러리가 포함된 특수 Dockerfile을 저장소 자체에 넣어 보겠습니다. 이렇게 하면 개발자 자신이 반복 가능한 환경을 준비할 수 있으며 호스트에 특정 버전의 Node.JS를 설치하도록 OPS에 요청할 필요가 없습니다.

FROM node:12.10.0-alpine

RUN npm install yarn -g

이 빌드 이미지는 대부분의 Node.JS 애플리케이션에 적합합니다. 예를 들어 Sonar 스캐너가 포함된 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다음을 지정할 수 있습니다.

• 명명 정책에 따른 어셈블리 컨테이너의 이름
• 빌드 컨테이너를 실행하는 데 필요한 인수입니다. 여기서는 현재 디렉터리를 컨테이너 내부 디렉터리로 마운트합니다.

그리고 이미 빌드 단계에서 Docker 빌드 에이전트 내에서 실행할 명령을 나타냅니다. 무엇이든 가능하므로 ansible을 사용하여 애플리케이션 배포도 시작합니다.

아래에서는 간단한 Node.JS 애플리케이션이 구축할 수 있는 일반 Jenkinsfile을 보여주고 싶습니다.

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.

이 글을 작성하면서 플러그인을 사용하여 마스터 노드를 로드하지 않도록 원격 서버에서 에이전트를 사용하는 것에 대한 논의가 있었습니다. 도커 플러그인. 하지만 이에 대해서는 앞으로 이야기하겠습니다.

출처 : habr.com