[microservice-upLearning] Ⅵ. 인프라 파이프라인 구축

2021-10-22

MSA

Ⅵ. 인프라 파이프라인 구축

MSA는 일이 많고 복잡

작업 줄이려면? 환경 프로비저닝, 쉽게 배포 도구 필요
IaC, CI, CD등 데브옵스 관행 : 인프라 빠르고 안전히 변경, 마이크로서비스 쉽게 확장 가능

데브옵스 & 마이크로서비스

데브옵스 목표 : 소프웨어 개발, 릴리즈 , 지원 방식을 개선하는 것
이를 위해선? 관련된 조직 설계, 문화, 프로세스, 도구 개선 필요
MSA는 데브옵스 유사 목표 + 제한된 서비스, 독립적배포및 관리 목표
데브 옵스 방식 없이 MSA 구축은 매우 어려운 일이다

6.1 데브옵스 원칙과 관행

데브옵스 방식의 sw 구축 : 안전성을 유지한 빠른 어플리케이션 변경 ▶ 인프라 도구를 통해 얻고자 하는 것

데브옵스 세계의 3가지 개념 도입

변경 불가능한 인프라(Immutable infrastructure)
IaC
CI/CD

6.1.1 변경 불가능한 인프라(Immutable infrastructure)

객체 지향의 불변형 속성

불변형 객체 : 생성한 후 변경 불가
불변형 객체 업데이트 가능한 유일한 방법? 기존 객체 제거 새로운 객체를 만든 것
변경이 불가능 → 예측하고 재현이 쉬움 → 테스트 및 복제와 같은 작업을 더 쉽게 가능

변경 불가능한 인프라 : 이러한 불변 속성을 인프라 구성요소에 적용
ex) 라우팅 설정된 LB → 불변성 원칙 적용 → LB 제거하고 새로 만들지 않는 한 라우팅 설정 변경 불가능

불변성 적용시 주요 장점

전통적 시스템 : 운영자는 많은 작업을 수동으로 실행
- 시스템 패치하고 구성을 변경하며 프로세스를 시작/중지
- 어플리케이션 실행 가능한 환경 유지 노력 → 서버와 장치를 지속적 관리
- 여러 환경과 여러 서버 → 작업범위 높아짐
- 변경시에도 많은 변경 사항이 적용됨 → 일관성이 깨질 확율 증가
- 가변성 예측 불가능성 → 새서버 도입, 환경 변경 어려움 → 더 많은 전문성과 수작업 필요
- 인프라 제공 늦어짐, 운영 모델의 인프라를 셀프 서비스도구로 제공이 어려움
불변성 적용 : 예측가능하고 복제가 쉬운 인프라 생성 가능

변경 불가능한 인프라 원칙 적용

인프라 구성 요소는 생성후 변경하지 않는다
구성요소는 반드시 새로운 속성이나 변경된 속성을 가진 새로운 구성요소를 다시 만들어 변경해야 한다

trade off

원칙 적용시 비용 발생 : 구성을 제거하고 다시 만드는 비용
이 과정을 더 쉽고 작은 비용으로 하기 위한 중요한 결정이 필요
중요 결정 : 클라우드에 인프라 구현
- 클라우드가 아니면 물리적 하드웨어 구입, 서버 관리, sw 비용으로 복잡성, 비용 추가
- 클라우드 인프라 구성요소는 가상화 → sw처럼 다룰수 있음

불변형 인프라

서버 일관성 유지, 운영과 유사한 새로운 환경 복제/인스턴스화 하는 기능 제공
관리가능한 구성집합을 사용해서 모든 인프라를 정의할 수 있는 방법이 필요함

6.1.2 IaC

IaC

모든 인프라 변화는 관리된 코드 파일에서 수행되어야 한다
코드 외부에서 운영자가 수동 변경하면 안된다
인프라 코드 관리가 곧 인프라 상태 관리
궁극적으로 인프라 코드를 작성, 테스트, 배포하는 방식을 관리하는 것

테라폼

인프라를 자동화와 반복 가능한 방식으로 관리 가능
변경 불가능한 인프라 원칙 수용
코드 적용 → 기존 것 제거, 새로운 형태 다시 생성 → 이를 위해 테라폼은 인프라의 state 추적 필요
테라폼을 잘 관리 해야한다
- 테라폼 전체의 상태, 구성파일, 품질, 안전, 유지 보수성을 관리해야한다 → sw관리와 유사

6.1.3 CI/CD

불변성, IaC → 인프라 변화 좀더 예측 가능하게 만듬 → 항상 안전하지 않음

예시
- 네트워크 작은 변경 → 운영 환경의 LB가 중단될 수 있음
- 실수로 개발환경을 타겟으로한 변경 작업을 운영으로 전달 → 서비스 중단 될 수 있음
위험 방지 필요
- 모든 변경 사항에 대해 적용전에 여러 번 확인 하는 것
  - 수행하는 모든 작업에 검증 과정이 추가됨
  - 변경 속도가 매우 느려짐
  - 인프라 설계, 개발 초기 발견 가능한 문제를 검증 과정이 되서야 발견 가능
  - 결과적으로 인프라 계획이 크게 변경될 수 있는 대량 테스트단계에서 많은 비용 소모

더 효율적인 방식 : CI/CD

데브옵스 소프트웨어 관행 : 지속적 통합, 지속적 전달
CI/CD 관행은 도구 크게 의존
파이프라인 사용 : CI/CD 프로세스 각 단계 정의하고 관리 가능
해당 서적에서는 깃허브 액션 사용

6.2 IaC 환경 설정

테라폼 설치

테라폼사이트 가서 다운로드 해서 설치
개인적으로는 패키지 관리자로 설치하는 것을 추천

6.3 AWS 웹서비스 구성

6.3.1 AWS 운영 계정 설정

새 계정 생성

IAM에서 생성
권한 IAM Full Access
유저 이름 : ops-account
Access Key : AKIA4MJV6IIZD3ZK4HMQ
Secret Access Key : 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

6.3.2 AWS CLI 구성

위 계정을 콘솔에서 생성했으니 AWS API를 통해 구성을 변경하기 위해 테라폼을 사용한다
AWS CLI를 사용하면 변경 사항을 더 쉽게 설명할 수 있고 UI 변경 빈도가 낮은 장점

역시 패키지 관리자로 설치하는 것을 추천

aws cli 설정

PS C:\Users\user> aws configure
AWS Access Key ID [None]: AKIA4MJV6IIZD3ZK4HMQ
AWS Secret Access Key [None]: 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
Default region name [None]: ap-northeast-2
Default output format [None]: json
PS C:\Users\user>

cli 올바르게 구성했는지 계정 조회

$ aws iam list-users
{
    "Users": [
        {
            "Path": "/",
            "UserName": "ops-account",
            "UserId": "AIDA4MJV6IIZMO2JYYQWE",
            "Arn": "arn:aws:iam::851053527602:user/ops-account",
            "CreateDate": "2021-10-18T09:22:07+00:00"
        }
    ]
}

6.3.3 AWS 권한 설정

기존 opt-account 사용자 권한 : IAMFullAccess
운영 계정에는 인프라 구축에 필요한 aws 리소스 관리위해 훨씬 더 많은 권한 필요
기존 계정 opt-account를 Opt-Accounts라는 새 그룹에 사용자로 추가
→ 그룹이 소유한 권한을 새로운 사용자에게 동일하게 할당 가능

aws 자동완성(개인 추가)

참고 : https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-configure-completion.html#cli-command-completion-windows
프로필 권한 때문에 실행 안될 경우
- 관리자 권한으로 Set-ExecutionPolicy -ExecutionPolicy Unrestricted

새그룹 생성

그룹 생성 성공하면 다음처럼 생성 그룹 정보 표시

$ aws iam create-group --group-name Ops-Accounts
{
    "Group": {
        "Path": "/",
        "GroupName": "Ops-Accounts",
        "GroupId": "AGPA4MJV6IIZPE7XKKNE3",
        "Arn": "arn:aws:iam::851053527602:group/Ops-Accounts",
        "CreateDate": "2021-10-19T05:00:40+00:00"
    }
}

$

사용자를 새 그룹에 추가

1 2	$ aws iam add-user-to-group --user-name ops-account --group-name Ops-Accounts $ # 올바르게 작동하면 CLI에서 특별한 응답을 받지 않음

권한 연결

새그룹에 필요한 권한의 모음을 연결
그룹에 속한 사용자 계정에 자동으로 적용
실무에선 인프라 설계 프로세스 진행하면서 운영자 계정 권한 변경할 가능성이 큼
예제에선 이전에 설계 작업 완료했으므로 필요 정책을 미리 정확하게 알고 정의

AWS 기본 정책 연결

$ aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/IAMFullAccess && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonEKSServicePolicy && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonVPCFullAccess && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonRoute53FullAccess && \
aws iam attach-group-policy --group-name Ops-Accounts \
--policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess

$ aws iam list-attached-group-policies --group-name Ops-Accounts
{
    "AttachedPolicies": [
        {
            "PolicyName": "AmazonEC2FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"
        },
        {
            "PolicyName": "IAMFullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/IAMFullAccess"
        },
        {
            "PolicyName": "AmazonEKSClusterPolicy",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
        },
        {
            "PolicyName": "AmazonEC2ContainerRegistryFullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess"
        },
        {
            "PolicyName": "AmazonS3FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonS3FullAccess"
        },
        {
            "PolicyName": "AmazonVPCFullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonVPCFullAccess"
        },
        {
            "PolicyName": "AmazonEKSServicePolicy",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSServicePolicy"
        },
        {
            "PolicyName": "AmazonRoute53FullAccess",
            "PolicyArn": "arn:aws:iam::aws:policy/AmazonRoute53FullAccess"
        }
    ]
}
$

list-group-policies는 인라인 정책만 나온다
attach-group-policy로 추가한 정책은 list-attached-group-policies를 사용해야 한다

사용자 지정 정책을 이용한 EKS 권한 설정

EKS를 사용하려면 몇가지 특별한 권한 필요
필요한 권한을 연결할 수 있는 기존 정책이 존재하지 않음
사용자 지정 정책을 만들어 그룹에 연결해야 한다

custom-eks-policy.json

{
    "Version": "2021-10-19",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "eks:DescribeNodegroup",
                "eks:DeleteNodegroup",
                "eks:ListClusters",
                "eks:CreateCluster"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "eks:*",
            "Resource": "arn:aws:eks:*:*:cluster/*"
        }
    ]
}

$ aws iam create-policy --policy-name EKS-Management --policy-document file://custom-eks-policy.json
{
    "Policy": {
        "PolicyName": "EKS-Management",
        "PolicyId": "ANPA4MJV6IIZLV7GHI5S6",
        "Arn": "arn:aws:iam::851053527602:policy/EKS-Management",
        "Path": "/",
        "DefaultVersionId": "v1",
        "AttachmentCount": 0,
        "PermissionsBoundaryUsageCount": 0,
        "IsAttachable": true,
        "CreateDate": "2021-10-19T05:44:16Z",
        "UpdateDate": "2021-10-19T05:44:16Z"
    }
}

ARN

모든 AWS 리소스는 ARN이라는 고유식별자가 있음
위에서도 있는 Arn의 숫자와 문자열은 사용자의 aws 인스턴스에서 고유하다

위에서 나온 arn number를 사용해서 정책 추가

1
2
3

$ aws iam attach-group-policy --group-name Ops-Accounts \
  --policy-arn arn:aws:iam::851053527602:policy/EKS-Management
$

이제 ops-account 계정은 AWS 인프라 리소스를 자동 생성하는데 필요한 권한을 가진다

6.3.4 테라폼을 위한 S3 백엔드 생성

테라폼의 상태 파일

테라폼은 목표 상태를 위한 각 스텝별 단계를 정의하는 것이 아니다
원하는 인프라 상태를 선언형으로 정의 가능 → 강력
선언한대로 인프라 환경을 적절하게 변경하는 마법 → 이를 위해 상태와 작업 수행 이력 추적 가능해야 함
테라폼은 JSON 기반 상태 파일에 모든 정보를 추적하여 실행될 때마다 읽고 업데이트
상태 파일 로컬 보관
- 기본값
- 여러 작업 환경에서 테라폼 관리를 위해선 상태 공유가 필요함
- 로컬파일은 공유가 어려우며 상태충돌, 동기화 문제등이 발생 가능
S3 보관
- 테라폼은 S3를 상태 백엔드로 사용할 수 있는 기본 기능 제공
- 상태 데이터에 대한 새로운 bucket을 만들고 운영자 계정이 접근할 수 있는 권한이 설정 되어 있는지 확인과정 필요
- 버킷 개요
- 버킷을 생성하려면 고유한 이름과 리전 지정 필요
  - 이름은 aws 전체 리전에서 고유해야 한다
  - 여기서는 ahn-s3-bucket로 대체
  - 리전은 AWS 구성시 선택한 리전

us-east-1 리전에서 버스킷 호스팅은 간단

1 2	$ aws s3api create-bucket --bucket ahn_s3_bucket \ > --region us-east-1

us-east-1 가 아닌 다른 리전에서는 다음과 같이 한다
정상적 진행되면 버킷 위치가 포함된 json객체가 표시된다

$ aws s3api create-bucket --bucket ahn-s3-bucket \
> --region ap-northeast-2
> --create-bucket-configuration LocationConstraint=ap-northeast-2
{
    "Location": "http://ahn-s3-bucket.s3.amazonaws.com/"
}
$

S3는 기본적으로 외부에 공개되지 않음
- 따라서 s3버킷의 테라폼 상태파일은 권한 없는 사용자가 조회/변경 불가
- 현재 계정은 S3의 전체 권한이 있으므로 사용 가능

6.4 IaC 파이프라인 구축

인프라 파이프라인 구축

환경을 신속하게 프로비저닝 가능한 안전/쉬운 방법 제공 → 매우 중요
없으면? → 많은 단계 수동 진행 → 마이크로서비스 환경이 서로 다른 방향으로 흘러감

샌드박스 테스트 환경 구성

IaC 모듈과 파이프라인 테스트 맛보기 환경구성
구성요소 단계
- 샌드박스 테스트 환경을 위한 깃허브 호스팅 깃 저장소
- 샌드박스를 정의하는 테라폼 루트 모듈
- 샌드박스 환경을 생성 가능한 깃허브 액션 CI/CD 파이프라인

6.4.1 샌드박스 저장소 생성

깃허브 신규 저장소 생성

깃허브에서 새 저장소 생성
.gitignore 추가시 테라폼 템플릿 선택 : 테라폼의 숨겨진 작업 파일 커밋하지 않도록

6.4.2 테라폼의 이해

테라폼 파일 : HCL
- JSON과 유사
- JSON과 차이 : 키와 qoffb tkdldp : 를 사용하지 않음, 문맥에 따라 공백이나 =로 구분
- 주석, 문자열등 사소한 부분도 다른 부분 존재
테라폼 주요 4가지개념
- 백엔드
  - (앞서 말했듯?) 테라폼은 인프라 환경에 어떤 변경을 적용해야하는 지 알 수 있도록 상태 파일 유지 필요
  - 백엔드 : 해당 상태 파일의 위치
  - 기본값은 로컬파일시스템 저장
  - 예제에서는 S3 버킷 사용
- 리소스
  - 리소스는 상태를 선언한 것을 나타내는 객체
  - 테라폼은 리소스를 선언한 상태로 만들기 위해 변경 작업 수행
- 공급자
  - 테라폼 공급자 : 코드에서 사용할 수 있는 패키지화된 리소스 라이브러리
  - 예제에서는 대부분의 작업에 테라폼의 AWS 공급자 사용
  - 테라폼의 장점 : 다양한 클라우드 플랫폼, 인프라 환경에서 사용 가능
  - 사용자는 단지 테라폼에 공급자를 지정하기만 하면 된다
- 모듈
  - 테라폼 모듈 : 일반 프로그래밍 언어의 함수, 프로시저와 비슷
  - 재사용 가능한 방식으로 HCL 코드를 캡슐화 할 수 있는 방법 제공
더 자세히
- 테라폼 공식 문서(영어)
- 테라폼 기초 튜토리얼

6.3.4 샌드박스 환경 테라폼 코드 작성

목표 : 환경구축을 위한 인프라/도구 설정(테라폼 테스트용 맛보기 파일 생성)

포매터 적용

방법 : terraform fmt main.tf
fmt명령 : HCL 검사, 일관성과 가독성을 위한 formatter,변경된 파일 이름 출력

env-sandbox/main.tf

terraform {
  backend "s3" {
    bucket = "ahn-s3-bucket"
    key    = "terraform/backend"
    region = "ap-northeast-2"
  }
}

locals {
  env_name         = "sandbox"
  aws_region       = "ap-northeast-2"
  k8s_cluster_name = "ms-cluster"
}

# 네트워크 구성

# #KS 구성

# GitOps 구성

공급자 설치

공급차를 설치하지 않으면 테라폼이 구문 검사를 수행할 수 없음

방법 : terraform init

$ terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

구문 오류 확인

1 2	$ terraform validate Success! The configuration is valid.

작업확인 - plan

plan

테라폼이 지정한 환경을 만들기 위해 어떤 변경 수행하는지 미리 확인
코드가 적용될때 실행하는 동일한 단계 수행(실제로 변경 X)

테라폼 요청대로 인프라를 구축하기 위한 계획을 보여주는 모의테스트 같은 것

$ terraform plan
No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are
needed.

테라폼 구성과 실제 리소스간 차이 없음 → 별도 작업 필요 없음
plan 결과 : No Changes → 실제로 생성할 리소스를 정의하지 않았으므로
커밋

6.3.4 파이프라인 구축

파이프라인 설정

방금 생성하는 테라폼 파일을 자동으로 적용하는 CI/CD 파이프라인
도구 : 깃허브 액션
깃허브 액션 장점 : 인프라 코드와 동일 위치에 파이프 라인 구성 가능
가장 간단한 방법 : 브라우저 인터페이스통해 구성

Secrets 설정

브라우저에서 설정

저장소 상단 → Settings → Secrets에 [New repository secret] 선택해서 입력
저장할 것 : AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

워크플로 생성

워크플로(workflow)

파이프라인 트리거 될 때마다 샐행되는 일련의 스텝들
msa 인프라 파이프라인은 테라폼 검증, 샌드박스 환경에 적용하는 워크플로가 필요
이외에도 테라폼 적용 전, 적용후에 스텝들 추가 필요
- 빌드환경을 준비하기 위해 로컬 환경에서 했던 것처럼 테라폼과 aws-cli 설치 필요
- 워크 플로 빌드는 VM에서 이루어짐 ▶ 코드 저장소에서 코드 사본 가져오는 스텝도 필요
- 변경사항 적용후 정리or프로비저닝 작업 가능 ▶ 예제에선 로컬에서 aws 접속위한 구성파일 만듬
트리거 지정
- 깃허브에서 워크플로 시작할 시기 알 수 있도록 트리거 지정
- 예제에서는 tag를 트리거로 사용
워크 플로 전체 모습

파이프라인 스텝 정의

YAML, 깃허브 액션 워크 플로 명령을 사용
템플릿 사용하지 않고 처음부터 직접 작성

직접 작성시 나오는 basic workflow yaml

# 직접 작성시 나오는 basic workflow

name: CI

# 워크플로가 실행할 컨트롤 
on:
  # 메인 브렌치에서 푸쉬나 PR일때 트리거
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

  # 액션 텝에서 수동으로 워크플로 실행 허용
  workflow_dispatch:

# 워크플로는 1개 이상의 잡들을 직렬or병렬로 실행 가능
jobs:
  # 이 워크플로는 "build"라 불리는 단일 job을 포함
  build:
    # job이 올라갈 runner 타입
    runs-on: ubuntu-latest
    # step은 job의 일부로써 수행될 task들의 시퀀스를 나타냄
    steps:
      # job이 엑세스 가능하도록 $GITHUB_WORKSPACE 밑에 저장소를 체크아웃
      - uses: actions/checkout@v2

      # runner의 쉘에서 한개의 명령어 수행
      - name: Run a one-line script
        run: echo Hello, world!

      # runner의 쉘에서 다수의 명령어 수행
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

트리거 및 설정 구성

워크플로 트리거와 작업 설정

name: 샌드박스 환경 빌드

on:
  # v* 패턴과 일치하는 새 태그가 생성될 때마다 워크플로 실행
  create:
    tags:
      - v*

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY_ID}}
      AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET_ACCESS_KEY}}
    
    steps:
      - uses: actions/checkout@v2

      - name: 한줄 스크립트
        run: echo 헬로우 월드!

      - name: 여러줄 스크립트
        run: |
          echo 프로젝트의 빌드, 테스트, 배포에 
          echo 다른 액션을 추가해보자

워크 플로 실행 준비 완료

종속성 설치

목표는 테라폼 실행
그전에 도구를 실행할 수 있도록 환경을 설정해야 함
로컬에서 인프라 개발 환경 설정할떄 git, aws-cli, terraform 명령어 도구 설치 했듯이
빌드 환경도 유사한 작업 수행해야함
실행에 필요한 특정 작업을 알고 있기 때문에 더 간결한 종속성 집합 설치 가능
깃허브 액션은 git을 자유롭게 사용 가능하므로 별도 설치 필요 없음
해시코프가 즉시 사용 가능한 테라폼 깃허브 액션 제공 - 테라폼 설치도 걱정 없음
AWS 구성만 작업하면 됨
앞장에서 AWS CLI를 통해 했던 작업을 파이프 라인에서는 테라폼을 사용하여 변경
따라서 AWS-CLI 설치 안함

필요한 종속성 - k8s 기반 MSA를 다루기 위해선 몇 가지 종속성이 필요

AWS 인증자(authenticator) 도구 설치

AWS 인증자

다른 도구에서 AWS 환경을 인증/접속하는데 사용할 수 있는 명령줄 도구
나중에 k8s작업과 AWS에서 호스팅하는 k8s 클러스터 접근 구성시 사용

name: 샌드박스 환경 빌드

on:
  # v* 패턴과 일치하는 새 태그가 생성될 때마다 워크플로 실행
  create:
    tags:
      - v*

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY_ID}}
      AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET_ACCESS_KEY}}
    
    steps:
      - uses: actions/checkout@v2
      
      # 종속성 설치
      - name: Install aws-iam-authenticator
        run: |
          echo Install aws-iam-authenticator
          mkdir ~/aws
          curl -o ~/aws/aws-iam-authenticator \
          "https://amazon-eks.s3.us-west-2.amazonaws.com/\
          1.19.6/2021-01-05/bin/darwin/amd64/aws-iam-authenticator"
          chmod +x ~/aws/aws-iam-authenticator
          sudo cp ~/aws/aws-iam-authenticator /usr/local/bin/aws-iam-authenticator

      # 테라폼 적용

테라폼 파일 적용

파이프라인에서 테라폼 파일 형식 지정 유효성 검사


# 테라폼 적용
- uses: hashicorp/setup-terraform@v1
  with:
    terraform_version: 1.0.9

- name: Terraform Formatter
  run: terraform fmt

- name: Terraform Init
  run: terraform init

- name: Terraform Validate
  run: terraform validate -no-color

- name: Terraform Plan
  run: terraform plan -no-color

- name: Terraform Apply
  run: terraform apply -no-color -auto-approve

테라폼 CLI를 호출하기 위해 run 액션 사용
-auto-approve : 워크플로에서 운용자 승인단계를 skip하도록

파일 게시 및 변경 사항 커밋

# 정보 게시
- name: Upload kubeconfig file
  uses: actions/Upload-artifact@v2
  with:
    name: kubeconfig
    path: kubeconfig

6.4.5 파이프라인 테스트

태깅 후 푸쉬

1 2	$ git tag -a v0.1 -m "워크플로 test" $ git push origin v0.1

필요시 태그 삭제

git tag -d v0.1
원격 저장소 올라간 태그 삭제 : git push origin :v.0.1

깃허브 저장소의 액션에서 워크플로 실행 결과를 확인 가능

devArchitectureMicroservice