용어 정리
프로비저닝
클라우드 서비스를 시작하고 구성하는 것, Puppet, Ansible 등이 있다.
Puppet, Ansible
커뮤니티 오픈소스 IT 자동화 툴. 서버/엔드포인트 기기에서 시스템 구성 및 프로비저닝, 소프트웨어 배포, 업데이트 관리와 같은 일상적인 task를 자동화 해서 IT 운영과 DevOps 작업을 간소화 할 수 있다. Ansible은 자동화 대상에 추가 소프트웨어를 설치하지 않아도 되는 유연한 에이전트리스 접근 방식이며, 반면 Puppet은 전통적으로 각 시스템에 주가 소프트웨어를 설치해야 하는 에이전트 기반 접근 방식을 선택한다.
배포
프로비저닝된 서버를 위해 애플리케이션 버전을 제공하는 작업
AWS CodePipline
소프트웨어 release에 필요한 단계를 모델링, 시각화 및 자동화하는 데 사용할 수 있는 지속적인 전달 서비스.
Jenkins
거의 모든 언어의 조합과 소스코드 리포지토리에 대한 지속적인 통합과 전달환경을 구축하기 위한 간단한 방법을 제공한다. 다른 일상적인 개발 작업을 자동화할 뿐만이아니라 파이프라인을 사용해 통합 및 전달 환경을 구축하기 위한 간단한 방법을 제시한다.
Github Actions
빌드, 테스트 및 개발 파이프라인을 자동화하기 위한 지속적인 통합과 전달(CI/CD) 플랫폼.
CI/CD란?
- CI(Continuous Integeration) : 개발자들이 코드베이스를 지속적으로 통합
- CD(Continuous Delivery) : 코드 베이스가 항상 배포 가능한 상태를 유지하는 것
- CD(Continuous Deployment) : 코드 베이스를 사용자가 사용 가능한 환경에 배포하는 것.
오케스트레이션
여러 시스템 또는 서비스를 조정하는 작업.
오케스트레이션 vs 자동화
클라우드 자동화는 응용 프로그램 배포와 같은 클라우드 관련 작업을 자동화하여 IT 팀에게 요구되는 수동 작업을 줄여준다. 오케스트레이션은 이러한 자동화된 작업을 대규모로 조정할 수 있다. 오케스트레이션 도구를 사용하면 IT 팀이 하드웨어부터 미들웨어에 이르기까지 매우 복잡한 클라우드 환경을 관리할 수 있다.
Kubernetes
컨테이너화된 애플리케이션 배포, 관리, 확장을 예약하고 자동화하기 위한 컨테이너 오케스트레이션 플랫폼.
컨테이너
애플리케이션 소스코드와 모든 환경에서 코드를 실행하는 데 필요한 모든 운영 체제 라이브러리 및 종속성을 결합하는 경량의 실행 가능한 애플리케이션 구성 요소.
salt
솔트(Salt)는 파이썬 기반 오픈 소스 원격 실행 프레임워크이다.
개요
자동화가 필요한 이유
일반적인 방식으로 배포를 진행한다면 규모에 따른 반복성 지원, 버전 컨트롤 불가, 감사 추적의 부재, 일관성 없는 데이터 관리에 어려움을 겪는다. 특히 배포는 불필요한 반복 작업이다. 따라서 자동화를 통해 애플리케이션 배포에 작업자가 직접 관여하지 않고도 새로운 기능과 애플리케이션을 더 빨리, 더 자주 출시할 수 있다.
인프라의 지속적 전달을 위해 필요한 것
위의 그림은 소스, 빌드, 테스트, 프로덕션의 4단계 릴리스 프로세스다.
이 과정 중 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식인 지속적 전달을 위한 도구와 프로세스를 사용한다.
- 인프라를 코드로 취급하는 방법
- 인프라 리소스를 생성하고 업데이트하는 워크 플로를 관리할 수 있는 도구
- 변경 사항을 적절히 테스트하고 결함 및 잠재적 문제가 있는지 검사하는 도구
코드형 인프라
버전 제어오 지속적 통합과 같은 코드 및 소프트 웨어 개발 기술을 사용하여 인프라를 프로비저닝하고 관리하는 방식
워크플로
직접 정의한 릴리스 프로세스 모델을 기반으로 코드가 변경될 때마다 코드를 빌드, 테스트 및 배포함으로써 변경 사항을 신속하고 안정적으로 제공
AWS는 이 두 가지 방식을 서비스하고 있다. 특히 지금 다룰 Cloud Formation의 경우 코드형 인프라를 제공한다.
AWS Cloud Formation
AWS CloudFormation은 AWS 리소스를 모델링하고 설정하여 리소스 관리 시간을 줄이고 AWS에서 실행되는 애플리케이션에 더 많은 시간을 사용하도록 해 주는 서비스입니다. 필요한 모든 AWS 리소스(예: Amazon EC2 인스턴스 또는 Amazon RDS DB 인스턴스)를 설명하는 템플릿을 생성하면 CloudFormation이 해당 리소스의 프로비저닝과 구성을 담당합니다. AWS 리소스를 개별적으로 생성하고 구성할 필요가 없으며 어떤 것이 무엇에 의존하는지 파악할 필요도 없습니다. CloudFormation에서 모든 것을 처리합니다. 다음 시나리오는 CloudFormation이 얼마나 유용한지를 보여줍니다.
용어 정리
AWS 리소스를 코드로 정리하는 템플릿과 템플릿을 읽고 실제 리소스를 생성 및 관리하는 스택으로 구성된다.
기능
- AWS 리소스 모음을 모델링, 생성 그리고 관리하는 간소화된 방법 제공
- 스택 생성 시 템플릿에 설명된 리소스를 프로비저닝 및 구성을 담당하는 laC(코드형 인프라)기반
- CloudFormation을 통한 해결
- 인프라 관리 최소화
- 신속한 인프라 복제
- 인프라 변경 사항 쉽게 제어 및 추적
비용
프로비저닝된 리소스만 비용지불! → 비용 없음!
AWS CloudFormation 작동 방식
스택 생성 워크플로우
스택 업데이트
스택의 리소스를 업데이트해야 하는 경우 스택의 템플릿을 수정할 수 있다. 새 스택을 만들고 이전 스택은 삭제할 필요가 없이 본 스택 템플릿의 수정된 버전, 다른 입력 파라미터 또는 둘 다를 제출하여 변경 세트를 생성한다. CloudFormation은 두 수정 전후 템플릿을 비교하고 변경 세트를 생성한다.
- Change set을 사용하면 변경 사항을 구현하기 전에 미리 확인할 수 있으며 스택 삭제 및 업데이트 시 리소스 보존 및 백업을 위해 DeletionPolicy 속성을 사용할 수 있다.
laC로써의 AWS CloudFormation
수동 인프라 관리는 시간이 많이 걸리고 오류가 발생하기 쉽다. 특히 애플리케이션을 대규모로 관리하는 경우 코드형 인프라를 사용하면 원하는 상태에 도달하기 위한 모든 단계를 포함하지 않고도 인프라의 원하는 상태를 정의할 수 있다.
- 용이한 환경 복제
- 복잡한 매칭 환경 감소
- 복잡한 환경의 신속한 배포
- 일관성
- 간편 정리(스택삭제 시 리소스 삭제)
- 수동 구성으로 인한 구성 오류 감소
- 모범 사례 환경 반복
IaC는 구성 파일을 소스 코드 파일처럼 처리하여 가상화된 리소스를 제어할 수 있다. IaC는 사람이 읽을 수 있고, 기계 소비가 가능한 템플릿 파일을 작성하여 클라우드 리소스를 프로비저닝하고 관리하는 프로세스다. 복제, 재배포, 용도 변경이 가능하며 장애 발생 시 마지막 양호한 상태로 롤백이 가능하다.
샘플 템플릿 분석 - lab.network.yaml
- AWSTemplateFormatVersion : 포맷 버전
AWSTemplateFormatVersion: "2010-09-09"
- Description : 스택 설명
Description: ">-"
- Parameters : 스택 생성 및 업데이트시 템플릿에 전달하는 값
- Mappings : 조건부 파라미터값을 지정하는 데 사용할 수 있는 Key-Value 값의 매핑 리전별로 리소스를 달리할 시 사용
- Metadata : 템플릿에 대한 추가 정보
- Conditions : 스택 생성 또는 업데이트 시 특정 리소스 속성에 값이 할당되는지의 여부를 제어, 스택 환경이 prod인지 test인지에 따라 달라지는 리소스를 조건부로 생성할 때 사용
- Resources : aws 리소스 및 해당 리소스의 속성을 지정한다. VPC설정이므로 VPC와 관련된 리소스 입력함
- DeletionPolicy : retain → 삭제나 업데이트 시 보존 가능
Resources:
## VPC
VPC:
Type: AWS::EC2::VPC
Properties:
EnableDnsSupport: true
EnableDnsHostnames: true
CidrBlock: 10.0.0.0/16
## Internet Gateway
InternetGateway:
Type: AWS::EC2::InternetGateway
VPCGatewayAttachment:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
VpcId: !Ref VPC
InternetGatewayId: !Ref InternetGateway
## Public Route Table
PublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
PublicRoute:
Type: AWS::EC2::Route
DependsOn: VPCGatewayAttachment
Properties:
RouteTableId: !Ref PublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
## Public Subnet
PublicSubnet:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.0.0/24
AvailabilityZone: !Select
- 0
- !GetAZs
Ref: AWS::Region
PublicSubnetRouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
SubnetId: !Ref PublicSubnet
RouteTableId: !Ref PublicRouteTable
PublicSubnetNetworkAclAssociation:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
SubnetId: !Ref PublicSubnet
NetworkAclId: !GetAtt
- VPC
- DefaultNetworkAcl
- output : 템플릿으로 생성한 것의 결과를 출력
Outputs:
PublicSubnet:
Description: The subnet ID to use for public web servers
Value: !Ref PublicSubnet
Export:
Name: !Sub '${AWS::StackName}-SubnetID'
VPC:
Description: VPC ID
Value: !Ref VPC
Export:
Name: !Sub '${AWS::StackName}-VPCID'
Configuration Drift
예상치 못한 인프라 변경에 대한 사고와 미치는 영향을 Configuration Drift라고 부른다.
Drift detection
CloudFormation에서는 외부에서 변경하면 스택 업데이트 또는 삭제 작업. 드리프트 감지를 사용하여 스택 리소스를 식별할 수 있는데 이를 drift라고 한다. 드리프트 감지를 사용하면 스택의 실제 구성이 다른지 여부를 감지할 수 있다.
→ 리소스가 드리프트되었는지 여부를 확인하기 위해 CloudFormation은 예상 스택 템플릿에 정의된 resource 속성 값과 로 지정된 모든 값 템플릿 매개 변수. 그런 다음 CloudFormation은 이러한 예상 값을 실제 값과 비교한다.
'AWS' 카테고리의 다른 글
AWS linux kafka 초기 설정 (0) | 2024.09.20 |
---|---|
[CASE STUDY] 리멤버의 서비스 모니터링 분석 (1) | 2024.01.21 |
[SAA] Associate SAA-C03 5문제 (0) | 2023.12.23 |
CloudWatch와 x-ray를 통해 관찰 가능성 확보하기 (0) | 2023.12.02 |
[SAA] Associate SAA-C03 5문제 (0) | 2023.12.02 |
댓글