Cp-ansible: 앤서블 갤럭시 지원

업데이트가 있습니까? 이 플레이북을 사용하는 것이 훨씬 쉬울 것입니다.

현재로서는 가능한 은하계에 퍼블리싱할 계획이 없습니다. 향후 릴리스에서 이를 조사하는 방법을 알아보기 위해 내부 jira를 제출할 것입니다.

일반적인 기대는 리포지토리를 복제한 다음 지정된 설정에 필요한 플레이북을 실행하는 것입니다.

Ansible 2.9는 Collections라는 새로운 배포 형식을 도입했습니다. 컬렉션에 플레이북, 역할, 모듈 및 플러그인이 포함될 수 있으므로 이 문제를 해결하는 데 더 적합해 보입니다.

몇 가지 포인터:

• https://www.ansible.com/blog/getting-started-with-ansible-collections
• https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
• https://docs.ansible.com/ansible/latest/dev_guide/developing_collections.html

나는 갤럭시 컬렉션으로 재구성하는 것을 찔렀고 all.yml 플레이북과 대부분의 기본적인 구성(ssl 및 sasl/plain 리스너)으로 작업하는 것을 테스트했습니다. 일부는 매우 투박합니다. 주로 내가 말할 수 있는 한 필터와 모듈을 참조하려면 전체 은하 이름 공간을 참조해야 합니다. 내 사용 사례에 적합하며 팀에서 추가할 가치가 있다고 생각하면 PR을 열게 되어 기쁩니다.

https://github.com/aig787/cp-ansible/tree/agriffin/5.4.1-repack

@aig787 좋아요! 나는 항상 업그레이드 플레이북이 "플레이북" 디렉토리에 있어야 한다고 생각했습니다.
역할은 플러그인 디렉토리의 내용에 액세스할 수 있습니까?
또한 confluentinc_cp 디렉토리가 필요합니까?

한 가지 까다로운 부분은 ansible.cfg입니다. 저는 항상 플레이북 바로 옆에 있는 것을 좋아했습니다.

역할은 모두 플러그인 디렉토리(https://docs.ansible.com/ansible/devel/dev_guide/develping_collections.html#plugins-directory)에 있는 항목에 액세스할 수 있습니다. 액세스하려면 전체 이름을 사용해야 한다고 생각합니다. 예를 들어 필터가 작동하도록 하려면 KAFKA_OPTS: "{{ kafka_broker_final_java_args | java_arg_build_out }}" 를 KAFKA_OPTS: "{{ kafka_broker_final_java_args | aig787.confluent_cp.java_arg_build_out }}" 로 변경해야 했습니다. 우회할 수 있는 방법이 있을 수 있지만 찾지 못했습니다.

방금 confluentinc_cp 디렉토리를 제거한 상태에서 시도했는데 제대로 작동했으므로 필요하지 않은 것 같습니다. 처음에 ansible-galaxy collection init 부트스트랩하고 생성된 구조를 사용했습니다.

sible.cfg가 나머지와 함께 플레이북 디렉토리로 이동할 수 없는 이유가 있습니까? 플레이북을 사용하려면 사람들이 여전히 저장소를 복제하고 지금처럼 실행해야 한다고 _생각_합니다. 은하계에 있는 것의 장점은 플레이북을 더 쉽게 만드는 것보다 사람들이 자신의 설정에서 역할에 액세스할 수 있도록 하는 것입니다. 어쨌든 내 2 센트입니다.

저는 개인적으로 ansible.cfg가 어디에 있는지 신경 쓰지 않습니다. 플레이북을 실행하고 현재 디렉토리가sible.cfg가 있는 위치가 아니면 문제가 있다는 것만 압니다.

가능한 모범 사례를 준수하고 컬렉션 디렉토리 구조를 따르는 것의 가치를 알 수 있지만 이 컬렉션을 은하계에 게시함으로써 얻을 수 있는 이점이 무엇인지 궁금합니다. 더 많은 가시성?

나에게 은하계와 우리 지사에서 버전 관리를 관리하는 것은 많은 오버헤드처럼 보입니다.

그것은 사용의 용이성 이득이 될 것입니다. 모든 노드에 기본 구성을 수행하는 플레이북이 있는 경우 이를 요구 사항 파일에 추가하고 `ansible-galaxy install -r requirements.yml'을 실행하고 복제할 필요 없이 기존 플레이북에서 kafka 역할을 참조할 수 있습니다. 리포지토리를 만들고 플레이북을 확장하거나 역할 디렉토리를 복사합니다.

실제로 게시해야 하는 이유에 관해서는 컬렉션이 역할과 같은 자식 참조를 지원한다고 생각하지 않습니다(https://galaxy.ansible.com/docs/using/installing.html#installing-multiple-roles-from-a -file 대 https://docs.ansible.com/ansible/latest/user_guide/collections_using.html#install-multiple-collections-with-a-requirements-file). 버전 관리를 위한 오버헤드의 양에 대해 동의합니다. 약간 무거워 보입니다.

저는 개인적으로 Galaxy에 있는지 여부에 상관하지 않지만 요구 사항 파일에서 다른 역할을 쉽게 참조할 수 있다는 것은 정말 감사할 일입니다.스마일:

새 문제를 등록하려고 했으나 내 문제가 이 문제와 관련이 있는 것 같습니다. 따라서 여기에서 코멘트로 시작하여 관리자와 지켜보고 있는 다른 사람들로부터 초기 피드백을 얻으십시오.

이 리포지토리의 역할을 사용하고 싶지만 내 사용자 지정 역할(역할 확장)의 역할 종속성으로 사용하고 싶습니다. 우리는 플레이북(all.yml)을 사용하여 시작했지만 정확한 타이밍에 확장 기능을 적용하는 데 많은 어려움을 겪었습니다. 이 접근 방식의 첫 번째(차단) 문제는 https://github.com/confluentinc/cp-ansible/pull/442 로 수정되었습니다

[DEPRECATION WARNING]: Included file 
'/builds/kafka/provisioner/tasks/failure_handling.yml' not found, however since
 this include is not explicitly marked as 'static: yes', we will try and 
include it dynamically later. In the future, this will be an error unless 
'static: no' is used on the include task. If you do not want missing includes 
to be considered dynamic, use 'static: yes' on the include or set the global 
ansible.cfg options to make all includes static for tasks and/or handlers. This
 feature will be removed from ansible-base in version 2.12. Deprecation 
warnings can be disabled by setting deprecation_warnings=False in ansible.cfg.

디테일을 보니 전체적인 문제는 현재 역할이 자족적이지 않다는 점이라고 생각합니다. 이를 수정하는 것은 결국 Ansible Galaxy에 역할 또는 역할 컬렉션을 게시하기 위한 필수 단계입니다. 그리고 이것은 역할 내에서 다음 최상위 디렉토리 /filter_plugins 및 /tasks 에 대한 참조로 요약되기 때문에 이것은 아주 쉽게 고칠 수 있다고 생각합니다.

pull 요청으로 다음 작업에 대해 어떻게 생각하십니까?

1. /filter_plugins 폴더를 confluent.variables 역할로 이동하여 해당 역할의 일부로 만드시겠습니까? 필터 플러그인은 최소한 이 역할에서 사용 중입니다.

2. /tasks 의 재사용 가능한 작업 파일을 기존 역할 중 하나로 이동합니다. 아마도 confluent.common 가 기존 역할에 가장 적합하거나 해당 역할을 위한 새로운 전용 역할을 생성하는 것입니다( confluent.common_tasks )? 그리고 include_role#tasks_from을 사용하여 재사용된 작업 파일에 대한 참조를 업데이트합니다. 예시:

Index: roles/confluent.zookeeper/tasks/health_check.yml
<+>UTF-8
===================================================================
--- roles/confluent.zookeeper/tasks/health_check.yml    (revision 0d369ae20c8215dd2ec469f269dc804539f58190)
+++ roles/confluent.zookeeper/tasks/health_check.yml    (date 1602793473938)
@@ -25,7 +25,9 @@
   ignore_errors: true

 - name: Fetch Files for Debugging Failure
-  include: tasks/failure_handling.yml
+  include_role:
+    name: confluent.common
+    tasks_from: failure_handling.yml
   vars:
     service_name: "{{zookeeper_service_name}}"
     config_file: "{{zookeeper.config_file}}"

@erikgb 과거에 내부적으로 논의한 내용입니다. 특히 자체 포함된 역할과 코드 중복 최소화에 대한 논의가 상당히 많았습니다. 2.12에서는 이것을 변경해야 할 것 같습니다. 경고에 따라 Ansible이 릴리스되었으므로 /filter_plugins 및 /tasks 를 모두 confluent.common 역할로 이동한 다음 적절한 다른 모든 역할의 import 문.

@domenicbove 당신의 생각은 무엇입니까?

기능이 일관되게 유지되는 한 파일 위치를 이동하는 데 문제가 없습니다. @erikgb @JumaX.
이것은 우리의 다음 릴리스를 목표로 하는 마스터 브랜치로 이동해야 할 만큼 충분히 큰 작업인 것 같습니다.

@domenicbove 다음 주요 릴리스를 위한 작업에 동의했습니다. @erikgb 내부 JIRA를 추가하여 이를 추적하고 다음 릴리스의 로드맵에 포함시킬 수 있는지 확인할 것입니다.

또는 @erikgb 브랜치에 작업이 있는 경우 마스터 브랜치에 PR을 작성하면 검토하겠습니다. 나는 그것이 이 문제를 완전히 해결할 것이라고 생각하지 않지만, 우리는 여전히 은하계를 만들어야 합니다.

다음 주요 릴리스? 그것이 Confluent Platform 7이 될까요? 이 변경 사항은 주요 진입점이 플레이북과 역할이라고 생각하는 한 이전 버전과 호환될 수 있다고 생각합니다. CP 7 이전에 이 문제를 해결하고 싶습니다. 😄

@erikgb CP 6.1

@domenicbove @JumaX CP 6.1이 더 합리적입니다. 이번 주 후반에 pull 요청을 처리할 시간이 있는지 확인하겠습니다. 리팩토링을 의미 있는 부분으로 분할하는 것이 좋습니다. 어떻게 생각하십니까?

@erikgb 여러 PR로 분할하려는 경우 각 PR이 추가 PR 없이 계속 실행될 수 있다고 가정하면 괜찮습니다. 내가 그것을 잘 진술했는지 확실하지 않습니다. :). 마스터 브랜치를 목표로 해야 합니다.