От хаоса к порядку: «1С:Управление ландшафтом» для больших компаний

Расскажу об истории создания решения «1С:Управление ландшафтом» и о том, как оно помогает управлять хаосом.

Меня зовут Антон Евтушенко, я работаю в фирме «1С». Мой опыт в разработке и проектировании – более 15 лет. В фирме «1С» я руковожу группой, которая отвечает за качественную работу наших продуктов у клиентов. Мы занимаемся работами в рамках проектов ЦКТП и создаем собственные решения, которые помогают в работе не только партнерам, но и нам самим. А еще некоторые могут знать меня как преподавателя и экзаменатора на курсах подготовки к сертификации 1С:Эксперт.

Идея создания решения «1С:Управление ландшафтом» возникла, когда несколько партнеров и клиентов обратились к нам со своей болью. У них регулярно возникали проблемы при эксплуатации, сопровождении и обновлении, и они хотели получить готовый инструмент, который помог бы эти проблемы решить «из коробки». Мы задумались и решили: почему бы и правда не создать для этого продукт?

Я расскажу:

• какие боли и потребности партнеров и клиентов привели нас к идее создания продукта «1С:Управление ландшафтом»;

• какие базовые принципы заложены в его основу, и как именно он помогает решать проблемы;

• о палитре функциональных возможностей продукта;

• что у него «под капотом» – на чем построена его архитектура;

• и с чего стоит начать, если вы хотите попробовать продукт.

 

Предпосылки создания продукта: острая боль и ваши потребности

 

 

Одна из основных проблем, с которой сталкивались наши клиенты и партнеры – это многообразие систем, требующих управления.

• В корпоративной среде есть множество систем, которые помогают компании выживать и функционировать. Это могут быть как системы 1С, так и внешние сервисы, написанные на Python, Go и других языках. Все это требует администрирования, управления, поддержки – за всем этим должен кто-то следить.

• В итоге мы имеем десятки разных платформ, каждая из которых живет по своим правилам: свой интерфейс, свои особенности администрирования и эксплуатации, свои API, логины, пароли и документация. Управлять этим зоопарком систем действительно тяжело.

Мы со своей стороны понимаем, что автоматизировать управление абсолютно всеми системами невозможно – особенно если речь идет о сторонних самописных инструментах. Но наша ключевая задача – сделать так, чтобы эксплуатация 1С становилась проще, понятнее и доступнее.

 

 

Поскольку каждая система уникальна, ими приходится управлять либо вручную, либо полуавтоматически – через скрипты, которые кто-то когда-то запускает.

Множество ручных процессов приводят к ошибкам и простоям, потому что во главе всего этого стоит человек, а человек, как мы знаем, склонен ошибаться.

• Приходится нанимать дорогих узкоспециализированных специалистов, которые могут быстро решать конкретно ваши проблемы. При этом они могут достаточно хорошо знать, как работает система, но не всегда способны глубоко погрузиться в контекст для решения уникальных задач.

• Другой вариант – передать поддержку системы на аутсорс. Но здесь появляются риски простоев из-за проблем с коммуникацией, задержками в решении задач, зависимости от внешних графиков и приоритетов подрядчика. То, что вы хотели бы решить сегодня, может сдвинуться на послезавтра.

 

 

Ещё один типичный запрос, с которым к нам приходили клиенты и партнеры – это проблема управления пользователями.

Классическая ситуация – пользователь сообщает, что у него нет доступа или не хватает прав. Такие сообщения бывают очень разными. Хорошо, если сотрудник хотя бы прикладывает скриншот – тогда можно по косвенным признакам понять:

• куда пытался войти пользователь;

• можно ли ему туда входить;

• к чему у него должен быть доступ, а к чему – нет.

Чаще всего пользователи ничего не прикладывают, и тут хоть экстрасенсов зови, чтобы понять, что именно не работает. В худшем случае приходится звонить пользователю и выяснять детали лично.

Когда отсутствует централизованное управление, невозможно быстро понять, куда именно у пользователя есть доступ, какие права выданы, а какие – нет.

 

 

Другая проблема – это создание и блокировка учетных записей.

Когда база одна, создать в ней одного пользователя несложно. Но когда баз несколько и пользователя нужно создать сразу во всех базах, или еще хуже, когда нужно дать доступ к базам сразу группе пользователей, сразу возникают вопросы:

• под кем нужно зайти;

• какие адреса подключения у каждой из систем, в которые нужно зайти;

• какие полномочия там вообще есть;

• какие полномочия нужно дать конкретно этому пользователю.

После всех этих уточнений начинается: «зайди в одну базу, создай там пользователя, добавь его в нужные группы доступа, а потом повтори то же самое для каждой системы». Это долгая и кропотливая работа, которая требует повышенной внимательности. А если администратор забудет добавить разрешения на работу с конкретной системой или некоторые права – пользователь как раз придет и скажет: «У меня недостаточно прав, не могу работать».

Обратная сторона этой же проблемы – блокировка учетных записей пользователей. Нередко бывает так, что сотрудник переходит в другой отдел, у него меняются задачи и доступы. Или он увольняется. Бывает, мы случайно забываем забрать у человека доступы – и тогда безопасность наших данных держится только на порядочности этого сотрудника.

 

 

Еще одна боль, о которой нам рассказывали партнеры и клиенты – это обновление систем.

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

• Обновление включает в себя слишком много ручных действий, каждое из которых связано с рисками. Классический процесс обновления выглядит так: нужно открыть конфигуратор, выбрать правильный файл, выгнать из базы пользователей, запустить обновление и дождаться его окончания. И это только для одной информационной базы. А когда баз несколько, это нужно повторить для каждой из баз.

• А теперь представьте: у вас много однотипных систем, и в одной из них всплыла ошибка, «нужно по-быстрому ее исправить прямо на проде». В результате часть систем оказывается в одном состоянии, часть – в другом, версии расходятся, и начинается путаница, которую потом сложно разгрести.

• В большинстве случаев история обновления не ведется, и в результате непонятно – кто, когда и что именно обновлял. Конечно, правильная практика эксплуатации – вести журнал изменения системы, где фиксировать обновления ее кода. Но писать такой журнал вручную долго, скучно и утомительно. Хотелось бы, чтобы система делала это автоматически, без участия человека.

Проблема ручных обновлений в том, что:

• нужно договориться с пользователями о технологическом окне;

• важно делать все в правильной последовательности;

• одна ошибка, и ты ошибся – придется все переделывать или еще хуже, восстанавливаться из копии.

 

Ключевые принципы решения «Управление ландшафтом»

 

Мы решили создать «1С:Управление ландшафтом», потому что нам хотелось дать компаниям единое автоматизированное решение для превращения хаоса из множества разрозненных систем в понятный и управляемый ландшафт – минимизировать ошибки в работе техподдержки, а также снизить риски и затраты на обслуживание корпоративных информационных систем.

Расскажу, что лежит в основе нашего решения, и на какие принципы мы опирались при его разработке.

 

 

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

 

 

Второе – простота и интуитивность использования.

Мы постарались сделать интерфейс решения максимально простым и понятным, не перегрузить его лишними деталями, сделать так, чтобы любое действие выполнялось максимально просто. Если операцию можно сделать за один шаг, значит она должна выполняться за один шаг, а не за 110.

 

 

Следующее, что нам было важно – это поддержка в решении всех последних возможностей платформы и продуктов из экосистемы 1С.

За последнее время в экосистеме 1С появилось множество интересных и крутых механизмов, которые помогают работать быстрее и качественнее. Некоторые из них требуют настройки, и хотя разработчики стараются сделать процесс максимально понятным, но на практике люди иногда сталкиваются с проблемами, поскольку действуют по принципу: «сначала делаем, потом читаем документацию».

Благодаря тому, что наш продукт предоставляет единое окно и возможность централизованного управления всеми этими механизмами, мы позволяем настраивать их прямо из нашего решения. Например, у нас уже поддержана функциональность фонового обновления информационной базы без простоев, которая появилась в 8.5.3.

 

 

Мы применили в нашем продукте готовые лучшие практики, позволяющие расследовать проблемы и настраивать системы для стабильной и качественной работы.

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

 

Палитра возможностей 1С:Управление ландшафтом

 

Кратко рассмотрим палитру возможностей продукта «1С:Управление ландшафтом». В нее входит:

• Установка платформы.

• Управление кластерами серверов.

• Развертывание информационных баз и управление информационными базами и приложениями. Под «приложениями» я имею в виду разделенные базы, у которых есть области данных – в терминологии 1С:Фреш они называются приложениями, и мы тоже решили называть их приложениями, чтобы было проще и понятней.

• Управление веб-серверами и веб-публикациями

• Управление пользователями и их полномочиями

• Управление обновлениями.

 

Установка платформы

 

Раньше для установки платформы на сервер требовалось:

• подключиться к серверу;

• скопировать на него дистрибутив;

• установить;

• проверить работу служб;

• не забыть запустить RAS, иначе возникнет сложность с удаленным администрированием – для изменения настроек к серверу придется каждый раз подключаться;

• и так требовалось повторить для каждого сервера – т.е. если нужно развернуть 10 серверов, нужно проделать все это 10 раз.

Как стало:

• нужно однократно загрузить в 1С:Управление ландшафтом дистрибутив платформы;

• выбрать хост для размещения сервера;

• дождаться окончания установки.

 

 

Покажу, как выглядит этот процесс в 1С:Управление ландшафтом:

• Мы переходим в раздел меню «Инфраструктура» – «Версии платформы» и создаем новую версию с видом «Предприятие 8».

• Загружаем в карточку версии скачанные с портала релизов zip-архивы. Причем мы сразу загружаем архивы и для Linux, и для Windows, чтобы работать и с тем, и с другим.

• Сохраняем версию.

Далее переходим к установке агентов серверов 1С на конкретные хосты.

• В меню «Инфраструктура» – «Агенты серверов 1С» выбираем пункт «Создать новый». Здесь же есть пункт «Существующий» – с его помощью можно подключиться к уже существующей площадке, но в этом случае часть функциональности работать не будет – если мы к серверу подключились снаружи, службой агента сервера мы управлять не сможем.

• Выбираем хост, на котором заранее установлен агент управления инфраструктурой, помогающий всем этим управлять.

• Указываем порт.

• Указываем версию платформы.

• Нажимаем кнопку «Создать», после чего дистрибутив платформы устанавливается на выбранный сервер.

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

 

Управление кластерами серверов

 

 

Следующая возможность – управление кластерами серверов.

Раньше, для того, чтобы собрать кластер и настроить для него ТНФ, нужно было:

• Вспомнить, где находится центральный сервер.

• Вспомнить, какая версия платформы установлена на центральном сервере, а какая – на рабочем сервере. Эти версии, естественно, должны совпадать.

• Настроить требования назначения функциональности.

• Вспомнить логин и пароль администратора кластера.

 

 

Как это работает теперь:

• Мы заходим в раздел «Кластеры» и вызываем команду «Создать».

• Выбираем машину центрального сервера, для которой создается кластер.

• Указываем порт менеджера и записываем изменения.

Далее заходим в кластер и переходим внутри него в раздел «Рабочие серверы»:

• Добавляем новый рабочий сервер.

• В поле «Агент сервера» выбираем узел из доступного списка.

• В поле «Диапазоны IP-портов» определяем порты, на которых наши рабочие процессы будут запускаться.

• Записываем изменения – у нас создается рабочий сервер.

Дальше переходим в карточку рабочего сервера и проставляем для него значения в разделе «Требования назначения функциональности».

• Добавляем новую строку, где в качестве объекта требований указываем «Сервис журнала регистрации».

• Таким же образом добавляем еще одну строку, где в качестве объекта требований – «Сервис полнотекстового поиска».

• Для обеих строк устанавливаем тип требования – «Назначать».

• Допустим, что этот рабочий сервер у нас считается основным, значит, согласно лучшим практикам, задаем для него приоритет обоих объектов требований.

• Сохраняем изменения.

Далее переходим ко второму серверу кластера – для него также проставляем значения в разделе «Требования назначения функциональности».

• Также указываем тип требования – «Назначать».

• Но приоритет устанавливаем – 0.

После того как мы все назначим, система автоматически поймет, что в конфигурации кластера появились изменения и предложит нам применить ТНФ.

Здесь поведение осталось таким же, как и в консоли кластеров – слева у нас показывается сообщение о том, что есть изменения. И в истории операций вся изменения логируются – можно увидеть, что у нас было применение ТНФ, и оно было успешным.

Для проверки мы подключаемся к консоли кластера и видим: у нас в кластере два сервера, и значения ТНФ на каждом из них указаны ровно такие, как мы и назначали – т.е. все транслировалось как нужно.

 

Управление информационными базами и приложениями

 

 

Следующая задача, которая, думаю, знакома всем 1С-никам – это развертывание информационных баз.

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

• Нужно найти нужную версию платформы, которая будет подходить под этот DT-файл.

• Нужно вспомнить логин и пароль, в том числе от СУБД – указать эти данные при подключении.

• Нужно принести файл (DT или CF) для развертывания.

• Дождаться окна о том, что информационная база успешно загружена, и нажать кнопку для перезапуска. Причем пока вы эту кнопку не нажмете, база так и не будет считаться развернутой – будет висеть, ожидая вашу реакцию.

 

 

Теперь о том, как эта же задача решается в 1С:Управлении ландшафтом.

У нас есть специальное хранилище для шаблонов – «Инфраструктура» – «Шаблоны информационных баз».

• Мы создаем новый шаблон.

• Загружаем в него DT-файл.

• И даем название, которое описывает состояние этого файла – в данном случае, «Демо БСП 3.1.11.202».

После того как DT-файл сохранится в хранилище, его уже не нужно будет таскать на отдельные машины вручную – агент все сделает за вас сам.

Дальше мы переходим в меню «Ландшафт» – «Информационные базы» и создаем новую базу:

• Указываем вариант «Из шаблона» и выбираем из уже загруженных шаблонов тот, в котором находится нужный DT-файл.

• Указываем имя базы – как мы хотим, чтобы она называлась в дальнейшем.

• Выбираем кластер серверов, на котором должна быть размещена база.

• И сервер СУБД, на котором она будет размещаться. Сервер СУБД здесь показывается справочно, конкретно про него никакой информации нет, и пока мы серверами СУБД не управляем, но в будущем очень хотелось бы – как минимум, чтобы не нужно было каждый раз создавать логины и пароли.

• Еще здесь есть галочки «Разрешить выдачу лицензий сервером 1С:Предприятие» и «Блокировать регламентные задания» – вы можете сразу создать базу с нужными параметрами. Чаще всего лицензии нужно раздавать, поэтому эта галочка используется. А с блокировкой регламентных заданий все бывает по-разному, но если вам нужно их заблокировать сразу при создании, то без проблем – здесь все как в стандартном стартере 1С, блокируете сразу, и все.

Ждем некоторое время, база разворачивается, и мы видим статус, что база работает.

В данном случае мы создадим из одного шаблона три базы – очень просто и быстро. Не нужно никуда подключаться. Система автоматически сама все сообщит.

 

 

Следующая история – это управление информационными базами и приложениями.

Иногда у администраторов возникают вопросы:

• Под управлением какой СУБД работает эта база?

• Где этот сервер СУБД вообще находится?

• Какие еще базы есть в том кластере, на котором размещена конкретно эта база?

 

 

В «Управлении ландшафтом» вы просто заходите в карточку информационной базы, переключаетесь на закладку «Свойства» и видите, какой сервер СУБД здесь указан – в него можно провалиться и увидеть необходимую информацию.

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

 

Управление веб-серверами

 

 

Следующая достаточно удобная возможность – это управление веб-серверами.

Раньше, чтобы установить и настроить веб-сервер для работы с 1С, нужно было:

• Вспомнить, какая версия компоненты 1С нужна.

• Найти конфигурационный файл, прописать в него этот подключаемый модуль.

• И потом убедиться, что все заработало.

 

 

Теперь все проще:

• Вы просто переходите в пункт «Инфраструктура» – «Веб-серверы» и вызываете команду «Создать новый».

• Выбираете хост, на котором будет размещен веб-сервер.

• Указываете версию платформы и жмете «Создать» – больше ничего делать не нужно.

Система автоматически скачает Apache (пока мы поддерживаем только его и только на Linux), настроит его для работы с нужной платформой и запустит.

А поскольку Apache – это тоже служба, для него справа также доступны элементы управления: вы можете эту службу остановить, запустить или перезапустить.

 

Управление веб-публикациями

 

Следующее – управление веб-публикациями.

Все, кто когда-либо сталкивались с публикацией базы на веб-сервере, знают, здесь есть свои определенные особенности:

• Например, чтобы опубликовать базу, вам нужно либо запустить конфигуратор от имени администратора, либо воспользоваться утилитой webinst, которая также имеет свои нюансы в использовании.

• А потом при публикации еще есть целая куча настроек, в которых нужно разобраться и установить правильно.

 

 

В «Управлении ландшафтом» все это выглядит намного проще. Если помните, мы ранее создавали три базы, сейчас мы каждую из них опубликуем:

• Заходим в пункт меню «Инфраструктура» – «Веб-публикации» и вызываем команду «Создать».

• Выбираем веб-сервер, где эта веб-публикация будет размещаться.

• Указываем информационную базу, которую хотим опубликовать.

• Прописываем путь, по которому эта база будет доступна (если на одном сервере публикуется несколько баз, их пути, конечно, должны различаться).

• И проставляем настройки: вид базы, аутентификация через логин/пароль, параметры публикации и т.д. Пока доменная аутентификация или аутентификация через OpenID Connect здесь не доступны, но в дальнейшем все это будет поддерживаться.

Повторяем эти действия для наших трех баз.

Обратите внимание, что из карточки веб-публикации можно по ссылке перейти и проверить, как база опубликовалась. Удобно.

 

Управление пользователями и их полномочиями

 

Следующая возможность – это управление пользователями и их полномочиями.

Знакомая всем ситуация: в компанию приходит новый сотрудник, и его нужно завести во все необходимые базы. Раньше это был целый марафон – администратор должен был:

• зайти в нужную информационную базу;

• создать этого пользователя;

• не забыть ему указать правильные логин и пароль;

• добавить ему правильные доступы, нигде не ошибиться;

• и потом повторить это для каждой информационной базы, куда сотруднику нужен доступ (или для каждой области данных, если у вас разделенная база).

 

 

А теперь о том, как это выглядит сейчас:

• В «Управлении ландшафтом» единое хранилище для всех пользователей. Мы создаем там пользователя и указываем для него необходимые параметры: наименование (фамилию, имя, отчество), логин и пароль, которые будут дальше использоваться в дальнейшем во всех системах.

• Далее переходим в раздел «Пользователи» – «Группы доступа», открываем нужную группу доступа и добавляем в нее нового сотрудника. Эти группы доступа загружаются из информационных баз заранее – вместе с профилями и ролями, которые к ним относятся. Система уже знает, какие группы существуют, каким профилям они соответствуют, и какие конкретные права за ними закреплены.

• На закладке «Приложения» у группы доступа мы можем указать, какие информационные базы будут доступны пользователям этой группы – так мы можем настроить, чтобы этот пользователь сразу получил доступ по все три базы, которые мы завели.

• И после записи изменений эта информация автоматически уходит через 1С:Шину в наши информационные базы.

Через несколько секунд пользователь уже создан во всех указанных базах. Мы можем открыть любую из них и убедиться, что пользователь там уже прописан, имеет нужные права и может заходить, работать с системой.

 

Управление обновлениями

 

Следующий блок возможностей – это управление обновлениями.

Обновление кажется достаточно простой операцией, но на практике в нем тоже есть свои нюансы:

• Что делать, если надо обновить не одну, а десятки или даже сотни этих баз – и все на одну и ту же версию?

• Как гарантировать, что обновление, проверенное на тестовом стенде, не будет отличаться от того, что вы зальете на продуктив?

• Как ответить на вопрос: кто, когда и каким образом обновил конкретную базу?

Также важно заранее понимать ответы на вопросы, которые ставят обновления перед бизнесом и службой эксплуатации:

• Первый и один из важных вопросов – каким будет время простоя, как долго система вообще будет обновляться и сколько времени пользователи будут не работать в информационной базе. Естественно, чем меньше будет время простоя, тем лучше.

• Второй вопрос – для чего вообще выполняется обновление? Какие функциональные возможности появятся? Какие ошибки будут исправлены? Какие задачи вольются? Все это хочется видеть и понимать из единого места.

• Также нужна повторяемость – чтобы в продуктивную базу вошли только протестированные изменения, которые были всеми проверены и одобрены.

• Ну и, конечно, уверенность в том, что ничего не поломается после обновления.

 

 

Расскажу, как мы обеспечиваем управление обновлениями и идентичность этих самых обновлений.

• Все обновления мы решили собрать в пакет – завели отдельную сущность и назвали ее «пакет». По сути, это основная транспортная единица в нашей системе доставки.

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

• Или в пакет могут входить изменения для произвольного набора расширений – при этом расширения мы можем и поставить, и удалить, и обновить, поэтому здесь есть свои особенности.

 

Доставка обновлений

 

У нас есть такое понятие, как задача доставки – по сути, средство распространения пакетов изменений по нашей системе.

Задача доставки может быть:

• одиночной – когда пакет изменений доставляется в одну информационную базу или в одну область в случае расширения;

• групповой – когда изменения отправляются сразу на целую группу баз или приложений.

У задачи есть история доставки:

• общая – можно посмотреть, как задача доставки выполняется в целом по всей системе;

• для конкретного пакета изменений – можно узнать, что происходило с конкретным пакетом: где что упало и что пошло не так, или как все прошло замечательно и успешно.

При этом по задаче всегда можно получить ответы на вопросы:

• Кто и когда создал задачу?

• С какими параметрами создали задачу?

• С каким результатом завершилась задача?

В зависимости от того, куда задача может доставить изменения, объектами доставки могут быть:

• информационная база;

• группа информационных баз;

• группа приложений (или областей данных, если речь идет про расширение).

При этом у задачи доставки также есть параметры обновления – вы можете выполнять:

• Обновление на сервере.

• Динамическое обновление.

Также есть варианты реструктуризации:

• Монопольное обновление информационной базы.

• Оптимизированный механизм реструктуризации, также известный как реструктуризация v2 или java-реструктуризация.

• Динамическая реструктуризация – обновление без простоев, которое появилось в 8.5.3.

 

 

Покажу, как это выглядит.

• В разделе «Проекты» находим наш проект – по сути, отражение конфигурации.

• В карточке проекта нажимаем кнопку «Добавить версию конфигурации».

• С помощью перетаскивания загружаем в область «Исходные данные конфигурации» CF-файл.

• Описываем параметры новой версии – указываем номер версии, поставщика, режим совместимости, минимальная версия платформы и так далее.

Дальше мы будем делать из нашей сборки пакет изменений для наших баз, для этого в разделе «Доставка изменений» – «Пакеты изменений» создаем новый пакет:

• Выбираем проект – то, что мы будем обновлять.

• На закладке «Конфигурация» выбираем определенную версию – ту, которую мы загрузили до этого в карточку проекта

• Задаем пакету человекочитаемое наименование, чтобы было понятно, что за обновление там внутри.

• Обратите внимание здесь на поле «Код пакета» – это некий идентификатор, который можно синхронизировать с внешними системами управления изменениями, такими как Git или СППР. С помощью этого кода вы потом можете узнать, какие изменения есть в вашем пакете поставки и так далее.

Дальше мы сохраняем этот пакет, открываем его заново и создаем задачу доставки через команду «Доставка изменений»:

• Сначала в качестве объекта доставки мы указываем вариант «Информационной базе», потому что в первую очередь хотим проверить наши изменения в одной базе, чтобы убедиться, что все работает корректно. В поле «Информационная база» выбираем нужную базу, и обновление проходит – на закладке «История доставки» в пакете изменений можно увидеть длительность выполнения задачи.

• Дальше мы уже хотим обновить сразу несколько баз – указываем для команды «Добавить изменения» вариант «Группе информационных баз» и выбираем нужные базы. Задача запускается, и в истории доставки мы сможем увидеть, что наши базы успешно обновились, и с ними уже можно работать.

Эти же изменения мы сразу видим и в списке информационных баз – там теперь отображается новая версия проекта.

 

Доставка расширений

 

Теперь о доставке расширений. В рамках пакета изменений можно:

• Установить одно или несколько расширений.

• Не только установить, но и обновить расширения.

• И даже удалить расширения, если вдруг по какой-то причине они стали не нужны.

 

 

Расширения можно доставлять:

• в одну или несколько информационных баз – в задаче доставки мы выбираем базы, куда нужно установить расширения;

• в одно или несколько приложений (областей данных, в которые мы хотим доставить изменения расширений);

• во все приложения набора областей, которые принадлежат одной информационной базе.

 

 

Причем в задаче установке расширений есть некоторые нюансы, которые отличают ее от задачи обновления конфигурации:

• Сам пакет изменений в случае с расширениями доставляется через 1С:Шину.

• Перед установкой проверяются текущие настройки системы.

• Происходит загрузка расширения в информационную базу – при этом сама функциональность еще не меняется.

• Проверяется применимость – можно ли это расширение вообще применить к данной информационной базе.

• Если все хорошо, происходит обновление – расширение становится активным.

 

 

Покажу, как в 1С:Управлении ландшафтом происходит доставка расширений.

Мы можем вызвать команду «Доставка изменений» в карточке конкретной информационной базы – с вариантом «Выбрать существующий пакет» выбираем пакет, в который уже загружено нужное нам расширение.

Поскольку это расширение изменяет структуру данных, по использованию этого пакета есть некоторые нюансы – при создании задачи доставки изменений система:

• блокирует базу;

• выгоняет всех пользователей;

• устанавливает расширение;

• и потом возвращает базу обратно в рабочее состояние.

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

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

В «Истории доставки» можно увидеть результат – что в выбранных базах расширение у нас успешно обновилось.

 

Архитектура управления ландшафтом

 

Теперь о том, как 1С:Управление ландшафтом устроена внутри.

Напомню, что наш первый ключевой принцип – это единое окно, единая точка контроля и ответственности. А это значит:

• больше не нужно помнить кучу логинов и паролей;

• больше нет нужды вспоминать, где какая база находится;

• больше не нужно входить в каждую базу для назначения прав.

Мы сделали 1С:Управление ландшафтом, чтобы мы могли освободить голову для действительно важной и полезной информации, не тратить ресурсы за запоминание логинов и паролей.

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

• Они управляют десятками и сотнями узлов из единой точки.

• Отказ одного агента не приведет к простою всей системы.

• Вы получаете быструю возможность развертывания. Чтобы развернуть новый узел инфраструктуры, достаточно просто зайти на него и поставить агента, а потом подключить его к панели управления. Это происходит в считанные минуты.

• Исполнитель скриптов, который мы используем – 1С:Элемент Скрипт – позволяет обеспечивать гибкость и адаптивность для управления всей этой историей.

Под капотом 1С:Управление ландшафтом также лежит 1С:Шина – она используется для мгновенной синхронизации между узлами системы, позволяя:

• управлять пользователями;

• управлять группами доступа;

• управлять профилями групп доступа;

• выдавать доступ на информационные базы и приложения;

• доставлять расширения.

 

 

Внутри все это работает приблизительно так:

• Есть панель управления на 1С:Предприятие Элемент, у которой под капотом работают 1С:Шина и менеджер.

• Панель управления общается с 1С:Шиной и менеджером через REST.

• 1С:Шина взаимодействует с информационными базами через протокол AMQP.

• А агенты взаимодействуют с менеджером через REST и WebSocket.

 

Выводы

 

Когда вам нужно 1С:Управление ландшафтом?

• Если у вас корпоративная сеть – большая корпоративная система, которой хочется как-то управлять.

• Если у вас много пользователей, которыми нужно управлять.

• Если у вас сложный цикл разработки и обновления, а вам хочется на выходе получать конкретный и консистентный пакет, который можно протестировать в тестовом контуре, а потом положить в прод – в уверенности, что он точно везде доедет одинаковым.

• Если вам требуется повторяемость обновления.

• Если у вас большое количество серверов в контуре, которыми хочется управлять. Потому что обновить один сервер – несложно. А обновить 15, 20, 30 серверов уже может быть непросто.

• И если у вас множество публикаций информационных баз, которыми хочется управлять, и хочется, чтобы пользователи имели к ним единый доступ по понятному пути.

 

Начните сейчас, масштабируйтесь завтра

 

С чего стоит начать, чтобы попробовать 1С:Управление ландшафтом:

• Мы предлагаем вам быстрый старт с минимальными вложениями. Вы можете получить полную функциональность и первые результаты при обслуживании пяти узлов системы всего за 600 тысяч рублей – это меньше, чем квартальная зарплата инженера. Внедрение решения сэкономит вам время нескольких специалистов, которые могут заняться действительно важными и полезными задачами, а не постоянным повторением рутинных действий.

• При этом у вас есть возможность плавного роста – вы можете обновить свою лицензию, увеличив размер информационной системы до 10, 50 или 100 узлов.

• И есть безграничные возможности для корпоративного уровня – версия без ограничения числа обслуживаемых серверов стоит 12 миллионов рублей.

Сделайте хаос управляемым.

 

Станислав Субботин

Руководитель корпоративного отдела Инфостарт

У вас те же боли? Заинтересовало решение?

• Развёртывайте, обновляйте без простоев и управляйте доступами из одной точки. Получите индивидуальную консультацию, где мы ответим на все вопросы!

Получить консультацию эксперта

 

Вопросы и ответы

 

Практически все, что вы рассказывали – это инструменты развертывания, для которых уже есть плейбуки Ansible и инструменты на OneScript. Чем 1С:Управление ландшафтом лучше?

Чтобы использовать Ansible или другие сторонние инструменты, нужны узкоспециализированные специалисты, которые умеют настраивать скрипты, шаблоны, плейбуки и так далее. Это дорого и рискованно – если такой специалист уйдет, компания не сможет это полноценно использовать и развивать.

У 1С:Управления ландшафтом порог вхождения намного ниже, а вся настройка происходит в красивом удобном интерфейсе. Все, что требуется – это установить агентов и пользоваться. Зато простые рутинные задачи полностью автоматизированы.

Как вы получаете от баз обратную связь по результатам операций добавления пользователей, установки расширений и обновлений для конкретных конфигураций?

Что касается установки расширений и обновлений – агенты сообщают о том, в каком состоянии находится та или иная задача, и из этого мы делаем вывод – удалось нам доставить наши изменения или не удалось, успешно было все или не успешно.

А управление пользователями у нас сейчас целиком автоматизировано через функциональность БСП. И чтобы как-то поддержать конфигурации, которые БСП вообще не используют, нам потребуется придумать дополнительный API – пока других вариантов я не вижу.

Подходит ли 1С:Управление ландшафтом для многоуровневого управления? Можно ли поставить ваше решение в облаке и делегировать задачи управления на клиентов, которые арендуют облачные ресурсы, чтобы каждый из них мог управлять своей частью?

На данном этапе развития продукта такой функциональности нет. Но вообще да, мы планировали реализовать достаточно ветвистую ролевую модель – чтобы в продукте были роли:

• администратора в целом всего облака;

• администратора конкретного куска или пространства облака;

• администратора приложения;

• администратора, который отвечает за обновление;

• администратора, который отвечает за пользователей;

• специалисты службы поддержки;

• инженеров SRE, которые отвечают за эксплуатацию и доступность.

Очевидно, что у них всех должен быть разный доступ, но он должен быть грамотно продуман и спланирован.

Мы понимаем эти потребности, но пока еще их не реализовали. Не могу пока сказать, когда именно мы это реализуем, но планы такие точно есть.

Будет ли 1С:Управление ландшафтом взаимодействовать с системами мониторинга, например, с ЦКК?

С ЦКК взаимодействие точно будет. В том числе мы, скорее всего, будем поддерживать ту функциональность, что уже есть в платформе 1С:Предприятие 8, например, выгрузку показателей производительности в формате OpenMetrics для их анализа в Prometheus.

Будете ли вы реализовывать управление сбором технологического журнала или считаете это избыточным?

Это уже запланировано в ближайших версиях – скоро появится возможность управлять сбором журнала, останавливать и запускать его при необходимости. А после сбора технологического журнала мы хотим реализовать выгрузку его данных в ЦУП, чтобы анализировать там все централизованно.

Вы показали, что можно добавить пользователя в произвольное количество баз. А можно ли заблокировать пользователя в конкретной базе?

Функциональность блокировки есть уже сейчас, но она неявная. Пока мы можем просто удалить пользователя из группы – в этом случае 1С:Шина автоматически доставляет сообщение об удалении в связанные с группой базы, и пользователь в них удаляется из группы.

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

Как вы решаете проблему доставки больших обновлений, когда производительность системы упирается в трафик?

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

Есть ли для пользователей интеграция с Active Directory?

Пока нет, но мы собираемся поддержать все возможности аутентификации – на том уровне, как это есть сейчас в 1С:Предприятии.

Создавать пользователя из 1С:Управление ландшафтом в Active Directory и наоборот, автоматически добавлять его в базы при появлении в домене – пока не планируется.

Можно ли будет инфраструктуру описывать кодом декларативно?

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

1С:Управление ландшафтом сделано на технологии 1С:Элемент. Можно ли его дорабатывать самим?

В текущей реализации нельзя, но в будущем мы планируем, чтобы решение можно было кастомизировать.

Часть, написанную на 1С:Элемент, однозначно можно будет кастомизировать. Скрипты на 1С:Предприятие.Элемент Скрипт – тоже. С точки зрения лицензионной политики тоже пока никаких ограничений нет.

Подумаем, как описать в документации, чтобы было понятно, как это можно кастомизировать.

Поддерживается ли публикация информационных баз на веб-сервере IIS? Или только на Apache?

IIS пока не поддерживается. В будущем планируем.

Вы сказали, что для установки обновления нужно выбрать пакет с загруженным в него файлом и вызвать команду «Доставка изменений». А можно ли настроить обновление по расписанию – из хранилища, из Git?

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

Вы показывали, что в задаче доставки обновления поддерживается механизм реструктуризации 2.0. Если мы выберем этот механизм и нажмем «Обновить», будет ли проверено наличие на сервере Java и других зависимостей?

Задача в момент обновления в любом случае вернет вам обратную связь. Т.е. если обновить не удастся – причину вы увидите.

Но вообще при установке «1С:Управление ландшафтом» Java ставится автоматически, так что с этим проблем быть не должно.

Какую минимальную версию платформы поддерживает 1С:Управление ландшафтом, чтобы можно было этот узел подключить в ландшафт?

Мы тестировали на 8.3.24, поскольку сейчас большинство последних версий типовых конфигураций работают на 8.3.24. Вероятно, будет работать и на 8.3.22-8.3.23, но официально мы не проверяли.

Обновление без простоев будет работать только с платформы 8.5.3 – в других версиях платформы этого просто нет. А так, да – мы старались поддержать именно актуальные версии платформы.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.