ansible-rola-infosvr-import-export

Rola Ansible do automatyzacji importu i eksportu treści oraz struktur w IBM InfoSphere Information Server.

Nie znasz Ansible? Ten prosty wstęp może pomóc.

Wymagania

• Ansible w wersji 2.8+
• Dostęp do środowiska IBM Information Server z uprawnieniami do dsadm
• Grupy inwentarza skonfigurowane tak samo jak rola IBM.infosvr
• (Dla łatwiejszego użycia, rola IBM.infosvr zainstalowana i skonfigurowana)
• Zainstalowany jmespath na maszynie kontrolnej (rola korzysta z modułu json_query, który polega na tej bibliotece)

Rola opcjonalnie wykorzystuje podniesienie uprawnień do konta root w celu automatyzacji kilku zadań konfiguracyjnych. Jeśli twoje środowisko nie zezwala na podniesienie uprawnień, upewnij się, że te wymagania zostały już spełnione ręcznie w twoim środowisku i zmień zmienną ibm_infosvr_impexp_priv_escalate w pliku defaults/main.yml na False (to pominie wszelkie próby podniesienia uprawnień do roota).

Jeśli ustawisz podniesienie uprawnień na fałsz, upewnij się, że w docelowym środowisku przed uruchomieniem roli wykonano następujące kroki:

• Instalacja biblioteki python-requests (np. przez yum)
• Instalacja biblioteki python-lxml (np. przez yum)
• Instalacja curl (np. przez yum)
• Katalog {IS_HOME}/ASBServer/logs w warstwie domeny musi być zapisywalny przez użytkownika uruchamiającego rolę (a także przez każde z plików .log w tym katalogu)

(Podniesienie uprawnień do dsadm jest używane głównie do obsługi metadanych operacyjnych oraz wydobywania i ładowania zmiennych projektów DataStage; jeśli nie musisz z tego korzystać, może nie być konieczne podnoszenie uprawnień.)

Zmienne Roli

Zobacz defaults/main.yml w celu uzyskania dokumentacji wbudowanej, a poniżej przykład głównych zmiennych, które są potrzebne. W przypadku wszelkich pytań dotyczących oczekiwanych zmiennych akcji i podstruktur dla różnych typów obiektów, zapoznaj się z dokumentacją poniżej.

Domyślnie rola przeprowadzi weryfikację SSL samodzielnie podpisanych certyfikatów, jeśli zostały one pobrane za pomocą zadania get_certificate.yml z roli IBM.infosvr (zobacz przykład playbooka poniżej). Jest to kontrolowane przez zmienną 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 dowolny certyfikat domeny w warstwie nie będzie już zaufany.

Przykład Playbooka

Rola obejmuje możliwość eksportu i importu wielu różnych typów zasobów w Information Server. Rola może być zaimportowana do innego playbooka, podając tylko interesujące zmienne, aby ograniczyć zasoby do uwzględnienia w import lub eksport (puste zmienne spowodują, że rola pominie przetwarzanie tych typów zasobów).

Pierwszy poziom zmiennych przekazanych do roli definiuje szerokie działania, które muszą być podjęte, i zawsze będą one wykonywane w tej kolejności, niezależnie od tego, w jakiej kolejności zostały określone:

1. gather - pobierz szczegóły o środowisku (tj. numery wersji)
2. export - wyodrębnij zasoby z środowiska do plików
3. merge - scal wiele plików zasobów w jeden plik
4. ingest - załaduj zasoby do środowiska z plików (ze względu na zastrzeżoną zmienną import w Ansible, używamy ingest...)
5. progress - przesuń zasoby przez przepływ pracy (nie wykona nic, jeśli przepływ pracy nie jest włączony)
6. validate - sprawdź, czy środowisko jest w oczekiwanym stanie, korzystając z obiektywnych zliczeń zasobów

Jakiekolwiek brakujące zmienne po prostu pominą ten zestaw działań.

Na przykład:

---

- name: ustawienie zmiennych Information Server
  hosts: all
  tasks:
    - import_role: name=IBM.infosvr tasks_from=setup_vars.yml
    - import_role: name=IBM.infosvr tasks_from=get_certificate.yml

- name: ładowanie i walidacja zasobów
  hosts: all
  roles:
    - IBM.infosvr-import-export
  vars:
    isx_mappings:
      - { type: "HostSystem", attr: "name", from: "MY_HOST", to "YOUR_HOST" }
    gather: True
    ingest:
      datastage:
        - from: /some/directory/file1.isx
          into_project: dstage1
          with_options:
            overwrite: True
      common:
        - from: file2.isx
          with_options:
            transformed_by: "{{ isx_mappings }}"
            overwrite: True
    validate:
      that:
        - number_of: dsjob
          meeting_all_conditions:
            - { property: "transformation_project.name", operator: "=", value: "dstage1" }
          is: 5
        - number_of: database_table
          meeting_all_conditions:
            - { property: "database_schema.database.host.name", operator: "=", value: "YOUR_HOST" }
          is: 10

... zacznie się od zebrania szczegółów środowiska, w którym działa playbook.

Następnie zaimportuje wspólne metadane z pliku file2.isx (oczekuje się, że znajduje się w podkatalogu files/ względem twojego playbooka), zmieniając wszelkie nazwy hostów z MY_HOST na YOUR_HOST, a także nadpisując wszelkie istniejące zasoby o tych samych identyfikatorach. Potem zaimportuje zasoby DataStage z /some/directory/file1.isx do projektu dstage1, nadpisując wszelkie istniejące zasoby o tych samych identyfikatorach.

Zauważ, że kolejność, w jakiej są definiowane zmienne, nie ma znaczenia: rola sama zajmie się eksportem i importowaniem obiektów w odpowiedniej kolejności, aby zapewnić, że zależności między obiektami są odpowiednio obsługiwane (tj. że metadane wspólne i biznesowe są ładowane przed relacjami itp.). Jednakże, kolejność wielu obiektów zdefiniowanych w danym typie może mieć znaczenie, w zależności od twoich własnych zależności.

Ostatecznie playbook zweryfikuje, czy załadunek doprowadził do oczekiwanych zasobów w docelowym środowisku: 5 zadań DataStage w projekcie dstage1 i 10 tabel baz danych w jakiejś kombinacji schematów i baz danych na serwerze YOUR_HOST.

(Jednocześnie nie są zdefiniowane żadne akcje progress ani export, więc nie zostaną one wykonane.)

Struktury akcji (i obiektów)

Poniżej opisane są wszystkie działania i typy obiektów aktualnie objęte tą rolą oraz ich oczekiwane struktury.

1. gather - zbieranie szczegółów środowiska
2. export / merge / ingest typy zasobów metadanych (jak w powyższych działaniach, kolejność poniżej definiuje kolejność, w jakiej te typy obiektów będą wyodrębniane i ładowane - niezależnie od kolejności, w jakiej się pojawią w ramach akcji)
   1. customattrs - definicje atrybutów niestandardowych
   2. common - wspólne metadane (powinny być traktowane jako niskopoziomowe, a tam, gdzie to możliwe, omijane przez korzystanie z opcji specyficznych dla danego typu)
   3. logicalmodel - metadane modelu logicznego
   4. physicalmodel - metadane modelu fizycznego
   5. mdm - metadane modelu zarządzania danymi master
   6. database - metadane bazy danych
   7. datafile - metadane pliku danych
   8. dataclass - metadane klasy danych
   9. datastage - zasoby DataStage
   10. ds_vars - zmienne projektu DataStage
   11. infoanalyzer - zasoby Analyzera Informacji
   12. openigc - bundle i zasoby OpenIGC
   13. extendedsource - rozszerzone źródła danych
   14. extensionmap - dokumenty mapowania rozszerzeń
   15. glossary - zasoby słownika
   16. relationships - relacje metadanych
   17. omd - metadane operacyjne
3. progress - postęp przepływu pracy
4. validate - ramy walidacji

Dla export, merge i ingest, mapowania mogą być zastosowane do przekształcania metadanych między środowiskami (np. zmiana nazw, zmiana zawartości itp.), a większość typów zasobów można również ograniczyć za pomocą warunków.

Zauważ, że ogólnie możesz pisać te struktury zmiennych w dowolnej formie wspieranej przez Ansible, np. wszystkie są równoważne i zależą wyłącznie od twoich osobistych preferencji:

var_name: [ { a: "", b: "", c: "" }, { d: "", e: "", f: "" } ]

var_name:
  - { a: "", b: "", c: "" }
  - { d: "", e: "", f: "" }

var_name:
  - a: ""
    b: ""
    c: ""
  - d: ""
    e: ""
    f: ""

Licencja

Apache 2.0

Informacje o autorze

Christopher Grote