Bare minimum requirement
- GitHub Action을 이용하여 CI 상에서 Mini node server를 Docker 이미지로 만든 후, 여러분의 Docker Hub에 push하세요.
Getting Started
두번째 스프린트는 앞서 GitHub Action으로 진행한 빌드/테스트 자동화가 끝나고 진행되는 스프린트입니다.
1. CI 상에서 주어진 Dockerfile을 이용해 Docker 이미지를 빌드할 수 있도록, workflow를 새로 만드세요.
- 다음 레퍼런스를 참고해서 Docker 빌드용 GitHub Action workflow를 만드세요.
- workflow를 추가한다고 해서 GitHub Action이 즉시 작동하지는 않을 것입니다.
- repository에서 왼쪽 사이드바를 살펴보면, Release -> Create a new release 링크가 존재합니다. 이 링크를 누르고 새로운 릴리즈를 발행합니다. 설정은 다음과 같이 진행합니다.
- Choose a tag: v1.0.0
- Release title 및 Release notes는 여러분이 자유롭게 입력하세요.
- Publish release 후에 GitHub Action이 작동하나요?
- Q. 왜 작동이 되는걸까요? 아까는 왜 안됐을까요?
2. 인증 정보에 대한 환경 변수를 만드세요.
1번 과정을 통해 GitHub Action을 실행하면 그 결과는 실패로 나타날 것입니다. 무엇이 잘못되었는지 먼저 로그를 살펴보세요.
- Q. 왜 실패했을까요? 로그에서 그 이유를 찾아보세요.
Workflow YAML 파일을 자세히 살펴보면, DOCKER_USERNAME 및 DOCKER_PASSWORD 라는 환경 변수가 존재합니다. 말 그대로 아이디와 비밀번호와 같은 민감정보를 YAML 코드에 입력해서 git commit 기록으로 남겨둔다면, 더 이상은 그 비밀번호를 사용할 수 없게 될 것입니다. (돌이킬 수 없어요!)
GitHub에서는 이러한 환경 변수를 안전하게 보관할 수 있는 기능을 제공합니다. Settings -> Secrets 에서 환경 변수를 설정하세요.
우선 전에 했던 스프린트에서 이어하는거인거 같았다. 전 스프린트에서는 깃허브 액션을 이용해 깃허브레포에 푸쉬하거나 풀리퀘스트하면빌드 테스트르 자동화 하는 것이것이었고 이번에는 릴리즈를 하면 도커허브에게 이미지를 올리게 자동화 하는 것과 깃허브 내에서 도커 아이디 비번을 환경변수처리 하는 스프린트 같았다.
우선 깃허브액션에 들어가 도커허브에 릴리즈하면 자동으로 도커허브에 푸쉬하도록 해보겠다.
먼저, 해당 레포에 깃허브 액션에 들어가 도커이미지 워크플로를 만든다.
그 후, 레퍼런스에서 YAML을 복사하여 도커 이미지에 붙여넣고 필요없는 부분은 지운다.
트리거는 릴리즈 시 이미지에 올라가게 되있고 도커 허브에 로그인 비번이 되있고 밑에는 빌드 그리고 푸쉬 도커 이미지가 되있다.
그럼 여기서 도커이미지의 아이디 비번을 올리면 누구든지 다 볼 수 있게된다. 그래서 환경변수 처리를 하였다.
세팅 - 시크릿 - 액션 에 들어가면 설정이 가능하며 이렇게 설정하면 직접 적지 않아도 실행이 되며 안전하게 보호를 할 수 있다.
이렇게 하면 이미지가 올라갈까? 아니다. 왜냐하면 트리거를 릴리즈로 짰기 때문에 릴리즈를 해야한다.
우측 중단에 릴리즈를 눌려 추가하면 된다. choose a tag에 버젼을 적으면 된다. 그럼 자동으로 도커허브에 이미지가 올라가야한다
근데 난 자꾸 오류가 났는데 오류가 난 부분은 자꾸 테스트를 하면
buildx call failed with: error: denied: requested access to the resource is denied
이 오류가 났다. 그래서 터미널로도 해봤더니 똑같은 오류가 나서 해결법을 찾아보자 이미지 앞에 도커허브 아이디를 붙이면 해결된다해서 해봤더니 터미널 안에서는 해결 되었다. 그래서 똑같이 tags에 도커 유저네임을 넣어 해결했다.
그래도 자꾸 같은 오류가 나 도저히 모르겠어서 동기분한테 물어보니 정말 간단한 실수였다.
yaml파일의 태그 부분을 수정하고 새로운 버젼으로 릴리즈를 해야 변경사항이 적용되는데 난 변경 사항이 적용이 되어있지않은 곳에 자꾸만 테스트를 했으니 같은 오류가 났던 것이다. 그래서 새롭게 릴리즈를 하고 테스트를 하니 잘 해결되었고 도커허브에도 잘 푸쉬 되는 것을 볼 수 있었다.
배포 자동화
한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것을 말한다.
배포 자동화의 이유
- 수동적이고 반복적인 배포 과정을 자동화함으로써 시간 절약에 용이하다.
- 휴먼 에러(Human Error)를 방지할 수 있다.
휴먼 에러란 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수를 뜻하며 그전에 했던 배포 과정과 비교하여 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것이 휴먼 에러의 예로 볼 수 있다. 배포 자동화를 통해 전체 배포 과정을 매번 일관되게 진행하는 구조를 설계하여 휴먼 에러 발생 가능성을 낮출 수 있다.
배포 자동화 파이프라인
배포에서 파이프라인은 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다. 위 그림처럼 배포 과정을 여러 단계로 분리할 수 있으며, 각 단계는 파이프라인 안에서 순차적으로 실행되며, 단계마다 주어진 작업(Actions)을 수행한다.
파이프라인을 여러 단계로 분리할 때, 대표적으로 쓰이는 세 가지 단계가 존재하나 이는 상황과 필요에 따라 유동적으로 세분화 또는 간소화 할 수 있다.
파이프라인의 대표적 세 가지 단계
- Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행한다.
- Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공하며 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
- Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.
AWS 개발자 도구
AWS에는 개발자 도구 섹션이 존재하며 이를 활용해서 배포 자동화 파이프라인을 구축할 수 있습니다.
CodeCommit
CodeCommit은 GitHub과 유사한 서비스를 제공하는 버전 관리 도구이며 Source단계를 구성할 때 사용한다.
GitHub과 비교했을 때 CodeCommit 서비스는 보안과 관련된 기능에 강점을 가지며 소스 코드의 유출이 크게 작용하는 기업에서는 매우 중요한 요소이다. 다만 CodeCommit을 사용할 때는 과금 가능성을 고려해야하며 프리티어 한계 이상으로 사용할 시 사용 요금이 부과될 수도 있습니다. 사이드 프로젝트나 가볍게 작성한 소스 코드를 저장해야 할 경우에는 GitHub을 이용하는 것이 효과적이라고 볼 수 있다.
CodeBuild
CodeBuild 서비스를 통해 유닛 테스트, 컴파일, 빌드와 같은 빌드 단계에서 필수적으로 실행되어야 할 작업을 명령어를 통해 실행할 수 있으며 Build 단계에서 CodeBuild 서비스를 이용한다.
CodeDeploy
Deploy 단계를 구성할 때는 기본적으로 다양한 서비스를 이용할 수 있다. CodeDeploy 서비스를 이용하면 실행되고 있는 서버 애플리케이션에 실시간으로 변경 사항을 전달할 수 있으며 S3 서비스를 통해 S3 버킷을 통해 업로드된 정적 웹 사이트에 변경 사항을 실시간으로 전달하고 반영할 수 있다.
CodePipeline
각 단계를 연결하는 파이프라인을 구축할 때 CodePipeline 서비스를 이용한다.
'TIL' 카테고리의 다른 글
| 36일차 배포 자동화 (0) | 2022.06.07 |
|---|---|
| 35일차 배포 자동화 (0) | 2022.06.03 |
| 33일차 지속적 통합 (0) | 2022.05.31 |
| 32일차 지속적 통합 (0) | 2022.05.30 |
| 31일차 yaml (0) | 2022.05.30 |