CI/CD - Build push/pull (Docker Image 저장소 : AWS ECR) + (GitLab을 이용한 자동화 : GitLab Runner)

만들었고, 아직 아무런 image가 없다. No images.

이 오른쪽 위에, View push commands 를 봐야 한다.

이 저장소를 사용하기 위한 다양한 명령어들이 있다.

당연히 이것도 마찬가지로, ECR에 대한 접근 권한이 있어야 한다.

접근 권한을 생성해줘야 한다.

이 명령어를 사용하기 전에 접근 권한을 먼저 설정하는 일을 해봐야 한다.

 

Docker Image는 회사의 중요한 자산이다.

Docker Image는 사실상 제품에 대한 정보를 가지고 있는 것이니까.

그러니 그걸 저장하고 있는 ECR은 아무나 접근하게 두어선 안 된다.

그래서 권한 관리를 해줘야 한다.

AWS에서는 IAM 이라는 서비스를 이용해서 권한을 관리를 할 수 있다.

IAM을 통해서 access key, secret key 를 가지고 key를 가진 사람만 접근이 가능하다.

 

ECR에 접근이 가능한 권한을 가진 users 를 만들어줘야 한다!

IAM 사용에 대해서는 나름 복잡한 부분들이 있어서 자세한 사용법은 공부가 좀 필요해보인다.

일단 지금은 강의에서 하라는대로 나아가보자.

모든 리소스에 대한 접근 권한을 주는 걸 가진 user를 만드려고 한다. 루트 권한을 가진 user.

유저가 만들어졌으니, 이 유저를 위한 key를 만들어주면 된다.

 

 

유저를 클릭해서 들어가보면,

Security credentials 에 보면 key 생성에 대한 걸 볼 수가 있다.

access key 생성 후 csv 파일을 다운로드 할 수가 있다.

 

csv 파일을 확인해보면, Access key ID, Secret access key 두 개가 들어있다.

그걸 linux ubuntu 의 터미널에서 aws configure 라는 명령어를 입력해서 등록을 해야 한다.

그런데, 나는 aws 명령어를 사용할 수가 없다고 나왔다.

그래서 aws 명령어를 사용할 수 있도록 해야 한다.

# 최신 패키지 업데이트
sudo apt update

# AWS CLI v2 설치 스크립트 다운로드
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

# 압축 해제
unzip awscliv2.zip

# 설치
sudo ./aws/install

# 설치 확인
aws --version

이제는 가능하다.

Default region name - 서울에 있는 AWS 사용중이니까 거기에 맞는 지역 번호 코드가 있다고 한다.

서울은 - ap-northeast-2

---

제대로 연결된것까지 확인 했다.

 

이제는 아까 봤던 ECR의 push commands 로 가보자.

거기서 CLI (linux ubuntu의 terminal과 같은 UI에서 사용하는 것)에 해당하는 것 복사해서 붙여넣기를 하면,

로그인 성공이 나온다!

 

이제 이미지 빌드 후, 빌드된 이미지를 tag 해주고, 그리고 나서 push를 해줘야 한다.

나는 이미 docker image 빌드를 했었기 때문에, 2번 단계는 건너뛰고 3번과 4번으로 간다.

tag 번호에 latest 라고 되어 있는 것만, 0.1로 바꿔주면 된다. (docker images 라고 명령어쳐서 tag 번호 확인 하고 입력하면 된다)

 

push 완료! push가 끝났으니, ECR에 잘 저장되어있는지 확인해보면 된다.

 

이제 저장소에 있는 image를 가지고 와서 container 실행이 가능한지 테스트 해보자.

 

Image URI 를 복사하자.

 

그전에, 로컬에 있던 images 들을 강제로 제거를 하자

로컬에 남아있으면 로컬에 있는것부터 실행할 수가 있으니 그냥 지우고 하는걸로.

 

docker run 을 할 건데, ecr-test 라는 이름을 가지고, 포트 포워딩인 5000, 그리고 URI 복사한 걸 붙여넣자.

그런데, 도커 이미지를 아까 지웠는데, Already exists 라고 뜨는 이유는, 도커가 바로 지우는게 아니라 내부 캐시에 저장을 해놓는다고 함. 그래서 그런 것일뿐. 어쨌든 잘 실행이 되었다.

 

멈추고 나서 docker ps -a 프로세스 기록을 보는거라서 ports 에는 아무런 정보가 없지만,

names에 ecr-test 라고 잘 되어 있는것까지 확인 끝!

 

ECR을 통해서, ECR에 push 하고 push한 ECR의 image 를 pull 해서 실행하는 걸 해봤는데,

이제 이 과정을 자동화를 하면 된다.

---

GitLab 을 이용한 Build Push 자동화를 해볼 것.

 

지금까지 여러가지 명령으로 수작업으로, 매뉴얼하게 ECR까지 push를 했었다.

이 과정을 GitLab을 이용해서 자동화하는 것 GitLab이 하는 일은, 사람이 하는 일을 코드로 자동화하는 것.

GitLab이 어떤 스크립트를 관리해서 사람 대신에 전 과정을 진행한다고 보면 된다.

 

지금까지 Docker Image Build / Docker Image Push 까지 했다.

 

GitLab을 사용하게 되면,

개발자가 개발한 code 를 GitLab이 읽게 되고,

자동화 스크립트를 실행(run)하게 될 것이다.

자동화 스크립트는 Docker Image Build/Docker Image Push/Deploy(아직 배포는 안 하긴 했음)

이 단계들을 매뉴얼하게 실행했던 명령들을 실행해주는 스크립트가 될 것이다.

자동화 스크립트

- docker build

- ecr login

- ecr push

- deploy (이거는 나중에 배울 것)

 

GitLab은 결과적으로 이 자동화 스크립트를 Run 하는 것.

CI/CD pipeline에 대한 설계라는 건,

결과적으로는 이 자동화 스크립트를 만들고 각 단계마다 실행할 수 있도록 해주는 것이

CI/CD 파이프라인 자동화라고 보면 된다.

자동화 스크립트를 실행하는 건, GitLab Runner 가 한다.

 

이거는 설치를 해야 함.

구글에 gitlab runner install ubuntu 라고 해보자

 

 

 

architecture 부분은 amd64 로 바꿔주자.

 

다운 받고 나서는 실행을 해야 한다.

---

 

 

 

gitlab runner 가 실행 중인 걸 확인했다.

이제 gitlab CI 에서 gitlab runner를 등록을 시켜주면 된다.

등록할 프로젝트를 들어가서 왼쪽 바에서 아래쪽에 settings를 보면, CI/CD 라고 나와있다.

 

들어가보면 runner를 등록할 수가 있다.

runner가 실행되고 있는 운영체제를 선택하면 되고,

Run untagged jobs 를 클릭해야 하는데, 특정 태깅이 된 프로젝트들만 빌드, runner를 작동할 수 있게 하는데

이 경우에는 태깅이 안 되어 있더라도 실행할 수 있도록 설정하는 것.

그리고 나서 다음 단계로 가면, runner가 등록을 할 준비가 완료되는 것.

 

step 1의 명령어를 gitlab이 설치된 호스트에서 실행해주면 된다.

token 정보가 중요한데, GitLab CI 는 이 token을 가지고 연결한 gitlab runner를 우리가 허용한 runner 라고 해서 등록을 해주는 것.

 

GitLab CI 서버가 있고 거기는 git 저장소를 가지고 있을 것.

gitlab runner를 아무거나 등록해주면 안 된다.

그렇게 하면 gitlab에 있는 데이터들이 외부에 노출될 수가 있기 때문.

외부에 gitlab runner가 등록 요청을 할 건데,

그 때 GitLab CI에서 발급한 token 을 가지고 등록 요청을 하고, 

GitLab CI는 자기가 발급한 token이 맞는지 확인을 하고,

확인이 되면은 gitlab runner가 여기 프로젝트에 접근할 수 있는 권한을 주는 것.

이후에,

gitlab은 주기적으로 gitlab에 있는 변동사항이 있는지 확인해서 있다면,

git에서 코드를 읽어와서 CI/CD 작업을 수행하게 되는 것. CI/CD 작업은 script를 읽어서 수행하는 것.

1. GitLab CI 서버와 Git 저장소가 존재
   └── GitLab은 프로젝트와 코드를 관리

2. GitLab Runner 등록
   ├── 외부 GitLab Runner가 등록 요청
   │    ├── GitLab CI에서 발급한 Token을 사용
   │    └── GitLab CI는 요청된 Token을 확인
   └── Token 검증 성공 시 GitLab Runner가 프로젝트 접근 권한 획득

3. GitLab Runner와 CI/CD 파이프라인 실행
   ├── GitLab은 저장소를 지속적으로 모니터링
   │    ├── 코드 변경 사항이 감지되면
   │    └── 변경된 코드를 Git에서 가져옴
   ├── GitLab CI는 프로젝트에 정의된 .gitlab-ci.yml 파일 확인
   │    └── CI/CD 작업 스크립트를 읽어 실행
   └── GitLab Runner는 스크립트를 실행하여 작업 수행
        ├── 예: 코드 빌드, 테스트, 배포
        └── 작업 결과를 GitLab CI에 보고

4. 결과
   ├── 작업 성공 또는 실패 여부를 GitLab CI가 기록
   ├── GitLab은 사용자에게 작업 상태 제공 (UI 또는 알림)
   └── CI/CD 작업 완료

---

요약된 플로우

1. GitLab CI 서버는 프로젝트와 저장소를 관리.
2. GitLab Runner 등록 요청: Token을 통해 Runner를 인증.
3. Runner와 CI/CD 실행: GitLab CI는 코드 변경을 감지하고 스크립트를 실행.
4. 결과: 작업 상태를 GitLab이 기록하고 사용자에게 알림.

이 플로우는 GitLab과 GitLab Runner 간의 상호작용을 단순하게 보여줍니다.

---

gitlab-runner가 등록이 완료되었다는 걸 확인할 수 있다

 

이제 자동으로 gitlab-runner를 실행할 수 있도록 설정해줘야 한다.

 

중간에 엄청 많은 과정이 있고, 그걸 100% 다 이해한건 아니지만,

결과적으로 재부팅되더라도 자동으로 실행되도록 설정을 완료했다!