'개발/Jenkins'에 해당되는 글 10건

1. Jenkins 다운로드

 - http://jenkins-ci.org/ 가자마자 download war 버튼이 있다.

2. Jenkins 설치

 - 설치랄게 별로 없고, tomcat의 webapps에 넣어주면 바로 접근이 가능해짐.

 - jetty가 내장되어 있기 때문에, 명령어만으로 바로 띄울 수도 있는 것 같지만, 플러그인 목록이 가끔 안보이는 문제 등 불안정한듯.. yum repo등록 시 설치하는 방법도 마찬가지..  

 - 그래서 톰캣에 올리는 것을 추천한다.

3. Jenkins 세팅 

 - 플러그인 먼저 설치해준다. (Jenkins관리 - 플러그인 관리)

 - Git Plugin, Gerrit Trigger Plugin을 설치한다. (재시작 없이 설치하기를 권장) 

(그냥 Gerrit Plugin이 있는데 Gerrit Trigger Plugin의 예전 버전이며, deprecated 된 플러그인이라고 한다. 실제로 오류를 뿜음)

 - Jenkins관리 - 시스템 설정에 가서 SCM (여기서는 git), Maven, Jdk에 대한 설정을 해준다.

4. Gerrit Trigger Plugin 설정 (Jenkins관리 - Gerrit Trigger) 

 - 좌측의 Add New Server버튼을 눌러서, Gerrit Server를 등록해준다. 

 - 아래와 같은 화면이 나오는데, 회사 정보는 삭제하였다. 

  - Frontend URL에 1번 포스팅에서 proxy설정을 마친, apache url을 입력해준다.

  - username, email은 jenkins전용 계정을 생성해서 등록하는 것을 추천한다. (Gerrit의 Verify Label에 찍히게 될 계정이다) 

  - 모두 입력 후, Test Connection을 눌러서 제대로 연결이 되는지 확인한다.

5. Item 추가 (구버전에서는 Job이라고 불렀었다.)

  - 좌측 상단의 새로운 Item버튼을 누르고, 내가 Maven을 주로 사용하므로 이름을 대충 지어주고, Maven Project를 선택한다.

6. Item Configuration  

  - 소스코드 관리 항목에서 git 부분에 gerrit에 생성되어 있는 repo의 ssh 경로를 적어준다.

  - credential도 gerrit에서의 인증정보와 동일하게 설정 해준다. 

  - 빌드유발 항목에 보면, gerrit event항목을 볼 수 있는데, Gerrit에서 특정 이벤트(Trigger On에서 지정한)가 발생하면 이 Item을 실행하도록 설정이 가능하다. 

  - 다른 항목은 각자 프로젝트 환경에 맞게 설정하고, Trigger on항목은 Patchset Created로 지정하여, 바로 테스트를 진행해보자.

  - 저장하고, 일부로 PatchSet을 생성해서 하나 올려보도록 하자.

  - 설정이 완료된, Item을 실행시킨다. 

  - Gerrit의 Verified Label에 verify 점수가 등록되어 있으면 성공! 

7. Item Detail Configuration

  - 6번과 같이 설정하는 경우 잘되는것처럼 보이지만, 새로 생성된 patchset에 대해서 빌드를 수행하지 않고,

기존에 올라가있는 소스에 대한 빌드를 수행한다.

  - 이럴 경우, 소스코드 관리 항목에서 고급을 눌러서 Refspec에 origin/$GERRIT_REFSPEC 라고 입력해주고,

Branches to build에는 $GERRIT_BRANCH라고 입력해준다.  

  - Additional Behaviours에서도 Strategy for choosing what to build항목에서 Gerrit Trigger를 명시해주어야 한다. 

  - 이렇게 하면, 올라간 Patchset에 대해서 빌드를 해준다..  

  - 저렇게 환경변수로 지정을 해두면, Trigger돌면서 환경변수에 해당하는 것을 알아서 찾아서 돌려준다.

  - 추가로, Additional Behaviours에서 Wipe out repository & force clone을 추가 해준다. (이게 없으면 전에껄 clone해옴)

8. 7번 문제에 대한 해결

  - Gerrit Trigger가 2.12.0으로 업데이트가 되었음.

  - Gerrit Trigger Configuration에 Build Current Patches Only 이런 옵션이 생겼다!!

  - 정말 가장 최근 PatchSet 찾아서 잘 verify한다..

  - 그리고 가장 중요한... 아래 화면... (좌측은 Plain으로 설정해서 Repository명 써야하고, 오른쪽 Branches는 Path로 바꾸어 주어야 **이 먹는다.. (이거 가지고 이틀 삽질함;;;) 

  - 참고로, 수동으로 돌리려면 Item자체를 실행하는 것이 아니라, Query and Trigger Gerrit Patches 메뉴에서 실행해주어야 한다.

(그래야 현재 Open되어 있는, PatchSet, Branch에 대해서 제대로 찾는 것 같다.) 

이후 세부 설정 및 복잡한 처리 프로세스에 대해서는 더 연구가 필요하며,

정리되는대로 하나씩 올려나갈 예정이다. 

기존에 주로 사용하던 SVN을 드러내고, Git으로 갈아타면서

코드 리뷰 시스템인 Gerrit을 사용해보기로 하였고, Gerrit을 사용하는 김에 Jenkins를 통해 verify하는 기능까지 연동해보기로 하였다.

일단 Gerrit을 사용하기 위해서는, 기본적으로 JDK가 필요하다.

1. JDK 설치

 - openJDK로 해도 되고, 소스 설치를 해도 됨. (이건 알아서...) 

2. Gerrit 다운로드 (버전 업이 자주되므로, 최신버전을 추천) 

 - http://gerrit-releases.storage.googleapis.com/index.html  

 - war파일 하나가 받아진다. 

3. Gerrit 설치

 - java -jar gerrit-2.9-1.war init -d /usr/local/gerrit-2.9.1/

 - 위 명령어를 실행하면, 뭔가 막 고르라고 나오는데, 대충 엔터를 치면 넘어가지만, 중요한 옵션들이 있다.  

DataBase Type, Authentification Method, Java Runtime은 신경써서 지정해주자. (잘못 지정해도 나중에 수정이 가능하긴함)

4. Apache  / mod_proxy 설치

 - Gerrit은 기본적으로 apache / nginx등의 proxy기능을 요구한다. (여기선 apache 기준으로 설명)

 - Apache는 2.2.xx 버전을 소스 컴파일로 설치할 것을 추천한다. (2.4.xx 버전은 apr-util등이 yum으로 설치 시에 버전이 낮다고 에러를 뿜는다.)

 - 설치 시 옵션은 아래 명령어 정도만 주면 된다. 

./configure --prefix=/usr/local/httpd-2.2.24 --enable-module=proxy  


 - 이렇게 설치 하면 보통은 apache/modules 폴더에 mod_proxy관련된 라이브러리 2개가 생겨야 하는데, 생기지 않는 경우 아래 링크를 참조한다. (라이브러리만 수동으로 컴파일하는 방법) 

http://blog.pointbre.com/2794/mod_proxy-%EC%84%A4%EC%B9%98-%EC%84%A4%EC%A0%95.html 

 - 이제 아파치 설정을 수정해보자.

 - httpd.conf에서 include httpd-vhosts.conf 항목을 주석 해제해주고, 포트도 80이 아닌 다른 포트로 적절히 바꾸어 준다.

(ex : Listen 8181) 

 - extra/httpd-vhosts.conf 에서 proxy설정을 해줌.

[httpd-vhosts.conf] 

NameVirtualHost *:8181 
<VirtualHost *:8181>
    ServerName localhost

    ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On

    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy> 

    
    <Location /login/ >    // login/ 경로에 대해서만 아래 인증 정보로 인증을 수행함.
        AuthType Basic
        AuthName "Gerrit Code Review"
        Require valid-user
        AuthUserFile /usr/local/gerrit-2.9.1/etc/passwords       // gerrit인증에 사용될 인증정보가 들어가 있는 파일
    </Location>

    AllowEncodedSlashes On      // 이 옵션이 없으면, Gerrit에서 / 가 들어간 경로로 진입할 때, permission이 없다고 나옴..

                                                    // 왜 안되지 하는데, 공식홈에 나와있었음;;
    # gerrit location
    ProxyPass / http://gerritHost:gerritPort nocanon     // nocanon은 없어도 잘 동작하지만, gerrit 공식 홈피 가이드에 나와있어서 추가
</VirtualHost> 

 - gerrit에도 proxy정보를 추가해주자. 

[gerrit.config]

[gerrit]
        basePath = git
        canonicalWebUrl = http://apacheHost:apachePort/
[database]
        type = h2
        database = db/ReviewDB
[index]
        type = LUCENE
[auth]
        type = HTTP
[container]
        user = root
        javaHome = /opt/jdk1.7.0_67/   
[sshd]
        listenAddress = *:29418
[httpd]
        listenUrl = proxy-http://gerritHost:gerritPort/
[cache]
        directory = cache 

 - htpasswd를 이용하여 Gerrit로그인에 사용될 사용자 계정을 등록해 주자.

/usr/local/apache2/htpasswd -c /usr/local/gerrit-2.9.1/etc/passwords ID PASSWORD

​

 - 브라우저에 http://apacheHost:apachePort/login/ 입력 후 위에 지정한 ID, PASSWORD로 로그인을 시도하면 로그인이 된다.

5. Verified Label 추가하기 (참고 : http://blog.bruin.sg/2013/04/how-to-edit-the-project-config-for-all-projects-in-gerrit/) 

 - Gerrit 2.9.1 버전 기준으로, Web UI상에서 Code Review Label밖에 없다. 하지만, jenkins에서 verify를 수행하게 하려면

Gerrit에서도 verify Label이 적용되어 있어야 함.

 - 로컬에서 git bash등으로 아래 명령어를 실행함. 

보통 Maven을 설치하면, conf아래에 settings.xml이 있고,  

Nexus의 인증 정보를 settings.xml의 <servers>에다가 넣어주는데,

이게 Jenkins에서 deploy할때는 /home/{user}/.m2/settings.xml을 기본으로 참조하는 것 같다.

따라서, Maven/conf 폴더에 있는 settings.xml을 .m2/아래로 복사만해주면 해결이 된다. 

물론, 기존에 쓰던 pom.xml내에 포함된 설정으로, Goals and options에다가 tomcat7:redeploy라고 입력하면,

배포는 잘 하는데, UnStable빌드인데도 무조건 Goal을 수행하기 때문에, 불안정한 빌드가 올라갈 가능성이 생겨버린다.

(Eclipse에선 불안정한 빌드면 잘 걸러내더만...) 

이런 현상을 방지하기 위해, 빌드 후 조치를 사용한다.

Tomcat에 배포하기 위해서는, Deploy Plugin을 설치해야 하고, 설치 한 후에 Deploy war/ear to a container메뉴를 선택해서

pom.xml에 tomcat7 plugin을 설정했던 것처럼 입력해준다.

다만 다른점이 있다면.. Tomcat 경로 지정 시에 /manager/text는 제외되고, 기본 URL을 입력해주어야 한다.

그래도 잘 안된다면, 톰캣 매니저 xml에서 manager-script권한이 추가되어 있는지 확인해본다. 

기존에는 테스트용도로 매번 Context Path을 pom.xml에서 변경해서 사용했었는데,

이건 아예 Context Path를 다르게 만들어서 Item을 미리 여러개 만들어놓으면,

더 확장이 쉬운 것 같다.

이걸로 pom.xml에 있는 tomcat7 deploy plugin은 지워버리는걸로... 

아무리 바꿔도 안바뀌길래, pom.xml 경로를 따라 들어가보니

Jenkins workspace폴더에 item기준으로 폴더가 나뉘어있고,

그 폴더 root에 존재했다.

maven project상에서 pom.xml을 바꾸어도 기존에 이미 파일이 있으면

간혹가다가 바꾸지 않는것 같다.. (좀 이상하긴하지만;;; 버그인듯)

1. 그럴땐 워크스페이스를 날리고, 다시 실행하면 반영이 된다.

2. Workspace Cleanup Plugin 이걸 설치해서 활용해도 된다.

ssh key 생성하고, user name, email등 다 입력했는데..

아래와 같은 에러가 발생하는 경우가 있다.

User testerJenkins has no capability to connect to Gerrit event stream.

이런 경우 Gerrit 관리자 계정으로 들어가서

Group Event Streaming Users에서 Trigger를 실행하고자 하는 계정을 추가를 해주면 된다.

그래도 안되는 경우.. 프로젝트쪽에서 권한이 막힌 경우인데

Global Capabilities카테고리의 Stream Events를 Allow 시켜주면 해결 된다.

이외의 에러는, ssh Key를 잘못 생성했거나, 비밀번호를 잘못입력한 경우로 보면 된다.

Jenkins를 Linux환경에 설치를 하고, 보통 scm에서 땡겨서 여러대의 Linux 머신에 배포를 할 때는

sshpass와 rsync만으로 충분히 가능하다.

하지만, Target서버가 Linux환경이 아닌 Windows환경의 경우, 일반적인 방법으로는 불가능하다.

그러던 중, SSAG에 글을 남겨서 Jenkins Slave라는 것이 있다는 것을 알게되고,

세팅을 시작하게 되었다.

Jenkins Master (Linux), Jenkins Slave (Windows) * n과 같이 구성을 하여,

1대의 Slave에서 돌아갈 Batch Script만 짜두면, 어디서 돌릴지 Slave를 선택하여 돌아갈 수 있게끔 해주는 유용한 기능이다.

이러한 환경 구성을 위해, 각 Slave에 Agent세팅을 필요로 한다.

Slave에는 사전에 Java가 설치되어 있어야 하며, Jenkins Master에서 Slave를 연결을 시킬 수가 있다.

[Jenkins 관리 - 노드관리] 메뉴로 진입하여 신규 노드버튼을 누르면 아래와 같은 화면이다.

중요한 부분 몇가지만 보고 넘어가면, 

Remote root directory는 Jenkins Slave의 Workspace와 Log 정보등이 저장되게 되는 디렉토리이며,

Launch method는 Launch slave agents via Java Web Start로 Java Web방식으로 슬레이브 에이전트를 띄우는 옵션이므로,

이 옵션으로 바꾸어 주고, 저장을 하고나면, 아래와 같은 화면이 나온다.

(어차피 가상환경 IP라서 그냥 공개했음)

순서대로 따라하면 된다.

Launch버튼을 눌러서 slave-agent.jnlp 파일을 받고,

파일을 받은 경로에 가서, Run from slave command line에 있는것을 cmd창을 열어서 그대로 실행하면,

Master에 연결이 되어, Master에서 컨트롤 가능한 상태가 된다.

Item생성 시에는 Multi-configuration project 타입으로 생성을 하면,

아래와 같이 Configuration Matrix옵션이 있는데, 여기서 어떤 Slave에서 돌아갈지에 대해서 설정이 가능하다.

이걸 몰랐을 때는, Windows에다가 openSSH도 깔아보고 freeSshd도 깔고, 별짓을 다했는데..

가장 간편하고, 깔끔하게 해결이 되었다.

사실 별거 아니긴한데, Job의 Read권한때문에 애를 먹었다.

기본적으로 유저를 생성하면 Overall/Read권한은 무조건 다 주는 게 맞는데,

이게 Job의 READ권한까지 포함을 하고 있는줄 알았더니,

Job을 볼 수 있는 권한은 Job/Read로 따로 있었다.

여기까지 사전지식이 필요한 부분에 대한 내용이었고, 설정 방법에 대해 소개한다.

Autorization 부분에서 Project-based Matrix Autorization Strategy를 선택해야 한다.

그리고 Job/Read권한은 Anonymous에게 주지 않고, Overall/Read권한만을 부여한다.

이제 생성되어 있는 Job 설정에 가서 Enable project-based security옵션을 체크하여,

해당 Job에 대한 권한을 가질 유저들을 지정해주면 된다.

정리를 해보면..

Anonymous User기준으로.. 

Overall/Read 권한은 Jenkins Main페이지에 접근할 수 있는 권한

Job/Read 권한은 말그대로 Job을 볼 수 있는 권한

Administrator권한은 둘 다 포함

local vm 환경에서는 같은 네트워크라서 그런지 sshpass같은 명령어로 execute shell에다가만 넣어도 

ssh인증이 문제가 없었는데.. (그놈의 vagrant가 또 문젠가...?)

회사 보안 정책상 뭐가 특이하게 걸려있는지

회사에서 받은 vm에서는 제대로 동작을 하지 않았다.

ssh key폴더를 바꿔보고 이리저리 플러그인을 설치해봤지만... execute shell로는 안되더라.

그러던중 public over ssh plugin이라는 넘을 우연찮게 발견을 했는데..

ssh인증을 미리 받아놓고, jenkins workspace에 있는 빌드 된 넘들을 remote directory (ssh인증을 받아놓은 서버)로 transfer를 해주는 훌륭한 기능을 가지고 있었다.

뭐 아래 링크에 나온 정보가 사실 가장 정확하긴 하지만, 나 처럼 영어를 싫어하는 사람들을 위해 손쉽게 설명을 하도록 함.

https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+SSH+Plugin

일단 Public Over SSH Plugin을 설치한 후에!

[Jenkins관리] - [시스템 설정]에 가보면, Add an SSH Server라고 아래와 같이 추가할 수 있는 화면이 나온다! 

Name은 Alias라고 보면 되고, hostname이랑 username정도만 적어준다.

그 후, 만들어둔 Item(Job) 설정으로 가서, 빌드 스텝을 추가하는데 아래와 같이 노란색으로 칠해진 넘이 추가가 되었다.

아래와 같이, 빌드 스텝이 아닌 빌드 후 조치사항에서도 동일하게 이용을 할 수가 있다.

체크를 하고나면, 드디어 원하는 동작을 할 수 있도록 구성된 UI가 보인다.

Source files는 jenkins의 job workspace 폴더를 기준으로 어떤 파일을 복사할 것인가에 대해 정의한다.

Remove prefix는 Source files에서 지정한 경로의 하위 폴더를 지우는 기능이라는데.. 이딴걸 어디다 쓰나 싶다.

Remote directory는 SSH Server로 지정한 서버의 원격지 폴더를 의미한다. 

(주의할 점은, 만약 계정이 test라면 /home/test를 기본 폴더로 보게 된다. /test 같은데다가 복사하려고 하면, ../../ 이런거 막 넣어도 원하는대로 안된다는 걸 명심하자. 문의한 사람이 ROOT경로에 /test로 만들어뒀길래.. 어떻게든 맞춰줄려고 왜 안되지 왜안되지 하면서 고민하다가 보니깐, 계정 폴더 하위에 들어가 있었다. ㅡㅡ;; 

본인처럼 삽질하지 말기를...)

Exec command는 파일 전송이 모두 끝난 이후에, SSH Server로 지정한 서버에서 실행될 스크립트를 지정해주는 기능이다.

아래 Add Server버튼이 있는 걸 보면 알겠지만, 서버 여러대에다가도 기존처럼 Execute Shell로 For Loop돌아가며 원시적으로 알아보기 힘든 스크립트를 작성하지 않고도, 깔끔하게 정리가 가능하다.

퇴근하고 계속 머리에 맴돌아서 집에와서 밥도 안먹고 2시간동안 삽질하다가 해결!

이로써 배포 자동화가 완성되었다.

Jenkins + SVN을 연동하여 사용하면, 기본적으로 HEAD에 대해서 update를 받아서 사용이 된다.

이것만으로 충분한 경우가 대부분이지만, 개발 조직이 아닌 운영 조직 같은 경우는,

왜 특정 Revision으로의 update는 안되냐고 테클이 들어오는게 보통이다.

이런 테클을 방지하기 위해, 해결책을 마련해보았다.

1. Job 설정에서 매개변수를 추가한다.

2. SVN Repo URL을 SVN Url@$매개변수명 형태로 넣어서 지정한다.

  - 이 때, 유효하지 않은 URL이라고 나오지만, 무시하자.

@$매개변수명 이게 포인트 인 것 같다.

스크린샷을 올리고 싶었으나.. 되도않는 보안정책 어쩌고하면서 사진 공유가 안된단다.

어쨋든, 이로써 해결