티스토리 뷰
정말로 대부분의 케이스에서는 elastic beanstalk도 아주 훌륭한 선택입니다
매우 손쉽게 배포환경을 구축 및 운영할 수 있습니다
eb 어플리케이션을 만든 후에 새로운 버전의 코드를 업로드하는것만으로 새로운 환경을 만들어 배포하는것이 가능한 흐름을 지니고 있습니다
이러한 elastic beanstalk는 멀티컨테이너형태로 구성시 다음과 같은 구성도를 갖게 됩니다
하나의 인스턴스에 구성에 따라 정해놓은 컨테이너들이 배치됩니다(위의 그림에서는 container1, container2, container3)
그리고 auto scale을 통해 인스턴스가 확장되면 동일한 구성이 계속해서 복사되는 방식으로 인스턴스가 확장됩니다
손쉬운 배포라는 측면에서 매우 좋지만 여러종류의 컨테이너들을 클러스터단위로 관리하고 배포하기에는 적합하지 않는 측면이 있습니다
그래서 좀 더 고차원의 요구사항에 맞게 컨테이너를 클러스터링하고 싶은 경우에는
ecs(elastic container service)를 이용하면 됩니다
ecs는 왼쪽의 서버리스 기반의 fargate와 오른쪽의 ec2 기반의 ecs를 선택할 수 있습니다
두개의 차이는 바로 이 그림을 통해서 알 수 있는데요
왼쪽은 EC2 기반의 ECS이고 오른쪽은 Fargate 기반의 ECS입니다
왼쪽의 ec2 기반은 ecs는
ECS로 관리되는 각 인스턴스에 ECS 에이전트와 Docker agent를 설치하고
이 모든 인스턴스를 ECS가 통합하여 관리하게 됩니다
이 말은 즉 ec2를 관리해야할 관리포인트가 생긴다는 점입니다
그러나 이러한 인스턴스들을 관리해야하는 관리 포인트마저 제거한 것이 서버리스의 fargate 입니다
오른쪽 그림에서 보시면 각각의 컨테이너들은 인스턴스에 묶이지 않고 자유자재로 관리됩니다
물론 aws 어딘가에 인스턴스가 생성되겠지만
인프라를 구성하는 우리들 입장에서는 container가 어딘가에서 띄워지고 관리되는구나 라고만 인지하면 됩니다
ecs의 ec2를 섬세하게 관리하고자 한다면 ec2 기반의 ECS를
좀 더 심리스하게 컨테이너들만 관리하고 싶다면 fargate를 사용하시면 됩니다
비용적인 측면에서 ec2를 운영하는것보다 fargate가 좀 더 비쌉니다만 이제는 서울리전에서도 spot fargate를 사용할수 있습니다
잠시 요금얘기를 해보자면(2022.2.3일 기준 서울리전)
ec2는
t3.micro 시간당 0.013 USD 2vcpu 1GiB
t2.micro 시간당 0.0144 USD 1vcpu 1GiB
fargate는
vcpu당 0.04656 USD
GB당 0.00511 USD
입니다
fargate를 1vcpu 1GB 사용한다면 그 합이 0.05167 USD 정도가 되는데
동급의 ec2에 비해서 많게는 3배까지 비용이 비쌉니다
그만큼 서버리스의 장점이 있겠지만 비용대비해서는 좀 더 고민을 해보아야 할 것입니다
시작하기 마법사를 통해 fargate ecs를 한번 만들어볼까요
컨테이너 정의섹션에서 custom을 선택하여 구성 버튼을 클릭합니다
컨테이너를 설정합니다
적당한 이름을 정하고 컨테이너 이미지 경로를 넣습니다
ecr에 컨테이너 이미지를 푸시했다면
ecr 화면에서 해당하는 이미지의 URI를 복사하여 붙여넣기 하면 됩니다
그리고 포트매핑은 컨테이너에서 사용하는 포트번호를 넣어주세요
그리고 작업 정의 섹션의 편집 버튼을 누르면 작업 정의 구성 화면이 나타납니다
일단은 변경하지 말고 그대로 유지해서 진행해봅시다
컨테이너 정의와 작업 정의가 끝났으니 서비스를 정의 합니다
서비스 정의에서 로드밸런서가 필요한 경우라면 로드밸런서 유형을 Application Load Balance로 설정합니다
마지막으로 클러스터 구성입니다
VPC와 서브넷이 자동으로 생성되네요
기본 구성대로 가봅시다
이렇게 모든 설정을 끝마쳤습니다
자동적으로 클러스터, 서비스, 작업정의, 컨테이너가 생성됩니다
ecs 메뉴의 클러스터 화면에서도 생성한 default 클러스터가 확인됩니다
작업 메뉴에서는 현재 실행중인 작업(컨테이너)이 하나 보이는군요
그런데 컨테이너의 실행포트와 로드밸런서에 연결할 포트가 다른경우
(예를 들면 도커내의 컨테이너에서 웹어플리케이션이 3000번 포트에서 실행되고 있는데 로드밸런서에서는 80번 포트로 접속하게 하고 싶은 경우)
마법사 시작화면에서는 이 두가지를 따로 설정할수 있는 방법이 없습니다
그래서 생성후에 직접 이 클러스터에 연결된 로드밸런서를 찾아가서 리스너의 포트를 변경하고, 보안그룹의 포트도 변경해주는 작업을 해야합니다
자 이렇게 수정을 마치고 로드밸런서의 public url로 접근하시면 원하는 화면을 보실수 있습니다
소스코드가 변경되어 업데이트를 할때는 이렇게 합니다
ecs가 컨테이너 기반으로 동작하기 때문에 새로운 컨테이너 이미지를 등록하면 됩니다
작업 정의 메뉴로 이동하여 생성되어있는 작업에 체크를 합니다
작업에 체크를 하면 "새 개정 생성" 이라는 버튼이 활성화 되는데
이버튼을 눌러주세요
그렇게 되면 기존 작업정의의 새로운 버전을 만들수 있게 됩니다
기존의 작업정의에서 메모리나 cpu를 변경할 수도 있습니다
하지만 우리에게 필요한것은 작업에 연결된 컨테이너를 교체하는것입니다
여기에 기존에 있는 컨테이너 이름을 선택하고 새로운 컨테이너 이미지 주소를 넣어주면 됩니다
새로운 이미지 주소를 넣고 업데이트를 하면 새로운 작업 개정이 생성됨과 동시에 작업에 정의된 컨테이너로 새로 배포되는 작업이 진행됩니다
'AWS' 카테고리의 다른 글
aws aurora database 로 손쉬운 replication 클러스터 구축 (0) | 2022.02.10 |
---|---|
ecs fargate codepipeline 연결하기 (0) | 2022.02.08 |
docker 파일 하나로 단일 컨테이너 elastic beanstalk에 배포하기 (0) | 2022.02.05 |
nodejs elastic beanstalk 에 codepipeline 배포하기 (0) | 2022.02.04 |
codepipeline으로 푸시부터 빌드를 지나 배포까지 완성 (0) | 2022.02.03 |
- Total
- Today
- Yesterday
- 경진대회
- Apple
- 웹표준
- 자바스크립트
- 네이버
- 모바일
- 어플리케이션
- JavaScript
- 스마트폰
- 공모전
- 창업
- 게임
- android
- 아이디어
- php
- 트위터
- 안드로이드
- iPhone
- 벤처
- 앱
- CSS
- 구글
- 대학생
- 앱스토어
- AWS
- 아이폰
- 소프트웨어
- 애플
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |