01 CI/CD(CodeCommit, CodeBuild, CodeDeploy, CodePipeline)

김종욱·2023년 5월 20일

학습주제
CI/CD
CI/CD(CodeCommit, CodeBuild, CodeDeploy, CodePipeline)
학습내용
CI/CD는 우리가 빌드한 것을 자동적으로 빌드하고 배포하는 과정들
AWS에는 이 서비스 제공함

지속적 통합
모든 개발자가 개발한 코드를 공유 리포지토리에 하루에도 여러번 코드를 커밋하고 병합하는 것
커밋 / 병합

지속적 던달
개발팀이 짧은 주기로 소프트웨어를 개발하고 언제든지 운영환경으로 안정적으로 배포하는 것
Deployment

그림을 보면
계획 - 코딩 - 빌드 - 테스트 - 릴리즈 - 배포 - 운영 - 모니터링
모두 모아서 CI/CD라고 한다
DEVOPS의 가장 중추적인 역할

릴리즈(Release)는 개발자가 완전한 버전의 소프트웨어를 공개적으로 사용할 수 있도록 공개하는 것을 의미합니다. 즉, 개발자가 개발한 소프트웨어를 완료하고 버전 관리 시스템을 통해 공개적으로 배포할 준비가 되었을 때 릴리즈를 진행합니다. 릴리즈는 일반 사용자들이 소프트웨어를 사용하고 테스트할 수 있는 단계입니다. 이 단계에서 버그 수정, 기능 개선 및 성능 향상 등의 작업이 이루어질 수도 있습니다.
배포(Deployment)는 릴리즈된 소프트웨어를 실제적으로 사용 가능한 환경으로 전달하는 과정을 의미합니다. 배포는 릴리즈된 소프트웨어를 실제 서버, 클라우드, 앱 스토어 등의 환경에 설치하거나 업로드하여 사용자들이 접근하고 사용할 수 있도록 만드는 작업을 포함합니다. 배포 단계에서는 소프트웨어를 운영 환경에 맞게 설정하고, 보안 및 성능 등의 측면을 고려하여 실제 사용에 문제가 없도록 준비합니다.
요약하자면, 릴리즈는 소프트웨어를 공개적으로 사용 가능한 상태로 만드는 과정이며, 배포는 릴리즈된 소프트웨어를 실제적으로 사용 가능한 환경으로 전달하는 과정입니다.

CI/CD를 할 수 있는 aws 서비스들을 알아보다

도식화 개요
소스는 깃허브에 올려놓음
aws에서도 git과 같은 서비스를 제공
빌드 - 연동 - 배포를 자체적으로 할 수 있음

codecommit - 깃허브와 같음. 레포 역할
깃허브를 통해 CI/CD 서비스 역할을 수행케 할 수 있음

파이프 라인으로 연결할 수 있음. CodePipeline
빌드할 땐 codeBuild
아마존 SNS 통해 확인
CodeDeploy - 배포

이중화, 삼중화 제공
CI/CD가 없다면 하나씩 올려야함

자동화가 가능함

CodeCommit: 깃허브의 Repo와 같은 역할.
비공개로 저장해서 관리 가능
깃허브를 사용했다면 기능들은 똑같음.
사용방법도 비슷

-> 깃허브 CI/CD 영상으로 복습해야함.
flow는 똑같음

깃허브와 유사하다

코드 커밋을 높은 가용성, 내구성을 제공, 하드웨어, 소프웨어 관리 부담을 줄여줌 하드웨어를 프로비저닝하고, 소프트웨어 설치할 필요 없음

하드웨어 프로비저닝은 컴퓨터 시스템 또는 네트워크 장비와 같은 하드웨어 리소스를 사용 가능한 상태로 설정하는 과정을 말합니다. 이 과정은 새로운 하드웨어를 구입하거나 기존 하드웨어를 사용할 때 필요한 작업입니다.
코드를 안전히 저장할 수 있음
코드에서 공동작업 가능. 깃과 같음. 각 브런치에서 개발하고 push. PR기능을 이용해 병합하고, 코드 리뷰를 제공. 중간중간 하는 행위에 대해 이메일로 제공함
버전관리 프로젝트를 쉽게 확장할 수 있음. 대용량 파일 등을 포함해 레포를 처리함
언제든지 모든걸 보관할 수 있음.
다른 사용자와, 다른 서비스와 호환 가능
깃 기반의 리포에서 마이그레이션을 할 수 있음. 깃 내용을 코드커밋으로 연결 가능.
깃 툴 그대로 사용 가능

레포를 생성해본다

강의에선 IAM 사용자로 로그인 된 상태. 나의 경우 루트사용자라 경고와 함께 주소가 뜨지 않는 것 같다.
하단에 임의의 파일을 눌러 파일 생성을 할 수도 있다.

배쉬에서 clone을 시도하자 로그인 하라는 메세지가 떴다.

프라이빗하게 레포를 aws를 이용

Codebuild

단위 테스트를 지원한다고 한다

코드빌드만 운영하는 경우는 없고
코드 파이프라인을 연결해서 자동화를 한다

깃허브와도 연동이 가능함. oauth, 엑세스 토큰으로 연동

코드커밋에서 앞서 만든 repo를 등록

연동을 하고 나면

내 리포가 나오고 가져다 쓸 수 있다.

코드커밋으로 리포를 선택하면
아직 브랜치가 만들어져 있지 않다. develop를 개발서버로 가고 master/main을 운영서버로

개발서버: 개발서버는 주로 개발자들이 새로운 기능을 개발하고 테스트하는 환경입니다. 개발자들은 개발 작업을 수행하고 변경사항을 해당 브랜치에 커밋합니다. 이러한 브랜치는 주로 "develop" 또는 "feature"와 같은 이름을 가지며, 여러 개발자들이 함께 작업할 수 있도록 공유됩니다. 개발서버에 있는 브랜치는 아직 완전하지 않은 기능이 포함되거나 버그가 있을 수 있으므로, 실제 운영에 사용되지 않습니다.
운영서버: 운영서버는 실제 사용자들이 접근하여 소프트웨어를 실행하는 환경입니다. 일반적으로 "master" 또는 "main" 브랜치와 연결되어 있습니다. 운영서버는 안정적이고 신뢰할 수 있는 버전의 소프트웨어를 제공해야 하므로, 테스트 및 검증이 완료된 기능들이 포함된 브랜치를 배포합니다. 개발자들은 개발서버에서 작업한 내용을 검토하고, 필요한 테스트와 코드 리뷰 등의 과정을 거친 후에 운영서버로 변경사항을 병합(merge)합니다. 이를 통해 운영서버에 안정적이고 품질 좋은 소프트웨어가 배포됩니다.

하위 모듈에 대해서만 작동을 하고 싶다면

체크박스에 체크

환경은 기본적으로 세팅

역할을 하나 만들어본다
빌드스크립트 추가가 필요
소스 파일 내에 buildspec을 만들어 스크립트를 만들 수 있음
아니면 빌드 명령 삽입으로 스크립트를 넣어줌

그래들?

"그래들 명령어를 넣으라"는 말은 Gradle 빌드 도구를 이용해서 프로젝트를 빌드하라는 의미입니다. Gradle은 Java, Kotlin, 그외 다른 여러 언어로 작성된 프로젝트를 빌드하기 위한 도구입니다.

해당 프로젝트에 대해 자료파일로 부트를 하게 된다
캐시 등도 설정할 수 있음 캐시를 사용하면 좀더 빨리 빌드에 도움이됨

빌드가 진행된 다음 deployment에서 뭔가 알아야될 파라미터, 아규먼트
추가하면 다음 스텝에서 알 수 있음

빌드가 생성됨

CodeDeploy

자동으로 배포를 해주는 서비스

앞단에서 코드빌드를 통해 빌드된 걸 자동으로 배포

일반 어플리케이션, 람다, 패키지, 스크립트 배포해서 넘길 수 있음

서비스 역할은 IAM에서의 역할을 의미한다
임의로 code deploy 정책을 담은 역할을 생성하였더니 서비스 역할이 뜬다

대상그룹을 1개 선택해준다

임의대로 만들어준다

애플리케이션에 가면 배포할수 있는 배포그룹이 생성되어 있다

code pipeline 검색
우리가 만일 서버가 2대 있다고 하면
개발 서버, 운영 서버
파이프 라인은 2개가 생성되어야 함.
개발용, 스테이지용, 운영용 등
각 서버에 대한 이벤트를 받아서 해당 서버로 배포하기 위함

개발 서버를 위한 파이프라인을 만든다고 가정하고

코드 커밋을 통해 받는다고 가정
만일 깃허브를 한다고 하면 버전 2를 선택해야함

undefined로 설정 후
앱이 없어, 새 앱을 설치한다
업로드중..

연결이 됨

기존에 있던 repo가 있음
다음번에 깃헙으로 실습