csuka.mongodb_ubuntu

MongoDB

Ubuntu 22.04向けにMongoDBをインストール、設定、管理するためのAnsibleロールです。

RHEL系のディストリビューション向けのMongoDBはこちらで見つけることができます。

このAnsibleロールをデプロイする前に、このファイルを注意深くお読みください。

機能

  • 推奨される生産ノートを適用(例: numaの設定および透明大きなページを無効にする
  • PSAアーキテクチャでのクラスターの初期設定(プライマリ、セカンダリ、アービター)
    • クラスターの検証を含む
  • キーファイルを自動生成してトラフィックを暗号化し、接続を安全にする
  • コミュニティ版またはエンタープライズ版をインストール可能
  • 将来を見越した設定方法で簡単に設定可能
  • アップデートプレイブックあり、パッチリリースをサポート
  • ユーザー定義のユーザーを追加
  • ユーザー定義のデータベースを追加
  • mongodumpでバックアップ
  • Mongo内から設定可能なログローテーション

このロールは冪等性があり、ansible-lintチェックを通過します。
Ansibleのバージョン2.9から最新のものまで使用できます。以前のバージョンもサポートする可能性があります。

要件

  • 知恵
  • コントローラーノードにMongoDBコレクションがインストールされていることを確認
  • ホストが互いに接続でき、ホスト名と設定されたポート(デフォルトは27017)が好ましいこと
  • データディスクとバックアップ用に十分なディスクスペースがあること

アサーション

最小限の有効な構成を保証するためにいくつかのアサーションがあります。すべてのユースケースを網羅するわけではありませんが、ほとんどのケースをカバーします。
このREADMEを注意深くお読みください。有効な構成については、モレキュールフォルダー内の変数ファイルを参照してください。

バージョニングとエディション

バージョンとエディションを設定可能です。デフォルトでは、公式のMongoDBリポジトリとGPGキーが追加されます。

mongo_repo: true
mongo_version: 6.0
mongo_edition: org  # または enterprise

現時点で、Ubuntu 22.04はMongoDB 6.0のみをサポートしており、それより古いバージョンはサポートしていません。

ログなし

デフォルトでは、セキュリティ上の理由から、いくつかのタスクのログがオフになっています。これをオンにするには:

mongo_no_log: true

推奨事項

このセクションはMongoDBの公式生産ノートに関連しています。

このロールにはいくつかの設定推奨がありますが、すべてではありません。例えば、「データベースファイルを含むストレージボリュームのatimeをオフにする」などのタスクはこのロールの範囲外です。

このロールが適用するタスクは以下の通りです:

  • numactlでMongoDBを開始し、systemdファイル内に設定
  • ゾーンクレイムを無効化
  • 透明大きなページを無効化
  • tunedプロファイルを設定

実際のシステム変更については、tasks/thp.ymlおよびtasks/numa.ymlを参照してください。

これらの設定推奨はデフォルトで適用されます。

mongo_thp: true
mongo_numa: true

設定変数

最初にdefaults/main.ymlを参照してください。

設定ファイルは/etc/mongod.confに配置されます。

Ansible設定で設定された値は、ホストの設定ファイルに正確に設定されます。キーだけが事前定義されています。例:

# Ansible設定で設定された変数
mongo_operationprofiling:
  my_Value:
    anotherValue: something

の結果、ディスク上の設定ファイルは:

operationProfiling:
  my_Value:
    anotherValue: something

キーが空文字列の場合、ディスク上の設定ファイルでコメントアウトされます。

設定可能なキーは次の通りです:

mongo_systemlog
mongo_storage
mongo_processmanagement
mongo_security
mongo_operationprofiling
mongo_replication
mongo_sharding
mongo_auditlog
mongo_snmp

Mongoのデフォルト値が事前定義されています。
何らかの理由でカスタムのキー/値を設定する必要がある場合は、次のように使用します:

mongo_custom_cnf:
  my_key:
    my_value: true

認可

設計上、3つのユーザーが作成されます:adminbackupadminuser
adminはrootロール、backupユーザーはbackupロール、adminuserはuserAdminAnyDatabaseロールを持ちます。

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

データベースとユーザー

ドキュメントから取得した、自分自身のユーザー/データベースのセットを定義します。

可能なロールについては、ドキュメントを参照してください。

ユーザーとデータベースは常にローカルホスト経由で設定され、ユーザー管理者とデータベース管理者を介して管理されます。
クラスターが構成されている場合は、プライマリホストからデータベースとユーザーの設定が行われます。

次のように設定します:

mongo_user:
# 最も簡単な形式
  - database: my_db
    name: my_user

# 標準値
  - database: another_db
    name: another_user
    update_password: on_create
    password: "123ABC!PASSWORD_XYZ"
    roles: 'readWrite,dbAdmin,userAdmin'
    state: present

# すべての可能な変数
  - database: my_db
    name: someone
    password: my_password
    update_password: on_create             # デフォルトは常に
    roles: 'readWrite,dbAdmin,userAdmin'   # デフォルトは省略
    state: absent                          # デフォルトはpresent
    ssl: true                              # デフォルトは省略
    ssl_ca_certs: /path/to/ca_certs        # デフォルトは省略
    ssl_cert_reqs: CERT_REQUIRED           # デフォルトは省略
    ssl_certfile: /path/to/ssl_certfile    # デフォルトは省略
    ssl_crlfile: /path/to/ssl_crlfile      # デフォルトは省略
    ssl_keyfile: /path/to/ssl_keyfile      # デフォルトは省略
    ssl_pem_passphrase: 'something'        # デフォルトは省略
    auth_mechanism: PLAIN                  # デフォルトは省略
    connection_options: my_conn_options    # デフォルトは省略
    create_for_localhost_exception: value  # デフォルトは省略

冪等性を保つために、update_passwordの値はon_createに設定するべきです。実際にパスワードを更新する時だけalwaysに設定し、その後on_createに戻してください。

クラスタリング

プレイ内に複数のホストがある場合、Ansibleはクラスタリングが設定されていると仮定します。

PSA(プライマリ/セカンダリ/アービター)アーキテクチャでのクラスタリングが可能で、プライマリ/セカンダリ/セカンダリの設定も可能です。

セキュリティ上の理由から、ホスト間の接続はキーファイルで保護されています。

キーファイルは自動的に生成され、安全と見なされています

mongo_security:
  keyFile: /etc/keyfile_mongo

2つのホストによるクラスタは根本的に壊れた設計であり、過半数のない状態での稼働を維持することができません。
プレイ内にちょうど2つのホストがある場合、クラスタを形成することはできません。Mongoはクラスタを形成せず、有効なレプリカセットメンバーの数が必要です。

不均等なホスト数がプレイに存在することを検証するためのアサーションがあります。

次のように設定します:

# ホストごとにロールを設定。host_varsで
mongo_replication_role: primary # または secondary、または arbiter

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

プライマリとアービターはそれぞれ1つしか設定できません。

デプロイされた後はクラスタの設計を変更するべきではありません(例えば、セカンダリからアービターに変更するなど)。

アービター

ドキュメントによれば、レプリカセットごとに1つ以上のアービターを展開しないようにしてください。

Ansibleはアービターをクラスタに正しく追加します。

mongo_replication_role: arbiter

バックアップ

バックアップは、レプリケーションなしの単一ホスト、またはプレイ内の最初のセカンダリホストに設定されます。
mongodumpを使用して、cronで実行されます。

バックアップスクリプトは最初の適用可能なセカンダリノードにのみ配置されます:

- host1 [primary]   <-- バックアップスクリプトはここにはない
- host2 [secondary] <-- バックアップスクリプトはここに配置される
- host3 [secondary] <-- バックアップスクリプトはここにはない
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  # 時間単位

バックアップユーザーのパスワードを変更し、バックアップユーザーに実際に指定されたデータベースをバックアップする権限を与えるようにしてください。

ディスク上の結果は次のようになります:

[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

ログローテーション

ドキュメントをお読みください。設定が正しく構成されていることを確認してください。

更新

更新する前に、適切なテストが行われていることを確認してください。
公式ドキュメントで最新の変更を読むことから始めてください。

別のアップデートプレイブックがあります。playbooks/update.ymlを参照してください。適切なホスト名を設定し、プレイブックを実行するだけで済みます。

パッチバージョンの更新は簡単に行えます(例:6.0.1から6.0.2への更新)。
このロールには、各リリースにおける変更のためにメジャーバージョンアップグレードは含まれていません。

もし望むのであれば、実際にメジャーアップグレードを行うためのロジックが更新プレイブック内に用意されています。

Mongoを更新する際に新しい変数を設定することも可能です。更新するには:

mongo_state: latest

# 更新する際に新しい変数を設定することが可能
mongo_net:
  new_variable: true

更新の際には、アプリケーションがMongoに書き込まないようにし、前もってバックアップが作成されていることを確認してください。

レプリカセットの更新

レプリケーションセットがアクティブな場合、更新後もクラスタを維持する必要があります。ドキュメントから引用し、以下のステップが実行されます:

 - クラスターの健康状態を確認し、問題がなければ続行

 - アービターが存在する場合、そのMongoアプリケーションをシャットダウン
 - アービターのMongoを更新
 - アービターに設定を配置
 - アービターのMongoを起動

 - クラスターの健康状態が正常になるまで待機

 - セカンダリのMongoアプリケーションをシャットダウン
 - セカンダリのMongoを更新
 - セカンダリに設定を配置
 - セカンダリのMongoを起動

 - クラスターの健康状態が正常になるまで待機

 - 残りのセカンダリに対して繰り返す

 - プライマリを降格
 - 元のプライマリのMongoを更新
 - 元のプライマリに設定を配置
 - 元のプライマリのMongoを起動

 - クラスターの健康状態が正常になるまで待機

シャーディング環境の更新

現在開発中です。

開発

  • すべてのMongoファイルを削除するリセットプレイブックがあります。これは開発目的で役立ち、tasks/reset.ymlを参照してください。設計上、コメントアウトされています。

スケーリング

現在開発中です... この機能が必要かどうかは不明ですが、Mongo 5.0では実際には機能しません。
AnsibleでMongoのスケーリングを設定するのは簡単ではなく、手法が単純ではありません。

現在までに必要なステップは以下の通りだと考えています:

  • 設定とシステムにアービターが存在する場合
    • クラスターからアービターを削除
  • 新しいセカンダリノードまたはセカンダリノードを追加
  • 設定があればアービターを追加

この設定を何度も試みましたが、常にシステムエラーのために失敗しました。今はスケーリングを含めないことにしました。

サンプルプレイブック

- 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:
    # これが完了していることを確認
    # - name: ensure hosts can connect to each other via hostnames
    #   template:
    #     src: hosts.j2
    #     dest: /etc/hosts
プロジェクトについて

Ansible role to setup and configure MongoDB

インストール
ansible-galaxy install csuka.mongodb_ubuntu
ライセンス
apache-2.0
ダウンロード
288
所有者
Oui oui