'Jenkins'에 해당하는 글 6건

Jenkins vs ECS

Server/AWS 2018. 8. 12. 02:40



Jenkins 가 지속적 통합(CI), 즉 빌드/테스트 및 배포 자동화 도구라고 할 때, ECS 는 Docker 컨테이너를 실행 및 관리하는 AWS 서비스라고 할 수 있다. 이 설명만으로 볼 때 이 둘이 비교가 가능한건지... 비교할 수는 없겠지만 단지 배포 자동화를 중점으로 간략하게 비교해 보고자 한다. 전 세계에서 대부분의 개발자들이 필요로 하고 사용하는 전문적인 서비스들이지만, 나에겐 그저 자동화라는 가면을 쓴 골치아픈 녀석들 일 뿐.


Jenkins 는 배포가 빠르고 간편하다. 소스 저장소에 push 하거나, 목록에서 배포할 서버를 찾아 버튼을 클릭하는 것 만으로 배포를 완료할 수 있다. 사실 서버도 적고 Release 후에 유지보수가 거의 필요없다면 굳이 이런 CI 툴 등은 필요하지 않을 것이다. 공부하고 설치하고 세팅하고 테스트하고 관리비용 내고... 근데 정작 배포할 일은 거의 없고... 그렇다면 그냥 FTP 로 올리는게 여러가지로 맘이 편할지 모른다. 난 처음 Jenkins 를 설치하고 서버별로 각종 세팅을 하는데에 적지 않은 시간을 할애하면서, 이게 자동화인가... 라는 생각을 했다. 다 만들어놨을 때나 자동화지, 자동화를 위해 흘려야 할 피, 땀, 눈물이... 힘들었다. ㅋㅋ 하지만 이렇게 CI 툴을 하나 익혀놓으면 다른 비슷한 툴들도 쉽게 접근할 수 있다. 방식은 거의가 똑같다.


Jenkins 의 단점을 세가지 정도로 쥐어 짜봤다.


  • 하나는 오토 스케일링. 오토 스케일링이 필요하지 않는 서버라면 상관없겠지만... 늘어난 서버를 수대로, 또 수동으로 세팅해 줘야 한다는건 오토 스케일링이 필요한 사람들에게는 꽤나 번거로운 문제.
  • 또 하나는 복원. 나는 주로 태그로 복원하는 편인데, 롤백할 때마다 설정에 태그 붙였다 뗏다 하는 것도 번거로움. (쥐어짠 티가 남;)
  • 마지막으로 무중단 배포. 이건, 글쎄... 불가능 한건 아니지만 수동적인 무중단 배포(?) 라고 설명하면 되려나.


그렇다면 ECS 가 Jenkins 의 이러한 단점들을 극복해 줄 수 있을까. ECS 는 결론만 말하자면 가능하다. 간단하게 오토 스케일링 및 관리가 가능하고, 이전 버전으로의 복구는 가능은 하지만 그닥 편하다고는 볼 수 없다. 그리고 무중단 배포도 가능하다. 서버 수를 원하는대로 늘였다 줄였다 무중단 연속 배포하는... 이 정도면 배포에 있어서는 거의 완벽하다고 볼 수 있다. 


하지만 안타깝게도 ECS 도 단점이 있다. 기능상의 단점이 아닌 사용자의 능력에 따른 자동화라고 해야 하나. ECS 배포 자동화를 위해 알아야 할 것들이 꽤 많은 편이다. 어느 정도 AWS 나 배포 바닥(?) 을 모르는 초보자라면 이것 저것 시간을 꽤 할애해야 한다. Jenkins 는 사실 Jenkins 만 설치하고 약간의 메뉴얼만 보면 쉽게 따라할 수 있다. ECS 는 Docker 기반이다보니 최소 배포할 이미지는 만들 줄 알아야 한다. 또 이미지 저장소인 ECR 에 이미지를 올리기 위해서는 AWS-Cli 를 사용해야만 한다. 그리고 ECS 를 공부해야 한다. cluster-service-task 를 숙지하고 업데이트/복구 배포 전략을 세워야 한다. 쓰고 보니 크게 공부를 하지 않아도 될 거 같은...; Jenkins 는 구성을 크게 달리할 여지가 별로 없고 인터넷만 조금 뒤져보면 원하는 답을 금방 얻을 수 있지만, ECS 는 운용에 있어 아직 사례들이 부족한 편이라 사용자들이 각자의 환경에 맞게 충분히 헤딩을 해보면서 준비해야 한다. 예를 들자면 이미지 업로드를 어떻게 자동화 할 것인지, 이미지가 업데이트 되었을 때 배포는 어떻게 자동화 시킬 것인지 등이다.



정리하자면 이렇다.


무중단배포, 오토 스케일링이 필요 없다면 그냥 알아서... 해당 사항 없음.

서버 수가 변동될 일이 별로 없고, 업데이트가 잦고, 무중단배포(수동) 가 필요하면 Jenkisn.

지금의 Jenkins 운용에 만족한다면 그냥 Jenkins.

서버 수가 급변하고, 업데이트가 잦고, 무중단배포(자동) 이 필요하다면 ECS.

AWS 에 친숙하고 자동 배포의 끝판왕을 만들고 싶다면 ECS. (얼마나 완벽한 자동화를 만드느냐는 사용자의 몫...)




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Jenkins git rollback

Tool/Jenkins 2017. 2. 17. 00:34

Jenkins 에서 예전 빌드로 배포하는 방법을 좀 찾아봤다. 흔히 말하는 롤백.

배포되지 말아야 할 소스가 배포되었다거나, 잠시 이벤트성 수정이 들어갔다거나 할 경우 꼭 필요한 기능!

빌드 리스트 세부 메뉴에 Re-Build Now 라는 메뉴가 하나 더 있어서 그 당시 리비전으로 빌드/배포되면 차암~ 좋을거 같았는데... 없네...

Jenkins 에는 알아서 롤백해주는 머 그런건 아직 없는 듯...


하지만 수고+1 정도를 추가하면 가능하긴 하다. 바로 [SCM] - [Branch Specifier] 항목을 이용하면 된다.

Branch 를 지정할 경우 해당 Branch 의 최신 리비전을 가져오지만,

Tag 로 지정할 경우 해당 Tag 의 리비전을 가져오니, 롤백이 가능하다는 말쌈.


그리고 Git Tag Message 플러그인을 설치하면 슬랙 알림에 tag 메시지도 전할 수가 있다.

설치하고 [SCM] - [AdditionalBehaviours] - [Export git tag and message as environment variables] 를 선택하면 $GIT_TAG_MESSAGE 를 사용할 수 있다.



ps.

[SCM] 의 Tag 말고도 해당 프로젝트의 Build History 에서 임의로 Tag 를 달아 위 방식처럼 해당 리비전을 가져올 수도 있다.

[SCM] - [AdditionalBehaviours] - [Create a tag for every build] 에서 매 빌드마다 태그를 자동 생성할 수도 있다.

하지만 프로젝트가 여러개일 경우 복잡하고 번거로울 것 같다.

Git 에서 Tag 달아주는게 제일 무난할 듯!




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Jenkins + Slack

Tool/Jenkins 2017. 2. 16. 01:04

Jenkins 에서 빌드 실패 / 성공에 관한 여러가지 알림 이벤트를 슬랙으로 받을 수 있다.



1. App Directory 에서 Jenkins CI 검색 -> 설치 -> 채널 선택

2. Jenkins 대시보드에서 Slack Notification Plugin 설치

3. 시스템 설정에서 팀 도메인 / 토큰 / 채널 입력

4. 해당 프로젝트 설정의 빌드 후 조치 추가(Post-build Actions) - [Slack Notifications] 에서 필요한 알림 이벤트 체크




기본 메시지는 [프로젝트 네임] - [빌드 넘버] 정도로 단순하다.

[고급] - [Include Custom Message] 를 선택하여 원하는 변수로 메시지를 작성할 수도 있다. (환경 변수 참조)


Build #$BUILD_NUMBER 
Branch $GIT_BRANCH 
submitted $GIT_COMMITTER_NAME
cs


작성된 문구는 기본 문구 아래에 더해진다.

하지만 난 정작 필요한 마지막 커밋 메시지가 없어서 패스.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Jenkins build

Tool/Jenkins 2017. 2. 15. 23:19

Freestyle project 의 UI 에서 설정한 빌드/배포 등을 pipeline script 로도 작성할 수 있다.

또한 Multibranch Pipeline item 을 사용하여 Jenkinsfile 과 함께 작성할 수도 있다.


하지만 결론부터 얘기하자면... 난 script 로 작성하는 것을 실패했다 ㅜ

빌드까지는 문제 없었지만 Publish Over SSH 플러그인을 사용하여 배포하는 부분을 script 로 변환하는데 실패했다. 내공 부족 ㅜ

일단 Freestyle project UI 만으로 Product/Development 코드 분리와 모듈별 web/api/cms 부분을 빌드하는데 별 문제가 없으니 일단은 그냥 진행하는걸로...;



Build


기존에는 Product/Development 코드를 build.gradle 에 변수 값을(dev/prod)를 바꿔가며 해당 properties 를 가져와 배포했었다.

이부분의 변수를 gradle task 에서 전달하는 것으로 변경했다.


- From build.gradle


environment = 'dev'
//environment = 'prod'
cs


- To build.gradle


def deployType
if (project.hasProperty("deployTypeParam")) {
    deployType = deployTypeParam
else {
    deployType = "dev"
}
environment = deployType
cs


이러면 빌드 파라미터에 deployTypeParam 가 있다면 그 값을 적용할 것이고, 없다면 dev 값으로 설정 파일들을 가져올 것이다.

그래고 product 서버에 배포할 때는 [Build] - [Tasks] 에 다음과 같이 설정한다. (ex. web module)


:web:build -PdeployTypeParam='prod'



Configuration


그리고 Jenkins 기본 설정으로 포트와 타임존을 변경했다.

포트는 기본 8080 을 iptables 에서 80 으로 변경했고,

타임존은 /etc/sysconfig/jenkins 파일에 다음 줄을 추가했다.


JENKINS_JAVA_OPTIONS="-Dorg.apache.commons.jelly.tags.fmt.timeZone=Asia/Seoul"
cs




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

Freestyle project

Tool/Jenkins 2017. 2. 13. 23:40

Jenkins 설치를 진행하여 Jenkins 웹UI에 접속할 수 있었다. 영어와 한글이 혼합되어 있는 이 모습이 썩 맘에 들진 않는다;

암튼 다음 할 일은 Pipeline 을 생성하고 설정하여 우리가 하려는 CI 기능을 동작시키는 것이다.

Pipeline 이란 것은 빌드나 테스트, 배포 등의 단계를 구성하는 하나의 프로젝트 정도로 봐도 될 것 같다.


Pipeline 을 정의하는 방법은 두가지가 있다.

- 웹UI 를 이용하는 방법

- Jenkinsfile 을 이용하는 방법


어느 것을 사용하던 동작은 동일하다.

웹UI를 따라서 선택하고 입력한 것이나, Jenkinsfile 에 DSL 코드로 작성하는 것이나 동일한 동작을 하게 할 수 있다.

SCM 을 이용하여 협업 등을 이유로 메뉴얼에서는 Jenkinsfile 의 사용을 추천하고 있다.


그러나...


나는 freestyle project 를 먼저 사용해 봤다.

단계별 어떤 옵션들이 있는지 정도는 알아야 Pipeline 을 작성할게 아닌가 ㅜ



* Jenkins 에게 원하는 목표

- Git 소스 체크아웃

- 소스 빌드(gradle)

- 빌드 파일 원격 서버로 업로드



기본 설정


1. 플러그인 설치

[Jenkins 관리] - [플러그인 관리]

- git plugin

- gradle plugin

- publish over ssh 


2. ssh 서버 설정

[Jenkins 관리] - [시스템 설정] 에서 배포할 타겟 서버를 구성한다. (굳이 ssh 를 이용할 필요가 없다면 ftp 플러그인을 받아 설정하면 된다.)

- hostname / username 과 [고급]에서 private Key 입력

- Test Configuration 으로 접속 테스트


3. gradle 설정

[Jenkins 관리] - [Global Tool Configuration]

- Install automatically > 체크 원하는 버전 선택



freestyle project



1. freestyle project 생성

[새로운 Item] - [freestyle project]


2. 소스 코드 관리

- Git Repository URL 정보 입력


3. Build

- Build : Invoke Gradle 선택


4. 빌드 후 조치

- Sned build artifacts over SSH 선택

- SSH Server Name : [시스템 설정]에서 구성한 타겟 서버 선택

- Source files : **/build/libs/*.war

- Remove prefix : /build/libs/

- Exec command :


sudo service tomcat8 stop
sudo cp -ap web1-1.0-SNAPSHOT.war /var/lib/tomcat8/webapps/ROOT.war
sudo service tomcat8 start
cs


5. Build Now

[Console Output] 에서 성공/실패 로그를 확인할 수 있다.


Started by user LeeHongKyu
Building in workspace /var/lib/jenkins/workspace/freestyle project
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/ggamzzak/javatest.git # timeout=10
Fetching upstream changes from https://github.com/ggamzzak/javatest.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/ggamzzak/javatest.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 7599f414e9beb11d4d1350e571b83b2290557465 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7599f414e9beb11d4d1350e571b83b2290557465
 > git rev-list 7599f414e9beb11d4d1350e571b83b2290557465 # timeout=10
[Gradle] - Launching build.
[freestyle project] $ /var/lib/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle33/bin/gradle
Starting a Gradle Daemon (subsequent builds will be faster)
:help
 
Welcome to Gradle 3.3.
 
To run a build, run gradle <task> ...
 
To see a list of available tasks, run gradle tasks
 
To see a list of command-line options, run gradle --help
 
To see more detail about a task, run gradle help --task <task>
 
BUILD SUCCESSFUL
 
Total time: 12.231 secs
Build step 'Invoke Gradle script' changed build result to SUCCESS
SSH: Connecting from host [ip-172-31-27-119]
SSH: Connecting with configuration [honghost1] ...
SSH: EXEC: STDOUT/STDERR from command [sudo service tomcat8 stop
sudo cp -ap web1-1.0-SNAPSHOT.war /var/lib/tomcat8/webapps/ROOT.war
sudo service tomcat8 start
] ...
Stopping tomcat8: [  OK  ]
Starting tomcat8: [  OK  ]
SSH: EXEC: completed after 2,003 ms
SSH: Disconnecting configuration [honghost1] ...
SSH: Transferred 1 file(s)
Finished: SUCCESS
cs


중간에 BUILD SUCCESSFUL 로 빌드가 성공한 것을 확인할 수 있고, 제일 마지막의 SUCCESS 로 모든 과정이 성공한 것을 확인할 수 있다.

타겟 서버에 접속해서 새로운 빌드 파일로 배포가 되었는지 확인한다.

지금까지 아주 기본적인 설정만을 선택하여 Git 소스 체크아웃 받고 gradle 로 소스를 빌드하고 타겟 서버에 빌드 파일을 업로드한 것을 확인할 수 있다.


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,