컨퍼런스

T아카데미 토크ON세미나 84차 젠킨스를 활용한 CI/CD 파이프라인

와니's(Wani) 2020. 10. 23. 00:14

도입부

유튜브 채널인 T아카데미를 구독을 해놔서 가끔 연관 동영상이 올라올때가 있다.
과거 리눅스 기초나, 애자일 프로세스 방식과 같은 기본을 익히기 위해 보았다.
그런데 이번 주제가 Jenkins를 이용한 CI/CD환경 구축이였다.

T아카데미 교육

컨퍼런스 참석 이유

CI/CD환경 구축을 위해 참석을 했다.

우리 회사는 현재 cafe24에서 php로 호스팅을 하여 서버를 구축하고 있었다.
하지만 호스팅의 부작용은 한두가지가 아니였다.
예를들면 인접 서버가 디도스 공격을 받음에 따라 같이 서버가 죽어버리는 현상도 있었고,
어느 권한 이상의 작업을 하지 못하는 경우가 허다했다.
또한 어플리케이션 사용자가 급격하게 늘어남에 따라 우리가 직접 제어할수 있는 서버가 필요했다.
그래서 AWS환경으로 옮기기로 마음을 먹었고, 그에 따른 지식이 필요했다.
특히 우리는 php여서 FTP를 사용해 직접 업로드를 하는 방식을 썼는데, 힘든일이 많았다.

이 이유는 과거 인턴을 했던 회사에서 대부분의 개발자가 이런 방식을 알려줬다.
지금 와서 생각해보면 엄청 위험한 발상이 아닌가?

그래서 우리는 CI/CD환경이 필요했고 그중 여러가지 대안책이 나왔지만,
제일 유명한 젠킨스를 사용하자고 했다.

 

꽤나 좋았던 현장

공덕역 4번출구에 있는 front원 건물에서 진행을 했는데,
4층만을 사용했지만 그 건물은 여러 기업들이 참여해서 스터디 공간으로 사용하는 건물인것 같다.
꽤나 좋았다. 참여한 사람들에게 간식도 줄뿐만 아니라
과거 교재로 사용했던 책을 나누어 주었다.

 


예전에 사려고했다가 사지 못한 SQL책과 Java의 정석을 들고왔다.
그후 몇분뒤 강사님의 소개와 이어서 강의가 시작되었다.


강사님의 약력으로는 블록체인 업체에서 백엔드 엔지니어로 활동을 하다가 가상화폐거래소의 ETL파이프라인 구축경험이 있었다.
젠킨스랑 CI/CD 환경을 AWS내 클라우드 환경에서 구축을 담당했다.

 


이번 강의의 목표는 CI/CD 환경을 이해하고 그 기본개념과 동작방식을 이해후 젠킨스의 파이프라인을 구축하는 것이다.

CI란 무엇인가?

Continuous Integration 이라고 지칭을 한다.
많은 의미이겠지만, 직관적으로 여러 개발자들의 코드베이스를 계속 통합하는것 이다.
여러명의 많은 개발자가 로컬환경에서 개발을 하는데 그 코드들을 합쳐서 소비자에게 내놓아야 한다.
하지만 사람이 일일이 만나서 코드의 차이가 있는걸 merge해서 배포하는것이 아니라
카피해서 지속적으로 빠르게 배포하기 위함이다.

CD란 무엇인가?

Continuous Delivery 이라고 지칭을 한다.
사용자에게 제품, 서비스를 지속적으로 배달한다. 그리고 코드베이스가 항상 배포가 가능한 상태를 유지하는것을 말한다.
또한 사용자 뿐만 아니라 우리 내부소비자 (QA , FrontEnd 개발자, 관리자)들을 코드를 사용할 수 있게 배포를 다룬다.
궁극적으로는 개발자가 코드를 작성했는데 내부에서 일어나는것은 모르고 내 코드를 사용자들이 쓰는게 목적이다.

Continuous Deployment
옛날에는 엔지니어가 붙어서 서버가 내려가지 않고 버전을 바꾸는것을 말한다. 서버가 끊기지 않고 배포하는것을 목적으로 했는데,
현재는 클라우드가 보통 서비스를 제공해준다. 예를 들어서 ECS는 블루그린 배포를 자동으로 해준다.

다시말해 CICD란 개발자들이 개발하는 코드들을 사용자들에게 지속적으로 배포되고 단순하게 코드만 작성하는것이 아니라
테스트하고, 언어를 빌드하는 일련의 작업들을 자동화 하는것이다.

CI는 왜 필요한가?

예를들면 10명의 개발자가 열심히 개발을 한다. 하지만 깃을 사용해봤으면 알겠지만 머지할경우 헬파티가 열린다. 그뒤 다른사람이 코드를 푸시했는데?!
누군가 사고를 쳤다. 마지막 커밋이 누군지 수색을 한다. 여기저기서 개발한걸 갑자기 합치니까 문제가 생긴다.
하지만 CI를 통해서 매일 코드를 작성하자마자 합치면 개발자들이 남탓을 하는게 아니라 멘탈의 평화가 찾아온다.
CI를 하게되면 코드를 작성하고나면 내 레포지토리를 믿을수 있게 된다.

CD는 왜 필요한가?

백엔드 코드를 개발하고 프론트와 협업을 하는데 예를들면 1주일동안 스크럼하고 배포를 하게되는데 이 스크립트들이 엄청나게 많이 필요하다.
결국 담당자가 배포를 하는데 너무 힘들어진다. 그렇게 되면 결국 실수가 많아지면서, 개발자들이 울게된다.
CD와 함께라면 이 일련의 일들이 자동화가 되어서 멘탈이 회복된다.

젠킨스 넌 누구냐!

젠킨스는 귀찮은 작업들을 해준다. 비서같이 생겼다고 해서 귀찮은걸 다해준다.
자바 런타임에서 동작을 하는데, 만약 없다면 도커 배포판을 쓴다.
젠킨스는 우리의 귀찮은 일을 다 해주는 시종과 같은 존재라서 빌드 배포 테스트까지 다해준다.
우리는 코드로 개발만 한다.

  • 기본개념
    • 자바 런타임에서 동작한다.
    • 젠킨스에서 도는 다양한 플러그인들을 조합해서 사용할수있다.
    • AWS배포도하고, 도커빌드도하고, 코드 테스트도 하고,
    • 이것들을 하나의 플러그인으로 만든것이다.
    • KEY들도 관리를 해준다.
  • Plugin
    정~~말 많은 플러그인들이 존재한다. 그중 많이 쓰는 플러그인들이 있는데
    깃플러그인, 파이프라인플러그인, 크리덴셜플러그인 등이 있다.

젠킨스 실습에 앞서.

파이프라인은 무엇인가?

개발자들이 코드를 작성하면 빌드(웹팩 ,타입스크립트컴파일, 자바컴파일 등)를 하고 테스트(jest, junit)를 하고 배포(ECS Rolling)를 하면 사용자들이 사용하는것이다.
물흐르듯이 흘러간다는 뜻에서 파이프라인이라고 지칭을 했다.
CI/CD파이프라인을 젠킨스에 구현하기 위한 일련의 플러그인들의 집합이자 구성으로 지칭한다.
여러 플러그인들을 이 파이프라인에서 용도에 맞게 사용하고 정의함으로써 파이프라인을 통해 서비스가 배포된다.
Pipeline DSL(Domain Specific Language)로 작성을 한다.

파이프라인을 구성하는 요소!

두가지 형태의 Pipeline Syntax가 존재(Declarative, Scripted Pipeline)
우리는 최신이자 더 가독성 좋은 문법을 가진 Declarative Pipeline syntax 를 사용 한다.

PipeLine Syntax에는 무엇이 있는가!

  • Sections: 하나 이상의 Declarative나 Steps를 가진다.
    • Agent Section
      • 젠킨스는 많은 일들을 해야하기 때문에 혼자하기 버거워진다.
        여러 slave node들을 두고 일을 시킬수가 있다.
        어떤 젠킨스가 일을 하게 될것인지 정할수가 있따.
    • Post section
      • 스테이지가 끝난 이후의 결과를 통해서 후속 조치를 취할수가 있다.
      • 예를들면 성공시 성공메시지
    • Stages Section
      • 어떤 일들의 처리할것인지 일련의 스테이지들을 정의한다.
    • Steps
      • 한 스테이지 안에서의 단계로 일련의 스텝들을 보여주게 된다.

개발환경 구성을 알아보자.

  • 개발자가 개발을 하는 로컬환경이 있다.
  • 개발자들끼리 개발을 한 개발 내용에 대한 통합 테스트를 하는 개발 환경이 있다.
  • 개발이 끝나고 QA엔지니어 또는 내부 사용자들이 이용해보기 위한 QA환경이 있다.
  • 실제 유저가 사용하는 Production 환경이 있다.
  • 쉽게 DEV, QA, PROD 환경으로 부르는 관례가 있다.

간략한 개발 프로세스

  1. 개발자가 자신의 PC에서 개발을 진행한다.
  2. 다른 개발자가 작성한 코드와 차이가 발생하지 않는지 내부 테스트를 진행한다.
  3. 진행한 내용을 다른 개발자들과 공유하기 위해 GIT에 푸시한다. 흔히 Dev브랜치에 푸시를 한다.
  4. Dev브랜치의 내용을 개발 환경에 배포하기 전에 테스트또는 Lint등 코드 포맷팅을 하게 된다.
  5. 배포하기 위한 빌드과정을 거친다.
  6. 코드를 배포한다.
  7. 테스트를 진행한다.
    1 위의 모든 과정을 DEV, QA, PROD 환경에서 모두 진행하고 각각에 맞는 환경에 배포를 하게 된다.

강사님이 알려준 꿀팁

  1. 우리는 흔히 AWS에서 배포를 하게 되면 같은 ROOT아이디에서 여러가지 IAM을 뿌려서 진행을 하게 된다.
    하지만 이는 위험할수도 있다. 그래서 자신의 회사에서는 DEV , QA , PROD환경의 아이디를 각각 만들어서
    따로따로 사용을 한다.
  2. 위와 같은 환경을 구성하기 위해서 테라폼과 같은 서비스를 사용한다.
  3. 젠킨스는 여러 환경변수는 필요가 없고 자신이 어떤 환경인지만 알면 된다.
    • DEV
    • PROD
    • QA
  4. 젠킨스가 이걸 알면 알아서 배포하고 그 환경에 맞는 환경변수는 코드레벨에서 관리를 한다.
    • 예) 스프링부트 properties에 담긴 데이터베이스 커넥션은 따로따로 관리를 해서 알맞게 쓴다.
  5. 환경변수를 더욱이 잘 쓰고싶으면 AWS System Manager를 쓰자
  6. 멀티 배포환경을 어렵게 생각하지 말고, 각각 환경에서 차이가 나는게 무엇인지 알아보자
  7. 하지만 싸게싸게 하고싶으면 한개로 잘 관리를 하자.
  8. 요즈음에는 서비스 뿐만 아니라 인프라도 CI/CD를 한다.

'컨퍼런스'의 다른글

  • 현재글T아카데미 토크ON세미나 84차 젠킨스를 활용한 CI/CD 파이프라인

티스토리툴바