AWS(Amazon Web Services)는 2019년 기준으로 전 세계 클라우드 인프라 시장의 33%를 차지하는 업계의 리더입니다. 2020년 1월 현재, AWS는 컴퓨팅, 스토리지, 데이터베이스, 분석, 네트워킹, 모바일, 개발자 도구, 관리 도구, IoT, 보안 및 엔터프라이즈 애플리케이션을 포함하여 160개에 이르는 클라우드 기반의 제품을 전 세계에 제공하고 있습니다. 스타트업, 대기업 및 정부 기관을 포함한 수백만 고객사들이 AWS의 클라우드 서비스를 이용하여 사업을 강화해 나가고 있습니다.
개발 도구를 통해 클라우드의 활용도를 크게 향상할 수 있으며, 조직은 강력한 클라우드 컴퓨팅의 이점을 활용하기 위해 클라우드 네이티브 애플리케이션 개발방식을 채택하고 있습니다. 클라우드 네이티브 기술을 사용하는 조직은 클라우드 서비스를 무한정 개발하고 배포할 수 있습니다. 반면, 각기 다른 언어로 개발되어 별도의 툴을 통해 배포되는 여러 마이크로서비스를 관리하는 소규모 조직들은 정보의 고립(silo)에 이르게 됩니다.
툴 체인(Tool Chain)의 복잡성은 오늘날 클라우드 네이티브 개발을 수행하는 DevOps 팀들의 공통 화두입니다. Forrester가 IT 전문가들을 대상으로 2019년에 실시한 설문조사에서, 많은 소프트웨어 개발팀이 여러 도구를 관리하고 통합하는 데 어려움을 겪고 있음을 토로했습니다. AWS 서비스를 활용하기 위해서, 개발팀은 코드 배포를 위해 5가지, 혹은 그 이상의 도구를 사용해야 할 수 있습니다. 그런 다음, 이러한 도구를 관리해야 합니다. 개발자는 새로운 혁신이나 개발보다는, 복잡한 툴 체인을 관리하는 데 많은 시간을 소모하게 됩니다.
AWS는 스토리지, 네트워킹, 서버 리스(serverless)에 이르기까지 모든 것을 한 곳에서 제공하는 올인원 클라우드 서비스이며, 이로 인해 많은 조직이 AWS를 사용하고 있습니다. AWS는 포괄적인 서비스로, 고객들은 다음과 같은 이점들을 누릴 수 있습니다.
- 간단함: 모든 클라우드 데이터를 한 곳에서 관리.
- 편리함: 필요한 모든 것을 구 비하고 있음.
- 신뢰성: 우리의 솔루션을 믿고 맡길 수 있음.
- 사용의 편의성: 여러 클라우드 서비스를 사용하기 위한 교육을 받을 필요가 없음.
심플한 클라우드 운영을 위해 AWS에 올인하는 조직도 있지만, AWS가 워낙 방대한 클라우드 서비스를 제공하기 때문에 효율적인 기능 사용에는 한계가 있을 수 있습니다.
DevOps 도구를 사용하면, 이러한 올인원 전략을 취함과 동시에 기능적인 효율성 또한 만족시킬 수 있습니다. DevOps 팀은 개별적인 툴을 통합하고 관리하는 대신, GitLab 하나만 사용하여 단일 통합 환경에서 소프트웨어 개발 수명 주기 전체를 관리할 수 있습니다.
GitLab에서 AWS 사용하기
GitLab과 여타 다른 DevOps 애플리케이션들의 차이점은, 단일 인터페이스에서 소프트웨어 전체 개발 수명 주기를 관리할 수 있어 복잡한 툴 체인이 필요 없다는 것입니다. GitLab CI/CD를 사용하면 모든 AWS 서비스에 맞춤화된 배포가 가능합니다. 이 포스트에서는 GitLab과 AWS의 5가지 인기 서비스인 Lambda, Fargate, EKS, ECS 및 EC2가 어떻게 통합되는지 살펴봅니다.
GitLab + Lambda
CNCF(Cloud Native Computing Foundation)가 2019에 실시한 설문조사에 따르면 41%의 응답자가 서버 리스 기술을 사용하고 있습니다. 서버 리스를 사용하는 이용자 중 80%는 호스팅 플랫폼 서비스를, 나머지 20%는 설치형 소프트웨어를 사용하고 있습니다. 호스팅 서비스 이용자들이 뽑은 최고의 도구는 AWS Lambda(53%)입니다.
AWS Lambda는 가장 주목받는 서버 리스 애플리케이션 구축 서비스입니다. 서버 리스 애플리케이션 구현에는 다음과 같은 서비스가 필요합니다.
- 컴퓨팅 서비스
- 데이터베이스 서비스
- HTTP 게이트웨이 서비스
Lambda는 오픈소스 솔루션뿐만 아니라 다른 AWS 서비스와 통합이 가능한 AWS의 독자적인 서비스입니다. 오늘날 서버 리스 애플리케이션을 구축하는 대부분의 개발자는 Lambda 함수를 사용하고 있습니다.
서버 리스 채택을 위한 가장 큰 장애물은 도구의 선택과 워크플로우의 정립입니다. 조직은 서버 리스의 확장성과 자동화를 반기지만 효과적으로 구현할 수 있는 도구의 부재에 대해 걱정합니다. 복잡한 툴 체인 환경에서 일하고 있는 기업들은, 이미 복잡한 개발 스택에 또 다른 툴을 추가하는 것에 대해 주저하고 있습니다.
GitLab에서는 다음의 조합을 통해 AWS Lambda 함수를 배포할 수 있으며, 풍부한 서버 리스 애플리케이션의 개발이 가능합니다.
- AWS 서버 리스 프레임워크 (Serverless Framework)
- AWS 서버 리스 애플리케이션 모델 (SAM, Serverless Application Model)
- GitLab CI/CD
GitLab 사용자는 Serverless Framework/JS 템플릿에서 프로젝트를 생성 할 수 있습니다:
템플릿 불러오기가 완료되면, 샘플 프로젝트를 이용해서 시작할 수 있습니다.
다음 단계: 인증에 사용할 AWS IAM 계정을 생성합니다.
사용자에게 필요한 정책을 선택합니다.
과정을 완료하면 아래와 같은 결과에 대한 요약화면을 볼 수 있습니다.
다음 단계 : 아래와 같이 AWS_ACCESS_KEY
와 AWS_SECRET_ACCESS_KEY
를 CI/CD 변수로 프로젝트에 추가합니다.
프로젝트 샘플에는 .gitlab-ci.yml
파일이 포함되어 있습니다. 레포지토리 변경이나 파이프라인(Pipeline) 시작 시 아래와 같이 4개의 CI 작업(test
, production
, postdeploy_test
및 pages
) 이 실행됩니다.
production 작업이 완료되면 Lambda 엔드포인트 URL이 생성됩니다.
해당 URL로 GET 요청을 전송하면 다음과 같은 샘플 텍스트가 반환됩니다.
GitLab + SAM
AWS SAM(Serverless Application Model)은 AWS에서 서버 리스 애플리케이션을 구축하기 위한 최고의 오픈소스 프레임워크입니다. 이는 서버 리스 애플리케이션에서 일반적으로 사용되는 Lambda 함수, API 게이트웨이의 API 및 DynamoDB 테이블과 같이 AWS 리소스를 보다 쉽게 생성하고 배포할 수 있는 CloudFormation의 확장된 형태라고 볼 수 있습니다.
SAM은 템플릿 기능 외에도 테스트와 배포를 위한 CLI를 제공하지만, 일부 CLI 명령은 CloudFormation을 호출하기 위한 별칭(alias)입니다. 이 샘플 프로젝트에서는 SAM 애플리케이션을 구축하고 배포하기 위해 AWS CloudFormation CLI를 사용했습니다.
{{cookiecutter.project_name}}
폴더 안에 "AWS News"라는 샘플 SAM 애플리케이션이 포함되어 있지만, 레포지토리 최상단에 존재하는 .gitlab-ci.yml
파일을 모든 SAM 애플리케이션에서 사용하는 것도 가능합니다.
먼저 AWS SAM CLI를 설치합니다.
SAM init 명령어를 실행하여 hello-world 예제가 포함된 AWS SAM 프로젝트를 생성합니다.
gitlab-aws-sam-demo라는 프로젝트 폴더가 생성됩니다. 다음으로, 프로젝트를 빌드하고 배포하기 위해 .gitlab-ci.yml
파일을 생성합니다.
다음으로, git init 명령어를 실행하여 GitLab에 푸쉬합니다.
파이프라인 작업이 완료되면, 아래와 같이 서버 리스 엔드포인트의 URL이 출력됩니다.
curl을 사용하여 서비스 엔드포인트로부터 “Hello World”라는 메시지가 출력되는지 확인합니다.
추가적인 참고자료:
- serverless.yaml 설정
- 서버 리스 함수를 AWS Lambda에 배포하는 방법에 대한 문서화
- GitLab CI/CD를 이용해서 AWS Lamda 함수 배포하기
- AWS 서버 리스 애플리케이션 모델 (SAM, Serverless Application Model)
- 서버 리스 프레임워크 (Serverless Framework)
- CI/CD에 TriggerMesh KLR 사용하기
GitLab + Fargate
최근 Datadog이 실시한 시장분석에 따르면, AWS에서 컨테이너를 실행하는 회사 중 19% 가 AWS Fargate를 사용하고 있으며, 이는 전년 대비 14% 증가한 수치입니다. Fargate의 빠른 발전을 통해 아마존 엘라스틱 컨테이너 서비스(ECS, Elastic Container Service)는 AWS 환경에서 쿠버네티스(Kubernetes)의 지속적인 성장에 발맞추어 왔습니다.
AWS Fargate는 ECS 및 EKS (Amazon Elastic Kubernetes Service)와 함께 작동하는 컨테이너용 서버 리스 컴퓨팅 엔진입니다. Fargate를 이용하면 기본적으로 서버를 프로비저닝하고 관리할 필요가 없어지며, 개발자는 애플리케이션별로 리소스를 지정할 수 있습니다.
GitLab와 Fargate를 사용하려면 아래와 같은 AWS 스택이 필요합니다.
- Amazon ECS 클러스터
- Fargate 작업을 실행하는 클러스터에 속하게 될 서비스
- Docker 이미지를 위한 접근 가능한 컨테이너 레지스트리 (Container Registry)
- CPU 및 메모리 요구사항을 정의하는 레지스트리에 저장된, Docker 이미지를 참조하는 Amazon ECS 작업 정의 (Task Definition)
- 대상 그룹(Target Group) 내에서 정상 동작 중인 대상으로 요청을 포워딩시켜주는 애플리케이션 로드 밸런서 (Application Load Balancer)
- 대상 그룹 (Target Group)
준비가 됐으면, GitLab CI/CD 파이프라인을 만들고 .gitlab-ci.yml
파일을 업데이트하기만 하면 됩니다.
아래는 Fargate 클러스터에 대한 작업을 정의하는 개발 환경용 샘플 스크립트입니다.
추가적인 참고자료:
Web Captioner의 개발팀이 GitLab과 AWS를 사용하여 어떻게 원클릭 Fargate 배포를 구현했는지 확인해 보세요.
GitLab + EKS
아마존 엘라스틱 쿠버네티스 서비스 (EKS, Elastic Kubernetes Service)는 쿠버네티스를 위한 완전 관리형 서비스(Fully Managed Service)입니다. EKS는 복잡한 환경을 추상화를 통해 간소화시켜주고, 쿠버네티스 클러스터를 더욱더 쉽게 생성하고 관리할 수 있다는 점에서 큰 호응을 얻었습니다. 또한, 보안에 대한 보다 세밀한 제어와 가능하며 리소스 사용에 대해 직관적인 정책 설정이 가능합니다.
GitLab은 반복적인 작업을 자동화하고 개발자가 비즈니스 로직에 집중할 수 있도록 함으로써 개발자 생산성을 높이려고 노력하고 있습니다. 최근 GitLab은 아마존 EKS에서 쿠버네티스 클러스터를 자동 생성할 수 있는 기능을 추가했습니다. 또한, GitLab은 아래의 사용 사례를 포함하여 다양한 요구에 부합하는 기능을 제공합니다.
- GitLab Runner를 사용한 뛰어난 확장성의 CI/CD 시스템: 때로는 운영 서버로의 배포가 거의 없는 한가한 날도 있습니다. 이럴 때도 리소스를 붙들고 있어야 할까요? 아마존 EKS와 GitLab을 통합하면 클릭 한 번으로 GitLab Runner를 설치할 수 있으며 리소스 부족에 대한 걱정 없이 CI/CD를 손쉽게 실행할 수 있습니다.
- 공유 클러스터: 여러 쿠버네티스 클러스터를 유지 관리하는데 어려움과 많이 비용이 들어갈 수 있습니다. 아마존 EKS를 사용하면 GitLab에서 인스턴스, 그룹 및 프로젝트 수준에서 클러스터를 설정할 수 있습니다. 쿠버네티스 네임스페이스는 아마존 EKS가 인스턴스와 프로젝트 레벨에서 통합되는 시점에 GitLab 프로젝트별로 생성되므로 격리 및 보안이 보장됩니다.
- 앱 검토: 코드 또는 설계의 변경사항을 검토하는 것은 까다로운 과정으로, 브랜치를 체크아웃 받고 테스트 환경에서 코드를 실행해야 합니다. 아마존 EKS와 통합된 GitLab에서는 새로운 변경사항이 적용된 앱을 동적인 환경에 배포하며, 간편하게 “View App” 버튼을 클릭하여 변경사항을 검토할 수 있습니다.
- [Auto DevOps](https://docs.gitlab.com/ee/topics/Auto DevOps/)는 아마존 EKS 통합을 활용하여 애플리케이션을 감지, 빌드, 테스트, 배포 및 모니터링합니다. 요번 장에서는 Auto DevOps를 사용하여 생성한 아마존 EKS 클러스터에 샘플 애플리케이션을 배포해 보겠습니다.
AWS에서 리소스에 접근하기 위한 설정 (최초 1회)
먼저 AWS에서 "provision”과 "service" 역할(role)을 생성하여 GitLab에 AWS 리소스에 대한 액세스 권한을 부여하고, EKS 클러스터 생성 및 관리에 필요한 권한을 설정해야 합니다. 이 단계는 한 번만 수행하면 되며 다른 통합작업이 필요하거나 더 많은 클러스터를 만들려는 경우 언제든지 재사용할 수 있습니다.
1단계 - 프로비저닝 역할 생성
GitLab이 AWS 리소스에 접근하려면 프로비저닝 역할(provision role)이 필요합니다.
- 그룹의 "Kubernetes" 메뉴를 선택하여 Gitlab의 쿠버네티스 통합(Kubernetes Integration) 페이지를 엽니다. 프로젝트의 Operations > Kubernetes 메뉴로 들어가 “Add Kubernetes Cluster” 버튼을 클릭합니다.
- "Create new cluster on EKS"탭 하단에 있는 옵션 중 “Amazon EKS”를 선택합니다.
- 인증에 사용할 Account ID와 External ID가 표시됩니다. 이후 단계에서 필요하니 이 값을 기록해 두십시오.
- 다른 탭에서 IAM 관리 콘솔(IAM Management Console)을 열고 “Create Role”을 클릭합니다.
- “Another AWS account” 탭을 클릭하고 GitLab에서 발급받은 Account ID와 External ID를 입력한 후 Next 버튼을 눌러 권한 설정 페이지로 넘어갑니다.
권한(permissions) 페이지에서 “Create policy.”를 클릭하여 JSON 형식으로 권한을 설정할 수 있는 새로운 탭을 엽니다.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“autoscaling:*”,
“cloudformation:*”,
“ec2:*”,
“eks:*”,
“iam:*”,
“ssm:*”
],
“Resource”: “*”
}
]
}
이를 통해 아래와 같이 GitLab에서 리소스를 만들고 관리할 수 있는 모든 권한을 부여하게 됩니다.
제한된 권한을 선호하는 경우, 아래 JSON 예제와 같이 GitLab에 리소스를 생성할 수 있지만, 삭제는 불가능하도록 설정할 수 있습니다. 하지만, 생성과정중에 오류가 발생하면 변경사항이 롤백되지 않고 리소스를 수동으로 제거해야 한다는 단점이 있습니다. 이는 관련 CloudFormation 스택을 삭제함으로써 가능합니다.
{
“Version”: “2012-10-17”, “
Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“autoscaling:CreateAutoScalingGroup”,
“autoscaling:DescribeAutoScalingGroups”,
“autoscaling:DescribeScalingActivities”,
“autoscaling:UpdateAutoScalingGroup”,
“autoscaling:CreateLaunchConfiguration”,
“autoscaling:DescribeLaunchConfigurations”,
“cloudformation:CreateStack”,
“cloudformation:DescribeStacks”,
“ec2:AuthorizeSecurityGroupEgress”,
“ec2:AuthorizeSecurityGroupIngress”,
“ec2:RevokeSecurityGroupEgress”,
“ec2:RevokeSecurityGroupIngress”,
“ec2:CreateSecurityGroup”,
“ec2:createTags”,
“ec2:DescribeImages”,
“ec2:DescribeKeyPairs”,
“ec2:DescribeRegions”,
“ec2:DescribeSecurityGroups”,
“ec2:DescribeSubnets”,
“ec2:DescribeVpcs”,
“eks:CreateCluster”,
“eks:DescribeCluster”,
“iam:AddRoleToInstanceProfile”,
“iam:AttachRolePolicy”,
“iam:CreateRole”,
“iam:CreateInstanceProfile”,
“iam:CreateServiceLinkedRole”,
“iam:GetRole”,
“iam:ListRoles”,
“iam:PassRole”,
“ssm:GetParameters”
],
“Resource”: “*”
}
]
}
- 아래는 어떤 권한이 부여됐는지를 보여줍니다.
- 정책이 생성되면 브라우저의 "Create Role" 탭으로 돌아가서 새로 고침을 눌러 새로 만든 정책이 표시되는지 확인합니다. 정책을 선택하고 "Next"를 클릭합니다.
- 특별히 필요한 경우를 제외하고는, 태그(Tag) 섹션에서 태그를 입력할 필요가 없습니다. 검토(Review) 단계로 넘어가겠습니다.
- 새로운 역할의 이름을 지정합니다. 생성된 정책은 목록 하단에 표시되며, “Create Role"을 클릭하여 완료합니다.
- 역할 목록 중 새로 생성한 역할을 클릭하여 세부사항을 확인합니다. 목록의 첫 화면에서 보이지 않는 경우 검색해야 할 수도 있습니다. 해당 역할의 ARN을 복사합니다 – 뒤에 나오는 GitLab 쿠버네티스 통합 페이지에서 사용됩니다.
2단계 - 서비스 역할 생성하기
서비스 역할(Service Role)은 아마존 EKS 및 쿠버네티스 컨트롤 플레인(Kubernetes Control Plane) 에서 사용자를 대신하여 AWS를 관리하는 데 필요합니다.
- IAM 관리 콘솔에서 "Create Role"을 클릭하고 "AWS service" 탭을 선택합니다.
- 서비스 목록에서 EKS를 선택하고 아래와 같이 유스 케이스를 선택 후 Next를 클릭합니다.
- "AmazonEKSClusterPolicy"와 "AmazonEKSServicePolicy" 권한이 선택되었음을 알 수 있습니다. Tags를 클릭하여 다음 단계로 넘어가 필요한 경우 태그를 생성한 후, Next를 클릭하여 검토 단계로 이동합니다. "Create Role"을 클릭하여 완료합니다.
GitLab EKS 통합
조직에서 사용할 AWS 설정에 프로비저닝 및 서비스 역할이 없는 경우 한 번만 생성하면 됩니다. 다른 통합작업이나 클러스터 생성 시 역할을 재사용할 수 있습니다.
- GitLab의 쿠버네티스 통합 페이지로 돌아와서, 앞서 생성한 프로비저닝 역할의 ARN을 입력하고 "Authenticate with AWS" 버튼을 클릭합니다.
- 인증이 되면, 아래와 같이 클러스터를 설정하는데 필요한 파라미터를 입력하고 "Create Kubernetes Cluster"를 클릭합니다. 이제, 나머지는 모두 GitLab이 알아서 해줍니다!
입력이 필요한 파라미터는 아래와 같습니다.
- Kubernetes cluster name - 원하는 클러스터 이름.
- Environment scope - 클러스터와 연관되는 GitLab의 환경. "*"는 해당 클러스터가 모든 환경으로의 배포에 사용됨을 나타냅니다.
- Kubernetes version - 사용할 쿠버네티스 버전. 현재, 1.14 버전만 지원됩니다.
- Role name - 앞서 생성했던 서비스 역할의 이름
- Region - 클러스터가 생성될 AWS 리전
- Key pair name - 작업자 노드 연결 시 사용할 키 페어(key pair) (필요한 경우에만)
- VPC - EKS 클러스터 리소스로 사용할 VPC
- Subnets - 작업자 노드가 실행될 VPC의 서브넷(subnets)
- Security group - EKS 관리형 엘라스틱 네트워크 인터페이스(Elastic Network Interfaces)에 적용할 작업자 노드 서브넷에서 생성된 보안 그룹. 본 가이드에서는 AWS 제공하는 기본 default 그룹을 사용하지만, 리소스에 필요한 올바른 규칙을 설정하기를 권장합니다.
- Instance type - 작업자 노드의 AWS 인스턴스 유형.
- Node count - 작업자 노드의 수.
- GitLab 관리형 클러스터: GitLab이 해당 클러스터에 대한 네임스페이스와 서비스 계정을 관리하길 원한다면 체크 상태로 유지합니다.
- 클러스터 생성 프로세스는 약 10분이 소요됩니다. 완료되면 사전 정의된 일부 응용프로그램 설치가 진행될 수 있습니다. 최소한, 다음을 항목을 설치해야 합니다.
- Helm Tiller: 다른 애플리케이션들을 설치하는 데 필요합니다.
- Ingress: SSL 터미네이션, 로드 밸런싱 및 이름 기반(name-based) 가상 호스팅 애플리케이션을 제공합니다. 애플리케이션의 웹 프록시 역할을 하며 Auto DevOps를 사용하거나 개발한 앱을 배포할 때 유용합니다.
- Cert Manager: 이 인증서는 Let's Encrypt를 사용하여 인증서를 발급하는데 필요한 기본 쿠버네티스 인증서 관리 컨트롤러입니다. 별도의 인증서 발급자를 사용하려는 경우 필요하지 않습니다.
- Prometheus: GitLab은 애플리케이션의 자동 모니터링을 위해 프로메테우스 (Prometheus)와의 통합을 제공하며, 이를 통해 쿠버네티스 컨테이너에서 메트릭을 수집하여 GitLab UI를 통해 확인할 수 있습니다.
- [Auto DevOps](https://docs.gitlab.com/ee/topics/Auto DevOps/quick_start_guide.html)의 자동 Review Apps 및 Auto Deploy를 사용하려면 Base Domain 이름과 함께, 사전 정의된 앱 목록에서 Ingress를 설치할 때 생성된 Ingress의 엔드포인트를 가리키는 와일드카드 DNS를 입력해야 합니다.
추가적인 참고자료:
GitLab + ECS
아마존 엘라스틱 컨테이너 서비스(ECS, Elastic Container Service)는 완전한 관리형 컨테이너 오케스트레이션 서비스입니다. ECS는 AWS Identity and Access Management (IAM) 및 아마존 CloudWatch와 같은 다른 많은 서비스와 통합됩니다. 또한, ECS는 아마존 EC2와 AWS Fargate를 혼합하거나 스팟 혹은 온디맨드의 요금을 적용할 수 있는 유연성을 제공합니다.
GitLab은 프로젝트에 포함할 수 있는 일련의 CI 템플릿을 제공합니다. ECS 클러스터에서 애플리케이션 배포를 자동화하기 위해 .gitlab-ci.yml
파일에 Deploy-ECS.gitlab-ci.yml
템플릿을 포함할 수 있습니다.
이 과정을 시작하기 전에 AWS ECS 상에 클러스터가 존재해야 하며, ECS 서비스, ECS 작업 정의, AWS RDS 상의 데이터베이스 등과 같은 관련 구성이 필요합니다.
AWS ECS에서 설정을 마친 후 다음 단계로 넘어갑니다.
- AWS 자격증명이 프로젝트의 환경 변수로 설정되어 있는지 확인해야 합니다. 다음 단계에 따라 설정을 완료할 수 있습니다.
- 프로젝트의
.gitlab-ci.yml
파일에 다음과 같은 변수를 추가합니다.
-
변수:
CI_AWS_ECS_CLUSTER:my-cluster
CI_AWS_ECS_SERVICE:my-service
CI_AWS_ECS_TASK_DEFINITION:my-task-definition
-
각 변수는 다음을 의미합니다:
CI_AWS_ECS_CLUSTER
: 배포 대상인 AWS ECS 클러스터의 이름.CI_AWS_ECS_SERVICE
: AWS ECS 클러스터에 연결된 대상 서비스의 이름.CI_AWS_ECS_TASK_DEFINITION
: 위의 서비스에 연결된 작업 정의의 이름.
AWS ECS 대시보드에서 대상 클러스터를 선택하면 이름을 확인할 수 있습니다.
3..gitlab-ci.yml
에 템플릿을 추가합니다.
include:
- template: Deploy-ECS.gitlab-ci.yml
- GitLab과 함께 제공되는 Deploy-ECS template은 GitLab.com에서 찾을 수 있습니다.
업데이트된 .gitlab-ci.yml
을 커밋하고 프로젝트 저장소에 푸시하면 완료됩니다!
애플리케이션 Docker 이미지가 다시 빌드되어 GitLab 레지스트리로 푸시됩니다. 해당 작업 정의의 Docker 이미지 위치가 업데이트되고, 그 결과로 ECS에 새로운 개정이 생성됩니다.
마지막으로, AWS ECS 서비스의 작업 정의가 새로운 버전으로 업데이트되며, 클러스터가 최신 버전의 애플리케이션을 가져옵니다(pull).
추가적인 참고자료:
- AWS Elastic Container Service (ECS)에 애플리케이션 배포하기
- ECS (Amazon Container Service)에 자동 배포하기 (이슈 번호 39089) · GitLab.org
- Gitlab 설정하기 / ECS 지속적인 배포 파이프라인
GitLab + EC2
아마존 엘라스틱 컴퓨트 클라우드(EC2, Elastic Compute Cloud)는 클라우드상에서 안전하고 확장이 가능한 컴퓨팅을 제공하는 웹 서비스입니다. 개발자에게 확장성을 가진 쉬운 웹 클라우드 컴퓨팅을 제공하도록 설계되었습니다.
AWS 콘솔에서 EC2와 GitLab을 연결하려면, 사용 가능한 템플릿 중에서 아마존 머신 이미지 (AMI, Amazon Machine Image)를 선택합니다.
사용 목적에 최적화된 인스턴스 유형을 선택합니다.
GitLab 인스턴스는 네트워크를 통해 Runner와 통신이 필요하며, 이는 AWS 보안 그룹을 구성할 때 또는 DNS 구성을 설정할 때 고려되어야 합니다.
개발자는 Terraform을 사용하여 AWS 인스턴스를 구동하여 더욱더 쉽게 EC2를 대상으로 지정 할 수 있습니다. 참고로, GitLab에는 Terraform 프로젝트를 AWS EC2에서 시작하기 위한 예제가 포함되어 있습니다.
GitLab은 EC2 스팟 인스턴스를 활용하는 데 유용한 툴입니다. Amazon EC2 스팟 인스턴스를 사용하면 여분의 아마존 EC2 컴퓨팅 리소스에 입찰할 수 있습니다. 스팟 인스턴스는 온 디맨드 요금보다 할인된 가격으로 제공되는 경우가 많으므로, 애플리케이션 실행 비용을 크게 줄임과 동시에 같은 예산으로 애플리케이션의 성능과 처리량을 늘리고 새로운 유형의 클라우드 컴퓨팅 애플리케이션을 시도해 볼 수 있습니다.
NHS (National Health Service)에 디지털 솔루션을 제공하는 기술 회사인 Substrakt Health는 오토스케일링(Autoscaling) GitLab Runner를 사용하여 EC2 비용을 90% 절감했습니다.