CI/CD (Github Actions와 Jenkins 비교)
이전 포스팅에서 AWS EC2에 도커 이미지화 한 프로젝트 배포를 진행해 보았다.
이번 포스팅에서는 EC2 지속적 통합과 지속적 배포를 하기 전 조사 과정을 담아보았다.
CI/CD란?
CI(Continuous Integration)
지속적 통합을 의미. 빌드/ 테스트 자동화 과정
CD(Continuous Deployment or Continuous Delivery)
지속적 배포 지속적인 서비스 제공을 의미. 배포 자동화 과정
CI/CD 종류
Jenkins, CircleCI, TravisCI, Github Actions 등등
Jenkins 와 Github Actions 비교
| Jenkins | Github Actions |
| 무료 오픈소스. 빌드, 테스트, 배포와 관련된 소프트웨어 개발 부분을 자동화하고, 지속적인 통합과 지속적인 배포를 제공한다. |
Github에서 SaaS(Software as a Service, 서비스로서의 소프트웨어) 제품으로 제공하는 최신 기능 |
| 서버 설치 필요 | 클라우드에서 동작 |
| 동기적 (제품을 배포하는데 더 많은 시간 소요) | 비동기 CI/CD 가능 |
| 계정과 트리거에 기반, Github 이벤트 처리할 수 없음 | Github이벤트에 대해 Github Actions를 제공 |
| 환경 호환성을 위해 Docker 이미지에서 동작해야 함 | 모든 환경에 호환됨 |
| 캐싱 기법을 위해 플러그인 제공 | 캐싱이 필요하다면 직접 캐싱 매커니즘을 작성해야 함 |
Github Actions를 사용할 경우
1. S3에 코드를 올리고(저장하고) AWS CodeDeploy를 통해 빌드하고 EC2에 배포하는 방법
2. 도커 이미지를 Github Container Registry를 이용해서 빌드하고 EC2에 기존 이미지 삭제 후 새로운 이미지 바로 올리는 방법
https://codegear.tistory.com/84
Jenkins를 사용할 경우
EC2를 두 대를 두고 진행.
하나는 젠킨스, 도커를 설치하여 젠킨스 서버로 사용하고, 하나는 프로젝트가 실행되는 서버로 둔다.
[공부 후기]
지금 당장 AWS EC2에 올라가는 프로젝트는 하나이지만,
결국 나중에는 온프레미스로 올라가있는 프로젝트도 AWS로 넘어가려고 한다 하셨기 때문에,
젠킨스 서버를 하나 만들어서 EC2 두 대를 두고 진행해 보아야겠다.
아무래도 경험이 많지 않다보니, 지금 판단이 틀릴 수도 있지만
일단 해보고 또 틀렸으면 틀린 걸 통해서 배우고 그래야겠다!
여담으로 S3가 Simple Storage Service의 약어라는 걸 엊그제 책 읽으면서 알게 되었다
세상에 S3가 그냥 당연히 S3인줄만 알았는데 역시 늘 무언가 하나씩 알게 되는 과정은 참 즐겁다.
Reference
[참고1] EC2 젠킨스 이용할 때 설계
[참고2] Github Actions vs Jenkins
[참고3] CI/CD 설명
https://seosh817.tistory.com/104