ansible-role-infosvr-openigc

Rola Ansible do automatyzacji wdrażania obiektów OpenIGC dla Katalogu Zarządzania Informacjami w IBM Information Server.

Nowy w Ansible? Ta prosta wprowadzenie może pomóc.

Wymagania

• Ansible v2.6.x
• Następujące narzędzia zainstalowane na Twojej maszynie kontrolnej:
  • zip
  • curl

Rola nie używa podwyższenia uprawnień i działa głównie na samej maszynie kontrolnej (tylko przesyłając generowane pliki bezpośrednio do odpowiednich interfejsów API w środowisku).

Ze względu na użycie zaawansowanego szablonowania Jinja do danych wejściowych opartych na YAML, potrzebna jest wersja Ansible z aktualną dystrybucją Jinja (v2.4 nie jest wystarczająca, dlatego wymaga się v2.6.x). Chociaż v2.7 pozwala na przesyłanie plików za pomocą modułu uri, nie umożliwia anulowania autoryzacji certyfikatu, dlatego aby umożliwić walidację certyfikatów samopodpisanych, bez potrzeby modyfikacji CA na samej maszynie kontrolnej, nadal polegamy na curl na razie.

Zmienne roli

Zobacz defaults/main.yml dla dokumentacji inline oraz przykład poniżej dla głównych potrzebnych zmiennych.

Ta rola próbuje automatycznie ponownie wykorzystać zmienne z roli IBM.infosvr, na przykład używając playbooka, który najpierw importuje IBM.infosvr za pomocą tasks_from=setup_vars.yml.

Domyślnie rola zweryfikuje certyfikaty samopodpisane, jeśli zostały one pobrane za pomocą zadania get_certificate.yml z roli IBM.infosvr (patrz przykład playbooka poniżej). Kontroluje to zmienna ibm_infosvr_openigc_verify_selfsigned_ssl roli: jeśli chcesz weryfikować tylko poprawnie podpisane i zaufane certyfikaty SSL, możesz ustawić tę zmienną na False, a każdy certyfikat samopodpisany nie będzie już uważany za zaufany.

Przykład Playbooka

Rola jest głównie przeznaczona do importowania do innych playbooków, gdy jest to potrzebne do wdrożenia obiektów OpenIGC - zarówno zestawów, jak i instancji zasobów. (Stąd potrzeba Ansible v2.4.x i modułu import_role.)

---
- name: ustaw zmienne serwera informacyjnego
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

- name: załaduj zestawy i zasoby OpenIGC
  hosts: ibm_information_server_engine
  roles:
    - IBM.infosvr-openigc
  vars:
    bundles:
      - /some/directory/<BundleId>
    assets_as_xml:
      - /some/directory/asset_instances-<BundleId>.xml
    assets_as_yaml:
      - /some/directory/assets.yml
    flows_as_xml:
      - /some/directory/lineage_flows-<BundleId>.xml
    flows_as_yaml:
      - /some/directory/lineage.yml

Struktury akcji (i obiektów)

Poniżej opisano wszystkie akcje i typy obiektów obecnie obsługiwane przez tę rolę oraz ich oczekiwane struktury. Niezależnie od kolejności, w jakiej zmienne są wymienione w playbooku, zostaną załadowane w kolejności, w jakiej są wymienione poniżej.

bundles

Lista katalogów podana przez tę zmienną powinna być w formie zestawu, zawierająca następującą strukturę:

• <BundleId>: główny katalog, na który wskazujesz, powinien mieć tę samą wrażliwą na wielkość liter nazwę co sam zestaw
  • asset_type_descriptor.xml: XML opisujący zestaw (tj. wszystkie klasy, ich relacje / zawartość itp.)
  • i18n: katalog zawierający etykiety
    • labels.properties: tłumaczone zestaw klas i etykiet atrybutów
  • icons: katalog zawierający dwa pliki .gif na każdą klasę określoną przez zestaw:
    • <ClassId>-icon.gif: powinien być przedstawieniem klasy o wymiarach 16x16 pikseli i może być również plikiem .png, ale powinien mieć rozszerzenie .gif
    • <ClassId>-bigIcon.gif: powinien być przedstawieniem klasy o wymiarach 32x32 pikseli i może być również plikiem .png, ale powinien mieć rozszerzenie .gif

assets_as_xml

Lista plików XML podana przez tę zmienną powinna być w pełni działającymi plikami XML instancji zasobów, już wygenerowanymi (np. poniższą zmienną) lub ręcznie utworzonymi.

assets_as_yaml

Ta zmienna jest dostarczana jako wygodniejszy / bardziej czytelny sposób określania instancji zasobów niż nauka formatu XML wymaganego przez assets_as_xml.

Lista plików YAML podana przez tę zmienną jest używana do generowania prawidłowych plików XML instancji zasobów, które są następnie automatycznie ładowane. Struktura każdego pliku YAML powinna wyglądać następująco:

---

bundleId: $<BundleId>
contains:
  - class: <ClassName>
    name: <name>
    contains:
      - class: <NestedClassName>
        name: <name>
        contains:
          ...

Podstruktura contains może być zagnieżdżona tak wiele razy, jak to konieczne, aby stworzyć hierarchię zawartości, której potrzebujesz dla swoich zasobów. Każda podstruktura musi mieć co najmniej zdefiniowane class i name.

Ponadto można określić dowolną liczbę dodatkowych atrybutów, które są dozwolone przez definicję zestawu i domyślny zestaw atrybutów dla wszystkich obiektów (np. short_description, long_description). Atrybuty zdefiniowane w zestawie muszą być poprzedzone znakiem $. Na przykład:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: level1
    short_description: Katalog najwyższego poziomu
    $filesystem: UNIX
    contains:
      - class: Folder
        name: level2
        short_description: Następny poziom w strukturze katalogów
        contains:
          - class: File
            name: MyFile.txt
            short_description: Plik, który znajduje się w /level1/level2/MyFile.txt
            $encoding: UTF-8

W tym przykładzie zestaw TestBundle definiuje Foldery i Pliki, w których Foldery mogą mieć zdefiniowany atrybut filesystem, a Pliki mogą mieć zdefiniowany encoding. Oba mogą mieć short_description, ponieważ wszystkie obiekty w IGC mają ten atrybut.

Dla atrybutów, które pozwalają na wiele wartości, wystarczy zdefiniować wartość atrybutu jako listę YAML. W tym przykładzie atrybut users_with_access specyficzny dla zestawu pozwala na wiele wartości, więc dla tego atrybutu definiujemy każdą wartość jako część listy YAML:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    $users_with_access:
      - user123
      - user456
      - user789

Na koniec skrót names istnieje dla liściastych węzłów hierarchii zawartości, gdzie wystarczy określić tylko name każdego z nich - unika to konieczności podawania tej samej class wielokrotnie dla każdego liściastego węzła:

---

bundleId: $TestBundle
contains:
  - class: Folder
    name: root
    contains:
      - class: File
        names:
          - MyFile.txt
          - YourFile.txt
          - OtherFile.txt

flows_as_xml

Lista plików XML podana przez tę zmienną powinna być w pełni działającymi plikami XML przepływu linii, już wygenerowanymi (np. poniższą zmienną) lub ręcznie utworzonymi.

flows_as_yaml

Ta zmienna jest dostarczana jako wygodniejszy / bardziej czytelny sposób określania instancji zasobów niż nauka formatu XML wymaganego przez flows_as_xml powyżej.

Lista plików YAML podana przez tę zmienną jest używana do generowania prawidłowych plików XML przepływu linii, które są następnie automatycznie ładowane. Struktura każdego pliku YAML powinna wyglądać następująco:

---

assets:
  - class: <FullClassName>
    name: <name>
    contains:
      - class: <NestedFullClassName>
        name: <name>
        id: <unikalny identyfikator>
        contains:
          ...

flows:
  - name: <istotny komentarz>
    within: <id>
    contains:
      - name: <istotny komentarz>
        from:
          - <id>
          - ...
        to:
          - <id>
          - ...
      - ...

Podstruktura contains dla assets może być zagnieżdżona tak wiele razy, jak to konieczne, aby stworzyć hierarchię zawartości, której potrzebujesz dla swoich zasobów. Każda podstruktura musi mieć co najmniej zdefiniowane class i name (w rzeczywistości, wszelkie inne atrybuty są po prostu ignorowane, ponieważ nie są używane w XML przepływu linii). Należy pamiętać, że w tym przypadku należy podać w pełni kwalifikowane nazwy klas, w tym bundleId, np. $BundleId-ClassName. Ma to na celu zapewnienie możliwości połączenia zarówno obiektów OpenIGC, jak i zasobów rodzimych w przepływie linii (i utworzenia przepływów linii obejmujących wiele zestawów OpenIGC).

Dla jakichkolwiek zasobów, które planujesz użyć jako część przepływu, należy również dodać atrybut id, aby określić, jak będziesz się do nich odnosić w zmiennej flows. Ten identyfikator powinien być unikalny w pliku YAML i nie powinien zawierać żadnych spacji ani innych znaków specjalnych (poza . i _). Jest to konieczne oprócz name, ponieważ id zapewnia płaskie, unikalne odwołanie w pliku; name jest w rzeczywistości zagnieżdżonym identyfikatorem, który będzie zależał od struktury do zawartości, w której występuje, a zatem sam w sobie nie jest unikalny (tylko biorąc pod uwagę całą struktury do zawartości).

Każde name w zmiennej flows używane jest jako komentarz w wygenerowanym XML, ale w rzeczywistości nie pojawia się w IGC.

Rozważ następujący przykład:

---

assets:
  - class: $TestBundle-Folder
    name: root
    contains:
      - class: $TestBundle-File
        name: MyFile.txt
        id: MyFile.txt
      - class: $TestBundle-File
        name: YourFile.txt
        id: YourFile.txt
      - class: $TestBundle-File
        name: OtherFile.txt
        id: OtherFile.txt
  - class: $TestBundle-Command
    name: copy
    id: copy

flows:
  - name: Komenda kopiowania do duplikowania pliku
    within: copy
    contains:
      - name: Kopiuj z My do Your i Other
        from:
          - MyFile.txt
        to:
          - YourFile.txt
          - OtherFile.txt

W przykładzie mamy TestBundle, który definiuje nowe obiekty reprezentujące Foldery, Pliki i Komendy. Sekcja assets definiuje tylko obiekty, które chcemy opisać w linii, w tym ich hierarchię zawartości. Dla każdego zasobu, który zamierzamy użyć w przepływie, zdefiniowaliśmy unikalny atrybut id.

W sekcji flows następnie tworzymy linię: zewnętrzna within definiuje proces odpowiedzialny za jakąkolwiek akcję przedstawioną w linii, a contains w ramach tego określa konkretne wejścia i wyjścia akcji.

Licencja

Apache 2.0

Informacje o autorze

Christopher Grote