Documents

Ansible
IaaS, Infrastructure as a Service
  • 클라우드를 통해 가상머신 환경을 온디맨드로 제공

IaC, Infrastructure as Code
  • 인프라스트럭쳐 상태를트소프트웨어가 자동으로 실행할 수 있는 코드 형태로 기술

  • 여기서 말하는 인프라는 "시스템을 가동하기 위해 전제가 되는 주변 환경 모두"를 가르킴

  • 엄밀하게는 서버와 네트워크 계층을 다루는 것을 IaC, 미들웨어와 애플리케이션 배포 등의 상위 계층을 다루는 것을 CaC(Configutation as Code)라고도 하지만 넓은 의미로 IaC의 한 요소로 간주

  • 작업에서의 노동 시간 감소화 효율화에 의한 비용 감소

  • 코드화에 의한 고도의 품질 보증

  • IaC를 실현할 도구:

    • 이전에는 shell script, shell의 조합

    • 현재는 구성 관리 도구 사용 - Chef, Puppet, Ansible

DevOps
  • "개발(Dev) 계층과 운용(Ops) 계층의 밀접한 연결에 의한 소프트웨어 라이프 사이클의 단기화화라는 축을 중심으로 한 방법과 기술 등의 구체적인 것에서부터 조직론에서 경영 철학에 이르는 추상적인 개념까지 다양한 문맥에서 사용되어 여러가지 의미가 추가됨

  • 데브옵스 맥락에서 생각하면, 제일 중요한 것은 CI(Continuous Integration)에 의한 연결이며, IaC로 인프라를 자동화함으로써 개발에서 테스트, 인프라 설치에 이르기까지 시스템 릴리즈에 필요한 전 과정을 자동화하고 똑똑하게 통합할 수 있음

Ansible?

  • 미국 레드헷사가 제공

  • 파이썬으로 개발

  • NASA(미국항공우주국)와 같은 대규모 조직에서도 도입

  • 앤서블이 내세운 모토: "모든 사람을 위한 자동화(Automation for Everyone)"

  • 앤서블이 지향하는 방향성: "누군가는 사용하기 쉽다"가 아닌 "누구나 사용하기 쉽다", 국소적인 생산성이 아닌 조직 전체의 생산성.

앤서블의 구성

  1. 본체

    앤서블 소프트웨어 그 자체로, 서버/클라이언트 구성과 같은 형태가 아니며 상주 프로세스를 둘 필요가 없다. 한 번 설치하면 필요할 때 명령을 실행하는 것으로 충분하다.

  2. 인벤터리(Inventory)

    앤서블이 작업할 대상 머신. "어디에서" 앤서블을 실행하는가?

    인벤터리는 앤서블에서 조작 대상이 되는 서버 접속 정보를 나타낸다. 인벤터리는 여러 개의 서버를 그룹화해 정의하거나 각각의 서버와 그룹에 대해 변수를 사용한 파라미터를 설정할 수 있다.

  3. 모듈(Module)

    앤서블에서 실행되는 개별 작업의 정의. "무엇을" 앤서블에서 실행하는가?

    앤서블에서 실행된 하나하나의 명령 같은 것. ansible-doc -l 명령어로 공식 모듈을 확인할 수 있다.

  4. 플레이북(Playbook)

    모듈 호출의 중심에 있는 앤서블 코드. "어떻게" 앤서블을 실행하는가?

    앤서블에서 스크립트(=코드)이며 앤서블을 사용할 때 필요한 작업은 플레이북의 구현과 실행이라고 할 수 있다. YAML로 작성한다.

앤서블의 특징

Ansible deployment architecture

Agentless

기존에 존재하던 구성 관리 도구인 Chef와 Puppet은 루비로 작성되었고, 작업 대상 머신에 전용 에이전트가 중앙 서버에 접근해 코드를 취득한 다음 에이전트가 스스로 해당 머신에 적합한 상태를 설정한다. 이렇게 중앙서버에서 설정을 가져오는 것을 pull type 아키텍처라고 한다.

이에 반해 앤서블에서 채용한 에이전트리스 모델은 push type 아키텍처로, 앤서블이 설치된 중앙 머신이 각 실행 대상에게 로그인해서 직접 명령을 실행한다.
네트워크 접속은 일반 SSH를 이용한다. 즉, 사람이 로그인할 때와 동일하게 실행 대상 서버에 로그인한다.

Idempotency

멱등성. "어떤 작업을 여러 번 실행해도 결과가 항상 같다다는 성질이다. 앤서블에 대해서는 각 모듈의 내부에서 무엇을 실행할 것인가를 "절차적"으로 다루는 것이 아니라, 최종 본래의 형태를 "선언적"으로 다뤄 멱등성이 보장되도록 하는 것이다. "파일 A를 배치한다"는 처리를 예로 멱등성의 유무에 따라 동작이 어떻게 달라지는지 보자.

멱등성을 고려하지 않은 경우

"파일 A를 어디에 복사한다"라는 절차 그 자체가 설정돼 있으며 작업 실행 전의 파일 설치 상황은 고려하지 않는다. 이미 파일이 있는 경우에도 다시 복사하거나, 작업 대상의 상태에 따라 필요 없는 처리가 실행되는 것처럼 기대하지 않은 결과가 발생할 우려가 있다.

멱등성이 보장된 경우

"파일 A가 어디에 존재한다"라는 최종적인 상태가 정의돼 있으며, 먼저 파일이 설치 상태를 확인한 다음 처리가 실행된다. 이미 같은 파일이 있으면 정의된 상태를 만족하므로 변경에 따른 처리를 실행하지 않는다. 설치돼 있지 않거나 다른 내용의 파일이 있는 경우에 대해서만 파일을 복사한다.

여기서 말하는 멱등성이란 작업 대상의 상태가 항상 같게 되는 것을 가리키는 것은 아니다. 예를 들어 "패키지를 최신 버전으로 유지"라고 정의한 경우에는 그 패키지의 최신 버전이 외부 요인에 의해 달라져, 실제 결과가 달라질 수 있다. 어디까지나 플레이북에 작성된 목적에 기분을 둘 때 결과가 일정하게 되는 점에 주의해야 한다.

Reusability

재사용성. "높은 재사용성" 즉, 범용성을 유지할 수 있으면 앤서블을 계속 사용함에 따라 구현 등에 따른 시간이 줄어들 것이다. 모듈 이외에도 플레이북 측에서도 재사용을 위한 구조로 Role이 있다.

ansible,IaC,infrastructure