Fabric: v2 호환 '역할' 또는 이와 유사한 것

개요

작성 당시 v2 분기에는 이전에 '역할'(일명 "작업을 수행하는 호스트 묶음")으로 알려진 단위 역할을 할 수 있는 Group 클래스가 있습니다.

그러나 Group 개체를 구성하거나 레이블을 지정하는 구체적인 방법은 아직 없습니다. 고유한 고유한 생성 방법을 사용하려는 고급 사용자의 순수한 API 사용 사례에는 충분히 "완료"되었지만, CLI 지향 사용자 또는 프레임워크 구축을 원하는 중급 사용자에게는 아무 것도 부족합니다.

달리 말하면, API로 순전히 롤링하지 않는 한, CLI 또는 작업 호출 비트에서 찾을 방법이 없는 경우 어딘가에 Group 개체를 배치하는 것은 쓸모가 없습니다!

배경

v1에서 역할은 단순한 문자열 레이블을 v2의 그룹에 매핑하는 단일 플랫 네임스페이스였으며 런타임 시 CLI에서 선택( fab --roles=web,db ) 및/또는 작업의 기본 대상으로 등록( @task('db') \n def migrate(): ), 호스트와 매우 유사합니다.

사용자는 env.roledefs , 간단한 사전에 정의했습니다. 모든 중간에서 고급 기능은 일반적으로 런타임(사전 작업 또는 서브루틴을 통해), 때로는 모듈 로드 시 수정을 중심으로 이루어졌습니다.

특정 사용 사례/요구/하위 기능

• 시스템의 다른 곳에서 사용/참조하기 위한 기본적이고 순진한 매핑: 이름을 입력하고 Group s 및/또는 Connection s의 일부 반복 가능을 가져옵니다.
  
  
  
  • 자주 앨리어싱 것은, 그와 함께 가고 싶어 그래서 예를 들면 Lexicon 대신의 dict .
  
  
  • '번들링'과 같은 더 깊은 구성, 예를 들어 db , web , lb 라는 이름의 직접 매핑이 있지만 prod 라는 두 번째 계층 이름이 있습니다 Lexicon 추가했는지 잊어버렸습니다. 이미 그렇게 하는 다른 지도 하위 클래스가 있을 수 있습니다.
  
  
  • 추가적으로/또는, 글로빙(globbing)이나 기타 문자열 구문과 같은 것들이지만 개인적으로 파이썬이 "문자열 형식"이 아니라는 사실을 활용하는 것을 선호하지만...
  
  
• 주어진 연결이 속한 그룹을 식별할 수 있는 유용한 '역 매핑'.
  
  
  
  • 문제: 현재 전역 공유 상태가 없기 때문에 ID를 사용하여 이에 대한 순진한 대답은 기술적으로 동일한 여러 연결 개체를 만들 수 있기 때문에 실패합니다.
  
  
  • 특히 그룹에 단축 호스트 문자열을 제공하면 그룹이 사용자를 대신하여 암시적으로 생성할 수 있기 때문에 편의 옵션일 뿐입니다.
  
  
  • 그러나 전역 상태가 없다는 제약 조건을 감안할 때 동등성 테스트를 대신 사용하는 데 명백한 문제를 볼 수 없으므로 실행할 수 있어야 합니다. 예를 들어 cxn 가 고유한 개체인 경우에도 if cxn in group 가 작동합니다. group 내부의 동등한 멤버에서.
  
  
  • 마음에 떠오르는 유일한 것은 연결에서 그룹으로의 강력하고 상태 저장 링크가 있는 경우(그룹, 복수여야 함)가 그 반대의 경우가 아니라 그것을 보유하고 있다는 것입니다.
  
  
• 이전 기능과 밀접하게 관련됨: "현재 실행 중인 역할"이 무엇인지 검사/표시하는 기능(v1에서 사람들이 오랫동안 원했지만 디자인으로 인해 중요하지 않은 기능)
  
  
  
  • 주요 문제는 이것이 실제로 두 개의 반쯤 별개의 질문이라는 것입니다. "일반적으로 말하면, 현재 호스트 부분이 어떤 역할(들)인지"(기본적으로 역방향 조회의 이전 사용 사례) "어떤 역할(들)이 특별히 실행하도록 요청받은 실행 기계".
  
  
  • 즉, 역할 A, B, C에 속하는 호스트 'foo'가 컨텍스트가 'foo'이지만 '역할 A에서 실행' 요청으로 인해 실행된 주어진 작업 내에서 다음을 찾고 있는 사용자입니다. "A, B 및 C"(전체적으로 'foo' 역할) 또는 "A"(현재 실행 중인 역할)에 대한 답변은 무엇입니까?
  
  
  • 기능 요청이 두 개를 통합한 것으로 기억하지만 이것은 실제로 두 개의 별개의 API 호출처럼 느껴집니다.
  
  
• CLI에서 전역 및/또는 작업별 대상 선택
  
  
  
  • "모든 작업이 정의한 것 위에 추가되는 플래그"를 설명하기 위한 Invoke의 CLI 시스템 확장이 이를 위해 유용하거나 필요할 수 있습니다. 실제로 pyinvoke/invoke#205 영역에 확고하게 들어가므로 이미 이전보다 높은 우선 순위를 얻었습니다(상당히 높음).
  
  
• 동일한 작업 수준 기본값
  
  
  
  • 작업 수준 대상 기본값은 실제로 연결, 연결, 그룹 obj, 그룹 objs 또는 그룹 objs를 평가하는 이름 중 하나가 되기를 원하지만(이 티켓과 직접적으로 관련된 것은 마지막 항목뿐입니다)
  
  
• 컬렉션 수준 기본값과 동일(v2의 새로운 기능!)
  
  
  
  • 즉, "$submodule의 모든 작업은 기본적으로 db 역할에 대해 실행됩니다."
  
  
  • 이전 포인트와 동일한 거래 - 이 기본값은 문자열 키뿐만 아니라 다양한 값을 허용하려고 합니다.
  
  
• 이것과 함께 가고 싶어하는 OO 접근 방식에 의해 가능해진 새롭고 흥미로운 다른 것이 있습니까? 예를 들어 Chef 또는 Ansible과 같은 시스템을 완전히 재창조하는 것이 아니라 빌딩 블록 및 고급 사용자 활성화에 중점을 두어야 함을 기억하십시오.

구현 아이디어/우려사항

• 구성 시스템을 기본 저장 벡터로 사용하는 경우 값은 yaml, json 등에 저장할 수 있도록 기본 값이 "원하지만" "모든 그룹/연결 kwargs를 큰 ol에 저장"으로 끝나는 웜 캔입니다. list-o-dicts" 등
• 정의가 주로 Python에 있을 것으로 예상되는 경우 간단히 "그룹 개체 인스턴스화"라고 말하면 해당 데이터를 구성 시스템에 병합하거나 어떻게든 독립형으로 남겨둘 수 있습니다.
  
  
  
  • 나는 말 그대로 모든 것을 중첩된 구성 딕셔너리에 채우는 것이 나쁜 소식으로 이어질 것처럼 느껴지기 때문에 후자를 선호한다고 생각합니다.
  
  
• 앨리어싱 및 번들링과 같은 더 깊은 구성은 복잡성 및 순서 문제를 추가합니다(예: key1의 값이 그룹이지만 key2의 값이 key1인 사소한 별칭 설정을 상상해 보세요. 이제 key2를 확인하거나 확인하기 위해 구조를 두 번 크롤링해야 함)
  
  
  
  • 우리가 대부분 "파이썬 내에서 수행" 접근 방식을 사용하면 선언적 구조로 시작할 수 있지만 초기 설정 후 메서드 호출에 의해 더 많은 것이 활성화되는 구성 시스템의 API와 매우 유사해집니다. 나는 그것이 끔찍하다고 생각하지 않는다? 편집: 그리고 그것이 Lexicon이 어쨌든 작동하는 방식이라고 생각합니다.
  
  
• 형식에 관계없이 고급 사용자가 외부 소스 또는 이와 유사한 소스에서 즉석에서 생성하려는 방법을 파악해야 합니다. 여기에 앨리어싱 문제 등을 더하면 우리가 이것을 어딘가에 "저장된" 순진한 구조가 아니라 그것을 생성하기 위해 호출되는 일부 객체 또는 객체에 대한 API로 원할 수 있음을 의미합니다.
  
  
  
  • 나는 우리가 역할/그룹의 선택에서 '하향' 작업을 하고 싶어할지도 모른다고 생각합니다. 가장 고급 사용자는 필연적으로 다음을 원할 것이기 때문에 "사용자가 제공한 것을 실행 가능한 대상 단위로 전환"하기 위한 가장 높은 수준의 API에 도달합니다. 해당 API 호출의 구현을 완전히 제어할 수 있습니다. 그러면 우리는 항상 유용한 일반적인 경우처럼 느껴지지만 "일을 하는 한 가지 방법"으로 명확하게 표시된 것을 제공할 수 있습니다.
  
  
  • @RedKrieg는이 멋진 아이디어를 우리가 가지고있는 곳이 라인을 따라가 @group 와 같은 @task , 그리고 기능은 작업의 실행 단위 아니지만, 대신 그룹 개체를 얻을 수 있습니다.
  
  
  • 이 접근 방식은 기본적으로 작업 계층(컬렉션)을 재사용합니다. 이는 실용적이고(휠을 재발명해야 하는 이유) 우아합니다(실제 사례에서 역할/그룹 정의가 종종 이를 사용하는 작업과 매우 밀접하게 매핑되기 때문입니다!)
    
    
    
    
    
    • 또한 그룹이 작업에 매핑되지 않는 경우에도 잘 작동합니다. 루트 컬렉션 수준에서 정의를 간단히 작성할 수 있기 때문입니다. 쉬워요.
    
    
    
  
  
  • 이것이 각 함수에서 단일 그룹을 반환하는 것이 가장 좋은지, 여러 그룹(또는 연결)을 생성하는 기능을 원하는지 또는 장식된 함수가 아닌 API 호출로 수행하는 것이 가장 좋은지 확실하지 않습니다. 컬렉션(예: 컬렉션 수준 구성이 저장되는 방식).
  
  
  • 예를 들어 그룹/역할 데이터가 동적이고 Fabric 외부에서 여전히 해결해야 하는 사용 사례(이것이 앞서 내가 먼저 이 공간에 대한 최고 수준의 API를 식별해야 한다고 언급한 이유입니다. 이 중급 수준의 아이디어로.)