CHAPTER 1 IaC와 테라폼

1.1 인프라 자동화의 성숙도 변화

인프라 방식

  1. Manual
    1. 문서로 관리
      1. 인프라 관련 모든 정보
      2. 인프라 구성 방법
      3. 인프라 변경 방법
      4. 기존 아키텍처에 대한 내용
    2. 모든 변경을 문서로 남겨야 한다
      그렇지 않으면 기억에 의존한다
    3. 장점?
      1. 정보와 구성을 곧바로 눈으로
        매뉴얼을 보고 확인할 수 있다
      2. 물리적으로 가까이 있는 사람에게
        즉각 정보를 전달 할 수 있다
    4. 단점?
      1. 매뉴얼은 사람이 아닌 인프라가 이해할 수 없다
      2. 결국 사람이 실제 작업을 위한 명령어와 구성 파일을 별도로 준비해야 한다
      3. 변경 사항 반영 어려움 → 재사용성 낮음
      4. 버전 관리 불가능 → 업데이트 위해서는 새로 작성 필요
  2. Script
    1. 반복되는 작업 → 스크립트를 작성해서 자동화(작업자 노하우)
    2. 신규 서버 설정, 특정 기능 수행
    3. 반복 지루한 작업을 줄이고, 미리 정의한 동작 한번에 실행 → 오류를 줄여준다
    4. 단점
      1. 동작하는 코드 증가
      2. 시스템의 응답이나 상태를 고려해야하는 케이스 발생
      3. 스크립트 특성상 상태와 상관없이 실행
      4. 최종 상태가 스크립트 결과와 일치 하지 않는 경우가 종종 발생
  3. VM
    1. 가상화 솔루션 → 가상 머신 → 인프라 운영 관리 편해짐
    2. 가상 머신 이미지 템플릿 → 저장, 반복적 사용 가능
    3. 필요 패키지 설치 + 필요설정 추가한 템플릿 가능
    4. 스냅샷 : 수동적이지만 state를 보관 가능하다
    5. 단점?
      1. 가상화 솔루션 범위에 포함이 되지 않거나
        서로 다른 툴 사용? → 일관된 관리 불가능
      2. 하이퍼 바이저에 의존하게 된다
      3. 이미지 변경 → 수작업
  4. Cloud Infra
    1. 인프라를 더 이상 소유하지 않고
      상품화된 인프라와 데이터 센터를 사용하는 단계
      → 기본적으로 클라우드 리소스를 원격 관리 가능
    2. 빠른 인프라 시작 구성 가능, 뛰어난 확장성
    3. 단점
      1. 클라우드 제공자마다 서로 다른 API
      2. 멀티 클라우드 자동화 위해서는 ?
        → 개별적인 작업이 추가로 필요
  5. Container
    1. 물리적머신 → VM→OS를 가상한 환경 제공
    2. 최근 데브 옵스 흐름 → 더 빠른 성장
    3. k8s같은 오케스트레이션 사용
      → 특정 서버가 아닌 적절한 리소스의 어떤 서버에 배포
      → 리소스 활용율 ↑, 이전보다 더 자동화
    4. 가용한 모든 리소스 확장 가능
    5. 매우 빠른 배포 전략 도입
    6. 역설적인 단점 : 자동화의 역설
      1. 기존 : 물리적 하드웨어가 VM으로 가상화
        → 이를 제어하기 위한 SW 관리 작업이 추가 됨
      2. 컨테이너도 관리와 배포를 위한 제어 시스템 구축
        → 모니터링 노력이 상대적 커짐 → 자동화의 역설
    7. 가장 최신 기술 → 컨테이너 개발/운영 전문 인력이 부족

_1.2 프로세스로서의 자동화

  • 자동화: 각 프로세스 작업을 통합하고 재활용성을 높이는 것이 중요하다
  • 이전 자동화 방향성 : “기술 주도형 접근”
    • 강력한 엔지니어적 협조
    • 빅뱅방식 적용
      • 개발 기간을 정하고
      • 모든 시스템을 일괄적으로
      • 구축 또는 업그레이드 하는 개발 방식
    • 느리고 매뉴얼화된 절차적단계를 거쳐 프로세스 진행
    • 단계별로 파편화된 자동화 → 특정 환경에서만 동작
    • 따라서 내부에서 구축된 리소스 자동화에 적합
  • 새로운 자동화 필요 : CI/CD
    • 고정적이지 않고 추상화된 리소스 → 기존 자동화 재적용 어려움
    • 동적 인프라(like 클라우드)+ 다른 플랫폼 기술 융합 자동화 → 프로세스적인 접근법 필요
    • 작은 규모로 독립성을 유지 관리 → 주기적인 변경과 적용 방식 지향 → 빠른 시장 적응과 장애 극복 능력 획득 필요
    • 코드 표현 방식에 기반한 자동화 설계 → 개별 서비스를 릴리즈 하기 위한 반복 작업 효율화
  • 자동화의 역설 어게인
    • 기존 하드웨어 기반에 비해 시간과 인력 소모 → 자동화 할수 있는 API인터페이스 제공
    • 자동화(가상화↑, 컨테이너화) → 일반적으로 업무량이 줄고 더 나은 워라밸이 가능해야 한다
    • 자동화의 역설 → 무수히 많은 반복과 검증 작업 필요 → 이전보다 더 많은 시간과 노력을 요구하기도 한다
    • 더 아이러니 한 것
      • 인프라 관리, 운영을 위한 단계 방식이 어느 것 하나 없어지지 않음
      • VM, 베어메탈 같은 서버 환경이 현재도 존재
      • 기존 서버 환경보다 더 작은 Edge, IOT 인프라도 관리대상 추가

1.3 IaC의 이해

  • 코드로 인프라를 관리 한다는 것
    • “자유롭게 변경”하고
    • “환경을 이해”하고
    • “반복적으로 동일한 상태”를 만들 수 있다
    • 이에 대한 명세를 별도의 문서로 정리하지 않아도
      인프라가 명확하게 정의되어 남게 된다
  • 좋은 코드의 특징을 먼저 살펴보면
    • 잘 작동함
    • 관리가 쉬움
    • 읽기 쉬움
    • 변경이 쉬움
    • 모듈화 됨
    • 간결하고 명확함
    • 테스트 가능함
    • 효율적임
    • 보기 좋음 -우아함
  • 좋은 코드의 특징과 IaC의 관계
    • 인프라도 좋은 코드처럼 관리가 가능
      • 자동화를 위해 → 문서화
      • 인프라 종속성 분석해서 관리
      • 인프라 자원 있을때마다 변경
      • 결과물이나 결과물 만드는 도구를 관리
    • 인프라를 위한 좋은 코드 : 연습이 필요하다
> IaC (Infrastructure as Code)는 코드로 인프라를 관리하는 것으로,
> 좋은 코드의 특징과 비슷합니다.
> 인프라도 코드처럼 잘 작동하고, 관리가 쉽고, 읽기 쉽고, 변경이 쉽고,
> 모듈화되며, 간결하고 명확하며, 테스트 가능하고, 효율적이며, 우아합니다.
> IaC는 이러한 좋은 코드의 특징을 활용하여 인프라를 자동화하고,
> 문서화하고, 인프라 종속성을 분석하여 관리하며, 인프라 자원이 있을 때마다
> 변경하며, 결과물이나 결과물을 만드는 도구를 관리합니다.
> 이러한 과정 없이, 좋은 코드가 좋은 인프라 자동화로 이어지도록 만들어줍니다.
  • IaC 장점
    • 속도와 효율
    • 버전 관리
    • 협업
    • 재사용성
    • 기술의 자산화
  • IaC 우려 측면
    • 코드 문법 학습 - 새로운 도구를 위한 학습 필요
    • 파이프라인 통합 - 기존 워크플로에 자동화를 위한 수고가 추가로 필요
    • 대상 인프라 이해 필요 - 관리 대상이 되는 인프라의 지식이 필요

1.4 테라폼의 특성

  • 테라폼 : 하시코프사
  • 3가지 철학 - 워크플로에 집중, IaC, 실용주의
    • workflow -Workflows, not technologies
      • solution - 기술, 기능 구현을 위해 만들어진다
      • 어떤 기능 하나가 모든 것을 해결해주지 않음
      • 테라폼 : 개발자/관리자가 일하는 방식과 유사한
        workflow를 만들기 위한 도구로 설계
      • workflow대상: 인프라 구성과 배포, 보안구성, 모니터링 도구 설정 등
      • 어떤 기술이 사용되더라도 workflow를 통해
        환경 변화에 크게 구애 받지 않는다
      • 인프라 환경이 바뀌어도 workflow는 유지될 수 있음
    • IaC
      • 의미: 구현/구성되는 모든 것이 코드로 표현되어야 한다
      • ‘문서화된 실행 가능한 텍스트’
      • 기록 뿐 아니라 버전 관리 대상 → 많은 장점
    • 실용주의(pragmatism)
      • 현실적인 해결을 위해 이상을 재평가 해야하는 상황이 많음
      • 실용주의:
        • 새로운 아이디어와 접근 방식, 기술을 다시 평가
        • 타협이 아닌 이전의 것이 틀릴 수 있다는 사실을 받아들이는 적응 능력
        • 혁신에 있어 매우 중요

책에 나오지 않은데 스터디에서 설명해준 내용

- 페이저 비활성화

export AWS_PAGER=""
 

AWS CLI 페이지 매김 옵션 사용 - AWS Command Line Interface

--starting-token 파라미터는 null이거나 비어있을 수 없습니다. 이전 명령이 NextToken 값을 반환하지 않으면 반환할 더 이상의 항목이 없는 것이기 때문에 명령을 다시 호출할 필요가 없습니다.

docs.aws.amazon.com

  • 명령어 사용시 바로 프롬프트가 떨어지도록 한다.

- Amazon Linux 2 최신 ami id 찾기

  • 자주 업데이트가 된다
  • (참고)이미지 타입 : /aws/service/ami-amazon-linux-latest/amzn2-ami-kernel-5.10-hvm-x86_64-gp2
# amazon owner 이미지들 : 어마어마한 양임.. page마다 나오지 중간에 나오면 된다
#aws ec2 describe-images --owners self amazon

# 위의 내용에서 이미지 ID만 필터링 : 내가 직접 세본 것만 200페이지가 넘어간다. 중간에 나오자.
aws ec2 describe-images --owners self amazon --query 'Images[*].[ImageId]' --output text
# 최신 이미지 리스트 - 머신 타입에 따라 다름에 유의
aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest

#위에서 타입들만 필터링해서 리스트
aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest --query "Parameters[].Name"
# 위에서 이미지 리스트만
aws ssm get-parameters-by-path --path /aws/service/ami-amazon-linux-latest --query "Parameters[].Value"

- AWS Default VPC 생성

  • 조회방법
# vpc 확인
aws ec2 describe-vpcs --filter 'Name=isDefault,Values=true' | jq
{
...

# vpc id만 확인
aws ec2 describe-vpcs --filter 'Name=isDefault,Values=true' | jq '.Vpcs[0].VpcId'
"vpc-3912a952"

# 서브넷 확인
#aws ec2 describe-subnets --filter 'Name=vpc-id,Values=vpc-3912a952' --output table
aws ec2 describe-subnets --filter 'Name=vpc-id,Values=vpc-<자신의VPC ID>' --output table

 

 


도전과제1

Ubuntu 에 apache(httpd) 를 설치하고 index.html 생성(닉네임 출력)하는 userdata 를
작성해서 설정 배포 후 웹 접속
 - 해당 테라폼 코드(파일)를 작성

 

 

provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_instance" "example" {
  ami                    = "ami-0c9c942bd7bf113a2"
  instance_type          = "t2.micro"
  vpc_security_group_ids = [aws_security_group.instance.id]

  user_data = <<-EOF
              #!/bin/bash
              apt-get update
              apt-get install -y apache2
              service apache2 start
              echo "My Nickname : rkaehdaos" > /var/www/html/index.html
              EOF
  tags = {
    Name = "Single-WebSrv"
  }
}
resource "aws_security_group" "instance" {
  name = var.security_group_name

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port       = 0
    to_port         = 0
    protocol        = "-1"
    cidr_blocks     = ["0.0.0.0/0"]
  }		
}

variable "security_group_name" {
  description = "The name of the security group"
  type        = string
  default     = "terraform-example-instance"
}

output "public_ip" {
  value       = aws_instance.example.public_ip
  description = "The public IP of the Instance"
}
첫 주 스터디를 하기 전에 예습을 했어야 했는데...

정말 내가 이상한지 모르겠는데..
IaC는 그냥 프로그램하고는 다르다..
분명히 스터디 하고 영상 다시 보기 할 떄는 맞아 맞아.. 그거지..했는데.. 막상 도전 과제 하나 하려니..
정말 실습에서 아주 조금 비튼 건데.. 지금 몇 시간을 날린건지..새벽 2시가 되서야.. ㅠ
과제는 과제로 치고.. 진짜로 빡집중하자 진짜로.

자고 일어나서
동영상 2번 다시 볼것!!

아냐.
1번 보고 다시  따라 해볼 것!

 

블로그 이미지

감동맨

rkaehdaos의 블로그

,