sql >> データベース >  >> NoSQL >> MongoDB

ClusterControlを使用したデータベースユーザー管理

    このブログシリーズの以前の投稿では、クラスタリング/レプリケーション(MySQL / Galera、MySQLレプリケーション、MongoDB&PostgreSQL)の展開、既存のデータベースとクラスターの管理と監視、パフォーマンスの監視と正常性、セットアップを高度に行う方法について説明しました。 HAProxyとMaxScaleから利用でき、バックアップをスケジュールして災害に備える方法、データベース構成を管理する方法、最後の投稿でログファイルを管理する方法。

    ClusterControl DBAになるための最も重要な側面の1つは、タスクをチームメンバーに委任し、ClusterControl機能へのアクセスを制御できるようにすることです。これは、誰が何を実行できるかを制御できるユーザー管理機能を利用することで実現できます。チームまたは組織をClusterControlに追加し、それらをDevOpsロールにマッピングすることで、さらに一歩進めることもできます。

    チーム

    チームは、完全な組織またはユーザーのグループのいずれかと見なすことができます。クラスターはチームに割り当てることができます。このようにして、クラスターは、割り当てられたチーム内のユーザーにのみ表示されます。これにより、1つのClusterControl環境内で複数のチームまたは組織を実行できます。明らかに、ClusterControl管理者アカウントは引き続きすべてのクラスターを表示および管理できます。

    [サイドメニュー]->[ユーザー管理]->[チーム]を選択し、左側の[チーム]セクションの下にあるプラス記号をクリックして、新しいチームを作成できます。

    新しいチームを追加した後、ユーザーをチームに割り当てることができます。

    ユーザー

    新しく作成されたチームを選択したら、右側のダイアログのプラス記号を押して、このチームに新しいユーザーを追加できます。

    ロールを選択することにより、ユーザーの機能をスーパー管理者、管理者、またはユーザーのいずれかに制限できます。これらのデフォルトの役割は、[アクセス制御]セクションで拡張できます。

    アクセス制御

    標準の役割

    ClusterControl内のデフォルトの役割は、スーパー管理者、管理者、およびユーザーです。スーパー管理者は、チーム、ユーザー、および役割を管理できる唯一のアカウントです。スーパー管理者は、チーム間または組織間でクラスターを移行することもできます。管理者の役割は特定の組織に属しており、この組織内のすべてのクラスターを表示できます。ユーザーロールは、自分が作成したクラスターのみを表示できます。

    ユーザーの役割

    ロールベースのアクセス制御画面内に新しいロールを追加できます。役割が許可される(読み取り専用)、拒否される(拒否される)、管理する(変更を許可する)、または変更する(拡張された管理)かどうかにかかわらず、機能ごとに特権を定義できます。

    アクセスが制限されたロールを作成する場合:

    ご覧のとおり、アクセス権が制限された(ほとんどの場合読み取り専用)ユーザーを作成し、このユーザーが何も壊さないようにすることができます。これは、ここにマネージャーのような非技術的な役割を追加できることも意味します。

    スーパー管理者の役割は、ClusterControl内で最高レベルの権限を持つデフォルトの役割であり、変更できないため、ここにはリストされていないことに注意してください。

    LDAPアクセス

    ClusterControlは、Active Directory、FreeIPA、およびLDAP認証をサポートしています。これにより、ユーザーを再作成しなくても、ClusterControlを組織内に統合できます。以前のブログ投稿では、OpenLDAP、FreeIPA、およびActiveDirectoryに対して認証するようにClusterControlを設定する方法について説明しました。

    これが設定されると、ClusterControlに対する認証は次の表に従います。

    ここで基本的に最も重要な部分は、LDAPグループをClusterControlロールにマップすることです。これは、[ユーザー管理]の[LDAP設定]ページでかなり簡単に実行できます。

    上記のダイアログは、DevopsTeamをClusterControlの制限付きユーザーの役割にマップします。次に、マップする他のグループに対してこれを繰り返します。この後、ClusterControlに対して認証するユーザーは、LDAP統合を介して認証および承認されます。

    最終的な考え

    上記のすべてを組み合わせることで、ClusterControlを既存の組織により適切に統合し、制限付きまたはフルアクセスで特定の役割を作成し、ユーザーをこれらの役割に接続できます。これの利点は、データベースインフラストラクチャを中心に編成する方法がはるかに柔軟になったことです。誰が何を実行できるのでしょうか。たとえば、DBAに毎日チェックさせる代わりに、バックアップチェックのタスクをサイト信頼性エンジニアに任せることができます。開発者がMySQL、Postgres、MongoDBのログファイルをチェックして、それらを監視と関連付けることができるようにします。また、上級開発者がノード/シャードを追加してデータベースを拡張したり、経験豊富なDevOpsエンジニアにアドバイザーを作成させたりすることもできます。

    ここでの可能性は無限であることがわかるように、それはそれらのロックを解除する方法の問題にすぎません。 Developer Studioブログシリーズでは、ClusterControlを使用した自動化について詳しく説明し、DevOps統合のために最近CCBotをリリースしました。


    1. JavaMongoDBオブジェクトのバージョン管理

    2. カスタムBSONマーシャリングの処理

    3. MongoDBの$inクエリに渡されるパラメーターの最大数はいくつですか?

    4. pymongoで動作するallowDiskUse:Trueを取得できません