섹션 18 - Cloud Formation
> CloudFormation 은 그림보단 YML 이 매우 많이 나온다. YML 로 선언하고 AWS 에게 맡기는 영역이기 때문. CloudFormation 에게 명령하기 위해 어떤 것들을 설정할 수 있는지, 어떤 방식으로 YML 을 작성할 수 있는지를 확인하며 되겠다
<197강 개요>
<IaC란>
> 강사님이 가장 좋아하는 리소스 중 하나라고 함. ㅈㄴ 좋아하는 듯
> IaC 서비스 -> 구글 검색시 다음과 같이 나옴 : "코드형 인프라스트럭처는 물리적 하드웨어 구성이나 인터페이스 구성 도구가 아닌 기계가 읽을 수 있는 정의 파일들을 통한 컴퓨터 데이터 센터의 관리 및 프로비저닝 과정" (인프라 설계를 코드로 한다 이거임)
> 지금까지 SU 을 위해 수동 작업을 엄청 많이했는데, 이런건 다른 리젼, 다른 계정에 복제하기도 어려움
> 사고로 다 삭제될 경우 다시 다 만들어야 하는 것도 어려움
> 그래서 우리가 제어하는 인프라가 Code 형태로 있는 것 (Code 정의서) > 새로운 IT 업계의 유행?
> 이 코드를 사용해서 우리는 우리의 인프라를 생성 / 수정 / 삭제 할 수 있는 것
<CloudFormation>
> AWS 의 IaC 서비스로, AWS 인프라를 설계하는 것을 선언적 방식으로 작성하는 것
>> ex : Security Group 필요함, EC2 두개가 이걸 사용할 것임, EIP 필요함, S3 버킷 해주셈, LB 필요함
> 이 모든 구성들을 적절한 순서 & 정확한 구성대로 생성해주는 것을 CloudFormation 이 지원해줌
장점
1) IaC 의 장점 : manually 제어하는 리소스가 없으므로 관리가 쉬움, 형상 관리 가능 (git 따위를 이용)
2) 인프라에 대한 것들이 Code 를 통해 리뷰가 가능
3) CloudFormation 자체는 무료이지만, 너가 생성하는 리소스들은 아님. 따라서, CloudFormation 내부에서 너의 스택들이 얼마나 cost 하는지 쉽게 확인가능
4) CloudFormation 템플렛으로 리소스 예상 비용 추산 가능
5) 비용 절감 전략 : 개발 환경에서, 저녁 5시에 리소스 삭제 -> 오전 8시에 재생성과 같은 자동화 방식을 안전하게 이용해서 예산을 절감할 수 있다
6) 생산성 : 원하는 만큼 즉흥적으로 인프라를 삭제하고, 재생성 할 수 있음 / 템플렛에 대해 Diagram 자동으로 그려줘서 쉽게 리뷰 가능 / 선언적 프로그래밍으로, ordering, orchestration 순서를 CloudFormation 이 알아서 해준다고 함.. (?)
7) Separation of Concern 도 존재 > many Staks 를 설정할 수 있음 (Beanstalk 에서도 Env 를 할 때마다 CloudFormation 이 Template 을 생성했던 것)
>> Network / VPC / Subnet 을 제어하는 VPC Stack, Network Stack
>> 배포할 앱에 대한 정보를 주는 Application Stack
8) 이미 범용적으로 사용되는 템플렛들이 있으므로, 우리들의 템플렛을 만들기 위해 시간을 많이 쓸 필요 없음 (구성하는 방법 정도만 알아두면 됨)
9) 문서도 엄청 방대하지만 정보들을 얻을 수 있음
<CloudFormation 의 동작 규칙들?>
> Behind the scene 으로 S3 에 Template 이 업로드가 되는데, 이를 CloudFormation 에서 가져오게 된다
> 이는 나중에 나오겠지만, 한번 업로드한 template 을 수정할 수 없는 이유이다. 새 버전을 업로드 해야함 (CloudFormation 이 두 버전 사이의 차이점을 파악해서 적용해줌)
> Stack 들은 이름을 통해 구분된다
> Stack 을 삭제하면, 해당 Stack 을 통해서 CloudFormation 이 생성한 모~든 리소스들을 다 삭제한다 (장점이기도 함. 생성한 것들을 한 클릭으로 모두 확실하게 삭제할 수 있다는 점)
<CloudFormation Template 배포하기>
수동적인 방법
> CloudFormation Designer 에서 template 을 직접 수정
> 콘솔에 매개변수를 입력하는 방식 사용
자동화된 방법
> 텍스트 에디터를 사용해 YML 파일에서 템플릿을 수정
> AWS CLI 를 사용해서 템플렛을 배포할 수 있다
> 모든 플로우를 완전히 자동화하고 싶을 때 권장되는 방법
> 솔직히 두 방법 다 뭔소린지 모르겠음.. 암튼 후자 방법을 배우려는 것 같은디?
<CloudFormation Building Block>
> 빌딩블록이란 구글링 결과, 한 시스템을 설계하는 과정에서 리소스를 구성하는 각각의 구성 요소를 서로 독립된 모듈로써 구성하는 방법이라고함??
> 이 섹션에서 블록 설계에 대해서 많이 배운다고 하는데, 위에 뜻이 맞는듯? 그냥 설계하는 방법이라고 일단 생각하자.
> Template 을 구성하는 요소들은 다음과 같아
>> Resources (필수) : template 에 선언된 원하는 AWS 리소스 ex: EC2, EIP, SG, LB 등
>> Parameter : template 에 요청할 수 있는 동적 입력값
>> Mapping : Template 의 정적 변수
>> Outputs : Template 의 결과로 어떤 것들을 Export 할 수 있고, 다른 Template 에서 이를 참조해갈 수 있는 방식 (template return 같은 것)
>> Conditionals : Template 내 IF 문으로, 리소스 생성을 perform 하기 위한 제시된 조건들을 말한다
>> Metadata
> Template Support 기능 들도 존재 (Helper 라 부름)
>> References : 템플렛 내에서 참조/링크 등이 가능
>> Functions : 데이터 변환 등의 함수를 사용할 수 있다.
<이번 섹션에 대해서>
> CloudFormation 에 대해서만 완벽히 배우고 이해하는데는 3시간 이상 무조건 소요된다
> 이 섹션은 어쨌든 최대한 CloudFormation 의 이해를 돕기 위해 만들어 졌지만, 원리에 조긐 더 집중하고 실습은 살짝 적다고 느낄 수 있음 (너무 깊은 원리도 빠져있긴 함)
> 시험에 대한 문제는 다 커버할 수 있을 수준
> CloudFormation 을 쓰라는 이런걸 시험에서 ㅛ구하진 않고, A,B,C 기능, 그런 상황을 위해선 CloudFormation 을 어떻게 활용해야 하냐 이런거 물어봄. 그래도 CloudFormatino 을 읽고 이해할 수 있는 능력은 필요함!
------------------------------------------ 구체적으로 살펴보기 전에 대충 이런식이구나를 느껴보는 실습
<198강 - 스택 생성 실습, 199 강 다음에 원래 198강 순서임>
EC2 스택 예시
>1 번 yml (이미 Stack 으로 배포해놓은 상태라고 보는듯 - 199 강에서 해놓은 것)
Resources:
MyInstance:
Type: AWS::EC2::Instance
Properites: # 인스턴스 적용 속성
AvailabilityZone: ap-northeast-2
ImageId: ami-a4c7edb2 # AMI ID 도 설정, 특정AZ 에서 해야하는 이유 # 예전에 공부했던건데 기억이 안난다 ㅋㅋㅋ
InstanceType: t2.micro
> 2번쨰 yml 에서는 Parameter 도 추가, EC2 에 SG 추가, EIP, SSH SG 추가 등등을 명시했음 (보고싶으면 나중에 Pause 하고 적자)
> 위에 배포했던걸 업그레이드 배포하기 위해서 작성하는 것임
Parameters:
SecurityGroupDescription: # 내가 이름 짓는 변수 Key
Description: Security Group Desc
Type: String
Resources: # 필수
MyInstance: # 내가 짓는 리소스 이름
Type: AWS::EC2::Instance
Properties:
AvailabilityZone: us-east-1a
ImageId: ami-a4c7edb2
InstanceType: t2.micro
SecurityGroups: # 둘다 내가 아래 선언한 자원들을 참조하는 것을 알 수 있다
- !Ref SSHSecurityGroup
- !Ref ServerSecurityGroup
MyEIP:
Type: AWS::EC2::EIP
Properties:
InstanceId: !Ref MyInstance
SSHSecurityGroup:
Type: AWS:EC2:SecurityGroup
Properties:
GroupDescription: Enable SSH access via port 22
SecurityGroupIngress:
- CidrIp: 0.0.0.0/0
FromPort: 22
IpProtocol: tcp
ToPort: 22
SSHSecurityGroup:
Type: AWS:EC2:SecurityGroup
Properties:
GroupDescription: !Ref SecurityGroupDescription
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 192.168.1.1/32
> 1 > 2 로 업데이트 하는 과정을 실습할 것임
> CloudFormation > Stacks > Update Stack 으로 이동
> Replace Template 선택 > Upload file 에서 2번째 yml 선택
> AWS 는 2번째 yml 을 인지해서, 템플렛 파일에 있는 SecurityGroupDescription Key 에 Value 를 추가하라고 함
> 나머지는 다 기본으로 뒀다. Template URL 도 확인했고, 마지막 Review 를 보면 Change Set Preview 를 확인할 수 있음 (이게 문제에 나오기도 하네 ㅅㅂ ㅋㅋ)
> 이게 1>2 로 업그레이드 ㅏ면서 변경, 추가 되어야 하는 것들을 CloudFomration 에서 인지한 후 한번 보여주는 것이다.
>> 이번 예제에서 보면 EC2 가 교체되어야 함이 명시되어 있다. (Replacement : True) > EIP 떄문일까?
>>이번 Stack 에서 할 일을 정리 후 보여주는 느낌
> 변경이 만족한다면 Update Stack 누르면 된다. > 아까 그 Stack 을 보면 Events 에서 stack 을 처리하고 있는 모습을 볼 수 있다. (Stack 이 새로 생기는게 아님)
>> 변경되는 상황을 지켜보면 EC2 를 만들었는데도 EIP 를 추가하지 않고 다른것 부터 진행하고 있다
>> CloudFormation 은 우리가 지정하지 않았음에도, 리소스들을 연동시키면서 어떤 순서대로 진행시켜야 하는지 스스로 판단을 한 후 진행한다 (아마 SG 를 추가, EC2 인스턴스 업데이트, EIP 추가 의 과정으로 진행할 예정이다)
>> 다 완료되면 예전 EC2 삭제도 진행한다
> 이젠 생성한 것들을 좀 확인해본다. Stack 에 Resources 를 보면 이 Stack 이 생성에 관여하여 종속되어 있는 리소스들을 확인할 수 있는데, 거기에 EIP, Instance, SSH SG, Server SG 가 포함되어 있다.
> 이 때, SSH SG 로 이동하면 아까 내가 Parameter 로 입력했떤 (SecurityGroupDescription) 의 Value 가 Description 에 적혀있는 것을 확인할 수 있다.
> 자원을 삭제하려면 해당 리소스로 직접 이동 후 삭제해도 된다. 근데 그렇게 하면 STack 에서 만든 다른 자원들은 남아있다. (Ec2 를 직접 삭제해도, EIP, SG 들이 남아있음)
>> 따라서 Stack 자체를 삭제하는걸 권장한다 (물론 충분히 확인 후에) > Stack 삭제 후 Event List 를 또 보면 어떤 순서대로 삭제해야 하는지 스스로 스케줄링을 한 다음에, 순서대로 진행하게 된다.
> CloudFormation 의 힘을 잘 확인할 수 있었다 > Cloud Formation 의 리소스 생성 / 업데이트 / 삭제 의 사이클을 이해하는 것이 중요
> 좀 익숙해지면 매우 편리해진다고 함 (직접 하던 때로 못돌아간다고 함)
------------------------------------------
<199강 - CloudFormation 업데이트 및 스택 직접 삭제> - 이거 198강이랑 강의 순서 바뀐 것 같음 ㅋㅋㅋㅋㅋㅋ
> 참고로 순서상 198강이 이거 다음이다.
> 이제 템플렛을 만들어보자. 먼저 만들려는걸 설계해본다
> EIP, SG 추가할 예정.
> 참고로 계속 말하지만 Stack 에 Resources 누르면 얘가 종속하고 있는 AWS 리소스들을 확인할 수 있고, Template 을 누르면 전체 json 을 확인할 수 있으며, View in Designer 를 통해서 UI 친화적이게 확인할 수 있다
>> EBstalk 를 통해 만든거 확인하면 Prod EBStaclk 할 때 얼마나 많은걸 만들었는지 확인할 수 있다.
> 실습 같이 할거면 US East 1 Northern Virginia 로 이동한다 (이번에 사용할 템플렛은 여기서 사용가능한 것이기 때문? AZ 별로 안되는 곳들도 있는건가 - 확실하게 하기 위해서라곤 하는데..)
> 스택 생성 > 새 리소스 사용 (Standard) 선택 > json 파일 업로드 방식으로 하시는데, 집에가서 직접 실습해봐도 될 듯
> Stack name - First Stack 으로 지정, Param 없음, Permission 추가할 것 없음, 다른 옵션 다 시험 범위 밖임.
> Review 로 이동, 스택 생성 진행, Event 탭을 보면 Create_in_progress 가 뜸, Instance 생성이 진행중임
> 인스턴스로 이동해보면 인스턴스가 생성되어있고, EC2 인스턴스 태그에 CF 정보도 태깅되어 있다 (CF 에서 태그를 통해 Control 하는 듯? K8s 처럼?) (Stack ARN 이 id 로 태그매핑되어 있음)
> 이제 하나 생성하는게 yml 이였으므로, Stack 이 완료되었다고 뜬다.
> 디자이너를 보면 Instance 하나가 그려져 있는 것을 볼 수 있음 > 이 모든것을 관리할 수 있는 것이 IaC 의 힘!
------------------------------------------
<200 강 - CloudFormation YML 살펴보기> - 그냥 당연히 알던 강의
> CF 는 YML / JSON 지원 (JSON 은 쓰지 않는게 좋다. 최악임. YML 은 매우 좋아서, YML 을 많이 사용한다
> YML 이 뭔지 공식적으로 살펴보는 시간!
> YML 은 Key/Value Pairs 로, 매우 읽기 쉬운 구조이다
> YML 에서는 '|' 문자를 사용하여 멀티 라인 문자열(?) 을 지원한다
> YML 에 더 있을 수 있는 구조는
>> 또다른 Key/Value Pair 을 포함하는 객체 즉, Nested Objects (Indent 로 구분한다)
>> Array 도 지원 (Value 에 '-' 를 표시하면 Array 객체란 뜻) (객체 Array 일 수도 있고, String Array 일 수도 있고 그렇다)
> CloudFormation 에서 방금 사용한 것을 확인해보면, YML 을 통한 Nested Objects, Key/value Pairs 들을 확인할 수 있다
> 두번째 배포에 사용한 것을 확인하면, - 가 있기 때문에 List 까지 있다는 것을 확인할 수 있다
-----------
<201강 - CF Resources>
Parameters:
SecurityGroupDescription: # 내가 이름 짓는 변수 Key
Description: Security Group Desc
Type: String
Resources: # 필수
MyInstance: # 내가 짓는 리소스 이름
Type: AWS::EC2::Instance
Properties:
AvailabilityZone: us-east-1a
ImageId: ami-a4c7edb2
InstanceType: t2.micro
SecurityGroups: # 둘다 내가 아래 선언한 자원들을 참조하는 것을 알 수 있다
- !Ref SSHSecurityGroup
- !Ref ServerSecurityGroup
MyEIP:
Type: AWS::EC2::EIP
Properties:
InstanceId: !Ref MyInstance
SSHSecurityGroup:
Type: AWS:EC2:SecurityGroup
Properties:
GroupDescription: Enable SSH access via port 22
SecurityGroupIngress:
- CidrIp: 0.0.0.0/0
FromPort: 22
IpProtocol: tcp
ToPort: 22
SSHSecurityGroup:
Type: AWS:EC2:SecurityGroup
Properties:
GroupDescription: !Ref SecurityGroupDescription
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 0.0.0.0/0
- IpProtocol: tcp
FromPort: 80
ToPort: 80
CidrIp: 192.168.1.1/32
> 위에서 예시로 들었던 두번 재 yml 파일인데, 이번 강의에서도 확인하면서 공부해서 보기 편하게 복붙함 ㅇㅇ
> 말했듯이 Resoure 블록은 필수 블록으로, 없다면 Stack 형성이 동작하지 않는다 (Resource 를 명시하려면, Type Key 와 Properties Key 가 함께 묶어서 명시해야 한다)
> 그리고 Custom 한 이름을 Key 로 시작하여 명시해 나가기 시작한다
> AWS 구성 요소를 말한다. (AWS Component 의 동의어) (224 개 이상의 리소스가 있음 ㅋㅋ) > 이거 보면서 아래 예시들의 항목들을 살펴봄
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html
> Resources 들은 선언되고, 서로를 참조할 수 있다 (템플렛 안에서 Ec2 와 SG 를 선언후 연결할 수 있음)
> Resoure Type 의 identifier 는 다음과 같다 (Type Key 에 Identifier 를 Value 로 적는다)
AWS::{aws-product-name}::{data-type-name}
> 224 개의 AWS 리소스들을 확인할 수 있는 AWS 링크가 있음
> 링크로 보면 정말 많은 리소스들이 있음을 알 수 있다. 반가운 친구들이 있는데, AutoScalingGroup, ScalingPolicy, CodeBuild, CodeDeploy, EC2, EIP 이런게 있음
> EC2 를 하나로 예시로 살펴본다
> AWS::EC2::Instance >> EC2 인스턴스 리소스를 명시한다
> 아래로 내려보면 YML 을 볼 수 있다. 정말 많은 것들을 Customize 할 수 있다.
>> Example: IamInstanceProfie 같은 경우, 이동해서 확인해보면 Not Required, String Type, No Interruption (EC2 제거 후 새로 생성되지 않을 거임), Replacement (기존을 제거하고 새것을 만든다) 이런 설정들을 확인할 수 있다
> 아까 쓴 거에는 AZ, AMI ImageId, InstanceType 을 Property 로 명시해줬음을 기억해볼 수 있다
> 이번엔 EIP 를 또다른 예시로 살펴본다
> AWS::EC2::EIP > 명시할게 훨씬 적긴 함
>> 새로운건, 내가 지정한 또다른 리소스를 참조하고 있다는 것이다 >> InstanceId : !Ref MyInstance (Ref 는 나중에 더 살펴볼 것임)
> 이번엔 SecurityGroup 을 살펴본다
> AWS::EC2::SecurityGroup
> 그 중 SecurityGroupIngress 라는 항목을 살펴보면, 문서를 살펴보면 EC2 Security Group Rule 들의 List 인 점을 알 수 있다
>> 그 List 안에 들어갈 객체 정보들까지 다 확인할 수 있다 (IpProtocol, FromPort, toPort, CidrIp 등) / 이런 네트워크 세팅은 구체적으로 아직 몰라도 되는게 맞겠..? CidrIp 이거? 뭔지 알아야 할 것 같음. 한번 생각해보기
FAQ
1) Dynamic Amount of Resources 생성이 가능한가? 동적인 생성?
>> No. 동적으로 코드를 통해 생성할 수 없다. 생성할 리소스들은 Template 에 정확히 명시되어 있어야 한다
2) Is Every AWS Service Supported? (이거 T/F 문제로 나오려나? ㅋㅋ)
>> No but Almost Everything. 아주 조그마한 것들이 아직 미지원 되지만, 이건 AWS 람다 Custom Resource 기능을 통해서 한다고 함
---------------
<202강 - CF 매개변수>
> AWS CF Template 에 입력값을 제공하는 방식으로, 템플렛 재활용시 중요한 사항임.
> 특정 inputs 들은 미리 결정되어서 넣어질 수 없을 수도 있다 (ex 키페어)
> 매개변수 주입은 매우 유용한 기술, Types (?) 덕분에 잘못 주입되는 것을 어느정도 막아줄 수 있다
> 보안 그룹 지정했던 예시 (위에 사진 있음, 이후에 관련되어서 Value 값 넣으라고 UI 로 안내되었던 부분)
Parameters:
SecurityGroupDescription: # 매개변수 이름
Description: Security Group Desc
Type: String
> 이 CF 리소스의 설정이 나중에 바뀔 가능성이 있는가? -> 있다면 그 설정 정보는 Parameter 로 넣는 것이 좋다 (template reupload 방지)
> 프로그래밍 할 떄 매개변수 장점이랑 똑같은거임 ..
<매개변수 설정 값들>
> Type: String, Number, List, AWS Param 등등
> Description, Constraints, Min/Max Length, Defaults, AllowedValues, AllowedPattern, NoEcho(비밀값) 등등등
> 시험을 위해서는 간단한 것과 String Type 정도만 알면 됨
<매개변수를 리소스가 참조하려면>
> 계속 봤듯이 !Ref 를 활용하며 됨 (가장 템플렛에서 많이 사용되는 함수)
> !Ref 는 매개변수를 참조하는 것 뿐만 아니라, 리소스 자체를 참조, 입력값, 구성 등 다양하게 사용된다
> 우리가 사용했던 복잡한 YML 을 예시로 보면, 위에서 제시한 SecurityGroupDescription 매개변수를 아래 ServerSecurityGroup 에서 참조하고 있는 것을 알 수 있다
>> 참고로 해당 YML 에서는 중간에 리소스를 참조하고 있는 것도 확인할 수 있다
< Pseudo Parameter >
> AWS 제공 매개변수, 언제나 사용될 수 있으며, 기본적으로 활성화되어 있음
> !Ref 해서 그냥 Value 만 쓰면 알아서 들어가는 것들
> 사용하면 AWS 자체적으로 매개변수를 확인해주는 그런 것, 알아서 AccountId, Notification ARN, NoValue, Region 등의 값을 알아서 주입해준다
> AccountID 같은 경우는 생각보다 자주 쓰임
--------
<203강 - CF 매핑>
> CF 템플릿에서의 고정 변수 값. 하드 코딩 되어야 한다
> 서로 다른 Environment (dev/prod) , 다른 Region (AWS Region), 다른 AMI Type 등을 구분지어줘야 할 때 유용하다
> 모든 Value 들은 템플렛 내에 하드코딩 되어 있어야 한다
> 형태 예시: 특정 지역에서 어떤 bit 의 node 를 쓰냐에 따라 다른 ami 를 사용한다
<언제 쓰나?>
> Mapping 으로 구분지어줘야 하고, 그 값을 모두 정확하게 알고 있는 상태, 그리고
> 또한 구분되어야 하는 기준까지 명확하게 알고 있을 때 잘 사용된다
>> ex : Region, AZ, AWS Account, Env (dev vs Prod)
> Parameter 와의 use Case 구분은 나름 명확한데, Parameter 는 원하는 값이 사전에 어떤 값인지 알 수 없을 때 사용하면 된다
<Mapping Value 를 참조하려면?>
> Fn::FindInMap 함수를 사용하면 되며, 조회하려는 Value 는 하기와 같이 지정한다
!FindInMap [MapName, TopLevelKey, SecondLevelKey]
> 예시를 보면, !FindInMap [RegionMap, !Ref "AWS::Region" , 32]
>> 참고하려는 매핑 리소스를 선택, 그 중 첫번째 Key 값을 AWS 지원 Pseudo Param 으로 지정, 두번째 키값을 직접 지정, 원하는 이미지 값을 할당 받을 수 있다
------------------
<204 강 - CF 출력>
> 시험에 매우 자주 나오는 영역!!
> 다른 Stack 에서 import 할 수 있는 Value 들을 output 되도록 선언하는 것, 선택적으로! (다른 CF Template 에서 참조할 수 있다는 것임)
> CF 템플렛을 AWS 콘솔에서 출력을 볼 수도 있고, CLI 를 이용하여 출력값을 검색할 수도 있음
> Use Case : Network CF 를 구성하고, output 으로 VPC ID 와 서브넷 ID 를 변수로 내보낸다 (매우 유용하게 사용할 수 있음)
> 네트워크 영역 전문쪽에서 VPC 와 서브넷의 자체적인 부분을 처리하고, 개발자인 우리는 이 값을 참조하여 구성한다 -> 이런식으로 여러 스택간 협업이 가능
> 해당 스택의 output 을 타 스택이 참조중이라면 해당 스택은 삭제할 수 없음 (알아두기!)
Outputs:
StackSSHSecurityGroup:
Description: The SSH Security Group for our Company
Value: !Ref MyCompanyWideSSHSecurityGroup
Export:
Name: SSHSecurityGroup
> SSH 보안 그룹을 만들었는데,
> 위에 것을 보면 이름이 지정되어 있고, Output 하는 Value 는 같은 템플렛 내 어딘가에서 만들었을 SG 이다. 이 ID 값을 외부 템플렛에 output 으로 제공하는 것
> Export 블록은 선택사항 (맞음..??? 선택사항이 아니라는 거 아님? ㅋㅋㅋㅋㅋ ) Export 를 specify 하지 않으면 Export 하지도 않고 외부에서 import 하지도 못한다고 하는 듯
> Export Value 를 지정하면 "MyCompanyWideSSHSecurityGroup" 이란 리소스의 ID 는 "SSHSecurityGroup" 이란 이름으로 Export 되게 된다 => 유의 : "StackSSHSecurityGroup" 은 뭔가요? 이건 그냥 Output 항목의 이름일 뿐이다!!
<Cross Stack Reference - 다른 스택에서 참조하기>
> Fn::ImportValue 함수를 사용한다
> 위에서 내보낸 StackSSHSecurityGroup 리소스를 참조하려면, 이름으로 내세운 SSHSecurityGroup 의 값을 들고와야 한다
Resources:
MySecureInstance:
Type: AWS::EC2::Instance
Properties:
AvailabilityZone: us-east-1a
ImageId: ami-a4c7edb2
InstanceType: t2.micro
SecurityGroups:
- !ImportValue SSHSecurityGroup
> 사용할 SecurityGroup 이 참조된다. (내부가 아니라 다른 템플렛인거다! 다른 Stack!) - 근데 그 범위는 뭘까? 같은 CloudFormation 안에 있는 내부에서 전역 사용?? 아니면 해당 template 을 import 한다는 뭔가가 있나?
> 참고로 이제 이 템플렛이 삭제되기 전에는 SSHSecurityGroup 을 export 하는 템플렛은 삭제될 수 없다 (FK 관계 같은것)
> 출력 / 내보내기는 굉장히 자주 나옴!! / ex: CF 하나에서 다른 하나로 어떻게 값을 연결하는가? 이 내용과 ImportValue 에 대해 알고 있어야 함
----------------
<205 강 CF Conditions 조건>
> Condition - 리소스의 생성 혹은 output 을 조절/제어하기 위해 사용
> 자유롭게 설정할 수 있나, 일반적인 Use Case 는 아래와 같다
>> Environment (Dev/test/prod)
>> AWS Region
>> Any Parameter Value
> Condition 항목은 다른 컨디션, Parameter Value, Mapping 값 등을 참조할 수 있다
> 예시는 하기와 같다
Conditions:
CreateProdResources: !Equals [ !Ref EnvType, prod ]
> CreateProdResources 가 사용된다면, EnvType 이란 값을 참조할 수 있어야 하고, 그 값은 prod 여야 한다
>> 아마 Envtype 은 Parameter 로 설정된 값이고, 그 값을 참조하고 있는거지 않을까?
> !Equals 는 아니라는 뜻이 아니라 Equals 조건을 쓰는 함수이다 ㅋㅋㅋ
> Fn::And / Equals / If / Not / Or 등의 논리 함수들로 구성할 수 있다
<Condition 을 그럼 어떻게 사용하라는걸까?>
Resources:
MountPoint:
Type: "AWS::EC2::VolumeAttachment"
Condition: CreateProdResources
> MountPoint 라는 이름의 리소스이며, 내가 명시한 Condition 을 통과해야만 동작하게 된다 (Type 아래 보통 위치)
> Condition 은 위와 같이 Resource 에 적용될 수 있으며, 다른 output .. etc 에 모두 적용될 수 있다
> 꽤 고급 내용!
-------------------------
<206강 CF 내장 함수>
> 내장 함수들에 대해서 반드시 알아둘 것들이 있다
> Ref, Fn::GetAtt, Fn::FindInMap, Fn::ImportValue, Fn::Join, Fn::Sub, Condition Fucntionos(Fn::If/Not/Equals ...) 하나씩 살펴보자!!
> 참고로 Condition 에서 사용되는 Inner Function 들은 위에 살짝 설명된 정도로 충분
<Fn::Ref>- ㅈㄴ 중요!!
> 가장 중요한 함수로, 다양한 존재들을 참조할 때 사용된다
>> Parameter -> 참조로 걸어놓으면 param 으로 설정한 값을 Ref 함수가 반환시키면서 그 값을 넣어준다 이거인듯
>> Resources -> 참조로 지정된 리소스의 physical ID 를 반환한다 (ex: EC2 ID)
> YML 에서는 !Ref 로 사용된다
Properties:
VpcID: !Ref MyVPC ## 이렇게 하면 어딘가에 선언된 MyVPC 의 물리적 ID 를 VpcID 에 지정하게 된다
<Fn::GetAtt>
> Attribute 은 생성하는 리소스 어디에나 붙어있는 값들 (메타데이터인가? - ㅇㅇ 리소스의 메타데이터 같은거인듯)
> 너의 리소스의 attribute 을 알려면 documentation 을 확인하는 것이 가장 좋다고 함 (Expose 되는 attribute 들)!!!
> 공식문서의 Template Ref 내 AWS::EC2::Instance 를 확인한다
>> Return Values 를 확인한다 >> Fn::GetAtt 을 확인할 수 있는데, AZ, PrivateDNSName, Public DNSName PrivateIP 등이 Attribute 으로 얻을 수 있는 값들이다
> AZ 를 얻고 싶을 때, EBS Volume 에 넣고 싶음
> AvailabilityZone 에 !GetAtt, EC2Instance.AvailabilityZone 이런식으로 메타데이터? 를 가져올 수 있는 것임!
>> 시험에 매우 자주 나옴!! ex:) 왼쪽 EC2 리소스의 Availability Zone 을 오른쪽 S3 에 넣고 싶은데 어떻게 해야 하나요? 이런 식으로! GetAtt 사용이 답!!
<Fn::FindInMap>
> 항목으로 지정한 Map 을 명시해서 가져올 값의 Key 들을 명시한다 (위에서 나왔음)
> !FindInMap [ MapName, TopLevelKey, SecondLevelKey ]
<Fn::ImportValues>
> 다른 템플렛으로부터 Export 내역이 존재할 경우 사용 가능,
> 근데 나 이거 실사용 모습을 좀 봐야 더 이해가 갈 것 같음, 외부 Template 이 어떤 Template 인지 명시하는게 있음??
<Fn::Join>
> Delimiter(?) 값과 함께 Join 할 값을 명시할 수 있음
!Join [delimiter, [ comma-delimited list of values ] ]
> 그냥 String 값을 delimiter 를 중간중간에 넣어서 섞는거임 (SDK 같은거군)
> !Join [ ":", [a,b,c]] 하면 "a:b:c" 가 탄생, 리소스 이름 적을때 쓸 수도?
> 시험에 이 함수의 output 은 무엇인가? 하는 단순한 문제가 나올 수도 있음!
<Fn::Sub>
> Substitute 의 약자로, String 으로 값들을 대체할 수 있도록 해준다
> Fn::Sub 와 다른 Pseudo Variables or References 들과 합쳐서 사용할 수 있다
> 교체하려는 String 내부에는 ${VariableName} 로 교체 지정한 값을 호출할 수 있는 부분?
!Sub
- String
- { Var1Name : var1Value, Var2Name: var2Value}
> 이거 사용 예제좀 봐야할듯 ㅋㅋㅋㅋ 뭔지 잘 모르겠음
----------------
<207 강 - CF Rollbacks>
> 시험에 출제될 확률이 높으니, 작동 방식을 이해하는 것이 매우 중요
> StackCreation 이 실패할 경우, 기본적으로 모든 항목이 롤백된다. (로그에서 확인 가능)
> 롤백 옵션을 해제하고 사용하여 그 사이에 어떤 것들이 발생한 것인지 좀더 확인할 수 있다
> StackUpdate 이 실패할 경우, previous 상태로 되돌린다
< 실습 >
Resources:
MyInstance:
Type: AWS::EC2:Instance
Properties:
AvailabilityZone: us-east-1a
ImageId: ami-123456 # 존재하지 않는 Image ID
InstanceType: t2.micro
SecurityGroups:
- !Ref SSHSecurityGroup
- !Ref ServerSecurityGroup
> 위 내용이 포함된 YML 파일로 Stack 생성을 시도한다 (실패할 것이기 때문)
> 내리다보면 Stack Failure Option 을 확인할 수 있다
>> 1번 > Rollback All Stack Res > 이전에 알려진 안정 상태로 롤백
>> 2번 > Preserve Successful provisioned Res > 성공적으로 프로비저닝 된 것들은 보존, 롤백 금지 > 이거 선택함
> 실패하는 것을 확인할 수 있음 > 생성에 성공한 것은 보존한다
> 두번째 실습에서는 정상을 먼저 배포하고, 다음 버전에는 실패 버전을 배포하였다 (위에것)
> 이번엔 1번을 선택했음.
> UPDATE 을 진행하게 되고, 인스턴스 생성하다가 Upate 가 실패하는 것을 확인할 수 있음.
> 계속 새로고침하다보면 다 롤백하는 것을 알 수 있고, 이번 업데이트로 만들어졌던 SG 들이 모두 삭제된다는 로그들까지 확인할 수 있다.
> 실습에서 2번 (ROLLBACK 금지) 로 설정한 다음에 실패 확인했을 때는 스택을 업데이트 하고 문제를 수정할 수 없다(??) - 그럼 ㅆㅂ 이 기능이 왜있냐 ㅅㅂ.. 그래서 생성 성공한 것들 남아두라고 했으면서 이거 삭제하려면 Stack 삭제해야함 ㅋㅋ ㅂㅅ 같은데?
> 두번 째 업로드에서는 ROLLBACK 하라고 명시함. 롤백 다 끝난다음에 Update Stack 을 할 수 있는데..? 이거 퀴즈 2번 답 잘못된거 아님??
-------------------------
<208강 CF Service Role (사용자? 역할) - 설정할 때 나옴>
> 사용자가 생성하는 IAM Role 로, CF 에게 너를 대신해서 리소스들을 생성/수정/삭제 할 수 있도록 허용해주는 Role 이다
> Stack 에 종속된 Resource 들을 직접 제어할 권한이 없더라도, CF 에 대한 권한이 있다면 이를 통해서 Resource 들에 대한 create/update/delete 을 할 수 있다
> 위 상황은 유저가 S3 에 직접 접근할 권한이 없는 경우이다
> 해당 유저에게 CF 에서 작업을 수 행할 수 있는 자체 IAM 권한 (Own IAM 권한은 뭐임?) 을 정의. (iam:PassRole 을 포함?)
> CF 에서 전담하게 될 Service Role 도 생성하였다 (S3 버킷에 대해 만들고 업데이트, 삭제 등의 수행 권한)
(지금 위에 상황은 CF 의 Service Role 도 저 위 User 가 전해준듯 (iam:PassRole 의 권한으로)
Use Case
> 최소한의 권한 부여로 목적을 수행하고 싶음
> 사용자에게 Stack Resource 생성을 위한 모든 권한을 주지 않으며, Only Invoke a service role on CF 의 권한만 주여진다 (PassRole 권한)
> ㅆㅂ 뭔소린지 모르겠음 ㅅㅂ (아래 실습보고 난 이후 다시 와서 쓰는거지만, 특정 스택에서 작업하기 위한, 이번 스택 작업에 필요한 역할만을 부여하기 위해서 사용하는 것인듯)
<실습>
> IAM 으로 이동, Role 로 이동, CF 에 대한 새로운 Role 생성
> S3 Full Access 권한 정책을 추가한 상태로 만든다 (LectureDemoRoleForCF)
> Stack 생성으로 이동해서, 3단계를 보면 Permissions 을 지정하는 곳이 있는데, IAM Role 을 지정할 수 있다. 지정하지 않으면 내 개인 권한 (현재 계정) 을 사용하게 된다.
> 위에서 만든 LectureDemo Role 로 지정한다, 이 역할은 모든 스택 작업에 사용된다.
> 이제 CF 는 모든 스택작업시 내 권한을 사용하지 않고, 이 권한을 사용한다. 이 권한은 S3 권한만 가지고 있기 때문에, CF 가 EC2 인스턴스를 생성하라는 template 을 받을시, 실패하게 된다
> 권한 관리가 중요하긴 한가봄
> 그냥 CF 에 Role 전달해주는 건데 ㅈㄴ 어렵게도 설명한다
-------------------------
<209강 CF Capabilities>
> Capabilities 란 탬플렛이 Create or Update an IAM resources, such as (IAM User, Role, Group, Access Keys, Instance Profile 등) 하려 할 때 CF 에게 전달해줘야 하는 것을 말한다
> 솔직히 뭔지 잘 모르겠음
> CAPABILITY_NAMED_IAM (리소스에 이름이 부여된 경우), CAPABILITY_IAM (리소스에 이름이 부여되지 않은 경우)
> CAPABILITY_AUTO_EXPAND (탬플렛이 Macro 나 Nested Stacks 와 같이 Dynamic Transformation 을 수행하려 할 경우 필수적) --> Deploy 전에 템플렛이 변경될 수 있다는 점을 인지하는 것(?)
> 템플렛 Deploy 중 InsufficientCapabilitiesException 이 발생한다면, CF 템플렛이 Capability 가 필요한데 부여받지 못한 경우에 발생한다 (탬플렛 re-upload 필요, capability 사용 필요)
>> API 호출에 parameter 추가 or 콘솔에서 체크박스 그냥 하고 그러는걸로 부여할 수 있는 듯
<실습>
Resources:
MyCustomNamedRole:
Type: AWS::IAM::Role
Properties:
RoleName: MyCustomRoleName
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: [ec2.amazonaws.com]
Action: ['sts:AssumeRole']
Path: "/"
ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonEC2FullAccess
Policies:
- PolicyName: MyPolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Efect: Allow
Action: 's3:*'
// ...
> 강사님이 다 안보여주심.. ㅋㅋ
> IAM Role 생성도 제어하는 Template 임을 확인할 수 있음 > Role Name 은 "MyCustomRoleName" 이다.
> ManagedPolicy 를 사용한다 (MP 란 AWS 에서 제공하는 관리정책) : AmazonEC2FullAccess Policy 의 ARN 을 명시
> 이렇게 만들고 Upload Template File 로 Stack 을 만들어보자
> 만들고 Review 하는 영역에서 AWS 가 Role 생성이 포함되어있음을 인지하고, Capability 가 필요하다는 박스를 띄워준다
>> 내 템플렛으로 인해 CF 가 IAM 리소스를 만든 다는 점을 인지하고 있다고 체크해야함
> 체크박스에 체크한다는 것 자체가 (아까 말했듯이) Capability 를 부여하는 행위임!
-------------------------
<210강 CF 삭제 정책>
> DeletionPolicy >> CF 템플렛이 삭제되거나, CF 템플렛에서 리소스가 삭제되었을 때 발생할 일들을 제어하는 기능
>> 백업 리소스들을 보존하기 위한 보안장치 역할을 하기도 한다
> Default : Delete (Default 기 때문에 따로 명시 안해도 됨)
>> CF 탬플렛을 삭제하면, 연계된 모든 리소스들을 삭제한다.
Resources:
MyEC2Instance:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-12345678
InstanceType: t2.micro
...
DeletionPolicy: Delete
> 템플렛 삭제시 각 리소스별로 DeletionPolicy 를 맥일 수 있는 것인듯
> 예외사항 ) S3 버킷은 Delete 설정이 빈 버킷일 경우에만 적용된다. 즉, 빈 버킷이 아닐 경우 S3 삭제에 실패한다
> Retain Policy
>> 단순하게 Delete 과 반대임. 살려놓고 싶은 리소스에 명시해두는 것
Resources:
MyDynamoDBTable:
Type: AWS::DynamoDB::Table
Properties:
TableName: MyTable
...
DeletionPolicy: Retain
> 데이터를 보존하고 싶기에, DB 리소스를 Template 삭제되어도 보존되도록 Retain 으로 명시해줄 수 있다
> Snapshot Policy
>> 삭제하기 전에 마지막 상태를 Snapshot 하여 저장해두는 것
>> EBS Volume, ElasticCache Cluster, RDS DBInstance, RDS DBCluster, Redshift Cluster 등등
> 위와 같이 특정 인스턴스 항목에 설정해두면 됨
<실습>
> SG 에 DeletionPolicy: Retain 으로 먹임
> EBS 는 반면에 다음과 같이 Snaptshot 으로 먹임 (EBS 건 처음봐서 좀 적어둠)
Resources:
MySecurityGroup:
Type: AWS::EC2::SecurityGroup
DeletionPolicy: Retain
...
MyEBS:
Type: AWS::EC2::Volume
DeletionPolicy: Snapshot
Properties:
AvailabilityZone: us-east-1a
Size: 1
VolumeType: gp2
> 삭제하면 EBS 같은 경우 삭제되겠지만 Snapshot 이 저장될 것이다. SG 는 삭제 안될 것이다
> 이 템플렛으로 CF 에서 Stack 을 만들었음
> 삭제를 해본뒤 Events 들을 보면, MySecurityGroup 은 DELETE_SKIPPED 라고 떠 있다. EBS VOLUME 은 DELTE_COMPLETE 라고 뜬다
> 근데 DELETE_IN_PROGRESS 를 보면 "SNAPSHOT_CREATION_SUCCEDDED | Logical ID :~!@$!@#$ " 라고 적혀 있음
> 그리고 EC2 Instance 로 가서 EBS> Snapshots 항목으로 이동하면 스냅샷이 있는 것을 알 수 있다. 하지만 >Volumes 로 이동하면 EBS 자체는 삭제되어 있음
-------------------------
<211강 CF Stack Policies>
> CF Stack Update 를 한다면, 기본적으로 모든 리소스에 모든 Actions 들이 허용된다 (스택 정책이 필요한 이유)
> Stack Policy 는 JSON 문서로, Stack update 시 특정 리소스에 대한 어떤 업데이트 액션이 허용되는지 명시한 문서이다.
> 의도치 않은 업데이트 트리거로부터 리소스들을 보호하기 위함
> Stack Policy 설정을 일단 하면, 빈 문서라도, 모든 업데이트로 부터 리소스는 보호된다.
>> update 를 허용하는 특정 리소스를 명시적으로 전달해야 업데이트가 진행된다
-------------------------
<212강 CF Termination Protection>
> CF Stack 의 의도치않은 삭제를 방지하기 위해 사용하는 기능
> 스택에서 Stack Actions 로 이동, Termination Protection 활성화 가능
> 이제 삭제를 하라고 하면, 바로 삭제 안내가 나오지 않고 Termination Protection 을 비활성화 하라고 함. (이건 권한이 있어야 비활성화 가능)
-------------------------
<213강 CF Custom Resources (User 지정)>
> CF 에서 아직 지원되지 않는 일부의 리소스들이 있다. 이런것들을 위해서나, 혹은 자체적인 프로비저닝 (on-premise 리소스, 3rd party 리소스 등)
>> 혹은 특정 리소스들이 create/update/delete 되는 도중 custom script 가 실행되게 하는 것 (람다 함수를 이용함)
>>> ex S3 버킷 삭제 전에는 empty 하라는 script 를 실행
> 시험에 자주 나오는 영역
> 일반적으로 람다 함수, 혹은 SNS Topic 이라는 리소스와 함께 사용된다
> 자체 리소스를 넣으려면 다음 둘 중 하나를 사용해야 한다
- AWS::CloudFormation::CustomResources
- CUstom::MyCustomResourceTypeName (권장)
< 정의 방법 - 람다를 예시로 >
Resources:
MyCustomResourceUsingLambda:
Type: Custom::MyLambdaResource
Properties:
ServiceToken: arn:aws:lambda:REGION:ACCOUNT_ID:function:FUCNTION_NAME
#Input values (Optional)
ExampleProperty: "ExampleValue"
> 위 Custom Resource 템플렛을 보면, ServiceToken 이란 property 가 있고, Type 은 Custom 리소스임을 명시해줬다
> ServiceToken 에는 일반적으로 람다 함수 ARN 혹은 SNS ARN 을 명시한다 (같은 지역에 있어야 함)
>> Input Parameters 항목을 활용해서 람다 함수에게 Input Values 들을 줄 수 있다
< 대표적인 Use Case >
위에서 계속 언급했듯이, S3 버킷을 삭제하려고 할 때가 대표적인 Use Case 이다
> S3 버킷은 안에 내용물이 있으면 절대로 삭제되지 않는다
> 따라서 CF 가 S3를 삭제할 시에 안에 내용물을 모두 삭제하고 진행하라는 Custom Resource 를 만들 수 있다.
> 위 그림과 같이 CF 에서 삭제 스택을 실행할 때마다 Lambda 함수로 지원되는 사용자 정의 리소스가 API 호출을 실행하여 S3 버킷을 비우고, 그 이후에 CF 가 S3 버킷 삭제를 시도하게 된다.
-------------------------
<214강 CF Stack Sets>
> Stack Set 을 활용하여 단일 Operation / Template 을 통해서 Multipe Accounts And Regions 전역적으로 스택들을 Create / Update / Delete 를 할 수 있다.
> 관리자 계정의 Template 을 사용하여(?) Stack Set 을 만든다
> 이 스택 세트를 사용하면 여러 지역, 여러 계정에 스택을 배포할 수 있다.
>> 솔직히 뭔소린지 잘 모르겠음
> Stack Set 을 update 하면, 모든 계정 리전 전역적으로 연관된 stack instance 들은 영향을 받게 되어, 한 번에 모든 것을 업데이트 할 수 있다
> 가장 일반적은 사용 사례는 AWS Organization 을 만드는 모든 계정에 적용하는 것이다 (?) (Apply into all acoounts within the AWS Organization) - (그냥 groups of account in AWS 란 뜻이래)
>> 이 Organization 에서는 관리자 계정으로만 Stack Set 을 만들 수 있는 것임 !! (안그러면 말도 안되는 것
>> 뭔소린지 모르겠다~~~~
-------------------------
<퀴즈>
1. CF 에서 업데이트에 대한 변경 사항을 실행 전에 분석해 주는 것은? (이거 생성할 때 맨 마지막에 한번 Preview 해주는 것) - Change Set Preview 기능이라고 한다
2 (틀림, 이상함) . 관리자가 CF 템플렛을 생성함. ROLLBACK_COMPLETE 상태로 실패. 해결후 뭘 해야 하나? 아니 롤백을 안해주거나 해주거나 무조건 삭제후 새 스택이 답인거야??? 롤백 안해준거는 업데이트 자체가 안된다며
- 실패한 스택에서 업데이트 스택 작업을 수행 (내 답 - 오답)
- 실패한 스택을 삭제하고 새 스택을 생성 (정답)
3. 여러 지역, 여러 계정 CF 스택 생성하려 함 - Stack Set
4. CF 외부에서 스택 리소스 변경 사항을 감지하는데 사용할 수 있는 기능? 외부..? (이거 ㅆㅂ 강의에 안나왔다 미친놈아)
- 정답 : CF Drift 라고 하는데, 이거 강의에 안나옴.
5. CF 템플렛 두개, A 는 네트워킹 구성 요소 포함, B 는 인프라가 포함. A 의 SG 를 B 의 EC2 에 연결 - 이거 output 수행 필요, ImportValue 수행 필요
6. CF 를 사용하여 ELB 를 구성하는데 노력함. ELB 프로비저닝 해야 하는 팀에서 Code Snippet 을 재사용하고 싶어 함. - 템플렛 자체 를 참조하라고 하나? - 정답 : S3 에 CF 템픞ㄹ렛을 업로드하고, 사람들에게 이를 CF 중첩 스택으로 사용하도록 안내
- 아니 Nested Stack 도 안나왔어 ㅆㅂ... 중첩 스택이란 말이 나온적이 Capability 할 때 밖에 없음.. (나중에 리뷰할 때 확인해보자)
7. Output 이름은 고유해야함
8. Stack Output 을 다른 곳에서 참조시, 참조하는거 먼저 삭제해야함. (FK
9. Fn::Join: 의 동작성 문제, 강의에서와는 다르게 - 로 List 항목들을 구분해서 넣어줌
10. !Ref 내장 함수는 _ 를 제외하고 모든 것을 참조할 수 있다. --> Condition 인듯? : Ref 는 Condition 참조 못하는 거 기억 (생각보다 놓치는 내용이 많나..? 이것도 왜 처음 듣는 거 같지..?)
11. 잘못된거 찾는거, EnvName 정의안함
12. ALB 의 DNS 이름을 검색할 수 있는 CF 내장함수는? 모르는거보니 GetAtt 에서 엔간한거 다 가져왔던 듯!
13. 템플렛에서 리소스는 필수다
14. CF 템플렛 작성시 리소스 순서 필요 없음
15. 이 블로그 먠 위에서 알 수 있듯이, CF 는 S3 를 언제나 참조한다. AWS 콘솔에서 하는 경우도 Behind-the-scene 에서 AWS S3 에 템플렛을 업로드 하고, CF 는 거기에서 참조되도록 동작한다.
16. CF 로 생성한 인프라가 자꾸 바뀜. 스택을 업데이트하려면? - 템플렛을 다시 처 올리세요 (이거가 2번임, 잘못 읽어서 3번함)
17. 유효하지 않은 Pseudo Param 인 것은?? - AccountName 은 없다!- 대표적인 것들 외워야 할듯!!
(AccountId, REgion, StackId 는 모두 지원!)
정말 길었던 AWS Cloud Formation 끗- 뭔가 붕 뜬 강의였던 것 같음. 너무 훅훅 지나가고... 퀴즈도 좀 이상했던게 많았던 것 같아. 복습하면서 확인해보고, 걍 본문에 없더라도 퀴즈에 나왔던 건 그냥 꼭 알고 있자.
====================================================================================
교육 출처
- AWS Certified Developer Associate 시험 대비 강의 - Udemy
'웹 운영 > AWS' 카테고리의 다른 글
| [CDA] 섹션 19 - AWS 통합 및 메시징: Kinesis (0) | 2024.07.25 |
|---|---|
| [CDA] 섹션 19 - AWS 통합 및 메시징: SQS, SNS (0) | 2024.07.21 |
| [CDA] 섹션 17 - AWS Elastic Beanstalk (0) | 2024.07.15 |
| [CDA] 섹션 16 - ECS, ECR 및 Fargate - AWS 의 도커 (0) | 2024.07.10 |
| [CDA] 섹션 15 - CloudFront (0) | 2024.07.09 |
