웹사이트 검색

CentOS 7에서 지속적인 개발 통합을 위해 Jenkins를 설정하는 방법

소개

병합 코드. 릴리스 조정. 빌드 상태 결정. 업데이트 유지. 단어 자체가 두통을 위협할 정도로 이러한 프로세스의 좌절감을 잘 알고 있다면 Jenkins CI를 살펴보는 것이 좋습니다.

모든 프로젝트, 특히 여러 팀원이 동시에 개발한 프로젝트와 많은 기능, 구성 요소, 언어 및 환경을 통합할 수 있는 프로젝트를 유지 관리하는 것은 기쁠 때에도 힘든 일이며 최악의 경우에도 살아남기 위해서는 초인적인 위업이 필요합니다.

Jenkins가 도와드리겠습니다. 근본적으로 지속적인 통합을 위한 솔루션(예: 모든 코드를 지속적으로 하나의 중앙 빌드로 병합하는 방법)인 Jenkins는 프로젝트 운영의 본부 역할을 합니다. 모든 측면에서 프로젝트를 모니터링, 규제, 비교, 병합 및 유지할 수 있습니다.

본질적으로 Jenkins는 자동화된 통합과 외부 빌드 모니터링이라는 두 가지 작업을 수행합니다. 즉, 코드를 유지 관리하는 프로세스를 크게 단순화하고 빌드 품질을 지치지 않고 면밀히 주시하여 일부 개발자가 코드가 준비되기 전에 코드를 병합할 때 불쾌한 놀라움으로 끝나지 않도록 할 수 있습니다. .

핵심으로 들어가서 Jenkins가 어떻게 생겼고 어떻게 사용하는지 정확히 알아봅시다.

전제 조건

이 자습서를 따르려면 다음이 필요합니다.

  • CentOS 7 드롭릿
  • Sudo 권한이 있는 루트가 아닌 사용자(Ubuntu 및 CentOS에서 Sudoers 파일을 편집하는 방법에서 설정 방법을 설명함).

이 자습서의 모든 명령은 루트가 아닌 사용자로 실행해야 합니다. 명령에 루트 액세스가 필요한 경우 앞에 sudo가 옵니다.

시스템별 패키지와 WAR 파일 비교

Jenkins가 무엇인지 알았으니 이제 Jenkins가 어떻게 배포되는지 이해해야 합니다. Jenkins는 Java에서 실행되며 WAR 파일로 제공됩니다. 이는 웹 애플리케이션을 구성하고 서버에서 실행되도록 의도된 관련 콘텐츠 모음입니다. 그러나 Jenkins 개발자는 Jenkins가 제어된 서비스로 실행될 수 있도록 하는 여러 시스템별 패키지를 통해 사용 편의성을 친절하게 확장합니다.

Jenkins 패키지는 CentOS 운영 체제를 포함하는 Red Hat 배포 제품군에 사용할 수 있습니다. 그러나 특히 CentOS 7은 까다로운 품종이므로 다른 접근 방식이 필요합니다. 다른 Red Hat 기반 OS, 심지어 다른 CentOS 버전에서도 작동하는 작업은 CentOS 7에서 다르게 작동하는 경향이 있으며 이로 인해 발생하는 잠재적인 오류는 디버그하기 어려울 수 있습니다. Jenkins 패키지는 Red Hat의 일반적인 패키지이기 때문에 CentOS용으로 차별화된 것이 아니라 다른 OS에 비해 문제가 발생할 가능성이 높습니다. 이러한 이유로 이 패키지를 통해 Jenkins를 실행하지 않습니다. 그러면 Java를 통해 실행되는 WAR 파일이 남게 됩니다. 이 파일은 훨씬 덜 편리하므로 Java를 통해 수동으로 시작하고 중지해야 합니다.

다행히도 이 문제를 해결할 방법이 있으며 패키지 없이도 CentOS와 협력하여 Jenkins를 서비스처럼 취급할 수 있습니다.

1단계 — Jenkins 설치

CentOS에 Jenkins를 설치하는 기본 방법에는 리포지토리 또는 WAR 파일을 통한 두 가지 기본 방법이 있습니다. 리포지토리에서 설치하는 것이 선호되는 방법이며 먼저 설명하겠습니다.

Jenkins(두 방법 모두)를 실행하려면 Java가 필요하므로 서버에 아직 Java가 없는 경우 다음을 사용하여 설치하십시오.

  1. sudo yum -y install java

일반적으로 서비스나 도구가 필요하지만 어떤 패키지가 제공하는지 확실하지 않은 경우 다음을 실행하여 언제든지 확인할 수 있습니다.

  1. yum whatprovides service

여기서 service는 필요한 서비스 또는 도구의 이름입니다.

저장소에서 설치

이제 다음을 실행하여 Red Hat 리포지토리에서 Jenkins를 다운로드합니다.

  1. sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo

wget 도구는 "O\ 플래그(0이 아닌 대문자 'O'임) 뒤에 지정된 파일 이름으로 파일을 다운로드합니다.

그런 다음 패키지 관리자 RPM을 사용하여 확인 키를 가져옵니다.

  1. sudo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key

마지막으로 다음을 실행하여 Jenkins를 설치합니다.

  1. sudo yum install jenkins

그게 다야! 이제 Jenkins를 서비스로 시작할 수 있습니다.

  1. sudo systemctl start jenkins.service

서비스가 시작되면 상태를 확인할 수 있습니다.

  1. sudo systemctl status jenkins.service

이렇게 하면 프로세스가 어떻게 시작되고 무엇을 하는지에 대한 많은 정보와 함께 상당히 긴 정보를 얻을 수 있지만 모든 것이 잘 진행되면 다음과 유사한 두 줄이 표시되어야 합니다.

Loaded: loaded (/etc/systemd/system/jenkins.service; disabled)
Active: active (running) since Tue 2015-12-29 00:00:16 EST; 17s ago

이는 Jenkins 서비스가 시작을 완료하고 실행 중임을 의미합니다. http://ip-of-your-machine:8080에서 이전과 같이 웹 인터페이스를 방문하여 이를 확인할 수 있습니다.

마찬가지로 서비스를 중지할 수 있습니다.

  1. sudo systemctl stop jenkins.service

또는 다시 시작하십시오.

  1. sudo systemctl restart jenkins.service

systemctl을 사용하여 서비스를 관리하는 방법에 대한 자세한 내용은 Systemctl을 사용하여 Systemd 서비스 및 단위를 관리하는 방법 문서에서 찾을 수 있습니다.

WAR 파일에서 설치

어떤 이유로든 리포지토리를 통해 Jenkins를 설치하지 않기로 선택한 경우 약간 더 많은 작업이 필요하지만 WAR 파일을 사용하여 동일한 결과를 얻을 수 있습니다.

먼저 Jenkins WAR 파일을 서버에 다운로드하고 기본이 번거로움 없이 제대로 작동하는지 실기 없이 실행해 보겠습니다.

Jenkins의 최신 버전은 언제든지 Jenkins 미러에서 사용할 수 있습니다. 원하는 도구를 사용하여 이 파일을 다운로드할 수 있습니다. 다음 방법은 wget이라는 명령줄 도구를 사용합니다.

  1. wget http://mirrors.jenkins-ci.org/war/latest/jenkins.war

준비가 되면 Java를 통해 Jenkins를 시작합니다.

  1. java -jar jenkins.war

Jenkins가 실행을 시작했음을 나타내는 출력이 콘솔에 표시되어야 합니다.

...
INFO: Jenkins is fully up and running
...

이제 브라우저를 통해 인터페이스에 액세스할 수 있습니다(http://ip-of-your-machine:8080).

Jenkins가 성공적으로 실행되는지 확인했으면 프로세스를 종료하여 다음 단계에서 설명하는 대로 서비스로 실행할 수 있도록 변경할 수 있습니다. 실행 중인 포그라운드 프로세스를 종료하려면 CTRL-C를 누르십시오.

2단계 - Jenkins를 서비스로 실행

이전 섹션에서 리포지토리를 통해 Jenkins를 설치하지 않고 대신 WAR 파일을 사용했다면 아직 Jenkins를 표준 서비스처럼 사용할 수 없습니다. 저장소를 사용한 경우 이 단계를 건너뜁니다.

Jenkins를 다음과 같이 구성하면 여전히 Java를 통해 실행되지만 서비스처럼 취급하여 시작 및 중지하고 백그라운드에서 쉽게 실행되도록 할 수 있습니다. 서비스는 기본적으로 래퍼로 작동합니다.

먼저 다운로드한 WAR 파일이 장기간 저장 및 사용하기에 편리한 위치에 있는지 확인하십시오.

  1. sudo cp jenkins.war /usr/local/bin/jenkins.war

그런 다음 /etc/systemd/system/ 디렉토리로 이동하여 jenkins.service라는 새 파일을 만듭니다. 다음 데모에서는 나노 편집기를 사용하지만 당연히 원하는 편집 도구를 사용할 수 있습니다.

  1. cd /etc/systemd/system/

  2. sudo nano jenkins.service

이제 새 jenkins.service 파일에 다음 줄을 추가합니다. 잠시 후에 이 라인이 수행하는 작업을 정확히 살펴보겠습니다.

[Unit]
Description=Jenkins Service
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/bin/java -jar /usr/local/bin/jenkins.war
Restart=on-abort

[Install]
WantedBy=multi-user.target

이전에 구성 파일(INI 파일 또는 이와 유사한 파일)을 본 적이 있다면 여기에서 사용되는 구조를 인식할 수 있습니다. 괄호로 묶인 텍스트는 섹션 제목을 나타냅니다. 즉, 예를 들어 [Service]는 "Service\라는 섹션을 선언하고 그 아래의 모든 할당에는 시스템이 섹션 헤더를 찾고 관련시키는 방법을 알 수 있는 관련 정보가 포함되어 있습니다. .

여기에 포함된 구성 파일은 일반적으로 텍스트 파일입니다. 즉, 컴퓨터에 본질적인 의미가 없습니다. 오히려 텍스트 파일은 일부 프로세스에 의해 구문 분석되고 해당 프로세스는 제목 및 기타 정보를 사용하여 길을 찾습니다. 이러한 이유로 주어진 구성 파일을 읽는 프로그램이 모든 것이 의미하는 바를 이해할 수 있는 한 주어진 구성 파일이 배치되는 방식은 기술적으로 관련이 없습니다.

첫 번째 섹션인 Unit에는 두 개의 구성 지시문만 포함되어 있습니다. 첫 번째는 단순히 이름입니다. 원하는 이름이 될 수 있지만 이상적으로는 새 프로세스를 고유하게 식별하는 이름이어야 합니다. 두 번째 지시문은 현재 서비스를 시작하는 데 필요한 서비스(있는 경우)를 명시합니다.

다음 섹션에서 Type 지시문을 사용하면 이 서비스가 사용할 시작 유형을 선택할 수 있습니다. 값 simple은 나중 지시문 ExecStart에 기록된 프로세스가 생성되는 서비스의 기본 프로세스임을 나타냅니다. 실제로 type은 불필요합니다. 유형이 지정되지 않은 경우 simple이 가정되기 때문입니다. 그러나 명확성을 위해 그대로 둡니다.

사용자는 이 프로세스를 제어할 수 있는 사용자를 지정하고 재시작은 이 경우 프로세스가 종료되지만 종료 코드가 오류를 암시하는 경우 서비스가 다시 시작합니다. 이는 예상치 못한 충돌이 발생할 경우 서비스의 연속성을 유지하는 데 유용합니다.

언급한 바와 같이 ExecStart는 서비스의 기본 작업이 될 프로세스를 나타내는 지시어입니다. 이 지시문은 Jenkins의 기본 래퍼를 나타냅니다. 서비스는 포그라운드 프로세스로 처리하지 않고 Java를 통해 WAR을 실행합니다.

마지막으로 Install 섹션에서 multi-user.target은 CentOS 7 이전의 런레벨이라고 하는 대상을 나타냅니다. 이는 시스템에 어떤 리소스를 제공해야 하는지 알려줍니다. 이 서비스와 사용자가 요구하는 강도의 양.

파일이 생성되고 저장되면 새로운 Jenkins 서비스를 시작할 수 있습니다!

준비가 되면 다음을 실행합니다.

  1. sudo systemctl daemon-reload

이렇게 하면 이 유닛에 대한 변경 사항이 적용됩니다(실제로는 변경된 모든 유닛에 변경 사항이 적용됩니다).

이제 Jenkins를 서비스로 시작할 수 있습니다.

  1. sudo systemctl start jenkins.service

서비스가 시작되면 상태를 확인할 수 있습니다.

  1. sudo systemctl status jenkins.service

이렇게 하면 프로세스가 어떻게 시작되고 무엇을 하는지에 대한 많은 정보와 함께 상당히 긴 정보를 얻을 수 있지만 모든 것이 잘 진행되면 다음과 유사한 두 줄이 표시되어야 합니다.

Loaded: loaded (/etc/systemd/system/jenkins.service; disabled)
Active: active (running) since Tue 2015-12-29 00:00:16 EST; 17s ago

이는 Jenkins 서비스가 시작을 완료하고 실행 중임을 의미합니다. http://ip-of-your-machine:8080에서 이전과 같이 웹 인터페이스를 방문하여 이를 확인할 수 있습니다.

마찬가지로 서비스를 중지할 수 있습니다.

  1. sudo systemctl stop jenkins.service

또는 다시 시작하십시오.

  1. sudo systemctl restart jenkins.service

systemctl을 사용하여 서비스를 관리하는 방법에 대한 자세한 내용은 Systemctl을 사용하여 Systemd 서비스 및 단위를 관리하는 방법 문서에서 찾을 수 있습니다.

3단계 - 사용자 생성

Jenkins가 원활하게 실행되면 좋은 보안을 설정하는 것이 다음 단계입니다. 여기서부터 귀하의 정확한 행동은 주로 Jenkins에 대한 귀하의 목적에 따라 달라집니다. 그러나 다음은 Jenkins를 가장 잘 설정하고 사용할 수 있는 방법에 대한 일반적인 지침과 이를 위한 몇 가지 예입니다.

Jenkins는 액세스 제어 및 사용자 작업 정의에 유용한 보안 및 역할 관리를 위한 설정을 제공합니다. 이러한 개념을 소개하기 위해 간단히 살펴보겠습니다. 이러한 설정을 얻으려면 서비스가 실행된 후 브라우저를 통해 Jenkins 인터페이스로 돌아갑니다(http://ip-of-your-machine:8080). 왼쪽에 메뉴가 표시됩니다. 그 메뉴에서 Jenkins 관리를 선택합니다. 이렇게 하면 다양한 사용자 지정 옵션이 포함된 페이지로 이동합니다. 상단에 경고가 표시될 수도 있습니다. 보안되지 않은 Jenkins는 네트워크의 모든 사람이 사용자를 대신하여 프로세스를 시작할 수 있도록 허용합니다. 오용을 방지하려면 최소한 인증을 활성화하는 것이 좋습니다. 이것은 시스템에 일부 보안 요소를 도입하도록 하는 Jenkins의 지시입니다.

여기에서 수행할 첫 번째 단계는 Jenkins 관리 페이지의 링크 목록 상단 근처에 있는 전역 보안 구성으로 이동하는 것입니다. 이 목적을 위한 옵션 그룹을 불러오려면 보안 사용 옵션 상자를 선택하십시오. Jenkins에서 보안을 구성하는 방법에는 여러 가지가 있습니다. Jenkins 사용 설명서의 표준 보안 설정 섹션에서 자세한 설명을 읽을 수 있습니다.

이러한 옵션 중 가장 간단하고 오늘 소개할 옵션은 Jenkins가 자체 데이터베이스를 사용하여 사용자 구성을 저장하는 것입니다. 확인란에 플래그를 지정했을 때 나타난 액세스 제어 섹션에서 Jenkins의 자체 사용자 데이터베이스를 선택합니다. 간단히 말해서 다른 옵션은 Jenkins를 기존 Unix 사용자 및 그룹에 연결하거나 조직 전체 로그인(LDAP 옵션)을 사용하거나 Java 서블릿이 액세스를 관리하도록 허용하는 것입니다. 플러그인을 통해 다른 옵션을 추가할 수 있습니다(플러그인에 대해서는 잠시 후에 설명하겠습니다).

신규 사용자의 가입을 허용할지 여부는 주로 자신의 필요에 따라 다릅니다. 그러나 일반적으로 액세스를 제한하고 사용자가 원하는 대로 가입하도록 허용하면 잠재적으로 위험할 수 있는 개방성을 허용할 수 있습니다. 이를 제한하려면 사용자가 가입하도록 허용이라고 표시된 확인란을 선택 취소합니다. 이 설정이 해제되면 관리자만 새 계정을 만들 수 있습니다. 잠시 후에 생성할 사용자에 대한 관리 권한을 제공하고 새 사용자를 추가하는 방법에 대해서도 자세히 살펴보겠습니다.

인증에서 매트릭스 기반 보안 옵션을 선택합니다. 이를 통해 복잡한 설정에 의존하지 않고 컨트롤을 미세 조정할 수 있습니다. Anonymous라는 사용자가 이미 있음을 알 수 있습니다. 익명 사용자는 로그인하지 않은 경우에도 어디서나 모든 사람을 의미하므로 기본적으로 익명 사용자는 능력이 없습니다. 이것은 Jenkins 인스턴스의 초기 설정이므로 이 사용자에게 전체 권한을 부여해야 합니다. 현재 익명 이외의 사용자가 없으며 로그인하지 않았으므로 익명 권한을 끄면 사실상 Jenkins 액세스가 차단됩니다. 조금도.

익명 행 오른쪽에 있는 작은 버튼을 사용하여 모든 권한을 선택합니다. 그런 다음 사용자/그룹을 추가 입력 필드를 사용하여 권한을 추가할 새 사용자를 지정합니다. 이것은 실제로 사용자를 생성하는 것이 아니라 곧 생성할 사용자에 대한 권한을 지정한다는 점에 유의하십시오.

일반적으로 먼저 새 사용자를 만든 다음 양식의 이 부분에서 해당 사용자에 대한 권한을 지정합니다. 아직 사용자가 없으므로 권한을 설정한 다음 사용자를 생성합니다.

사용자 이름을 입력하고 추가를 누릅니다. 알려진 버그로 인해 사용자 이름을 소문자로 유지하는 것이 좋습니다. 익명 사용자에 대해 수행한 것과 동일한 방식으로 새 사용자에게 모든 권한을 부여합니다. 이것은 기본적으로 새 관리자를 설정합니다.

완료되면 적용을 누른 다음 저장을 누릅니다.

새 계정을 만들 수 있는 가입 페이지로 자동 이동됩니다. 생성한 계정의 사용자 이름은 이전에 지정한 권한과 일치해야 합니다.

완료하면 자동으로 로그인됩니다.

보안 페이지(Jenkins 관리 -> 글로벌 보안 구성)로 돌아가서 보안 매트릭스까지 아래로 스크롤합니다. 관리 사용자를 만들었으므로 이제 익명 사용자에 대한 권한을 제한할 수 있습니다. 익명 행의 모든 권한을 선택 취소한 다음 적용 및 저장을 클릭합니다. 이제 새 사용자는 Jenkins에 액세스할 수 있는 유일한 사용자가 됩니다.

이전에 자동 가입을 해제한 경우 추가 새 사용자를 수동으로 생성해야 할 수 있습니다. 방법은 다음과 같습니다.

Jenkins 관리 페이지로 돌아가서 맨 아래로 스크롤하고 사용자 관리를 클릭합니다. 왼쪽에는 링크가 있는 사이드바가 표시됩니다. 사용자 생성을 클릭합니다. 첫 번째 사용자를 생성한 것과 동일한 방법으로 새 사용자에 대한 정보를 입력하고 가입을 클릭합니다. 이제 새 사용자가 포함된 사용자 목록으로 리디렉션됩니다. 이 사용자에게는 권한이 없으므로 권한 프로세스를 반복하여 글로벌 보안 구성으로 이동하고 사용자/그룹을 추가하여 필드를 사용하여 매트릭스에 행을 추가하고 권한을 지정하고 적용 및 저장을 클릭해야 합니다. 단순화를 위해 생성할 사용자가 여러 명인 경우 권한 추가로 이동하기 전에 모두 생성하십시오.

새 사용자를 생성할 때 제한이 주요 보안 자산이 될 수 있음을 염두에 두십시오. Jenkins 사용 설명서의 매트릭스 기반 보안 섹션에서 매트릭스 기반 보안의 특정 기능에 대해 자세히 알아볼 수 있습니다.

일반적으로 다음 단계는 사용자에게 역할을 할당하여 정확한 능력을 제어하는 것입니다. 이 기사에서 자세히 다루지는 않겠지만 이 주제에 대한 좋은 기사입니다. 역할을 할당한 후 변경 사항을 저장해야 합니다.

4단계 - 플러그인 설치

Jenkins가 설치되고 최소한으로 구성되고 합리적으로 보호되면 이제 필요에 맞게 만들 차례입니다. Jenkins를 처음 설치할 때 알 수 있듯이 Jenkins에는 상대적으로 기능이 거의 없습니다. 실제로 Jenkins는 많은 소프트웨어 개발자의 신조를 대표합니다. 한 가지만 잘 수행하십시오. Jenkins는 소프트웨어 프로젝트의 중개자 역할을 하여 \한 가지 일\을 하고 플러그인을 제공하여 \잘 수행\합니다.

플러그인은 Jenkins가 다양한 외부 소프트웨어와 상호 작용하거나 타고난 능력을 확장할 수 있게 해주는 추가 기능입니다. Jenkins 설정의 많은 영역과 마찬가지로 설치하는 정확한 플러그인은 프로젝트에 따라 크게 달라집니다.

Jenkins의 기본 왼쪽 메뉴에서 Jenkins 관리 -> 플러그인 관리를 클릭합니다. 방문하는 페이지에는 이미 설치되어 있지만 업데이트가 필요한 플러그인이 표시됩니다. 업데이트할 플러그인을 선택하고 하단에 있는 버튼을 클릭하여 쉽게 수행할 수 있습니다.

이 페이지에서 사용 가능을 클릭하면 사용 가능한 플러그인의 거대한 목록으로 이동합니다. 분명히 가능한 모든 플러그인을 설치하고 싶지는 않을 것이므로 다음 질문은 필요한 플러그인을 선택하는 방법입니다.

언급했듯이 이 문제에 대한 귀하의 선택은 귀하의 필요와 목표에 따라 달라집니다. 다행스럽게도 Jenkins wiki는 주제별로 멋진 플러그인 목록을 제공합니다.

이 목록은 정독할 가치가 있지만 프로젝트에 관계없이 포함해야 할 몇 가지 플러그인이 있습니다. 다음은 몇 가지입니다. 일부는 일반적이고 일부는 구체적입니다.

  1. 소스 제어 Git, SVN 및 Team Foundation Server는 보다 일반적인 소스 제어 시스템 중 일부입니다. 이 세 가지 모두 Jenkins 목록에 플러그인이 있으며 덜 일반적인 시스템을 위한 플러그인도 있습니다. 소스 컨트롤이 무엇인지 모른다면 소스 컨트롤에 대해 제대로 배우고 프로젝트에 통합하기 시작해야 합니다. Jenkins가 이를 통해 빌드를 실행하고 테스트를 제어할 수 있도록 소스 제어 시스템용 플러그인을 설치해야 합니다.\n
  2. 아티팩트 복사 이 플러그인을 사용하면 프로젝트 간에 구성 요소를 복사할 수 있으므로 진정한 종속성 관리자가 없는 경우 유사한 프로젝트를 설정하는 수고를 덜 수 있습니다.\n
  3. 스로틀 동시 빌드 공유 리소스 등으로 인해 충돌이 발생할 수 있는 여러 빌드를 실행 중인 경우 이 문제를 쉽게 완화할 수 있습니다.\n
  4. 종속성 그래프 뷰어\n프로젝트 종속성을 그래픽으로 표현하는 멋진 플러그인입니다.\n
  5. Jenkins 디스크 사용량 Jenkins는 상당히 가벼울 수 있지만 통합되는 프로젝트에 대해 항상 동일하다고 말할 수는 없습니다. 이 플러그인을 사용하면 작업이 소비하는 컴퓨팅 리소스의 양을 식별할 수 있습니다.\n
  6. 빌드 도구 프로젝트가 큰 경우 Maven 또는 Ant와 같은 빌드 관리자를 사용할 수 있습니다. Jenkins는 기본 기능에 연결하고 개별 빌드 단계, 프로젝션 구성 및 빌드의 기타 여러 측면에 대한 제어를 추가하기 위해 이들 중 많은 플러그인을 제공합니다.\n
  7. 보고 Jenkins는 자체 보고서를 제공하지만 이 기능을 여러 보고 도구로 확장할 수 있습니다.\n
  8. 추가 인증 보안을 위한 기본 Jenkins 기능이 적합하지 않은 경우 Google 로그인에서 Active Directory, 기존 보안의 간단한 수정에 이르기까지 이를 확장할 수 있는 많은 플러그인이 있습니다.\n

일반적으로 프로젝트에 특정 도구가 필요한 경우 위키의 플러그인 목록 페이지에서 해당 도구의 이름이나 해당 기능에 관한 키워드를 검색하세요. 이러한 플러그인이 있을 가능성이 높으며 이것이 효율적으로 찾을 수 있는 방법입니다.

사용 가능 탭에서 설치하려는 플러그인을 선택했으면 지금 다운로드라고 표시된 버튼을 클릭하고 다시 시작한 후 설치합니다.

이제 Jenkins가 원하는 방식으로 실행되고 있으므로 Jenkins를 사용하여 프로젝트 통합을 강화할 수 있습니다. Jenkins의 기능은 도메인 내에서 거의 무한하지만 다음 예는 Jenkins가 할 수 있는 범위와 Jenkins 작업을 시작하는 방법의 시작을 모두 보여 주는 역할을 해야 합니다.

5단계 - 간단한 프로젝트 만들기

Jenkins에서 얻을 수 있는 흥미로운 용도가 많이 있으며 설정을 가지고 놀아보는 것도 유익할 수 있습니다. 그러나 시작하려면 기본 작업을 설정하는 방법을 이해하는 것이 도움이 됩니다. 간단한 작업을 설정하고 실행하는 방법을 알아보려면 이 섹션의 예를 따르십시오.

Jenkins 인터페이스 홈에서 새 항목을 선택합니다. 이름을 입력하고 자유형 프로젝트를 선택합니다.

다음 페이지는 작업 구성을 지정하는 곳입니다. 금방 알 수 있듯이 새 프로젝트를 만들 때 사용할 수 있는 여러 가지 설정이 있습니다. 일반적으로 더 중요한 제어 중 하나는 소스 리포지토리에 연결하는 것입니다. 이 소개 예제의 목적을 위해 해당 단계를 건너뛸 것입니다.

이 구성 페이지에는 스크립트 실행과 같은 추가 작업을 수행하기 위해 빌드 단계를 추가하는 옵션도 있습니다.

이렇게 하면 필요한 명령을 추가할 수 있는 텍스트 상자가 제공됩니다. 이를 사용하여 서버 유지 관리, 버전 관리, 시스템 설정 읽기 등과 같은 다양한 작업을 실행합니다.

이 섹션을 사용하여 스크립트를 실행합니다. 다시 말하지만 데모 목적으로 매우 간단하게 유지하겠습니다.

원하는 경우 후속 빌드 단계도 추가할 수 있습니다. 세그먼트 또는 개별 스크립트가 실패하면 전체 빌드가 실패합니다.

결과를 자신에게 이메일로 보내는 것과 같이 실행할 빌드 후 작업을 선택할 수도 있습니다.

프로젝트를 저장하면 프로젝트 개요 페이지로 이동합니다. 여기에서 빌드된 이력을 포함하여 프로젝트에 대한 정보를 볼 수 있지만, 이것이 완전히 새로운 프로젝트이기 때문에 현재로서는 해당 정보가 없습니다.

빌드를 시작하려면 왼쪽에서 지금 빌드를 클릭하십시오. 작동 중임을 나타내는 빌드 기록 변경이 잠시 표시됩니다. 완료되면 상태 아이콘이 다시 변경되어 결과를 간결한 형식으로 표시합니다.

자세한 정보를 보려면 빌드 기록 영역에서 해당 빌드를 클릭하면 빌드 정보 개요가 있는 페이지로 이동합니다.

이 페이지의 콘솔 출력 링크는 작업 결과를 자세히 검사하는 데 특히 유용합니다. 빌드 중에 수행된 작업에 대한 정보를 제공하고 모든 콘솔 출력을 표시합니다. 특히 실패한 빌드 후에는 이 위치를 살펴보는 것이 유용할 수 있습니다.

Jenkins 홈으로 돌아가면 상태(이 경우 하나만 있음)를 포함하여 모든 프로젝트 및 관련 정보에 대한 개요가 표시됩니다.

상태는 날씨 아이콘(위의 홈 페이지 대시보드에 있음)과 색상 공(아래에 표시된 개별 프로젝트 페이지에 있음)의 두 가지 방식으로 표시됩니다. 날씨 아이콘은 하나의 이미지에 여러 빌드 기록을 표시하므로 특히 유용합니다.

위의 이미지에서 일부 최근 빌드가 성공했고 일부는 실패했음을 나타내는 구름을 볼 수 있습니다. 모두 성공했다면 태양의 이미지가 보일 것입니다. 모든 빌드가 최근에 실패한 경우 나쁜 날씨 아이콘이 표시됩니다.

이러한 상태에는 호버에 대한 설명이 포함된 해당 도구 설명이 있으며 차트의 다른 정보와 함께 개요에서 필요한 대부분의 내용을 다룹니다.

여기에서 (지금 빌드)를 클릭하여 프로젝트를 다시 빌드할 수도 있습니다.

물론 전체 규모의 프로젝트 설정을 구현하려면 몇 가지 추가 단계와 약간의 미세 조정이 필요하지만 많은 노력 없이도 프로젝트에 매우 유용하고 매우 실용적인 모니터 및 컨트롤을 설정할 수 있다는 것은 분명합니다. Jenkins를 탐색하면 귀중한 도구임을 금방 알게 될 것입니다.

결론

다른 자습서, 기사 및 비디오를 찾는 것은 매우 가치가 있습니다. 거기에는 많은 정보가 있으며 풍부한 정보를 통해 Jenkins와 프로젝트 통합을 설정하는 것이 사실상 산들바람이 됩니다. Jenkins 팀이 주최하는 자습서는 살펴볼 가치가 있습니다.

특히 기본과 본격적인 프로젝트 사이의 격차를 해소하는 것은 Jenkins 기술을 향상시키는 좋은 방법입니다. 이러한 전환을 쉽게 하는 방법으로 다음 예를 따르십시오.

또한 Drupal과 같은 일반적인 유형의 프로젝트에 대한 많은 템플릿이 존재하므로 처음부터 모든 것을 설정할 필요조차 없을 가능성이 높습니다. 그러니 나가서 Jenkins에 대해 감히 배우고 인생을 훨씬 더 쉽게 만드십시오!