Rate this post

Производительность

Рабочие нагрузки необходимо ана­лизировать и в контексте произво­дительности. Контейнеры и виртуа­лизация —технологии, дополняющие друг друга. Для получения новых функций их можно использовать в сочетании с «голым железом».nnВ таблице 2 представлено краткое руководство, иллюстрирующее важные возможности, которые следует принимать во внимание при переносе приложений в контейнеры.nКонтейнеры представляют собой процессы Linux, которые обеспечи­вают более высокий уровень изоляции приложений с помощью таких технологий, как контрольные группы (egroups), Security-Enhanced Linux (SELinux) и пространства имен.nnЭто даст им возможность выполняться на собственной или близкой скорости. При этом уровень абстракции, такой как виртуализация, отсутствует, так что все помещенные в контейнеры приложения кластера должны быть построены на одной и той же аппаратной архитектуре и операци­онной системе.nnОставаясь в рамках того же примера — в среде НРС ,— отметим, что контейнеры можно строить на «голом железе». При этом будет обеспечи­ваться прежний уровень производительности, тогда ка к уровень изоляции будет возрастать. С другой стороны, если рабочая нагрузка представляет собой корпоративное приложение и для работы последнего требуются компоненты, функ­ционирующие в средах W indows и Linux, возможно, предпочтение следует отдать сочетанию контейнеров и средств виртуализации.nnПри выполнении контейнеров внутри виртуальной машины мы получа­ем сочетание аппаратной свободы и более высокого уровня ИЗОЛЯЦИИ и управляемости,обеспечиваемогоnс использованием образов контейнеров. Таблица 2 поможет вам уяснить плюсы и минусы сочетания различных технологий.nnn

Перечень технических требований

Рекомендации по перемещению приложений в контейнеры можно свести к приведенному ниже списку требований:n

  • Разделяйте приложения на уровни.
  • Число уровней должно отражать степень сложности приложения.
  • Уровень абстракции контейнеров должен быть чуть выше, чем у пакетов установочных файлов RPM.
  • Не старайтесь решать все проблемы внутри контейнера.
  • Для обеспечения простого извлечения вереде исполнения используйте уровень стартовых сценариев.
  • Встраивайте в контейнеры четкие и лаконичные операции, которыми будут управлять инструменты, расположенные во внешней среде.
  • Идентифицируйте и разделяйте код, параметры настройки и данные.
  • Код должен функционировать на уровнях образов.
  • Настройки, данные и секретные сведения должны поступать из среды.
  • Контейнеры следует перезагру­жать.
  • Не восстанавливайте процессы.
  • Никогда не продолжайте разработку кода с последнего тега, иначе через некоторое время ваши сборки станут невоспроизводимыми.
  • Используйте проверки на суще­ствование и готовность.

Разработка архитектуры

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

    n

  1. Определите местоположение всех исполняемых файлов, необходимых для того, чтобы приложение могло выполняться в контейнере.n
      n

    1. Используйте уровни — помните о базовых сборках и уровнях среды исполнения приложений.
    2. Установите зависимости и определите, должны ли предшеству­ющие уровни содержать эти зависимости, особенно если они могут быть объектами совместного использования или применяться другими приложениями. в) Установите, какие механизмы запускают исполняемые файлы: сценарий, процесс systemd и т. д.

    n

  2. Определите файлы и каталоги, содержащие данные по настройкам для приложения. Настройка должна осуществляться из среды (разработка/тестирование/эксплуатация) и не встраиваться в образ контейнера.
  3. Определите файлы и каталоги, которые будут содержать данные для приложения. Эти данные должны быть смонтированы к приложению во время исполнения. Данные приложения должны поступать из среды разработка/тестирование/эксплуатация и не встраиваться в образ контейнера.
  4. Определите, какие сетевые протоколы потребуются для приложения. Это позволит понять, предназначены ли данные службы для работы с внутренними контраген­тами (кластером) или с внешними (заказчиком).
  5. Можно ли реконструировать программу установки, с тем чтобы точнее представить, как она работает?n
      n

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

    n

  6. Определите, легко ли перезапу­скается служба. Если она чувстви­тельна к перезапускам, с помощью проверок на существование и готовность выясните, требуется ли вмешательство со стороны оператора. Чрезвычайно важно максимально автоматизировать содержимое среды оркестровки контейнера.
  7. Определите, куда должны поступать данные регистрации и выходные данные. Как правило, журналы регистрации приложений, установленных с помощью пакетов RPM, поступают в каталог /var/log или в другие известные местопо­ложения. В контейнеризованной среде это может привести к сбросу больших объемов данных на уровень чтения-записи.
  8. Установите, есть ли потребность в масштабировании индивиду­альных процессов. При необхо­димости распределите приложение по нескольким контейнерам.

n

Обеспечение безопасности

Обращайтесь к этому перечню при создании образов контейнеризован­ных приложений. Важно учитывать следующие рекомендации:n

    n

  1. При любой возможности используйте политики. Для определения политик применяйте ограничения контекста безопасности и учетные записи служб. Специалисты Red Hat пришли к заключению , что элементы управления на базе профилей обычно функционируют лучше, а также поддерживаются более широко, чем индивидуаль­ные правила для каждого приложения.
  2. Определите файлы, содержащие секретные сведения, которые используются приложением. К ним относятся, в частности, сертификаты и пароли. Подобные объекты никогда не следует размещать в образе контейнера , поскольку доступ к ним получает любой пользователь, загрузивший такой образ. Эти данные должны быть защищены и предоставлены средой контейнера.
  3. Не запускайте контейнеры на низких портах, где требуется наличие привилегий. Пользуйтесь встроенными ограничениями контекста безопасности, которые препят­ствуют реализации этого варианта.
  4. Избегайте выполнения контей­неров в качестве корневых. Даже в случае применения пользо­вательского пространства имен в ядре существует опасность выхода за границы контейнера, что может привести к компрометации базового хоста контейнера. Чтобы не допустить подобного развития событий, используйте встроенные ограничения контекста безопас­ности.
  5. По возможности запускайте кон­тейнеры с корневой файловой системой в режиме «только чтение». С целью принудительного перехода в этот режим используйте ограничения контекста безопас­ности.n
      n

    1. При работе с веб-контентом запускайте службу установки тома тоже в режиме «только чтение».

    n

  6. Определите необходимый уровень изоляции. Руководствуйтесь принципами наименьших привилегий и глубокой обороны. Например, вереде Red Hat OpenShift Container Platform применяются следующие технологии с ограничениями контекста безопасности и учетными записями служб:n
      n

    1. S E Linux — системы Red Hat Enterprise Linux поставляются с профилями, готовыми к работе без предварительной настройки.nДинамические контекст гене­рируются для каждого контейнера с использованием технологии безопасной виртуализации (sVirt).
    2. Безопасные вычисления (secure computing, seccomp). Контейнеры запускаются без использования стандартного профиля seccomp.nПользователи должны определять и настраивать проф иль самостоятельно.
    3. Возможности Linux:n
        n

      1. стандартный контекст безопас­ности в OpenShift ограничен; возможности KILL, MKNOD, SYS _CHROOT, SETUID ,nSETGID не предусмотрены;
      2. возможно, у администраторов возникнет потребность в создании особых ограничений, исключающих следующие функции, в первую очередь для процессов, которым будут предоставляться корневые привилегии (полезно для админи­страторов): AUDIT CONTROL, BLOCK SUSPEN D, DAC_nREAD SEARCH, IPC_LOCK,nIPC. OWNER, LEASE,nLINUX IM MUTABLE, MAC-OVERRIDE, а также MAC — ADMIN ;
      3. возможно, у администраторов возникнет потребность в создании особых ограничений, предусматривающих следующие функции, в первую очередь для процессов, которым будут предоставляться корневые привилегии (полезно при выполнении административных задач): NET_ADMIN, NET -nBROADCAST, SYS_ADMIN,nSYS BOOT, SYS MODULE,nSYS_NICE, SYS. PTRACE ,nSYS-PACCT, SYS-R AWIO ,nSYS_RESOURCE, SYS_TIME,nSYS-TTY-CONFIG, SYSLOG,nа также WAКE_ALARM .

      n

    4. Ограничения контекста безопас­ности включаются в платформу Red Hat OpenShift Container и регулируются правилами, при­меняемыми по умолчанию.

    n

n

Обеспечение производительности

Обращайтесь к этому перечню при создании образов контейнеризо­ванных приложений . Важно учитывать при веденные ниже реко­мендации:n

  • Определите, обращаются ли приложения к временным файлам или создают их. По умолчанию эти файловые системы монтируются как нередактируемые. Их можно подключать как тома, но следует проявлять осторожность при предоставлении нескольким процессам права доступа с возможно­стью чтения и записи.n
    • /sys;
    • /ргос:n
      • — псевдофайловая система, пре­доставляющая доступ к структурам данных ядра;
      • по большей части нередактируемая, но некоторые файлы предусматривают возможность изменения переменных ядра;
      • записи в каталоге/proc/[pid|ns представляют пространства имен ядра, созданные для размещенного в контейнере процесса id;
      • к числу примеров относятся /proc/asound. /рrос/bus, /рrос / fs, /proc /irq, /рrос /sys и /рrос /sysrq-trigger.
    • в) /dev:n
      • внутри контейнера приложение может взаимодейство­вать с ограниченным числом файлов устройств, таких как /dev /null и / dcv /zero .nКонтейнеризованные приложения могут обращаться к файлам устройств хоста, таким как /dev/sdX и /dcv /ttySX , только если функционируют в приви­легированном режиме.
    • /ru n:n
      • после подключения программы docker v l. 10 пользователь может передавать параметр -tm pfs для выполнения этой программы; далее /run под­ключается как tm pfs внутри контейнера;
      • в системах Red Hat /run/secrets всегда подключается KaKtmpfs, с тем чтобы обеспечить место для введения сведении о подписке;
      • на главной системе Linux /run подключается как tm pfs для с охранения временных данных процесса (например, pid системного процесса). После перезагрузки сервера они будут удалены. Внутри контейнера только каталог/run /secrets подключается как tmpfs, тогда ка к каталог /run включается в файловую систем у /(root).nВ результате файлы, входящие в каталог /run, не удаляются даже в случае перезагрузки контейнера.
  • Определите, нужно ли для работы приложения вносить изменения в параметры ядра (/proc/sys) или предоставлять доступ к специальным аппаратным средствам.n
    • По умолчанию размещенные в каталоге /p ro c /s y s переменные для настройки ядра могут использоваться контейнеризо­ванным процессом в режиме только для чтения.
    • Возможно, для запуска приложений этого типа потребуется внести в настройки определенных узлов корректные параметры ядра или аппаратные средства и использовать селекторы узлов для закрепления на узлах с особой архитектурой либо ресурсами. Приведем в качестве примеров /proc/sys/fs/mqueue, /ргос/sys/ kcrncl/{msgmax, msgmnb, msgmni, sem. shmall, shmmax, shmmni, and shin rm id forced}.
    • Если необходимо изменить параметры ядра в самом приложении (например, через sysctl), его следует запускать в изолированном кластере с привилегированными контейнерами.
  • Дата, время и локальные настройки.n
    • Определите, нужно ли вводить в приложение другой набор локальных настроек (например, JST). Введите их в образ на этапе его создания — перестройте образ.
    • Определите, нужно ли в данном приложении изменить настройку даты.
  • Определите, предполагается ли присвоить приложению фикси­рованный IР-адрес.n
    • По возможности не используйте статическую IР-адресацию.
    • В интерфейсе контейнерной сети изменение ІР-адресов невозможно.
    • Где это возможно, используйте имена главных систем, поскольку заботу о средствах для работы в сети возьмет на себя служебная сеть Kubernetes.
    • Если в параметры или настройки приложения включен IР-адрес, отключите ENTRY POINT , чтобы файл настроек динамически изменялся пр и запуске.nДля выполнения этой операции используются такие инструменты , как SED или Ansible.
  • Выясните, нужно ли для работы приложения задействовать несколько сетевых интерфейсов.n
    • На сегодня технология Kubernetes не поддерживает использование сетевых интерфейсных плат (Network Interface Controllers, NICs ). Сетевые резервные функции, такие как связывание, не могут использоваться внутри контейнеров; такая возможность реализуется на уровне хостов.nКонтейнеры следует проекти­ровать так, чтобы сбои и переза­пуски осуществлялись на узлах с работающей сетью. Проведите необходимые проверки на интен­сивность и готовность.
    • Возможность использования интерфейсов многоканальных сетей может быть обеспечена с помощью инструментов сторонних производителей.

Таким образом, для успешного переноса приложения в контейнер или в несколько контейнеров необходимо разобраться в особенностях этого приложения и разработать подробный план. Такому переносу можно подвергнуть практически любое приложение, но важно иметь ясное представление о том объеме усилий, которые придется приложить для решения этой задачи. Кроме того, необходимо, чтобы миграция обеспечивала по меньшей мере сохранение прежних показателей производительности и приводила не к снижению, а желательно к повышению уровня обеспечения безопасности.nnИсточник: журнал «Windows IT Pro/RE»n

Мы можем осуществить перенос приложений в контейнеры быстро и с гарантией. Обращайтесь!

Похожие статьи:

  1. Отправка контейнерами
  2. Управление контейнерами Docker
  3. Облачный брандмауэр веб-приложений
  4. Сервер приложений (смета)