나는 다른 사람의 Ansible 코드에 대한 리뷰를 많이 하고, 직접 작성도 많이 합니다. 실수(다른 사람의 실수와 내 실수 모두)와 여러 인터뷰를 분석하는 과정에서 나는 Ansible 사용자가 저지르는 주요 실수를 깨달았습니다. 그들은 기본을 마스터하지 못한 채 복잡한 일에 빠져든다는 것입니다.

이러한 보편적인 불의를 바로잡기 위해 나는 이미 Ansible을 알고 있는 사람들을 위해 Ansible에 대한 소개를 작성하기로 결정했습니다. 나는 경고합니다. 이것은 사람의 이야기를 다시 한 것이 아닙니다. 이것은 많은 글자와 그림이 없는 장문의 책입니다.

독자가 기대하는 수준은 이미 수천 줄의 얌라가 작성되었고, 무언가가 이미 제작 중이지만 "어쩐지 모든 것이 비뚤어져 있다"는 것입니다.

제목

Ansible 사용자가 저지르는 가장 큰 실수는 무엇인지 모르는 것입니다. 이름을 모르면 설명서의 내용을 이해할 수 없습니다. 살아있는 예: 인터뷰 중에 Ansible에서 많은 글을 썼다고 말하는 듯한 사람이 “플레이북은 어떤 요소로 구성되어 있습니까?”라는 질문에 대답하지 못했습니다. 그리고 내가 “대답은 플레이북으로 구성될 것으로 예상됐다”고 제안하자 “우리는 그것을 사용하지 않는다”는 욕설이 뒤따랐다. 사람들은 돈을 위해 Ansible을 작성하고 놀이를 사용하지 않습니다. 그들은 실제로 그것을 사용하지만 그것이 무엇인지 모릅니다.

그럼 간단한 것부터 시작해 보겠습니다. 이름이 무엇인가요? 아마도 당신은 이것을 알고 있을 수도 있고, 문서를 읽을 때 주의를 기울이지 않았기 때문에 모를 수도 있습니다.

ansible-playbook은 플레이북을 실행합니다. 플레이북은 yml/yaml 확장자를 가진 파일로, 그 안에는 다음과 같은 내용이 있습니다.

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

우리는 이 전체 파일이 플레이북이라는 것을 이미 깨달았습니다. 역할이 어디에 있고 작업이 어디에 있는지 보여줄 수 있습니다. 그런데 놀이는 어디에 있나요? 그리고 놀이와 역할 또는 플레이북의 차이점은 무엇입니까?

그것은 모두 문서에 있습니다. 그리고 그들은 그것을 그리워합니다. 초보자 - 너무 많아서 한 번에 모든 것을 기억할 수 없기 때문입니다. 경험이 풍부한 - "사소한 것" 때문입니다. 경험이 있는 경우 이 페이지를 최소한 XNUMX개월에 한 번씩 다시 읽으면 귀하의 코드가 동급 최고의 코드가 될 것입니다.

따라서 기억하세요. 플레이북은 플레이와 플레이로 구성된 목록입니다. import_playbook.
이것은 하나의 연극입니다:

- hosts: group1
  roles:
    - role1

그리고 이것은 또 다른 연극이기도 합니다:

- hosts: group2,group3
  tasks:
    - debug:

놀이란 무엇인가? 그녀는 왜요?

플레이는 플레이북의 핵심 요소입니다. 왜냐하면 플레이 앤 플레이는 역할 및/또는 작업 목록을 실행해야 하는 호스트 목록과 연결하기 때문입니다. 문서의 깊은 곳에서 다음 사항에 대한 언급을 찾을 수 있습니다. delegate_to, 로컬 조회 플러그인, 네트워크 CLI별 설정, 점프 호스트 등 작업이 수행되는 장소를 약간 변경할 수 있습니다. 하지만 잊어버리세요. 이러한 영리한 옵션은 각각 매우 특정한 용도로 사용되며 확실히 보편적이지 않습니다. 그리고 모두가 알고 활용해야 할 기본적인 것들에 대해 이야기하고 있습니다.

"뭔가" "어딘가"를 수행하고 싶다면 연극을 씁니다. 역할이 아닙니다. 모듈과 대리인이 있는 역할이 아닙니다. 당신은 그것을 가지고 연극을 씁니다. 호스트 필드에는 실행할 위치를 나열하고 역할/작업에는 실행할 항목을 나열합니다.

간단하죠? 그렇지 않으면 어떻게 될 수 있습니까?

놀이를 통해서가 아니라 이를 하고 싶은 욕구가 생기는 특징적인 순간 중 하나는 '모든 것을 설정하는 역할'입니다. 첫 번째 유형의 서버와 두 번째 유형의 서버를 모두 구성하는 역할을 갖고 싶습니다.

전형적인 예는 모니터링입니다. 모니터링을 구성하는 모니터링 역할을 갖고 싶습니다. 모니터링 역할은 플레이에 따라 모니터링 호스트에 할당됩니다. 그러나 모니터링을 위해서는 모니터링 중인 호스트에 패키지를 전달해야 한다는 것이 밝혀졌습니다. 대리자를 사용하지 않는 이유는 무엇입니까? iptables도 구성해야 합니다. 대리자? 또한 모니터링을 활성화하려면 DBMS에 대한 구성을 작성/수정해야 합니다. 대리자! 그리고 창의력이 부족하면 대표단을 만들 수도 있어요 include_role 그룹 목록 및 내부에서 까다로운 필터를 사용하여 중첩 루프에서 include_role 당신은 더 많은 것을 할 수 있습니다 delegate_to 다시. 그리고 우리는 간다...

"모든 것을 수행하는" 하나의 모니터링 역할을 갖고자 하는 좋은 소망은 우리를 완전한 지옥으로 이끈다. 여기서 탈출구는 단 하나뿐인 경우가 많다. 모든 것을 처음부터 다시 작성하는 것이다.

여기서 실수는 어디서 발생했나요? 호스트 X에서 작업 "x"를 수행하려면 호스트 Y로 가서 거기서 "y"를 수행해야 한다는 사실을 발견한 순간 간단한 연습을 수행해야 했습니다. 가서 호스트 Y에서 y를 수행하는 play를 작성해야 합니다. "x"에 뭔가를 추가하지 말고 처음부터 다시 작성하세요. 하드코딩된 변수에도 마찬가지입니다.

위 문단의 내용은 모두 맞는 것 같습니다. 하지만 이것은 당신의 경우가 아닙니다! DRY 및 라이브러리와 같은 재사용 가능한 코드를 작성하고 싶고 이를 수행하는 방법에 대한 방법을 찾아야 하기 때문입니다.

여기에 또 다른 심각한 실수가 숨어 있습니다. 많은 프로젝트를 견딜 수 있게 작성된 것(더 나을 수 있지만 모든 것이 작동하고 완료하기 쉽습니다)을 작성자조차도 이해할 수 없는 완전한 공포로 만든 오류입니다. 그것은 효과가 있지만 하나님께서는 당신이 아무것도 바꾸는 것을 금지하셨습니다.

오류: 역할은 라이브러리 함수입니다. 이 비유는 좋은 시작을 너무 많이 망쳤기 때문에 보기만 해도 슬프다. 역할은 라이브러리 기능이 아닙니다. 그녀는 계산을 할 수 없고 플레이 수준의 결정을 내릴 수 없습니다. 놀이가 어떤 결정을 내리는지 알려주세요.

고마워요, 당신 말이 맞아요. Play는 어떤 호스트에서 어떤 작업과 역할을 수행할지 결정합니다(보다 정확하게는 정보 포함).

이 결정을 역할에 위임하고 심지어 계산을 수행하더라도 자신(및 코드를 구문 분석하려는 사람)을 비참한 존재로 파멸시키는 것입니다. 역할은 수행되는 위치를 결정하지 않습니다. 이 결정은 플레이로 이루어집니다. 역할은 말한 대로, 말한 곳에서 수행됩니다.

Ansible로 프로그래밍하는 것이 왜 위험한지, 그리고 왜 COBOL이 Ansible보다 나은지 이 장에서 변수와 진자에 대해 이야기하겠습니다. 지금은 한 가지만 가정해 보겠습니다. 각 계산은 전역 변수에 지울 수 없는 변경 흔적을 남기며 이에 대해 아무것도 할 수 없습니다. 두 개의 "흔적"이 교차하자마자 모든 것이 사라졌습니다.

비꼬는 사람에 대한 참고 사항: 역할은 확실히 제어 흐름에 영향을 미칠 수 있습니다. 먹다 delegate_to 합리적인 용도로 사용됩니다. 먹다 meta: end host/play. 하지만! 우리가 기본을 가르치는 것을 기억하시나요? 잊어버린 것 delegate_to. 우리는 가장 단순하고 아름다운 Ansible 코드에 대해 이야기하고 있습니다. 읽기 쉽고, 쓰기 쉽고, 디버그하기 쉽고, 테스트하기 쉽고, 완료하기 쉽습니다. 다시 한 번:

플레이하고 플레이만이 어떤 호스트에서 무엇을 실행할지 결정합니다.

이 섹션에서는 놀이와 역할 사이의 대립을 다루었습니다. 이제 작업과 역할의 관계에 대해 이야기해 보겠습니다.

임무와 역할

놀이를 고려해보세요:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

foo를 수행해야 한다고 가정해 보겠습니다. 그리고 그것은 다음과 같습니다 foo: name=foobar state=present. 이건 어디에 써야 하나요? 미리? 우편? 역할을 만드시겠습니까?

...그리고 작업은 어디로 갔나요?

우리는 다시 기본, 즉 플레이 장치부터 시작합니다. 이 문제에 얽매이면 놀이를 다른 모든 것의 기초로 삼을 수 없으며 결과는 "불확실"할 것입니다.

재생 장치: 호스트 지시어, 재생 자체 및 pre_tasks 설정, 작업, 역할, post_tasks 섹션. 플레이를 위한 나머지 매개변수는 이제 우리에게 중요하지 않습니다.

작업 및 역할이 포함된 섹션의 순서: pre_tasks, roles, tasks, post_tasks. 의미상 실행 순서는 다음과 같습니다. tasks и roles 명확하지 않은 경우 모범 사례에 따르면 섹션을 추가한다고 합니다. tasks, 그렇지 않은 경우에만 roles. 있을 경우 roles, 첨부된 모든 작업은 섹션에 배치됩니다. pre_tasks/post_tasks.

남은 것은 모든 것이 의미적으로 명확하다는 것입니다. pre_tasks, 그 다음에 roles, 그 다음에 post_tasks.

하지만 우리는 아직 질문에 대답하지 않았습니다. 모듈 호출은 어디에 있습니까? foo 쓰다? 각 모듈에 대한 전체 역할을 작성해야 합니까? 아니면 모든 면에서 두꺼운 역할을 맡는 것이 좋을까요? 역할이 아니라면 사전 또는 사후 어디에 작성해야 합니까?

이러한 질문에 대한 합리적인 대답이 없다면 이는 직관이 부족하다는 신호, 즉 동일한 "흔들리는 기초"입니다. 그것을 알아 봅시다. 첫째, 보안 질문입니다. 플레이가 pre_tasks и post_tasks (그리고 작업이나 역할이 없습니다.) 다음에서 첫 번째 작업을 수행하면 문제가 발생할 수 있습니다. post_tasks 끝까지 옮길게요 pre_tasks?

물론, 질문의 표현은 그것이 깨질 것임을 암시합니다. 하지만 정확히 무엇입니까?

... 핸들러. 기본 사항을 읽으면 중요한 사실을 알 수 있습니다. 모든 핸들러는 각 섹션 후에 자동으로 플러시됩니다. 저것들. 모든 작업 pre_tasks, 알림을 받은 모든 핸들러입니다. 그런 다음 모든 역할과 해당 역할에서 알림을 받은 모든 핸들러가 실행됩니다. 후에 post_tasks 그리고 그들의 핸들러.

따라서 작업을 다음에서 드래그하면 post_tasks в pre_tasks, 그러면 잠재적으로 핸들러가 실행되기 전에 실행할 것입니다. 예를 들어, 만약에 pre_tasks 웹 서버가 설치 및 구성되었으며 post_tasks 무언가가 전송된 다음 이 작업을 섹션으로 전송합니다. pre_tasks "전송" 시 서버가 아직 실행되지 않고 모든 것이 중단된다는 사실로 이어집니다.

이제 다시 생각해 봅시다. 왜 필요한가요? pre_tasks и post_tasks? 예를 들어, 역할을 수행하기 전에 필요한 모든 것(핸들러 포함)을 완료하기 위해. ㅏ post_tasks 역할(핸들러 포함) 실행 결과로 작업할 수 있습니다.

기민한 Ansible 전문가가 그것이 무엇인지 알려줄 것입니다. meta: flush_handlers, 그러나 재생 중인 섹션의 실행 순서에 의존할 수 있다면 왜 플러시_handler가 필요한가요? 게다가, 메타: 플러시_핸들러를 사용하면 중복 핸들러로 인해 예상치 못한 일이 발생할 수 있으며, 사용할 때 이상한 경고가 표시될 수 있습니다. when у block 등. 앤서블을 더 잘 알수록 "까다로운" 솔루션에 대해 더 많은 뉘앙스를 지정할 수 있습니다. 그리고 사전/역할/사후 간의 자연스러운 구분을 사용하는 간단한 솔루션은 미묘한 차이를 유발하지 않습니다.

그리고 'foo'로 돌아갑니다. 어디에 넣어야 하나요? 사전, 게시물 또는 역할에서? 분명히 이는 foo에 대한 핸들러 결과가 필요한지 여부에 따라 다릅니다. 거기에 없으면 foo를 pre나 post에 배치할 필요가 없습니다. 이 섹션은 코드 본체 앞과 뒤에 작업을 실행한다는 특별한 의미를 갖습니다.

이제 "역할 또는 작업"이라는 질문에 대한 대답은 이미 진행 중인 작업으로 귀결됩니다. 작업이 있으면 작업에 추가해야 합니다. 역할이 있는 경우 역할을 생성해야 합니다(하나의 작업에서도). 작업과 역할은 동시에 사용되지 않는다는 점을 상기시켜 드리겠습니다.

Ansible의 기본 사항을 이해하면 겉보기에 취향에 대한 질문에 대한 합리적인 답변을 얻을 수 있습니다.

작업 및 역할(XNUMX부)

이제 막 플레이북을 작성하기 시작할 때의 상황에 대해 논의해 보겠습니다. foo, bar, baz를 만들어야 합니다. 이 세 가지 임무는 하나의 역할입니까, 아니면 세 가지 역할입니까? 질문을 요약하자면, 어느 시점부터 역할 작성을 시작해야 합니까? 태스크를 작성할 수 있는데 역할 작성의 요점은 무엇입니까?... 역할이란 무엇입니까?

가장 큰 실수 중 하나(이에 대해서는 이미 이야기했습니다)는 역할을 프로그램 라이브러리의 함수와 같다고 생각하는 것입니다. 일반적인 함수 설명은 어떤 모습인가요? 입력 인수를 받아들이고, 부작용과 상호 작용하고, 부작용을 수행하고, 값을 반환합니다.

자, 주목하세요. 이 역할에서 무엇을 할 수 있습니까? 부작용을 호출하는 것은 언제든지 환영합니다. 이것이 전체 Ansible의 본질입니다. 즉, 부작용을 생성하는 것입니다. 부작용이 있습니까? 초등학교. 그러나 "값을 전달하고 반환하는" 방법은 작동하지 않습니다. 첫째, 역할에 값을 전달할 수 없습니다. 역할의 vars 섹션에서 플레이의 수명 크기를 포함한 전역 변수를 설정할 수 있습니다. 역할 내에서 수명이 다한 전역 변수를 설정할 수 있습니다. 또는 플레이북의 수명이 다하더라도(set_fact/register). 그러나 "지역 변수"는 가질 수 없습니다. "값을 가져오고" "반환"할 수 없습니다.

가장 중요한 점은 부작용을 일으키지 않고 Ansible에서 무언가를 작성할 수 없다는 것입니다. 전역 변수를 변경하는 것은 항상 함수의 부작용입니다. 예를 들어 Rust에서 전역 변수를 변경하는 것은 다음과 같습니다. unsafe. 그리고 Ansible에서는 역할의 가치에 영향을 미치는 유일한 방법입니다. 사용된 단어에 주목하세요: "역할에 값을 전달"하는 것이 아니라 "역할이 사용하는 값을 변경합니다". 역할 간에는 분리가 없습니다. 작업과 역할 사이에는 분리가 없습니다.

총계 : 역할은 기능이 아니다.

역할의 어떤 점이 좋은가요? 먼저, 역할에는 기본값이 있습니다./default/main.yaml), 둘째, 역할에는 파일을 저장하기 위한 추가 디렉터리가 있습니다.

기본값의 이점은 무엇입니까? Ansible의 다소 왜곡된 가변 우선순위 테이블인 Maslow의 피라미드에서는 역할 기본값이 가장 낮은 우선순위(Ansible 명령줄 매개변수 제외)이기 때문입니다. 즉, 기본값을 제공해야 하고 기본값이 인벤토리 또는 그룹 변수의 값을 재정의하는 것에 대해 걱정하지 않으려면 역할 기본값이 유일하게 적합한 위치임을 의미합니다. (조금 거짓말하고 있어요. 더 있어요 |d(your_default_here), 그러나 고정된 장소에 대해 이야기하면 역할 기본값만 사용됩니다).

역할의 또 다른 장점은 무엇입니까? 왜냐하면 그들은 자신의 카탈로그를 가지고 있기 때문입니다. 이는 상수(예: 역할에 대해 계산됨) 및 동적(패턴 또는 안티패턴이 있음) 변수에 대한 디렉토리입니다. include_vars 함께 {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). 다음은 디렉토리입니다. files/, templates/. 또한, 자신만의 모듈과 플러그인을 가질 수 있습니다(library/). 그러나 플레이북의 작업(이 모든 것을 포함할 수도 있음)과 비교할 때 여기서 유일한 이점은 파일이 하나의 더미에 덤프되지 않고 여러 개의 별도 더미에 덤프된다는 것입니다.

한 가지 더 자세한 내용은 갤럭시를 통해 재사용할 수 있는 역할을 생성해 볼 수 있다는 것입니다. 컬렉션의 출현으로 역할 분배는 거의 잊혀진 것으로 간주될 수 있습니다.

따라서 역할에는 두 가지 중요한 기능이 있습니다. 즉, 기본값(고유한 기능)이 있고 코드를 구조화할 수 있게 해줍니다.

원래 질문으로 돌아가서: 언제 작업을 수행하고 언제 역할을 수행합니까? 플레이북의 작업은 역할 전/후의 "접착제"로 사용되거나 독립적인 구성 요소로 가장 자주 사용됩니다(그러면 코드에 역할이 없어야 합니다). 역할과 혼합된 일반적인 작업 더미는 모호하지 않은 엉성함입니다. 업무나 역할 등 특정 스타일을 고수해야 합니다. 역할은 엔터티와 기본값을 분리하고 작업을 통해 코드를 더 빠르게 읽을 수 있도록 해줍니다. 일반적으로 보다 "정적인"(중요하고 복잡한) 코드가 역할에 배치되고 보조 스크립트는 작업 스타일로 작성됩니다.

import_role을 작업으로 수행하는 것도 가능하지만, 이 글을 쓴다면 왜 이 일을 하고 싶은지 자신의 미의식에 설명할 준비를 하세요.

기민한 독자는 역할이 역할을 가져올 수 있고 역할이 galaxy.yml을 통해 종속성을 가질 수 있으며 끔찍하고 끔찍한 일도 있다고 말할 수 있습니다. include_role — 우리는 체조가 아닌 기본적인 Ansible의 실력을 향상시키고 있음을 상기시켜드립니다.

핸들러 및 작업

또 다른 분명한 사실인 핸들러에 대해 논의해 보겠습니다. 올바르게 사용하는 방법을 아는 것은 거의 예술입니다. 핸들러와 드래그의 차이점은 무엇입니까?

기본 사항을 기억하고 있으므로 예는 다음과 같습니다.

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

역할의 핸들러는 rolename/handlers/main.yaml에 있습니다. 핸들러는 모든 플레이 참가자 사이를 뒤집니다. pre/post_tasks는 역할 핸들러를 가져올 수 있고 역할은 플레이에서 핸들러를 가져올 수 있습니다. 그러나 핸들러에 대한 "교차 역할" 호출은 사소한 핸들러를 반복하는 것보다 훨씬 더 많은 문제를 발생시킵니다. (모범 사례의 또 다른 요소는 핸들러 이름을 반복하지 않는 것입니다.)

주요 차이점은 작업이 항상 (멱등적으로) 실행된다는 점입니다(더하기/빼기 태그 및 when) 및 핸들러 - 상태 변경에 따라(변경된 경우에만 알림이 실행됨) 이것은 무엇을 의미 하는가? 예를 들어 다시 시작할 때 변경 사항이 없으면 핸들러가 없다는 사실입니다. 생성 작업에 변경 사항이 없는데 핸들러를 실행해야 하는 이유는 무엇입니까? 예를 들어, 문제가 발생하고 변경되었지만 실행이 핸들러에 도달하지 못했기 때문입니다. 예를 들어 네트워크가 일시적으로 중단되었기 때문입니다. 구성이 변경되었지만 서비스가 다시 시작되지 않았습니다. 다음에 시작할 때 구성은 더 이상 변경되지 않으며 서비스는 이전 버전의 구성으로 유지됩니다.

구성 상황은 해결될 수 없습니다(보다 정확하게는 파일 플래그 등을 사용하여 특별한 재시작 프로토콜을 만들 수 있지만 이는 더 이상 어떤 형태로든 '기본 앤서블'이 아닙니다). 하지만 또 다른 일반적인 이야기가 있습니다. 우리는 애플리케이션을 설치하고 기록했습니다. .service-file, 이제 우리는 그것을 원합니다 daemon_reload и state=started. 그리고 이에 대한 자연스러운 장소는 핸들러인 것 같습니다. 그러나 핸들러가 아니라 작업 목록이나 역할의 끝에 작업으로 만들면 매번 멱등적으로 실행됩니다. 플레이북이 중간에 깨졌더라도 말이죠. 이것은 다시 시작된 문제를 전혀 해결하지 못하지만(멱등성이 손실되었기 때문에 다시 시작 속성으로 작업을 수행할 수 없습니다), 확실히 state=started를 수행할 가치가 있습니다. 플레이북의 전반적인 안정성이 증가하기 때문입니다. 연결 수와 동적 상태가 감소합니다.

핸들러의 또 다른 긍정적인 특성은 출력을 막지 않는다는 것입니다. 변경 사항이 없었습니다. 추가로 건너뛰거나 출력에 문제가 없었으므로 읽기가 더 쉽습니다. 이는 부정적인 속성이기도 합니다. 선형적으로 실행되는 작업의 첫 번째 실행에서 오타를 발견하면 핸들러는 변경된 경우에만 실행됩니다. 일부 조건에서는 매우 드물게 발생합니다. 예를 들어, XNUMX년 후 내 생애 처음으로. 그리고 물론 이름에 오타가 있으면 모든 것이 깨질 것입니다. 두 번째로 실행하지 않으면 변경 사항이 없습니다.

이와 별도로 변수의 가용성에 대해 이야기해야 합니다. 예를 들어 루프가 포함된 작업을 알리면 변수에는 무엇이 포함되나요? 분석적으로 추측할 수 있지만 항상 사소한 것은 아닙니다. 특히 변수가 다른 위치에서 오는 경우 더욱 그렇습니다.

... 따라서 핸들러는 보이는 것보다 훨씬 덜 유용하고 훨씬 더 문제가 많습니다. 핸들러 없이도(장식 없이) 아름답게 작성할 수 있다면 핸들러 없이 작성하는 것이 더 좋습니다. 아름답게 풀리지 않는다면 그들과 함께하는 것이 더 좋습니다.

부식성 독자는 우리가 논의하지 않았다는 점을 올바르게 지적합니다. listen핸들러는 다른 핸들러에 대해 알림을 호출할 수 있고, 핸들러는 import_tasks(with_items로 include_role을 수행할 수 있음)를 포함할 수 있으며, Ansible의 핸들러 시스템은 Turing-complete이고, include_role의 핸들러는 플레이의 핸들러와 흥미로운 방식으로 교차합니다. 등등. .d. -이 모든 것이 분명히 "기본"이 아닙니다).

실제로 명심해야 할 기능인 특정 WTF가 하나 있지만. 작업이 다음과 같이 실행되는 경우 delegate_to 통지가 있으면 해당 핸들러가 없이 실행됩니다. delegate_to, 즉. 플레이가 할당된 호스트에서. (물론 핸들러가 delegate_to 같은).

이와 별도로 재사용 가능한 역할에 대해 몇 마디 말씀드리고 싶습니다. 컬렉션이 등장하기 전에는 보편적인 역할을 만들 수 있다는 생각이 있었습니다. ansible-galaxy install 그리고 갔다. 모든 상황에서 모든 변형의 모든 OS에서 작동합니다. 그래서 제 생각에는 작동하지 않습니다. 질량이 있는 모든 역할 include_vars, 100500개의 케이스를 지원하는 것은 코너 케이스 버그의 심연에 처해 있습니다. 대규모 테스트로 다룰 수 있지만 모든 테스트와 마찬가지로 입력 값과 전체 함수의 데카르트 곱이 있거나 "개별 시나리오가 포함"되어 있습니다. 내 의견은 역할이 선형(순환적 복잡성 1)이면 훨씬 더 낫다는 것입니다.

적은 수의 if(명시적 또는 선언적 - 형식) when 또는 양식 include_vars 변수 세트에 따라) 역할이 더 좋습니다. 때로는 가지를 만들어야 할 때도 있지만 반복해서 말하지만 가지가 적을수록 좋습니다. 그래서 은하계에서는 좋은 역할인 것 같아요. (작동해요!) when 다섯 가지 과제 중 '자신의' 역할보다 덜 선호될 수 있습니다. 갤럭시와의 역할이 더 좋아지는 순간은 뭔가를 쓰기 시작할 때다. 상황이 더 악화되는 순간은 무엇인가가 깨지는 순간, '은하와의 역할' 때문이라는 의심이 들 때다. 열어보면 XNUMX개의 포함사항, XNUMX개의 작업 시트 및 스택이 있습니다. when'ov... 그리고 우리는 이것을 알아내야 합니다. 5개의 작업 대신 깨뜨릴 것이 없는 선형 목록입니다.

다음 부분에서

• 인벤토리, 그룹 변수, Host_group_vars 플러그인, Hostvars에 대해 조금 설명합니다. 고르디우스 매듭을 스파게티로 묶는 방법. 범위 및 우선순위 변수, Ansible 메모리 모델. "그럼 데이터베이스의 사용자 이름은 어디에 저장하나요?"
• jinja: {{ jinja }} — nosql notype nosense 부드러운 플라스틱. 그것은 어디에나 있고, 심지어 당신이 기대하지 않는 곳에도 있습니다. 조금 !!unsafe 그리고 맛있는 얌.

출처 : habr.com