인프라와 자동화

인프라 자동화

• 이제 단순 자동화를 넘어서 네트워크 인프라 전체를 자동화하는 필요성 증가.
• 전문가들이 네트워크를 설계·구성·관리하는 방식이 크게 바뀌고 있음.
• 대표 도구: Puppet, Ansible, Chef (범용 자동화), pyATS, VIRL (네트워크 전용).

인프라 자동화란?

• 자동화란? 코드를 사용해 컴퓨팅, 스토리지, 네트워크와 그 위에서 실행되는 앱을 관리하는 것.
• Cisco 플랫폼은 Ansible 같은 범용 툴과 통합되거나 직접 API 제공.
• 캠퍼스, 데이터센터, 서비스 제공자 환경 모두 활용 가능.
• Cisco DevNet Automation Exchange에서 다양한 솔루션을 탐색 가능.

자동화가 필요한 이유

속도와 확장성: 빠르게 움직여 경쟁력 확보.

수동 작업 단점:

• 서버 설정에만 수십 분 소요, 수십~수백 앱이면 네트워크 중단 위험.
• 확장이 어렵고 인적 오류 발생 가능.
• 문서화는 불완전·애매모호·빠르게 구식화.

비용 문제: IT 중단 시 분당 5,600달러 손실, 보안 침해는 더 치명적.

종속성 위험: 오픈소스 생태계 의존 → 특정 기능이 중단되면 운영 차질, 취약한 스택에 갇힘.

풀스택 자동화의 필요성

• 장점: 속도, 반복성, 대규모 확장, 위험 감소.
• 셀프 서비스: 사용자가 DB, VPN, 분석 플랫폼 등을 직접 요청.
• 주문형 확장: 퍼블릭·프라이빗 클라우드에서 자동 확장.
• 관찰 가능성(o11y): 모니터링과 사전 테스트로 내부 상태 추적.
• 문제 완화/자가 복구: Chaos Engineering으로 장애를 가정하고 대비.

소프트웨어 정의 인프라와 자동화

클라우드 컴퓨팅 = 베어메탈/가상 리소스를 코드로 관리.

이점:

• 셀프 서비스로 신속한 자원 사용
• 표준화·일관성 유지
• 컨테이너로 앱/플랫폼 분리

과제:

• 클라우드별 API/UI 차이
• 권한 관리 어려움 → 보안 위협
• 사용하지 않는 리소스 방치 시 예상치 못한 비용 발생

해결책: 자동화로 리소스 사용 추적, 비용 관리

분산·동적 애플리케이션과 자동화

• 모놀리스 아키텍처(단일체): 하나의 서버나 애플리케이션 안에 모든 기능이 들어있는 방식. 단순해 보이지만, 단일 서버에 장애가 나면 전체 서비스가 중단되고, 성능과 확장성이 제한됨. 예를 들어, 게시판·로그인·결제 기능이 모두 한 프로그램 안에 들어 있는 경우.
• 문제점: 단일 장애 지점(SPOF), 전체를 한꺼번에 업데이트해야 해서 배포 위험 증가, 특정 부분만 확장하기 어려움.
• 마이크로서비스 아키텍처: 기능을 작은 서비스 단위로 쪼개 각각 독립적으로 개발·배포하는 방식. 서비스들은 컨테이너에 담겨 네트워크로 연결되고, 필요 시 개별적으로 확장 가능. 예를 들어, 로그인 서비스·결제 서비스·상품 서비스가 각각 독립적으로 운영됨.
• 장점: 서비스별 독립 확장 가능, 장애가 부분적으로만 발생, 유지보수와 업그레이드가 용이.
• 과제: 서비스 개수가 많아져 복잡성이 증가, 이를 관리하려면 자동화 도구 필수.
• 도구: Kubernetes, Mesos 같은 오케스트레이터가 서비스 배포·확장·자가복구를 자동화.

인프라 자동화 요약

자동화는 다음을 가능하게 함:

• 앱의 개발→테스트→배포→운영 전체 관리
• 소프트웨어 정의 인프라 관리
• 자동화 코드 자체를 보존·업데이트하여 지속 개선

즉, 앱과 인프라를 하나의 코드 작업물로 취급할 수 있음.

 

자동화 도구와 개념

자동화 도구의 역할

• 단순화와 표준화: 운영체제 명령어나 API 호출을 쉽게 사용할 수 있도록 래핑(wrapping)해줌.
  → 초보자가 복잡한 명령어 대신 간단한 코드만 작성해도 동일한 효과를 얻을 수 있음.
• 심층 기능 접근 가능: 필요하면 원시 셸 명령어도 실행 가능.
  → 기존에 쓰던 스크립트나 레거시 코드를 재사용할 수 있음.
• 안전성과 멱등성 지원: 변경 전 백업 자동화, 에러 발생 시 복구 기능 제공.
  → “한 번 실행하든 열 번 실행하든 결과가 동일”하게 보장.
• 개발 속도 가속화: 기본 제공 기능(out-of-the-box)으로 네트워크 스냅샷, 롤백 기능 등을 바로 활용 가능.
  → 예: Ansible은 Cisco ACI 설정 스냅샷과 롤백 지원.
• 재사용성과 보안 강화: 변수 정의, 서버 인벤토리 분리, 템플릿 활용 가능.
  → Ansible Vault처럼 민감 데이터 암호화 기능도 지원.
• 인벤토리 관리: 장비 하드웨어, OS, 애플리케이션 상태 등을 자동 수집.
  → 클라우드 환경에서는 동적 인벤토리로 자원 실시간 업데이트.
• 대규모 확장 지원: 수천~수만 개 노드를 한 번에 관리 가능.
• 커뮤니티 지원: 오픈소스 기반 → 전 세계 사용자가 공유하는 플레이북, 레시피 활용 가능.

 

중요한 개념

• 멱등성(Idempotency): 자동화 코드를 여러 번 실행해도 동일한 결과 보장.
  → 실수로 다시 실행해도 환경이 깨지지 않고, 원하는 상태로 수렴.
• 절차 vs 선언적:
  • 절차적: 순서대로 명령 실행 (Python, BASH 스타일).
  • 선언적: “최종 상태”만 기술하면 도구가 알아서 맞춰줌 (Ansible, Puppet).
• 프로비저닝 vs 구성 vs 배포 vs 오케스트레이션:
  • 프로비저닝: 서버·네트워크 기본 자원 확보.
  • 구성(Configuration): OS·서비스 설치 및 준비.
  • 배포(Deployment): 앱이나 클러스터를 실제로 설치.
  • 오케스트레이션: 자동 확장, 자가 복구 등 “전체적인 흐름 관리”.
• 상태 관리(Stateless vs Stateful):
  • Stateless: 상태 저장 X → 서버 추가/삭제에 유연 (예: 단순 웹서버).
  • Stateful: 상태 저장 O → 세션, DB 같은 경우 확장·이동이 어려움.
    → 자동화는 Stateless 앱에 더 적합.

 

CI/CD란?

 

CI (Continuous Integration, 지속적 통합)
여러 개발자가 작성한 코드를 자주(하루에도 여러 번) 중앙 저장소(GitHub 같은 곳)에 합치는 걸 말한다.
이때 자동으로 빌드·테스트가 실행돼서 코드 충돌이나 버그를 빨리 잡을 수 있다.
→ "코드를 자주 합쳐서, 문제를 빨리 찾자"는 개념.

CD (Continuous Delivery/Deployment, 지속적 전달·배포)
CI 이후에 안정적으로 테스트된 코드를 자동으로 배포(Deploy)까지 이어가는 과정.

• Continuous Delivery: 배포 준비까지 자동화 (실제 배포는 사람이 버튼 눌러서 실행)
• Continuous Deployment: 배포까지 완전 자동화 (테스트 통과하면 바로 운영 서버에 올라감)

요약

• 자동화 도구는 “복잡한 수동 작업 → 간단하고 안전한 코드 실행”으로 바꿔줌.
• 처음에는 백업·조회(GET) 기능으로 시작 → 점차 배포·오케스트레이션으로 확장.
• 멱등성·선언적 방식 이해가 자동화의 핵심.
• Ansible 같은 도구는 커뮤니티 자료가 많아 학습하기 가장 쉬움.

 

Ansible이란?

• 가장 널리 쓰이는 자동화 툴 중 하나.
• 오픈소스 버전과 IBM/Red Hat의 Ansible Tower(상용 버전)가 있음.
• 이름은 소설 속에서 '우주 어디서든 즉각 통신 가능' 장치에서 따옴.

기본 구조

• Control Node: Ansible이 설치된 곳 (보통 Linux 머신)
• Managed Node: Ansible이 관리하는 서버나 장비들
• 제어 노드에서 SSH로 연결해 명령 실행, 패키지 설치, 설정 변경 등을 수행.

설치 방법

sudo apt update
sudo apt install ansible -y

코드 구조 (YAML 기반)

• .yml 파일에 작업(Task)을 위에서 아래로 정의.
• 모듈(Module)을 불러와서 파라미터와 함께 실행 → 마치 함수 호출과 비슷.

예: 방화벽 설정(UFW 사용)

- name: Allow SSH and HTTP through firewall
  ufw:
    rule: allow
    port: "22,80"
    proto: tcp

Playbook과 Role

• Playbook: 여러 작업을 묶은 실행 단위.
• Role: 반복해서 재사용 가능한 작은 단위 작업 모음.
• Ansible Galaxy에서 다른 사람이 만든 Role을 가져다 쓸 수도 있음.

예: 데이터베이스 서버 배포

---
- hosts: dbservers
  become: true
  tasks:
    - name: Install PostgreSQL
      apt:
        name: postgresql
        state: present
        update_cache: yes

    - name: Ensure PostgreSQL is running
      service:
        name: postgresql
        state: started
        enabled: true

Ansible 폴더 계층 요소

• Inventory files (호스트 파일): 관리 대상 리소스를 정리. dev, test, staging, production 환경을 나눠 관리 가능.
• Variable files (변수 파일): 그룹 또는 개별 호스트에 필요한 변수 값을 정의.
• Library/Utility files (라이브러리/유틸리티): 사용자 정의 모듈(Python)이나 유틸리티 포함. Ansible Galaxy 등에서 가져올 수 있음.
• Main playbook files (플레이북 파일): YAML로 작성, 역할(Role) 또는 다른 플레이북 참조.
• Role folders and files (역할 폴더/파일): 특정 기능 단계를 모아둔 구조. /tasks/main.yml과 핸들러 파일 포함.

프로젝트 구조 예시

myproject/
├── inventory
├── site.yml
└── roles/
    └── dbservers/
        ├── tasks/main.yml
        └── files/init.sql

인벤토리 파일 예시

[dbservers]
192.168.1.20
192.168.1.21

배포 실행

ansible-playbook -i inventory -u ubuntu -K site.yml

• -i: 인벤토리 파일 지정
• -u: SSH 사용자 이름
• -K: sudo 암호 입력 요청

CI/CD와 연계

• GitHub에 코드 푸시 → Jenkins 같은 CI/CD 툴이 테스트 실행
• 테스트 성공 시 Ansible Playbook 자동 실행 → 서버에 적용

예: GitHub Actions 워크플로 일부

name: CI/CD Pipeline
on: [push]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run Ansible Playbook
        run: ansible-playbook -i inventory site.yml

Cisco 환경과 Ansible

• Cisco 장비도 Ansible 모듈로 자동화 가능.
• 예: IOS 장비의 인터페이스 설명 추가

- name: Configure interface description
  ios_config:
    lines:
      - description Uplink to Core
    parents: interface GigabitEthernet0/1

핵심 요약

• Ansible = SSH 기반 자동화 툴, YAML 문법으로 단순·명확.
• Playbook/Role 구조로 확장성과 재사용성 확보.
• GitHub Actions, Jenkins 등과 연계해 CI/CD 자동화에 적합.
• Cisco 네트워크 장비도 전용 모듈로 관리 가능.

 

자동화 프레임워크란?

• 프레임워크는 단순한 “도구(tool)”가 아니라 일정한 규칙과 구조를 가진 틀.
• 예를 들어 Ansible은 서버·네트워크·클라우드 자원을 자동화할 때,
  “인벤토리 → 플레이북 → 역할(Roles)” 같은 일정한 구조와 흐름을 강제한다.
• 이 덕분에 누구나 같은 방식으로 코드를 작성하고, 재사용/공유/협업이 쉬워진다.

YAML 기반

• YAML(Yet Another Markup Language)은 사람이 읽기 쉬운 데이터 표현 방식.
• Ansible은 이 YAML 문법을 사용해서 자동화 시나리오(플레이북)를 작성.
• 예를 들어 쉘 스크립트라면 apt install nginx라고 쓰는 걸, Ansible에서는 이렇게 YAML로 표현한다:

 

- name: Install nginx
  apt:
    name: nginx
    state: present

사람이 읽어도 명확하고, Ansible 엔진도 해석할 수 있다.

 

정리

자동화 코드를 YAML 형식으로 작성하고,
Ansible이 이를 해석해 서버나 네트워크 장비에 자동으로 적용해주는 구조화된 틀

 

 

CI 단계: 스크립트 문법 검사 + 시뮬레이션

1) 누가 해주는 건가?

CI 서버 / 파이프라인 툴이 맡음

• Jenkins
• GitLab CI/CD
• GitHub Actions
• Azure DevOps Pipelines
  이런 툴들이 Git과 연동되어 “코드 push → 자동 검사 → 리포트”를 해준다.

 

2) 문법 검사(Static Check)는 어떻게 하나?

 

CI 서버가 정해둔 스크립트(테스트 스크립트) 를 실행해서 오류를 잡아준다.
예를 들어 네트워크 YAML/Playbook이면:

• ansible-lint → Ansible Playbook 규칙 검사
• yamllint → YAML 문법 에러 확인
• Python 스크립트라면 pylint 나 flake8 같은 코드 검사기 사용

 

3) 시뮬레이션은 어떻게 하나?

여기도 CI 서버가 툴을 실행시킴.

• Cisco pyATS: 실제 장비 config를 가상으로 돌려서 예상 동작 확인
• Batfish: 네트워크 정책(ACL, 라우팅) 시뮬레이션
• Container 기반 테스트: 실제 IOSv, NX-OSv 같은 가상 장비 이미지를 띄워서 미리 config 적용

즉,  git push 한 순간,
→ CI 서버가 “lint → 시뮬레이션 테스트 → 결과 리포트”까지 자동으로 실행

 

4) 결과 확인은 누가?

• CI 서버가 Slack, 이메일, GitLab/GitHub 페이지에서 “Pass / Fail” 을 알려줌
• 실패하면 CD 단계(실제 배포)로는 안 넘어감 → 안전장치 역할

5) 비유

네가 시험 답안(Git commit)을 제출하면,

• 문법 검사기는 맞춤법 검사기
• 시뮬레이터는 모의고사 채점기
• CI 서버는 자동 채점 시스템