노스웨일즈 김씨 시조의 블로그

팀을 옮기면서 익히기 시작했던 Chronos. 핵심은 Mesos에서 실행되는 App에 불과하지만 분명 좋은 Tool인 것은 부인할 수 없다. 근데 문제는 Mesos, Chronos 모두 패키징을 제공하지 않아서 사용자가 스스로 BUILD해서 사용해야 한다는 점이다. 그런 부분이 좋은 BIZ Model이 되었는지 MESOSPHERE라는 회사에서 MESOS, CHRONOS를 묶어 PACKAGING을 제공하고 있다.

회사는 CENTOS6 이어서 그에 맞추어 RPM을 설치 했고, GOOGLING을 통해서 /sbin/start , /sbin/stop, /sbin/restart command로 각 Daemon을 start/stop할 수 있게 되었다.

근데 최근에 start option을 일부 수정할 이슈가 생겼는데, 어디를 수정해야 하는지 모르겠다는 점이다.

/sbin/start{stop,restart}를 체크해 보니 결국 /sbin/initctl의 link들이고 아래 article을 보니 /etc/init에 각 daemon 관련 config를 읽어 온다는 정보를 알게 되었다.

http://serverfault.com/questions/489525/linux-how-to-pass-parameters-to-service-foo-start-at-command-line

결국 CHRONOS 실행 Script를 찾았는데... 이 Script에 재밌는 부분이 보인다.

function load_options_and_log {

  set -x

  # Load Chronos options from Mesos and Chronos conf files that are present.

  # Launch main program with Syslog enabled.

  local cmd=( run_jar )

  if [[ -s /etc/mesos/zk ]]

  then

    cmd+=( --zk_hosts "$(cut -d / -f 3 /etc/mesos/zk)"

           --master "$(cat /etc/mesos/zk)" )

  fi

  if [[ -d $conf_dir ]]

  then

    while read -u 9 -r -d '' path

    do

      local name="${path#./}"

      if ! element_in "--${name#'?'}" "$@"

      then

        case "$name" in

          '?'*) cmd+=( "--${name#'?'}" ) ;;

          *)    cmd+=( "--$name" "$(< "$conf_dir/$name")" ) ;;

        esac

      fi

    done 9< <(cd "$conf_dir" && find . -type f -not -name '.*' -print0)

  fi

  logged chronos "${cmd[@]}" "$@"

}

/etc/mesos/zk파일을 읽어 와서 HOST설정하는 건 알고 있었는데, CONF_DIR에 파일들에 대해서 --<파일NAME>=<파일CONTENT>형태의 OPTION을 설정해 주는 부분이 정말 흥미로웠다.

일단 CONF_DIR에 내가 필요한 옵션 이름으로 파일을 만들어서 CHRONOS를 RESTART해 보니 과연 해당 파일 내용을 읽어와서 대몬을 START시켜준다.

항상 느끼는 거지만 SHELL을 잘 사용하면 사용할 수록 개발자들의 편의성이 없어 지는 듯 싶다.

Cron 시스템을 설치 하고 난 후 한 참 후 Log파일을 보니, 

신기하게도 어떤 파일들은 Compress되서 5개 파일로 Rotate되는데 어떤 파일들은 그대로 남아 있다.

마침 궁금해 하고 있었는데 Jie가 로그가 많이 빨리 쌓이니 파일들을 Rotate해 달라고 한다.

일단 파일들을 보니 root계정으로 처리 되어 있어, root cron script를 보다 보니 특별한게 없다.

다른 사람들한테 물어봐야 하나 하고 있는데 예전에 OAS 일하면서 cron script가 /etc/cron.d 밑에도 등록될 수 있던게 생각이 나서 뒤져 보니 /etc/cron.d에 logrotate가 있고,
logrotate는 /etc/logrotate.conf 정보를 읽어 보고 있고, 최종적으로 /etc/logrotate.d/ 폴더를 읽어 오게 되어 있다.

grep으로 로그가 저장되는 폴더를 찾아 보니 드뎌 아래를 발견했다.

# cat /etc/logrotate.d/syslog

/var/log/corp/*.nzlog /var/log/corp/*.info /var/log/corp/*.warning /var/log/corp/*.crit /var/log/corp/*.notice /var/log/corp/*.err /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron /var/log/kern {
    missingok
    copytruncate
    sharedscripts
    rotate 5
    size=5M
    compress
    postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

리뷰해 보니 일반적으로 시스템에서 log rotate하는 설정에 회사 관련 로그파일들을 넣었던 것이다.

생각해보니 형태가 시스템 파일들 로테이션 하는 것과 유사 했다.

덕분에 새로운 걸 알게 되었는데, 한편으론 아직도 왜 나는 "Why"라는 생각을 가지고 뭔가 파고들지 않을까 하는 자괴심도 든다.

뭐.. Googling을 해보니 꽤 괜찮은 Article도 보인다.

http://www.ducea.com/2006/06/06/rotating-linux-log-files-part-2-logrotate/

Console 관련 업무를 시작하게 되면서 새롭게 경험하게 된 분야가 DevOps & CI 부분이다.

원래 계획은 어땠는지 모르겠지만, 

원준씨가 퇴사하면서 Chronos 부분을 인수인계 받아 진행하게 되면서 업무에 익숙해 지기도 전에 이 일을 맏게 되었다.

덕분에 지난 6개월 동안 Puppet, Jenkins, Stash 같은 여러 Tool들을 다뤄 보게 되었다.

뭐.. 어떻게 될 지 모르니 이 쯤에서 새로운 것들 정리해 보는 것도 좀 필요할 듯 싶다.

1.  Puppet

원준씨 퇴사하고 Chronos관련 업무를 맏고 나서 제일 황당했던 건 시스템을 Release하기 위해서는 Puppet Manifest를 작성해서 Production 에서 실행시켜야 한다는 거였다. 정말 황당했지만 뭐 어쩌랴. 덕분에 Puppet을 속성으로 공부해야 했고, 기존 API 시스템 Release용으로 작성되어 있던 Puppet Manifest를 수정해서 Chronos 용으로 사용하게 되었다. 업무를 하면서 어려웠던 건 선언적언어라는 패러더임과 AppNexus의 Coordination 시스템과의 연계 부분을 알게 되는게 많이 힘들었다.

2. Jenkins

예전에 대권이 Jenkins를 처음 소개 했을 때는 좋은 툴이라는 생각, 그리고 관련 업무는 대권에게 다 맞겼었다.

근데 Chronos 에 올라가는 Application들은 내가 관리하게 되니 해당 Application관련 Jenkins Job은 내가 다 작성해야 했다.

다행히 지금까지는 API팀에서 사용하던 코드들이 넘어 오는 상황이라 API팀이 작성했던 Jenkins Job을 Copy해서 시스템에 적용해 나갔다.

근데 Jie가 Master뿐만아니라 개발 branch의 update시에도 실행되는 Jenkins  Job을 작성해 달라 한게 좀 Research가 필요했다.

우선 Jenkins의 branch부분을 *으로 처리해서 Job을 등록했더니 git checkout시 계속 문제가 생겼다.

알고 보니 Jenkins  Git Repositories 부분의 Repository Name을 비어놓았더니 Jenkins가 remote 이름을 아무이름이나 부여해서 ${GIT_BRANCH}에서 나오는 origin/<branch name>을 인식하지 못하는 것이었다.

Source Code Management -> Git -> Repositories -> Advanced -> Name을 "origin"으로 수정하고 나니 우선 문제 해결.

이제는 master를 제외한 나머지 branch에 대해서만 실행하는 방법을 찾아야 했는데 찾아 보니 하나의 Article이 나왔다.

http://stackoverflow.com/questions/21314632/how-to-exclude-git-branch-from-building-in-jenkins

Source Code Management-> Git 부분의 전체 정보를 master에 맞추어 작성하고, Additional behavior에 Inverse 를 선택해주면 master이외에 다른 branch에 대해서 실행이 된다는 것이다.

나름 테스트 해보니 master제외한 다른 branch에 대해서 실행은 되는데 코드가 수정이 되지 않아도 Polling Schedule시점에 마지막으로 실행되었던 branch기준으로 계속 테스트가 실행이 되는 것이다.

그래서 곰곰히 Help Doc을 읽어 보니 branch부분이 정규식을 지원한단다. 

그럼 master를 제외하는 정규식을 설정하면 되겠다 싶어서 :^(?!.*master).*$ 를 넣어 보고 테스트 해보니 master이외의 branch가 Update될때 잘 실행이 된다.

결론적으로 master이외의 branch에 대해서 Auto test를 수행하려면 

1. Source Code Management 의 Git설정시 Name부분을 origin으로 설정하고, 

2. Branches to build를 :^(?!.*master).*$ 로 

3. Build Trigger -> Poll SCM 부분을 H/3 * * * *으로 설정하게 되면 

Jenkins가 3분마다 git을 Polling하여 수정된 branch가 있을 경우 해당 branch에 대해서 Jenkins job을 수행하게 된다.

3. Stash Jenkins연동

기존 코드의 Migration이 어느정도 진행이 되자 Jie가 이젠 master branch업데이트 되는 걸 PR로만 진행할 수 있게 하자고 한다.  당연히 할 일이긴 한데, PR할때 Test를 실행하게 해달라고 한다.

생각해보늬 DevOps가 Puppet manifest수정  자동 승인시 Jenkins build진행시키는게 생각이 나서  corpwiki와 DevOps팀의 Jenkins Job을 참조해서 아래와 같이 진행했더니 PR이 생성시  Jenkins Job을 실행 할 수 있게 되었다.

1. Stash설정 - Stash의 Project 설정의 Hooks화면의 "Stash Webhook to Jenkins"를 설정한다.

2. Jenkins

   Git의 Refspec부분을 +refs/pull-requests/*/from:refs/remotes/origin/pull-requests/*/from +refs/heads/*:refs/remotes/origin/* 로 설정하고, Post Build Actions에 Notify Stash Instance를 설정하면  PR 생성시  Jenkins job이 실행되고 결과도 PR로 전달된다.

개발 관련되서는 많이 공부하고 있었으면서도 CI/CD에 대해서는 조금 뒤쳐저 있었었는데 이번에 Chronos관련 업무를 맞게 되면서 많은 것을 공부하게 되어서 나름 유익한 경험이었다.

미리 좀 준비 할 여유가 있었다면 더 좋았을 텐데 말이지만...