[Jenkins] Jenkins로 CI/CD 구축해보기 - (1)

1. Introduction

• 이번 주를 지나면서 CI/CD 툴로 많이 사용할 수 있는 Jenkins를 사용해 실제 CI/CD 파이프라인을 구축하는 것을 블로그로 남기려고 한다.
• 실제로 수행했던 시간은 6/1, 6/2 2일 정도로 몇몇 문제에 대해서는 결국 해결하지 못해 플랫폼을 변경하여 구축을 완료하였다.
• 전체적인 과정과 더불어 왜 이렇게 하는가에 대해서도 공부하면서 적어보려고 한다.

 

2. CI/CD

• CI/CD라는 용어는 매우 많이 들어왔던 용어이고 놓쳐서는 안되는 용어와 개념이라고 생각한다.
• 먼저 CI는 Continuous Integration의 약어로 한국어로는 지속적 통합이라고 한다.
  • 이때 지속적 통합의 대상은 기본적으로(또한 일반적으로) 프로덕션 코드이다.
  • 하나의 프로젝트에서 개인이 모든 부분에 대해 개발을 진행하는 경우는 거의 존재하지 않는다. 결국 여러 사람들이 함께 개발을 수행하며 이로 인해 여러 사람들이 개발한 코드들이 각자의 로컬에서 존재하게 된다.
  • 지속적 통합은 이런 각자 개발한 코드들을 하나로 합치는 것을 지속 가능한 형태로 수행하는 것을 의미한다. 가능하다면 이런 행동을 자동화하는 것이 좋을 것이다.
  • 이런 통합의 과정은 코드를 빌드하거나, 테스트하는 것을 말한다.
• CD는 Continuous Deployment의 약어이며 한국어로는 지속적 배포라고 한다.
  • 이때 배포되는 것은 위의 프로덕션 코드를 빌드한 결과물을 말한다.
  • 개발을 통해 프로덕션 코드에 변경이 일어날 때 마다 이런 변경한 코드를 빌드한 결과물을 프로덕션 서버에 설치해야 하는 일이 발생한다.
  • 지속적 배포는 이런 행동을 지속적으로 수행하는 것을 의미하여 가능하다면 자동화하여 수행하는 것을 포함한다.
• 즉 CI/CD는 여러 개발자들이 개발하는 코드를 지속적으로 통합, 빌드, 테스트하고 그 결과물을 프로덕션 서버에 지속적으로 배포함으로서 서비스를 개발하는 개발자와 서비스를 사용하는 사용자 사이의 격차(Gap)을 줄이는 것이다.
  • 이러한 과정을 지속적으로, 그리고 가능하다면 자동적으로 수행되게 하는 것이 CI/CD라고 할 수 있겠다.

 

3. Jenkins

• Jenkins는 Java로 만든 오픈소스 CI/CD 툴이다.
• Jenkins를 활용하면 빌드, 테스트, 배포와 같은 CI/CD 과정을 자동화할 수 있으며 이를 통해 개발자가 이런 CI/CD에 사용하는 자원을 줄일 수 있다.
  • 또한 github와 같은 형상 관리 시스템과 연동하여 commit, push가 발생할 시 위의 CI/CD 과정을 수행하도록 트리거 설정도 가능하다.
• Jenkins는 여러 Plug-in을 활용하여 여러가지 일들을 수행할 수 있다. 이에 대해서 상세히 말하기에는 주제와 맞지 않기 때문에 이는 또 다른 Section에서 다뤄보도록 하겠다.

 

이번 주제에서 사용하는 환경에 대해 적습니다. 해당 과정을 실제 수행한 시각은 2024-06-02일 입니다.

인스턴스 : AWS EC2 사용하였습니다. 어떤 인스턴스를 사용했는지는 다음을 참고해주세요
    - Jenkins server : AWS EC2 small
    - SpringBoot Server : AWS EC2 micro

Jenkins의 경우 Docker를 사용하여 설치했습니다. 설치 버전은 LTS 버전을 활용해서 설치했으므로 시간이 지난 뒤에 해당 글에서 설치했던 Jenkins 버전과 시간이 지난 뒤에 설치한 Jenkins 버전이 서로 맞지 않을 수 있음을 유의해 주세요

빌드 툴은 Maven을 사용하였으며 3.9.7버전을 사용합니다.

 

4. AWS Instance 세팅

• AWS에서 EC2 인스턴스를 만든다.

• Ubuntu 22.04 LTS버전을 사용하였다.

• 인스턴스 유형을 t2 small로 사용했는데 이유는 메모리를 더 줘서이다.
• 메모리가 부족해 Jenkins가 정상적으로 작동이 잘 되지 않는다는 글을 많이 보았다. 어차피 이후에 swap memory를 사용하여 어느 정도 매꾸겠지만 그래도 기본 메모리가 더 있는게 좋다고 생각해 small로 사용하였다.
  • swap memory를 적극적으로 활용할 생각이 있다면 굳이 small을 사용하지 않아도 될 것 같다. micro로 변경하여 비용을 절감하는 것도 괜찮다는 생각이다.
  • 필자는 실제 서비스(디스코드 봇 서비스)를 Jenkins를 통해 배포할 생각이므로 1GB보다는 2GB가 안정성 면에서 더 좋을 것 같다는 판단을 하여 small을 사용했다.

• Jenkins는 GUI를 지원한다. 경로는 별도의 설정을 하지 않았다면 http://jenkins가 설치된 인스턴스의 ip:포트 의 경로로 들어갈 수 있는데 이를 위해서 트래픽을 허용한다.
• SSH 트래픽도 역시 허용해준다.

• 스토리지는 기본 8GB인데 2GB를 추가하여 10GB로 하였다.
  • 이유는 swap memory를 사용하여 HDD 용량을 메모리로 어느 정도 빼 놓을 건데 그러면 여유 공간이 더 줄어드므로 줄어드는 용량만큼 매꿔야 하겠다고 생각했기 때문이다.
• 이후 생성을 눌러주면 인스턴스가 생성될 것이다.

 

4-2. 보안 그룹 설정

• 처음 AWS를 사용하는 사람들이라면 인스턴스를 사용하기 전에 확인해야 하는 부분이 있다.

• 보안 그룹으로 들어가 각 인스턴스들이 어떤 포트를 뚫어놓을 것인지를 설정을 해주어야 한다. 만약 이런 설정을 하지 않았다면 방화벽에서 해당 포트로의 요청을 모두 차단할 것이다.
• 우리가 뚫어줘야 하는 포트들은 3 ~ 4개 정도가 되겠다.
  • http 사용 포트인 80 포트
  • https 사용 포트인 443 포트
  • Jenkins에서 사용할 8080포트
  • SSH에서 사용할 22 포트
• 해당 포트로의 접근을 뚫어준다면 Jenkins에 요청을 보낼 때 방화벽으로 차단되는 일은 없을 것이라 생각된다.

• 우측 상단의 보안 그룹 생성 버튼을 눌러 들어간다.

• 다른건 적당히 설정해 주면 되고 여기 아웃바운드 규칙이 접근을 허용할 포트를 정의하는 곳이다. 유형, 프로토콜, 포트 범위가 존재한다.
  • 유형에서 HTTP, HTTPS, SSH를 선택할 수 있다. 선택하면 프로토콜과 포트 범위가 자동으로 지정된다.
  • 대상은 인스턴스가 어떤 IP 대역에 대해 이런 규칙을 적용할 것인가이다.
    • 만약 특정 IP 대역을 설정했다면 해당 대역 이외의 IP에서는 이 규칙으로 접근이 불가능하다.
  • 우리는 모든 IP에 대해 해당 규칙을 적용받도록 할 것이다. 이는 0.0.0.0/0으로 설정함으로서 가능하다.
  • 8080포트의 경우에는 유형에서 사용자 지정 TCP를 선택하여 포트 범위에 8080을 적어주면 된다. 대상은 위와 동일하다.
• 이후 보안 그룹을 생성해주면 

• 이런 보안 규칙이 생성된다.
• 보안 규칙을 생성했으니 이제 인스턴스에 해당 규칙을 적용시켜야 한다. 다시 인스턴스로 돌아간다.

• 적용할 인스턴스를 선택한 후 우측 상단의 작업 - 보안 - 보안 그룹 변경을 눌러 들어간다.

• 여기에서 적용시킬 보안 그룹(규칙)을 선택할 수 있다. 하나만 선택할 수 있는게 아닌 여러 보안 그룹을 적용시킬 수 있다. 여기서 보안 그룹 선택을 누르면 우리가 만든 보안 그룹들이 보이게 된다.
• 그것을 선택한 뒤에 저장을 누르면 해당 보안 그룹에 존재하는 규칙이 인스턴스에 적용되게 된다.

 

마치며

• 다음 포스트에서는 Jenkins Instance에 접속해서 Docker 설치와 Jenkins 설치, 세팅을 하는것과 Build 하는 것 까지 진행하도록 한다.