docker
2.486
Docker Hub에서 사용할 수 있는 Jenkins 지속적 통합 및 전달 서버.
이것은 완전한 기능을 갖춘 Jenkins 서버입니다. https://jenkins.io/.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
참고: 50000 포트 매핑의 역할에 대해서는 아래 에이전트 연결 섹션을 읽어보세요. 참고: "이 Jenkins 인스턴스가 오프라인인 것 같습니다."라는 메시지가 표시되는 경우 DNS 구성 섹션을 읽어보세요.
그러면 작업공간이 /var/jenkins_home 에 저장됩니다. 플러그인 및 구성을 포함하여 모든 Jenkins 데이터가 여기에 있습니다. 이를 관리하고 업그레이드를 위해 다른 컨테이너에 연결할 수 있도록 이를 명시적인 볼륨으로 만들고 싶을 것입니다.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts-jdk17
그러면 호스트 시스템에 'jenkins_home' 도커 볼륨이 자동으로 생성됩니다. Docker 볼륨은 컨테이너가 중지, 시작 또는 삭제된 경우에도 콘텐츠를 유지합니다.
참고: 호스트 시스템의 폴더에서 /var/jenkins_home 으로 바인드 마운트를 사용하지 마십시오. 이렇게 하면 파일 권한 문제가 발생할 수 있습니다(컨테이너 내부에서 사용되는 사용자는 호스트 시스템의 폴더에 대한 권한이 없을 수 있습니다). 실제로 jenkins_home 마운트를 바인딩해야 하는 경우 컨테이너 내부의 jenkins 사용자가 호스트의 디렉터리에 액세스할 수 있는지 확인하거나(jenkins 사용자 - uid 1000) docker run 과 함께 -u some_other_user 매개 변수를 사용하세요.
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 --restart=on-failure jenkins/jenkins:lts-jdk17
그러면 포트 전달 및 볼륨이 추가된 분리 모드에서 Jenkins가 실행됩니다. 첫 번째 로그인 토큰을 확인하려면 'docker log CONTAINER_ID' 명령을 사용하여 로그에 액세스할 수 있습니다. 위 명령의 출력에서 컨테이너의 ID가 반환됩니다.
볼륨에 마운트를 바인딩하는 경우 언제든지 해당 디렉터리(jenkins_home)를 간단히 백업할 수 있습니다.
바인드 마운트를 사용하면 권한 문제가 발생할 수 있으므로 권장되지 않습니다. jenkins_home 디렉터리를 데이터베이스처럼 취급합니다. Docker에서는 일반적으로 데이터베이스를 볼륨에 배치합니다.
볼륨이 컨테이너 내부에 있는 경우 docker cp $ID:/var/jenkins_home 명령을 사용하여 데이터를 추출하거나 다른 옵션을 사용하여 볼륨 데이터가 있는 위치를 찾을 수 있습니다. 일부 OS의 일부 심볼릭 링크는 복사본으로 변환될 수 있습니다(이로 인해 jenkins와 lastStableBuild 링크 등이 혼동될 수 있음).
자세한 내용은 볼륨 사용에 대한 Docker 문서 섹션을 확인하세요.
Groovy 스크립트를 사용하여 Jenkins 내장 노드에서 실행기 수를 정의할 수 있습니다. 기본적으로 실행자는 2개로 설정되어 있지만 이미지를 확장하고 원하는 실행자 수로 변경할 수 있습니다(내장 노드에서는 실행자 0개 권장).
executors.groovy
import jenkins.model.* Jenkins.instance.setNumExecutors(0) // Recommended to not run builds on the built-in node
및 Dockerfile
FROM jenkins/jenkins:lts COPY --chown=jenkins:jenkins executors.groovy /usr/share/jenkins/ref/init.groovy.d/executors.groovy
기본적으로 컨트롤러에서 빌드를 실행할 수 있습니다. Jenkins 프로젝트에서는 컨트롤러에서 실행기를 활성화하지 않을 것을 권장합니다.
인바운드 TCP 연결을 통해 에이전트를 연결하려면 포트를 -p 50000:50000 으로 매핑하세요. 해당 포트는 에이전트를 컨트롤러에 연결할 때 사용됩니다.
SSH(아웃바운드) 빌드 에이전트만 사용하는 경우 컨트롤러에서 연결이 설정되므로 이 포트가 필요하지 않습니다. 웹 소켓을 사용하여 에이전트를 연결하는 경우(Jenkins 2.217부터) TCP 에이전트 포트도 사용되지 않습니다.
일반적으로 시스템 속성을 조정하거나 힙 메모리 설정을 조정하기 위해 Jenkins를 실행하는 JVM을 사용자 정의해야 할 수도 있습니다. 이 목적으로 JAVA_OPTS 또는 JENKINS_JAVA_OPTS 환경 변수를 사용하십시오.
docker run --name myjenkins -p 8080:8080 -p 50000:50000 --restart=on-failure --env JAVA_OPTS=-Dhudson.footerURL=http://mycompany.com jenkins/jenkins:lts-jdk17
Jenkins 컨트롤러용 JVM 옵션은 JENKINS_JAVA_OPTS 통해 설정해야 합니다. 다른 도구도 JAVA_OPTS 환경 변수에 응답할 수 있기 때문입니다.
Jenkins 로깅은 속성 파일과 java.util.logging.config.file Java 속성을 통해 구성할 수 있습니다. 예를 들어:
mkdir data cat > data/log.properties <<EOF handlers=java.util.logging.ConsoleHandler jenkins.level=FINEST java.util.logging.ConsoleHandler.level=FINEST EOF docker run --name myjenkins -p 8080:8080 -p 50000:50000 --restart=on-failure --env JAVA_OPTS="-Djava.util.logging.config.file=/var/jenkins_home/log.properties" -v `pwd`/data:/var/jenkins_home jenkins/jenkins:lts-jdk17
접두사(예: mysite.com/jenkins)를 사용하여 역방향 프록시 뒤에 Jenkins를 설치하려면 환경 변수 JENKINS_OPTS="--prefix=/jenkins" 추가한 다음 아래 절차에 따라 역방향 프록시를 구성해야 합니다. Apache 또는 Nginx가 있는지 여부에 따라 다릅니다.
아파치
엔진스
"이 Jenkins 인스턴스는 오프라인인 것 같습니다."라는 메시지가 나타나는 경우 처음 시작할 때 나타나고 컨테이너 로그에 java.net.UnknownHostException: updates.jenkins.io 와 같은 줄이 표시되면 컨테이너에 DNS 이름을 확인하는 데 문제가 있을 수 있습니다.
잠재적으로 문제를 해결하려면 DNS 서버(예: Cloudflare의 1.1.1.1, Google의 8.8.8.8 또는 기타 DNS 서버)를 지정하는 컨테이너를 시작하세요.
docker run -p 8080:8080 -p 50000:50000 --restart=on-failure --dns 1.1.1.1 --dns 8.8.8.8 jenkins/jenkins:lts-jdk17
Jenkins 이미지를 실행하는 docker에 전달하는 인수는 jenkins 실행 프로그램에 전달되므로 예를 들어 다음을 실행할 수 있습니다.
docker run jenkins/jenkins:lts-jdk17 --version
실행 가능한 전쟁에서 Jenkins를 실행할 때와 마찬가지로 Jenkins 버전이 표시됩니다.
JENKINS_OPTS 를 통해 Jenkins 인수를 정의할 수도 있습니다. 이는 파생된 Jenkins 이미지에서 Jenkins 실행기에 대한 인수를 사용자 정의하는 데 유용합니다. 다음 샘플 Dockerfile은 이 옵션을 사용하여 이미지에 포함된 인증서와 함께 HTTPS를 강제로 사용합니다.
FROM jenkins/jenkins:lts-jdk17 COPY --chown=jenkins:jenkins certificate.pfx /var/lib/jenkins/certificate.pfx COPY --chown=jenkins:jenkins https.key /var/lib/jenkins/pk ENV JENKINS_OPTS="--httpPort=-1 --httpsPort=8083 --httpsKeyStore=/var/lib/jenkins/certificate.pfx --httpsKeyStorePassword=Password12" EXPOSE 8083
샘플 Dockerfile에서 JENKINS_SLAVE_AGENT_PORT 정의하여 Jenkins의 기본 에이전트 포트를 변경할 수도 있습니다.
FROM jenkins/jenkins:lts-jdk17 ENV JENKINS_SLAVE_AGENT_PORT=50001
또는 docker에 대한 매개변수로,
docker run --name myjenkins -p 8080:8080 -p 50001:50001 --restart=on-failure --env JENKINS_SLAVE_AGENT_PORT=50001 jenkins/jenkins:lts-jdk17
참고 : 이 환경 변수는 jenkins.model.Jenkins.slaveAgentPort 시스템 속성을 설정하는 데 사용됩니다.
이 속성이 JAVA_OPTS 또는 JENKINS_JAVA_OPTS 에 이미 설정된 경우
JENKINS_SLAVE_AGENT_PORT값은 무시됩니다.
컨테이너를 루트로 실행하고 apt-get을 통해 설치하거나, jenkins 도구 설치 프로그램을 통해 빌드 단계의 일부로 설치하거나, 고유한 Dockerfile을 만들어 사용자 지정할 수 있습니다. 예를 들면 다음과 같습니다.
FROM jenkins/jenkins:lts-jdk17 # if we want to install via apt USER root RUN apt-get update && apt-get install -y ruby make more-thing-here # drop back to the regular jenkins user - good practice USER jenkins
이러한 파생 이미지에서 후크 스크립트나 추가 플러그인을 사용하여 jenkins 인스턴스를 사용자 정의할 수 있습니다. 이를 위해 /usr/share/jenkins/ref 대상 설치에 원하는 기본 JENKINS_HOME 컨텐츠를 정의하는 장소로 사용하십시오.
FROM jenkins/jenkins:lts-jdk17 COPY --chown=jenkins:jenkins custom.groovy /usr/share/jenkins/ref/init.groovy.d/custom.groovy
플러그인 관리자 CLI를 사용하여 종속성과 함께 다운로드할 플러그인 세트를 전달할 수 있습니다. 이 도구는 업데이트 센터에서 다운로드를 수행하며 기본 업데이트 센터에는 인터넷 액세스가 필요합니다.
다운로드하는 동안 CLI는 다음 환경 변수로 정의된 업데이트 센터를 사용합니다.
JENKINS_UC - 기본 업데이트 센터. 이 업데이트 센터는 Jenkins LTS Core 버전에 따라 플러그인 버전을 제공할 수 있습니다. 기본값: https://updates.jenkins.io
JENKINS_UC_EXPERIMENTAL - 실험용 업데이트 센터. 이 센터는 플러그인의 알파 및 베타 버전을 제공합니다. 기본값: https://updates.jenkins.io/experimental
JENKINS_INCREMENTALS_REPO_MIRROR - Incrementals 저장소에서 플러그인을 다운로드하는 데 사용할 Maven 미러를 정의합니다. 기본값: https://repo.jenkins-ci.org/incrementals
JENKINS_UC_DOWNLOAD - 업데이트 센터의 다운로드 URL입니다. 기본값: $JENKINS_UC/download
JENKINS_PLUGIN_INFO - 플러그인 정보의 위치입니다. 기본값: https://updates.jenkins.io/current/plugin-versions.json
이미지의 환경 변수를 재정의할 수 있습니다.
❗ 업데이트 센터 변수를 변경해도 Jenkins 런타임에서 사용되는 업데이트 센터는 변경 되지 않으며 플러그인 관리자 CLI에만 관련됩니다.
Dockerfile 내의 /usr/share/jenkins/ref/plugins/ 에 플러그인 HPI 파일을 복사하여 사전 빌드된 사용자 정의 플러그인을 설치할 수 있습니다.
COPY --chown=jenkins:jenkins path/to/custom.hpi /usr/share/jenkins/ref/plugins/
Dockerfile에서 CLI를 수동으로 실행할 수 있습니다.
jenkins/jenkins:lts-jdk17RUN jenkins-plugin-cli --plugins 파이프라인 모델 정의 github-branch-source:1.8에서
또한 이 플러그인 세트를 포함하는 파일을 전달할 수도 있습니다(줄 바꿈 여부에 관계 없음).
jenkins/jenkins:lts-jdk17COPY --chown=jenkins:jenkins 플러그인.txt /usr/share/jenkins/ref/plugins.txtRUN jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt
jenkins 컨테이너가 시작되면 JENKINS_HOME 에 이 참조 콘텐츠가 있는지 확인하고 필요한 경우 거기에 복사합니다. 이러한 파일은 재정의되지 않으므로 UI에서 일부 플러그인을 업그레이드한 경우 다음 시작 시 되돌려지지 않습니다.
재정의 하려는 경우 참조 파일 이름에 '.override'를 추가하세요. 예를 들어 /usr/share/jenkins/ref/config.xml.override 라는 파일은 JENKINS_HOME의 기존 config.xml 파일을 덮어씁니다.
JENKINS-24986도 참조하세요.
다음은 기존 서버에서 플러그인 목록을 가져오는 예입니다.
JENKINS_HOST=username:[email protected]:port curl -sSL "http://$JENKINS_HOST/pluginManager/api/xml?depth=1&xpath=/*/*/shortName|/*/*/version&wrapper=plugins" | perl -pe 's/.*?<shortName>([w-]+).*?<version>([^<]+)()(</w+>)+/1 2n/g'|sed 's/ /:/'
예제 출력:
cucumber-testresult-plugin:0.8.2 pam-auth:1.1 matrix-project:1.4.1 script-security:1.13 ...
2.x 파생 이미지의 경우 다음을 수행할 수도 있습니다.
RUN echo 2.0 > /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state
이 Jenkins 설치가 완전히 구성되었음을 나타냅니다. 그렇지 않으면 사용자에게 추가 플러그인을 설치하라는 메시지가 표시되며 이는 부적절할 수 있습니다.
Docker 컨테이너 내부의 Jenkins 홈 디렉터리에서 Jenkins 사용자 액세스 로그를 활성화하려면 JENKINS_OPTS 환경 변수 값을 --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/jenkins_home/logs/access_log 로 설정합니다. --accessLoggerClassName=winstone.accesslog.SimpleAccessLogger --simpleAccessLogger.format=combined --simpleAccessLogger.file=/var/jenkins_home/logs/access_log
Docker Hub의 태그에 대한 명명 규칙은 <repository_name>:<tag> 형식을 따릅니다. 여기서 저장소 이름은 jenkins/jenkins이고 태그는 이미지 버전을 지정합니다. LTS 및 최신 버전의 경우 태그는 각각 lts 및 latest 입니다.
이러한 태그를 사용하여 Docker Hub에서 해당 Jenkins 이미지를 가져와 시스템에서 실행할 수 있습니다. 예를 들어 Jenkins 이미지의 LTS 버전을 가져오려면 다음 명령을 사용합니다. docker pull jenkins/jenkins:lts
Jenkins와 함께 Docker Compose를 사용하려면 Jenkins 인스턴스와 이에 의존하는 기타 서비스를 포함하는 docker-compose.yml 파일을 정의할 수 있습니다. 예를 들어 다음 docker-compose.yml 파일은 Jenkins 컨트롤러와 Jenkins SSH 에이전트를 정의합니다.
서비스: 젠킨스:이미지: 젠킨스/젠킨스:ltsports:
- "8080:8080" 볼륨:
- 젠킨스_홈:/var/jenkins_home
ssh-agent:이미지: 젠킨스/ssh-agent볼륨: jenkins_home: 이 docker-compose.yml 파일은 두 개의 컨테이너를 생성합니다. 하나는 Jenkins용이고 다른 하나는 Jenkins SSH 에이전트용입니다.
Jenkins 컨테이너는 jenkins/jenkins:lts 이미지를 기반으로 하며 포트 8080에서 Jenkins 웹 인터페이스를 노출합니다. jenkins_home 볼륨은 Docker가 생성하고 관리하는 명명된 볼륨입니다.
Jenkins 컨테이너의 /var/jenkins_home 에 마운트되며 Jenkins 구성 및 데이터가 유지됩니다.
ssh-agent 컨테이너는 jenkins/ssh-agent 이미지를 기반으로 하며 SSH 서버를 실행하여 Jenkins SSH Build Agent를 실행합니다.
docker-compose.yml 파일에 정의된 Jenkins 인스턴스와 기타 서비스를 시작하려면 docker compose up -d 실행하세요.
그러면 시스템에 아직 필요한 이미지가 없는 경우 Docker Hub에서 필요한 이미지를 가져오고 백그라운드에서 서비스가 시작됩니다.
그런 다음 호스트 시스템의 http://localhost:8080 에서 Jenkins 웹 인터페이스에 액세스하여 Jenkins 인스턴스(여기서 localhost Docker 엔진에 의해 게시된 포트를 가리킴)를 구성하고 관리할 수 있습니다.
참고: "이 Jenkins 인스턴스가 오프라인인 것 같습니다."라는 메시지가 표시되는 경우 DNS 구성 섹션을 읽어보세요. 이 경우 yaml에 DNS 구성을 추가합니다.
서비스: jenkins:# ... 기타 configdns:
- 1.1.1.1 - 8.8.8.8# ... 기타 구성플러그인 설치 관리자 도구는 플러그인 파일 업데이트를 지원합니다.
예제 명령:
JENKINS_IMAGE=젠킨스/젠킨스:lts-jdk17
docker run -it ${JENKINS_IMAGE} bash -c "stty -onlcr && jenkins-plugin-cli -f /usr/share/jenkins/ref/plugins.txt --available-updates --output txt" >plugins2.txt
mv 플러그인2.txt 플러그인.txt필요한 모든 데이터는 /var/jenkins_home 디렉토리에 있으므로 이를 관리하는 방법에 따라 업그레이드 방법에 따라 달라집니다. 일반적으로 복사한 다음 이미지를 다시 "docker pull"하면 최신 LTS를 갖게 됩니다. 그런 다음 해당 데이터(/var/jenkins_home)를 가리키는 -v로 시작할 수 있으며 모든 것이 다음과 같습니다. 그것을 떠났다.
언제나 그렇듯 - 도커 구동 방법, 특히 볼륨 처리 방법을 알고 있는지 확인하세요!
Jenkins 홈 디렉터리를 볼륨이라는 Docker에 탑재하면 업그레이드는 docker pull 만으로 구성됩니다.
특히 사용자가 Jenkins 컨테이너의 역방향 프록시로 병렬 nginx/apache 컨테이너를 실행하는 경우 docker compose 사용하는 것이 좋습니다.
기본적으로 플러그인은 수동으로 업그레이드되지 않았고 Docker 이미지의 버전이 컨테이너의 버전보다 최신인 경우 업그레이드됩니다. Docker 이미지로 설치된 버전은 마커 파일을 통해 추적됩니다.
수동으로 업그레이드된 플러그인을 강제로 업그레이드하려면 -e PLUGINS_FORCE_UPGRADE=true 로 docker 이미지를 실행하세요.
마커 파일을 작성하지 않은 Docker 이미지에서 업그레이드할 때 기본 동작은 기존 플러그인을 그대로 두는 것입니다. 마커 없이 기존 플러그인을 업그레이드하려면 -e TRY_UPGRADE_IF_NO_MARKER=true 로 docker 이미지를 실행할 수 있습니다. 그러면 Docker 이미지에서 제공하는 버전이 최신 버전인 경우 플러그인이 업그레이드됩니다.
이 저장소에 수정 사항을 제공하려면 전용 문서를 참조하세요.
본 Docker 이미지의 보안에 관한 내용은 전용 문서를 참고하시기 바랍니다.
우리는 Gitter에 있습니다, https://gitter.im/jenkinsci/docker
