이 글은 Arie Bregman 씨의 “20 Ansible Interview Questions” 을 번역한 것입니다.
질문1
Ansible 에서 다음 각각의 컴포넌트에 대해서 이들 사이의 관계를 포함해 설명하시오.
- Task
- Module
- Play
- Playbook
- Role
Answer
이 질문은 당신이 Ansible 의 기본적인 컴포넌트에 익숙한지 않한지, 그들이 어떻게 상호작동 하는지를 체크한다. 나는 이것이 우리가 Ansible 로 하고자하는 모든 것에 기본인만큼 매우 중요한 것임을 알았다.
- Task – 특정 Ansible 모듈(Module) 호출하기
- Module – 여러분의 호스트나 원격 호스트에서 Ansible 에 의해서 실제 실행되어지는 코드의 묶음. 모듈들은 카테고리로(database, file, network, …) 인덱스되고 task 플러그인처럼 첨조된다.
- Play – 주어진 호스트에 실행되어질 하나 혹은 그 이상의 Task 들.
- Playbook – 하나 혹은 그 이상의 Play들. 각각의 Play 들은 같은 호스트 혹은 다른 호스트들에서 실행되어질 수 있다.
- Role – Ansible Role 은 어떤 기능이나 서비스를 기반으로 자원들을 그룹화 해 쉽게 재사용할 수 있도록 해준다. Role 에서 variables, defaults, files, templates, handlers, tasks 그리고 metadata 를 위한 디렉토리를 가진다. 그리고 Role 을 Playbook 에 지정해서 사용할 수 있다.
더 자세한 Ansible core components 사항은 여기서 확인할 수 있다.
질문2
‘/tmp/new_directory’ 디렉토리를 생성하는 task 를 작성하라.
Answer
매우 기본적인 질문지만 당신이 Ansible 을 어떻게 활용하는지를 알수있게 해준다. 많은 사람들이 Shell 이나 Command 모듈을 사용하는 것으로 이 질문에 답합니다. 이것이 꼭 나쁜것은 아니지만, 제일 좋은 사례는 항상 명시적인 Ansible 모듈을 사용하는 것 입니다. (이 경우에, file 모듈을 사용하는 것이다.)
왜 그런가? 주요한 이유는 가독성(readability) 때문이다. 어떤 액션들은 서로 다른 운영체제에 따라 다르게 실행되지만, Module 은 언제나 같은 것을 사용하고(운영체제에 관계 없이) 어떤 Ansible 사용자라고 할지라도 Task 를 읽다보면 그것이 무엇을 뜻하는지를 알게된다. (특히 긴 쉘 명령어일 경우)
주의: 이것은 Module 이 ‘shell’ 이나 ‘command’ 로 지정한 명령어보다 반드시 좀 더 빠르다는 것을 의미하지 않는다.
디렉토리 생성 Task 는 다음과 같다.
|
|
- name: Create a new directory file: path: "/tmp/new_directory" state: directory |
질문3
다음 Play 결과는 무엇인가?
|
|
--- - name: Print information about my host hosts: localhost gather_facts: 'no' tasks: - name: Print hostname debug: msg: "It's me, {{ ansible_hostname }}" |
Answer
작성된 코드가 주어지면 항상 철저히 검토하세요. 만약 여러분의 대답이 “이것은 실폐할 것이다” 라면 맞습니다. 이 코드는 실행한 호스트로부터 수집된 정보의 일부인 ansible_hostname 이라는 Fact를 사용하고 있다. 하지만 이 경우에, Fact 수집을 비활성화(gather_facts: no) 했기 때문에 ansible_hostname 변수는 정의되지 않을 것이며 따라서 결과는 실폐하게 된다.
이 질문의 목적은 Fact 가 무엇인지를 체크하기 위한 것이지만 여러분이 아주 세세한 부분까지 신경을 쓰고 있는지를 체크하는 것이기도 하다.
유사하게 다음과 같은 질문이 있을 수 있다.
- 활용가능한 모든 Fact 를 나열하는 방법은?
- 당신만의 Fact 를 지정하는 방법은?
질문4
시스템에 ‘/tmp/mario’ 파일이 존재한다면 모든 시스템에 ‘vim’, ‘zlib’ 설치를 위한 Playbook 을 작성해라.
Answer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
--- - hosts: all vars: mario_file: /tmp/mario package_list: - 'zlib' - 'vim' tasks: - name: Check for mario file stat: path: "{{ mario_file }}" register: mario_f - name: Install zlib and vim if mario file exists become: "yes" package: name: "{{ item }}" state: present with_items: "{{ package_list }}" when: mario_f.stat.exists |
이 질문에 답하기 위해서 여러분은 register, conditionals 그리고 loops 에 익숙해져 있어야 한다.
첫번째 Task 는 ‘stat’ 모듈을 사용해서 각 시스템에 파일이 존재하는 체크한 결과를 ‘register’ 를 사용해서 ‘mario_f’ 변수에 담아두는 것이다. 이렇게 하면 등록한 변수를 어떤 다른 Task 에서도 사용할 수 있다. 이 경우에, 우리는 ‘/tmp/mario’ 파일의 상태를 담았고 다음 Task 에서 만약 파일이 존재한다면 패키지들을 설치하게 된다.
여러분이 본것처럼, 패키지들을 설치하기 위해서 우리는 리스트(list)를 반복할 수 있게해주는 “with_items” 루프를 사용했고 리스트에 아이템마다 module/task 를 실행했다. loop는, 다른 프로그래밍 언어처럼, Ansible 의 기본적인 사항이고 여러분은 Ansible 이 지원하는 다른 타입의 loop 을 알고 있어야 한다.
다른 주목해야할 라인은 ‘become: yes’ 인데, 이것은 Task 를 root 처럼 실행하게 해주기도 하지만 다른 사용자로 실행되도록 사용자를 지정해줄 수 있다(e.g. become: ‘toad’). 패키지 설치는 시스템의 sudo 권한만으로 수행할 수 있기 때문에 이 라인이(become: yes) 이 포함되어 있지 않으면 패키지 리스트 설치 Task 는 실패할 것이다.
다른 주목해야할 라인은 ‘become: yes’ 인데, 이것은 Task 를 root 처럼 실행하게 해주기도 하지만 다른 사용자로 실행되도록 사용자를 지정해줄 수 있다(e.g. become: ‘toad’). 패키지 설치는 시스템의 sudo 권한만으로 수행할 수 있기 때문에 이 라인이(become: yes) 이 포함되어 있지 않으면 패키지 리스트 설치 Task 는 실패할 것이다.
*Bonus: 어떤 Ansible 모듈들은 인자로(argument) 리스트를 받을 수 있다. 이 질문에서, loop 처리는 ‘package’ 모듈에 package_list 변수를 직접 제공함으로써 완벽하게 제거할 수 있었다. 또, 우리는 Ansible 에 정규표현식으로 파일 리스트를 반복하는 ‘with_fileglob’ loop 를 사용함으로써 “stat” 모듈을 완벽하게 제거할 수 있다. 이를 종합하면 다음과 같다.
|
|
--- - hosts: all vars: package_list: - 'zlib' - 'vim' tasks: - name: Install zlib and vim if mario file exists become: "yes" package: name:"{{ package_list }}" state: present with_fileglob: - 'tmp/mario' |
질문5
controller 그룹을 제외한 모든 서버에 다음의 내용을 가진 ‘/tmp/system_info’ 파일을 배포하는 Playbook 을 작성하라.
|
|
I'm <HOSTNAME> and my operating system is <OS> |
<HOSTNAME>과 <OS>는 실행되는 호스트의 실제 데이터로 바뀌어야 한다.
Answer
system_info 파일을 배포하는 Playbook 은 다음과 같다.
|
|
--- - name: Deploy /tmp/system_info file hosts: all:!controllers tasks: - name: Deploy /tmp/system_info template: src: system_info.j2 dest: /tmp/system_info |
system_info.j2 템플릿 내용은 다음과 같다.
|
|
# {{ ansible_managed }} I'm {{ ansible_hostname }} and my operating system is {{ ansible_distribution }} |
Template 사용은 여러분의 Playbook 이나 Role 들을 좀 더 다이나믹하게 해주고 다른 시나리오와 쉽게 적용할 수 있게 해준다. Ansible 은 파일의 동적 템플릿 구성을 위해서 ‘Jinja2(진자2)’ 불리는 강력한 템플릿 엔진을 사용한다. 많은 인기있는 프로젝트와 회사들이 이것을 사용중이고 우리는 시간을 갖지고 미래에 여러분이 그것을 잘 사용할 수 있도록 사용법을 익히는것을 강력히 추천 합니다.
Ansible 을 위한 Jinja 템플릿을 작성할때에 템플릿 최상단에 ‘ansible_managed’ 변수를 추가하는 것이 가장 좋은 사례 입니다. 이 변수는 Ansible 로 생성되거나 관리되는 출력파일을 누구나 읽을수 있는 문자열로 확장 됩니다. 그 다음, 우리는 호스트 이름을 위해서 ansible_hostname 을, OS 배포판을 위해서 ansible_distribution 을 사용했다.
이 질문은 다른 방법으로 구현 될 수 있다는 점에 유의해라. 예를들어, ansible_hostname 을 사용하는 대신 어떤분은 inventory_hostname 을 사용할 것이다. 그들은 같지 않지만, 이 경우에는 둘다 괜찮다.
질문6
어떻게 여러분의 Ansible 기반 프로젝트를 테스트 하는가?
Answer
몇몇 인터뷰때 이 질문을 했었는데, 아주 많은 다른 대답을 받았다. 그 답변들 중 몇가지 이다.
- Manual run: “나는 그냥 그것을 실행시키고 시스템이 원하는 상태에 있는지를 체크한다” – 개인적으로 나는 이런 대답만 하는것을 싫어한다. 나는 이것이 가장 쉬운방법임에 동의하지만 잠재적으로 아주 위험하다. 비록 개발환경에서 새로 작성한 Role 을 테스트한다 할지라도, 이것이 프로덕트 환경에서 같은 결과를 얻는다는 것을 의미하지 않는다.
- Check mode – yes, check mode 는 실제로 check mode 없이 실행할 경우 무슨일을 했는지 결과를 알려주므로 Ansible 코드를 테스트하기에 좋은 방법이다. 그래서 여러분은 Ansible이 실행되면 여러분이 기대한 행동이 나오는지를 쉽게 볼 수 있다. 하지만 여기서 “그리고 스크립트 어떤가?” 라는 질문이 있다. 보통, 나는 대답으로 “그게 뭔데?” 라는 소리를 들는데, 만일 롤(Roles)과 플레이북(Playbook) 에 스크립트를 사용하지 않는다면 괜찮겠지만, Check Mode 는 스크립나 명령어를 실행할 수 없다는 것을 알아야 한다. 그것을 실행하기 위해서는, “check_mode: no”를 사용하여 특정 Task에 대한 Check Mode 를 비활성화해야 한다.
- Asserts – 나는 Python처럼 다른 언어를 테스트하는 방법과 비슷한 테스팅 메소드로 Assert 를 좋아하는데 중요한 것은 여러분의 시스템이 Check mode 와 같은 초안이 아닌 Task가 특정 자원을 원하는 상태로 변경했다는 실제 검증처럼 원하는 상태에 도달했는지 확인해준다.
요약하면, 단순하게 여러분이 선택을 설명해야할때 자신감을 가져라.(또, 누군가 이것들을 모두 사용하도록 기대하는 것은 현실적이지 않기 때문에 이 모두를 사용하지 마세요.
질문7
데이터베이스 그룹에(RedHat 으로 가정하고) 모든 서버에 PostgreSQL 설치하고 postgresql.conf.j2 템플릿으로 postgresql.conf 설정을 업데이트하는 Playbook 을 작성하시오.
추가로, 설정 업데이트 task만 실행하기 위해나 방법을 제시하라.(패키지 설치하지 않고..)
Answer
여기에는 놓치지 말아야할 두가지가 있다: handlers 와 tags. 여러분의 Playbook 은 다음과 비슷할 것이다.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
--- - name: Installing PostgreSQL hosts: databases vars: pg_packages: - postgresql - postgresql-client pg_service: postgresql pg_admin_user: postgres pg_admin_group: postgres pg_version: 1981 tasks: - name: Install PostgreSQL packages become: yes yum: name: "{{ item }}" state: latest loop: "{{ pg_packages }}" notify: - start_postgresql - name: Update postgres.conf file template: src: postgres.conf.j2 dest: /etc/postgresql/{{ pg_version }}/postgresql.conf owner: {{ pg_admin_user }} group: {{ pg_admin_group }} mode: 0644 become: yes notify: - restart postgresql tags: - postgres_config handlers: - name: start_postgresql service: name: "{{ pg_service }}" state: started - name: restart_postgresql service: name: "{{ pg_service }}" state: restarted |
보시는 봐와같이, 하나의 파일에 모든 것을 담았지만 더 좋은 해결법은 Roles 를 생성하게 하고 각 섹션들을 그들만의 디렉토리에(vars, handlers, tasks,…) 넣는 것이다. 나중에 Roles에 대한 상세한 질문과 답변을 하겠다.
첫째로 봐야할 것이 ‘Handler’다. Handler는 변화에 따른(보통 task) 트리거 액션을 수행한다. 위에서 본것처럼, 문법은 확실히 단순하다, ‘notify’ 키워드를 사용함으로서 실행을 위한 액션 리스트를 제공할 수 있다. 이것은 설치를 위해 필요한 메인 Task와 PostgreSQL 설정이 무엇인지, Task를 완료하는데 필요한 작은 “sub” 액션이 무엇인지를 명확하게 구분하게 해준다.
두번째로 봐야할 것은 ‘tags’다. 이것은 어떻게 설정 업데이트 부분만 실행하도록 하는지에 대한 질문의 두번째 부분에대한 답변이다. 여러분이 100 task를 가지고 있고 그들중에 아주 오직 작은부분만 실행되길 원있다고 가정하고 애플리케이션 업데이트를 담당하는 네가지 Task 를 가정해보자. tags 가 없다면, 여러분의 playbook 에서 모든것을 실행해야만하지만 tags를 사용하면 특정 tag 로 표시한 tag만 실행할 수 있다.
질문8
다른 값을 가진 여러 장소에서 같은 변수이름을(whoami) 사용한다고 생각해보자.
- role defaults -> whom:mario
- extra vars(-e 를 통해서 Ansible CLI 로 전달되는 변수들) -> whom:toad
- host facts -> whoami:luigi
- inventory variables(타입과 상관없다) -> whoami:browser
최종적으로 어느것을 사용해야 합니까? 왜?
Answer
정답은 ‘toad’ 다.
Variable precedence 는 변수들이 다른 위치에 있을때에 어떻게 변수들이 서로 오버라이드(override) 하는지에 대한 것이다. 만약 아직 여러분이 그것을 다루어보지 못했다면 어느시점에서 그것을 다룰것인데, 그것을 깨닫기에 유용한 주제다.
질문의 문맥에서, 순서는 extra vars(매번 모든 다른 변수를 오버라이드한다) -> host facts -> inventory variables -> role defaults (제일 약하다)
전체 목록은 위 링크에서 찾을 수 있다. 한가지 주의해야 할것은 Ansible 1.x 와 Ansible 2.x 는 아주 다르다.
질문9
여러분에게 Ansible 모범 사례로 친숙한 것 (적어도) 3가지는?
Answer
- 여러 파라메터를 사용할때에 YAML dictionary 포맷을 사용하는 것이 더 낫다. 나는 개인적으로 좀 더 읽기 편하다.
|
|
# BAD - name: Update postgres.conf file template: src=postgres.conf.j2 dest=/etc/postgresql/{{ pg_version }}/postgresql.conf owner={{ pg_admin_user }} group={{ pg_admin_group }} mode=0644 # GOOD - name: Update postgres.conf file template: src: postgres.conf.j2 dest: /etc/postgresql/{{ pg_version }}/postgresql.conf owner: {{ pg_admin_user }} group: {{ pg_admin_group }} mode: 0644 |
- “항상 태스크 이름을 사용하라”. 여러분이 ‘debug’ 모듈을 사용하는 것처럼 아주 단순한 것일지라도 매번 태스크를 추가할때마다 name 을 사용하는 것으로 얻을 수 있는 이득이 있다. task의 name은 왜 추가되었고 그것이 무엇을 하는지와 같은 어떤 정보를 제공한다. 알려진 버그를 해결할 수 있는 벙법일 수도 있고 길고 지루한 명령일 수도 있으므로 사용자가 playbook을 읽거나 사용할때에 간단하게 무엇을 하는지를 기술한다면 고마워할 것이다.
|
|
# BAD - template: src: postgres.conf.j2 dest: /etc/postgresql/{{ pg_version }}/postgresql.conf # GOOD - name: Update postgres.conf file template: src: postgres.conf.j2 dest: /etc/postgresql/{{ pg_version }}/postgresql.conf |
- Ansible 코드의 모든 변경은 ansible-lint 로 전달되어야 한다. 이것은 기본적으로 best-practices checker 인 또 다른 비공식 모범 사례다. This is why I consider it as one of the most important best practices to implement as it makes it easier to make sure other best practices are being followed, especially in a shared repository where you have several contributors(역, 모범 사례가 되기 위해서는 task 의 name 을 사용하는 것이 좋다. 여러 컨튜리뷰터들과 저장소를 공유할때에는 이러한 것이 모범 사례가 되게 만드는데 도움을 준다.
이미 언급한 바와같이, 언급된 모든 모범 사례가 공식적인(Ansible 문서) 것이 아니며 여러분이 그것이 왜 모범 사례인지를 설명할 수 있다면(좀 더 정확하게 좋은 연습사례) 그것으로 괜찮다.
질문10
“The inventory file is in <inventory_file_path> and the inventory groups are <inventory_groups>” 내용을 가지는 ‘/tmp/info’ 파일을 모든 호스트에 생성하는 Ansible Ad-Hoc command 를 작성하라
주의: 인벤토리 그룹에 포함된 호스트도 나열해야 한다.
Answer
Ansible 을 실행하는 다른 방법을 아는 것은 시간을 절약해 준다. 그중에 하나가 Ad-Hoc 방법인데, 원격 호스트에 빠르게 무엇이든 실행해준다.
이 경우에, ad-hoc command 는 다음과 같을 것이다.
|
|
ansible all -m copy -a 'content="The inventory file is in {{ inventory_dir }} and the inventory groups are {{ groups }}" dest=/tmp/info' |
-m은 모듈 이름을 지정하기 위한 것이다. 우리는 ‘copy’를 사용하지만, 동일한 결과를 얻기 위해서 다른 모듈을 사용할 수도 있다.
-a파일의 내용과 어디에 생성할지를 모듈에 전달하기 위한 아규먼트다.
나는 이것에 친숙해지기 위해, 실전에서 사용할때 충분히 편안함을 느낄수 있도록 ad-hoc command를 여러번 실행해 볼것을 권장한다.
질문11
ansible-pull 은 무엇인가? 어떻게 ansible-playbook 과 다른가?
Answer
우리는 ansible-playbook 을 실행하는 것이 컨트롤 노드로 알려진 호스트에서(우리가 명령을 실행하고 있는 노드) 운영중인 호스트에 어떤 설정을 강제한다는 것을 알고 있다.
ansible-pull 또한 설정을 적용하지만 컨트롤 호스트로부타가 아닌 관리 호스트로부터 실행된다. 이것은 주어진 URL 저장소로부터 설정을 pulling 한다.
이것은 여러분이 접속한 호스트에서 중앙 위치로부터 설정을 강제하는 Reversed Architecture 가 필요할때에 유용할 수 있다.
질문12
여러분은 디렉토리 목록을 가지고 있고 첫째로 발견한 디렉토리를 원격 서버로 복사하는 Task를 작성하기 원한다.
Answer
|
|
- name: Copy directory to a remote host synchronize: src: "{{ item }}" dest: "{{ ansible_env.HOME }}" with_first_found: - "/home/mario/dir1" - "/tmp/dir2" - "/tmp/dir3" |
역주: Ansible 2.7 에서는 없어진듯 보인다. 공식문서에서 검색했지만 나오지 않는다.
질문13
다이나믹 인벤토리는 무엇인가?
새로운 dynamic inventory 스크립트를 작성할 때 어떤 규칙을 따르는것이 중요한가?
Answer
라인을 추가/삭제하거나 수동으로 호스트이름 목록을 업데이트하는 default 혹은 static 인벤토리와 다르게, dynamic inventory 는 클라우드(Cloud)나 LDAP 과 같은 외부 소스로부터 정보를 추출함으로써 생성어된다. 대부분의 이러한 dynamic 저장소 스크립트는 contrib/inventory 디렉토리에서 찾을 수 있다.
새로운 동적 인벤토리를 개발할 때 ‘-list’인수를 사용하여 호출하면 해당 스크립트의 중요한 결과가 JSON 형식에 그룹을 출력한다. 다음과 같이 group:managed_hosts 처럼 할 수 있다.
|
|
{ "database":["host1", host2"], "web":["host3", "host4"], "video":["host5", "host6"] } |
혹은 다음과 같이 group:dict_of_variables 처럼 할 수 있다.
|
|
{ "databases": { "hosts": ["host1"], "vars": { "this_is_cool": true } }, "web": { "hosts": ["host2", "host3"], "vars": { "this_is_also_cool": true } } } |
물론, 두개를 혼합할 수 있다.
|
|
{ "databases": { "hosts": ["host1"], "vars": { "x": 2 } }, "app": ["host2", host3"] } |
dynamic inventory 에 대한 더 많은 정보는 여기서 찾을 수 있다.
질문14
파일의 전체 또는 상대 경로가(-e 와 함께 변수를 전달 함) 주어지면 다음을 수행하십시오.
- 현재 작업 디렉토리나 주어진 위치에서 찾아라.
- 만일 파일을 찾을 수 있다면, 리모트 호스트 사용자 홈 디렉토리에 그것을 복사하라. 만일 파일을 찾지 못할 경우, run/execution 은 실패로 처리하라.
Answer
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
name: find a given file find: file_type: file pattern: "{{ given_path | basename }}" paths: - "{{ lookup('env', 'PWD') }}/{{ given_path | dirname }}" - "{{ given_path | expanduser | dirname }}" register: find_results delegate_to: localhost - name: fail when file was not found fail: msg: "Unable to find the file: {{ given_path | basename }}" when: given_path|default('') and find_results.matched == 0 - name: copy file to remote host vars: file_src: "{{ find_results.files[0].path }}" copy: src: "{{ file_src }}" dest: "{{ ansible_env.HOME }}" |
질문15
Apache 설치를 위한 롤을 작성하라.
Answer
나는 이 질문이 인터뷰에서 아주 인기 있는 질문이라고 생각한다. 왜냐하면 ‘role’은 Ansible의 핵심 컴포넌트이며 이것은 앞에 질문에서 논의했던 tasks, templates 그리고 variables 와같은 많은 컴포넌트들을 사용하도록 만들기 때문이다.
이 질문에 대한 하나 이상의 답이 있다는 점에 주의해야 한다. 나는 짧지만 포괄적인 답을 제공할 것이다. role 에서 모든 디렉토리를 사용하는 자세한 대답은 아마도 추가 점수를 줄 것이다.
구조부터 시작하자.
|
|
apache-role/ vars/ handlers/ tasks/ defaults/ meta/ |
이것은 매우 표준적인 구조지만 여러분은 각 디렉토리가 왜, 무엇을 위해 사용되고 이 케이스에서 Apache 설치를 어떻게 구현하는지 익숙해질 필요가 있다.
이것은 매우 표준적인 구조지만 여러분은 각 디렉토리가 왜, 무엇을 위해 사용되고 이 케이스에서 Apache 설치를 어떻게 구현하는지 익숙해질 필요가 있다.
vars 를 시작해보자. vars 는 우리가 role 에서 사용할 모든 변수를 가진다. 무엇이 변수일 수 있나? 만약 우리가 서로다른 운영체제에 이 role 을 사용할것이라면, apache2의 서비스 이름은 변수일 수 있다. Fedora에서, 서비스 이름은 httpd 일 것이지만 Debian 에서는 apache2 로 부른다. 또 다른 변수로 각 운영체제에 패키지를 설치해기 위해 정의한 apache2_packages 일 수도 있다. 어떻게 이것을 구현하는지 보자.
|
|
apache-role/ vars/ RedHat.yml Debian.yml |
RedHat.yml 살펴보자.
|
|
--- # This file is vars/RedHat.yml apache2_service: httpd apache2_packages: - 'httpd' - 'httpd-devel' |
Debian.yml 살펴보자.
|
|
--- # This file is vars/Debian.yml apache2_service: apache2 apache2_packages: - 'apache2' - 'httpd-devel' |
이제 Handler 로 가보자. Handler 는 어떤 변화(Change)에 따라 트리거되는 액션이다. 이 경우, 아주 흔한 handler 로 ‘restart service’ 일 수 있다.
|
|
--- # This file is handlers/main.yml - name: Restart apache2 service: name: "{{ apache2_service }}" state: 'started' |
이 handler 는 설정에 변경이 있은 후에 apache2 시작을 위해서 사용되어질 수 있다. {{ apache2_service }} 는 RedHat.yml 과 Debian.yml 에 정의되어 있음을 기억해라.
다음으로, 우리는 defaults/main.yml 에서 기본 변수들을 정의할 것이다.
|
|
apache2_listen_port: 80 apache2_listen_port_ssl: 443 |
만약 defaults 와 vars 차이에 의문이 든다면 여러분은 default를 모든 타입의 운영체제나 시나리오에 사용하기 위한 공통변수로 생각해야 한다. 반면에, vars 는 특별한 환경/케이스에 사용하기 위해 수정된 변수들이다. 이 경우 운영체제 타입이다.
meta folder 는 role 에서 별도의 행동을 정의하기 위한 장소처럼 행동한다. 일반적으로 대부분 role 의존성을 정의하는데 사용한다. 이것은 role 이 다른 role 에 의존성이 있는 경우인데, 예를들어 자바(Java) 기반 애플리케이션 설치하는데 설치된 자바가 필요한 것이다. 이 예제를 만들어보면 우리는 두개의 role 을 가질것이다.
- Java 설치 role
- Elasticsearch 설치 role
우리의 play 는 다음과 같을 것이다.
|
|
- hosts: elasticsearch roles: - { role: java, version: 8 } - elasticsearch |
하지만 우리는 다른 사람과 role들을 공유하는 걸 좋아하기 때문에, ElasticSearch role을 사용하고자하는 유저는 ‘Java’ 라는 다른 role 을 의존성을 모를 수 있다. 따라서 meta folder에 다음과 같이 라인을 추가해줘야 한다.
|
|
--- # This file is meta/main.yml dependencies: - { role: java, version: 8 } |
이것은 ‘elasticsearch’ role 을 불러오기 전에 ‘java’ role 을 시도하고 실행할 것이다. 이것은 이전의 play 를 재작성하도록 해준다.
|
|
- hosts: elasticsearch roles: - elasticsearch |
최종적으로, 우리는 몇개의 task들을 정의할 것이다. role의 핵심은, 무엇을 실행시킬 것인지를 정의하는 부분이다. 우리는 목적에 기반한 추가적인 task 를 포함하는 단순한 메인 파일을 가질 것이고 OS 타입에 따라서 그것이 동작할 것이다. 올바른 패키지를 설치하기 위해서, 우리는 각 OS에마다 사용할 이전에 정의했던 변수들을 포함할 것이다.
|
|
# This is tasks/main.yml file - name: Include OS variables include_vars: "{{ ansible_os_family }}.yml" - name: Install Apache include_tasks: "install-{{ ansible_os_family }}.yml" |
이제, install-RedHat.yml을 살펴보자.
|
|
# This is tasks/install-RedHat.yml - name: Install Apache become: yes yum: name: "{{ item }}" state: present with_items: "{{ apache2_packages }}" |
최종적으로, 이것이 앞에 모든 파일들을 생성한 이후 구조다.
|
|
apache-role/ vars/ Debian.yml RedHat.yml handlers/ main.yml tasks/ main.yml install-RedHat.yml defaults/ main.yml meta/ main.yml |
기억해라, 이것은 완전한 해결책이 아니며 당신이 더 장황하고 상세한 답변을 줄수록, 당신은 더 많은 신뢰를 얻을 것이다.예를들어, 설정을 위해 템플릿을 가지는 템플릿 디렉토리을 추가하거나 Apache 설정 Task 추가등이다.
질문16
여러분은 다음의 play 를 가진다.
|
|
--- - name: Print variable hosts: localhost tasks: - name: Print test variable debug: msg: "{{ test }}" |
그리고 여러분은 다음의 command 를 실행한다.
|
|
ansible-playbook -e test="test 1 2 3" debug.yaml |
test 변수의 출력값은 무엇인가?
- test 1 2 3
- test
- empty string
- the variable is not defined
Answer
대답은 ‘test’다.
이것은 속임수이고 여러분이 shell 과 Ansible을 이해하고 있는지를 체크한다. 이 경우에, command는 shell에 의해서 우선 처리 때문에, 인용문의 내용과 백슬래쉬와 빈공백 이후의 모든것은 무시된다.
면접관으로서, 여러분은 대부분의 면접자들이 이것에 올바른 대답을 못것인지 아니면 단순한 추측은 아닌지 알아야 하며 이것이 Ansible에 익숙한지 아닌지를 나타내는 지표는 아니다.
해결책은 전체적으로 ‘-e’ 이후에 내용을 인용하는 것이다.
|
|
ansible-playbook -e 'test="test 1 2 3"' debug.yaml |
질문17
오직 task 이름들만 표시하도록 Ansible 실행의 출력 포맷을 어떻게 변경할 것인가?
Answer
해답은 “callback plugin” 이다. 여러분이 알고 있는 것만 바꿀것만 아니라 Ansible 에서 다른 이벤트를 기반으로 여러분이 원하는 모든것을 할 수 있다. 그래서 유사한 질문이 있을 수 있다: “어떻게 파일에 모든 것을 기록할 수 있나?” 그리고 대답은 여전히 callback plugin 일 수 있다.
여기에는 여러분이 callback plugins 에 대해서 알아야할 몇가지 포인트가 있다.
-
- Ansible 트리에 몇가지 callback plugins 가 있다.
- callback plugin을 활성화하기 위해서, ansible.cfg 에 다음과 같은 것을 포함해야 한다.
|
|
callback_whitelist = my_cool_plugin |
-
- Ansible 실행에 기본 표준 출력을 바꾸기 위해서는, ansible.cfg 를 다음과 같이 바꿔라.
|
|
stdout_callback = my_new_stdout_callback_plugin |
- 새로운 callback plugin 을 개발할때, 부모 클래스 “CallbackBase” 로부터 상속이 필요하며 다음의 메소드를 오버라이드(override) 해야 한다.
- v2_runner_on_skipped
- v2_runner_on_unreachable
- v2_runner_on_ok
- v2_runner_on_failed
Callback plugin 은 여러분의 Ansible 실행을 커스터마이징을 위한 좋은 방법이고 여러분이 Ansible 아웃풋(Output)을 소비하는 방법이다.
질문18
다음의 컨텐츠를 포함하는 파일 ‘/tmp/excercise’ 가 있다.
|
|
Goku = 9001 Vegeta = 5200 Trunks = 6000 Gotenks = 32 |
하나의 Task 를 가지고, 다음과 같이 컨텐츠를 바꿔라.
|
|
Goku = 9001 Vegeta = 250 Trunks = 40 Gotenks = 32 |
Answer
|
|
--- - name: Change saiyans level lineinfile: dest: /tmp/exercise regexp: "{{ item.regexp }}" line: "{{ item.line }}" with_items: - { regexp: '^Vegeta', line: 'Vegeta = 250' } - { regexp: '^Trunks', line: 'Trunks = 40' } |
새로운 컨셉이 아닌, 두개의 아이템을 매번 반복하는 곳에서 약간의 loop 문을 응용한 것이다. (regexp 과 line)
주목할 것은 이 문제를 ‘blockinfile’ 로 해결할 수도 있다.
질문19
문자열을 대문자로 바꾸는 필터를 작성해라.
|
|
ansible localhost -m debug -a 'msg="{{ "i love pizza" | cap }}"' localhost | SUCCESS => { "msg": "I love pizza" } |
Answer
|
|
def cap(self, string): return string.capitalize() |
우리는 매우 단순한 필터(filter)를 작성했다. 필터를 작성하는 Ansbile 을 마스터할때 자신의 것으로 하고 싶은 좋은 스킬인데, 거기에는 몇가지 이유가 있다.
첫째로, 믿던 안 믿던, 필터는 몇몇 게이스에서 여러분의 playbook 들을 좀 더 읽기편하게 해준다. 특히, 여러분이 아주 긴 명령어를 사용할때 사용자는 무엇을 왜 작성했는지 이해하는데 몇분이 소요된다. ‘hostname_to_ip’ 는 이해하기 아주 쉽다. right?
게다가, Ansible 의 모든 것을 맹목적으로 사용하지 마라. 이런것이 2차면접에서 의미있는 것은 아니다. 다른 사람이 이해하기 쉽고 성능에 영향을 미치지 않지만 어떤 경우에도 이를 고수하지 않을 경우 가능하면 Ansible 을 사용해라.
질문20
마지막 질문은 질문 요약이다. 10개의 지문이 있고 그것이 true 나 false 인지를 정해라.
-
- Module은 Task 의 집합이다.
- 특정한 Module 대신에 shell 이나 command 를 사용하는게 낫다.
- Host 팻츠(facts)는 play 변수들을 무시한다.
- Role 은 vars, meta 그리고 handler 를 포함할 수도 있다.
- 다이나믹 인벤토리는 외부 소스로부터 정보룰 추출함으로써 생성된다.
- 4칸 보다 2칸의 들여쓰기를 사용하는 것이 좋은 모범 사례다.
- 다음의 Task 는 성공적으로 실행될 것이다.
|
|
- name: Install zlib yum: name: zlib state: present |
- ‘notify’ 는 Handler 를 트리거(Trigger)하는데 사용 된다.
- “hosts:all:!controllers” 는 ‘hosts 그룹에 controller 만 실행하라’ 라는 것이다.
- 기본 Role 은 role 변수를 무시한다.
Answer
- False play 는 Task들의 집합이다. Task 는 특정 모듈(Module)을 실행하는 것이다.
- False Shell 이나 Command 를 사용하는 것 좀 더 빠를 수 있지만, 일반적으로 Ansible 사용자를 위해서 더 쉽게 읽을수 있도록 언제나 특정 모듈을 사용하는 것이 좋습니다.
- False Play 변수들은 host 팻츠(Facts) 를 무시한다.
- True
- True OpenStack 과 같은 클라우드나 LDAP 일 수도 있다.
- False 이것은 정말 말이 안된다.
- Depends playbook 이나 role dl ‘become: yes’ 를 가지고 있다면, 이것은 성공적으로 실행되겠지만 그렇지 않다면 퍼미션때문에 실패할 것이다.
- True
- False Controller 들을 제외한 모든 hosts 를 대상으로 실행하라는 뜻이다.
- False Role 변수들은 role 기본값을 무시한다.
Practice is everything
여러분이 대부분의 질문에 올바르게 대답할 수 있었다면,이것은 Ansible 컨셉과 사용에 여러분이 익숙해 있다는 것을 확실하게 말해준다. 하지만 기억해야한다. 인터뷰 질문에 답하는것만이 아닌 연습만이 최고다.
더 많은 인터뷰 질문들
더 많은 인터뷰 질문이나 Ansible 을 배울때 검토할 주제의 체크리스트는 Github 저장소를 방문해라.
