Связаться по:
vkarabedyants Telegram Viber

Блог о системном администрировании серверов и сайтов

Установка, настройка программного обеспечения Linux, Windows операционных систем

Отправка контейнерами

Если говорить о стратегиях высокого уровня, то существует три основных подхода к процедуре перемещения приложений в контейнеры: действия по принципу «взял и перенес» (lift and shift), перенос с дополнением (augment) и перенос с перекодиро­ванием (rewrite).

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

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

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

Некоторые предположения

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

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

Надлежащее разбиение по уровням

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

Если число уровней избыточно, контейнер будет слишком сложным в управлении. Число уровней в приложении должно отражать степень сложности последнего — чем сложнее приложение, тем больше в нем уровней. Так. если задача контейнера Hello World состоит в том , чтобы передавать в стандартный поток вывода (stdout) текст Hello World, в этот контейнер не нужно включать настройки , управление процессами или зависимости. Соответственно здесь нам понадобится один уровень. Но если мы захотим расширить задачу приложения Hello World так, чтобы оно обращалось с приветствием к конкретному пользователю, нам нужно будет ввести второй уровень, ответ­ственный за сбор входных данных.

Стартовые сценарии

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

Повторный запуск

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

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

Возьмем файл JSON, простой удаленный вызов процедуры (Remote Procedure Call, RPC), которая сопоставляет места распо­ложения файлов настроек и стартовой информации. Упомянутый файл JSON интерпретируется модулем set_ configs.ру, который при запуске контейнера копирует файлы настроек в места их размещения. Пользователь перенастраивает установки базы данных M ariaD B, изменяя настройки на хосте и перезапуская компьютер.
Положитесь на оркестровку

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

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

Требования к приложениям

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

Архитектура

В архитектурном отношении перемещение приложений в контейнеры чем-то напоминает переход от Unix к системе Linux или обновление опе­рационной системы. Часто речь идет о таком приложении, которое экс­плуатируется уже в течение нескольких лет. А документации у подобных приложений часто не бывает вообще или она безнадежно устарела.

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

  1. Где расположены исполняемые файлы для данного приложения? Установлены ли они с помощью инсталлятора, который размешает все подобные файлы водном месте, или разбросаны по всей файловой системе? Имеется ли один исполняемый файл, который с легкостью запускается, или мы можем задей­ствовать простой файл systemd?
  2. Где размещаются данные, исполь­зуемые этим приложением? Предназначены они только для чтения или допускают возмож­ность как чтения, так и записи?
    Можно ли записывать их без риска с применением двух одновременно исполняемых процессов?
  3. Где размещаются все данные с настройками? В одном каталоге, в одном файле или в различных местах по всей файловой системе?
  4. Какого рода секретные данные обра­батывает приложение? Можно ли задавать местоположение секретов в приложении? Допустимо ли перемещение этих данных в отдельные каталоги или к ним можно обращаться с помощью того или иного ключа через сервер идентифика­ции либо сервер сертификатов?
  5. Какого рода сетевой доступ требуется для приложения? Просто HTTP? Или это сервер имен, для доступа к которому необходим протокол пользовательских дейтаграмм (User Datagram Protocol, UDP)? А может быть, мы имеем дело со сложным приложением, предусматриваю­щим двухточечное шифрование данных, передаваемых от одного контейнера к другому, с помощью одного из протоколов IPsec?
  6. Является ли программа установки сценарием оболочки, при использова­нии которого мы можем получить дополнительную информацию о схеме приложения методом реконструкции? Устанавливаются ли исполняемые файлы с помощью диспетчеров RPM или с помощью других диспетчеров пакетов?
  7. Получаете ли вы в соответствии с лицензионным соглашением об использовании приложения право на беспрепятственное размещение приложения внутри образа контей­нера? Иногда условия лицензиро­вания накладывают на пользова­теля весьма жесткие ограничения; с другой стороны, вы, возможно, приобрели лицензию на работу с сайтом.
  8. Легко ли перезапускается прило­жение? Решения Apache нередко перезапускаются без сбоев тысячи раз. однако таблицы базы данных могут в таких условиях быть повреждены. Может ли это осложнить процесс оркестровки и вос­становления?

Ответы на эти вопросы дают возможность судить о том, насколько ваше приложение приспособлено для переноса в контейнер ( табли­ца 1). Если этот процесс окажется слишком сложным , вы просто не получите достаточную отдачу от инвестиций.

Безопасность

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

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

Рассматривая рисунок 2, мы отмечаем, что каждое последующее тех­нологическое решение обеспечивает более высокий уровень изоляции. Для некоторых приложений доста­точный уровень изоляции обеспе­чивают регулярные процессы Linux. Нередко MySQL и веб-сервер выполняются на одном экземпляре опера­ционной системы Linux.

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

Возьмем для прим ера рабочие нагрузки при осуществлении высо­копроизводительных вычислений (High-Performance Computing, НРС), которые выполняются сегодня в больших кластерах, где изоляция обеспечивается только средствами регулярных процессов Linux. Это решение несовершенно, ведь работающие в большом кластере иссле­дователи могут попытаться «навести порядок» в процессах своих коллег, однако принято считать, что такой уровень риска является допустимым.

Еще один пример. Даже при исполь­зовании виртуальных машин широко распространена практика, когда обращенные во внешнюю среду службы, такие ка к серверы имен доменов (DNS), службы HTTP или виртуальных частных сетей (VPN), вы полняются во внеш ней сети, то есть совершен но не в том кластере виртуализации, в котором действуют службы, обращенные во внутреннюю среду, скажем, базы данных Oracle или экземпляры SAP. Такую схему размещения можно считать эквивалентной изоляции на уровне серверной стойки.

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

Источник: журнал «Windows IT Pro/RE»

Мы можем быстро и качественно перенести приложение в контейнер. Обращайтесь [email protected]

Оставить комментарий

Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.