최종 아키텍쳐 이제 CI부분까지는 완료됐으니, 배포 부분 yml만 작성해주면 끝이다. 먼저 빌드 부분 yml 파일을 작성하기 전에 러너를 선택해야되는데, 깃허브 액션의 기본 러너를 사용하면 깃허브 액션을 실시할 때마다 러너의 IP가 바뀌기 때문에 서버의 인바운드 규칙을 설정하기가 상당히 애매해진다. 따라서 내 서버를 러너로서 사용하는 self-hosted runner를 선택했다. Self-hosted 러너 설정 actions ➡️ runners ➡️ new self-hosted runner를 선택해준다. 배포 서버의 운영체제에 맞게 선택해주고, 하단에 있는 스크립트들을 배포서버의 배포 폴더에서 실행시켜 주면 준비 끝! Self-hosted 러너 테스트 name: nsfServer Github Action..

지난번 젠킨스에 이어, 이번엔 github action을 활용해 CI/CD를 구축해보자. 먼저 CI (Continuous Integration) 환경을 구축하는 법을 알아보자. 구축하고자 하는 최종 아키텍쳐는 다음과 같다. CI/CD 학습용이기 때문에 EC2 하나로 구현을 시도하였다. 그러나 추후 여러 문제로 인해 green group을 위한 ec2 서버를 추가하였다. (무중단 배포 불가능한 이슈) github action 시작하기 github 프로젝트 ➡️ actions에서 workflow를 하나 작성해준다. 기본 workflow를 다음과 같이 수정해준다. 필자는 프로젝트에서 mysql 설정을 [application-mysql.properties](http://application-mysql.prope..

구축하고자 하는 최종 아키텍쳐는 다음과 같다. 3편까지 모두 따라하고 나면 다음과 같은 아키텍쳐를 구축하게 된다. (단, 추후 EC2가 한 개 더 필요해진다.) 먼저 이번장에서는 스프링으로 구축한 서버를 nginx로 로드밸런싱 하는 부분을 다뤄볼 것이다. 이번 장에서 목표로 하는 아키텍쳐는 다음과 같다. 위 그림이 현재 목표인 아키텍쳐이다. (물론 최선은 각각을 하나의 EC2에 두는 것이다.) Docker를 사용해 한 컴퓨팅 자원에서 웹서버와 WAS를 분리한다. 각각의 이미지가 분리되어있기에 인프라 구축에 용이하다. Nginx를 사용한 로드 밸런싱 서버로 들어오는 요청을 8081,8082에 띄워진 두 WAS로 나누어 부하를 분산시킬 수 있다. 무중단 배포 배포 시 하나의 서버에 배포를 진행한다면 반드시 ..

Github to Jenkins Webhook 설정하기 깃허브에서 Webhook 설정 깃허브의 프로젝트 ➡️ settings➡️Webhooks ➡️Payload URL에 Payload URL을 '{Jenkins 서버IP:PORT}/github-webhook/'로 적은 후 저장한다. Webhook 테스트 저장 후 Recent Deliveries 탭에서 Webhook을 보내고 정상적으로 되는지 확인한다. 젠킨스 Jenkins Job 설정 Github에서 Webhook을 보내고 Jenkins가 수신하는 것까지 완료된 것이고 Webhook을 받았을 때 자동으로 Jenkins Job이 실행되도록 하려면 Jenkins Job 설정에서 Github hook trigger for GITScm polling 체크박스를 ..

문제 상황 젠킨스에서 빌드를 할 때, 내려받고자 하는 레포지토리에 lfs 파일이 있다면 (사이즈가 굉장히 큰) 내려받지 못하고 다음과 같이 에러가 발생했다. stderr: Downloading google-chrome-stable_current_amd64.deb (86 MB) Error downloading object: google-chrome-stable_current_amd64.deb (d6bb13a): Smudge error: Error downloading google-chrome-stable_current_amd64.deb (d6bb13aad7c0a2b026b8b36d2e8a74f9bf66fe64610ce12fbbd23b4325699da7): batch request: git@github.co..

지난 포스팅들에서는 도커와 젠킨스의 기본 환경 설정을 했다면, 이번 포스팅에서는 실제 파이프라인을 구축해보겠다. docker start jenkins docker exec -it jenkins /bin/bash 혹시 젠킨스를 재실행할 상황이 온다면 위 스크립트를 실행하면 된다. (run 명령어는 재설치이므로 유의) 젠킨스와 깃허브 연동 젠킨스의 메인 페이지이다. 왼쪽 네비게이션에서 새로운 item을 클릭해준다. item name을 적고, Freestyle project를 선택해준다. 이제 상세 설정의 소스 코드 관리 탭에서 Repository URL을 적어주면 되는데, 여기서 한 가지 의문이 든다. 바로 우리 프로젝트의 Repository는 private 레포이기 때문이다. 따라서 gitHub와 Jenk..

2023.10.21 - [분류 전체보기] - [CI/CD] - 도커와 젠킨스를 사용한 CI/CD -1 (도커의 설치부터 자동배포까지) 도커의 설치와 기본 세팅은 위 포스팅에 정리되어있다. 젠킨스 이미지 다운 docker pull jenkins/jenkins:lts 먼저 docker 명령어를 이용해 jenkins 이미지를 다운받는다. docker images 를 통해 내가 다운받은 이미지 목록을 볼 수 있고, 이렇게 젠킨스가 잘 다운된 것을 확인할 수 있다. 젠킨스 이미지를 컨테이너화 docker run -d -p 8088:8080 -v /jenkins:/var/jenkins_home --name anna_jenkins -u root jenkins/jenkins:lts 이제 젠킨스 이미지를 컨테이너에 올려..

오늘은 window wsl2 ubuntu18.04환경에서 도커를 설치하고, 젠킨스를 이용해 자동 배포 파이프라인을 구축해 볼 예정이다. 자동 배포의 필요성 기존 팀 프로젝트의 work flow는 다음과 같았다. 각자 기능 구현 후 PR EC2 서버로 접속 github에 merge된 코드를 git pull gradle을 이용해 build jar파일을 java -jar 명령어를 통해 80번포트에 실행 이 1번~ 5번 과정이 서버 배포의 플로우이고, 서버 배포는 매번 기능이 추가 될 때마다 시행되어야 한다. 이 flow는 새로운 기능마다 바뀌는 것이 아니기에, 자동화 할 수 있는 대상이다. 이를 자동화하여 최신상태의 코드가 자동으로 배포되도록 하는 것을 Continuos Distribution, 지속적 배포라..