Ansible 이란?
기존엔 프로그램이 돌아가기 위한 실행환경을 만드는 데에 쉘 스크립트를 일반적으로 사용했어.
쉘 스크립트에 설치하고자하는 패키지나 혹은 그 외 다른 명령어들의 나열을 통해 원하고자 하는 실행흐름을 만들었지.
하지만 요즈음 여러 기술들의 발전과 함께 관리해야하는 서버의 숫자가 급격하게 증가하고 있어.
이러한 상황속에서 단순 쉘 스크립트만으로는 관리하기에 어려운 상황인거지.
이를 해결하기 위해 나온게 IaC(Infrastructure as a Code). 이는 컴퓨터의 인프라 구성을 소프트웨어를 개발하는 것처럼 코드로 작성하는 것을 의미한다. Ansible 또한 IaC 개념이 도입 되어 자동화 도구를 이용하여 인프라의 설정을 코드로 작성하고 이를 모든 서버에 배포함으로써 특정 환경을 동일하게 유지할 수 있도록 도와준데
Ansible에 대하여
특징
- provisioning : 다양한 서버를 셋업할 수 있게 해줘!
- configuration management : os, device 혹은 application의 설정을 변경하게 해줘! 그리고 이를 추적 가능하게 해줘!! 결국 이 또한 형상관리 툴에 의해 추적될 수 있기 때문에 그 기록을 볼 수 있지.
- application deployment : product 서버에 프로그램 배포를 자동화할 수 있게 해줘. 즉 devops를 쉽게 할 수 있도록 도와줘
- agentless : agent가 붙어서 동작하는 방식이 아니야!! 일반적인 자동화 도구들은 agent가 붙어 pull 형태로 이루어지지만 ansible의 경우 agent없이 push하는 방식이야.
구조
크게 위의 구조처럼 생겼어.
제어노드가 ansible이 설치되어있는 서버라고 생각하면 될 것 같애.
그리고 이 제어노드가 ansible을 이용해 관리 대상이 되는 서버들에게 일괄적으로 처리해야할 작업들을 손쉽게 동작할 수 있게 하는거지.
그리고 이때 통신에는 ssh를 사용해.
이렇게 통신할 때 어떤 것이 필요할까? 크게 다음 두가지겠지
- 접속정보 : 관리 대상이 되는 서버들에 대해 접속 ip나 혹은 login 정보 등이 필요하겠지 = Inventory files
- 명령어 : 어떤 명령을 실행할 지가 필요하겠지. ansible 에서는 한가지 명령어를 실행하는 방식을 ad-hoc command라고 불러. 그리고 여러 명령어의 시나리오를 파일로 만들어 실행하는 방법을 playbook이라고해.
조금 더 들어가보면
Inventory
인벤토리 파일에는 위에서 말했듯이 접속정보가 주어져.
이 인벤토리 파일의 형식에는 크게 두가지가 존재해.
먼저 첫번째로 아래와 같은 INI형식.
1 | mail.example.com |
두번 째는 아래 예시처럼 YAML 형식.
1 | all: |
이렇게 접속하고자 하는 대상의 정보를 인벤토리 파일에 정의해. 이때 단순 접속하고자 하는 도메인 혹은 ip를 제외하고도 추가적인 정보를 넣을 수 있어.
예를들어, 넘겨야하는 변수들이나 혹은 sudo 권한 획득을 위한 정보 등 여러 정보들을 추가할 수 있어.
또 ssh 통신을 사용하기에 default로 23 port를 이용하지만 만약 다른 포트로 열어놨다하면 해당 파일에서
domain(ip) ansible_port=xx 이런식으로 옵션을 줄 수도 있어. 이런 방법들은 내용이 방대하기에 공식 문서를 참고하는게 좋아.
그리고 각 도메인 혹은 Ip 위에 [ group name ] 을 볼 수 있는데 이렇게 그룹을 지정해 그룹별로 원하는 작업을 진행할 수 있어.
playbook
playbook은 위에서 설명했듯이 관리 대상이 되는 서버들에 대해 작업해야할 정보들이 담겨있어.
1 |
|
위처럼 줄 수 있어. 이때 시작할 때 —- 구분자 넣는 거 까먹으면 no!
위의 속성들을 간단히 설명해보자면
- host : 어떤 대상으로 할 것인가 (group, remote server)
- vars : 위의 예시에는 없으나 사용할 변수를 지정해 놓을 수 있어.
- tasks : 수행해야할 작업들 내용이 하위에 와. 이름과 모듈 등 리스트 형태로 진행해야할 작업들의 시나리오가 와.
- handlers : 얘도 위의 예시에서는 없지만 태스크에서 진행되는 작업을 정의할 수 있어. (a call by tasks. it will run only once, after all of the tasks complete)
playbook을 작성하다보면 하나의 큰 파일이 될 수 있는데 그럴 경우 재사용성에서 좋지 않아.
그래서 include, import를 사용하여 파일을 쪼갤 수 있어. 이 둘은 느낌상 컴파일러와 인터프리터의 느낌처럼 언제 처리되는지의 차이만 가지고있지 유사하다고 볼 수 있어.
- import : 플레이북이 파싱되는 동안에 pre-processed 된데. (all import statements are pre-processed at the time playbooks are parsed
- include : all include statements are processed as they encountered during the execution of the playbook.
이 외에도 roles 즉 각각의 role들을 분리해서 관리할 수 있어.
ansible 에서는 group에 맞게 directory를 구성할 경우 알아서 읽어와 실행해줘.
이 부분은 공식문서를 참조하는 것이 좋아.
위에서 한번 언급했듯이
ansible 명령어를 통해 한 모듈을(모듈은 굉장히 많은 종류가 존재하며 상세 종류 별 기능은 공식 document 참조) 대상(hosts)에 적용하는 것이 ad-hoc command이고
ansible-playbook 명령어를 통해 여러 무듈을 대상(hosts)에 적용하는 방식이 playbook이야.
이러한 명령어들은 구조를 어떻게 하는지, 혹은 원하는 옵션이 무엇인지에 따라 내용이 방대해지기에 ansible이 어떤 것인지 이해한 후 부터는 공식문서의 guide를 참조해 그때그때 찾아가서 사용하자!!
어느정도 이해가 되어 효율적인 구조를 원하는 경우 ansible best practice 를 참조하면 좋을 것 같애
https://docs.ansible.com/ansible/latest/user_guide/index.html#getting-started