[교육] DevOps Engineering on AWS 1일차

소감

3일간 진행하는 DevOps Engineering on AWS 교육 1일차 내용 이론과 실습을 정리해보았다.

공유받은 자료 속 이론들이 매우 유익했다. (공유 불가능 ㅠ)

작성하면서 느낀 점은 전체적으로 너무 내가 알아볼 수 있게끔만 작성한 것 같다.

이후에 또 따라할 수 있도록 혹은 누가봐도 실습 내용을 이해할 수 있도록 작성 해야겠다.

 

이론

모노 (mono=하나)ㄹ리식

∙ 큰 단일 플랫폼

∙ 긴 개발 주기

∙ 크기 조정의 복잡성

∙ 단일 서버에서 cpu/mem 하나의 컴포넌트 추가하기 힘듦 → 확장성 한계 존재

 

DevOps 방식으로 운영한다는 것

∙ CI/CD, MSA, IaC, Monitoring, Logging, etc. 를 사용한다는 것

 

모니터링 및 로깅

∙ 운영 가시성 및 인사이트

∙ 지표 수집

∙ 성능 개선

 

Amazon CodeGuru

∙ AWS CodeCommit에서 코드 리뷰 자동화, 추천 및 수정 제안

 

AWS Lambda

∙ 15분 제한이 있으므로 무거운 서비스는 돌릴 때는 추천X

 

AWS AppMesh

∙ sidecar container가 가운데서 application container 대신 처리해줌

 

Amazon Inspector

∙ V3와 유사하나 문제를 감지만 하고 조치하진 않음

 

코드형 인프라(IaC)

∙ 셸 스크립트

∙ 애플리케이션 코드

∙ AWS CloudFormation

∙ third Party도구 (Ansible, Terraform, etc.)

 

코드형 인프라의 이점

∙ 애플리케이션 소스코드 처럼 버전 관리

∙ 반복적이고 안정적으로 생성

∙ 리소스 종료 및 재 생성

 

자동화 필요성

∙ 인적 오류 감소

∙ 보다 빠른 릴리스 및 응답 시간

∙ 코드형 정책으로 규정 준수 유지

 

CloudFormation

∙ Template → Stack(만들어진 인프라) 

∙ nested stack (중첩 스택) : 스택을 여러 개 사용 가능

∙ Stack: 실제 생성될 인프라의 논리적인 모습

∙ 콘솔 또는 CLI로 생성하는 Stack 단위로 인프라 생성

∙ Drift 탐지 → Drift란, CloudFormation 리소스 구성과 현 리소스 구성의 동기화 를 의미함

 

 

AWS TaskCat

∙ AWSCloudFormation 템플릿을 테스트

 

AWS SDK

∙ 널리 사용되는 프로그래밍 언어(python, java)를사용하여 애플리케이션을 AWS 서비스와 통합한다.

 

AWS CDK

∙ 익숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 모델링하기 위해 클라우드 인프라(IaC)를 정의하고 프로비저닝한다. 

 

AWS CloudFormation 헬퍼 스크립트

EC2 내 소프트웨어(헬퍼)를 설치하고 서비스 시작함

∙ cfn-init 

리소스 메타데이터를 검색 및 해석하고 패키지 설치, 파일 생성, 서비스 시작하는데 사용

 

∙ cfn-signal

CreationPolicy 또는 WaitCondition을 사용하여 신호를 보내는데 사용

필요한 리소스나 애플리케이션이 준비될 때 스택의 다른 리소스를 동기화할 수 있음

성공 또는 실패 신호를 제공

 

∙ cfn-get-metadata

리소스의 메타데이터 또는 특정 키의 경로를 검색하는 데 사용

 

∙ cfn-hup

메타데이터 업데이트를 확인하고 변경 사항이 탐지될 때 사용자 지정 후크를 실행하는 데 사용

메타데이터에 변경 사항이 있는지 cfm 스택을 폴링

 

템플릿의 메타데이터를 변경하고 기존 스택을 업데이트하면 어떻게 되나요?
아무일도 일어나지 않는다. cfn-init를 실행하거나 cfn-hup가 메타데이터 변경을 모니터링하도록 구성된 경우에만 동작이 발생한다.

 

DeletionPolicy

∙ 스택이 삭제될 때 리소스를 보존 또는 백업하기 위하여 사용

∙ 옵션

∙ 삭제

∙ 유지(Retain)

∙ 스냅샷

 

AWS CodeCommit

∙ 코드 형상 관리 저장소 (ex. GitHub)

∙ Git 기반 개발자들이 버전 관리를 통해 소스 코드를 효율적으로 관리하고 협업 가능

∙ 실제 저장되는 곳은 S3

 

AWS CloudFormation

∙ Format Version : CloudFormation 템플릿 버전

∙ Description : 텍스트 문자열, 주석

∙ Parameters : 템플릿에 대한 입력

∙ Mappings : 정적 변수, 키 값 페어

∙ Conditions : 특정 리소스의 생성 또는 업데이트 여부 및 시기에 대한 제어

∙ Transform : 템플릿을 처리할 하나 이상의 매크로 지정

∙ Resources : 생성할 AWS 자산

∙ Outputs : 템플릿이 생성하는 사용자 지정 리소스 값 (URL, 사용자 이름 등)

 

∙ DRIFTED : 스택이 예상 템플릿 구성과 다름. 하나 이상의 리소스가 드리프트한 스택은 드리프트한 것으로 간주

∙ NOT_CHECKED : AWS Cloudformation이 스택과 예상 템플릿 구성이 다른지 검사하지 않음

∙ IN_SYNC : 스택의 실제 구성이 예상 템플릿 구성과 일치

 

* 모든 리소스를 CFM으로 생성할 수 있는 것이 아님!!

* 여러 값을 지정할 때 리스트 혹은 - 으로 지정

 

Git

∙ 오픈 소스 분산형 소스 코드 관리 시스템

 

브랜치(branch)

∙ 리포지토리의 복사본

∙ 독립적으로 코드 작업 수행 가능

∙ 다른 개발자의 커밋을 내 리포지토리로 가져오고, 내 커밋을 다른 사용자에게 푸시하고, 병합 가능

 

AWS CodeCommit용 설정

1. AWS CodeCommit에 액세스하기 위한 IAM 자격증명 및 정책을 생성
2. IAM 사용자에 대한 액세스 정책을 연결하여 권한을 부여
3. Git 설치
4. AWS CLI 설치
5. 자격 증명(HTTPS/SSH, AWS CLI 자격 증명 헬퍼를 사용하여 기존 키)를 설정
6. AWS CodeCommit에 연결하고 리포지토리를 복제

 

LDAP (Lightweight Directory Access Protocol)

https://www.samsungsds.com/kr/insights/ldap.html

∙ 네트워크상에서 조직이나 개인, 파일, 디바이스 등을 찾아볼 수 있게 해주는 소프트웨어 프로토콜

 

Federation은

∙ 서로 다른 시스템이나 도메인 간의 신뢰 관계를 설정하여 사용자 인증 및 권한 부여를 상호 연동하는 개념

∙ ex. SSO(Single Sign-On)

 

트렁크(단일 공유 브랜치) 기반 개발

∙ 많은 개발자가 단일 공유 브랜치를 통합하거나 여기로 커밋하는 또 다른 분기 모델

∙ 대부분의 조정/수정/커밋은 트렁크에서 발생하고 그런 다음 릴리스 브랜치에 병합된다.

 

풀 리퀘스트 작업

∙ 풀 리퀘스트: 여러 개발자가 한 리포지토리에서 협업하는 방법

∙ 협업하여 한 브랜치에서 다른 브랜치로 병합

 

실습

실습 1: AWS CloudFormation을 사용하여 기본 인프라 프로비저닝 및 관리

• Description: 템플릿을 설명하는 텍스트 문자열입니다.
• Parameters: 스택을 생성하거나 업데이트할 때 런타임에 템플릿에 전달되는 값입니다.
• Resources: 스택 리소스와 그 속성을 지정합니다.
• Outputs: 스택이 성공적으로 완료된 후 스택 속성으로 반환되는 값을 설명합니다.

과제 1.1: 템플릿에 파라미터 추가

****************************************************************************************************************

※ CloudFormation 코드 중 일부

lab1.yaml 템플릿의 Parameter 를 업데이트 합니다.

****************************************************************************************************************

Parameters:
  InstanceType:
    Description: WebServer EC2 instance type
    Type: String
    Default: t2.nano
    AllowedValues:
      - t2.nano
      - t2.micro
      - t2.small
    ConstraintDescription: Must be a valid EC2 instance type.

 

 

 

과제 1.2: 템플릿에 리소스 추가

****************************************************************************************************************

※ CloudFormation 코드 중 일부

이 과제에서는 Cloud9 환경에서 lab1.yaml 템플릿에 리소스를 추가합니다.

****************************************************************************************************************

Resources:
    Logical ID:
        Type: RAWS::EC2::Route
        DependsOn:
            - VPC
            - AttachGateway
        Properties:
            RouteTableId: !Ref RouteTable
            DestinationCidrBlock: 0.0.0.0/0
            GatewayId: !Ref InternetGateway

 

 

 

과제 1.3: 템플릿에 출력 추가

****************************************************************************************************************

※ CloudFormation 코드 중 일부

이 과제에서는 Cloud9 환경에서 lab1.yaml 템플릿에 Outputs을 추가합니다.

****************************************************************************************************************

Outputs:
  Logical ID:
    Description: Newly created application URL
    Value: !Sub 'http://${WebServerInstance.PublicIp}'

 

 

과제 2: 스택의 CloudFormation 템플릿을 사용하여 인프라 프로비저닝

이 과제에서는 AWS CLI에서 스택 생성 프로세스를 시작하고 생성된 모든 리소스를 CloudFormation 콘솔에서 검토한다.

 

 

현재 배포하고자하는 yaml이 있는 폴더로 이동한다.

$ aws cloudformation create-stack --stack-name Lab1 --parameters ParameterKey=InstanceType,ParameterValue=t2.micro --template-body file://lab1.yaml

 

 

과제 2.1: LAB1.YAML 템플릿을 사용하여 CREATESTACK 실행

****************************************************************************************************************

※ 아래처럼 출력되어야 정상적으로 스택 생성 

****************************************************************************************************************

{
    "StackId": "arn:aws:cloudformation:ca-central-1:350214907448:stack/Lab1/7f733ee0-bf54-11ec-aa09-0244448197b2"
}

 

 

 

과제 2.2: 스택의 상태 확인

aws cloudformation describe-stacks --stack-name Lab1

 

 

과제 2.3 APPURL 작동 확인

Cloudformation 콘솔의 Outputs 탭에서 새 브라우저 탭에 표시된 AppURL을 시작하면 페이지에 접근할 수 없음을 확인할 수 있다.

 

 

과제 3: CloudFormation 스택의 드리프트 탐지

AWS CloudFormation을 사용하여 CloudFormation에 의하지 않은 변경 사항을 탐지한다.

환경을 변경하고, 모든 드리프트를 탐지하도록 CloudFormation에 지시한 다음 결과를 확인한다.

환경을 수정해보자. 예를 들어, 보안 그룹 규칙을 0.0.0.0/0으로 수정하자.

 

 

과제 3.1: 드리프트 보고서 생성

콘솔에서 생성된 스택을 누른 후, 세부 정보 창에서 Stack actions 드롭다운 메뉴를 선택한 다음 드리프트 감지 를 선택한다.

스택이 선택된 후, Stack actions 드롭다운 메뉴에서 드리프트 결과 보기 를 선택한다.

 

 

과제 3.2: CLI를 통해 드리프트 탐지 결과 보기

$ aws cloudformation describe-stack-resource-drifts --stack-name Lab1 --stack-resource-drift-status-filters MODIFIED DELETED

 

 

과제 4: 변경 세트를 사용하여 스택 업데이트

CLI를 통해 스택 변경 세트 생성 및 실행

$ aws cloudformation create-change-set --stack-name Lab1 --change-set-name Lab1ChangeSet --parameters ParameterKey=InstanceType,ParameterValue=t2.micro --template-body file://lab1-CS.yaml

 

 

****************************************************************************************************************

※ 아래처럼 출력되어야 정상적으로 스택 생성 

****************************************************************************************************************

{
    "Id": "arn:aws:cloudformation:ca-central-1:350214907448:changeSet/Lab1ChangeSet/b62f9a0f-bd5e-4988-9016-bba2c46f351b",
    "StackId": "arn:aws:cloudformation:ca-central-1:350214907448:stack/Lab1/7f733ee0-bf54-11ec-aa09-0244448197b2"
}

 

 

 

과제 4.1: 변경 세트 실행

CloudFormation Stack에서 변경 세트 실행 을 선택한다.

기본값인 Roll back all stack resources가 선택된 상태에서 Execute change set를 선택한다.

Lab1ChangeSet는 더 이상 사용할 수 없으며, Last executed change set 아래에 새 항목이 있다.

 

 

과제 4.2: APPURL 작동 확인

Outputs 탭에서 새 브라우저 탭에 표시된 AppURL을 시작하면 정상적으로 웹 페이지를 확인할 수 있다.