<aside> 💡 GitLab Runner, Jenkins, Kubernetes를 지나서 결국 현재 Pikurate 서비스에 맞는 가장 적절한 CI 환경 구축은 Jenkins라고 결론을 내렸고 DEV 서버의 Jenkins 환경을 구축하는 과정을 다음과 같이 정리하였다.

</aside>

Jenkins SSH plugin 도입

기존의 서비스에서 Jenkins를 이용한 CI가 어려웠던 것은 레거시 코드로 인한 배포환경의 권한 문제라고 할 수 있다. 즉, Jenkins 유저를 새당 배포 서버에 설치하여 권한을 받아 pull과 supervisor를 사용하는 것에 문제가 생겼기 때문이다.

이 문제를 SSH 플러그인을 통해서 해당 서버에 접속하여 명령어를 실행하는 효과를 내도록 하여 CI를 구축하고자 한다.

[Jenkins] [ec2] Jenkins 원격 서버 배포(Publish Over SSH)

• [x] Jenkins 도메인 및 https 연결

  Jenkins 서버 설치 shell 파일

  간단하게 terraform으로 구축

  server와 같은 도메인에 설정

• [x] GitlabJenkins Token 생성

  • GitLab에서 Access Token을 발행한다.

    Access Token:

  • Jenkins 관리 > Credentials > global 선택

    • Jenkins Credential GUI
    • Username: gitlab ID
    • password: PW 혹은 GitLab Access Token
    • ID: Jenkins 내에서 사용할 아이디

  <aside> 💡 Credential 설정을 맞추었는데도, git ls-remote <git_address> 에러가 발생한다면 jenkins 서버에 git이 설치되어 있는지 확인을 하도록 하자...

  </aside>

• [x] Pipelin 생성

  • 추후 GitLab Webhook과 연동을 위한 Build Trigger 설정

    

  • 고급 설정을 통해서 비밀 키를 받는다.

    Jenkins Secret Token: 84dd8f17e2eab3012fbbf5df9c9afd5f

  • Jenkins의 Pipeline을 어떤식으로 구축할 지 정하는 방법

    

    Jenkinsfile의 위치를 정확히 기입해준다.

• [x] Build Now를 통한 테스팅

  

  stage view를 확인할 수 있다.

• [x] SSH plugin을 이용하여 SSH 접속 환경 만들기

  • 먼저 Jenkins 플러그인에서 Publish Over SSH를 다운 받는다

    

  • 환경설정 > 시스템 관력 > Publish over SSH

    

    SSH 접속을 위한 기본적인 옵션 설정을 진행하자

    • Passphrase: SSH 접속시 암호를 요구하는 경우, 필요한 암호를 입력하는 부분

    • Path to key: SSH의 대상이 되는 private key의 경로에 해당한다.

      read 부분에서 에러가 발생한다면 chmod를 이용해서 읽기 권한을 부여한다.

    

    서버의 접속과 관련이 있는 부분이다.

    • 기본적으로 ssh의 config 파일을 작성하는 부분과 동일하다
    • 작정을 완료하였을 경우 가장 밑의 Test Configuration을 클릭하여 접속 테스트를 할 수 있다.

• [x] Test Job만들기

  기존의 계획했던 부분과 달라진 점은 Pipleline이 아닌 Freestyle Job으로 진행을 하는 방향으로 바꾸었다. 이유는 다음과 같다.

  1. SSH 접속을 플러그인을 이용해서 간편하게 진행간으
  2. Container 기반의 환경이 아니기 때문에 파이프라인에서 복잡한 구조가 필요하지 않다.

  먼저 Freestyle Job을 만들고 "빌드 후 조치"에 "Send build artifacts over SSH"를 선택하여 SSH 접속 이후에 실행할 명령어를 입력한다.

  • 참고 사진

  단, 참고해야할 상황은 Jenkins에서 제공하는 콘솔에서는 SSH 이후의 상황에 대한 로그를 제공하지 않는다. Exec란에 system의 작동여부를 echo를 이용해서 로그에 대한 이슈를 해결하는 것도 좋을 것으로 보인다.

  

• [x] 테스팅하기

  SSH에서 Jenkins가 실행하길 바라는 부분은 다음과 같이 요약할 수 있다.

  1. gill pull origin <target branch>
  2. supervisorctl restart all

  먼저 위 두 명령어를 실행하기 위해선 권한이 있는지 확인을 해야한다. 이를 위해서 SSH 서버에 접속을 하였을 때, id > test.txt를 이용해서 접속 유저가 누구인지 확인하자

  

  admin 유저이기 때문에 별다른 제한없이 명령어 사용이 가능할 것으로 판단 하였다.

• [x] Job 만들기

  cd djangoapp/
  
  echo "-------------------------------------------" >> jenkins.txt
  echo date >> jenkins.txt
  git pull origin release
  sudo supervisorctl restart all 
  sudo supervisorctl status all >> jenkins.txt
  

  아래의 형식으로 아주 간단한 CI 코드를 작성하였다.

  

  아래와 같은 느낌으로 만들어진 것을 볼 수 있다.

• [x] GitLab Webhook

  현재 진행중인 dev 서버의 경우는 release 브랜치에 직접적인 push가 일어나지 않기 때문에 MR이 보내질 때만 Webhook이 가도록 설정하였다.

  

  MR인 상황에서 Webhook이 일어나도록 바꾸었다

  

  Webhook에 잘 반응하여 Jenkins가 실행된 것을 볼 수 있다.

  

  로그도 적절하게 잘 나온 것을 볼 수 있다.

보완사항

일단 Pikurate 엄무를 하면서 발생할 수 있는 MR은 크게 두가지로 나뉠 수 있다.

• feature/* → develop
• develop → release

Jenkins에서는 release 브랜치를 바라보도록 설정하였기 때문에 trigging이 되더라도 release에 변화가 없는 한 문제가 없지만, supervisorctl restart all 명령어가 매번 실행이 될 것이다. 일단 지금 상황에서는 문제가 없지만 사용자가 많아짐에 따라서 사이 시간에서 누락될 수 있는 데이터 컨트롤에 대한 고려가 필요해질 것으로 보인다.

추가적으로 python 패키지를 써야하는 경우 바로 빌드를 하는 상황에서 문제가 발생할 수 있다. 이 문제는 pip install을 파이프라인에 명시 하는 것도 필요할 것으로 보인다.