'CI'에 해당하는 글 3건

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
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

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
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Jenkins install

Tool/Jenkins 2017. 2. 9. 23:09

프로젝트의 자동 빌드 및 배포를 목적으로 CI/CD (Continuous Integration/Deployment) 를 적용하기로 했다.

CI tool 중 가장 많이들 사용하는 jenkins 와 AWS 에 최적화 된 우리에게 적합한 CodeDeploy 를 테스트하고 비교해 보기로 했다.


[필수 요구 조건]


- 하나의 VCS 에서 모듈 별로 배포가 가능해야 한다.

- 운영/개발 서버별로 배포가 가능해야 한다.

- 배포시 특정 서버를 선택할 수도 있어야 한다.


현재는 로컬에서 빌드하고 S3에 업로드 하고 각 서버들에서 배치파일을 실행하여 배포가 되는 식이다.

이것을 VCS 에서 특정 모듈을 특정 서버로 자동 배포하는 방식으로 바꾸려는 것이다.




1. Jenkins 란


Jenkins 는 Java 로 제작된 CI 오픈소스 툴이다.

소프트웨어 빌드, 테스트 및 배포와 같은 모든 종류의 작업을 자동화하는 데 사용할 수 있다.



2. 설치 전 요구사항


- Java 8 (최소 7)

- 1GB+ 메모리 (최소256M)

- 50GB+ (최소1G)



3. 다운로드 / 설치


Jenkins 는 Docker 로도 설치할 수 있고, Tomcat 에 서블릿으로도 설치할 수 있고, 서버에 독립형(Standalone) 으로도 설치가 가능하다.

난 설정이 번거롭긴 하지만 깔끔하게 독립형으로 진행해 본다.


- Redhat / Centos


$ wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
$ rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
$ yum update
$ yum install jenkins
cs


- Debian / Ubuntu


$ wget -q -O - https://pkg.jenkins.io/debian/jenkins.io.key | sudo apt-key add -
$ sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
$ apt-get update
$ apt-get install jenkins
cs


나머지 OS 는 사이트 document 참고 - https://jenkins.io/doc/book/getting-started/installing/



4. 환경 설정


/etc/sysconfig/jenkins 설정 파일에서 필요한 부분을 확인/수정한다.

(JENKINS_HOME, JENKINS_USER, HTTP_PORT 등)


HTTP_PORT 를 수정하여 브라우저 접속 포트를 변경할 수 있다.(기본 8080)



5. 데몬 실행


$ service jenkins start
cs



6. Jenkins 사이트 설정


jenkins 데몬을 실행하고 브라우저로 해당 서버에 접속하면 (http://ip or domain:8080/) jenkins 가 잠겨 있는데,

서버의 특정 위치(예:/var/lib/jenkins/secrets/initialAdminPassword) 에 생성된 password 를 복붙하여 다음 화면으로 이동한다.


- Customize Jenkins

다음으로 플러그 인을 설치하는 화면인데 필요한 플러그인을 모른다면, 일단 기본(추천) 하는 플러그인만 설치한다.

이렇게나 많은 플러그인 들이 기본으로...



- Create First Admin User

다음은 jenkins 를 관리할 관리자 계정을 생성하면 관리자 화면으로 이동하게 되고 설치를 일단락한다.





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

트랙백  0 , 댓글  0개가 달렸습니다.
secret