SOA-C03 08/16 — 이미지와 Infrastructure as Code
정보보안기사 응시 후 학습을 위해 미리 작성한 본문이다. 작성·보존은 대화 전달이나 학습 완료를 뜻하지 않는다.
1. 코드·이미지·배포 상태를 연결한다
재현 가능한 운영에는 세 가지가 필요하다. 무엇을 만들라는 선언, 실행할 소프트웨어, 실제로 적용된 상태다.
Git commit의 코드·설정
→ image build와 검증
→ AMI ID 또는 container digest
→ IaC에서 배포 대상을 참조
→ 변경 계획 검토·적용
→ 실제 리소스와 서비스 검증저장소에 코드가 있다고 실행 환경이 그 코드와 같지는 않다. 반대로 운영 화면에서 바꾼 설정은 코드에 반영되지 않으면 다음 배포에서 사라질 수 있다.
2. AMI는 EC2를 기동하는 소프트웨어 출발점이다
AMI에는 기동에 필요한 소프트웨어와 block device mapping이 있다. AMI는 Region·OS·processor architecture·root volume·virtualization 특성과 연결된다. x86 이미지와 Arm 유형처럼 호환성이 맞지 않으면 기동할 수 없다. 다른 Region에서는 복사된 AMI를 해당 Region의 ID로 참조한다. AMI
운영에서 새 이미지가 있어도 기존 instance가 자동으로 교체됐다고 가정하지 않는다. Launch template의 image 참조, 실제 배포된 instance의 AMI, 교체 전략을 연결한다.
이미지에 넣기 좋은 것은 반복 설치되는 OS package·runtime·공통 설정이다. 환경별 secret·일회성 token은 이미지에 굽지 않고 실행 시 권한 있는 경로로 가져오도록 설계한다. 이미지 공유·복사 전에는 민감한 파일과 사용자 데이터가 남지 않았는지 확인한다.
3. Image Builder는 build·test·distribution을 관리한다
| 구성 | 책임 |
|---|---|
| Base image | 시작하는 OS·이미지 |
| Recipe | base와 적용할 component·설정 |
| Build component | software 설치·설정 변경 |
| Test component | 생성한 이미지에서 기대 기능 검증 |
| Infrastructure configuration | build instance·역할·network·log 환경 |
| Distribution configuration | 배포할 Region·공유·출력 설정 |
| Pipeline | 실행 일정과 위 구성을 연결 |
Build 환경에서 package repository에 접근하지 못하면 이미지 내용보다 network·DNS·IAM부터 본다. Build 성공 뒤 test image 기동이 실패하면 아키텍처·드라이버·서비스 기동 로그를 확인한다. 배포 실패는 목적지 권한·KMS·공유 범위를 본다. Image Builder
Golden image는 관리된 출발점을 뜻한다. 시간이 지나며 취약점·종속성·설정 요구가 변하므로 지속적인 rebuild와 검증이 필요하다.
4. ECR에서 tag와 실제 이미지 내용을 구분한다
Container image는 애플리케이션과 종속성을 packaging하고 ECR은 이를 저장·배포한다. Tag는 사람이 쓰는 이름이고 digest는 특정 내용의 식별에 사용한다. Mutable tag를 덮어쓰면 같은 이름이 다른 이미지를 가리킬 수 있다.
ECR tag immutability는 기존 tag 덮어쓰기를 제한하며 현재 설정에는 exclusion 선택도 있다. Release tag가 실제로 보호되는지 repository 설정과 예외를 확인한다. ECR tag mutability
배포 기록에는 Git commit·build 결과·image digest·task definition 또는 배포 설정을 연결한다. 이미지를 registry에 push한 것과 workload가 그 이미지를 pull해 정상 기동한 것은 별도다. 정리 정책에서도 rollback에 필요한 이미지를 남기는지 검토한다.
5. CloudFormation: 선언·변경 계획·실행
Template은 리소스와 속성·참조 관계를 선언하고 stack은 관리 단위를 만든다. Parameter로 환경 차이를 입력하고 output으로 다른 구성에서 쓸 값을 제공한다. 참조는 생성 순서를 결정하는 dependency의 근거가 될 수 있다.
Change set에서는 추가·수정·삭제·교체를 본다. 특히 이름·storage·network 같은 속성 변경이 resource replacement로 이어지는지 검토한다. Change set 생성은 리소스 변경 자체가 아니며, 사전 검증을 통과해도 runtime 조건 때문에 실행이 실패할 수 있다. Change sets
| 단계 | 확인할 증거 |
|---|---|
| Template 작성 | 의도·속성·참조·parameter |
| Change set | 실제 변경 대상과 교체·삭제 영향 |
| Stack 실행 | resource별 event·status·오류 |
| 서비스 검증 | 사용자 요청·데이터·관측 지표 |
Drift detection은 실제 설정과 CloudFormation의 예상 설정 차이를 찾는 도구다. 지원 resource·property 범위에 제한이 있으므로 drift 없음이 환경 전체가 완전히 동일하다는 뜻은 아니다. Drift
6. CDK는 프로그래밍 언어에서 인프라를 정의한다
AWS CDK는 construct로 구성을 만들고 CloudFormation template으로 합성한다. 반복 구조·재사용을 코드로 표현할 수 있지만 실제로 배포할 리소스의 권한·quota·교체 제약은 여전히 존재한다. 생성한 template과 diff를 보고 실행 결과를 확인한다. AWS CDK
즉 코드가 compile·synth됐다는 것은 인프라 생성 성공의 증거가 아니다. 고수준 construct가 자동 생성하는 IAM·security group·storage 설정도 검토 대상이다.
7. Terraform은 configuration·state·실제 resource를 대응시킨다
Terraform state는 configuration의 resource와 원격 객체의 대응을 추적한다. 팀 작업에서는 state의 접근·동시 변경·복구를 관리해야 한다. State에는 민감한 값이 포함될 수 있어 일반 소스와 같은 공개 범위로 취급하지 않는다. Terraform state
Terraform plan은 제안된 변경을 보여 준다. Plan의 update·replace·destroy와 대상 workspace·backend·provider account를 확인한 뒤 적용한다. 검토한 plan 이후 원격 상태가 달라질 수 있으므로 검토 대상과 실제 적용 대상을 일치시킨다. Terraform plan
CloudFormation과 Terraform이 같은 객체를 독립적으로 관리하면 서로의 변경을 되돌리려 할 수 있다. 소유 도구를 명확히 두고 이관할 때 import·state와 실제 리소스 관계를 검토한다.
8. Git의 이력은 배포 사실과 연결해서 사용한다
Git diff는 변경 내용을, commit은 특정 이력 지점을 보여 준다. PR·review는 그 변경을 검토하는 흐름으로 사용한다. Merge만으로 image build·IaC apply·실환경 검증까지 완료됐다고 판단하지 않는다. Git diff
재현할 수 있는 배포 기록은 “어느 commit, 어느 이미지, 어느 parameter, 어느 account·Region, 어느 실행 결과”를 연결한다. Rollback도 이전 코드뿐 아니라 schema·secret·데이터 호환성이 맞는지 확인해야 한다.
9. 완성된 운영 적용 — 공통 runtime 갱신
- 기존 이미지 recipe와 코드 변경을 Git에서 검토한다.
- Image Builder로 새 이미지와 test 결과를 만든다.
- 출력 AMI ID·Region·아키텍처를 배포 설정과 대조한다.
- IaC change set/plan에서 교체 범위와 데이터 보존을 확인한다.
- 제한된 배포 대상에서 기동·health·대표 요청을 검증한다.
- 배포를 진행하고 실제 fleet의 image ID를 확인한다.
- 이전 이미지·설정으로의 복구 경로와 잔존 자원을 확인한다.
여기서는 실행 구조를 학습하며 실제 이미지 생성·배포는 수행하지 않았다. 시험 범위는 AMI·container와 IaC 도구의 역할·관리 흐름이고, 배포 실패와 계정 간 배포는 09에서 이어진다. 범위: Domain 3.