11 posts tagged with "jenkins"

Azure 사용중인데 얼마전 연락을 받았다. 비용이 좀 과다하게 나오고 있는 것 같다고.

1. Outbound traffic​

확인해보니 outbound traffic이 약 2주동안 63TB 정도.

Azure 정책상 inbound는 무료, outbound에는 GB당 얼마씩 과금이 되는데 합하니 약 천만원 정도의 비용이 찍혀있었고 billing history 상세 내역을 확인해보니 (날짜, category, vm 별로 상세 데이터가 csv로 제공됨) 특정 vm 2개가 매일 2~6TB씩 outbound traffic을 발생시키고 있었다. 뭐 특별한거 서비스하는 것도 아니었는데...

2. Process 확인​

해당 VM 중 하나에 접속해서 우선 top으로 CPU 점유 / Memory 사용량과 사용되는 process 들을 확인해봤다.

jenkins user가 사용하는 XiosElom이라는 process가 눈에 띄었는데 지금까지 본 적 없는 이름이어서 더 상세한 process 정보를 확인해보니 jenkins 설치 경로 하위에 처음 보는 이름의 파일이 복수의 process로 실행중이었다. 이상하다.

3. File / 문서 확인​

XiosElom 이라는 파일을 확인해보니 9월 22일에 생성이 되어있었고 관련 자료를 검색해보니 malware라는 얘기가 위키에 올라와있다. 10월 1일 날짜로 등록된 것으로 보아 비교적 최근에 발견되고 있는 문제인 것으로 보인다.

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-10-01

4. 원인 / 조치​

문제가 된 2개의 VM 모두 테스트용 jenkins가 설치되어 있는 상태라 process를 중단하고 jenkins를 purge로 삭제한 후 재설치를 하고 security 설정을 enable 했다. 근본적으로는 jenkins를 통해 누군가가 설치하고 실행한 process가 원인이지만 방심하고 security 설정을 하지 않은게 그것을 가능하게 했다고 생각한다. 또 급하게 조치하고 나서 보니 추가로 분석할 로그 파일과 실행 파일을 남겨두지 않은게 후회된다.

Jenkins plugin 중 하나를 수정할 일이 있어서 clone 해서 빌드를 해봤는데 테스트에서 실패하는 문제(테스트 코드 상으로는 전혀 문제가 없어보였는데)가 생겨서 plugin 개발 과정 그대로를 진행해봤다.

OS : OS X Yosemite (10.10.3)

IDE : Eclipse Luna

1. settings.xml 준비​

Jenkins plugin은 maven으로 dependency 관리 및 빌드를 하도록 되어있는데 라이브러리나 모듈 등을 maven 중앙 저장소 대신 별도 저장소에서 관리하고 있다. 그렇기 때문에 jenkins 저장소들에 대한 경로를 maven이 인식할 수 있어야 하므로 settings.xml 파일에 아래 내용을 추가하라고 가이드하고 있다.

나의 경우에는 별도로 settings.xml 파일을 변경해서 사용하고 있지 않기 때문에 maven 기본 설정을 따라가게 되어있는데 위의 내용을 ~/.m2/settings.xml 파일로 생성해 놓으니다른 maven project들이 의존관계를 갖는 모듈을 찾지 못하는 문제가 있었다. 그래서 별도로 eclipse에서 workspace를 생성해서 그 위치에 settings.xml 파일을 두고 그 workspace에 있는 project들만 위의 settings.xml 내용을 따르도록 조치해두었다. 불편한 점인데 maven의 기본 settings.xml 내용을 안다면 위의 내용만 추가해서 처리할 수 있을 것 같은데 뒤로 미뤄두기로 했다.

2. Plugin 생성 (skeleton)​

Plugin tutorial을 따라서 해보니 아래의 command로 새로운 plugin을 생성해줘야 한다.

mvn -U org.jenkins-ci.tools:maven-hpi-plugin:create

그런데 위의 내용대로 하면 maven에 설정된 settings를 따라가게 되기 때문에 jenkins에 대한 의존관계를 찾지 못해 아래와 같은 오류가 발생한다.

그래서 별도로 생성한 settings.xml을 적용할 수 있게 command를 변경했다.

mvn -s settings.xml -U org.jenkins-ci.tools:maven-hpi-plugin:create

아래 이미지처럼 groupId와 artifactId를 입력하면 skeleton project가 생성된다.

3. mvn install (optional)​

튜토리얼에는 hpi로 packaging 하기 위해 아래의 command를 사용하라고 되어있다.

mvn install

단순 packaging인데 goal을 install로 하라는게 이상하다. 어차피 IDE에서 드럼과 장구를 칠테니 이 과정은 없어도 될 듯 하다. 그래도 command 변경해서 한 번 해봤다.

mvn -s ../settings.xml install

전형적인 install 처럼 maven 로컬 저장소 경로에 packaging 된 파일들이 생성된다. packaging 과정을 거쳐서 진행되는거니 /project_path/target 에도 hpi가 생성되고 goal을 package로만 지정해도 target에는 hpi가 생성된다.

4. mvn hpi:run​

Dependency 중에 jenkins war도 있어서 hpi:run을 goal로 지정하면 플러그인이 설치된 상태로 jetty로 jenkins를 실행시켜준다. 이 때 기본 context path는 /jenkins이고 port는 8080

mvn -s ../settings.xml hpi:run

5. Project import​

Skeleton project는 기본으로는 maven을 사용하고 있으므로 'Existing Maven Project'로 import 해도 된다. 나의 경우엔 특이한 현상이 있어서 eclipse project로 변환해 보기도 했는데 변환할 경우 아래의 command 형태를 사용하도록 튜토리얼에 기술되어 있다.

mvn -DdownloadSources=true -DdownloadJavadocs=true -DoutputDirectory=target/eclipse-classes -Declipse.workspace=/path/to/workspcae eclipse:eclipse eclipse:add-maven-repo

이제 수정하거나 이것저것 만들어서 빌드하고 실행해볼 수 있다.

6. 특이한 현상​

경험했던 특이한 현상이 아래의 두가지였다.

(1) Skeleton project를 run 했을 때 configuration에 나타나지 않는 문제

Skeleton project를 그대로 실행하면 원래는 아래 그림처럼 jenkins configuration에 'Hello World Builder' 라는 section이 추가되고 job 설정에서 프랑스어로 인사를 print 할 수 있는 기능을 build에 넣을 수 있게 되어있는데 어느 곳에도 project와 관련된 부분이 나타나지 않는 현상이 있었다.

(2) Clone한 project build시 test에서 실패하는 문제

수정하려고 했던 plugin을 clone해서 packaging을 했는데 테스트에서 실패하는 문제가 있었다. 아래 그림처럼 단순한 형태의 테스트 코드였는데 객체가 얻어지지 않는게 테스트 실패의 원인이었다.

두 가지 문제를 해결하려고 시도하던 중 eclipse project로 변환하면서 문제들이 저절로 해결되었다. source를 download 하라고 설정되어 있어서 source가 꼭 필요한 무언가가 있어서 해결된 것인가 (그래도 이상하다) 아니면 변환 과정에서 의존성을 가진 일부 모듈을 download 하는 건지 추측을 해봤지만 정확하지는 않다. 아래는 같은 현상을 경험했던 분이 stackoverflow에 올려놓은 글.

http://stackoverflow.com/questions/23002818/jenkins-plugin-shows-on-plugin-page-but-does-not-show-on-configuration-page

Google의 code review tool인 Gerrit 사용시 기존의 label인 Code-Review, Verified 이외에 사용자 정의 label이 필요한 경우가 있다.

내 경험으로는 CI를 위해 custom label이 필요했었는데 특정 label의 point로 build 여부를 결정짓는데 사용했다.

Custom label이 필요한지 여부를 판단하는 것은 어디까지나 SCM 정책에 따라 달라질 수 있고 그 설정과 관리는 대부분의 사용자들과는 관계가 없는 부분이다.

1. Project clone​

Custom label을 적용하고자 하는 특정 project (저장소)를 clone 한다.

Gerrit의 branches 메뉴를 보면 refs/meta/config 라는 reference가 존재하는데 일반적으로 master branch가 항상 있는 경우 refs/meta/config를 checkout 하지 않으면 보이지 않는다.

비어있는 project를 대상으로 하면 (branch가 없음) clone 하면 바로 유일한 reference인 refs/meta/config의 내용이 나타난다.

2. project.config 수정​

refs/meta/config에는 project.config와 groups 파일이 있는데 (모든 경우를 살펴본 것은 아니라서 다른 파일이 추가되어 있을 수도 있음)

groups 파일에는 access control에 추가되어 있는 관계된 group 정보가 포함되어 있고 custom label 설정과는 관계가 없다.

project.config 파일을 열어보면 access control에 대한 내용과 project 일반적인 설정들이 포함되어 있는데 (description 등) 추가할 label에 대한 내용을 정의한다.

보통 이런 형태로 작성하면 되는데

[label "test label"]

function = NoOp

value = 0 Do Not Build

value = +1 Build Now

추가 상세 설정은 Gerrit 문서를 참조해서 진행한다.

function을 NoOp으로 설정한 경우 submit 여부를 결정하는데 test label이 영향을 미치지 않는다. (기존 정책에 따라 submit 여부가 결정됨)

value는 설정한대로 부여할 point의 범위가 결정되는 역할을 한다.

3. Commit / Push​

소스코드와 동일하게 저장소 변경사항이 발생했으므로 commit을 하고 push를 한다. (Push 할 때 refs/meta/config를 지정하는 것은 기본)

Gerrit의 branches 에서 refs/meta/config의 내용을 확인해 변경사항이 제대로 반영되었는지 확인이 되면 Access Control 메뉴에서 설정할 때 내가 추가한 test label 설정이 가능한 것을 확인할 수 있다.

4. 결론​

일반 개발자들이나 사용자들은 어쩌면 알 필요가 없는 기능이다.

하지만 이런 것도 Gerrit이 제공한다.

알아두면 CI 구성이나 SCM 정책을 좀 더 유연하거나 강화시키는데 도움이 될것이라고 본다.

국내에서는 이런 custom label 사용보다 사실 Gerrit이 제공하는 기본 기능, 정책들만이라도 잘 지킬 수 있기를 희망한다.

0. 준비

Jenkins에 있는 job을 remote trigger 할 일이 생겼다. 자동화를 해야 하기 때문에 적절히 trigger 될 수 있어야 한다. 여기에서 '적절히'는 trigger 되는 job이 후보군 중 일부에만 몰리는 일이 없어야 하며, 동시에 slot (Jenkins의 executor)이 비는 경우도 없어야 하고 가급적 빠르게 시작할 수 있어야 한다는 것을 의미한다.

1. 환경

현재 환경이 가지고 있는 조건들은 아래와 같다.

#1 : 거의 동일한 내용의 작업을 수행하는 job이 복수로 존재한다. (이름만 다른 job)

#2 : 각 job은 parameter를 받도록 되어있고, parameter의 조합은 항상 다르다.

#3 : 각 job은 master / slave 어디에서든 실행될 수 있어야 한다.

2. Executor / Build Queue 특징

2-1. Executor

Jenkins에서 job이 실제 실행될 때 위치하는 공간인 executor는 같은 이름의 job을 단 하나만 가질 수 있다. Executor의 내용을 json이나 xml로 뽑아보면 각 job이 가지고 있는 속성 중에 progress 라는게 있는 것을 확인할 수 있는데 job이 시작된지 얼마나 흘렀는지를 표시하는 값으로 보인다. (진행시간을 second 단위로 표시하는 것으로 추측됨)

2-2. Build Queue

Build Queue는 executor와는 조금 다르게 같은 이름의 job이라도 여러개 위치할 수 있다. 모든 job이 여러개 위치할 수 있는 것은 아니고 parameter가 다른 경우 같은 이름의 job이라도 다른 것으로 인식하는 것으로 보인다. Executor처럼 queue의 내용을 뽑아보면 executor의 progress 대신에 inQueueSince 라는 값으로 처음 queue에 들어온 시간을 저장해두고 있다.

3. 목표

내가 처한 환경에서는 job이 지속적으로 생성되는데(당연하지만), 한 개 job이 작업을 마치는데 시간이 몇분에서 길게는 한시간 이상 소요될 수 있기 때문에 필연적으로 job이 쌓일 것으로 예상된다. Executor는 동일한 이름의 job을 받아 들이지 않기 때문에 동일한 이름의 job을 trigger하게 되면 queue에 쌓이게 될 것이다. Executor가 비어있는데도 queue에 쌓이는 일을 막기 위해서 executor에 없는 job을 우선적으로 trigger 할 수 있어야 한다. Executor가 꽉 찬 경우에는 어쩔 수 없이 queue에 job이 등록될텐데 이 경우 가장 빨리 실행될 수 있을 것 같은 job을 고를 수 있어야 하고 그 job을 trigger 해야한다. 또 queue에는 동일한 이름의 job이 여러개 위치할 수 있기 때문에 복수의 job에 대해서도 고려되어야 한다.

4. Modeling

4-1. Sorting / Weight

전체 job list를 T라고 하자. Executor에 위치한 job list를 E, queue에 있는 list를 Q라고 했을 때 각각을 적당한 기준으로 sorting을 하면 우선순위를 매기기 편할 것이라고 생각했다. 그 기준이 애매할 수 있는데 감사하게도 Jenkins에는 위에 설명된 것처럼 적당한 값들을 저장하고 있다. E는 progress, Q는 inQueueSince를 기준으로 sorting 하기로 했다. Progress는 클수록 시간이 오래 흘렀음을 의미하므로 progress 값이 큰 job은 우선적으로 종료될 가능성이 높다. 그래서 E는 progress를 기준으로 내림차순 정렬하고 Q의 inQueueSince는 progress와 반대이기 때문에 오름차순으로 정렬한다. 이렇게 두 세트를 만들어 보면 정렬된 리스트 중 가장 앞에 위치한 job이 선택에 있어서 가장 높은 우선순위를 갖게 된다.

Executor에 없는 job이 항상 queue에 있는 job 보다는 우선순위가 높아야 하기 때문에 queue에서는 절대 넘을 수 없는 벽 같은 것을 만들어야 했다. 그래서 weight의 개념을 사용하기로 했는데, E와 W의 가중치를 각각 다르게 주되 그 차이를 각각 가질 수 있는 weight의 가용범위보다 크게 하면 벽처럼 사용가능할 것 같았다.

4-2. Model

위에서 정렬된 리스트 E, Q에서 순서대로 weight를 부여한다. 수식으로 만들어보면 아래처럼 되는데 Jw는 job의 가중치 총합계를 의미하고 아래첨자 i는 정렬된 리스트의 index 값 (낮을수록 우선순위 높음), executor와 queue를 분리하기 위한 기본 weight 값이다. Qc는 queue에 존재하는 동일한 job의 갯수이다.

Jw = Ei + (Qi + Wb) * Qc

여기에서 Wb를 결정하기 위해서는 Ei가 가질 수 있는 최대값을 알면 되는데 Ei의 최대값보다 Wb를 크게만 만들면 executor에 없는 job의 우선순위를 queue 보다 높일 수 있다. 고민 끝에 Wb를 적절한 값으로 선택할 수 있었는데 바로 executor의 Total Executor 값이다. Ei 값은 index이기 때문에 job의 갯수에 맞춰서 설정할 executor의 총합보다 클 수가 없기 때문이다. Queue에 복수로 존재하는 job의 경우에는 queue에 하나만 존재하는 job 들보다 우선순위가 확연이 떨어지는데 이것 역시도 절대 넘을 수 없는 경계를 만들 수 있어야 한다.

5. Case

위의 내용을 바탕으로 일단 간단한 경우만 그려보면 아래처럼 된다. 덕분에 복잡할 수 있는 구현을 비교적 단순하게 할 수 있었다. 여러 경우를 고려했을 때 아직은 문제가 없어보이지만 혹시 발견되면 수정할 예정이다.

Jenkins에서 시간값을 unix timestamp로 내주길래 (숫자 13자리) 기억이 가물거려 다시 찾아봤다.

Unix timestamp는 1970년 1월 1일을 시작으로 흐른 시간이며 단위는 seoncd이다.

32bit 환경에서는 10자리, 64bit에서는 20자리라고 하는데 Jenkins에서 13자리를 내 준 이유는 단위를 milli second로 잡았기 때문인 것 같다.

(Jenkins는 Java로 만들어졌고 java에서 timestamp를 처리하는 method 들의 기본단위가 milli second임)

변환은 Java native API에도 있고 참조 링크페이지에서도 가능하다. (참조 링크)

나의 경우엔 알아보기 쉽게 변환할 필요는 없고 가장 작은 값이 가장 오래된 거라고 판단하면 되겠다.

Jenkins의 build queue를 살펴볼 일이 생겼다.

1. Build Queue

우선 Jenkins에서의 build queue는 수행될 job이 수행되기 전에 쌓이는 공간으로 여기서 대기하다가 job이 executor (slot)에 들어갈 수 있는 상태(executable)가 되면 executor로 이동된다.

Executor에 빈 slot이 없어서 실행되지 못하는 상황에 build queue에 job이 쌓이기도 하지만 동일한 이름의 job이 실행중인 경우 같은 job이 build trigger 된다면 이전에 실행중인 job이 종료될 때 까지 build queue에서 대기한다.

2. Build Queue를 사용하려는 이유

자동화에 Jenkins를 사용하고 있는데 remote로 build trigger를 하려다보니 무작정 job을 trigger 할 수 없다. 현재 build queue에 어떤 job이 있는지 executor에는 어떤 job 이 있어서 build 중인지를 확인하고 나서 적합한 job을 trigger 하는게 올바른 접근일 것이다.

3. Build Queue 접근

Jenkins에 authentication 설정이 걸려 있다고 해도 build queue api 접근은 가능하다. 이 페이지가 공식적으로 제공되고는 있는데 API에 대한 설명 같은게 없어서 일단은 구현하면서 대략의 구조를 살펴보게 되었는데, 제공되는 API는REST 방식으로 제공된다고 하는데  HTTP / get으로 간단히 접근할 수 있다.

4. Build Queue 구조

id

buildableStartMilliseconds

task (color, name, url)

inQueueSince

stuck

blocked

params

why

actions

┣━━━━ parameters (name, value)

┗━━━━ causes (shortDescription, userId, userName)

buildable

문서가 없어서 각 요소의 정확한 내용은 아직 알 수가 없지만 Jenkins developer group에 문의를 한 상태다. 이름과 얻어낸 값으로 예상한 내용은 아래와 같다.

[table nl='||']

Key, Type, Description, Note

id, Integer, Trigger된 job의 ID, 계속 변경되는 값으로 보임

buildableStartMilliseconds, Long, ?, 알 수 없음

task > color, String, 상태에 대한 이미지, 이전 상태 나타내는 이미지로 보임

task > name, String, Job의 이름, -

task > url, String, Job의 url, -

inQueueSince, Long, Build Queue에 쌓인 시간, -

stuck, Boolean, 막혔는지 여부, Build Queue에 쌓인 시간이 오래되면 true로 변경됨

blocked, Boolean, ?, stuck과의 차이를 알 수 없음

params, String, Trigger 될 때의 parameter, 줄바꿈된 문자열로 나열되어 활용 어려움

why, String, Build Queue에 쌓인 이유, 동일한 job이 실행중인지 등의 이유에 대한 설명

actions > parameters > name, String, Parameter의 name, -

actions > parameters > value, String, Parameter의 value, -

actions > causes > shortDescription, String, Job 실행에 대한 간단한 설명, -

actions > causes > userId, String, Job을 실행한 사용자의 ID, -

actions > causes > userName, String, Job을 실행한 사용자의 이름, -

buildable, Boolean, Build 가능 여부, -

[/table]

참고

actions의 parameters 항목의 경우 job에 parameter를 받는게 아니라면 값이 비어있는게 아니라 아예 생성되지 않는다.

이것은 parameter가 Jenkins 기본 기능이 아니라 parameterized plugin을 이용하는 거라 그런 것으로 생각된다.

Jenkins는 동일한 job의 동시 실행 갯수를 제한한다.

1. Concurrent Build

아무런 조건이 없을 때 Job A가 실행중이라고 가정했을 때, 누군가에 의해서 혹은 remote로 Job A가 trigger 되면 Job A가 Build Queue로 올라간다.

그러므로 concurrent build의 갯수는 2개라고 할 수 있다. (정확히는 executor에 1, queue에 1)

그 이상이 trigger 되는 job은 cancel도 아니고 pending도 아닌 그냥 무시된다.

혹시 로그에는 있을지 모르겠으나 표면으로는 나타나지 않는다.

당연히 build number도 부여되지 않고, history에도 없다.

2. 문제

항상 문제가 생긴다. (푸는 게 우리의 일)

동일한 job을 여러개 실행해야 할 상황이 생겼다.

3. 상황 설명

Code review 및 기타 이유로 Gerrit을 사용할 예정이다.

Gerrit에서 trigger될 job이 있는데 관리의 편의성까지 고려했을 때 branch 마다 하나의 job을 배치하는게 최선이다.

Gerrit에서 trigger 횟수는 1시간에 수십회 이상이 될텐데 (branch로 나누더라도 마찬가지를 감안해야 함) Jenkins에서 그만큼을 소화할 수가 없다.

결국은 쌓이게 된다는 얘기다.

그리고 문제는 Jenkins에서는 기본적으로 concurrent build 횟수가 2로 제한된다는 사실이다.

나머지는?

결국 버려질 것 같았다.

큰 문제가 발생하는 것이다.

4. Hello (real) World

실제로 검토를 했다.

Job 수행시간을 충분히 늘려두고 job을 수없이 trigger 했다. (손으로도, remote로도)

일반적인 job의 경우 결과는 역시 동일했다.

혹시나 싶어 Gerrit에서 trigger 되도록 했다. 여러번.

믿을 수 없게 Build Queue에 쌓여가는 job을 목격할 수 있었다.

5. How?

StackOverflow에서 찾아보니 trick이 있었다.

실행될 job의 parameter를 다르게 던지는 것.

필요없어도 아무런 값이나 만들어 던지면 된다고 한다. (StackOverflow 원문 참조)

생각해보니 Gerrit에서 trigger 되는 job은 실제 parameter가 함꼐 오는데 그 값이 모두 다르다.

그래서 보통과는 다른 결과가 온 것이 아닌가 생각된다.

6. 회고

가만히 생각해보니 Jenkins의 concurrent build를 제한하는게 어이없지는 않다.

완전히 동일한 내용의 job을 무한정 돌릴 필요가 있을까?

하지만 parameter가 다르다면 job의 이름은 같더라도 다른 내용을 실행하게 될테니 다른 job처럼 인식하는게 올바른 방식일 것 같다.

걱정을 하나 덜었다.

나에게 필요할 것 같은 Jenkins Plugin을 찾아봤다.

주로 Job 생성, 관리, 설정을 간단하게 할 수 있는 것들인데 일부는 쓸모없거나 문제가 있는 것들도 보인다.

선별해서 사용할 예정인데, 이리저리 조사하고 써보니 Jenkins Plugin도 개발하고 개선할 것들이 꽤 될 것 같다.

[table nl="||"]

Category, Plugin, Description, Feature, Note

Job 생성, Job Import Plugin, 다른 Jenkins server에 있는 job을 선택적으로 import 할 수 있는 plugin, Remote job selection||Remote job import, 오류가 있으나 수정되지 않음||https://issues.jenkins-ci.org/browse/JENKINS-11185

Job 생성, Job Generator Plugin, Parameter를 넘겨 주면서 job 생성이 가능한 plugin, Generator parameter 전달 가능||Post build job에 parameter 전달 가능, Run Condition Plugin/Token Macro Plugin이 설치되어 있어야 함||특정 script를 몰라도 설정만으로 job 생성이 가능하지만 사용한다면 Job DSL Plugin이 더 간단할 것으로 보임

Job 생성, Job DSL Plugin, DSL script(Groovy)를 이용해서 job을 생성하는 job을 만들 수 있는 plugin, 생성할 job 정의하는 기능||Job 자동 생성, Tutorial 참조

Job 관리, Multijob Plugin, 여러개의 job을 묶어서 순차적으로 실행할 수 있는 plugin, Phase 구분||Phase 별 job 선택 가능||실패 조건 결정 가능||한 phase에 존재하는 복수의 job은 parallel로 실행됨, Parameterized plugin이 사전에 설치되어 있어야 함||Jenkins의 job이 너무 많은 경우 유용함

Job 관리, Nested View Plugin, Job을 폴더 형태로 관리할 수 있게 해주는 plugin, Subview 추가, View tab을 늘리면 가로로 추가되기만 하고 job이 늘어날 경우 보기가 어려워지는데 폴더 형태로 job을 정렬함으로써 job 갯수가 많은 경우 유용

Job 관리, Sectioned View Plugin, 화면을 section으로 구분해서 더 다양한 정보를 보여주기 위한 plugin, Test result/list view/job graph/text/view listing section 지원, Jenkins의 view 하나를 dashboard로 사용할 수 있을 것으로 보임||정적 분석이나 test 결과에 대한 정보 위주로 분석 툴이나 결과 data를 직접 활용하는 것이 효율적일 것으로 생각됨

Configuration, Config File Provider Plugin, 사전에 정의한 파일을 이용해 build에 이용할 수 있도록 해주는 plugin, Maven settings.xml / plain xml / Groovy / plain text는 향상된 수정기능 제공, -

Configuration, Managed Script Plugin, Config File Provider Plugin에서 script 파일을 추가할 수 있는 plugin, Batch / shell script 지원||Argument를 미리 정의해서 build job 설정시 argument를 설정해서 사용 가능, 미리 정의된 build script를 하나로 관리하기 용이

Configuration, Scriptler Plugin, Groovy script를 미리 작성해두고 job 실행시에 사용할 수 있도록 지원하는 plugin, Script 추가/수정/삭제||Github에 공유된 script 이용 가능||Script 보관하는 GIT repository 지원, Build 수행내용을 미리 Groovy로 작성한 후 일괄 적용하기 유용함

Master-slave, Copy To Slave Plugin, Build 전 master의 파일을 복사해 가거나 build 이후 slave에 있는 파일을 master로 옮겨올 수 있는 plugin, Copy할 파일 지정 가능||상대경로 지정 가능||Copy 제외목록 지정 가능, Custom workspace를 지정해서 복사할 파일의 경로로 이용하게 되면 job이 master에서 실행될지 slave에서 실행될지 모르기 때문에 파일 경로가 모호해지는 문제가 있음 (slave 실행시에도 custom workspace를 이용함)

Master-slave, Multi slave config plugin, 여러개의 slave를 추가/삭제/설정할 수 있는 plugin, 복수의 slave 생성/설정 가능, FS Root가 slave 마다 다른 경우에는 생성 후 개별적으로 설정해야 하는 불편함 있음

Master-slave, NodeLabel Parameter Plugin, Job 실행시 특정 node나 job을 지정해서 빌드할 수 있도록 지원하는 plugin, Node/Label 지정||Post build job도 node와 label로 지정 가능, Parameterized Trigger Plugin 필요||Build job을 여러개로 분리할 경우 수행된 slave에서만 계속되어야 하므로 필요할 수 있음

Master-slave, Slave Setup Plugin, Slave 연결시 master에 있는 script로 초기 설정 작업을 수행하도록 할 수 있는 plugin, Master의 script 경로 저장||Slave로 script 복사||Script 실행||실행될 slave의 label 지정, Slave 연결시에만 수행되는 작업임||Prepare script/setup script는 모두 상대경로를 지정해야 함||매번 초기화 작업이 필요하면 사용할 필요가 있지만 별도의 job으로 구성할 필요도 있음

Monitor, Monitoring, Jenkins가 사용하는 메모리 등의 상태에 대한 monitoring을 할 수 있는 plugin, CPU / memory 사용량||Http session / request 등에 대한 mean time||JavaMelody를 이용한 통계치를 보여주는 기능||http://jenkins\_url/monitoring 이라는 permanent link 제공, -

Monitor, Monitoring External Jobs, Jenkins 외부에서 실행된 job을 monitoring 할 수 있는 plugin, 외부 job monitoring, Linux에서 설치해야 하는 별도 package의 위치를 찾을 수 없음

Monitor, slave-status, Slave가 동작중인지와 메모리 사용량 등을 알려주는 plugin, Monitoring, 3141 Port를 기본으로 사용함||한 machine에서 여러개의 slave를 사용해서인지 monitoring page 로딩되지 않음||Nagios라는 monitoring tool을 설치해야만 할 수도 있으나 그래야만 한다면 사용하지 않음

Misc., Email Ext Plugin, Email 전송시 좀 더 세분화시켜서 email을 선별적으로 발송할 수 있는 plugin, Email notification trigger 선택 가능||Contents 지정 가능||수신자 지정 가능, 이용 하더라도 별도의 email sender 구현 필요성 있음

Misc., MySQL Database Plugin, MySQL driver plugin, -, Database plugin이 설치되어 있어야 함||Jenkins / plugin 개발용 plugin으로 보임

[/table]

Jenkins를 여러개 띄워서 검토할 내용이 생겼다.

일반적으로 한 machine에 하나의 Jenkins만 올려서 사용하니 가용한 한 대의 테스트 서버와 다른 사람들의 PC까지 활용하면 어찌어찌 할 수 있겠다 싶었다.

하지만 접속해서 설정해줘야 하고 나 덕분에 다른 사람들은 불편함이 생기니 어떻게 내 PC에서만 Jenkins를 여러개 띄울 수 없나 고민하게 되었다.

처음엔 Jenkins는 필요한 각종 설정이나 plugin, job 정보들을 JENKINS_HOME으로 등록된 경로에서 관리하니 이 경로와 http port만 다르게하면 되지 않을까 생각해봤다.

그러나 결과는 Port 충돌.

Http port는 다르게 했으니 문제가 없었는데 내부적으로 사용하는 port들이 문제를 일으키는 것 같았다. 로그상으로는.

사용되는 Port를 보니 http port, ajp13 port, sshd port, tcp port (JNLP slave agent listener).

이 중에서 http와 ajp13 port가 설정이 가능하다. (Jenkins Wiki 참조)

그래서 임의로 master, slave1 이라 명명해서 각각 아래처럼 해보니 충돌없이 잘 된다.

Master

[bash]

java -jar -DJENKINS_HOME=D:/jenkins/master -jar jenkins.war --httpPort=7070

[/bash]

Slave1

[bash]

java -jar -DJENKINS_HOME=D:/jenkins/slave1 -jar jenkins.war --httpPort=7071 --ajp13Port=8109

[/bash]

Master는 ajp13 port로 8009를 사용한다. (Jenkins default)

근데 도대체 ajp13은 무얼까?

찾아보니 Apache Jakarta Project에 있는 Apache JServ Protocol version 1.3 이라고 한다. (AJPv13 참조)

참고로 Windows 7에서 처리했고, Jenkins version은 1.474였다.

Jenkins monitoring을 매일 해야하는데 열어야 하는 페이지가 많다면 어떻게 해야 하는가?

상당히 귀찮다. 단순 반복이기도 하고.

특별히 문제가 있는 경우는 별로 없지만 그래야 안심이 되어서 매일 아침마다 하고 있는 상황이다.

한 눈에 파악할 수 있는 monitoring page를 간단하게라도 만들어볼까 하는 생각에 우선 각 서버들에 퍼져있는 job의 status 확인이 가능한지 알아봤다. (RSS도 되는데 없을리가...)

아래의 주소를 curl이나 wget으로 실행하면 xml 형태의 data가 날라오게 되고 마지막을 xml 대신 json으로 변경하면 json 형태로도 data를 받을 수 있다.

http://{your_ip}/job/{your_job}/api/xml

나의 경우엔 job에 대한 여러 정보 중에서 마지막 job에 대한 것만 필요하기 때문에 아래와 같은 url을 던졌다.

http://{your_ip}/job/{your_job}/lastBuild/api/xml

위에 대한 결과로 아래와 유사한 형태의 xml data를 확인할 수 있다.

<freeStyleProject>
<displayName>{your_job_display_name}</displayName>
<name>{your_job_name}</name>
<url>{your_job_url}</url>
<buildable>true</buildable>
<color>grey</color>
<inQueue>false</inQueue>
<keepDependencies>false</keepDependencies>
<nextBuildNumber>1</nextBuildNumber>
<concurrentBuild>false</concurrentBuild>
<scm></scm>
</freeStyleProject>

이제 xml이나 json으로 된 재료는 있으니 어떻게 요리하느냐가 남았는데, 재미있을 듯 하다.

시간과 여유를 낼 수 있느냐가 문제.