CI/CD AWS codepipeline으로 구성하기

CI/CD?

개발을 하다보면 CI/CD라는 말을 많이 듣게 되는데요. 과연 이게 무슨 뜻일까요?

CI는 Continuous Integration의 약자며 CD는 Continuous Delivery의 약자로써 업무를 지속적으로 개선하고 자동화하는 역할을 수행합니다.

배포 과정을 전반적으로 관리해주는 것이죠 git에 서로 push를 하고 머지를 하고 그 결과물을 서버에 배포하는 것

간단하게 말하면 배포를 자동화하는 것입니다.

아무래도 사람 손으로 일일히 머지하고 배포하다보면 시간도 걸릴 뿐더러 실수를 할 수도 있으니

이 CI/CD를 자동화하는 것은 정말 중요합니다.

aws codepipeline?

이 CI/CD 툴은 여러가지가 있는데요 저희는 그 중 codepipeline을 통해 배포를 할 예정입니다.

aws codepipeline은 코드의 커밋 기록을 체킹하여 자동으로 배포해주는 서비스입니다.

가격도 아주 저렴한데요. 처음 CI/CD를 경험하기에는 적은 돈으로 많은 경험을 할 수 있습니다.

V1, V2로 구성되어 있어 V1같은 경우는 사용하지 않아도 일정량의 금액을 지불 했어야 했으나 V2가 나오게 되면서 배포한만큼만 내면 되는 것으로 바뀌어 비용이 아주 저렴해졌습니다.

실무에서는 자주 상용서버에 배포를 안한다면 비용은 달에 1$아래로 청구될 정도로 금액이 저렴합니다.

EC2의 pre-tier 서비스와 같이 결합하면 저렴한 비용으로 CI/CD를 경험해볼 수 있는 것이죠.

그래서 codepipeline은 어떻게 구성해야 되는건데?

1. 파이프 라인 설정 선택

가장 기본적으로 aws 계정이 있어야겠죠? aws 계정을 가입한 후 로그인을 해줍니다. 그후 CodePipeline를 검색해줍시다.

파이프라인 생성을 들어가줍시다.

파이프라인 생성에 들어가게 되면 어떤 방식으로 파이프라인을 구성할지에 대해 물어보는데요 저는 custom pipeline을 선호해서 custom pipeline을 선택해줬습니다.

여러분은 template를 선택하셔도 좋습니다. 좀 더 단계가 간편해져요.

자 다음 단계에 들어가면 pipeline의 이름을 정할 수 있는데요. 서비스나 EC2에 연관된 이름을 설정해주는 것이 좋습니다. V1,V2로 관리하거나 prod, stage등 용도에 맞게 구성하는 것이 좋아요. 실행 모드의 경우 저는 병렬 구조를 선호합니다.

ex) [서비스명]-pipeline-prod-v2

핵심적인 부분은 서비스 역할에 있는데요. 기존 pipeline을 구성해서 서비스 역할이 있다면 상관 없지만 처음 만들 경우에는 없기 때문에 새 서비스 역할을 만들어줍니다. 이건 재사용할 확률이 높기 때문에 서비스명에 pipeline만 넣어서 구성해주는 것이 좋습니다.

ex) [서비스명]-pipeline

그 다음은 고급설정인데 기본 위치와 현재 이미 구성되어 있는 S3를 선택해서 올릴수도 있습니다.

S3란?이 포스팅을 참고해주시고 버킷 생성을 해서 하고 싶은 분들은 생성 후 지정 위치로 지정해주면 됩니다.

처음 만드시는 분들은 만드는 게 귀찮다 하시면 기본 위치에 생성해주시면 되겠습니다.

5. 여기선 어느 코드를 체크해서 배포를 하게 만들건지 선택하는 화면 인데요 저희는 개발자의 단비이자 꽃인 GitHub(버전 2)로 구성하겠습니다.

앞으로 회사가 제공해주는 거에 맞춰서 진행하시면 됩니다. S3로 구성하셔도 되고 나중에 GitLab을 쓰시면 그걸로 구성하셔도 되고 Git을 회사용으로 따로 파셨다면 그거의 링크를 연결하시면 됩니다.

2. 소스 스테이지 추가

본격적으로 GitHub를 연결해볼텐데요 저희는 처음 연결했다고 가정했으니 GitHub에 연결 버튼을 눌러줍시다.

새로운 창이 뜨게 될텐데 당황하지 마시고 [프로젝트명]-github를 입력하시고 GitHub에 연결을 클릭해줍시다.

그 후 새 앱 설치를 눌러줍시다.

GitHub가 뜰텐데 거기에 해당하는 사람을 눌러주세요.

거의 다 왔습니다. All repositories를 선택해서 모든 repositories를 해도 되지만 실수할 수도 있고 명확한게 좋기 때문에 Only select repositories를 눌러 하나의 repositories만 지정해주고 Install & Authorize를 눌러주시고 그 후 비밀번호를 입력주세요

자 이러면 인증된 GitHub repositories가 세팅된거라 연결 버튼을 눌러 진행해주세요.

아 이제 연결에서 추가한 GitHub를 클릭하고 리포지토리 이름을 선택합니다. 기본 브랜치는 사용 서버에 구성한다고 가정하겠습니다. 그래서 main을 선택해주고요. 그 후 출력 아티팩트 형식은 기본값 그대로 가고 트리거는 바꾸지 않고 다음을 누르겠습니다.

프로젝트를 구성할때 기본적으로 develop,stage,main의 구성을 주로 사용하며 main은 상용서버에 배포할때 사용하고 develop은 개발한 후 stage에 배포 후 테스트를 거치고 상용서버인 main에 배포를 하기 때문에 이런 식으로 구성하였습니다.

3. 빌드 스테이지 추가

생략하실 분들은 codeDeplay 과정만 진행하셔도 됩니다. codeBuild 과정은 상용 서버의 안정성을 위한 과정이기 때문에 테스팅 서버나 소규모 서버는 생략하셔도 무방합니다. 따라서 너무 복잡하다 지금 CI/CD 구조만 만들고 싶다 이런 경우 빌드 스테이지를 건너뛰기를 통해 건너 뛰어주세요. 아닌 분들은 프로젝트 생성을 클릭해주세요.

그 후 AWS codeBuild 구성하기를 클릭해서 codeBuild를 구성해줍니다. 하나에 작성하다보니 너무 길어져서 그러니

다 생성하게 되면 이 화면으로 나오게 되는데 다음을 눌러줍시다.

4. 테스트 스테이지 추가

Test의 경우 생략하셔도 무방합니다. Skip test stage를 눌러줍시다.

5. 배포 스테이지 추가

마지막인 배포 스테이지입니다. 자기가 어떤 곳에 배포를 하는지 맞춰서 진행하는데 저 같은 경우는 AWS Elastic Beanstalk을 통해 배포를 진행해서 선택해주고 진행하시면 됩니다. AWS Elastic Beanstalk을 사용하지 않는 경우 CodeDeplay를 통해 배포를 하는 게 좋은데 이 부분은 따로 작성하도록 하겠습니다.

최종으로 점검한 뒤 생성을 누르면 구성이 끝납니다.

최종 완료 후 변경사항 릴리스를 통해 모든 과정이 이상 없이 진행되는 지 확인하면 최종적으로 완료입니다.

마치며

codeDeplay 부분이 아직 미흡합니다. 금방 작성해서 그 부분을 채워 넣도록 하겠습니다.