Если говорить о стратегиях высокого уровня, то существует три основных подхода к процедуре перемещения приложений в контейнеры: действия по принципу «взял и перенес» (lift and shift), перенос с дополнением (augment) и перенос с перекодированием (rewrite).nnНо какой бы метод вы ни выбрали, важно отдавать себе отчет в том, что в большинстве своем компьютерные программы задумывались и создавались еще до появления современных технологий контейнеров на основе образов. Даже если вы решите воспользоваться методом «взял и перенес» — а в этом случае вам. возможно, придется запускать монолитное приложение внутри одного контейнера,— скорее всего, ваше приложение нужно будет модифицировать.nnЧтобы успешно выполнить переход к работе с контейнерами, вам придется разработать добротную стратегию миграции. в которой будут учтены потребности ваших приложений и природа контейнеров в операционной системе Linux.nnВ предлагаемой статье приводятся специфические технические рекомендации и общие соображения, касающиеся перевода программного обеспечения в контейнеры , от процедур построения образов до указаний на то, как эти средства должны выполняться в производственной среде. Процедура переноса в контейнеры того или иного приложения определяется его требованиями.n
Некоторые предположения
В коммерческом отношении использование контейнеров даст нс меньшие выгоды , чем в техническом. При построении и использовании контейнеров решающее значение имеет размещение их компонентов. Анализируя приложение, вы должны думать о каждой из его частей и о том, ка к они взаимодействуют друг с другом. Это похоже на то, как аналитики разбивают программу на наборы классов и функций.nnКонтейнеры состоят из пакетов и сценариев, которые в сочетании с другими контейнерами составляют ваше приложение. Поэтому рассматривайте контейнеры как набор, состоящий из более мелких блоков, и имейте в виду, что, формируя из этих блоков легко управляемые структуры , вы облегчаете процесс понимания контейнеризованного приложения, а также процессы его развертывания и обслуживания.n
Надлежащее разбиение по уровням
Цель разбиения по уровням заключается в том, чтобы сформировать условия для создания более сложной структуры посредством введения тонкого уровня абстракции над предшествующим уровнем. Уровни — это логические блоки, содержимое которых относится к тому же типу объектов или решает аналогичную задачу.nВыделяя в контейнере надлежащее число уровней, вы облегчаете процесс его эксплуатации.nnЕсли число уровней избыточно, контейнер будет слишком сложным в управлении. Число уровней в приложении должно отражать степень сложности последнего — чем сложнее приложение, тем больше в нем уровней. Так. если задача контейнера Hello World состоит в том , чтобы передавать в стандартный поток вывода (stdout) текст Hello World, в этот контейнер не нужно включать настройки , управление процессами или зависимости. Соответственно здесь нам понадобится один уровень. Но если мы захотим расширить задачу приложения Hello World так, чтобы оно обращалось с приветствием к конкретному пользователю, нам нужно будет ввести второй уровень, ответственный за сбор входных данных.n
Стартовые сценарии
Стартовые сценарии весьма успешно справляются с задачей формирования тонкого уровня абстракции над уровнем обслуживания, который запускается при старте контейнера.nСтартовые сценарии расширяют возможности средств базового уровня с помощью весьма простого интерфейса прикладного программирования (API), к которому подключается оператор. Чаше всего стартовые сценарии решают такие задачи, как предоставление разрешений, перемещение файлов настроек, изменение собственников файлов, очистка каталогов и запуск служб.n
Повторный запуск
Каждое действие, влияющее на жизненный цикл приложения, предусматривает повторный запуск, поскольку это недорогой и эффективный способ извещения процесса о том, что выполняется некая операция.nnЧто же касается операций, влияющих на жизненный цикл, то перезапуск в ходе их выполнения требуется для того, чтобы внести изменения в процесс. Рассмотрим такой пример. Допустим, нам требуется перенастроить работу базы данных MariaDB.nnВозьмем файл JSON, простой удаленный вызов процедуры (Remote Procedure Call, RPC), которая сопоставляет места расположения файлов настроек и стартовой информации. Упомянутый файл JSON интерпретируется модулем set_ configs.ру, который при запуске контейнера копирует файлы настроек в места их размещения. Пользователь перенастраивает установки базы данных M ariaD B, изменяя настройки на хосте и перезапуская компьютер.nПоложитесь на оркестровкуnnНе следует полагать, что каждый уровень вашего приложения должен располагаться именно в ко и те і і пере, поэтому не создавайте в нем слишком много уровней. В этом случае ваши конструкции начнут быстро «накладываться» на существующие инструменты , на другие уровни, и структура контейнера станет слишком сложной.nnМы не хотим создавать дополнительную работу за счет встраивания в контейнеры инструментов, которые только и могут, что развертывать наше приложение и управлять им. Наша цель в том , чтобы облегчить решение задачи управления хорошо укомплектованным и контейнерами, возложенной на средства оркестровки.n
Требования к приложениям
К приложениям предъявляются вполне конкретные требования в отношении соответствия определенным архитектурным критериям, критериям безопасности и производительности, как показано на рисунке 1. Некоторые из этих требований влияю т на объем усилий, необходимых для переноса приложения в контейнер или для разнесения его по нескольким контейнерам.nnn
Архитектура
В архитектурном отношении перемещение приложений в контейнеры чем-то напоминает переход от Unix к системе Linux или обновление операционной системы. Часто речь идет о таком приложении, которое эксплуатируется уже в течение нескольких лет. А документации у подобных приложений часто не бывает вообще или она безнадежно устарела.nnКак это происходит в большинстве случаев при осуществлении миграции, совершающему данную операцию сотруднику потребуется выполнить всю работу, необходимую для понимания того, как функционирует приложение в конструктивном отношении. Ему нужно будет произвести реконструкцию и разобраться с тем, как приложение было настроено.nПо меньшей мере он должен подготовиться к тому, чтобы ответить на такие вопросы:n
- n
- Где расположены исполняемые файлы для данного приложения? Установлены ли они с помощью инсталлятора, который размешает все подобные файлы водном месте, или разбросаны по всей файловой системе? Имеется ли один исполняемый файл, который с легкостью запускается, или мы можем задействовать простой файл systemd?
- Где размещаются данные, используемые этим приложением? Предназначены они только для чтения или допускают возможность как чтения, так и записи?nМожно ли записывать их без риска с применением двух одновременно исполняемых процессов?
- Где размещаются все данные с настройками? В одном каталоге, в одном файле или в различных местах по всей файловой системе?
- Какого рода секретные данные обрабатывает приложение? Можно ли задавать местоположение секретов в приложении? Допустимо ли перемещение этих данных в отдельные каталоги или к ним можно обращаться с помощью того или иного ключа через сервер идентификации либо сервер сертификатов?
- Какого рода сетевой доступ требуется для приложения? Просто HTTP? Или это сервер имен, для доступа к которому необходим протокол пользовательских дейтаграмм (User Datagram Protocol, UDP)? А может быть, мы имеем дело со сложным приложением, предусматривающим двухточечное шифрование данных, передаваемых от одного контейнера к другому, с помощью одного из протоколов IPsec?
- Является ли программа установки сценарием оболочки, при использовании которого мы можем получить дополнительную информацию о схеме приложения методом реконструкции? Устанавливаются ли исполняемые файлы с помощью диспетчеров RPM или с помощью других диспетчеров пакетов?
- Получаете ли вы в соответствии с лицензионным соглашением об использовании приложения право на беспрепятственное размещение приложения внутри образа контейнера? Иногда условия лицензирования накладывают на пользователя весьма жесткие ограничения; с другой стороны, вы, возможно, приобрели лицензию на работу с сайтом.
- Легко ли перезапускается приложение? Решения Apache нередко перезапускаются без сбоев тысячи раз. однако таблицы базы данных могут в таких условиях быть повреждены. Может ли это осложнить процесс оркестровки и восстановления?
nОтветы на эти вопросы дают возможность судить о том, насколько ваше приложение приспособлено для переноса в контейнер ( таблица 1). Если этот процесс окажется слишком сложным , вы просто не получите достаточную отдачу от инвестиций.nnn
Безопасность
Во многих отношениях затрагивающие проблемы безопасности решения, которые связаны с контейнеризованными приложениями, подобны обычным приложениям, выполняемым внутри процессов.nnОпределение того, какой уровень изоляции достаточен для данного приложения, возлагается на администратора. Оценивая рабочие нагрузки в процессе миграции и принимая решение относительно того, предоставляют ли контейнеры достаточный уровень изоляции, оператор должен точно представлять уровень изоляции рабочей нагрузки, обеспечиваемый по месту се текущего выполнения.nnnnРассматривая рисунок 2, мы отмечаем, что каждое последующее технологическое решение обеспечивает более высокий уровень изоляции. Для некоторых приложений достаточный уровень изоляции обеспечивают регулярные процессы Linux. Нередко MySQL и веб-сервер выполняются на одном экземпляре операционной системы Linux.nnНа другом конце спектра — случаи, когда две копии того или иного приложения приходится размешать в двух отдельных центрах обработки данных, функционирующих в районах с различными погодными условиями и различным уровнем сейсмоопасности, что характерно для ситуаций восстановления после аварийного сбоя.nnВозьмем для прим ера рабочие нагрузки при осуществлении высокопроизводительных вычислений (High-Performance Computing, НРС), которые выполняются сегодня в больших кластерах, где изоляция обеспечивается только средствами регулярных процессов Linux. Это решение несовершенно, ведь работающие в большом кластере исследователи могут попытаться «навести порядок» в процессах своих коллег, однако принято считать, что такой уровень риска является допустимым.nnЕще один пример. Даже при использовании виртуальных машин широко распространена практика, когда обращенные во внешнюю среду службы, такие ка к серверы имен доменов (DNS), службы HTTP или виртуальных частных сетей (VPN), вы полняются во внеш ней сети, то есть совершен но не в том кластере виртуализации, в котором действуют службы, обращенные во внутреннюю среду, скажем, базы данных Oracle или экземпляры SAP. Такую схему размещения можно считать эквивалентной изоляции на уровне серверной стойки.nnРедкий эксперт по проблемам безопасности будет чувствовать себя, что называется, в своей тарелке, если ему доведется выполнять эти два типа рабочих нагрузок в одном и том же кластере виртуализации. То же можно сказать и о контейнерных платформах; обычно эти типы служб выполняются в различных кластерах.Итак, когда вы задаете себе вопрос, обеспечивают ли контейнеры достаточный уровень изоляции, рассмотрите его в контексте требований к рабочим нагрузкам.nnИсточник: журнал «Windows IT Pro/RE»n
Мы можем быстро и качественно перенести приложение в контейнер. Обращайтесь [email protected]