[TIL] 241127 Docker Compose, CI/CD

MONA·2024년 11월 27일

나혼공

목록 보기

36/92

역경으로 시작한 아침..
코드카타 하는데 인텔리제이만 너무 버벅대서 50분 정도를 이것저것 설정 건드려보느라 날렸다
보조모니터 때문인가, 뭐 다른게 실행되고 있나.. 재부팅도 해보고 별걸 다했는데
충전 꽂으니까 말짱해졌다 ㅋ ㅋ ㅋ ㅋ ㅋ

Docker Compose

다중 컨테이너 애플리케이션을 정의하고 실행하기 위한 도구
단일 파일(docker-compose.yml)에 여러 컨테이너의 설정을 정의하여 컨테이너 간의 의존성, 네트워크, 볼륨 공유 등을 편하게 관리할 수 있다
여러 서비스를 한번에 실행, 중지, 재시작할 수 있는 도구.

주요 개념

Service
- 하나의 컨테이너 역할 ex) 웹서버, 데이터베이스 등
- docker-compose.yml 파일에서 각 서비스의 이미지를 정의하고 네트워크, 볼륨 등을 설정
Network
- 서비스 간 통신을 위한 네트워크 환경을 정의
- Docker Compose는 기본적으로 각 프로젝트에 고유한 네트워크를 생성
Volume
- 데이터를 컨테이너 외부에서 저장하여 데이터 지속성을 유지함
docker-compose.yml
- 애플리케이션의 여러 컨테이너와 설정을 YAML 포맷으로 정의
- 컨테이너 이미지, 환경 변수, 포트 매핑 등을 포함

주요 기능

다중 컨테이너 관리
- 웹 서버, 데이터베이스, 캐시 등 여러 컨테이너를 하나의 명령으로 실행 가능
의존성 관리
- 서비스 간의 의존 관계를 정의하여, 올바른 순서로 컨테이너 실행
개발 환경 설정
- 동일한 설정 파일을 사용하여 로컬 개발 환경과 배포 환경을 일치시킬 수 있음
데이터 지속성
- 볼륨을 설정하여 컨테이너를 재시작해도 데이터를 유지함

주요 명령어

명령어	설명
`docker compose up`	모든 서비스 컨테이너를 생성 및 실행
`docker compose up -d`	컨테이너를 백그라운드에서 실행
`docker compose down`	실행 중인 컨테이너를 중지 및 네트워크, 볼륨 삭제
`docker compose ps`	실행 중인 컨테이너 목록 확인
`docker compose logs`	모든 서비스의 로그 확인
`docker compose logs -f`	실시간 로그를 확인
`docker compose restart`	모든 컨테이너를 재시작
`docker compose build`	이미지를 새로 빌드

장단점

장점
1. 개발 환경 설정 간소화: 여러 컨테이너를 한 번에 설정하고 실행 가능
2. 환경 간 일관성: 동일한 설정 파일로 개발, 테스트, 프로덕션 환경을 구성
3. 의존성 관리: 서비스 간의 의존 관계를 명확히 정의하고 관리
4. 간편한 유지보수: YAML 파일을 수정하여 손쉽게 서비스 업데이트 가능

단점
1. 복잡성 증가: 프로젝트 규모에 맞게 선택해야 할 필요가 있다
2. 확장성 부족: 대규모 시스템에서는 Kubernetes와 같은 오케스트레이션 도구가 더 적합할 수 있음

Docker Compose와 Kubernetes

항목	Docker Compose	Kubernetes
목적	다중 컨테이너 애플리케이션의 로컬 환경 설정 및 실행	컨테이너의 대규모 배포, 스케일링, 관리
복잡성	간단하며, 소규모 프로젝트에 적합	복잡하지만 대규모 분산 환경에 적합
확장성	제한적 (로컬 개발 환경 중심)	자동 확장 및 고가용성 지원
운영 환경	주로 개발 및 테스트 환경	프로덕션 환경에 최적화
네트워크	기본적으로 프로젝트별 네트워크 생성	다양한 네트워크 옵션과 컨트롤 제공

Docker network

Docker container 간 통신을 설정하고 관리하기 위한 기능
네트워크를 통해 컨테이너 간 데이터 교환, 외부 네트워크와의 연결, 보안 설정 등을 제어할 수 있음

Docker는 컨테이너의 기본 네트워크 설정을 제공하며, 필요에 따라 사용자 정의 네트워크를 생성하고 구성할 수도 있다

특징

컨테이너 간 통신 지원: 동일 네트워크 내의 컨테이너는 자동으로 서로 통신 가능
네트워크 격리: 각 네트워크는 독립적이며, 컨테이너를 다른 네트워크로 격리 가능
유연한 설정: 기본 제공 네트워크 외에, 사용자 정의 네트워크를 구성할 수 있음
서비스 디스커버리: 사용자 정의 브리지 네트워크에서는 컨테이너 이름을 통해 서로 통신할 수 있음

유형

Bridge 네트워크
- 기본 네트워크로, 단일 호스트에서 컨테이너 간 통신에 사용
- Docker를 설치하면 기본적으로 bridge 네트워크가 생성됨
- 컨테이너 간 통신은 가능하지만 외부 네트워크와의 통신은 별도 설정이 필요함
Host 네트워크
- 컨테이너가 호스트의 네트워크 스택을 공유
- 컨테이너 내부 포트를 호스트의 포트로 직접 노출
- 네트워크 격리가 필요 없는 고성능 애플리케이션에 적합
None 네트워크
- 네트워크를 비활성화
- 네트워크 격리가 필요한 경우에 사용하며, 외부 연결 불가
Overlay 네트워크
- 여러 Docker 호스트 간에 컨테이너 통신을 지원하는 분산 네트워크
- Docker Swarm 또는 Kubernetes 환경에서 주로 사용
Macvlan 네트워크
- 컨테이너가 물리적 네트워크 인터페이스를 직접 사용
- 컨테이너에 고유한 MAC 주소를 제공하며, 외부 네트워크에서 직접 접근 가능
Third-party 플러그인 네트워크
- Calico, Flannel, Weave와 같은 외부 네트워크 플러그인을 사용

사용 시의 장점

유연한 네트워크 구성: 컨테이너 간 통신과 외부 네트워크 연결을 쉽게 구성 가능
보안 강화: 네트워크를 격리하여 컨테이너 간 불필요한 통신 방지
서비스 디스커버리: 사용자 정의 네트워크에서는 컨테이너 이름으로 쉽게 통신 가능
확장성: Overlay 네트워크를 통해 분산 환경에서 컨테이너 통신 지원

도커 네트워크와 컨테이너 간 통신

같은 네트워크라면

동일 네트워크에 연결된 컨테이너는 이름 또는 IP 주소를 통해 통신 가능
ex) curl http://app:8080

다른 네트워크

네트워크 간 통신은 기본적으로 차단되며, 별도 라우팅 설정이 필요함

외부 네트워크

컨테이너의 포트를 호스트 포트에 매핑하여 외부 통신 가능
ex) docker run -d -p 8080:80 nginx

Docker의 포트 번호와 네트워킹

Docker에서 컨테이너는 격리된 네트워크 환경에서 실행되며, 컨테이너의 내부 포트와 호스트 포트를 매핑하여 통신함
같은 컨테이너 포트 번호라도 다른 호스트 포트에 연결하면 문제 없이 실행 가능

포트 매핑(Publishing Ports)

컨테이너 내부 포트 (Container Port)
- 컨테이너 내부에서 애플리케이션이 사용하는 포트
- ex) 웹 서버가 80번 포트에서 실행
호스트 포트 (Host Port)
- 컨테이너의 포트를 호스트 머신에 노출하는 포트
- ex) 8080번 호스트 포트를 컨테이너의 80번 포트에 매핑
포트 매핑 구조
- docker run 명령에서 -p 옵션을 사용하여 매핑
- 형식: <호스트 포트>:<컨테이너 포트>
- ex) docker run -d -p 8080:80 nginx
  - 호스트의 8080 포트 → 컨테이너의 80 포트로 연결

포트 번호의 동작 원리

호스트 포트가 다르면 동일한 컨테이너 포트를 여러 번 사용 가능
```
docker run -d -p 8080:80 nginx
docker run -d -p 8081:80 nginx
```

두 컨테이너 모두 내부 80번 포트를 사용하지만 각각 호스트가 8080과 8081로 매핑되어 충돌하지 않음
호스트 포트가 동일하면 충돌이 발생함!

호스트 포트를 지정하지 않을 경우 자동 할당
-p <컨테이너 포트> 형식으로 작성하면 Docker가 사용 가능한 호스트 포트를 자동 할당해줌
```
docker run -d -p 80 nginx
```


+포트 번호는 `docker ps`나 `docker inspect` 명령어로 확인할 수 있다

### Docker 네트워크 모드에 따른 포트 매핑 차이
1. Bridge 네트워크(기본)
  - 컨테이너는 자체 IP 주소를 사용하며, 포트 매핑을 통해 호스트와 통신함
  - 외부에서 접근하려면 -p 옵션을 사용해 포트를 노출
2. Host 네트워크
  - 컨테이너가 호스트의 네트워크 스택을 공유
  - 포트 매핑 없이 컨테이너 포트가 호스트 포트에 직접 연결함
  ```docker run --network host nginx```
3. None 네트워크
  - 컨테이너가 네트워크를 비활성화하며, 외부 통신이 불가함

## 해보자!

### 1. Docker를 이용해 컨테이너 간 통신

- service A, B 컨테이너 생성
- service A 컨테이너로 호출 -> service B 호출 -> 응답 반환

1. Service A, B를 생성하고 각각 기본 설정과 컨트롤러 작성을 진행

- service A
```java
@RestController
@AllArgsConstructor
public class AController {

    private final BServiceClient bServiceClient;


    @GetMapping("/hi")
    public String hi() {
        String messageB = bServiceClient.getHello();
        return "service-a : hi~ service-b : " + messageB;
    }
}

service B

@RestController
public class BController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello from B~";
    }

}

service A의 "/hi"로 요청을 보내면, Feign Client를 통해 B service에 요청을 보내고, "/hello" 경로의 응답을 가져올 것이다.

요러케.
A는 18080, B는 18081 포트로 실행중이다.

정상 실행되는 것을 확인하고, 컨테이너 간의 통신을 시도해본다.
어차피 다른 환경에서 돌아가기 때문에 포트번호도 일치시켜주고, 각 서비스에 Dockerfile을 생성했다.

Dockerfile 생성

FROM openjdk:17-jdk-slim

VOLUME /tmp

ARG JAR_FILE=build/libs/*.jar

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["java","-jar","/app.jar"]

Docker network 생성

서로를 이름으로 호출하기 위해 사용자 정의 네트워크를 만들 것이다.

docker network create my-network

Is the docker daemon running? -> open -a Docker 로 Docker 실행

네트워크가 정상 생성 되었다.

이미지 생성

각각의 서비스 프로젝트를 빌드하고 각각의 이미지를 생성한다.

 docker build -t img-service-a .

docker build: Docker 이미지 생성
-t img-serevice-a
- -t: Tag. 생성된 이미지에 이름을 부여함
- img-service-a: 생성될 이미지의 이름(tag)
- 태그는 name:tag 형식으로 지정할 수 있으며, 기본적으로 latest 태그가 사용된다(ex: img-service-a:1.0)
.
- 이미지 빌드의 컨텍스트 지정
- 현재 디렉토리를 기준으로 Dockerfil과 관련 파일을 찾음
- Docker는 빌드 과정에서 필요한 모든 파일을 컨텍스트로 복사하여 이미지 생성에 사용함
생성된 이미지는 docker images 명령어로 확인 가능

컨테이너 생성

같은 방법으로 service A도 띄워준다

정상적으로 컨테이너가 띄워진 걸 확인하고, 아까와 같은 방법으로 호출해본다.

정상적으로 응답이 반환되는 것을 확인할 수 있다.

2. Docker Compose 이용해보기

현재 올라가있는 컨테이너를 삭제한다.

일단 실행중인 컨테이너를 내리고, docker -rm 으로 컨테이너를 지웠다.

docker-compose.yml 파일 생성
두 서비스가 모두 포함되어 있는 루트 디렉토리에서 만들어줬다.

version: '3.8'

services:
  service-a:
    image: img-service-a
    ports:
      - "18080:8080"
    environment:
      - SERVICE_B_URL=http://service-b:8080
    depends_on:
      - service-b

  service-b:
    image: img-service-b
    ports:
      - "18081:8080"

networks:
  default:
    driver: bridge

실행하면 포함된 서비스(여기선 2개)의 실행 로그가 막 섞여 뜬다.

정상 실행 중임을 확인

요청을 보내면 응답이 정상 반환됨을 알 수 있다. 와!

+docker compose는 실행될 때 새로운 네트워크를 만들어 포함된 서비스들을 한 네트워크 내에서 실행한다.

위의 docker compose 내 서비스들은 docker_prac_default 라는 새로운 브리지 네트워크에서 실행된 것.

CI/CD

Continuous Integration(지속적 통합)
Continuous Delivery/Deployment (지속적 배포/전개)

소프트웨어 개발에서 자동화된 프로세스로 코드를 빠르고 신뢰성 있게 빌드, 테스트, 배포하는 방법론
코드 변경사항이 애플리케이션에 통합되고 사용자에게 제공되는 속도와 품질을 향상시킬 수 있음

CI (지속적 통합, Continuous Integration)

코드 변경 사항을 자주 병합하고 자동으로 빌드 및 테스트하는 프로세스
개발자는 소스를 자주 리포지토리에 푸시하며, 각 푸시마다 자동화된 빌드와 테스트가 진행됨

목표

코드 변경 시 문제를 조기에 발견함
개발자 간의 충돌을 최소화함
소프트웨어 품질 향상

주요 단계
1. Push: 개발자가 코드 변경사항을 리포에 올림
2. 자동 빌드: push된 코드로 애플리케이션을 빌드
3. 자동화 테스트: 빌드된 애플리케이션에 대해 유닛 테스트, 통합 테스트 등 실행

CD (지속적 배포/전개, Continuous Delivery/Deployment)

Continuous Delivery (지속적 배포)

자동화된 배포 준비 프로세스로, 언제든지 안정적인 상태에서 배포 가능
운영 환경 배포는 사람이 승인(수동)하여 진행

Continuous Deployment (지속적 전개)

자동화된 배포가 한 단계 더 발전하여, 코드가 푸시되면 자동으로 운영 환경에 배포
사람이 개입하지 않으며, 높은 자동화와 테스트 신뢰성이 요구됨

항목	Continuous Delivery	Continuous Deployment
배포방식	자동화된 배포 준비+수동 승인	자동화된 배포가 운영 환경까지 진행
자동화 수준	배포 준비 단계까지 자동화	전체 프로세스 자동화
적용 사례	운영 환경 배포가 신중히 진행되어야 하는 경우	빠른 피드백과 빈번한 릴리스를 원하는 경우

CI/CD 파이프라인

CI/CD는 파이프라인으로 구성되며, 각 단계가 자동으로 실행됨

주요 단계

코드 소스 관리: Git 등 소스 관리 시스템에 코드 변경사항 push
빌드: 코드로부터 실행 가능한 애플리케이션 생성
테스트: 유닛 테스트, 통합 테스트 등 자동화된 테스트 실행
배포 준비: 준비된 애플리케이션을 스테이징 환경에 배포
운영 배포: 운영 환경에 애플리케이션 배포

장점

빠른 피드백: 문제를 조기에 발견하고 수정하여 개발 속도와 품질 향상
자동화: 수작업의 반복 작업을 줄여서 효율성을 높이고 오류를 최소화할 수 있음
빈번한 릴리스: 새로운 기능이나 버그 수정 사항을 빠르게 제공할 수 있음
일관성: 동일한 프로세스를 사용하여 안정적이고 예측 가능한 배포 가능
협업 강화: 팀원 간 충돌을 줄이고 협업을 원활하게 함

주요 CI/CD 도구

도구	설명
Jenkins	가장 인기 있는 오픈소스 CI/CD 도구. 다양한 플러그인으로 확장 가능
GitLab CI/CD	GitLab과 통합된 CI/CD 도구. 코드 관리와 배포를 하나의 플랫폼에서 수행
CircleCI	클라우드 기반 CI/CD 도구로 간단한 설정과 빠른 빌드를 지원
Travis CI	오픈소스 프로젝트에 자주 사용되는 CI/CD 도구
AWS CodePipeline	AWS 서비스와 통합된 CI/CD 솔루션
Azure DevOps	Azure 클라우드 환경에서의 CI/CD 솔루션
ArgoCD	Kubernetes 환경에서 GitOps 기반의 지속적 배포 도구
Spinnaker	멀티클라우드 환경에서 배포 자동화와 관리 기능을 제공
TeamCity	JetBrains에서 제공하는 CI/CD 도구로, 강력한 설정 및 통합 기능을 지원
Bamboo	Atlassian의 CI/CD 도구로, Jira와 연동하여 강력한 워크플로우 관리 지원

도입 시 고려사항

자동화 수준: 빌드, 테스트, 배포의 자동화 수준을 결정
테스트 신뢰성: 배포 자동화를 위해 자동화 테스트의 신뢰성을 높여야 함
도구 선택: 팀의 요구사항에 맞는 CI/CD 도구를 선택해야 함
배포 전략: Canary 배포, Blue-Green 배포 등 안정적인 운영 환경 배포 전략 도입

Amazon ECS (Elastic Container Service)

AWS에서 제공하는 완전 관리형 컨테이너 오케스트레이션 서비스
컨테이너화된 애플리케이션의 배포, 확장, 관리를 간소화하는데 사용됨
Docker 컨테이너를 기반으로, 인프라 없이 컨테이너를 실행하고 오케스트레이션 할 수 있는 기능을 제공

주요 특징

완전 관리형 서비스

AWS에서 제공하는 완전 관리형 컨테이너 서비스로, 컨테이너의 배포, 스케일링, 로드 밸런싱 등을 자동으로 관리

Docker 지원
- Docker 컨테이너를 기본으로 지원하며, 기존 Docker 애플리케이션을 ECS로 쉽게 마이그레이션 가능
유연한 컴퓨팅 옵션
- 두가지 컴퓨팅 옵션을 제공함
  - EC2 Launch Type: Amazon EC2 인스턴스를 사용하여 컨테이너 실행
    - 사용자가 EC2 인스턴스를 프로비저닝하고 관리
    - 클러스터 노드로 EC2를 사용하여 작업 실행
  - Fargate Launch Type: 서버리스 방식으로 인프라 프로비저닝 없이 컨테이너 실행
    - 서버리스 방식. EC2 인스턴스 관리 없이 컨테이너 실행
    - 사용자는 애플리케이션 요구사항만 정의(CPU, 메모리 등)
통합 서비스
- Amazon CloudWatch, IAM, ELB, VPC 등 AWS 서비스와 원활히 통합
확장성
- 애플리케이션 트래픽 증가에 따라 자동으로 컨테이너를 확장
비용 효율성
- Fargate를 통해 사용한 만큼만 비용을 지불
클러스터 관리
- ECS 클러스터를 사용하여 컨테이너화된 애플리케이션을 분리, 그룹화 및 관리

+인프라 프로비저닝: 애플리케이션을 실행하기 위한 서버, 네트워크, 스토리지 등 IT 인프라 자원을 준비하고 설정하는 과정

구조

Amazon ECR (Elastic Container Registry)

컨테이너 이미지를 저장, 관리, 배포하는 Docker 레지스트리 서비스
기능
- 컨테이너 이미지 업로드 및 다운로드 지원
- 프라이빗 및 퍼블릭 레지스트리 제공
- IAM으로 세분화된 엑세스 제어 가능

ECS Cluster

ECS에서 task 및 service를 실행하는 논리적 그룹
구성: EC2 Launch Type, Fargate Launch Type
기능
- task와 service 실행 환경 제공
- 클러스터 내 리소스를 기반으로 컨테이너 스케줄링

ECS Task

ECS에서 실행되는 컨테이너의 단일 인스턴스
작업 정의(task definition)을 기반으로 실행
구성: 사용할 컨테이너 이미지, 리소스 요구사항, 포트 매핑 및 환경변수

Task Definition (작업 정의)

컨테이너를 실행하기 위한 구성 템플릿
구성
- Docker 이미지 정보
- 컨테이너 포트 매핑
- CPU 및 메모리 리소스 설정
- 볼륨 및 환경 변수 설정

ECS Service

클러스터에서 작업을 안정적으로 실행하고 유지함
기능
- 작업 복제본의 원하는 개수 유지
- 로드 밸런싱을 통한 트래픽 분산
- 장애 발생 시 작업 재시작

Load Balancer

서비스로 들어오는 트래픽을 여러 작업으로 분산
지원 유형
- Application Load Balancer (ALB): HTTP/HTTPS 트래픽에 최적화
- Network Load Balancer (NLB): TCP/UDP 트래픽에 최적화

Amazon CloudWatch

ECS 클러스터, 서비스, 작업 등의 모니터링 및 로깅
기능
- ECS 이벤트와 작업 상태 모니터링
- CPU, 메모리 등 리소스 사용률 추적

IAM (Identity and Access Management)

ECS 리소스와 작업의 권한 및 보안 관리
기능
- EC2 or Fargate 작업의 권한 및 보안 관리
- 작업이 S3, RDS 등 다른 AWS 서비스에 접근할 수 있도록 설정

구조 다이어그램

+---------------------+
| Amazon ECR          |  <- 컨테이너 이미지 저장
+---------------------+
         ↓
+---------------------+
| ECS Cluster         |  <- 컨테이너 실행 환경 (EC2 or Fargate)
+---------------------+
         ↓
+---------------------+
| ECS Service         |  <- 작업(Task) 관리 및 트래픽 분산
+---------------------+
         ↓
+---------------------+
| ECS Task            |  <- 컨테이너 실행 인스턴스
+---------------------+
         ↓
+---------------------+
| Docker Container    |  <- 실제 실행되는 컨테이너
+---------------------+

작동 원리

이미지 준비

애플리케이션을 Docker 이미지로 빌드 후 Amazon ECR에 업로드

작업 정의 작성

JSON 템플릿에 컨테이너 세부 정보 작성
ex) docker image, port 매핑, 환경변수

클러스터 생성

EC2 또는 Fargate를 사용하여 ECS 클러스터 생성

서비스 생성

작업 정의를 기반으로 컨테이너 실행
서비스가 task 수를 유지하며, 트래픽 분산을 위해 로드 밸런서 연결

모니터링 및 스케일링(로드 밸런싱 및 확장)

Auto Scaling을 사용하여 작업(Task) 수를 동적으로 조정
서비스에 로드 밸런서를 연결하고 컨테이너 자동 확장 설정

장단점

장점
1. AWS와의 통합: IAM, CloudWatch, VPC 등 AWS 서비스와 긴밀하게 연동
2. 유연한 실행 방식: EC2와 Fargate를 선택적으로 사용 가능
3. 비용 효율성: 서버리스(Fargate)를 통해 필요 리소스만 사용
4. 보안: IAM을 통한 세분화된 권한 관리 및 네트워크 격리
5. 확장성: 트래픽에 따라 컨테이너를 자동 확장

IAM (Identity and Access Management): AWS 리소스의 보안 및 엑세스 관리를 위한 서비스. 사용자와 리스소 간의 권한을 세부적으로 제어하고 리소스 접근 권한을 설정할 수 있음

단점
1. AWS 종속성: AWS 전용 서비스로 멀티 클라우드 환경에서는 제한적
2. Kubernetes와의 비교: EKS(Kubernets 기반)보다는 생태계 확장성이 떨어진다는 평가

ECS와 EKS

항목	Amazon ECS	Amazon EKS
초점	Docker 컨테이너 오케스트레이션	Kubernetes 기반의 컨테이너 오케스트레이션
관리 방식	AWS 전용 오케스트레이션 서비스	Kubernetes API를 사용하여 멀티 클라우드 지원 가능
컴퓨팅 옵션	EC2 및 Fargate 지원	EC2 및 Fargate 지원
복잡성	간단한 설정과 관리	Kubernetes의 복잡한 설정 필요
확장성	AWS 서비스에 최적화된 확장성 제공	Kubernetes의 네이티브 확장성 제공 (HPA, VPA 등)
생태계	AWS 서비스와 긴밀히 통합 (CloudWatch, IAM 등)	Kubernetes 에코시스템(Helm, Kubectl 등)을 활용 가능
유연성	AWS 환경에 특화, 멀티 클라우드에는 제한적	멀티 클라우드 및 하이브리드 환경에 적합
러닝 커브	상대적으로 쉬운 사용과 관리	Kubernetes의 러닝 커브가 높음
비용	ECS는 기본적으로 무료이며, 리소스 사용량에 따라 비용 발생	EKS는 관리 비용이 추가됨($0.10/시간/클러스터)
사용 사례	단일 클라우드 환경에서 간단한 컨테이너 배포	멀티 클라우드, 하이브리드 환경에서 복잡한 워크로드 관리

CI/CD 구축해보기

Gitlab 파이프라인 이용
파이프라인에서 빌드하여 AWS ECR에 Docker image 등록하고 파이프라인의 Deploy에서 ECS에 어플리케이션 배포

프로젝트 루트에 Dockerfile 생성

FROM openjdk:17-jdk-slim

VOLUME /tmp

ARG JAR_FILE=build/libs/*.jar

COPY ${JAR_FILE} app.jar

ENTRYPOINT ["java","-jar","/app.jar"]

aws 내 설정

보안 그룹 설정: 80, 8080 포트 추가
ECR 생성
ECS 생성
클러스터 생성 중 에러 발생

사유 확인

재시도 하고 다시 실패했으나 기다리니 성공

테스크 생성
- 이미지 URI: 이전에 생성한 ECR URI
서비스 생성
- 패밀리: 좀전에 작성한 task 지정
IAM 사용자 생성, 엑세스 키 만들기

gitlab

Gitlab CI/CD -> Add variable

루트 디렉토리에 .gitlab-ci.yml 작성

Push 후 gitlab build->pipelines 확인

실패함.
후다닥 계정 인증하고 파이프라인을 재생성했다.

초록색 체크가 뜨면 Passed. 누르면 진행 상황을 확인할 수 있다.

아래 파이프라인과 달리 위처럼 모두 passed 상태가 되면 성공한 것이다.

확인

로드 밸런서의 DNS 이름 + 엔드포인트로 정상 배포되었는지 확인

프로젝트에 작성해둔 "/sample" 요청에 정상적으로 응답이 반환함을 확인할 수 있었다.

MONA

고민고민고민

이전 포스트

[TIL] 241126 PriorityQueue, Kubernetes 알아보기, Docker

다음 포스트