AWS에 Jenkins를 구축해보자 - (1) VPC 설정

Jongwon·2023년 10월 5일

Github Webhook NAT Gateway Subnet aws aws lambda bastion host jenkins vpc

에피메테우스

목록 보기

1/6

이번 프로젝트에서 인프라를 가장 신경쓰기로 목표했기 때문에 CI/CD부터 이중화, 보안 등 여러 분야를 신경써서 AWS 서비스를 개발해보고자 합니다.

이번 글의 목표는 Private Subnet에 Jenkins를 설치하고, Github Webhook을 통해 main 코드의 변경 발생 시 Lambda로 Request를 받아 Jenkins가 Public Subnet에 SpringBoot Server를 배포하도록 하는 것입니다.

키워드만 보면 무슨 말인지 잘 이해가 안되겠지만, 하나씩 차근차근 진행하도록 하겠습니다.

전제 조건

Github Project가 존재해야 합니다. 이 프로젝트 내부에는 Spring Boot가 존재해야 합니다.

프로젝트는 JAVA 17 기반으로 진행하였습니다. 이전 버전이어도 무관합니다.

AWS 계정이 존재해야 합니다. 또한, IAM 계정을 생성하여 접속했을 때에는 아래의 권한들이 존재해야 합니다.

AmazonEC2FullAccess
AmazonVPCFullAccess
AWSLambda FullAccess
AWSCodeDeployFullAccess
AmazonAPIGatewayAdministrator

리전은 아시아 태평양 서울(ap-northeast-2)로 진행할 예정입니다.

VPC 생성

가장 처음 해야하는 일은 VPC를 생성하는 것입니다. VPC란 Virtual Private Cloud의 약자로, 퍼블릭 클라우드 환경인 AWS 내에서 VPC라는 독립적인 나만의 공간을 만드는 것입니다. 이를 통해 외부 인스턴스에서 내 인프라에 함부로 접속할 수 없도록 제한합니다.

진행 과정

VPC 생성

콘솔에서 VPC를 검색하여 들어갑니다.
VPC 생성을 클릭합니다.

이름 태그를 적으면 VPC 페이지에서 태그명으로 한눈에 볼 수 있습니다.
IPv4 CIDR 수동입력을 선택하고 CIDR을 입력합니다.
- ex) 10.100.0.0/24

CIDR이란?
네트워크 구분을 클래스(기존의 서브넷 A~E 클래스) 기반으로 작성하던 IP 주소 체계의 한계를 극복하고 주소 공간을 효율적으로 할당하기 위해 도입된 방식입니다.
ex) 192.168.1.0/24의 의미는 192.168.1.0 ~ 192.168.1.255까지를 사용하겠다는 의미입니다.

CIDR은 현대 IP 네트워킹에 많이 사용되는데, 라우팅이 쉽기 때문에 특히 BGP 프로토콜에서 핵심적인 역할을 합니다.

Subnet 생성

VPC에서 정한 네트워크의 범위 내에서 IP주소를 나누어야 합니다. 즉, 서브네팅을 통해 어떤 IP 주소들이 Private으로 지정될지, 어떤 IP주소들이 Public으로 지정될지 정해주어야 합니다.

왼쪽의 서브넷을 클릭합니다.
서브넷 생성을 클릭합니다.
VPC는 앞서 만들었던 VPC(태그를 지정했다면 태그명으로 확인할 수 있습니다.)를 선택합니다.
=> 이때 다른 VPC가 존재할텐데, 이는 기본적으로 계정에 배정된 VPC로 삭제가 불가능합니다.
서브넷 설정을 해줍니다.

가용 영역은 이 서브넷이 어느 az(물리 데이터센터)에 위치시킬지 정하는 것입니다. 한번 정한다면 이동이 불가합니다.
=> 나중에 서버 이중화를 계획중이므로 Main은 2a로, Backup은 2b로 설정하겠습니다.

CIDR block은 앞서 VPC에서 지정했던 CIDR 내에 있는 block으로 해야합니다.

ex) 10.100.0.0/24로 설정했다면 10.100.0.0 ~ 10.100.0.255까지 사용가능합니다. 예를들어 10.100.0.0/28로 한다면 VPC 내부에서 10.100.0.0 ~ 10.100.0.15까지는 이 서브넷이 사용할 IP라는 의미입니다.

총 4개의 서브넷을 생성합니다.(2개는 2a영역에, 2개는 2b영역에, public subnet + private subnet 한개씩 생성합니다. CIDR은 모두 달라야 합니다.)

어려울 수 있기 때문에 제가 생성한 서브넷을 표로 만들어보았습니다.

서브넷명	가용영역	CIDR block
server-public-subnet-main	ap-northeast-2a	10.100.0.0/28
server-public-subnet-backup	ap-northeast-2b	10.100.0.16/28
server-private-subnet-main	ap-northeast-2a	10.100.0.128/28
server-private-subnet-backup	ap-northeast-2b	10.100.0.144/28

Routing Table 생성

다음으로는 Routing Table을 생성해야합니다. Routing Table은 VPC 내부에서 네트워크 트래픽을 특정 네트워크 인터페이스로 전달하기 위한 규칙 집합을 담고 있습니다. 각 서브넷은 하나의 라우팅 테이블과 연결될 수 있습니다.

왼쪽에서 라우팅 테이블을 선택합니다.
라우팅 테이블 생성 버튼을 클릭합니다.
라우팅 테이블 이름과 VPC를 설정합니다.(이전에 만든 VPC 선택)
서브넷 연결 버튼을 클릭합니다.
2개의 public subnet을 라우팅 테이블에 연결합니다.
마찬가지로 라우팅 테이블을 1개 더 생성하여 private subnet 2개를 새로만든 라우팅 테이블에 연결합니다.

중간 점검

현재 단계까지 진행이 완료되었다면 4개의 서브넷과, 2개의 라우팅 테이블이 만들어졌을 것입니다. 한눈에 확인하려면 VPC 탭에서 생성한 VPC를 선택하고, 리소스맵을 보면 알 수 있습니다.

이름은 지정한대로 다를 수는 있겠지만, 어쨋든 라우팅 테이블에 Hover를 하면 서브넷과 2개씩 연결이 되어있어야 합니다.

진행과정 이어서

IGW(Internet Gateway) 생성 및 Public Subnet 연결

VPC는 격리된 공간이기 때문에 외부 인터넷에 접속할수도, 접속을 받을수도 없습니다. Private Subnet에 생성할 EC2에게는 환영할만한 일이지만, Public Subnet도 접속할 수 없다면 무용지물일 것입니다. 따라서 IGW를 생성하여 Public Subnet에 접속할 수 있도록 연결해주겠습니다.

왼쪽에서 인터넷 게이트웨이를 클릭합니다.
이름을 설정하고 생성합니다.
작업 -> VPC에 연결을 클릭합니다.
이전에 생성했던 VPC를 연결합니다.
왼쪽에서 라우팅 테이블을 클릭합니다.
Public Subnet들과 연결된 라우팅 테이블을 클릭합니다.
아래 라우팅 -> 라우팅 편집을 클릭합니다.
라우팅 추가를 클릭하고, 왼쪽 대상엔 0.0.0.0/0을, 오른쪽 대상엔 인터넷 게이트웨이를 선택하면 자동으로 나오는 igw를 선택합니다. 이 IGW는 바로 전에 만들었던 인터넷 게이트웨이 이름입니다.

왜 대상과 대상이지?
이 부분은 AWS 한국어 버전을 이용하기 때문에 발생한 혼동입니다. 왼쪽의 대상은 Destination을 의미하는 대상이고, 오른쪽의 대상은 Target을 의미하는 대상입니다.

Destination: 트래픽의 목적지를 의미합니다. 라우팅 테이블과 연결된 서브넷에서 보내는 트래픽의 목적지입니다. 이는 좁은 범위부터 선택이 되므로, 0.0.0.0/0을 지정하더라도 10.100.0.0/24 -> local로 되어있는 Dest부터 선택됩니다.
Target: 해당 목적지를 가진 트래픽을 어디로 라우팅할지입니다. 0.0.0.0/0 -> igw로 함으로써 VPC 내부 트래픽을 제외하고는 모두 IGW를 통해 외부로 보내고, 외부에서 IGW를 통해 public subnet 내의 인스턴스에 접근을 가능하게 합니다.
변경사항을 저장합니다.