티스토리 뷰

728x170

개요

이번 포스팅은 AWS Code Series 파이프라인 구성 과정에 대해 알아보도록 하자.

  • ① AWS EKS 환경에 MariaDB 구축
  • ② AWS Code Series 파이프라인 구축

AWS Code Series 파이프라인 구축

  • AWSCLI & AWS CodeCommit
  • Eclipse AWS Toolkit & AWS CodeCommit
  • 주요 Configuration File 확인
  • AWS CodeBuild
  • AWS CodePipeline

AWSCLI & AWS CodeCommit

먼저 AWS CodeCommit과의 통합을 위해 Windows 환경에 AWS Credential을 연결해야 한다. AWS Credential을 연결하는 방법은 Eclipse에서 직접 연결하는 방법과 Windows CLI에서 git cli를 사용하기 위해 aws configure를 이용하는 방법이 있다. 먼저 AWS Configure를 이용하여 Windows CLI에서 CodeCommit에 접근하는 과정을 살펴보자.

1) aws configure

▶ windows에서 aws command line interface를 사용하기 위해서는 아래와 같이 windows 용 installer를 설치해야 한다.

이와 함께 GRC(git-remote-codecommit)을 사용하기 위해 python과 git을 설치한다.

설치가 완료되면 다음과 같이 aws configre 명령어를 통해 aws credential을 연결한다.

C:\Users\user>aws configure
AWS Access Key ID [None]: AAAAAAAAAAAAA
AWS Secret Access Key [None]: BBBBBBBBBBBBBBBBBBBBBBBBB
Default region name [None]: ap-northeast-2
Default output format [None]: json

C:\Users\user>

2) GRC 설치

▶ git-remote-codecommit을 설치하기 위해 pip install git-remote-codecommit을 CLI 창에서 실행한다.

C:\Users\user>pip install git-remote-codecommit
Collecting git-remote-codecommit
  Downloading git-remote-codecommit-1.16.tar.gz (7.0 kB)
  Preparing metadata (setup.py) ... done
Collecting botocore>=1.17.0
  Downloading botocore-1.27.66-py3-none-any.whl (9.1 MB)
     ---------------------------------------- 9.1/9.1 MB 30.6 MB/s eta 0:00:00
Collecting python-dateutil<3.0.0,>=2.1
  Downloading python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
     ---------------------------------------- 247.7/247.7 kB ? eta 0:00:00
Collecting jmespath<2.0.0,>=0.7.1
  Downloading jmespath-1.0.1-py3-none-any.whl (20 kB)
Collecting urllib3<1.27,>=1.25.4
  Downloading urllib3-1.26.12-py2.py3-none-any.whl (140 kB)
     ---------------------------------------- 140.4/140.4 kB 8.7 MB/s eta 0:00:00
Collecting six>=1.5
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Using legacy 'setup.py install' for git-remote-codecommit, since package 'wheel' is not installed.
Installing collected packages: urllib3, six, jmespath, python-dateutil, botocore, git-remote-codecommit
  Running setup.py install for git-remote-codecommit ... done
Successfully installed botocore-1.27.66 git-remote-codecommit-1.16 jmespath-1.0.1 python-dateutil-2.8.2 six-1.16.0 urllib3-1.26.12

[notice] A new release of pip available: 22.2.1 -> 22.2.2
[notice] To update, run: python.exe -m pip install --upgrade pip

C:\Users\user>

3) Code Commit Repository 생성

▶ CodeCommit - Repository > 리포지토리 생성

Repository가 생성되면, URL 복제 - HTTPS(GRC) 복제를 선택하여 URL 정보를 복사한다.

4) git init & push

▶ git init - git remote add - git add - git commit - git push 순으로 동일하게 git repository를 사용한다.

D:\[NRSon] 개발관련\cospro_workspace\hikariTest\springboot-hikari-jdbc-mysql>git init
Initialized empty Git repository in D:/[NRSon] 개발관련/cospro_workspace/hikariTest/springboot-hikari-jdbc-mysql/.git/

D:\[NRSon] 개발관련\cospro_workspace\hikariTest\springboot-hikari-jdbc-mysql>git remote add origin codecommit::ap-northeast-2://nrson-repository

D:\[NRSon] 개발관련\cospro_workspace\hikariTest\springboot-hikari-jdbc-mysql>git add .

D:\[NRSon] 개발관련\cospro_workspace\hikariTest\springboot-hikari-jdbc-mysql>git commit -m "first commit"
[master (root-commit) a60f3e5] first commit
 20 files changed, 2627 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 LICENSE
 create mode 100644 ReadMe.md
 create mode 100644 bin/pom.xml
 create mode 100644 pom.xml
 ...
 create mode 100644 src/main/resources/application.properties

D:\[NRSon] 개발관련\cospro_workspace\hikariTest\springboot-hikari-jdbc-mysql>git push origin master
Enumerating objects: 35, done.
Counting objects: 100% (35/35), done.
Delta compression using up to 12 threads
Compressing objects: 100% (27/27), done.
Writing objects: 100% (35/35), 22.77 KiB | 1.75 MiB/s, done.
Total 35 (delta 2), reused 0 (delta 0), pack-reused 0
To codecommit::ap-northeast-2://nrson-repository
 * [new branch]      master -> master

D:\[NRSon] 개발관련\cospro_workspace\hikariTest\springboot-hikari-jdbc-mysql>

앞서 복사한 GRC URL을 이용하여 push를 진행한다.

5) repository 확인

위와 같이 nrson-repository에 push된 것을 확인할 수 있다.


Eclipse AWS Toolkit & AWS CodeCommit

이번에는 Eclipse AWS Toolkit을 이용하여 AWS CodeCommit에 접근해 보자.

1) AWS Toolkit Install

▶ Eclipse - Help - Install New Software - Work With 입력 (http://aws.amazon.com/eclipse)

  • AWS Core Management Tools - AWS Toolkit for Eclipse Core (Required)
  • AWS Developer Tools - AWS CodeCommit Plugin

위 두개 패키지 선택 후 Next - 동의 - Finash - Restart Now 순으로 Install을 진행한다.

2) AWS Explorer

▶ 재기동 후 AWS Credential을 입력하면 다음과 같이 AWS Explorer를 통해 AWS Resource에 접근할 수 있다.

Eclipse의 [Window] > [Show View] > [Other] > [AWS Toolkit] > [AWS Explorer]

3) AWS CodeCommit Repository Clone & Commit

▶ git clone repostiroy

▶ import project

▶ commit datasource url 변경 후 commit & push

▶ CodeCommit 변경 반영 확인

CodeCommit에 변경된 datasource url이 반영된 것을 알 수 있다.


주요 Configuration File 확인

다음으로 AWS CodeBuild를 수행하기 이전 Application Package에 포함해야 할 Configuration File에 대해 알아보자. 일반적으로 yaml 파일 형태로 구성한다.

[Eclipse Project]

  • buildspec.yml
  • deployment.yaml
  • service.yaml
  • Dockerfile
  • pom.xml
  • application.properties

▶ buildspec.yml

version: 0.2
phases:
  install:
    runtime-versions:
      docker: 18
    commands:
      - echo Install Kubectl
      - echo ---------------------------------
      - curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/amd64/kubectl
      - chmod +x ./kubectl
      - mv ./kubectl /usr/local/bin/kubectl
      - mkdir ~/.kube
      - aws sts get-caller-identity
      - aws eks --region ap-northeast-2 update-kubeconfig --name NRSON-EKS-CLUSTER
      - kubectl get po -n kube-system
      - echo ---------------------------------
  pre_build:
    commands:
      - echo ENV Values
      - echo ---------------------------------
      - echo $AWS_DEFAULT_REGION
      - echo $IMAGE_REPO_NAME
      - echo $IMAGE_TAG
      - echo $AWS_ACCOUNT_ID
      - echo ---------------------------------
      - echo Logging in to Amazon ECR...
      - docker login -u AWS -p $(aws ecr get-login-password --region ap-northeast-2) <AWS_ACCOUNT_ID>.dkr.ecr.ap-northeast-2.amazonaws.com
  build:
    commands:
      - echo Build Docker Image
      - echo ---------------------------------
      - echo Build Starting on `date`
      - echo Building with maven...
      - mvn install
      - echo Building the Docker image...
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
      - echo ---------------------------------
  post_build:
    commands:
      - echo Deploy Application
      - echo ---------------------------------
      - AWS_ECR_URI=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
      - DATE=`date`
      - echo Build completed on $DATE
      - sed -i.bak 's#AWS_ECR_URI#'"$AWS_ECR_URI"'#' ./k8s/deployment.yaml
      - sed -i.bak 's#DATE_STRING#'"$DATE"'#' ./k8s/deployment.yaml
      - cat ./k8s/deployment.yaml
      - export KUBECONFIG=$KUBECONFIG:~/.kube/config
      - kubectl apply -f ./k8s/deployment.yaml
      - kubectl apply -f ./k8s/service.yaml
      - echo ---------------------------------

buildspec은 Phase 별로 나뉘어 진행된다.

  • ① install : kubectl download, kubeconfig update
  • ② pre_build : env setting, docker login
  • ③ build : maven install, docker image build, docker image tagging, docker image push
  • ④ post_build : kubernetes deploy (deployment, service)

▶ deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hikari-test-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hikari-test
  template:
    metadata:
      labels:
        app: hikari-test
    spec:
      containers:
        - name: hikari-test
          image: AWS_ECR_URI
          ports:
            - containerPort: 8080
          imagePullPolicy: Always
          env:
            - name: DATE
              value: 'DATE_STRING'

▶ service.yaml

apiVersion: v1
kind: Service
metadata:
  name: hikari-test-service
spec:
  ports:
    - name: "8080"
      port: 8081
      targetPort: 8080
  selector:
    app: hikari-test
  type: LoadBalancer
#  type: ClusterIP

▶ Dockerfile

FROM openjdk:11.0-jdk
VOLUME /tmp
ADD ./target/springboot-hikari-jdbc-mysql.jar app.jar
ENV JAVA_OPTS=""
ENTRYPOINT ["java","-jar","/app.jar"]

deploymnet.yaml, service.yaml, Dockerfile은 kubernetes에 배포하는 일반적인 yaml 파일과 동일하다.

▶ pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>2.5.3</version>
	</parent>

	<groupId>com.mysql.springboot</groupId>
	<artifactId>springboot-hikari-jdbc-mysql</artifactId>
	<packaging>jar</packaging>
	<version>1.0</version>
	<name>springboot-hikari-jdbc-mysql</name>
	<url>http://maven.apache.org</url>

	<developers>
		<developer>
			<name>Metanoia</name>
		</developer>
	</developers>

	<dependencies>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-jdbc</artifactId>
			<exclusions>
				<exclusion>
					<groupId>org.apache.tomcat</groupId>
					<artifactId>tomcat-jdbc</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
		<dependency>
			<groupId>org.mariadb.jdbc</groupId>
			<artifactId>mariadb-java-client</artifactId>
		</dependency>
	</dependencies>

	<build>
		<finalName>springboot-hikari-jdbc-mysql</finalName>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<configuration>
					<source>11</source>
					<target>11</target>
				</configuration>
			</plugin>
		</plugins>
	</build>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>com.zaxxer</groupId>
				<artifactId>HikariCP</artifactId>
				<version>5.0.0</version>
			</dependency>
		</dependencies>
	</dependencyManagement>
</project>

pom.xml은 spring-boot-starter와 mariadb-java-client를 포함하여 빌드하며, finalName으로 jar 파일 이름을 결정할 수 있다.

▶ application.properties

# DATASOURCE (DataSourceAutoConfiguration & DataSourceProperties)
#spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.driverClassName=org.mariadb.jdbc.Driver
#spring.datasource.url=jdbc:mysql://<MARIADBIP>:<MARIADBPORT>/institute?useSSL=false
spring.datasource.url=jdbc:mysql://mariadb/institute?useSSL=false
spring.datasource.username=root
spring.datasource.password=DB_PASSWORD
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect

# HikariCP DataSource Properties
spring.datasource.hikari.connectionTimeout=30000
spring.datasource.hikari.minimumIdle=10
spring.datasource.hikari.maximumPoolSize=10 
spring.datasource.hikari.idleTimeout=100000 
spring.datasource.hikari.maxIdleTime=100000
spring.datasource.hikari.maxLifetime=110000
spring.datasource.hikari.poolName=HikariCP
#spring.datasource.hikari.connection-init-sql=set wait_timeout=105

#Spring Boot 2.0 includes HikariDataSource by default
## spring.datasource.type=com.zaxxer.hikari.HikariDataSource

# LOGGING
logging.level.root=ERROR
logging.level.com.mysql.springboot=INFO
logging.pattern.console=%-5level %logger{36} - %msg%n

application.properties는 hikari 관련 timeout과 DB 연결정보, 로깅정보를 포함하고 있다.


AWS CodeBuild

AWS CodeBuild를 통해 CodeCommit에 Push 된 Application과 yaml 파일 등을 기반으로 AWS EKS에 배포할 수 있다. 이때 AWS CodeDeploy는 AWS EKS를 지원하지 않아 AWS CodeBuild로 배포해야 함에 유의한다.

1) ECR Repository 생성

Container(Docker Image) Image를 저장할 Elastic Container Registry 생성

  • 리포지토리 이름 : nrson-image-repository

2) 프로젝트 만들기

3) 빌드 프로젝트 생성

▶ 프로젝트 구성

  • 프로젝트 이름 : 이름 입력 (ex - NRSON-CODEBUILDER-HIKARI)
  • 설명 : Description (ex - NRSON-CODEBUILDER-HIKARI)
  • 동시 빌드 제한 활성화 :  동시에 빌드 가능한 수를 입력 (ex - 1)

▶ 소스

  • 소스 공급자 : Amazon S3, AWS CodeCommit, GitHub, BitBucket, GitHub Enterprise 등을 지원하며, Repository를 선택 (ex - AWS CodeCommit)
  • 리포지토리 : 해당 소스 공급자에 등록되어 있는 Repository를 선택 (ex - nrson-repository)
  • 참조 유형 : 브랜치, Git Tag, Commit ID 중 배포 단위 선택 (ex - 브랜치)
  • 브랜치 : 선택한 Repository 중 Branch를 선택 (ex - master)
  • 커밋ID : Commit ID를 선택할 경우 보다 빠르게 배포가 가능하지만, 매번 새로운 버전을 배포하기 위해 변경이 필요함 (ex - commitID)
  • 소스 버전 : 최종 반영될 소스 버전 확인

▶ 환경

  • 환경이미지 : 관리형 이미지 또는 직접 생성한 사용자 지정 이미지 선택 (ex - 관리형 이미지)
  • 운영체제 : Amazon Linux 2 또는 Ubuntu 선택 (ex - Amazon Linux 2)
  • 런타임 (ex - Standard)
  • 이미지 (ex - aws/codebuild/amazonlinux2-x86_64-standard:2.0)
  • 이미지 버전 (ex - 이 런타임 버전에 항상 최신 이미지 사용)
  • 환경 유형 : Linux 또는 Windows 선택 (ex - Linux)
  • 권한이 있음 : Container 환경에 도커 이미지를 생성해야 하는 경우 활성화 (ex - 체크)
  • 서비스 역할 : 역할을 생성할 경우 새 서비스 역할, 기존 서비스를 사용할 경우 기존 서비스 역할 선택

▶ 역할이 포함해야 할 정책 리스트

  • AWSCodeCommitFullAccess
  • AmazonEKSClusterPolicy
  • AmazonEKSWorkerNodePolicy
  • AdministratorAccess
  • AmazonEKSServicePolicy
  • AWSCodePipelineFullAccess
  • AmazonEKS_CNI_Policy
  • AmazonEKSFargatePodExecutionRolePolicy
  • AmazonEKSVPCResourceController

▶ 역할을 configmap에 추가

a. 추가

    - rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/codebuild-EKS-DEPLOY-service-role
      username: codebuild-EKS-DEPLOY-service-role
      groups:
        - system:masters

b. 완성된 형태

[root@ip-10-192-10-183 EKS]# kubectl edit configmap aws-auth -n kube-system
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/EKS-WORKERNODE-ROLE
      username: system:node:{{EC2PrivateDNSName}}
    - rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/codebuild-EKS-DEPLOY-service-role
      username: codebuild-EKS-DEPLOY-service-role
      groups:
        - system:masters
kind: ConfigMap
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"mapRoles":"- groups:\n  - system:bootstrappers\n  - system:nodes\n  rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/EKS-WORKERNODE-ROLE\n  username: system:node:{{EC2PrivateDNSName}}\n- rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/service-role/codebuild-hikari-service-service-role\n  username: codebuild-hikari-service-service-role\n  groups:\n    - system:masters\n"},"kind":"ConfigMap","metadata":{"annotations":{},"creationTimestamp":"2022-09-02T04:44:12Z","managedFields":[{"apiVersion":"v1","fieldsType":"FieldsV1","fieldsV1":{"f:data":{".":{},"f:mapRoles":{}}},"manager":"vpcLambda","operation":"Update","time":"2022-09-02T04:44:12Z"}],"name":"aws-auth","namespace":"kube-system","resourceVersion":"1740","uid":"cb95d265-05e3-4c37-880c-97fb57b3664c"}}
  creationTimestamp: "2022-09-09T21:34:16Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:data:
        .: {}
        f:mapRoles: {}
      f:metadata:
        f:annotations:
          .: {}
          f:kubectl.kubernetes.io/last-applied-configuration: {}
    manager: kubectl
    operation: Update
    time: "2022-09-09T21:34:16Z"
  name: aws-auth
  namespace: kube-system
  resourceVersion: "3482"
  uid: cc0ee350-2a4c-4d0d-ac9b-df8dafb3dee0
  [root@ip-10-192-10-183 EKS]#

  • 역할 이름 : 새로 생성할 역할 이름 (ex - codebuild-NRSON-CODEBUILDER-HIKARI-service-role)
  • 제한시간 :  빌드 소요 시간에 대한 제한 (ex - default 빌드 1시간, 대기 8시간 제한)
  • 인증서 : 필요서 S3 버킷에서 인증서 설치 (ex - 인증서 설치 안함)

  • VPC : AWS CodeBuild가 엑세스 할 (EKS가 구축된) VPC 선택 (ex - vpc-xxxxxxxxxx)
  • 서브넷 : AWS CodeBuild가 VPC를 구성하는데 사용해야 하는 Private Subnet을 선택. 여러개의 AZ에 걸쳐 있는 서브넷을 선택하는 것이 가용성에 유리하며, 서브넷에는 NAT 게이트웨이가 포함되어 있어야 함 (ex - subnet-aaaaaaaaaa, subnet-bbbbbbbbbb)
  • 보안 그룹 : AWS CodeBuild가 VPC를 구성하는데 사용해야 하는 보안 그룹을 선택 (ex - sg-ccccccccccc)

  • 컴퓨팅 : CodeBuild를 수행할 EC2 인스턴스의 타입을 선택
  • 환경변수 : AWS_DEFAULT_REGION (ap-northeast-2), IMAGE_REPO_NAME (1번에서 생성한 ECR Repository Name), IMAGE_TAG (Image Version), AWS_ACCOUNT_ID (Account Id)

▶ Buildspec

  • Buildspec : 빌드 사양을 정의하는 buildspec 파일을 사용하는 방법과 빌드 명령을 삽입하는 방법. 대체로 Project 내에 포함하여 buildspec.yml 파일 형태로 반영

4) 프로젝트 빌드

▶ CodeBuild 프로젝트 빌드 메인 화면

생성한 CodeBuild의 주요 항목을 살펴보자면 다음과 같다.

  • 빌드 시작 : 정의한 CodeCommit & buildspec에 따라 처리
  • 빌드 기록 : 빌드 Num 별로 빌드 수행 결과 메시지 확인 (성공, 실패 확인 및 세부 빌드 차수 별 상세 화면 이동)

▶ 빌드 시작 버튼 클릭 시 전환되는 화면

빌드 시작 버튼을 클릭하면 아래와 같은 화면으로 전환된다.

  • 빌드 로그 : buildspec.yml의 처리 과정이 로그로 나타나며, 전체 로그 보기는 CloudWatch, 테일 로그는 CodeBuild 내에서 로그의 변화를 모니터링할 수 있다.
  • 단계 세부 정보 : 각 단계 별 상태 (성공/실패)를 확인할 수 있으며, 수행 시간을 확인할 수 있다.
  • 환경 변수 : 앞서 생성한 환경 변수 정보를 확인할 수 있다.

▶ 빌드 모니터링

빌드 모니터링은 크게 두 화면에서 진행할 수 있다.

  • 빌드 로그 : 해당 화면에서는 빌드 시 로그를 확인할 수 있다. 다만, 로그가 많이 발생되는 경우 테일 로그를 클릭하여 모니터링하는 것이 편리하다.
  • 빌드 세부 정보 : 빌드 세부 정보에서는 각 Stage 별로 성공/실패, 실패 시 원인 등을 확인할 수 있다.

▶ Kubernetes 배포 확인

[root@ip-10-192-10-183 CODESERIES]# kubectl get service
NAME                  TYPE           CLUSTER-IP       EXTERNAL-IP                                                                    PORT(S)          AGE
hikari-test-service   LoadBalancer   172.20.131.243   <ALB_DNS>									    8081:32319/TCP   115s
kubernetes            ClusterIP      172.20.0.1       <none>                                                                          443/TCP          15h
mariadb               NodePort       172.20.41.53     <none>                                                                         3306:30306/TCP   14h
[root@ip-10-192-10-183 CODESERIES]# kubectl get pods
NAME                                      READY   STATUS    RESTARTS       AGE
hikari-test-deployment-56855ccff7-cq847   1/1     Running   1 (112s ago)   118s
mariadb-65b58c446c-qhqd5                  1/1     Running   0              14h
[root@ip-10-192-10-183 CODESERIES]#

위와 같이 hikari-test-service와 hikari-test-deployment pod가 기동된 것을 확인할 수 있다.


AWS CodePipeline

AWS CodePipeline은 여러 Build/Deploy Task를 하나로 통합하여 실행해 주는 서비스이다. 쉽게 Jenkins Pipeline Job과 동일하다고 생각하면 된다.

1) CodePipeline 생성

CodePipeline에 파이프라인 생성을 선택한다.

2) 파이프라인 설정 선택

  • 파이프라인 이름 : 이름 입력 (ex - hikari-test-pipeline)
  • 서비스 역할 : 새 서비스 역할을 생성하거나, 기존 서비스 역할을 사용 (ex - default)

3) 소스 스테이지 추가

  • 소스 공급자 : Amazon S3, AWS CodeCommit, GitHub, BitBucket, GitHub Enterprise 등을 지원하며, Repository를 선택 (ex - AWS CodeCommit)
  • 리포지토리 이름 : 해당 소스 공급자에 등록되어 있는 Repository를 선택 (ex - nrson-repository)
  • 브랜치 이름 : 선택한 Repository 중 Branch를 선택 (ex - master)
  • 변경 감지 옵션 : 소스 코드에서 변경이 감지되면 파이프라인을 자동으로 시작하도록 하는 감지 모드로 Amazon Cloud Watch와 AWS CodePipeline에서 정기적으로 감지하는 방법 선택 (ex - Amazon Cloud Watch)
  • 출력 아티팩트 형식 : CodePipeline 기본값, 전체 복제 방식 선택. .git 등을 제외하고 배포하기 위해 CodePipeline 기본값 선택 (ex - CodePipeline 기본값)

4) 빌드 스테이지 추가

  • 빌드 공급자 : 빌드 공급자로 AWS CodeBuild 뿐만 아니라, Jenkins를 추가할 수 있다. (ex - AWS CodeBuild)
  • 리전 (ex - 아시아 태평양 (서울))
  • 프로젝트 이름 : AWS CodeBuild 프로젝트 이름 (ex - NRSON-CODEBUILDER-HIKARI)
  • 빌드 유형 : 단일 빌드 또는 배치 빌드 선택 (ex - 단일 빌드)

5) 배포 스테이지 추가

앞서 이야기한 바와 같이 AWS CodeDeploy는 AWS EKS를 지원하지 않아 배포 스테이지는 건너뛰기 한다.

6) 파이프라인 실행

파이프라인 생성이 완료되면, 자동으로 파이프라인이 동작된다. 이때 위와 같이 Stage가 Source, Build로 구분되며, 두 단계가 하나의 파이프라인 안에서 동작한다.

7) Kubernetes 배포 확인

[root@ip-10-192-10-183 CODESERIES]# kubectl get pods
NAME                                      READY   STATUS    RESTARTS        AGE
hikari-test-deployment-577475764f-t5mqz   1/1     Running   1 (2m20s ago)   2m26s
mariadb-65b58c446c-qhqd5                  1/1     Running   0               25h
[root@ip-10-192-10-183 CODESERIES]# kubectl get service
NAME                  TYPE           CLUSTER-IP       EXTERNAL-IP                                                                    PORT(S)          AGE
hikari-test-service   LoadBalancer   172.20.131.243   <ALB_DNS>   8081:32319/TCP   11h
kubernetes            ClusterIP      172.20.0.1       <none>                                                                         443/TCP          27h
mariadb               NodePort       172.20.41.53     <none>                                                                         3306:30306/TCP   25h
[root@ip-10-192-10-183 CODESERIES]#

위와 같이 Kubernetes Service와 Pod가 배포된 것을 확인할 수 있다. 특히 파이프라인의 변경 감지 옵션에 따라 소스코드가 AWS CodeCommit에 배포되면 자동으로 파이프라인이 동작하게 된다.


결론

지금까지 AWS Code Series 중 CodeCommit, CodeBuild, CodePipeline을 활용하여 AWS EKS 환경에 배포를 진행해 보았다. CodeCommit의 경우 GitHub와 같은 소스 리포지토리로써 AWS Resource와 통합 관리에 용이하다는 장점이 있다. CodeBuild는 Image를 생성하기 위한 Base(OS, JDK 등)를 제공하지만, 경량 이미지 등은 부족한 편이다. CodePipeline은 배포의 이점보다는 WebHook 연동 등을 통해 자동 배포 체계를 구축할 수 있다는 장점이 있다.

다만 이와 같은 CodeSeries를 사용하지 않고 오픈소스로 충분히 구현이 가능하며, 비용 역시 절감할 수 있다는 측면, 외부 요소와의 연계가 어렵다는 측면 등을 고려할 때 크게 메리트가 있는 구성이라 보기는 어려울 듯 하다.

그리드형
댓글
댓글쓰기 폼