GitLab을 사용해서 AWS에 배포하기

Lambda, Fargate, EC2, EKS와 ECS를 위한 단일 애플리케이션

Jake

Full-Stack Engineer

2020년 12월 8일 · 약 44분

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”라는 메시지가 출력되는지 확인합니다.

추가적인 참고자료:

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).

추가적인 참고자료:

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% 절감했습니다.

블로그 읽어보기

추가적인 참고자료:

AWS의 추가적인 기능들

GitLab은 매달 22일에 새로운 기능을 발표합니다. 패치를 포함한 새 버전에 대한 소개는 블로그의 release 카테고리에 있습니다. Upcoming release 페이지에서는 향후 공개될 버전과 핵심 기능들에 대한 소개를 볼 수 있습니다. 구매 옵션에 따른 제품군별 추가 예정 기능도 확인할 수 있습니다.

GitLab 시작하기

DevOps 프로세스 변경은 쉽게 적용하기 힘든 조직의 과제일 수 있으며, 타당성을 평가하려면 개념 증명(POC, proof of concept)이 필수적으로 이루어져야 합니다. 모든 팀마다 역할과 우선순위가 다르므로 새로운 프로세스에 대한 올바른 평가가 필요합니다. 다행히도, GitLab을 사용한 AWS 배포를 고려하고 있는 팀들이 선택할 수 있는 몇 가지 선택지가 있습니다.

AWS Management Console에서 GitLab 설치하기

AWS Management Console 페이지에서 LAUNCH A VIRTUAL MACHINE 선택

다음으로, COMMUNITY AMIS를 클릭해서 GitLab 최신버전 (예: GitLab 12.8 혹은 GitLab 12.9) 선택 후 SELECT 클릭

CHOOSE AN INSTANCE TYPE 화면에서 인스턴스를 선택. T2.MEDIUM 혹은 그 이상을 추천합니다.

기존의 키 페어를 선택하거나 새로운 키 페어 생성 후 LAUNCH INSTANCES 선택

끝났습니다! 이제 브라우저에서 GitLab Community Edition 인스턴스에 접근할 수 있습니다. 화면에 표시되지 않으면 보안 그룹을 확인하십시오.

AWS 마켓플레이스에서 GitLab 설치하기

또 다른 방법은 AWS 마켓플레이스를 통해 설치하는 것입니다. GitLab을 검색 후, GITLAB ULTIMATE - 5 USER PACK을 선택합니다. 안내를 따르면 설치가 완료됩니다.

참고: GitLab Ultimate-5 User Pack은 AWS 마켓플레이스에서 무료 평가판이 아니지만 GitLab 라이센스를 받고 Ultimate 기능을 사용할 수 있습니다. 제한된 수의 사용자들이 GitLab의 전체 기능을 경험해보고자 할 경우 좋은 선택이 될 수 있습니다.

GitLab을 통해 AWS를 사용할 경우 얻게 될 장점

고객들은 모든 클라우드 컴퓨팅 및 IT의 요구를 한 곳에서 충족시킬 수 있기 때문에 AWS를 좋아합니다. 올인원 클라우드 플랫폼은 클라우드 프로세스 및 클라우드 사용량에 대한 가시성을 제공함으로써 효율성을 향상할 수 있습니다. DevOps 도구는 클라우드 활용에 큰 도움을 줄 수 있지만, 취약한 툴 체인과 비효율적인 DevOps 프로세스로 인해 개발이 교착상태에 빠지는 경우 리소스를 효과적으로 관리할 방법이 없습니다.

GitLab은 소프트웨어 개발 수명 주기의 모든 단계에서 더 높은 효율성을 제공함으로써 소프트웨어 개발을 가속합니다. 가시성이 향상되면 팀의 생산성이 향상되어, 단절된 팀 간에 불필요하게 결과물을 주고받을 일이 줄어들고 병목 현상이 제거됩니다. 개발, 보안 및 운영팀은 하나의 인터페이스에서 협업하고 모든 AWS 인프라에 배포할 수 있습니다.

올인원 클라우드와 올인원 DevOps의 만남

AWS에서 GitLab을 실행함으로써, AWS 클라우드 인프라에 배포할 수 있는 완전한 DevOps 플랫폼 환경을 갖추게 됩니다. GitLab과 AWS는 공통으로 개발 프로세스를 간소화하려는 조직에 아래와 같은 이점을 제공합니다.

더 나은 가시성: AWS를 사용하는 팀은 단일 플랫폼에서 여러 클라우드 서비스를 활용할 수 있으며 DevOps 팀은 GitLab을 사용하여 하나의 애플리케이션에서 서비스를 개발하고 준비하며 배포 할 수 있습니다.
향상된 효율성: 올인원 클라우드는 팀이 여러 클라우드 플랫폼을 관리할 필요가 없으며, GitLab의 단일 인터페이스를 통해 팀이 소프트웨어 개발 수명 주기의 모든 단계에서 협업할 수 있습니다.
개발 주기의 단축: 팀은 여러 클라우드, 프로세스 및 도구를 관리하는 대신 AWS와 GitLab을 활용하여 유지 관리보다는 소프트웨어 구축에 집중할 수 있습니다.

기업들이 디지털 혁신을 계속해서 이어나감에 따라, DevOps는 품질을 높이면서도 비즈니스에 빠른 가치 전달을 가능하게 하는 방법으로 자리 잡았습니다. 개발 수명 주기 내에서 조직 간 벽을 허물고 결과물을 주고받는 데 소모되는 노력을 줄이는 것이 매우 중요하지만, 아직은 대부분의 조직에 어려운 과제로 남아있습니다.

GitLab은 완전한 DevOps 플랫폼으로, 조직이 보유한 인프라를 지원하는 유연한 단일 애플리케이션입니다. GitLab은 AWS 상에서 단일 애플리케이션 형태로 AWS 클라우드 인프라에 실행과 배포를 지원하는 DevOps 플랫폼입니다.

30일 무료 체험 가입하기

About GitLab

GitLab은 제품, 개발, QA, 보안 및 운영팀이 같은 프로젝트에서 동시에 작업할 수 있도록 DevOps 라이프 사이클의 모든 단계를 위한 단일 애플리케이션으로 개발된 DevOps 플랫폼입니다.

GitLab은 DevOps 라이프 사이클에서, 팀에게 단일 데이터 저장소, 사용자 인터페이스 및 권한 모델을 제공합니다. 이를 통해, 팀이 같은 플랫폼에서 소통하고 작업하며 프로젝트 협업을 가능하게 함으로써, 개발 주기를 대폭 단축하고 우수한 품질의 소프트웨어를 신속하게 구축하는 데 전념할 수 있도록 도와줍니다.

오픈 소스를 기반으로 하는 GitLab은 수천 명의 개발자와 수백만 사용자의 커뮤니티 기여를 통해 새로운 DevOps 혁신을 지속해서 제공합니다. 티켓마스터, 재규어 랜드로버, NASDAQ, 디쉬 네트워크, 컴캐스트를 포함하여 신생 기업에서 글로벌 기업에 이르는 10만 개 이상의 조직이 빠른 속도로 뛰어난 소프트웨어를 제공하기 위해 GitLab에 의지하고 있습니다. GitLab은 세계 최대의 원격 기업으로 65개국 이상에 1,200명 이상의 팀원이 있습니다.

GitLab에서 AWS 사용하기​

GitLab + Lambda​

GitLab + SAM​

추가적인 참고자료:​

GitLab + Fargate​

추가적인 참고자료:​

GitLab + EKS​

AWS에서 리소스에 접근하기 위한 설정 (최초 1회)​

1단계 - 프로비저닝 역할 생성​

2단계 - 서비스 역할 생성하기​

GitLab EKS 통합​

추가적인 참고자료:​

GitLab + ECS​

추가적인 참고자료:​

GitLab + EC2​

추가적인 참고자료:​

AWS의 추가적인 기능들​

GitLab 시작하기​

AWS Management Console에서 GitLab 설치하기​

AWS 마켓플레이스에서 GitLab 설치하기​

GitLab을 통해 AWS를 사용할 경우 얻게 될 장점​

올인원 클라우드와 올인원 DevOps의 만남​

About GitLab​

GitLab에서 AWS 사용하기

GitLab + Lambda

GitLab + SAM

추가적인 참고자료:

GitLab + Fargate

추가적인 참고자료:

GitLab + EKS

AWS에서 리소스에 접근하기 위한 설정 (최초 1회)

1단계 - 프로비저닝 역할 생성

2단계 - 서비스 역할 생성하기

GitLab EKS 통합

추가적인 참고자료:

GitLab + ECS

추가적인 참고자료:

GitLab + EC2

추가적인 참고자료:

AWS의 추가적인 기능들

GitLab 시작하기

AWS Management Console에서 GitLab 설치하기

AWS 마켓플레이스에서 GitLab 설치하기

GitLab을 통해 AWS를 사용할 경우 얻게 될 장점

올인원 클라우드와 올인원 DevOps의 만남

About GitLab