CI/CD with AWS

황순은·2021년 7월 6일

Final Project

목록 보기

2/3

CI / CD란?

CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 방법입니다. CI/CD의 기본 개념은 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포입니다. CI/CD는 새로운 코드 통합으로 인해 개발 및 운영팀에 발생하는 문제(일명 "인테그레이션 헬(integration hell)")을 해결하기 위한 솔루션입니다.

Backend engineer & DevOps

Final Project를 진행하는 과정에서 팀에서 백엔드 엔지니어와 DevOps역할을 맡아 서버 기능구현과 함께 클라이언트, 서버 배포를 계속 진행해 왔다. 배포는 First Project에서 몇일동안 꼬박 공부해서 처음 성공한 뒤로 꾸준히 하다보니 지속적으로 통합된 코드를 테스트하고, 배포하는데 몇시간에서 20분, 10분으로 줄기 시작했고 어느순간 10분내에 성공하게 되면서 CI/CD에 욕심이 생겼다.

상상..

여러번 배포를 진행하면서 CI/CD는 어떤 플로우로 이루어질까라는 생각을 계속 했었다. "Github에있는 repository가 머지가 되면 그걸 인식하고 자동으로 코드를 가져와서 배포까지 이루어지나?", "Github에는 환경변수가 없는데 어떡하지?", "npm은 어떻게 설치하고 package는 어떻게 하지?" 등등.. 하지만 상상은 현실이 되었다.

CodePipeline & CodeBuild

먼저 클라이언트 s3같은 경우 최신화된 repository를 가져온 후 로컬환경에서 build과정을 거쳐서 버킷에 업로드하고, CloudFront 캐쉬를 초기화시켜줘야 하기 때문에 수동으로 배포를 했을 경우 서버보다 시간이 더 오래걸렸다. 따라서 클라이언트단의 CI/CD를 먼저 구축하고자 Aws CodePipeline과 Aws CodeBuild를 먼저 공부했다. CodePipeline을 살펴보보니 수동으로 배포할때와 똑같은 구조를 가지고 있었으며 Aws CodePipeline에서는 소스 스테이지, 빌드 스테이지, 배포 스테이지 3단계로 나뉘어진다. 먼저 소스 스테이지에서 Github의 레포지토리를 연결할 수 있고, 최신화 될때마다 소스를 가져와서 파이프라인의 실행을 시작했다. 다음으로 빌드 스테이지(제일 까다로웠다)인 Aws CodeBuild에서 필요한 파일들을 설치, 코드를 테스트하고, 빌드(압축)한 코드를 배포스테이지로 전달한다. 전달받은 코드를 배포 스테이지에서 s3로 전달한다.(오류가 거의 없다. 압축을 풀든 안풀든 무조건 전달함) 이것으로 클라이언트 CI/CD는 완성되었다. 중간에 buildspec를 작성하는 과정에서 조금 애먹었지만 수동배포와 똑같은 플로우라는 것과 수동배포는 수없이 해왔고, 배포 자체에 이해도가 높았기 때문에 비교적 쉽게 구축할 수 있었다. (환경변수도 물론 우리가 생각하는곳에서 설정할 수 있다.)

phases:
  install:
    runtime-versions:
    commands:

  pre_build:
    commands:

  build:
    commands:

artifacts:
files:

  discard-paths:
  base-directory:

CodePipeline & CodeDeploy

클라이언트의 CI/CD구축완료 후 얻은 자신감으로 바로 서버 CI/CD구축에 도전했다. 수동 배포와 플로우가 다를게 없을 것이라는 예상을 가지고.. 먼저 클라이언트는 수동배포와 자동배포의 결승선이 s3였던것 처럼 서버도 마찬가지로 수동, 자동 둘다 ec2가 결승선이었다. 하지만 CodeBuild를 거치지 않아도 됐기때문에 쉬울거라는 예상과 달리 ec2는 결승선을 넘는것이 너무 어려웠다^^; ec2는 항상사용해오던 ubuntu를 사용했기 때문에 appspec에 내가 수동배포할때와 같은 커맨드를 입력해주면 된다라는 가벼운 생각은 무거운 고민으로 돌아왔다. 수많은 에러지옥을 맛보았고 심지어 항상 잘 받아오던 소스도 받아오지 못하는 상황도 연출됐다.

또한 appspec에 지정해둔 파일의 코드는 변경하면 바로 적용이 되지 않았다. 따라서 해당 코드의 변경이 필요할시에는 codedeploy-agent를 삭제하고 다시 파이프라인을 구동을 해야했고 수많은 테스트와 에러핸들링을 거친뒤에 왜 에러가 나는지, 해결방법은 무엇인지 알 수 있었고 하루만에 68의 contributions의 신기록을 달성하며 서버단 CI/CD구축을 완료할 수 있었다.

문제 발생

CI/CD구축전 s3는 us-east-1 리전에 있었고, ec2는 ap-northeast-2에 있었기 때문에 먼저 구축했던 클라이언트의 CodePipeline(us-east-1)으로 통합하기 위해서 ec2를 동일한 리전으로 옮기고 서버 CI/CD를 구축했다. 그결과 서버는 엄청 느린 응답을 주는 결과를 가져왔고 모든 리전을 ap-northeast-2(서울)로 옮기는 작업이 필요했다.ㅠ 복습한다고 생각하고..
완료.. 엄청 빨라졌다.. 좋아..