본문 바로가기

전체 글44

1. Jenkins 란? Jenkins 같은 녀석들을 CI/CD 도구라고 부른다. CI/CD 는 뭐야..?? (구축하다보면, 산넘어 산이다.. 이걸 하고 싶은데 이걸 하기 위해서는 또다른 무언가를 알아야 되고, 또다른 무언가를 알기 위해서는 또또다른 무언가를 알아야 되고.. 하…..) CI (Continuous Integration) 한글로 “지속적 통합” 이라고 한다. (대부분이 그렇듯이 한글로 바꾸면 없어보인다) 위키에 잘 설명되어 있다. (위키백과: 지속적 통합) 한줄 정의 : 모든 개발자가 소스를 받았을때 에러 없는 상태의 소스코드를 관리하는 것 팀원이 많아질수록 코드의 변경량이 많아지고, 누군가가 일일이 감시하지 않는한 문제가 되는 코드가 들어올수밖에 없다. 이를 사람이 일일이 모니터링 하는것은 불가능하다. CI는 개발.. 2024. 3. 14.
2. Jenkins Install 1. Jenkins download 먼저 설치파일을 다운받아야 한다. Jenkins download and deployment 설치하려는 서버의 OS 에 맞는 SW를 다운로드한다. Jenkins 홈페이지에 친절하게 install 과정이 설명되어 있다. 우리 서버는 Ubuntu 니 Jenkins book 에 Linux 페이지를 참고해서 설치하면 된다. curl 을 통해 LTS 버전 설치 curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \ /usr/share/keyrings/jenkins-keyring.asc > /dev/null echo deb [signed-by=/usr/share/keyrings/jenkins-.. 2024. 3. 14.
3. Jenkins 에서 Gerrit 프로젝트 빌드하기 Jenkins 에 새로운 프로젝트를 생성하고 빌드하는 방법에 대해 알아보자. gerrit 의 memore_client repository 를 예시로 설명한다. 1. http://xxxx.xxx (셋업한 젠킨스서버의 주소) 로그인 → 홈화면에 [+ 새로운 Item] 선택 2. 원하는 이름 넣고 → Freestyle project 선택 → OK 이제 프로젝트 설정을 채워야 한다. 3. 소스코드관리 → Git 선택 Git repository 설정이 펼쳐진다. 하나씩 보자. 3-1) Repository URL Git 저장소의 URL 주소 : memore_client 의 repository 정보를 적는다 (모르겠으면 gerrit 에서 clone 명령어를 보면 된다.) ssh://AriGerrit@review.ar.. 2024. 3. 14.
4. Jenkins 에서 Gerrit Review 특정 브랜치만 빌드 Gerrit 이 인기가 없는건지, Github 에 대한 자료는 많은데 Gerrit 은 의외로 개발자들이 참고할만한 블로그나 설명이 많지는 않다. 나같은 삽질 개발자들에게 조금이라도 도움이 됐으면 좋겠다. :) 오늘은 간단하게 팁 하나만 공유하려고 한다. 젠킨스 형님이 일을 너무 잘해서 게릿에 리뷰가 등록되기만 하면 무조건 트리거돼서 빌드를 돌린다. 그런데 일을 하다보면 특정 브랜치만 빌드를 돌리게 하고 싶을때가 있다. 우리팀 같은 경우는 리뷰를 등록하고 젠킨스 형님이 빌드해서 Build Successful 커멘트를 남기고 Verified +1 점을 주면 자동으로 Slack 에 리뷰 요청글이 등록되게 되어있어서, 테스트 커밋이나 아직 리뷰 요청할 단계 이전의 커밋들도 무조건 리뷰 요청 메시지가 간다. 그럼.. 2024. 3. 14.
5. Pipeline 프로젝트 앞에까지 simple project 하나를 만들어서 빌드하는것을 해보았다. 하지만 Jenkins 형님의 진정한 매력은 pipeline 에 있다. 말은 거창하지만 파이프라인이래야 여러가지 타스크를 직렬/병렬로 수행하는것에 불과하다. 따라서 작업이 필요한 경우에 한해서 진행하면 된다. 보통 프로젝트를 빌드하게 되면 아래와 같은 단계들이 생긴다. (내 경우) 1. pre build step (빌드 전 단계) 2. build step (빌드 단계) 3. test (유닛 테스트) 4. statci anaysis (정적 분석) 5. post build step (빌드 후 단계) 이런 일련의 작업들을 젠킨스 파이프라인을 이용하면 하나의 젠킨스 프로젝트에서 수행 할 수 있다. 1. pipeline 프로젝트 생성 역시나.. 2024. 3. 14.
6. Pipeline project - pipeline script pipeline 프로젝트 구성 마지막에 pipeline script 를 설정하면 이제 pipeline 문법을 이용해서 pipeline 을 구성할 수 있다. 이를 위해서 앞장의 마지막에 pipeline syntax 이전까지 살펴보았다. 이제 pipeline syntax 를 누르게 되면 아래와 같은 페이지를 만나게 된다. 여기서 뭘 어떻게 해야되지? 라는 막막한 생각이 들수 있는데, 당황하지 말고 영어를 찬찬히 읽으면 된다. Snippet Generator 라는 부분으로 원하는 액션에 대해서 Pipelien syntax (정확히는 Groovy 문법) 를 자동으로 만들어주는 역할을 한다. 예를들어, 빌드 후에 마지막으로 산출물을 저장하는 액션을 하고 싶다고 가정하자. 이는 물론 파이프라인이 아니어도 할 수 있.. 2024. 3. 14.
7. Pipeline project - pipeline script from SCM (1/2) 이 방법은 젠킨스 프로젝트에 pipeline 명령어를 설정하는게 아니고 소스 코드 프로젝트에 pipeline 명령어를 셋업하는 방식이다. 즉 젠킨스가 빌드할 소스 코드의 Jenkinsfile 이라는 파일을 하나 만들어서 거기에 필요한 명령어들을 셋업하면 된다. 이 옵션을 선택하면 아래와 같은 화면이 나오고, SCM 부분에서 Git 을 선택해주자. 선택하고 나면 Freestyle 때 접했던 익숙한 셋팅 화면을 만나게 된다. 감이 오죠? 이전 옵션(Pipeline script)는 웹상에서 명령어를 구성하는 반면 이 옵션은 소스코드 상에서 명령어를 구성하는 것이기에 파이프라인으로 빌드할 타겟 소스와 Jenkinsfile 을 셋업해주면 된다. 젠킨스는 파이프라인 프로젝트에서 기본적으로 소스 코드의 root pa.. 2024. 3. 14.
7. Pipeline project - pipeline script from SCM (2/2) 이제 다 왔다. 맨 처음에 파이프라인 빌드 단계를 언급한게 기억이 나는가? 이제 이걸 진행해 보자. 앞장에서 Jenkinsfile 스크립트를 설정한 위치에 파일을 하나 만들고 Jenkinsfile 이라고 이름짓자. Jenkinsfile 의 구성은 쉽다. pipeline { agent any stages { stage('1st step') { steps { // 원하는 액션들 } } stage('2nd step') { steps { // 원하는 액션들 } } ... } post { success { // 빌드 성공시 액션 } failure { // 빌드 실패시 액션 } always { // 빌드 성공,실패 여부와 상관없이 항상 수행할 액션 } } } 이해가 쏙 되죠? 여기서 각 단계를 설명하는것은 의미가 .. 2024. 3. 14.
자동 배포 전체 개요 드디어 자동 배포 시스템 구축을 완료했다 !!!! (2023년 12월 20일 완료) 역시나 삽질의 연속이었다. 이제부터 하나씩 페이지를 만들면서 기록을 남겨보려고 한다. 그 전에, 전체적인 개요도를 먼저 공유한다. 어느정도 지식이 있는 개발자면 아래 그림만 봐도 알것 같긴 하다. 참고로 여기에 사용된 툴은 1. 젠킨스 2. Ansible 3. Docker 등이다. 크게 두가지 단계로 나뉜다. 1. ECR 에 docker image 를 push 2. ECR 에 push 된 docker image 를 EC2 로 pull 해서 run 위 구성도의 번호표를 보면서 순서대로 따라가 보자. 릴리즈 할 준비가 되었다면 1. 각 backend, frontend 의 release branch 에 최종 수정사항을 반영한다.. 2024. 3. 14.
1. ECR에 Docker image push (1/2) 앞서 얘기했듯이 , 나의 자동배포 단계는 크게 두가지 단계로 나뉜다. 1. ECR 에 docker image 를 push 2. ECR 에 push 된 docker image 를 EC2 로 pull 해서 run 1번부터 찬찬히 풀어나가 보자. 어디서부터 어디까지를 해야할지 좀 애매하지만, 열정이 풍부한 개발자들이 이 페이지를 볼거라는 생각에 최대한 자세히 쪼개보려고 한다. 1. Git 브랜치 관리 우선 Release 를 위해서는 별도의 Git brach 를 관리하는것이 좋다. 필자는 release/1.x , release/2.x , ... 로 관리하곤 한다. develop 브랜치에 반영된 커밋들중에 1. 꼭 필요한 커밋 2. 안정성이 확보된 커밋 들만 추려서 release 브랜치에 반영하고 버전업을 한다... 2024. 3. 14.
2023-11-04 근황 지금까지 여기와서 많은 일을 했다. 다른것보다 SE 적으로 한걸 늘어보면 1. Github 도입 2. Gerrithub 도입 3. Jira 도입 4. Slack 도입 (수동) ---- 5. 자체 Gerrit 도입 6. 자체 Gerrit 이랑 Jira 연동 7. Jenkins 도입 -> 자체 Gerrit 연동 8. Slack 자동 커멘트 도입 ---- 여기까지만 해도 개발자가 코딩을 하고 서버에 반영하는 수준은 충분히 커버할 수 있다. 하지만 사람의 욕심은 끝이 없는지라.... 지금까지는 CI 였다면 CD 도 하고 싶어졌다. 그리고 CI 에서도 코드 정적 분석까지 도입해서 코드의 질도 높이고 싶어졌다. 그래서...... 9. Sonar qube 도입 -> 코드 정적 분석을 통한 코드 품질 향상 10. An.. 2023. 11. 3.
티스토리 개불편 팀내 위키로 Atlassian 사의 Confluence 를 활용하고 있다. 그러나 Confluence 는 팀내에서만 공유가 가능하다. 따라서 직장내 기밀이 유지될 필요가 없는 기술 포스팅은 널리 공유하고 싶어 (나같은 시행착오로 고생을 겪는 개발자들에게 조금이라도 보탬이 되고자) 블로그를 시작했고, 내가 많이 도움을 받았었던 티스토리 블로그를 선택했다. 몇달이 지난 지금...... 티스토리 개불편하다. 많은 단점이 있지만 굵직한거 몇개만 해보면, 1. 카테고리 구분이 2depth 밖에 지원되지 않는다. Confluence 는 무한히 depth 지원이 된다. 따라서 단계적으로 무언가를 확인할때 정말 알아보기 편하다. 그러나 티스토리는 2depth 밖에 지원이 안된다. 그래서 같은 종류의 포스팅 별로 묶기가.. 2023. 11. 3.

티스토리툴바