클라우드 56 일차

DDD

- 보편언어 : 도메인에 대한 어휘를 기획자, 개발자, 분석가들이 공통적으로 이해할 수 있도록 정의

- 모델주도 설계 : 분석/설계/구현의 모든 단계를 관통하는 하나의 모델을 유지

- 도메인 주도 설계 : 소프트웨어가 복잡한 이유는 도메인이 복잡하기 때문.

- 도메인 : 영역, 집합/ 비즈니스 Domain을 의미

- 전략적 설계

1. 비즈니스의 상황에 맞게 설계

2. 모든 Context를 이벤트 스토밍을 통해 공유

3. 각 Context를 그룹핑(Bounded Context)

4. 컨텍스트 매핑을 통해 Bounded context 간의 관계를 정의

=> 전략적 설계의 결과물 : 도메인 모델(서비스를 추상화할 설계도, 분리 & 연결)

 

- 전술적 설계

1. 더 상세한 부분(Bounded Context 내부) 모델링

2. Model driven design

3. Aggregate pattern

4. 계층형 아키텍처를 통한 도메인 모델 분리

5. 도메인 이벤트를 통해 도메인을 보다 명확히 모델링

 

---

DDD 핵심만 빠르게 이해하기 :: 온달의 해피클라우드(Happy@Cloud) (tistory.com)

DDD 핵심만 빠르게 이해하기

step1. Domain Event 정의

1. 이벤트에서 발생할 수 있는 모든 상황을 작성하기 -> 각자 생각나는거 다 적고 중복 없애기

2. 이벤트가 발생하는 시간 순서대로 붙인다. 동시 수행되는 이벤트는 수직으로 붙임

3. 비즈니스 용어로 말해야만 한다.

위와같이 포스트 잇으로 작성한다.

 

step2. 프로세스 그룹핑

1. 동일한 비즈니스 주제로 이벤트들을 묶어버린다.(위의 이미지도 그룹핑 한거다)

 

step3. Command 정의

1. 사용자의 행위의 결과를 command라고 생각한다.

 

step4. Trigger 정의

1. 행위자 정의

2. Event 발생과 관련된 외부 시스템이 있다면 Event의 우측 상단에 겹쳐서 붙인다.

step 5. Aggregate 정의

1. CMD 수행을 위해 CRUD 해야 하는 데이터 객체 정의

2. CMD를 수행해서 Event를 발생시키려면 어떤 데이터가 필요한지 각 CMD와 Event 사이의 위에 적기

step6. Bounded Context 정의

1. 비즈니스 상의 이벤트들을 묶는다.

2. Context를 묶어서 Bounded 시킨다.

 

그룹핑을 하기 위해서 각각의 이벤트들에 대한 정보를 뽑아냈다.

 

위의 3가지 카테고리 사이의 관계가 있다.

 

step7. Context Map 작성

1. Bounded Context 간의 관계를 도식화하자.

 

각각을 따로 분리해서 구현하고 나중에 연결을 해주면 된다.

 

MSA도 분리된 작은 서비스들을 하나의 서비스로 만들자는 것이었다.

 

---

 

IaC

IaC, 형상관리, 이미지 빌드

 

IaC (Infrastructure as Code)

네트워크, 로드밸런서, 저장소, 서버 등의 인프라 자원을 수동 설정이 아닌 코드를 이용하여 프로비저닝하고 관리하는 것 대표적인 IaC 도구로 Terraform, CloudFormation, Pulumi, Azure ARM Template 등이 있음

Terraform을 써보자

 

형상 관리 (Configuration Management)

서버 운영체제 상에 필요한 소프트웨어를 설치하고 원하는 설정으로 관리하는 것 Configuration as Code 라고도 불림 대표적인 형상 관리 도구로 Ansible, Puppet, Chef, Salt Stack 등이 있음

Ansible을 써보자

IaC vs 형상 관리

IaC와 형상관리

 

LinkedIn

Q&A: Configuration Management Tools vs Infrastructure as Code

인프라 관리 문제 => 테라폼

형상 관리 => 앤서블

 

각각의 문제 도메인을 쪼개고 각각의 문제를 효율적으로 해결할 수 이는 기술 스택을 가져가기

 

이미지 빌드 (Image Build)

AWS EC2, VMware, VirtualBox, Docker 등 여러 플랫폼에서 재사용 가능한 머신 이미지를 빌드하는 것 대표적인 이미지 빌더로 패커(Packer - 여러 플랫폼 지원), AWS EC2 Image Builder(AMI 이미지를 읽어들여서 구동) 등이 있음

코드로 관리한다는 것 (... as Code)

사람이 수동으로 처리하는 것을 코드로 작성하여 관리

-> 휴먼 에러 방지 / 재사용성 / 일관성

 

소프트웨어 개발처럼 Git과 같은 버전 관리 시스템(VCS) 활용 가능

-> 코드 리뷰(PR -> Reviewer 승인 -> apply) / 변경내용 추적(Audit log같은 거 추적) / 버전 관리 / 협업

 

선언형 설정(Declarative Configuration)과 절차형 설정(Imperative Configuration)의 차이

-> 선언형 설정(Terraform) : Desired State, 원하는 상태를 선언적으로 정의 -> 그 상태에 맞게 적용해줌

-> 절차형 설정(Ansible, Shell Script) : 순차적으로 명령어를 수행. (패키지 업데이트 -> nginx 설치 -> 방화벽 켜기)

 

 

Install Terraform | Terraform - HashiCorp Learn

Install Terraform | Terraform - HashiCorp Learn

위의 사이트에서 terraform을 설치하자

```

sudo yum install -y yum-utils

sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

sudo yum -y install terraform

terraform -install-autocomplete

```

 

이렇게 해야지  terraform을 치고 서브 명령어가 자동완성된다.

 

```

vi ~/.terraformrc

```

 

CLI Configuration | Terraform by HashiCorp

CLI Configuration | Terraform by HashiCorp

위의 페이지에서 terraform을 설정할 수 있다.

 

이중에서도 plugin_cache_dir을 설정해주자.

 

```

mkdir ~/.terraform.d/plugin-cache

```

각 워크스페이스를 관리하기 위한  terraform provider 나 module을 다운받을 수 있게 된다. 이걸 설정안하면 해당 워크 스페이스 안에 해당 파일들을 설치하게 되는데 나중에 플러그인들의 캐시가 증가함에 따라서 관리가 어려워진다.

그래서 동일 플러그인은 한번만 설치하도록 해서 공간을 아낄 수 있게 된다.

 

---

 

패커를 설치해보자

 

 

Downloads | Packer by HashiCorp

Downloads | Packer by HashiCorp

sudo yum install -y yum-utils

sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

sudo yum -y install packer

```

packer -autocomplete-install

```

ansible 설치

```

yum install -y epel-release

yum install -y ansible

ansible --version

```

 

Terraform 사용하기

HCL(... YAML가 비슷)

terraform plan

terraform apply

 

테라폼 레지스트리와 테라폼 다큐먼트 문서는 앞으로도 줄곧 보게 될 것이다.

Terraform Registry

Terraform Registry

테라폼 프로바이더는 AWS, GCP, AZURE, K8s와 같은 서비스 프로바이더라고 생각하면 된다.

테라폼 모듈은 인프라 리소스의 그룹/템플릿 예를들어 openvpn을 AWS EC2에 운용함에 있어서  여러가지 리소스가 들어가게 된다. 이것들을 모듈로 묶으면 openvpn 이 되고 여러개로 재사용함에 있어서 찍어낼 수 있게 된다.

 

그래서 테라폼 프로바이더를 검색해서 사용할 수 있게 된다.

 

What is Terraform | Terraform by HashiCorp

What is Terraform | Terraform by HashiCorp

Overview - Configuration Language | Terraform by HashiCorp

Overview - Configuration Language | Terraform by HashiCorp

HCL 문법인 Configuration 부분을 가장 많이 사용하게 될 것이다.

 

협업을 위해 Terraform Cloud나 atlassian를 사용할 수 있다.

 

Write/Plan/Apply

 

---

 

HCL 문법으로 Terraform을 다루어보자.

 

[ 테라폼 워크스페이스 생성 ]

워크스페이스 : 하나의 프로젝트 단위. 처음에는 그 규모가 작지만 회사 커짐에 따라서 워크스페이스 관리해야함.

 

infra -> network/accout/domain/service a/service b 등으로 인프라룰 구분하기 시작함.

테라폼은 인프라를 관리할때 변경사항을 추적하게 된다. 이걸 추적하기 위한 목적으로 상태관리하게 된다. .terraform.tfstate를 생성하게 됨. 워크스페이스 단위로 생성해서 관리하게 된다.

 

---

 

Write-Plan-Apply 워크플로우 실습

 

테라폼 워크스페이스 리소스 변경 및 제거

 

```

mkdir 0325

cd 0325

vi main.tf  # 테라폼은 tf로 끝난다.

```

Browse Providers | Terraform Registry

Terraform Registry

시작하기전에 테라폼 프로바이더를 결정해야한다.

 

이중에서 local을 사용하자

 

Documentation 탭으로 와서 USE PROVIDER을 클릭하면 두가지 설정이 나온다.

 

프로바이더를 사용하기 위한 설정들이 보인다.

terraform안에서는 테라폼 버전을 명시한다. 명시 안하면 최신버전을 사용한다.

 

provider local 설정만 가지고 와서 사용해보자

 

리소스는 로컬 프로바이더를 사용해서 관리할 수 있는 인프라 리소스이다.

데이터 소스는 인프라 리소스들을 관리할때 데이터 참조할 필요가 있을 때 쓰는 데이터 소스이다.

 

리소스는 새로운 리소스를 만드는 용도

데이터는 데이터를 쓰는 용도

 

라고 생각하면 된다.

 

provider "local" {
  # Configuration options
}
resource "local_file" "foo" {
    filename = "${path.module}/foo.txt"
    content  = "Hello World!"
}

 

${path.module} 부분은 테라폼에서 string interpolation이라고 한다. HCL에서 제공하는 변수나 컨텍스트에 접근해서 값을 가져오기 위한 목적이다.

 

path.module은 해당 파일이 위치한 디렉토리 경로이다. 그래서 main.tf 경로의 foo.txt 파일을 Hello, World라는 컨텐츠를 가지고 생성하겠다는 의미이다.

 

```

terraform init

```

 

 

이 상태에서 보면 terraform 폴더와 파일을 볼 수 있다.

.terraform 안에는 main.tf안에 명시된 모듈, 캐시, 데이터들을 provider안에 저장하게 된다.

.terraform.lock.hcl은 팀에서 협업하거나 CI/CD  파이프라인 용도이다.

 

해당 워크스페이스에서 사용하는 프로바이더들의 목록이 보이는데 해시섬과 버전을 보고 각각의 작업자가 동일한 환경에서 동일작업을 위해서 사용된다.

 

```

alias tf=terraform

```

```

terraform plan

```

우리가 작성한  main.tf 가 어떤 변경사항을 불러오는지 확인할 수 있다.

위와같이 작성되어 있어서 local_file.foo가 생성된것을 확인할 수 있다.

 

```

terraform apply

```

foo.txt와 tfstate 파일이 생긴것을 확인할 수 있다.

 

foo.txt 안에서는 Hello, World를 확인할 수 있다.

 

tfstate는 리소스의 상태를 확인할 수 잇다.

이걸 통해서 나중에 main.tf를 변경하고 적용할때 diff 결과를 좀더 명확하게 볼 수 있다.

 

local_file data source도 지원해준다.

이건 local filesystem 으로부터 파일 내용물을 읽어들이는 데이터 소스이다.

 

data라는 지시어로 정의하게 된다.

 

bar.txt 파일이 없어서 그렇다.

 

 

로컬에 파일을 만들고 실행시키어보자

 

그러면 정상적으로 수행된다.

 

이렇게 읽어들인 데이터를 보려면 output을 사용해서 출력을하자

 

위와같이 output을 정의해주어서 데이터를 가져와 출력해보자.

 

인프라 변경은 없는데 outrput이 변경되어 object가 생성된 것을 확인할 수 있다.

 

---

 

aws provider 다루기

provider를 설정해주었다. 이건 리전과 연결이 된다.

 

---

 

문제는 이걸 이용하기 위해서는  aws 사용자 인증 설정을 해주어야 하기 때문에 그걸 먼저해주자

 

ec2에 들어가서 키 페어를 먼저 생성해주자 이렇게하면 aws를 cli로 다룰 수 있게 된다.

 

AWS CLI 도구 설치 및 사용해보자

 

AWS CLI는 AWS 관리를 위한 명령형 도구이다.

```

yum install -y awscli

```

 

자격증명을 위해 AWS Access Key ID가 필요하다.

 

AWS CLI 자격증명 설정 우선순위(순서가 중요)

- CLI 명령어 옵션

- 환경변수

- CLI 자격증명 파일 ~/.aws/credentials

- *CLI 설정 파일 ~/.aws/config

했는데 에러가 떴다. 알고보니 내 현재시간이 안맞는다고 한다. ntp를 이용해서 다시 맞추어주어야 한다.

php - AWS SDK Error - Signature not yet current - Stack Overflow

AWS SDK Error - Signature not yet current

CentOS 7 / ntp로 시간 동기화 하는 방법 – MANUAL FACTORY

CentOS 7 / ntp로 시간 동기화 하는 방법

ntp를 가동시키니 

 

 

- 컨테이너 자격증명(ECS의 경우)

- *인스턴스 프로파일 자격증명 (EC2의 경우)

```

aws sts get-caller-identity

```

정상적으로 뜨는 것을 확인할 수 있다.

 

```

aws ec2 describe-key-pairs --region ap-northeast-1

```

하니까 우리가 이전에 접속했던 인스턴스에 대해서 key-pair 정보가 나온다.

 

이걸 --region을 매번 붙이지 않기 위해 aws config 파일을 수정해주자

```

vi ~/.aws/config

```

AWS CLI 사용자 프로파일 설정

=> 여러 aws 자격증명해주기

사용하기 위해서는 AWS-PROFILE 혹은 --profile을 이용해서 타 계정 사용가능

---

 

다시 테라폼을 다루어보자

테라폼을 수정했기 때문에 tf init을 새로 해주어야 한다.

 

aws vpc가 새로 생긴것을 확인할 수 있다.

 

tf apply로 VPC가 어떻게 바뀌었는지 확인해보자

 

놀랍게도 vpc 한대가 더 추가로 생성되었다.

 

output을 추가하고 apply해보자

 

vpc_foo가 추가되었다.

 

이번에는 기존에 있던것을 바꾸어보자

 

foo라는 vpc에 Name tag가 추가된다.

 

Name 태그가 추가된것을 확인할 수 있다.

 

이번에는 ip 대역을 바꾸어 버려보자

 

cidr_block은 aws에서 변경가능한 객체가 아니기 때문에 기존 객체를 삭제하고 새로 만들겠다는 이야기이다.

 

객체가 바뀐것을 확인할 수 있다. 그렇기 때문에 가급적 cidr은 막 바꾸면 안된다.

aws_vpc | Resources | hashicorp/aws | Terraform Registry

Terraform Registry

 

이번에는 이걸 사용해보자

 

끝단에 위와같이 붙여주고 apply 해보자

 

출력결과를 보면 위와같이 모든 vpc 들이 나오는 것을 확인할 수 있다.

 

만든것을 다 지워보자

 

```

tf destroy

```

 

우리가 만들었던 VPC가 삭제되었다.

 

---

 

테라폼 HCL 문법

Overview - Configuration Language | Terraform by HashiCorp

Overview - Configuration Language | Terraform by HashiCorp

BLOCK TYPE에 따라서 BLOCK LABEL의 수가 달라지게 된다.

 

resource는 첫번째로 resource의 종류고 두번째는 이름을 받게 된다.

블론을 열고나서는 terraform block내에 인자값을 할당하게 된다.

 

한마디로 이건 변수값이라고 보면 된다.

 

.tf 파일 확장명을 써서 HCL 파일을 작성하면 되고 JSON으로 짜도 되기도 한다.

 

주의할 점은 init -> plan -> apply 하면 .tf 와 .tf.json을 찾는데 하위 디렉토리는 찾지 않는다. 그래서 하위폴더내에 tf 파일이 들어가 있다면 탐색이 안된다.

 

UTF-8 필수이고 운영체제에 따라서 개행문자가 다르다.(unix : LF. / win : CRLF) 그래서 서로 다른곳에서 작업하다가 가져오면 파일이 꺠진다. 하지만 가급적 유닉스 스타일로 이걸 처리해주자.

 

tf를 포함한 폴더를 디렉토리 또는 모듈이라고 부르기도 한다.

 

모듈에도 root module과 child module로 존재할 수 있다.

사용하는 시기에 따라서 모듈의 형태가 달라진다.

 

대충 위와같이 한 디렉토리 내에서 먼저 시작한게 root module이 된다.

 

block의 레이블을 작성할때 레이블의 값을 identifier이라고 부른다. 레이블을 구성할 수 있는 문자에 제약사항이 존재한다. alpha letters, digits, underscores, hyphens가능/숫자 금지

 

모든 주석을 허용한다.

 

indent two space이다. tab쓰지마라

블록 내에 여러 성분을 넣을때는 위와같이 하이픈을 기준으로 보기 깔끔하게 정렬해주자

logical 한 그룹으로 끊어서 정의를 하는데 argument들을 논리적인 그룹으로 만들어서 각각의 그룹을 공백으로 구분해주자.

 

resource를 사용할때 meta-argument들을 사용할 것인데 각각의 아규먼트 별로 머리와 꼬리중 한곳에 놓으라는 convention이 있다. count나 forEach는 머리에 lifecycle, dependson은 꼬리를 선호한다.

 

다행히도 자동 포맷팅 기능도 지원해준다.

 

```

terraform fmt -diff # 이걸 사용하면 자동 포맷팅, 차이점 보여준다.

```

 

terraform

provider

locals

variable

resource

module

data

output

 

---

 

테라폼 HCL resource와 data

aws_instance | Resources | hashicorp/aws | Terraform Registry

Terraform Registry

먼저 ec2를 띄우기 위한 문서를 확인해보자

 

main.tf에 위와같이 복붙해주자.

 

resource 블록구조를 보면

aws_instance라는 resource 블록 정의이다.

naming은 web이라고 붙여주었다.

 

ami는 직접 아마존에 가야지 해당 이미지의 id를 확인할 수 있다.

 

provider "aws" {
  region = "ap-northeast-2"
}
resource "aws_instance" "ubuntu" {
  ami           = "ami-0454bb2fefc7de534"
  instance_type = "t2.micro"

  tags = {
    Name = "fastcampus-ubuntu"
  }
}

terraform init

terraform apply

 

aws에 인스턴스가 만들어지는 중이다.

 

나갈때 꼭 삭제해주자

 

aws_ami | Data Sources | hashicorp/aws | Terraform Registry

Terraform Registry

 

위 문서 생까고 원래 쓰던 ec2_instance 문서에서 data부분을 긁어왔다.

 

most_recent는 다음 검색결과가 여러 ami 결과중 가장 최신의 ami를 가져오겠다는 말이다.

 

owners는 Canonical이라고 적혀있는데 unbuntu를 만든회사라는 의미이다.

 

마지막으로 ami를 변수에서 긁어오겠다는 것을 작성해주어야 만들수가 있다.

 

```

terraform apply

```

 

이렇게하면 기존의 인스턴스를 부수고 새로 만들어진다.

 

 

테라폼 HCL module

Tedilabs (github.com)

Tedilabs

위에서 terraform 관련 레포지토리들을 확인할 수 있을 것이다.

 

tedilabs/terraform-aws-network: 🌳 A sustainable Terraform Package which creates Network resources on AWS (github.com)

GitHub - tedilabs/terraform-aws-network: 🌳 A sustainable Terraform Package which creates Network resources on AWS

그중에서도 위의 저장소에가서 vpc 부분을 확인해보자