Las 낙서장

Resource Group

- AWS에서 리소스는 사용할 수 있는 개체 (EC2, S3 등등)

- Resource Group을 사용하면 프로젝트 및 사용하는 리소스를 기반으로 정보를 구성하고 통합하는 사용자 지정 콘솔을 만들 수 있음

- Resource Group를 사용하지 않을 경우 서비스 상태를 확인하거나 각 애플리케이션 버전의 설정을 수정하는 간단한 작업을 할 때에도 다수의 콘솔에 액세스 해야함

- Resource Group에서는 단일 페이지를 사용하여 리소스를 보고 관리

- 예를 들어 Resource Group을 사용하여 애플리케이션의 각 버전 (개발, 테스트, 운영)에 대한 리소스 그룹을 만드는 경우 애플리케이션의 테스트 버전의 리소스를 확인하고 CloudWatch 경보가 트리거 되었는지 확인하려면 리소스 그룹을 열기만 하면 됨

작동 방식

- 리소스 그룹은 하나 이상의 태그 키 또는 태그의 일부를 공유하는 리소스의 컬렉션

- 리소스 그룹을 만드려면 그룹 멤버들이 공통적으로 가지고 있는 항목이 포함된 태그를 식별하기만 하면 됨

- 사용자 또는 관리자가 IAM을 사용하여 동일한 계정에 여러 사용자를 만드는 경우 해당 사용자는 개별 리소스 그룹을 가지게 됨 (해당 그룹들은 다른 사용자가 볼 수 없음)

- 하지만 각 사용자는 URL을 공유하여 동일한 계정의 다른 사용자와 리소스 그룹을 공유할 수 있으며 다른 사용자는 동일한 매개 변수로 리소스 그룹을 만들 수 있음

- 태그 자체는 리소스의 속성과 같은 기능을하므로 전체 계정에서 공유되므로 부서의 사용자는 부서 또 또는 계정 내 공통 용어(태그)를 바탕으로 각자의 역활 및 책임에 있어 유의미한 리소스 그룹을 만들 수 있음

- 공통의 태그 풀이 있을 경우 사용자들이 리소스 그룹을 공유하면 태그 정보를 잃어버리거나 충돌할 염려가 없다는 것을 의미

리소스 그룹 생성

- 리소스 그룹을 만들려면 먼저 리소스에 태그를 지정해야함, 그 다음 공통 태그 또는 그러한 태그의 공통 스트링이 있는 리소스의 보기를 만듬

(사용자 지정 태그를 만들거나 동일한 계정의 다른 사용자가 만든 태그를 사용할 수 있음, CloudFormation의 스택 이름과 같이 AWS가 자동으로 만드는 태그를 사용할 수도 있음)

- 모든 태그는 키와 값으로 구성되고 검색 엔진 측면에서 값을 추가하는 것은 OR 연산자로 검색하는 것과 유사 (검색된 모든 항목이 포함)

- 키를 추가하는 것은 AND를 사용하여 검색하는 것과 유사 (모든 키가 있는 항목만 포함)

- 지정한 각 태그 키에 값을 추가하면 리소스 그룹의 크기가 커지지만 키를 추가하면 그룹 키가 줄어들 수 있음

- 사용 예제

• 리소스가 2개 (인스턴스)가 있고 각 인스턴스에는 이름이 스택인 키를 사용하여 태그를 할당 중

• 스택키 중 하나는 프로덕션이고 다른 하나는 테스트, 스택키가 테스트인 인스턴스에는 Onwer키가 있고 그 값은 Jan

• 스택키와 프로덕션 및 테스트 값이 모두 포함된 리소스 그룹을 만들경우 그룹의 멤버는 2개가 됨 (스택키를 둘다 가졌으나 값이 다르기 때문에 그룹이 2개 생성)

• 그룹 정의에 소유자 키를 추가하면 하나의 인스턴스에만 해당 키가 있으므로 그룹이 하나로 축소

이외에도 일부 태그 값을 기준으로 그룹을 만들 수 있음, 예를 들어 알파, 베타, 릴리스 버전이 있는 경우 각 리소스의 이름 키에 여러 정보 포인트가 포함될 수 있는데 테스트 알파 버킷, 프리 알파 버킷, 개발 베타 버킷이 있다면 알파 버전의 리소스 그룹이 만들고 싶다면 알파가 포함된 태그만 지정하면 해당 리소스 그룹이 생성되는데 아니면 태그값에 버킷만 포함되도록 하여 버킷의 리소스 그룹 또한 생성할 수 있음

참조 URL

https://docs.aws.amazon.com/ko_kr/awsconsolehelpdocs/latest/gsg/what-are-resource-groups.html

CodeBuild 

- 소스 코드를 컴파일하는 단계부터 테스트 실행 후 소프트웨어 패키지를 개발하여 배포하는 단계까지 마칠 수 있는 완전 관리형 지속적인 통합 서비스

- CodeBuild를 사용하면 자체 빌드 서버를 프로비저닝, 관리 및 확장할 필요가 없음

- CodeBuild는 지속적으로 확장되며 여러 빌드를 동시에 처리하기 때문에 빌드가 대기열에서 대기하지 않고 바로 처리

- 지정된 위치에서 소스코드를 가져와 Build & Test 수행

아키텍처

1. Build project는 CodeBuild에서 빌드를 실행하는 방식을 정의하는데 여기에는 소스 코드를 가져올 위치, 사용할 빌드 환경, 실행할 빌드 명령 및 빌드 출력을 저장할 위치 등의 정보가 포함된다. (빌드 환경은 운영체제, 프로그래밍 언어 실행 시간 및 CodeBuild에서 빌드를 실행하는데 사용되는 도구의 조합을 나타냄)

2. CodeBuild가 Build project를 사용하여 빌드 환경을 생성

3. CodeBuild가 빌드 환경에 소스 코드를 다운로드한 다음 Build project에 정의된 대로 또는 소스 코드에 직접 포함된 빌드 사양을 사용 (빌드 사양은 CodeBuild가 빌드를 실행하는데 사용하는 YAML 형식의 빌드 명령 및 관련 설정 모음)

4. 빌드 출력이 없으면 빌드 환경에서 출력을 S3 Bucket에 업로드 (빌드 환경은 사용자가 빌드 사양에 지정한 작업을 수행할 수 있음)

5. 빌드가 실행되는 동안 빌드 환경이 정보를 CodeBuild 및 CloudWatch Logs에 전송

6. 빌드가 실행되는 동안 CodeBuild Console, AWS CLI 또는 AWS SDK를 사용하여 CodeBuild에서는 요약된 빌드 정보를 가져옴 (CloudWatch Logs에서는 자세한 빌드 정보를 가져올 수 있지만 CodePipeline을 사용하여 빌드를 실행하는 경우에는 CodePipeline에서 제한된 빌드 정보만 가져옴)

참조 URL

https://jojoldu.tistory.com/282

https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/welcome.html

https://luckyyowu.tistory.com/367

https://docs.aws.amazon.com/ko_kr/codebuild/latest/userguide/build-spec-ref.html

CodeCommit 

- 클라우드에서 문서, 소스코드 등을 비공개로 저장하여 관리할 수 있도록 AWS에서 호스팅 되는 버전 관리 서비스

아키텍처

1. AWS CLI 또는 CodeCommit Console을 사용하여 AWS CodeCommit Repository를 생성

2. 개발 시스템에서 Git을 통해 git clone을 실행하여 CodeCommit Repository의 이름 지정 (AWS CodeCommit Repository에 연결되는 로컬 Repo가 생성)

3. 개발 시스템에서 로컬 Repo를 사용하여 파일을 수정한 다음 git add를 실행하여 수정된 파일을 로컬로 스테이징, git commit을 실행하여 파일을 로컬로 Commit한 다음 git push를 실행하여 AWS CodeCommit Repository로 전송

4. 다른 사용자가 변경한 내용을 다운르도하고 git pull을 실행하여 CodeCommit Repository의 파일을 로컬 Repo와 동기화할 수 있음 (AWS CLI 또는 CodeCommit 콘솔을 사용하여 Repository 추적 및 관리 가능)

참조 URL

https://docs.aws.amazon.com/ko_kr/codecommit/latest/userguide/welcome.html

CodePipeline

- 소프트웨어를 프로덕션으로 빌드, 테스트, 배포하는 과정을 자동화하는 지속적인 제공 서비스

• 지속적 통합 (CI : Continuous Integration) : 자동화된 빌드 및 테스트가 수행된 후 개발자가 코드 변경 사항을 중앙 레포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식으로 소프트웨어 릴리스 프로세스 중 빌드 또는 통합 단계를 주로 가리키며 자동화 구성요소와 문화적 구성요소 모두를 포함

• 지속적 전달 (CD : Continuous Delivery) : 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식으로 빌드 단계 이후의 모든 코드 변경을 테스트 환경 또는 프로덕션 환경에 배포함으로써 지속적 통합을 확장

CodePipeline 릴리스 프로세스

1. 개발자가 소스 레포지토리에 수정을 하면 CodePipeline이 자동으로 수정 내용을 감지

2. 수정 내용을 빌드하고 테스트를 구성하는 경우에는 테스트를 실행

3. 테스트가 종료되면 빌드된 코드를 스테이징 서버로 배포

4. 스테이징 서버에서 통합이나 로드 테스트 같은 추가 테스트를 실행

5. 테스트가 성공적으로 끝나고 파이프라인에 추가된 수동 승인 작업에 승인을 받고나면 테스트가 완료된 코드를 프로덕션 인스턴스에 배포

아키텍처

- 릴리스 프로세스의 워크플로우 생성 및 관리를 지원

- 소프트웨어 변경 사항이 릴리스 프로세스에 적용되는 방법을 설명하는 워크플로우 (일련의 작업 과정) 구성

수정

- 수정이란 GitHub Repo 또는 CodeCommit Repo에 Push된 Commit, S3 Bucket에서 파일 업데이트처럼 소스에 변경을 가하여 CodePipeline에 대한 소스작업을 구성한 것

- 각 버전은 파이프라인을 거쳐 개별적으로 실행

- 동일한 파이프라인에서 여러가지 수정을 처리할 수 있지만 각 단계에서는 한번에 한개의 수정만 처리할 수 있음

- 소스 단계에서 지정한 위치에 변경을 처리하면 파이프라인을 통해 수정이 실행 

(파이프라인에 여러 개의 소스 작업이 포함되어 있는 경우 소스 작업 한개에만 변경이 감지되더라도 모든 소스작업이 다시 실행)

워크플로우

- 파이프라인은 워크플로우를 여러 단계로 나눔 (각 단계는 스테이지로도 표현)

• 빌드 단계에서는 코드를 빌드하고 테스트를 실행

• 배포 단계에서는 코드 업데이트를 환경에 배포

• 추적과 제어, 보고 성능을 높이기 위해 릴리스 프로세스의 각 단계에 이름을 붙일 수 있음 (소스, 빌드, 스테이징)

- 각 단계(Stage)에는 고유한 이름 (소스, 빌드, 스테이징)이 붙으며 워크플로우의 일환으로 일련의 작업(Action)이 포함

- 하나의 단계에서는 한개의 수정만 처리할 수 있는데 해당 수정이 실행되고 성공적으로 끝나야 단계가 완료된 것으로 간주 되어 다음 단계로 전환

(단계가 끝난 후 파이프 라인은 그 단계에서 작업으로 생성된 아티팩트[빌드의 결과로 얻을 수 있는 실행파일을 의미 (작업 결과물)]와 수정 내용을 다음 단게로 전환)

- 다음 단계로 전환은 수동으로 활성화하거나 비활성화 할 수 있음

- 모든 단계에는 최소 한개 이상의 작업이 포함되는데 이것은 아티팩트에서 수행하는 일종의 작업임

- 파이프 라인 작업은 단계 구성에서 정의한 대로 지정된 순서나 연속 또는 병렬로 발생

(배포 단계에서는 한개 이상의 스테이징 서버에 코드를 배포하는 배포작업이 포함, 필요에 따라 단일 시작 작업으로 단계를 구성하고 해당 단계에 작업을 추가 가능)

- 수정이 파이프 라인을 통해 실행되기 시작하면 CodePipeline은 해당 단계와 작업을 파이프라인에서 S3 버킷에 작업할 파일이나 변경 내용을 복사

(이런 객체를 아티팩트라 하며 작업 소스(입력 아티팩트) 또는 작업의 출력(출력아티팩드)라고 함, 아티팩트는 한 가지 이상의 작업에 의해 작동)

작업

- 위의 그림은 파이프라인에서 입력 아티팩트와 출력 아티팩트를 생성하고 소비하는 방법

- 작업의 유형

• 작업을 실행하는 동안 소비하거나 작업하는 입력 아티팩트

• 작업의 출력인 출력 아티팩트

- 파이프라인의 모든 출력 아티팩트에는 고유의 이름이 있어야함

- 하나의 작업에 대한 모든 입력 아티팩트는 앞선 파이프 라인 내의 작업의 출력 아티팩트와 일치해야함

(한 단계 전이든 몇단계 전에 실행된 작업이든 중요하지 않음)

전환

- 전환이란 워크플로우의 한 단계에서 다음 단계로 지속하는 파이프 라인 내 수정 행동

( 콘솔에서는 어떤 단계에가 일어나는지 순서를 보여주기 위해 전환 화살표가 여러 단계를 함께 연결)

- 단계가 끝나면 기본값으로 수정 내용이 파이프라인의 다음 단계로 전환 (다음 단계로 전환 비활성화 가능, 활성화를 다시 시작하면 중지된 부분부터 전환 실행)

- 한 단계를 통해 한번에 하나의 리비전만 실행할 수 있기 때문에 다음 단계를 이용할 수 있을때까지 이전 단계에서 완료한 모든 리비전을 CodePipeline이 일괄 처리

(최근 리비전이 단계를 거치고 나면 배치를 동해 최근 리비전으로 교체)

- 승인 작업은 권한이 허용될 때가지 파이프라인이 다음 작업으로 전환하지 않도록 방지 (승인받은 IAM 사용자만 가능)

- 승인 작업은 코드 컴토를 마친 후 다음 파이프라인으로 전환하고 싶을때, 파이프라인이 최종 프로덕션 단계로 전활할 시기를 제어하고 싶을때 사용

(프로덕션 배포 직전에 중지 후 공지를 거친 다음 실행 가능)

- 실패는 한 단계에서 성공적으로 완료하지 못한 작업 (다음 단계로 전환하지 못함)으로 다음 중 하나가 발생할때까지 CodePipe이 파이프라인을 중단

• 실패한 작업이 포함된 단계를 수동으로 재시작

• 해당 수정에 대하여 파이프라인 재시작

• 소스 단계에서 다른 수정 실행

- 소스 위치에 변경을 가하거나 수동으로 파이프 라인을 시작할 때 파이프라인이 자동으로 시작

(지정된 이벤트가 발생하면 파이프 라인을 자동으로 시작하도록 CloudWatch의 규칙 설정 가능[ CodeCommit 소스 레포지토리가 있는 파이프라인을 만들거나 편집하면 CodePipeline이 CloudWatch Events를 사용하여 레포지토리 변경을 감지하고 변경이 발생하면 파이프라인 시작])

CodePipeline 과정 

1. CodeCommit에 코드가 커밋되면 CodePipeline에서 코드가 커밋된것을 인식하여 자동으로 CodeBuild 과정을 진행 (Commit -> Build 과정 활성화 체크)

2. CodeBuild 과정에서는 정의된 명세서 (Buildspec) 대로 테스트를 거침

(Build VM 생성 -> CodeBuild Agent가 VM에서 실행 -> Source Code Download -> Buildspec에 정의된 대로 Build 실행 -> Build 결과 출력 및 아티팩트 생성 -> 아티팩트 S3에 업로드 ->  Build VM 삭제)

3. CodeBuild 단계에서 출력된 아티팩트를 S3에서 CodeDeploy가 다운로드

4. Appspec에 정의된 대로 스테이징 개체 또는 프로덕션 개체 생성

5. 배포 과정은 Appspec에 정의된 hooks 대로 블루/그린 방식 또는 인플레이스 방식으로 배포 (IAM으로 배포 인가시, Build 후 자동 Deploy 선택)

6. 배포 결과 출력

참조 URL

https://docs.aws.amazon.com/ko_kr/codepipeline/latest/userguide/concepts.html

https://blog.leedoing.com/82

https://www.holaxprogramming.com/2017/10/16/devops-aws-codestar/

• 비정상 상태일 때를 감지하여 종료 후 이를 대체할 인스턴스를 시작
• 복수의 AZ에 배포하도록 Auto Scaling Group을 구성하였을때 하나의 AZ가 사용 불가 상태가 되어도 다른 AZ에 같은 수의 인스턴스가 새로 배포되어 서비스 제공

• 현재 트래픽 요구를 처리할 수 있는 적절한 용량을 갖춤

• 필요에 따라 동적으로 인스턴스 수를 확장 / 축소 하면서 사용한 EC2 인스턴스에 대해서만 비용을 지불

• 인스턴스 사이즈 변경, EBS Capacity 증가

• 인스턴스를 추가하거나 삭제, ELB 활용

• 다양한 항목에 대해 사용량을 모니터링하고 관리할 수 있는 서비스
• 알람을 설정하고 측정된 데이터를 기반으로 어떠한 액션을 취할 수 있도록 알람을 설정할 수 있음

• CloudWatch에서 알람은 특정 기간 동안 하나의 메트릭을 모니터링하는 것 (메트릭은 모니터링할 대상을 의미 - CPU Used / Network In Traffic 등등)

• Software 설치
• S3로부터 Data Copy
• DNS에 등록
• 서비스 기동
• 패키지 업데이트
• Reboot 수행
• 80 Port 오픈 (ELB에 등록, Device Mount)

• 인스턴스에 포함된 스크립트 (Bash, PowerShell)
• 설정 관리 도구 (Chef, Puppet)
• AWS Opsworks

• 파일명 변경
  - 좀 더 빠르게 캐쉬에서 컨텐츠를 업데이트 하기 위해서는 버전을 사용하기를 권장하는데 이 말의 의미는 파일명을 바꾸도록 하는 것이다.
  (Ex. /image/photo.png가 있을때 이 파일이 변경되기를 원할 경우 HTML 원본에서 해당 이미지 명을 /image/photo_v2.png로 변경하고 새로운 파일명도 photo_v2.png로 저장을 하면 별도의 cache invalidation 작업 없이 바로 변경 내용을 반영할 수 있음)
• Query String
  - 파일명을 바꾸는게 어려울 경우 Query String을 사용할 수 있음
  (Ex. /image/photo.png?version=1.0 으로 HTML에서 이미지 경로를 걸어 놓으면 CloudFront는 “photo.png?version=1.0”을 Key로 캐쉬에 파일을 저장한다. Origin Server에 이렇게 파일을 요청하게 되면 이 파일은 정적인 컨텐츠이기 때문에 Query String은 무시되고 Origin Server는 “photo.png” 파일만 리턴한다. 원본 컨텐츠가 바뀌었을 경우, 원본 컨텐츠의 파일명은 변환할 필요가 없이 똑같이 “photo.png” 파일로 저장을 하되 HTML의 참조명을 /image/photo.png?version=2.0 으로만 변경해주면 CloudFront 입장에서 리소스의 이름이 아까와 다른 이름이기 때문에 캐쉬에서 찾지 못하고 다시 Origin Server로 요청하게 된다.)
  - Query String을 버전명으로 사용하기위해서는 CloudFront 설정에서 Query String by pass 기능을 On 해주어야 함

• 1번 부분은 리소스 파일명을 정의
• 2-3번 부분은 Query String을 정의하는 부분으로 Origin Server로 전달되는 Query String이다.
• 4번은 Policy로 접근 가능 정책 {IP 주소, 접근 가능 기간} 을 JSON으로 정의한 후에 Encoding한 String이다.
• 5번은 HMCA과 유사하게 이 URL이 변조되는 것을 막기 위해서 URL에 대한 Signature를 Base64 Encoding을 이용하여 생성해서 붙인 부분 (일종의 Hash 값으로 URL에 대한 Hash이고 URL 변조되면 이 Hash 값이 맞지 않음)
• 6번은 Key로 AWS CloudFront를 사용하기 위해서 발급된 Key