Типичный DevOps обеспечивает движение кода от Dev по направлению к PROD, и с этим все хорошо. Ну, насколько это может быть хорошо в нашем IT мире. Jenkins, Terraform, Octopus и многое другое к вашим услугам. А вот с движением информации назад все куда сложнее.
Да, во многих компаниях есть процессы копирования баз из PROD в QA и DEV (с обрезанием секретной информации), однако в сложных случаях необходимо смотреть, что происходит именно на PROD. Хотя бы логи. И, если вы работаете в Enterprise, то все сложно или очень сложно - в зависимости от уровня паранои важности информации.
В худших случаях у разработчиков нет никакого доступа на PROD, и им рассказывают (lol), что там происходит. Как вариант, организуется митинг (с 20 приглашенными), где шарится экран, и программист говорит, какие кнопки нажимать, чтобы посмотреть логи. КПД таких митингов крайне мал.
В более цивилизованных местах некоторым девелоперам или DBA могут дать временный доступ на PROD с помощью различных систем. Как пример такой системы упомяну CA PAM, которую наблюдал в работе в некоторых отделах. Минусы таких систем (с Remote Desktop Access) в том, что они дают все или ничего - потенциально доступ к PROD позволяет все там порушить, хотя, как правило, для анализа проблемы достаточен read-only доступ. Даже для доступа к СУБД, где можно явно организовать read-only доступ, проблема существует:
Из-за того, что написано во второй строчке, у RDP/Citrix доступа к PROD часто выключен copy-paste, что превращает работу в кошмар (если надо, например, скопировать на PROD полезный скрипт - увы, copy-paste нельзя отключать только в одну сторону, только полностью!)
Миссией проекта является организация безопасного метода доступа к higher environments, гарантирующего легкость и интерактивность с полным аудитом всех операций. Проект называется Bell - Action at a distance, а бородатый мужик на лого - это Джон Белл, вы его знаете по концепции "квантовой спутанности".
Что сделано
Проект полностью функционален и используется там, где я работаю. Сайт проекта тут и в этой статье я не буду повторять то, что написано на сайте, лишь кратко пройду по содержанию.
Проект, разумеется, open source. Модули сейчас пишутся на PowerShell, а сам сервер работает под Windows, хотя прямых завязок на Windows и PowerShell нет (кроме hardcode *.ps1 в некоторых местах). Конечно, хочется чтобы это рaботало и под Linux, и здесь надежда на комьюнти.
Модули пишуться очень просто - как будто собираешь что-то из лего. Как тот же Jenkins, свежеустановленный сервер 'пуст' - если в Jenkins вы создаете свои Jobs, то тут вы пишете свои модули с нуля, либо берете готовые и подпиливаете их под свою специфику. Существуют готовые модули:
MSSQL - SQL server - статистика, метрики, логи
WMI - Показывает LUNs, свободное место, состояние сервисов
VMware - Инвентории и статистики с VMware серверов (читаются из Postgre)
FileBrowse - позволяет читать файлы log, txt, xml, config на Windows серверах
PerfMon - Читает статистики Perfmon на Windows серверах и строит графики
EventLog - Показывает Event Log
Postgres - Все для базы Postgres
MySQL - Все для MySQL
AWS - Показывает состояние EC2 и RDS инстансов и позволяет показывать файлы на S3 бакетах.
Что хочется сделать
Модули: один из авторов проекта, ваш покорный слуга, MSSQL DBA. Поэтому модули Postgres, MySQL и AWS были сделаны на отъе минималистично, для СУБД я просто пытался перенести то, что сделано в MS SQL (когда есть аналог). Безусловно, если вы специалист по Postgre, MySQL (и совместимым базам), AWS - у вас будет куча идей, что добавить. Также хочется добавить поддержку Oracle.
Сервер: Фронт написан на vue.js версии 2, бэк - Node.js. Возможно, имеет смысл кое что изменить в используемом стеке.
Linux: Да, и любой shell script вместо ps1.
UI: дальнейшее развитие
Zoom In/Out для Charts
Live Charts (смотришь на них, а статистика идет)
Actions (не read-only действия) - для них потребуется ввод данных в формы.
Ждем тех, кому интересна эта тема!
Контактуйте со мной или с моим коллегой @Writer4
amarao
Ничего не понял. Вы Ансибл изобретаете или testinfra?
K27
Ansible для других целей, для развертывания готовой инфраструктуры на сервере. А тут, про создание и интеграцию новых продуктов, я так понял)
Tzimie Автор
Про обратный поток информации: метрики, состояния баз, сервисов итд
например, просто скриншотики
https://www.actionatdistance.com/vmware
https://www.actionatdistance.com/mssql
sshikov
Ну, и? Метрики и логи? А чем вам не угодили условно, Nagios (просто первое что пришло в голову), или Prometeus, ну или там Elastic? Иными словами — непонятно из текста, в чем для вас недостаток существующих решений, и какие вы смотрели.
А некоторые места просто непонятны сами по себе, и требуют пояснений, например вот:
Вот я как раз работаю через PAM. Я хожу на виртуалку, с которой есть доступ к пром серверам, например по ssh. Условно «полный» доступ у меня только к виртуалке, не более (там я могу создавать файлы, например). Доступ к прому — под личной учеткой, и права у нее где-то посредине между read-only и полными, и я не вижу, что бы такое мешало их ограничивать в принипе (кроме лени)? И все действия логируются. А в принципе, есть инструменты способные и запретить что-то (на уровне unix shell скажем).
Где это самое «все или ничего», откуда оно берется — из текста не ясно.
И кстати да, там где паранойя включена по полной, у нас есть доступ только к синонимам в базе данных, которые указывают на view в другой схеме, которые выбирают из таблиц в еще одной схеме только то, что положено видеть нашему приложению. То есть, даже имея доступ, я не смогу выбрать например данные банковских карт. Во view их нет, а создать еще view мне не дадут, да и grant select на таблицу у меня нет тоже. И как ваше решение тут поможет — не улавливается.
Tzimie Автор
по поводу view. Конечно, это рабочее решение. Но у кому принадлежит код view? Если этот дополнительный код поддерживают разработчики продукта, то это хорошо, но это вряд ли, да и невозможно для 3rd party products. А если это DBA допилил, то это а) может развалится с новой версией продукта b) хоть и безопасное, но изменение PROD. Предлагаемый продукт же не только agent-less, но и zero-touch, никаких изменений PROD не нужно
По поводу "откуда оно берется" - если (упрощая) девелоперу нужно дать читать только из таблицы LowLevelLog where DT>=getdate()-1, то именно эта кверь и имлементируется как одна из нод дерева, того, что юзер может делать. Ничего другого он сделать не сможет - просто некуда будет кликнуть.
sshikov
>А если это DBA допилил
Да, само собой. Такие вещи требуют изменений в схеме, и для купленных продуктов зачастую невозможны.
>именно эта кверь и имлементируется
Я правильно понял, что вы все возможные действия пользователя в проме пытаетесь заложить в систему как плагины?
Tzimie Автор
Не все возможные действия, а все действия, полезные и разрешенные (read-only) для девелопера. Их не так много, на самом деле. В сложных случаях да, надо лезть через RDP/CA-PAM итд, но 95% простых случаев это покрывает на практике
Tzimie Автор
Плагин это громкое слово, там скрипты из трех-четырех строчек.
sshikov
ну так и нагиос в принципе на таких же «плагинах» построен. Смотреть им файлы конечно нельзя, потому что параметров у плагина нет, которые пользователь бы мог ввести, чтобы указать файл, а в остальном они примерно тоже самое делают.
Tzimie Автор
Ну, и? Метрики и логи? А чем вам не угодили условно, Nagios (просто первое что пришло в голову), или Prometeus, ну или там Elastic?
Системы мониторинга не дают возможности смотреть на данные - лог таблицы, или вот такое: https://www.actionatdistance.com/filebrowse
Вот это у нас пользуется бешеной популярностью
sshikov
Ну да, тут я согласен. Смотреть на произвольные данные — это не мониторинг.
Writer4
Тут основная идея в простоте. Попытаюсь объяснить идею. Есть дерево, каждый листовой узел которого может быть 4-х типов - текст, html, chart, downloaded file При раскрытии узлов дерева или при выборе листового узла вызываются Power Shell скрипты, возвращающие либо список нижележащих узлов, либо информацию для листового узла в зависимости от его типа. Все, и больше ничего нет. Доступа к самим скриптам у пользователей нет, они видит только результат его работы. Скрипты выполняются на сервере (node.js), вебморда на vue показывает результат. Скрипты для примера возвращают:
списки серверов
результаты всякого perfmon
некие downloaded логи
тексты объектов бд
и т.д. и т.п. Естественно есть некоторые соглашения по формату, как писать скрипты, они достаточно простые.