MongoDB
 sql >> база данни >  >> NoSQL >> MongoDB

Управление на потребителите на база данни с ClusterControl

В предишните публикации от тази серия от блогове разгледахме внедряването на клъстериране/репликация (MySQL / Galera, MySQL репликация, MongoDB &PostgreSQL), управление и наблюдение на съществуващите ви бази данни и клъстери, наблюдение на производителността и здравето, как да направите вашата настройка високо достъпно чрез HAProxy и MaxScale, как да се подготвите срещу бедствия, като планирате архивиране, как да управлявате конфигурациите на базата си данни и в последната публикация как да управлявате вашите регистрационни файлове.

Един от най-важните аспекти да станете ClusterControl DBA е да можете да делегирате задачи на членовете на екипа и да контролирате достъпа до функционалността на ClusterControl. Това може да се постигне чрез използване на функционалността за управление на потребителите, която ви позволява да контролирате кой какво може да прави. Можете дори да отидете крачка по-далеч, като добавите екипи или организации към ClusterControl и ги съпоставите с вашите DevOps роли.

Екипи

Екипите могат да се разглеждат или като пълна организация, или като групи потребители. Клъстерите могат да бъдат присвоени на екипи и по този начин клъстерът е видим само за потребителите в екипа, към който е присвоен. Това ви позволява да управлявате множество екипи или организации в една среда на ClusterControl. Очевидно администраторският акаунт на ClusterControl все още ще може да вижда и управлява всички клъстери.

Можете да създадете нов екип чрез странично меню -> Управление на потребителите -> Екипи и щракнете върху знака плюс от лявата страна под секцията Екипи:

След като добавите нов екип, можете да присвоите потребители към екипа.

Потребители

След като изберете новосъздадения екип, можете да добавите нови потребители към този екип, като натиснете знака плюс в десния диалог:

Като изберете ролята, можете да ограничите функционалността на потребителя до супер администратор, администратор или потребител. Можете да разширите тези роли по подразбиране в секцията Контрол на достъпа.

Контрол на достъпа

Стандартни роли

В ClusterControl ролите по подразбиране са:супер администратор, администратор и потребител. Супер администраторът е единственият акаунт, който може да администрира екипи, потребители и роли. Супер администраторът също така може да мигрира клъстери между екипи или организации. Ролята на администратор принадлежи на конкретна организация и може да вижда всички клъстери в тази организация. Потребителската роля може да вижда само създадените от него клъстери.

Потребителски роли

Можете да добавяте нови роли в екрана за контрол на достъпа, базиран на роли. Можете да дефинирате привилегиите за всяка функционалност дали ролята е разрешена (само за четене), отказана (отказ), управление (разрешаване на промяна) или промяна (разширено управление).

Ако създадем роля с ограничен достъп:

Както можете да видите, можем да създадем потребител с ограничени права за достъп (предимно само за четене) и да гарантираме, че този потребител няма да наруши нищо. Това също означава, че можем да добавим нетехнически роли като мениджър тук.

Обърнете внимание, че ролята на супер администратор не е посочена тук, тъй като това е роля по подразбиране с най-високо ниво на привилегии в ClusterControl и следователно не може да бъде променена.

LDAP достъп

ClusterControl поддържа удостоверяване на Active Directory, FreeIPA и LDAP. Това ви позволява да интегрирате ClusterControl във вашата организация, без да се налага да пресъздавате потребителите. В по-ранни публикации в блога описахме как да настроите ClusterControl за удостоверяване срещу OpenLDAP, FreeIPA и Active Directory.

След като това е настроено, удостоверяването срещу ClusterControl ще следва диаграмата по-долу:

По принцип най-важната част тук е да съпоставите LDAP групата с ролята на ClusterControl. Това може да се направи сравнително лесно в страницата LDAP Settings под User Management.

Диалоговият прозорец по-горе би съпоставил DevopsTeam с ролята на ограничен потребител в ClusterControl. След това повторете това за всяка друга група, която искате да картографирате. След това всеки потребител, удостоверяващ се срещу ClusterControl, ще бъде удостоверен и оторизиран чрез LDAP интеграция.

Последни мисли

Комбинирането на всичко по-горе ви позволява да интегрирате по-добре ClusterControl във вашата съществуваща организация, да създавате специфични роли с ограничен или пълен достъп и да свързвате потребителите с тези роли. Красотата на това е, че вече сте много по-гъвкави в начина, по който организирате около вашата инфраструктура на базата данни:кой какво има право да прави? Можете например да разтоварите задачата за проверка на архивиране на инженер за надеждност на сайта, вместо да карате DBA да ги проверява ежедневно. Позволете на вашите разработчици да проверят регистрационните файлове на MySQL, Postgres и MongoDB, за да ги съпоставят с тяхното наблюдение. Можете също така да позволите на старши разработчик да мащабира базата данни, като добави още възли/шардове или да имате опитен инженер DevOps да пише съветници.

Както можете да видите, възможностите тук са безкрайни, въпрос е само как да ги отключите. В поредицата блогове на Developer Studio ние се потапяме по-дълбоко в автоматизацията с ClusterControl, а за интеграцията на DevOps наскоро пуснахме CCBot.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Внедряване на MongoDB във виртуален частен облак на Amazon (VPC)

  2. Високопроизводителни MongoDB клъстери на Amazon EC2

  3. Какво е полето __v в Mongoose

  4. Не мога да намеря документи, търсещи по ObjectId с помощта на Mongoose

  5. MongoDB Агрегация със сума от стойности на масива