💻
DevOps Cookbook
  • Home
    • Meiko DevOps Cookbook
  • Gitlab
    • Tips
      • 사전 정의된 CI/CD 변수의 기본 세트
    • 딥다이브 Gitlab CI/CD
      • GitLab CI/CD 시작하기
        • .gitlab-ci.yml 파일
        • Runner
        • 파이프라인
        • CI/CD 변수
        • CI/CD 컴포넌트
      • CI/CD YAML 구문 참조
    • CI/CD Notifications
      • CI/CD slack notifiaction 구축작업 결과
  • Kubernetes
    • Persistence Volume
      • play-cluster
    • Ingress
      • Ingress란
      • 수동으로 ingress 배포하기
    • Security
    • HPA
      • hpa troubleshooting history
        • 1. HELM_UPGRADE_VALUES_FILE로 hpa가 추가되지 않는 원인
        • 2. targetCPUUtilizationPercentage 계산은 어떻게 되는가
        • 3. helm values에 cpu resource 단위를 1로 했을 때 실제 파드에 1m( 0.001 ) 코어가 부여된 것
        • 4. pod cpu resources가 할당받은 것을 나타내는 것인 지 현재 사용량을 나타내는 것인지 검증
        • 5. 설정한 hpa를 기반으로 pod auto scaling이 동작하는 지 검증
      • HorizontalPodAutoscaler의 behavior 필드 중 stabilizationWindowSeconds 값이 Kubernetes 코드에서 어떻게 사용되는지 분석
  • prometheus
    • prometheus 리소스 alert 세팅
      • 슬랙 채널 구성
      • alert 환경 구성 가이드
  • Loki
    • loki-grafana alert 세팅
      • 1차 검증 결과
      • Alert 환경 구성 가이드
  • load test
    • nGrinder
      • nGrinder Test Configuration 값들
      • 질문리스트
        • groovy는 JUnit 스타일에 포함되지 않는건가 ? + GTest가 뭔지 좀 헷갈린다
      • Script
        • Groovy Script Structure
          • reference
          • Groovy script deep dive
          • Groovy Script 실행 구조 분석
      • Test
        • [nGrinder] single endpoint load test 하기
          • [nGrinder] single endpoint load test script 기반 cpu 사용량 테스트
          • [nGrinder] single endpoint load test script 기반 pod autoscaling 테스트
        • [nGrinder] multi endpoint load test 하기
          • [nGrinder] multi endpoint load test script에 정의한 test들이 실행 순서를 보장 받는가?
  • AWS
    • aws-cli
      • eks cluster vpc 스펙보기
    • aws-vpc
  • EKS
    • youtube links
    • EKS best practice
    • 질문 정리
  • Istio
    • Istio Basic
      • Istio 컴포넌트 별 역할
      • Kubernetes Ingress와 Istio VirtualService의 관계
    • Gateway
      • Gateway 주요 특징
      • Istio Gateway와 Kubernetes Ingress의 주요 차이점
  • IAC
    • Terraform
      • 테라폼 설치
      • 테라폼 문서
      • 테라폼 개념
        • 언어 구조
        • 사용 순서
        • 상태파일 (tfstate)
        • 변수 정의 방법
      • Terraform - AWS VPC
    • Ansible
      • Ansible 초기 학습 내용
      • Ansible Playbook
      • Ansible Study
        • Inventory
        • Playbook
          • Module
        • Variable
  • etc
    • Toss SLASH24
    • Elastic Load Balancing
    • 낙서장
      • IRSA
    • deep dive
      • Istio 공식문서 번역
        • Overview
          • What is Istio?
          • Why choose Istio?
          • Sidecar or ambient?
        • Concepts
          • Traffic Management
        • Page
      • eks 에서 control plane < - > data plane 통신 원리
Powered by GitBook
On this page
Edit on GitHub
  1. IAC
  2. Ansible

Ansible 초기 학습 내용

PreviousAnsibleNextAnsible Playbook

Last updated 1 year ago

Terraform과 Ansible 코드를 별도의 레포지토리로 관리하는 것의 장점

  • 분리된 책임: Terraform은 인프라를 프로비저닝하고 Ansible은 구성을 관리합니다. 각 도구가 다른 목적을 가지고 있기 때문에, 이를 분리하여 관리하면 더 명확한 책임 구분이 가능합니다.

  • 유지 보수 용이성: 각 레포지토리에 있는 코드가 독립적이기 때문에 변경 사항을 관리하고 유지 보수하는 것이 더 쉬워집니다.

  • 협업: 팀 내에서 다른 사람이 Terraform과 Ansible을 각각 다르게 관리할 수 있어 협업이 용이합니다.

  • 버전 관리: 각 도구의 버전 관리를 독립적으로 할 수 있어 특정 도구에만 영향을 미치는 변경 사항을 쉽게 관리할 수 있습니다.


구조 예시

  1. Terraform 레포지토리

    • 인프라 프로비저닝 코드 (VPC, 서브넷, EKS 클러스터, Bastion Host 등)

    • 출력 변수 설정 (예: Bastion Host IP)

  2. Ansible 레포지토리

    • 인벤토리 파일 (Terraform 출력 변수를 기반으로 동적 생성)

    • 플레이북 파일 (Istio 설치, ALB Controller 생성, Helm 설치 등)


Ansible 구조 설명

  1. Control Node: Ansible이 설치되어 있는 로컬 컴퓨터로, 여기서 Playbook을 작성하고 실행합니다. Control Node에서 SSH를 통해 Managed Node로 연결하여 명령을 실행합니다.

  2. Managed Node (Bastion Host): Control Node에서 연결되어 설정이 적용되는 노드입니다. Bastion Host는 EKS 클러스터와 상호작용하고 필요한 작업을 수행하는 역할을 합니다.

예시

  • Control Node: 사용자의 로컬 컴퓨터 (Ansible 설치)

  • Managed Node: Bastion Host (Terraform으로 프로비저닝된 EC2 인스턴스)

결론

Ansible을 사용할 때 Control Node는 사용자의 로컬 컴퓨터가 되고, Managed Node는 Bastion Host가 됩니다. 이렇게 구성하면 Control Node에서 Ansible을 사용하여 Bastion Host에 필요한 설정을 적용하고, Bastion Host를 통해 EKS 클러스터에 접근하여 필요한 작업들을 자동화할 수 있습니다.