SQL Clone позволяет разработчикам создавать, использовать и удалять базы данных SQL Server, такие как клоны, в своих экземплярах баз данных для разработки без использования обычных накладных расходов, которые, как правило, замедляют выполнение этой задачи. Это разница подобна разнице между ожиданием обеда и возможностью пользоваться столовой самообслуживания.

Администраторы системы сохраняют контроль над вопросами, которые им необходимы, такими как безопасность данных и контроль доступа. Они могут определять роли, назначенные каждому пользователю, и какие серверы каждый человек может устанавливать или удалять клоны. Они могут указать, какие данные должны быть замаскированы, отредактированы или удалены. Они могут указать базы данных, к которым можно получить доступ. Разработчики могут «извлекать» базы данных и удалять их по мере необходимости, но без необходимости административного входа в систему для экземпляров, которым они назначены.

Преимущества самообслуживания базы данных

В самообслуживании баз данных нет ничего нового. Радость использования контейнеров Docker SQL Server заключается в том, что вы можете просто выбрать контейнер с нужной вам базой данных, и он просто, вроде как, появится на вашей рабочей станции или сервере. Замечательно иметь контейнер SQL Server, который вы можете быстро раскрутить для случайного использования. Вы можете использовать это для своих тестов и затем разрушить это. Конечно, это требует большого количества сценариев и файловых копий, но как только вы почувствуете свободу от необходимости приставать администратора к установке базы данных для вас, вы никогда не захотите отказаться от нее. DevOps имеет смысл.

С базами данных, которые помогают управлять организацией, неизбежно, что ключевым вопросом является безопасность. В нашем энтузиазме по отношению к Docker легко забыть эту проблему. Docker улучшается. Он имеет пользовательский интерфейс для Docker Enterprise Edition, который обеспечивает групповой и пользовательский контроль доступа к изображениям Docker, но доступ к базе данных трудно автоматизировать в контейнере, поскольку экземпляр SQL Server, размещенный на виртуальной машине в работающем контейнере, неизбежно находится за пределами области Windows. Для этого требуется групповая управляемая учетная запись службы (gMSA).

Конечно, в дополнение к этому каждому контейнеру требуется своя собственная копия базы данных, поэтому нам нужно сделать столько копий базы данных, сколько разработчиков работает над своей собственной контейнерной базой данных. Большим преимуществом использования SQL Clone в качестве столовой базы данных является то, что база данных сохраняется только один раз, как изображение на сетевом ресурсе, и каждый пользователь сохраняет только различия, вызванные непосредственным изменением клона, в своем экземпляре локальной базы данных. Это означает, что процесс очень быстрый, потому что он не включает в себя большие файлы данных. Поскольку базы данных становятся больше, экономия становится очень значительной.

Как работает самообслуживание SQL Clone

Хотя SQL Clone мог обеспечить систему столовой базы данных в предыдущих выпусках, графический интерфейс на основе сети изначально (до v4) был больше ориентирован на администратора, а не на пользователя клона. Администраторы могут, если им повезет, разрешить пользователям создавать и развертывать клоны из набора образов, но они не могут контролировать образы, к которым имеет доступ каждый пользователь, или серверы и экземпляры, на которых могут быть развернуты клоны. Короче говоря, разные группы пользователей, работающие над разными проектами, но использующие одну и ту же установку SQL Clone, могут видеть и получать доступ к изображениям, клонам и экземплярам друг друга. Это будет считаться риском при оценке риска защиты данных GDPR (DPIA).

SQL Clone должен был обеспечить не только систему контроля доступа к изображениям, но и относительно простой способ защиты любых конфиденциальных данных в базе данных с помощью маскирования данных и их генерации. После этого каждый пользователь видит только ту информацию, изображения и клоны, которые актуальны.

По сути, все, что нужно потребителю, - это экземпляр SQL Server с установленным агентом SQL Clone правильной версии. В отличие от контейнера, которому требуется собственный экземпляр для запуска в виртуальной машине на сервере, экземпляр клона занимает очень мало места. Он не требует большого пространства для хранения или огромного объема памяти, а только быстрого сетевого подключения.

Клон выглядит так же, как любая другая локальная база данных в экземпляре, что неудивительно, потому что это то, что есть. Тем не менее, он использует общее сетевое хранилище для доступа к базе данных «image». Только последующие изменения, внесенные в базу данных, хранятся на локальном сервере, на котором размещен экземпляр, но SQL Server не знает, что в клоне есть что-то «другое».

Чтобы сделать выбор базы данных, члену группы необходим только доступ к серверу SQL Clone, как и любому другому локальному веб-сайту. Их ID - это либо сетевой пользователь Windows, либо, если домен отсутствует, локальный идентификатор пользователя для сервера клонов.

«Столовый» список доступных изображений и экземпляров SQL Server выбран в соответствии с потребностями пользователя. Для этого пользователи Clone сопоставляются с аутентификацией Windows. SQL Clone принимает модель ролей, пользователей и команд Docker для системы разрешений, но с добавлением, что пользователи могут быть сопоставлены непосредственно с именами входа в Windows, а также с учетными данными UserID / Password.

Система разрешений Clone

Система разрешений Clone позволяет организациям соблюдать действующее законодательство о конфиденциальности, когда изображения базы данных содержат реальные личные данные или конфиденциальные бизнес-данные. Это также означает, что пользователям предоставляется только релевантная и соответствующая информация, и больше ничего.

SQL Clone идентифицирует пользователей с помощью логинов и групп Windows и использует эту информацию для назначения им пользовательских ролей Clone, которые определяют, кто может что-то делать с SQL Clone. В SQL Clone v4 и более поздних версиях каждый пользователь SQL Clone может быть назначен команде и будет иметь доступ только к тем ресурсам (изображениям и экземплярам), которые также назначены этой команде. Все это можно сделать через веб-интерфейс пользователя или PowerShell.

Пользователи SQL Clone

Администратор домена может назначать пользователей в группы Active Directory, которые затем распознаются клоном SQL как участники, которые могут быть сопоставлены с пользователями клона SQL. Пользователи в каждой группе имеют общую роль и членство в команде. Это важный момент, потому что это означает, что администраторы домена могут назначать новых сотрудников пользователям Clone через группы и удалять оставшихся сотрудников.

Если подходящего домена нет, пользователи могут быть сопоставлены с локальными пользователями и группами Windows на сервере клонов, которые затем могут использовать эти учетные данные для входа на веб-сервер. Это позволяет SQL Clone быть доступным для пользователей, которые не находятся в домене Windows.

Роли SQL Clone 

Предварительно установлены:

• Роль Admin дает полный контроль над SQL Clone с возможностью добавлять, изменять или удалять роли, обновлять лицензии и создавать образы или клоны.
• Роль Standard позволяет пользователям создавать изображения, а затем создавать клоны из этих изображений.
• Роль Clone only ограничивает пользователей созданием клонов из изображений.

Команды SQL Clone 

Когда пользователи SQL Clone входят в команду, они получают доступ ко всем ресурсам (изображениям и экземплярам), которые назначены этой команде. Если пользователи не находятся в команде, они не видят изображения и экземпляры. Это позволяет любому лицу в локальной сети использовать SQL Clone без случайных стычек или возникновения проблем с безопасностью.

Когда пользователи добавляются в команду, они получают доступ к изображениям и экземплярам, ​​связанным с этой командой. Пользователи могут принадлежать к нескольким командам для увеличения доступа. Команды больше похожи на коллекции, поскольку совокупность пользователей, совокупность экземпляров и совокупность изображений, или совокупность всех трех, могут быть «командами».

Организация пользователей, ролей и команд клона

Вот гипотетическая схема того, как можно организовать разрешения клонирования.

Джо является администратором и может делать все что угодно, в то время как другие пользователи - это либо обычные пользователи, либо только пользователи клона. Каждая группа определяет набор экземпляров, изображений и пользователей, а команда разработчиков, например, имеет доступ ко всем пяти изображениям и всем шести экземплярам.

Однако если у каждого разработчика есть свой собственный компьютер для разработки, а также доступ к каким-либо совместно используемым экземплярам, то каждый разработчик будет иметь доступ к компьютеру для разработки друг друга. Чтобы избежать этого, может быть проще использовать команды так же, как можно использовать коллекцию. В следующем примере команда In Common, членом которой являются все пользователи, представляет собой просто набор изображений. Команды DevMachineX просто предоставляют каждому разработчику доступ к своему личному экземпляру разработки, а команда Test Cell - это просто набор экземпляров, и только тестеры являются членами этой команды и так далее.

Использование самообслуживания Clone при разработке и тестировании

SQL Clone предоставляет пользователям «контролируемый» доступ к определенному набору изображений, из которого они могут создавать, обновлять или удалять клоны в определенном наборе экземпляров. Это означает, что они могут автоматизировать использование SQL Clone в своих собственных сценариях PowerShell в соответствующий момент разработки.

Хотя специальная работа SQL Clone по созданию или удалению клонов проще всего выполнить с помощью графического интерфейса, существует множество рутинных задач, которые можно автоматизировать, таких как раскрутка и снос баз данных в рамках тестовых прогонов. Это имеет очевидное преимущество с юнит-тестами и интеграционными тестами. С помощью SQL Clone вы можете создать клон из изображения, представляющего текущую базу данных, применить к клону изменения, представляющие текущую ветвь, с которой вы работаете, и немедленно запустить все необходимые тесты, чтобы убедиться, что ветвь работает. Это уменьшает вероятность того, что задача объединения ветки в корневой каталог может привести к ошибке, которая впоследствии нарушит сборку и интеграцию.

Выводы

Существует не так много вещей, которые расстраивают разработчика больше, чем задержка в ожидании последней сборки базы данных или доступа к тестовой базе данных. Всегда остается соблазн сэкономить на работе по тестированию интеграции, масштабируемости или производительности, поскольку все они предъявляют повышенные требования к ресурсам и другим членам команды, отвечающим за работу администратора. Если самообслуживание можно сделать совместимым со многими правилами и ограничениями, которые сегодня управляют работой ИТ-отдела, то производительность и качество неизбежно возрастут.

No Comments