W poprzednich postach z tej serii blogów omówiliśmy wdrażanie klastrów/replikacji (MySQL / Galera, MySQL Replication, MongoDB i PostgreSQL), zarządzanie i monitorowanie istniejących baz danych i klastrów, monitorowanie wydajności i kondycji, jak sprawić, by konfiguracja była wysoce dostępne za pośrednictwem HAProxy i MaxScale, jak przygotować się na awarie poprzez planowanie kopii zapasowych, jak zarządzać konfiguracjami baz danych i w ostatnim poście, jak zarządzać plikami dziennika.
Jednym z najważniejszych aspektów zostania administratorem ClusterControl DBA jest możliwość delegowania zadań członkom zespołu i kontrolowania dostępu do funkcji ClusterControl. Można to osiągnąć, korzystając z funkcji zarządzania użytkownikami, która pozwala kontrolować, kto może co robić. Możesz nawet pójść o krok dalej, dodając zespoły lub organizacje do ClusterControl i mapując je do swoich ról DevOps.
Drużyny
Zespoły można postrzegać jako pełną organizację lub grupy użytkowników. Klastry można przypisywać do zespołów, dzięki czemu klaster jest widoczny tylko dla użytkowników z zespołu, do którego został przypisany. Pozwala to na prowadzenie wielu zespołów lub organizacji w jednym środowisku ClusterControl. Oczywiście konto administratora ClusterControl nadal będzie mogło widzieć wszystkie klastry i zarządzać nimi.
Możesz utworzyć nowy zespół w menu bocznym -> Zarządzanie użytkownikami -> Zespoły i klikając znak plus po lewej stronie w sekcji Zespoły:
Po dodaniu nowego zespołu możesz przypisać użytkowników do zespołu.
Użytkownicy
Po wybraniu nowo utworzonego zespołu możesz dodać nowych użytkowników do tego zespołu, naciskając znak plus w prawym oknie dialogowym:
Wybierając rolę, możesz ograniczyć funkcjonalność użytkownika do superadministratora, administratora lub użytkownika. Możesz rozszerzyć te domyślne role w sekcji Kontrola dostępu.
Kontrola dostępu
Role standardowe
W ClusterControl domyślne role to:superadministrator, administrator i użytkownik. Superadministrator to jedyne konto, które może administrować zespołami, użytkownikami i rolami. Superadministrator może również migrować klastry między zespołami lub organizacjami. Rola administratora należy do określonej organizacji i umożliwia wyświetlanie wszystkich klastrów w tej organizacji. Rola użytkownika może zobaczyć tylko klastry, które utworzył.
Role użytkownika
Możesz dodać nowe role na ekranie kontroli dostępu opartej na rolach. Możesz zdefiniować uprawnienia dla funkcji, niezależnie od tego, czy rola jest dozwolona (tylko do odczytu), odrzucona (odmowa), zarządzaj (zezwalaj na zmianę) lub modyfikowana (zarządzanie rozszerzone).
Jeśli utworzymy rolę z ograniczonym dostępem:
Jak widać, możemy utworzyć użytkownika z ograniczonymi prawami dostępu (głównie tylko do odczytu) i upewnić się, że ten użytkownik niczego nie złamie. Oznacza to również, że możemy tutaj dodać role nietechniczne, takie jak Menedżer.
Zauważ, że rola superadministratora nie jest tutaj wymieniona, ponieważ jest to rola domyślna z najwyższym poziomem uprawnień w ramach ClusterControl i dlatego nie można jej zmienić.
Dostęp do LDAP
ClusterControl obsługuje uwierzytelnianie Active Directory, FreeIPA i LDAP. Pozwala to na integrację ClusterControl w Twojej organizacji bez konieczności ponownego tworzenia użytkowników. We wcześniejszych wpisach na blogu opisaliśmy, jak skonfigurować ClusterControl do uwierzytelniania w OpenLDAP, FreeIPA i Active Directory.
Po skonfigurowaniu uwierzytelnianie względem ClusterControl będzie postępować zgodnie z poniższą tabelą:
Zasadniczo najważniejszą częścią tutaj jest mapowanie grupy LDAP na rolę ClusterControl. Można to zrobić dość łatwo na stronie Ustawienia LDAP w Zarządzaniu użytkownikami.
Powyższe okno dialogowe zmapuje DevopsTeam do roli ograniczonego użytkownika w ClusterControl. Następnie powtórz to dla każdej innej grupy, którą chcesz zmapować. Następnie każdy użytkownik uwierzytelniający się w ClusterControl zostanie uwierzytelniony i autoryzowany przez integrację LDAP.
Ostateczne myśli
Połączenie wszystkich powyższych elementów umożliwia lepszą integrację ClusterControl z istniejącą organizacją, tworzenie określonych ról z ograniczonym lub pełnym dostępem oraz łączenie użytkowników z tymi rolami. Piękno tego polega na tym, że jesteś teraz znacznie bardziej elastyczny w sposobie organizowania infrastruktury bazy danych:kto może co robić? Możesz na przykład przekazać zadanie sprawdzania kopii zapasowych inżynierowi ds. niezawodności witryny, zamiast codziennie sprawdzać je przez administratora. Pozwól swoim programistom sprawdzać pliki dzienników MySQL, Postgres i MongoDB w celu skorelowania ich z ich monitorowaniem. Możesz również pozwolić starszemu programiście na skalowanie bazy danych przez dodanie większej liczby węzłów/odłamków lub poprosić doświadczonego inżyniera DevOps o doradców pisania.
Jak widać możliwości są tu nieograniczone, pozostaje tylko kwestia ich odblokowania. W serii blogów Developer Studio zanurzamy się głębiej w automatyzację za pomocą ClusterControl, a do integracji DevOps niedawno wydaliśmy CCBot.
