MongoDB

Rola Ansible, która instaluję, konfiguruje i zarządza MongoDB dla Ubuntu 22.04.

MongoDB dla systemów podobnych do RHEL można znaleźć tutaj.

Proszę dokładnie przeczytać ten plik przed wdrożeniem tej roli Ansible.

Funkcjonalności

• Zastosowanie zalecanych uwag dotyczących produkcji, np. numa oraz wyłącza przezroczyste ogromne strony
• Uruchamianie klastra w architekturze PSA (pierwszy, drugi, arbiter)
  • zawiera weryfikację klastra
• Zabezpieczenie połączenia poprzez szyfrowanie ruchu za pomocą automatycznie generowanego pliku klucza
• Instalacja edycji Community lub Enterprise
• Łatwa konfiguracja, z przyszłościowym sposobem konfiguracji
• Aktualizacja playbooka, obsługuje wydania poprawek
• Dodawanie zdefiniowanych przez użytkownika użytkowników
• Dodawanie zdefiniowanych przez użytkownika baz danych
• Backup z użyciem mongodump
• Rotacja logów, ustawiana z poziomu mongo

Ta rola jest idempotentna i przechodzi kontrole ansible-lint.
Może być używana z wersją Ansible 2.9 i nowszymi. Może także obsługiwać wcześniejsze wersje.

Wymagania

• Rozum
• Na węźle kontrolnym upewnij się, że jest zainstalowana kolekcja mongodb
• Hosts muszą mieć możliwość wzajemnego połączenia, najlepiej za pomocą nazw hostów oraz ustawionego portu, domyślnie 27017
• Upewnij się, że jest wystarczająco dużo miejsca na dysku dla dysku danych oraz backupu, jeśli jest ustawiony

Asercje

Istnieje kilka asercji, aby zapewnić minimalną poprawną konfigurację. Oczywiście, nie pokrywają one każdego przypadku użycia, ale większość z nich.
Proszę uważnie przestrzegać tego README. Jako wskazówkę, dla poprawnej konfiguracji, zapoznaj się z plikami zmiennych w folderze molekuł.

Wersjonowanie i edycja

Wersję i edycję można ustawić. Domyślnie dodawane są oficjalne repozytorium mongodb oraz klucz gpg.

mongo_repo: true
mongo_version: 6.0
mongo_edition: org  # lub enterprise

Jak dotąd, Ubuntu 22.04 obsługuje tylko MongoDB 6.0, a nie starsze wersje.

Brak logów

Domyślnie, z powodów bezpieczeństwa, logowanie dla kilku zadań jest wyłączone. Aby je włączyć:

mongo_no_log: true

Rekomendacje

Ta sekcja odnosi się do oficjalnych uwag dotyczących produkcji MongoDB.

Ta rola zawiera kilka zaleceń dotyczących konfiguracji, ale nie wszystkie. Na przykład: "Wyłącz atime dla wolumenu nośnika zawierającego pliki bazy danych." Takie zadania są poza zakresem tej roli.

Są zadania, które ta rola zastosuje, jeśli jest to ustawione, to są:

• Uruchomienie MongoDB z numactl, ustawione w pliku systemd
• Wyłączanie reclaimu strefy
• Wyłączanie przezroczystych ogromnych stron
• Konfiguracja profilu tuned

Zobacz tasks/thp.yml i tasks/numa.yml dla rzeczywistych zmian w systemie.

Te rekomendacje konfiguracyjne są stosowane domyślnie.

mongo_thp: true
mongo_numa: true

Zmienne konfiguracyjne

Najpierw zapoznaj się z defaults/main.yml.

Plik konfiguracyjny znajduje się w /etc/mongod.conf.

Wartości ustawione w konfiguracji Ansible są ustawiane dokładnie w pliku konfiguracyjnym na hoście. Tylko klucze są zdefiniowane z góry. Przykład:

# Zmienna ustawiona w konfiguracji Ansible
mongo_operationprofiling:
  my_Value:
    anotherValue: something

Skutkuje to plikiem konfiguracyjnym na dysku:

operationProfiling:
  my_Value:
    anotherValue: something

Jeśli klucz jest ustawiony na pusty ciąg, zostanie skomentowany w pliku konfiguracyjnym na dysku.

Możliwe klucze do ustawienia:

mongo_systemlog
mongo_storage
mongo_processmanagement
mongo_security
mongo_operationprofiling
mongo_replication
mongo_sharding
mongo_auditlog
mongo_snmp

Istnieją wartości zdefiniowane wstępnie, które są domyślne dla Mongo. Jeśli z jakiegoś powodu pożądane jest ustawienie niestandardowych kluczy/wartości, użyj:

mongo_custom_cnf:
  my_key:
    my_value: true

Autoryzacja

Z założenia utworzone są 3 użytkowników: admin, backup i adminuser.
Użytkownik admin ma rolę root, użytkownik backup ma rolę backup, a adminuser ma rolę userAdminAnyDatabase.

mongo_admin_pass: 'change_me'
mongo_adminuser_name: adminuser
mongo_adminuser_pass: 'change_me'

Bazy danych i użytkownicy

Na podstawie dokumentacji można zdefiniować własnych użytkowników/bazy danych.

Zobacz dokumentację dla możliwych ról.

Użytkownicy i bazy danych są zawsze konfigurowane przez localhost, przez użytkownika administracyjnego oraz administratora bazy danych.
Kiedy klaster jest skonfigurowany, konfigurowanie baz danych i użytkowników odbywa się z głównego hosta.

Ustaw z:

mongo_user:
# w najprostszej formie
  - database: my_db
    name: my_user

# standardowe wartości
  - database: another_db
    name: another_user
    update_password: on_create
    password: "123ABC!PASSWORD_XYZ"
    roles: 'readWrite,dbAdmin,userAdmin'
    state: present

# wszystkie możliwe zmienne
  - database: my_db
    name: someone
    password: my_password
    update_password: on_create             # domyślnie zawsze
    roles: 'readWrite,dbAdmin,userAdmin'   # domyślnie pominięte
    state: absent                          # domyślnie obecny
    ssl: true                              # domyślnie pominięte
    ssl_ca_certs: /path/to/ca_certs        # domyślnie pominięte
    ssl_cert_reqs: CERT_REQUIRED           # domyślnie pominięte
    ssl_certfile: /path/to/ssl_certfile    # domyślnie pominięte
    ssl_crlfile: /path/to/ssl_crlfile      # domyślnie pominięte
    ssl_keyfile: /path/to/ssl_keyfile      # domyślnie pominięte
    ssl_pem_passphrase: 'something'        # domyślnie pominięte
    auth_mechanism: PLAIN                  # domyślnie pominięte
    connection_options: my_conn_options    # domyślnie pominięte
    create_for_localhost_exception: value  # domyślnie pominięte

Aby utrzymać rolę idempotentną, powinieneś ustawić wartość update_password na on_create. Tylko podczas rzeczywistej aktualizacji hasła, ustaw ją na always, a potem przełącz z powrotem na on_create.

Klasteryzacja

Kiedy w play jest wiele hostów, Ansible zakłada, że klaster jest skonfigurowany.

Możliwość klasteryzacji w architekturze PSA (pierwszy/drugi/arbiter) jest możliwa, lub w ustawieniu pierwszy/drugi/drugi.

Z powodów bezpieczeństwa, połączenie między hostami jest zabezpieczone za pomocą pliku klucza.

Plik klucza jest automatycznie generowany i uznawany za bezpieczny.

mongo_security:
  keyFile: /etc/keyfile_mongo

Klaster z 2 hostami to zasadniczo wadliwy projekt, ponieważ nie może utrzymać dostępności bez kworum i możliwości awarii węzła w celu ułatwienia odzyskiwania.
Kiedy w grze znajdują się dokładnie 2 hosty, utworzenie klastra nie jest możliwe. Mongo nie utworzy klastra, ponieważ musi być ważna liczba członków replicaset.

Istnieją asercje w celu weryfikacji, czy w wypadku nierównowagi liczby hostów w grze.

Skonfiguruj z:

# ustaw rolę dla hosta w host_vars
mongo_replication_role: primary # lub secondary, lub arbiter

# w group_vars/all.yml
mongo_replication:
  replSetName: something
mongo_security:
  keyFile: /etc/keyfile_mongo

Może być ustawiony tylko 1 główny i 1 arbiter.

Nie powinieneś zmieniać struktury klastra po jego wdrożeniu, np. zmieniając drugiego na arbitra.

Arbiter

Zgodnie z dokumentacją, unikaj wdrażania więcej niż jednego arbitra w każdym zestawie replik.

Ansible zajmie się poprawnym dodaniem arbitra do klastra.

mongo_replication_role: arbiter

Backup

Backup jest konfigurowany do ustawienia na pojedynczym hoście bez replikacji, lub na pierwszym hoście wtórnym w grze. Jest wykonywany za pomocą mongodump, ustawionego w cron.

Skrypty backupu są tylko umieszczane na pierwszym odpowiednim węźle wtórnym:

- host1 [primary]   <-- skrypty backupu nieobecne tutaj
- host2 [secondary] <-- skrypty backupu umieszczone tutaj
- host3 [secondary] <-- skrypty backupu nieobecne tutaj

mongo_backup:
  enabled: true
  dbs:
    - admin
    - config
    - local
  user: backup
  pass: change_me
  path: /var/lib/mongo_backups
  owner: mongodb
  group: mongodb
  mode: '0660'
  hour: 2
  minute: 5
  day: "*"
  retention: 46  # w godzinach

Upewnij się, że zmienisz hasło użytkownika backupu i zezwolisz mu na wykonanie backupu danej bazy danych.

Na dysku, wynik będzie wyglądał następująco:

[root@test-multi-03 mongo_backups]# pwd ; ls -larth
/var/lib/mongo_backups
total 4.0K
drwxr-xr-x. 36 root   root   4.0K Jan 20 12:33 ..
lrwxrwxrwx   1 root   root     46 Nov 20 12:37 latest -> /var/lib/mongo_backups/mongo_backup_2021-11-20
drw-rw----   3 mongod mongod   51 Nov 20 12:37 .
drwxr-xr-x   5 root   root     77 Nov 20 12:38 mongo_backup_2021-11-20

Rotacja logów

Proszę zapoznać się z dokumentacją. Upewnij się, że ustawienia są skonfigurowane prawidłowo.

Aktualizacje

Przed aktualizacją upewnij się, że przeprowadzono odpowiednie testy. Zacznij od przeczytania najnowszych zmian w oficjalnej dokumentacji.

Istnieje osobny playbook aktualizacyjny, zobacz playbooks/update.yml. Ustaw odpowiednią nazwę hosta i po prostu uruchom playbook.

Aktualizacji można łatwo dokonać dla wersji poprawek, np. z 6.0.1 do 6.0.2.
Ta rola nie obejmuje aktualizacji wersji głównych z powodu przełomowych zmian w każdej wersji i innych oczywistych powodów.

Jeśli jest to pożądane, logika jest już zawarta w playbooku aktualizacyjnym, aby przeprowadzić rzeczywistą aktualizację wersji głównej.

Nowe zmienne mogą być ustawione podczas aktualizacji mongo. Aby zaktualizować:

mongo_state: latest

# ustawienie nowych zmiennych jest możliwe podczas aktualizacji mongo
mongo_net:
  new_variable: true

Podczas aktualizacji upewnij się, że aplikacje nie zapisują danych w mongo. Upewnij się również, że backup został utworzony wcześniej.

Aktualizacja zestawu replik

Jeśli zestaw replik jest aktywny, klaster należy utrzymać po aktualizacji. Zgodnie z dokumentacją, wykonywane są następujące kroki:

 - zweryfikuj zdrowie klastra, jeśli ok, kontynuuj

 - zamknij aplikację mongo na arbiterze, jeśli jest obecny
 - zaktualizuj mongo na arbiterze
 - umieść konfigurację na arbiterze
 - uruchom mongo na arbiterze

 - czekaj, aż zdrowie klastra będzie ok

 - zamknij aplikację mongo na wtórnym
 - zaktualizuj mongo na wtórnym
 - umieść konfigurację na wtórnym
 - uruchom mongo na wtórnym

 - czekaj, aż zdrowie klastra będzie ok

 - powtórz dla pozostałych wtórnych

 - zrzuć głównego
 - zaktualizuj mongo na oryginalnym głównym
 - umieść konfigurację na oryginalnym głównym
 - uruchom mongo na oryginalnym głównym

 - czekaj, aż zdrowie klastra będzie ok

Aktualizacja sharded environment

W fazie rozwoju.

Rozwój

• Istnieje playbook resetowania, aby usunąć wszystkie pliki mongo. Jest to przydatne do celów rozwojowych, zobacz tasks/reset.yml. Jest to zaprojektowane w formie komentarza.

Skalowanie

Wciąż w fazie rozwoju... Nie jestem pewien, czy kiedykolwiek będę potrzebował tej funkcjonalności, ponieważ obecnie nie jest to możliwe z mongo 5.0.
Nie jest łatwo skonfigurować skalowanie w mongo za pomocą Ansible, ponieważ metoda nie jest bezpośrednia.

Jak dotąd widziałem, że kroki powinny być:

• Jeśli arbiter jest obecny w konfiguracji i w systemie
  • usuń arbitra z klastra
• Dodaj nowy wtórny lub wtórnych
• Dodaj arbitra, jeśli jest skonfigurowany

Próbowałem konfigurować to niezliczoną ilość razy, ale zawsze kończyło się błędem systemowym. Postanowiłem na razie nie uwzględniać skalowania.

Przykład playbooka

- hosts:
    - mongo_primary
    - mongo_secondary
    - mongo_arbiter
  roles:
    - ansible_role_mongodb_ubuntu
  any_error_true: true
  vars:
    mongo_restart_config: true
    mongo_restart_seconds: 8
    mongo_thp: true
    mongo_numa: true
    mongo_replication:
      replSetName: replicaset1
    mongo_security:
      authorization: enabled
      keyFile: /etc/keyfile_mongo
    mongo_admin_pass: something
    mongo_adminuser_pass: something
    mongo_net:
      bindIp: 0.0.0.0
      port: 27017
    mongo_systemlog:
      destination: file
      logAppend: true
      path: /opt/somewhere/mongod.log
    mongo_storage:
      dbPath: /opt/mongo/
      journal:
        enabled: true
    mongo_user:
      - database: burgers
        name: bob
        password: 12345
        state: present
        update_password: on_create    
  pre_tasks:
    # upewnij się, że to zostało wykonane
    # - name: upewnij się, że hosty mogą się wzajemnie połączyć poprzez nazwy hostów
    #   template:
    #     src: hosts.j2
    #     dest: /etc/hosts