Контейнерные технологии: Что такое контейнеризация | Плюсы технологии

Содержание

Что такое контейнеризация | Плюсы технологии

Технология контейнеризации — это ещё одна форма виртуализации ОС, предлагающая изоляцию приложений в пользовательских пространствах (контейнерах). Все контейнеры используют одну и ту же операционную систему. Благодаря технологии контейнеризации можно запускать приложение с нужными библиотеками в типовом контейнере, который соединяется с хостом или другой внешней компонентой при помощи простого интерфейса.

Все компоненты, необходимые для работы приложения (код, среда запуска, системные инструменты, библиотеки и настройки), упаковываются в один образ и могут быть использованы повторно в рамках текущей задачи или для любых других. Контейнер независим от ресурсов и архитектуры хоста. Он создаёт изолированную среду для приложения, не используя CPU, RAM или хранилище хостовой ОС. Все процессы идут внутри.

Виртуальная машина и контейнер: в чём разница

Виртуальные машины (ВМ) и контейнеры отличаются друг от друга. Это два разных подхода к созданию независимых изолированных вычислительных сред на физическом сервере. В чём особенность каждого варианта?

  • Виртуальная машина. Требуется гипервизор, для каждой ВМ используется собственная гостевая ОС. Позволяет создавать неоднородные вычислительные среды на одном компьютере. Из-за собственной ОС ВМ может занимать несколько ГБ, а запуск ОС и всех приложений занимает какое-то время.
  • Контейнер. Даже несколько контейнеров используют ядро одной хостовой ОС. Позволяет создавать на одном компьютере только однородные вычислительные среды. Намного легче ВМ, размер измеряется в Мб. Способен запускаться почти мгновенно.
Под разные задачи выбираются разные способы виртуализации.


Для чего нужны контейнеры

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

Что представляет собой контейнеризация с точки зрения используемых технологий? Для создания контейнеров используются е технологии, как Linux XC, OpenVZ, Linux VServer, BSD Jails и Solaris. Первая популярная технология контейнеризации в Linux — это OpenVZ, превратившаяся позднее в более совершенный коммерческий продукт Virtuozzo.

Плюсы контейнеризации

  • Скорость создания. Контейнер можно создать быстрее, чем ВМ. При этом среда контейнеризации для некоторых задач даёт больше возможностей.
  • Экономичность. Контейнер занимает меньше места в хранилище, что уменьшает накладные расходы.
  • Высокая производительность. Отсутствие межсетевых зависимостей и конфликтов повышает производительность разработки. Каждый контейнер фактически представляет собой микросервис, который можно независимо обновлять, не задаваясь вопросом синхронизации.
  • Управление версиями. Можно мониторить версионность контейнеров, следить за различиями между ними.
  • Возможность миграции среды вычислений. Все зависимости приложений и ОС, необходимые для работы приложения, инкапсулируются. Это позволяет без труда переносить образ контейнера из одной среды в другую. Так, один образ можно запускать в среде Windows и Linux или dev/test/stage.
  • Стандартизация. Как правило, контейнеры создаются на основе открытых стандартов. Поэтому с ними можно работать в большинстве дистрибутивов Linux, Microsoft, MacOS.
  • Безопасность. Контейнеры изолированы друг от друга и базовой инфраструктуры. Изменение/обновление/удаление одного контейнера не влияет на другой.


Недостатки технологии

  • Высокая сложность
    . Рост количества контейнеров, работающих с приложением, влияет на сложность управления ими. В производственной среде для работы с множеством контейнеров стоит использовать оркестраторы. Например, Kubernetes и Mesos.
  • Разрастание. Нередко в контейнеры упаковывается гораздо больше ресурсов, чем реально требуется. Из-за этого образ разрастается, занимая больше места на диске.
  • Поддержка Native Linux. Docker и многие другие контейнерные технологии основаны на Linux-контейнерах (LXC). Из-за этого запуск контейнеров в Windows-среде не всегда удобен, а ежедневное использование сложнее, чем при работе в Linux.
  • Недостаточная зрелость. Технологии контейнеризации приложений появились на рынке сравнительно недавно. Не всегда удаётся сразу решить возникшую проблемы. Иногда требуется время на поиск решения.

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

Если вас интересуют вопросы контейнеризации или вы хотите использовать облачный инструмент оркестрации контейнеров Kubernetes, обратитесь к менеджерам Cloud4Y по телефону 8 (499) 877-12-35. Вы можете связаться с нами любым другим способом.


Контейнеры это просто. Контейнерные технологии для начинающих | by Evgeny Vladimirovich | NOP::Nuances of Programming

Photo by Rye Jessen on Unsplash

Вступление

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

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

В основе любого компьютера лежит «железо»: процессор, накопитель (hdd, ssd), память, сетевая карта и т.д.

В ОС есть часть программного кода, которая служит мостом между софтом и железом, он называется — kernel (ядро). Ядро координирует запуск процессов (программ), управляет устройствами (чтение и запись адресов на диск и в память) и многое другое.

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

Ядро является частью ОС и интерфейсом для железа. ОС «живёт» в “kernel space”, а программы пользователя в “user space”. Kernel space — управляет user space.

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

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

Hypervisor может быть реализован как ПО, так и в виде реального железа, установленного непосредственно в Host машину. В любом случае hypervisor ресурсоёмкое решение, требующее виртуализации нескольких, если не всех, “железных” устройств и ядра.

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

Расходы ресурсов не масштабируются

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

Cgroups — это аббревиатура от Linux “control groups”. Это функция ядра Linux, которая изолирует и контролирует использование ресурсов для пользовательских процессов. Её создали инженеры из Google в 2006 году.

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

Для каждого пространства имён можно распределять ресурсы, так, чтобы ограничить использование CPU, RAM и т.д., для каждого набора процессов. Например, для фонового приложения агрегации логов, вероятно, потребуется ограничить ресурсы, чтобы не перегружать сам сервер, для которого ведётся лог.

Cgroups была в конечном итоге переработана в Linux, для добавления функции namespace isolation (изоляция пространства имён). Идея изоляции пространства имён не нова. В Linux уже было много видов namespace isolation. Например, изоляция процессов, которая разделяет каждый процесс и предотвращает совместное использование памяти.

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

  • PID (Process Identifier) Namespaces: эта функция гарантирует изоляцию процессов из разных пространств имён.
  • Network Namespaces: изоляция контроллера сетевого интерфейса, iptables, таблиц маршрутизации и других сетевых инструментов более низкого уровня.
  • Mount Namespaces: монтирует файловую систему таким образом, чтобы область файловой системы была изолирована и имела доступ только к смонтированными директориями.
  • User Namespaces: изолирует пользователя в пространстве имён, чтобы избежать конфликта user ID между пространствами.

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

Linux cgroups стала основой для технологии linux containers (LXC). На самом деле LXC была первой реализацией того, что сегодня называют контейнеры. Для создания виртуальной среды, с разделением процессов и сетевого пространства, взяли за основу преимущества cgroups и изоляцию пространств имён.

Сама идея контейнеров вышла из LXC. Можно сказать, что благодаря LXC стало возможным создавать независимые и изолированные пространства пользователей. Более того, ранние версии Docker ставились поверх LXC.

Docker

Docker — это наиболее распространённая технология контейнеров, именно Docker имеют в виду, когда говорят о контейнерах вообще. Тем не менее, существуют и другие open source технологии контейнеров, например rkt от CoreOS. Крупные компании создают собственные движки, например lmctfy от Google. Docker стал стандартом в этой области. Он до сих пор строится на основе cgroups и пространстве имён, которые обеспечивает ядро Linux, а теперь и Windows.

Docker

В Docker контейнер состоит из слоёв образов, при этом бинарные файлы упакованы в один пакет. В базовом образе содержится операционная система, она может отличаться от ОС хоста.

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

Поверх базового образа лежит ещё несколько образов, каждый из них является частью контейнера. Например, следующим после базового, может быть образ, который содержит apt-get зависимости. Следующим может быть образ с бинарными файлами приложения и т.д.

Самое интересное, это объединённая файловая система Docker. Например, у вас есть два контейнера со слоями образов a, b, c и a, b, d , тогда вам нужно хранить только по одной копии каждого слоя т.е. a, b, c, d , локально и в репозитории.

Каждый образ идентифицируется хэшем, и является одним из множества возможных слоёв образов, из которых состоит контейнер. Но идентификатором самого контейнера является только верхний образ, который содержит ссылки на родительские образы. На картинке выше видно, что два образа верхнего уровня (Image 1 и Image 2), разделяют три общих нижних слоя. В Image 2 есть два дополнительных слоя конфигурации, но родительские образы те же, что и у Image 1.

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

В Docker есть ещё очень классные фичи, например копирование во время записи, тома (общие файловые системы между контейнерами), docker daemon (управление контейнерами), репозитории с контролем версий (например Github для контейнеров), и много чего ещё.

Клиент командной строки (1) указывает процессу на машине «docker daemon» (2) что нужно делать. Daemon загружает образы из регистра/репозитория (3). Эти образы кэшируются (4) на локальной машине, далее можно запускать контейнеры (5)

Помимо изоляции процессов, у контейнеров есть много преимуществ.

Контейнер — это самоизолированная единица, которая запустится на любой поддерживаемой платформе, и каждый раз это будет всё тот же контейнер. Независимо от операционной системы хоста, вы сможете запустить ту систему, которая находится в контейнере. Поэтому можете быть уверены, что контейнер, который вы создаёте на своём ноутбуке, будет работать так же на корпоративном сервере.

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

Эта парадигма подразумевает, что у каждого контейнера своя фиксированная конфигурация ресурсов (CPU, RAM, количество потоков и т.д.), поэтому достаточно масштабировать количество контейнеров, а не индивидуальные ресурсы. Это обеспечивает более простую абстракцию для масштабирования приложений.

Кроме того, контейнеры — это отличный инструмент для реализации архитектуры микросервисов. В таком случае, каждый микросервис это комплекс взаимодействующих контейнеров. Например, микросервис Redis, можно реализовать с одним мастер контейнером и несколькими slave контейнерами.

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

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

Для этого инструмента требуется:

  • Назначить контейнеры машинам согласно спецификации (планирование)
  • Загрузить нужные контейнеры в машины через Docker
  • Решить вопросы с обновлениями, откатами и возможными изменениями системы
  • Быть готовым к «падениям» контейнеров
  • Создать кластерные ресурсы (мониторинг служб, взаимодействие между виртуальными машинами, вход/выход кластера)

Эти задачи относятся к администрированию распределённой системы, построенной на основе контейнеров (временно или постоянно изменяющихся). Для решения этих задач, уже созданы действительно классные системы.

Перевод статьи Will Wang : Demystifying containers 101: a deep dive into container technology for beginners

Что такое контейнеры, преимущества контейнерных технологий

Контейнерные технологии имеют длительную историю. Еще в 1979 году для ОС Unix была разработана утилита chroot (change root), при помощи которой можно было создавать отдельную изолированную ОС внутри основной. В ней могли работать приложения, причем доступ к их файлам был возможен только внутри пространства этой ОС. Это было очень полезно, например, для тестирования вновь написанного программного кода.

На рубеже 2000-х годов была создана Unix-подобная ОС под названием FreeBSD Jails, которая также использовала принцип chroot, но подняла его на новый уровень, обеспечив изоляцию пользователей, файловых систем, сетевых интерфейсов и др.

В 2004 году компания Sun представила новую ОС Solaris, которая называлась Solaris Containers. В ней были реализованы практически те же сервисы, что и в FreeBSD Jails, то есть она обеспечивала изоляцию отдельных сегментов, называемых «зонами» (zones).

В 2008 году была разработана ОС с открытым кодом Linux Containers (LXC). Именно эта ОС заложила основы контейнерной технологии Docker, которая появилась в 2013 году. Docker – это также название компании, которая придала импульс контейнерным технологиям. Вначале эта технология базировалась на LXC, затем компания Docker заменила LXC собственной библиотекой программ под названием libcontainer.

Docker достигла значительных успехов в создании экосистемы контейнеров, добавив такие сервисы, как интерфейс программирования приложений API (application programming interface), система командной строки CLI (command line interface), эффективная модель образов данных, а также средства управления кластером, обеспечивающие простое масштабирование.

Может создаться впечатление, что контейнерные технологии работают только в среде Linux, однако это не так. Например, в ОС Windows Server 2016 и Windows 10 контейнеры Docker поддерживаются для приложений Windows.

Виртуальные машины, контейнеры и «голое железо» (Bare Metal)

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

Рассмотрим основные особенности архитектуры: традиционной (Bare Metal) и виртуализованной на базе гипервизора.

Различия традиционной и виртуализованной архитектуры

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

Может возникнуть вопрос, зачем нужен гипервизор, а также все эти сложности? Разве не проще обходиться отдельными физическими серверами? Зачем их нужно нарезать, как батон хлеба? Ответ очень прост. В любом сервере традиционной архитектуры мощность процессора используется на 5–15 %. То есть оборудование любого дата-центра без виртуализации простаивает на 85–95 %. Почему это так – вопрос отдельный, но это так. В отдельные моменты какие-то тяжелые приложения иногда могут загрузить процессор сервера процентов на 50 %, но во временнóм усреднении процессор любого физического сервера без виртуализации оказывается загружен не более, чем на 15 %.

А вот при виртуализации использование (или «утилизация», как говорят ИТ-профессионалы) оборудования сервера можно довести практически до 100 %.

Почему при виртуализованной архитектуре утилизация оборудования во много раз выше

Однако несмотря на гораздо больший процент утилизации оборудования при использовании виртуальных машин, у этой технологии есть тоже есть недостатки. Например, часто бывает нужно переместить («мигрировать») виртуальную машину (ВМ) с одного физического сервера на другой. При этом нужно вместе с ВМ перемещать и операционную систему (ОС), в которой она работает.

Каждая ВМ требует наличия отдельной ОС. Каждая ОС требует доступа к оперативной памяти RAM, системе хранения (СХД) и ресурсам процессора. Горизонтальное масштабирование такой вычислительной среды, т. е. развертывание все большего числа виртуальных машин, неизбежно приведет к тому, что все аппаратные ресурсы сервера займут экземпляры операционных систем. Более того, если посмотреть, чем занимаются сами виртуальные машины, то можно будет обнаружить, что многие из них не полностью используют назначенные им ресурсы (а многие и вообще их не используют, простаивают).

Кроме того, при перемещении виртуальных машин с сервера одного вендора на сервер другого вендора также могут возникнуть проблемы. Например, ВМ на базе vSphere невозможно переместить в среду Amazon EC2 или Hyper-V. То есть перемещаемость (portability) ограничена рамками гипервизора: в средах, где гипервизор, на котором лежит ОС виртуальной машины, работает, ВМ могут перемещаться, а в средах, где используется другой гипервизор, такая перемещаемость не гарантирована.

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

Архитектуры на базе контейнеров

Если сравнить рисунки 1 и 3, то видно, что в архитектуре появляется новый слой абстрагирования – движок контейнера (container engine). Что это дает? Во-первых, даже в традиционной архитектуре Bare Metal теперь стало можно создавать изолированные рабочие нагрузки. Ранее такое было возможно только в виртуализованных средах на базе гипервизора. При этом не создается «толпа» операционных систем, которая быстро съедает аппаратные ресурсы.

Во-вторых, даже в виртуализованной среде при использовании гипервизора можно получить преимущества. Преимущества виртуализации не ограничиваются при этом только лишь увеличением коэффициента использования аппаратных ресурсов сервера или кластера из однородных серверов. С такой архитектурой можно управлять виртуализованными нагрузками гораздо более эффективно, чем в классической архитектуре виртуализации. Это приводит к росту доступности приложений, возможностям реализации эффективных схем катастрофоустойчивости DR (Disaster Recovery) и к росту общей управляемости рабочими нагрузками.

Вывод таков: контейнеры можно запускать где угодно: хоть в традиционной архитектуре Bare Metal, хоть в виртуализованной среде дата-центра, хоть в облаке. Работать будет все везде одинаково. Управлять работой приложений на контейнерах можно легко и наглядно. Кроме того, контейнеры дают новые возможности к повышению доступности и защищенности приложений, причем без таких огромных затрат, как строительство резервных дата-центров катастрофоустойчивости, основная задача которых – дублирование нагрузки с основным дата-центром и переключение в активный режим при аварии в основном дата-центре.

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

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

Архитектура на базе Docker Engine

Рассмотрим контейнеры Docker, где в качестве движка используется Docker Engine, который состоит из следующих основных элементов:

  • Docker host: это сервер, на котором постоянно работает Docker Engine как фоновый процесс (демон), обеспечивающий работу операционной системы.
  • API (Application programming interface): интерфейс программирования приложений определяет, как приложение будет взаимодействовать с демоном ОС.
  • CLI (Command line interface): интерфейс командной строки для клиента Docker, где администратор может взаимодействовать с API, который, в свою очередь, взаимодействует с сервером.
  • Dockerfile: список команд, позволяющий сгенерировать образ Docker image.
  • Docker image: образ Docker, система файлов, обеспечивающая корректную работы приложения. Образ хранится в СХД до тех пор, пока не понадобится запустить его для точного определения рабочей нагрузки того или иного приложения. Образы могут быть многослойными, отображающими изменения в файловой системе, инициированные со стороны Dockerfile.
  • Docker Registry: регистр, который хранит образы файлов Docker. Регистр напоминает книжную полку. В нем хранятся образы, которые можно извлекать для создания контейнеров, необходимых для запуска служб или веб-приложений. Частные регистры Docker могут храниться в локальной среде или в общедоступном облаке. Публичный регистр Docker называется Docker Hub, его могут использовать любые пользователи Docker. При использовании команд «docker pull» или «docker run» требуемый образ контейнера извлекается из заданного в конфигурации регистра. При использовании команды «docker push» образ помещается обратно в регистр.
  • Docker objects: объекты Docker, образы, контейнеры, сети, тома, плагины и другие объекты.

Архитектура Docker (источник: docs.docker.com)

  • Docker Container: контейнер – это запускаемый экземпляр образа, который можно создавать, запускать, перемещать или удалять при помощи интерфейса API. Один контейнер можно подключать к нескольким сетям, присоединять к нему хранилище или даже создавать новый контейнер, исходя из текущего состояния образа.

В Docker используется архитектура «клиент-сервер». Клиент Docker коммуницирует через REST API с демоном (Docker Daemon), который выполняет работу по созданию, запуску, управлению и распространению контейнеров Docker. Клиент и демон могут работать внутри единой системы, или же быть разнесенными в разные системы. В первом случае для API используются сокеты UNIX, во втором – сетевой интерфейс.

Соотношения между регистрами, образами и контейнерами

Файловые системы Union

Файловые системы Union, или UnionFS, предназначены для создания уровневой структуры образов, что делает их небольшими по объему и быстрыми в создании контейнеров. Docker Engine использует UnionFS в качестве склада образов для создания контейнеров и может использовать разные варианты UnionFS, включая AUFS, btrfs, vfs, и DeviceMapper.

Kubernetes

Часто можно встретить упоминание контейнеров Docker в связке с Kubernetes. Может создаться впечатление, что это две разных технологии контейнеров. Однако это не так, Kubernetes – это просто одно из инструментальных средств управления контейнерами Docker.

Kubernetes по-гречески означает «рулевой», «штурман». Исходный код Kubernetes был предоставлен для общего доступа компанией Google в 2014 году.

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

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

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

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

Преимущества контейнеров

Развертывание приложений исторически прошло три основных этапа

Традиционное развертывание: запуск приложений на физических серверах. Границы ресурсов для приложений на физическом сервере было очень сложно определить и это вызвало проблемы с распределением ресурсов между приложениями. Решением этой проблемы традиционно был запуск каждого приложения на отдельном физическом сервере. Однако при таком способе использование вычислительных ресурсов было очень неоптимальным. Большие парки серверов также очень дорого обходились.

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

Развертывание при помощи контейнеров: Контейнеры похожи на виртуальные машины, однако, у они могут совместно использовать операционные системы (ОС) для приложений. Поэтому контейнеры считаются «легкими». Подобно виртуальной машине, контейнер имеет свою собственную файловую систему, процессор, память, пространство процесса и многое другое. Но в отличие от ВМ, контейнеры не связаны с базовой физической инфраструктурой и могут легко переноситься между различными вычислительными средами.

Преимущества контейнеров:

  • Простота и эффективность создания образа контейнера по сравнению с использованием образа виртуальной машины.
  • Непрерывная разработка, интеграция и развертывание обеспечивает надежную и частую сборку и развертывание образа контейнера с быстрым и простым откатом благодаря неизменности образа (принцип DevOps).
  • В контейнерах можно отслеживать не только информацию и метрики на уровне ОС, но также информацию о работоспособности приложений и другие параметры.
  • Идентичная окружающая среда при разработке, тестировании и релизе: на ноутбуке работает так же, как и в облаке.
  • Универсальность и переносимость между операционными системами: работает на Ubuntu, RHEL, CoreOS, Google Kubernetes Engine и в других средах.
  • Распределенные выделенные микросервисы: вместо монолитного стека на одной большой выделенной машине, приложения могут быть разбиты на более мелкие независимые части, которые можно динамически развертывать и управлять.
  • Высокая эффективность и компактность использования ресурсов.

Что представляет собой контейнер? | Microsoft Azure

Контейнер и виртуальная машина

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

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

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

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

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

Хотя контейнеры можно переносить, они ограничены операционной системой, для которой предназначены. Например, контейнер для Linux не может работать в Windows и наоборот.

Немного о контейнерах / Хабр

Назовите любую технологическую компанию, и практически со 100% вероятностью окажется, что она заинтересована в продвижении контейнерных технологий. Google – конечно. IBM – да. Microsoft – разумеется. Вот и VMware не смогла пройти мимо.

Принимая во внимание тот факт, что в портфолио VMware имеется полный набор программного обеспечения для виртуализированных ЦОД, то интерес компании к популярной технологии ожидаем. Раньше системы на базе vSphere работали с контейнерами как с обычными виртуальными машинами, а это затрудняло управление и вело к проблемам с безопасностью.

«Теперь контейнеры станут полноправными элементами vSphere. Можно управлять как традиционными приложениями внутри виртуальных машин, так и приложениями следующего поколения на базе контейнеров. Обе технологии будут работать бок о бок на одной платформе», – говорит Кит Колберт (Kit Colbert), директор по облачным приложениям VMware.

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

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

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

Кажется, что контейнеры укладывают на лопатки ВМ по всем статьям. И это было бы правдой, если бы сравнение на этом заканчивалось. Однако вопрос все же несколько сложнее и шире, чем простое «куда поместится больше приложений».

Первая и самая серьезная проблема, которая часто упускается из виду – это безопасность, кто бы что ни говорил. Дэниэл Уолш (Daniel Walsh), инженер по безопасности Red Hat, опубликовал статью «Пустые контейнеры». В ней рассматривается Docker, который в качестве основы использует libcontainers. Libcontainers взаимодействует с пятью пространствами: Process, Network, Mount, Hostname, Shared Memory.

При этом оказывается, что множество важных подсистем ядра Linux функционируют вне контейнера. К ним относятся различные устройства, SELinux, Cgroups и вся файловая система внутри /sys. Это значит, что при наличии у пользователя или приложения прав суперпользователя в контейнере операционная система может быть взломана.

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

Вот три совета, которые дает Уолш по этому поводу:

  • Удалите привилегии;
  • Старайтесь не запускать службы с root-правами;
  • Всегда учитывайте, что root-права могут действовать и вне контейнера.

Но безопасность не является единственной проблемой. Еще существует проблема обеспечения качества. Допустим, что веб-сервер NGINX в состоянии поддерживать X контейнеров, но достаточно ли вам этого? Включен ли туда обновленный балансировщик TCP? Развернуть приложение в контейнере довольно легко, но если ошибиться с выбором компонентов, то вы просто потратите время впустую.

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

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

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

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

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

На эту тему есть неплохое поясняющее видео:

Так как же создать эти микроконтейнеры? Лучше всего начать со scratch-образа, в котором нет абсолютно ничего. С его помощью вы можете создать самый маленький образ для своего приложения, если вам удастся скомпилировать проект в один бинарный файл без зависимостей, как это позволяет сделать Go. Например, этот образ содержит веб-приложение на Go и весит всего 5 МБ.

Однако не все пишут программы на Go, потому, вероятно, у вас будут несколько зависимостей, и scratch-образ вам не подойдет. Воспользуемся Alpine Linux. Образ Alpine весит всего 5 МБ. Поэтому для нашего простого приложения на Node Docker-файл примет следующий вид:

FROM alpine
RUN apk update && apk upgrade
RUN apk add nodejs

Теперь, чтобы добавить код к образу, нужно прописать еще пару дополнительных строк:

FROM alpine
RUN apk update && apk upgrade
RUN apk add nodejs

WORKDIR /app
ADD . /app
ENTRYPOINT [ "node", "server.js" ]

Код приложения и подробные инструкции можно найти

здесь

.

Такие образы Docker содержат только необходимые компоненты для работы приложения. Ничего лишнего. Таков мир микроконтейнеров.

Контейнерные технологии: docker, rkt, orchestration, kubernetes, GKE и AWS Container Service

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

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

Минусами этой модели являются:

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

  • Масштабирование этой системы вверх/вниз также затруднено, что требует много усилий и времени при настройке новой физической машины.

  • Могут существовать различия в технических характеристиках оборудования, версиях OS/kernel и версиях пакетов программного обеспечения физических машин, что затрудняет управление этими экземплярами приложений аппаратно-зависимым способом.

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

Виртуальные машины решают некоторые из вышеперечисленных проблем:

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

Но они создают некоторые собственные проблемы:

  • Они потребляют большое количество ресурсов при запуске всего экземпляра операционной системы.
  • Они могут запускаться/выключаться не так быстро, как мы хотим (порядка секунд).
  • Даже при аппаратной виртуализации экземпляры приложений могут значительно снизить производительность по сравнению с приложением, запущенным непосредственно на хосте. (Это может быть проблемой только для определенных видов приложений)

  • Упаковка и распространение изображений VM не так просто, как могло бы быть. (Это не столько недостаток подхода, сколько недостаток существующего инструментария для виртуализации.)

Затем, где-то вдоль линии, контрольные группы (контрольные группы) были добавлены к linux kernel. Эта функция позволяет нам изолировать процессы в группах, решать, какие другие процессы и файловую систему они могут видеть, и выполнять учет ресурсов на уровне группы.

Появились различные среды выполнения контейнеров и движки, которые делают процесс создания «container», среды внутри OS, такой как пространство имен, которое имеет ограниченную видимость, ресурсы и т. Д., Очень простым. Распространенными примерами этого являются docker, rkt, runC, LXC и т. Д.

Docker, например, включает в себя демон, который обеспечивает такие взаимодействия, как создание «image», многоразового объекта, который может быть мгновенно запущен в контейнер. Он также позволяет интуитивно управлять отдельными контейнерами.

Преимущества контейнеров:

  • Они легкие и работают с очень небольшими накладными расходами, так как у них нет собственного экземпляра kernel/OS и они работают поверх одного хоста OS.
  • Они обеспечивают некоторую степень изоляции между различными контейнерами и возможность налагать ограничения на различные ресурсы, потребляемые ими (используя механизм cgroup).
  • Инструментарий вокруг них быстро эволюционировал, позволяя легко создавать многоразовые блоки (изображения), хранилища для хранения версий изображений (реестры контейнеров) и так далее, в основном благодаря docker.
  • Рекомендуется, чтобы один контейнер запускал один процесс подачи заявки, чтобы поддерживать и распространять его независимо. Легкий вес контейнера делает это предпочтительным и приводит к более быстрому развитию за счет развязки.

Есть и некоторые минусы:

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

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

  • Создание сетей между контейнерами
  • Балансировка нагрузки
  • Управление хранилищем, подключенным к этим контейнерам
  • Обновление контейнеров, их масштабирование, распределение по узлам в многоузловом кластере и так далее.

Когда мы хотим управлять кластером контейнеров, мы используем механизм оркестровки контейнеров. Примерами этого являются Kubernetes, Мезос, Docker Рой и т. Д. Они предоставляют множество функциональных возможностей в дополнение к перечисленным выше, и цель состоит в том, чтобы уменьшить усилия, связанные с разработкой.


GKE (Google Container Engine) размещен Kubernetes на платформе Google Cloud. Он позволяет пользователю просто указать, что ему нужен кластер n-node kubernetes, и предоставляет сам кластер в качестве управляемого экземпляра. Kubernetes является открытым исходным кодом, и если бы кто-то захотел, он также мог бы настроить его на Google Compute Engine, другом поставщике cloud или на своих собственных машинах в своем собственном центре обработки данных.

ECS-это запатентованная система управления контейнерами/оркестровки, созданная и управляемая Amazon и доступная как часть пакета AWS.

Контейнерные технологии в ИТ-ландшафте компаний

Российский бизнес инвестирует в контейнерные технологии, но отстает от западных компаний на три года

CNews Analytics и «Инфосистемы Джет» провели масштабное исследование по использованию российским бизнесом контейнеризированных технологий.

По результатам опроса отечественных компаний из списка ТОП-500, 56% из них применяют контейнеры для своих приложений. В то же время российские предприятия находятся в начале пути освоения этих технологий: пока лишь у каждой десятой компании в контейнерах находится половина и более приложений.

Понятия микросервисы, контейнеры, Kubernetes и DevOps ворвались в мировой ИТ-рынок совсем недавно. Они появились в ответ на стремления компаний к ускорению Time To Market, и радикально перекроили процесс разработки и ИТ-инфраструктуру компаний. Большинство крупных западных компаний приняли эти правила игры — более 87% бизнесов уже используют контейнерные технологии. В Россию этот тренд пришел с некоторым опозданием. Однако возможность применять апробированные технологии позволяет отечественным предприятиям легче перестроиться и быстрее получить преимущества в виде гибкости и масштабируемости бизнеса.

Целью исследования CNews Analytics и «Инфосистемы Джет» было определить степень проникновения технологий контейнеризации в ИТ-ландшафт крупных российских компаний и долю предприятий, планирующих использовать эти технологии в будущем.

Также было изучено применение контейнеров в различных отраслях. Респондентами выступили ИТ-руководители высшего и среднего звена 108 российских предприятий из рейтинга РБК-500. Это компании финансовой сферы, торговли, промышленности, добывающих отраслей, энергетики, фармацевтики, машиностроения, сельского хозяйства и ТЭК.

Контейнеры в точке роста

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

Российский бизнес находится в начале перехода на микросервисные приложения. Только 45% компаний, имеющих собственную разработку, используют контейнеры в продуктах, 23% — в тестовых средах. Еще 9% планируют использовать контейнеры в будущем, 18% — не планируют, 5% — с планами не определились.

Проникновение контейнеризированных технологий в ИТ-ландшафт российского бизнеса пока незначителен. Только 5% компаний размещают в контейнерах более 80% своих приложений. В основном же микросервисное ПО не превышает 20% от общего объема софта — это характерно для 58% компаний.

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

Среди отраслей чемпионом по использованию контейнеров оказался финансовый сектор — 73% респондентов этой отрасли имеют дело с приложениями в контейнерах.

Показатели реального сектора (металлургия, машиностроение, ТЭК, сельское хозяйство) и торговли в этом разрезе оказались равны. Контейнеры активно применяют 47% представителей данных отраслей соответственно.

Топовые инструменты управления контейнерами

Самым популярным средством управления контейнерами в российских компаниях стал Kubernetes on-premise, его используют 44% организаций с собственной разработкой. Интересно, что эта платформа лидировала по использованию и среди западных респондентов три года назад, тогда как сейчас фаворитами стали вендорские реализации Kubernetes от крупнейших облачных провайдеров — Amazon, Google, IBM и Microsoft. В «Инфосистемы Джет» ожидают, что схожий путь предстоит и российскому бизнесу. Разница будет лишь в том, что после эксперимента с бесплатными продуктами отечественные компании преимущественно выберут вендорские решения on-premise.

Тренд на использование отечественными компаниями решений on-premise (Open Source или вендорских) очевиден уже сегодня. Развертывание платформ управления контейнерами на своей ИТ-инфраструктуре предпочитают 57% респондентов. Среди вендорских решений, по данным «Инфосистемы Джет», on-premise лидируют внедрения Red Hat OpenShift, которые встречается в двух случаях из трех.

Трудности при внедрении контейнеров

Самые острые проблемы, с которыми столкнулись крупные компании при внедрении контейнеров — обеспечение надежности (27%) и безопасности (25%). Сложности с сетевым взаимодействием назвали 23% респондентов, еще 12% указали на кадровый аспект — нехватку квалифицированного персонала. Это вполне объяснимо: Open Source решения, на основе которых создана большая часть платформ управления контейнерами, при вводе в промышленную эксплуатацию конфликтуют с требованиями к безопасности и отказоустойчивости крупных предприятий, а команды ИТ-эксплуатации часто не имеют нужной квалификации для поддержки подобных систем.

«Технологии контейнерной виртуализации уже глубоко проникли в ИТ-ландшафты крупного бизнеса. Особенно активно они используются в самых динамичных индустриях — банках и страховых компаниях, ритейле, телекоме, — отмечает Александр Краснов, руководитель лаборатории DevSecOps компании «Инфосистемы Джет». — Доступность Open Source делает легким вход в эксперименты с контейнеризированными приложениями. По факту же на одной чаше весов мы имеем простоту их первоначального развертывания, а на другой — множество сложностей с эксплуатацией: обеспечением надежности, безопасности, вопросами «второго дня». В ландшафтах enterprise-уровня эти проблемы становятся критичными. Кроме того, половина компаний, обладающих собственной разработкой, остается наедине с трудностями, пытаясь решить их с помощью профильных сообществ и испытывая дефицит специалистов.  Хорошая новость — эти проблемы решаемы. На примере многих наших заказчиков мы видим, что крупный бизнес получает серьезные преимущества от внедрения подобных технологий без лишних рисков безопасности и надежности».

 

Что такое контейнерная технология? | TechRadar

Контейнерная технология, также известная как просто контейнер, представляет собой метод упаковки приложения, чтобы его можно было запускать вместе со своими зависимостями, изолированным от других процессов. Основные поставщики общедоступных облачных вычислений, включая Amazon Web Services, Microsoft Azure и Google Cloud Platform, внедрили контейнерную технологию, при этом программное обеспечение контейнеров имеет такие названия, как Docker, Apache Mesos, rkt (произносится как «ракета») и Kubernetes.

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

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

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

Виртуальные машины

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

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

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

Как работают контейнеры?

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

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

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

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

Как компании управляют контейнерами?

При таком большом количестве программного обеспечения, которое работает в виде контейнеров, управление контейнерами стало требованием, и выполнить эту задачу вручную сложно или практически невозможно.Требуется специализированное программное обеспечение для управления контейнерами, и популярным решением с открытым исходным кодом является Kubernetes, у которого есть несколько дистрибутивов, включая Red Hat OpenShift. Программное обеспечение для управления контейнерами упрощает развертывание контейнеров и хорошо работает со стратегиями быстрого развертывания философии DevOps .

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

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

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

30 основных инструментов и ресурсов для контейнерных технологий

Контейнеры

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

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

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

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

Среда выполнения контейнеров

Docker был первым крупным предложением контейнеров с открытым исходным кодом и быстро стал стандартом де-факто. Теперь Kubernetes развивается как новый стандарт для кластеров и управления кластерами.

Kubernetes изначально поддерживал Docker и rkt (или «ракету») через собственный код. Но теперь, с созданием интерфейса времени выполнения контейнера (CRI), у вас есть много способов хранить виртуальные машины и в то же время общаться через этот интерфейс.

Docker

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

Docker Enterprise

Этот набор расширений не только добавляет функции Docker, но также позволяет Docker (компании) добавлять коммерческую поддержку. Если вам нужна матрица поддержки, чтобы точно знать, какие версии какого программного обеспечения поддерживаются, и номер телефона, по которому можно позвонить, если что-то пойдет не так, тогда Docker Enterprise может быть для вас.

CRI-O

CRI-O, первая реализация интерфейса времени выполнения контейнера, представляет собой невероятно легкую эталонную реализацию с открытым исходным кодом.

rktlet

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

containerd

Проект Cloud Native Computing Foundation, containerd был ранним контейнерным форматом.Совсем недавно разработчики containerd создали плагин CRI, который позволяет Kubernetes запускать containerd так же, как rktlet или CRI-O.

Контейнеры Microsoft

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

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

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

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

Kubernetes

Хотя не существует стандарта для управления кластером, диспетчер кластеров с открытым исходным кодом Kubernetes, первоначально разработанный Google, несомненно, является самым популярным.Kubernetes, поддерживаемый Amazon AWS, Google Cloud Engine (GCE) и Microsoft Azure Container service, является относительно портативным, что помогает предотвратить привязку к поставщику.

Kubernetes может работать даже в частном облаке: OpenStack. Microsoft, Amazon и Google предоставляют контейнерные сервисы, на которых работает Kubernetes, с доступными вариантами коммерческой поддержки.

Istio и Envoy

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

Envoy и Istio — это технологии сервисных ячеек с открытым исходным кодом, которые добавляют уровень для обеспечения безопасности и наблюдаемости. Они могут шифровать трафик внутри кластера, наблюдая за ним. Envoy, разработанный Lyft, был первым сервисным мешом для Kubernetes. Istio включает Envoy, располагается поверх него и добавляет несколько плагинов, информационных панелей и других функций для его расширения.

Apache Mesos

Инструмент для абстрагирования вычислительных ресурсов Apache Mesos может запускать образы Docker и rkt бок о бок в одном кластере.DC / OS — это платформа, построенная на Mesos, которая функционирует как операционная система центра обработки данных.

Docker Swarm

Docker Swarm — бесплатный продукт для управления кластером, который запускается из командной строки и поставляется в комплекте с Docker 1.12 и выше. Swarm изначально не поддерживает автомасштабирование или балансировку нагрузки, но сторонние расширения предоставляют эту функцию.

Docker Datacenter

Docker Datacenter — это больше, чем просто коммерческая альтернатива Kubernetes, он разработан как прямая замена, позволяющая разместить весь центр обработки данных в контейнерах, и включает в себя коммерческую поддержку.Инструмент имеет интеграцию с LDAP и веб-панель управления с панелью управления, реестром, мониторингом, журналированием и непрерывной интеграцией.

Конечно, Docker Datacenter включает и расширяет бесплатные продукты Docker с открытым исходным кодом: Docker и Swarm. Инструмент добавляет балансировку нагрузки и масштабирование, которых нет в Swarm. И, конечно же, он работает с Docker Enterprise.

Контейнеры для хранения

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

BlockBridge

BlockBridge, компания «эластичной платформы хранения», предлагает хранилище в виде контейнера с использованием Docker с поддержкой Kubernetes, OpenStack и программно-определяемого безопасного хранилища.

EMC / libstorage

Система EMC / libstorage предлагает библиотеку кода для предоставления бесплатного и открытого хранилища контейнеров.

Плагины Docker для хранилища

EMC, NetApp и другие создали плагины для поддержки хранилища, которые Docker Inc. делает доступными для загрузки.

Безопасность контейнера

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

Twistlock

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

Aqua Container Security

Как и Twistlock, Aqua фокусируется на возможности создавать, отслеживать и применять политики для контейнеров, а также на интеграции с непрерывной интеграцией (CI), выполняя проверки безопасности для каждой сборки.

StackRox

Компания StackRox, основанная Самиром Бхалотрой, бывшим руководителем службы безопасности в Google и старшим директором по кибербезопасности в канцелярии президента США, обеспечивает обнаружение кластеров Kubernetes.Программа исследует весь кластер, сравнивая поведение работающих контейнеров с политиками безопасности компании. StackRox позволяет документировать и автоматически оценивать эти политики в коде.

Aporeto

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

Операционные системы

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

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

Alpine Linux

Если вы создаете образ Docker и не указываете операционную систему, вы будете использовать Alpine Linux.Это означает, что его используют большое количество образцов и тестовых контейнеров Docker. Было бы неплохо узнать о сильных и слабых сторонах операционной системы, которая является простой, но небольшой, быстрой и относительно безопасной.

RancherOS

Содержащий только ядро ​​Linux и сам Docker, образ системы RancherOS умещается всего на 22 МБ дискового пространства. RancherOS исключает systemd, систему управления службами, встроенную в большинство версий Linux, вместо этого запускает сам Docker Daemon в качестве системы инициализации или начальной загрузки.

Контейнер CoreOS Linux

Контейнер CoreOS Linux, предназначенный для работы с инструментами и системами CoreOS Linux, предварительно настроен для работы с контейнерами Linux. Он также поставляется с включенными автоматическими обновлениями; операционные системы обновляются без какой-либо обработки.

Ubuntu Core

Canonical, материнская компания Ubuntu Linux, утверждает, что Ubuntu является наиболее распространенной ОС для контейнеров. В дистрибутиве Ubuntu есть Core, небольшой безопасный выпуск, разработанный для устройств и контейнеров Интернета вещей.Ядро разработано для обеспечения высокой производительности, компактности и транзакционных обновлений, что гарантирует успешный откат обновлений, которые не удалось выполнить. Конечно, использование Ubuntu Core означает, что вы можете приобрести поддержку у Canonical.

Red Hat Atomic Host

Организации, использующие Red Hat Enterprise и желающие использовать контейнеры, захотят, чтобы на их хостах работала операционная система Red Hat Atomic Host. Эти инструменты позволят вам размещать контейнеры Linux в минимальной версии Red Hat Enterprise Linux.

Microsoft Nano Server

Nano Server — это небольшая удаленно управляемая операционная система с командной строкой на основе Windows Server 2016. Разработанная для работы исключительно в качестве контейнера, Nano предоставляет встроенные возможности контейнера для Windows Server. Windows Pro 10 Enterprise — еще одна операционная система Microsoft, в которой могут размещаться контейнеры Windows.

VMware Photon

При весе 220 МБ на диске, Photon является более крупной контейнерной операционной системой, чем некоторые другие, хотя ее размер по-прежнему составляет лишь одну сотую размера последней версии Windows.Этот хост-контейнер Linux предназначен для интеграции с продуктами виртуализации VMware vSphere.

Контейнерные события и источники для поддержки

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

Cloud Native Computing Foundation

Когда такие компании, как IBM, Lyft и Google запускают технологию с открытым исходным кодом, им нужен кто-то, кто возьмет на себя управление и поддержит ее.Вот где на помощь приходит CNCF, обеспечивающий обслуживание и управление такими проектами, как Kubernetes, Envoy и containerd. CNFC также организует мероприятия.

DockerCon

Это событие стоит посетить, если ваша компания придерживается архитектуры, полностью основанной на Docker, при поддержке Docker Datacenter, Swarm и других продуктов от бизнес-партнеров Docker. DockerCon 2019, завершившийся 2 мая, включал 11 треков, от молниеносных переговоров до практических семинаров, презентаций поставщиков и тематических исследований.

KubeCon + CloudNative Con

Главное мероприятие CNCF, мероприятия KubeCon + CloudnativeCon проводятся на нескольких континентах каждый год. В 2019 году это будут Барселона, Испания и Китай.

StackOverflow

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

Сайт сообщества Docker

Курируемый сайт сообщества Docker предоставляет информацию и форумы, ориентированные на Docker.

Идите вперед и создайте контейнеры

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

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

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

Продолжайте учиться

Что такое контейнеры и зачем они вам нужны?

Docker появился на свет в 2013 году и с тех пор вызывает ажиотаж в ИТ-кругах.

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

Вот ответы на 13 наиболее распространенных вопросов, связанных с этой технологией.

Что такое контейнеры и зачем они вам нужны?

Контейнеры

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

Проблемы возникают, когда поддерживающая программная среда не идентична, говорит создатель Docker Соломон Хайкс. «Вы собираетесь протестировать с использованием Python 2.7, а затем он будет работать на Python 3 в производственной среде, и произойдет что-то странное. Или вы полагаетесь на поведение определенной версии библиотеки SSL, и будет установлена ​​другая. Вы будете запускать свои тесты в Debian, а продакшн — в Red Hat, и происходит множество странных вещей ».

И проблемы могут возникнуть не только из-за другого программного обеспечения, — добавил он.«Топология сети может быть другой, или политики безопасности и хранилище могут отличаться, но программное обеспечение должно работать на ней».

Как контейнеры решают эту проблему?

Проще говоря, контейнер состоит из всей среды выполнения: приложения, а также всех его зависимостей, библиотек и других двоичных файлов, а также файлов конфигурации, необходимых для его запуска, объединенных в один пакет. За счет контейнеризации платформы приложений и ее зависимостей различия в дистрибутивах ОС и базовой инфраструктуре абстрагируются.

В чем разница между контейнерами и виртуализацией?

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

Напротив, сервер, на котором запущены три контейнерных приложения с Docker, работает под управлением одной операционной системы, и каждый контейнер использует ядро ​​операционной системы совместно с другими контейнерами.Общие части операционной системы доступны только для чтения, в то время как каждый контейнер имеет собственное монтирование (то есть способ доступа к контейнеру) для записи. Это означает, что контейнеры намного легче и потребляют меньше ресурсов, чем виртуальные машины.

Какие еще преимущества предлагают контейнеры?

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

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

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

В чем разница между Docker и контейнерами?

Docker стал синонимом контейнерной технологии, потому что он был наиболее успешным в ее популяризации.Но контейнерная технология не нова; он был встроен в Linux в форме LXC более 10 лет, и аналогичная виртуализация на уровне операционной системы также была предложена тюрьмами FreeBSD, разделами рабочей нагрузки AIX и контейнерами Solaris.

Есть ли стандартный формат контейнера?

Еще в 2015 году компания CoreOS разработала собственную спецификацию образа контейнера приложения (ACI), которая отличалась от спецификации контейнера Docker, и в то время существовал риск того, что недавно популярное движение контейнеров будет фрагментировано с конкурирующими форматами контейнеров Linux.

Но позже в том же году была объявлена ​​инициатива под названием Open Container Project, позже переименованная в Open Container Initiative (OCI). Целью OCI, работающей под эгидой Linux Foundation, является разработка отраслевых стандартов для формата контейнера и программного обеспечения выполнения контейнеров для всех платформ. Отправной точкой стандартов OCP была технология Docker, и Docker пожертвовал проекту около 5% своей кодовой базы, чтобы запустить его.

Спонсорами проекта являются AWS, Google, IBM, HP, Microsoft, VMware, Red Hat, Oracle, Twitter и HP, а также Docker и CoreOS

.

Почему все эти компании участвуют в Инициативе открытых контейнеров?

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

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

Существуют ли какие-либо бесплатные системы управления контейнерами с открытым исходным кодом?

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

Какие коммерческие решения по управлению контейнерами существуют сегодня?

Docker Enterprise Edition, пожалуй, самое известное коммерческое решение для управления контейнерами. Он предоставляет интегрированную, протестированную и сертифицированную платформу для приложений, работающих в корпоративных операционных системах Linux или Windows и облачных провайдеров.

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

  • CoreOS Tectonic предварительно упаковывает все компоненты с открытым исходным кодом, необходимые для создания инфраструктуры в стиле Google, и добавляет дополнительные коммерческие функции, такие как консоль управления, корпоративная интеграция единого входа и Quay, реестр контейнеров для предприятий.
  • Red Hat’s Open Shift Container Platform — это локальная частная платформа в качестве сервисного продукта, построенная на основе ядра контейнеров приложений, работающих на Docker, с оркестровкой и управлением, обеспечиваемыми Kubernetes, на основе Red Hat Enterprise Linux.
  • Rancher Labs ’Rancher — это коммерческое решение с открытым исходным кодом, которое упрощает развертывание и управление контейнерами в производственной среде в любой инфраструктуре.

Насколько безопасны контейнеры?

Многие люди считают, что контейнеры менее безопасны, чем виртуальные машины, потому что, если есть уязвимость в ядре хоста контейнера, оно может обеспечить доступ к контейнерам, которые его совместно используют. То же самое и с гипервизором, но поскольку гипервизор обеспечивает гораздо меньшую функциональность, чем ядро ​​Linux (которое обычно реализует файловые системы, сети, элементы управления процессами приложений и т. Д.), Он представляет собой гораздо меньшую поверхность для атак.

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

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

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

Также было разработано более специализированное программное обеспечение для защиты контейнеров. Например, Twistlock предлагает программное обеспечение, которое профилирует ожидаемое поведение контейнера и вносит в «белые списки» процессы, сетевую активность (например, исходные и конечные IP-адреса и порты) и даже определенные методы хранения, чтобы можно было отметить любое вредоносное или неожиданное поведение.

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

Какие дистрибутивы Linux подходят для использования в качестве узла контейнера?

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

Некоторые примеры включают:

  • Container Linux (ранее CoreOS Linux) — одна из первых легких контейнерных операционных систем, построенных для контейнеров
  • RancherOS — упрощенный дистрибутив Linux, построенный из контейнеров, специально для запуска контейнеров.
  • Photon OS — минимальный контейнерный хост Linux, оптимизированный для работы на платформах VMware.
  • Project Atomic Host — облегченная контейнерная ОС Red Hat имеет версии, основанные на CentOS и Fedora, а также в Red Hat Enterprise Linux есть корпоративная версия нижестоящего уровня.
  • Ubuntu Core — самая маленькая версия Ubuntu, Ubuntu Core разработана как хост-операционная система для устройств IoT и крупномасштабных развертываний облачных контейнеров

Что делать, если вы магазин Windows?

Docker работает не только в любом дистрибутиве Linux с ядром Linux версии 3.10 (или более поздней), но и в Windows.

Это потому, что в 2016 году Microsoft представила возможность запускать контейнеры Windows в Windows Server 2016 и Windows 10.Это контейнеры Docker, разработанные для Windows, и ими можно управлять из любого клиента Docker или из Microsoft PowerShell.

(Microsoft также представила контейнеры Hyper-V, которые представляют собой контейнеры Windows, работающие на виртуальной машине Hyper-V для дополнительной изоляции.)

Контейнеры Windows

могут быть развернуты при стандартной установке Windows Server 2016, упрощенной установке Server Core или в варианте установки Nano Server, который специально разработан для запуска приложений внутри контейнеров или виртуальных машин.

Помимо Linux и Windows, Docker также работает на популярных облачных платформах, включая Amazon EC2, Google Compute Engine, Microsoft Azure и Rackspace.

Смогут ли контейнеры в конечном итоге заменить полноценную виртуализацию серверов?

Это маловероятно в обозримом будущем по ряду важных причин.

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

Во-вторых, инструменты управления, доступные для оркестровки большого количества контейнеров, еще не так универсальны, как программное обеспечение для управления виртуализированной инфраструктурой, такое как VMware vCenter или Microsoft System Center. Компании, вложившие значительные средства в этот тип программного обеспечения, вряд ли захотят отказаться от своей виртуализированной инфраструктуры без уважительной причины.

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

VMware поощряет клиентов, которые вложили средства в ее инфраструктуру управления виртуальными машинами, запускать контейнеры в дистрибутиве Linux контейнера Photon OS внутри облегченных виртуальных машин, которыми затем можно управлять из vCenter.Это стратегия VMware «контейнер в виртуальной машине».

Но VMware также представила так называемые интегрированные контейнеры vSphere (VIC). Эти контейнеры можно развернуть непосредственно на автономном хосте ESXi или развернуть на vCenter Server, как если бы они были виртуальными машинами. Это стратегия VMware «контейнер как виртуальная машина».

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

Что такое контейнерные технологии, что такое Kubernetes и зачем они вам нужны?

Что такое контейнеры?

Контейнеры

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

Для чего нужен контейнер?

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

  • Модернизация существующих приложений в облаке
  • Создание новых приложений, которые максимально используют преимущества контейнеров
  • Изоляция, развертывание, масштабирование и поддержка микросервисов и распределенных приложений
  • Повышение эффективности / результативности DevOps за счет упрощенной сборки / тестирования / развертывания
  • Предоставление разработчикам согласованной производственной среды, изолированной от других приложений и процессов
  • Упрощение и ускорение повторяющихся функций
  • Облегчение гибридных и мультиоблачных вычислительных сред, поскольку контейнеры могут работать согласованно где угодно

Что такое контейнеризация?

Контейнеризация — процесс создания контейнера — включает извлечение только приложения / службы, которые вам нужно запустить, вместе с их зависимостями и конфигурацией, и абстрагирование их от операционной системы и базовой инфраструктуры.Полученный образ контейнера затем можно запустить на любой платформе контейнера. Несколько контейнеров могут запускаться на одном хосте и совместно использовать одну и ту же ОС с другими контейнерами, каждый из которых запускает изолированные процессы в своем собственном защищенном пространстве. Поскольку контейнеры совместно используют базовую ОС, результатом является возможность запускать каждый контейнер, используя значительно меньше ресурсов, чем если бы каждый был отдельной виртуальной машиной (ВМ).

Каковы преимущества контейнеров?

  • Контейнеры легкие: Поскольку они изолированы от уровня ОС, контейнеры эффективны и потребляют меньше ресурсов по сравнению с виртуальными машинами.
  • Контейнеры переносимы: Поскольку контейнер включает в себя все зависимости и конфигурации, вы можете писать один раз и перемещаться между средами.
  • Контейнеры масштабируемы: Из-за своего небольшого размера контейнеры быстро раскручиваются, масштабируются на лету, замедляются, когда они не используются, и быстро перезапускаются, когда это необходимо.
  • Контейнеры могут быть рентабельными: За счет снижения требований к ресурсам и интеллектуального масштабирования контейнеры предлагают гибкое, быстрое и экономичное решение.
  • Контейнеры требуют меньше управления инфраструктурой: Контейнеры заставляют вас разобраться в том, что вам действительно нужно, чтобы обеспечить удобство работы, которое лучше всего подходит вашим клиентам. Это упрощает управление инфраструктурой, поскольку требуется меньше инфраструктуры.
  • Контейнеры позволяют сосредоточиться: ИТ-команды будут тратить меньше времени на гостевые операционные системы и физическое оборудование, что позволит им участвовать в критически важных для бизнеса проектах.
  • Контейнеры ускоряют разработку: Контейнеры обеспечивают стабильную, предсказуемую среду, в которой оптимизируются ЦП / память, а код абстрагируется от инфраструктуры для обеспечения переносимости.
  • Контейнеры разблокируют современную архитектуру: Используя контейнеры, разработчики могут разбивать приложения на микросервисы, которые могут ускорить разработку и при развертывании масштабироваться индивидуально.

Какие проблемы у контейнеров?

  • Контейнеры относительно новые: Kubernetes был впервые выпущен в 2014 году и быстро завоевал признание рынка. Быть «горячим специалистом» может затруднить поиск опытных технологов, которые знают, как работать в контейнерных средах.
  • Не все службы контейнеризированы: Если ваше приложение полагается на службы, которые не являются контейнерами, вам, возможно, придется вложить значительные средства, чтобы преобразовать его в контейнерное решение.
  • Контейнеры требуют изменений процессов и навыков: Контейнеры могут ускорить ваш переход к более гибкой и эффективной разработке, но это может означать серьезные изменения в ваших текущих процессах разработки, развертывания, анализа и мониторинга. Аналогичным образом, существующие команды могут нуждаться в корректировке и переподготовке.
  • Технология развивается со скоростью: Это не уникально для контейнеров, но быстро развивающийся характер контейнерной технологии означает, что вам нужны люди (или партнеры), чтобы принимать обоснованные решения, снижать риски и гарантировать, что внедрение не будет в тупике из-за корпоративной инерции.
  • Контейнеры — не волшебная палочка: Просмотрите список преимуществ, и контейнеры могут выглядеть идеально, но любой переход требует серьезного обдумывания. Вы должны понимать, с чем вам нужно работать, что сработает, а что нет — или найти кого-то, кто поможет вам в этом.

Контейнеры и виртуальные машины

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

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

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

Docker против Kubernetes

Технология

Docker позволяет создавать и запускать контейнеры — и это отраслевой стандарт для определения понятия «контейнер.Kubernetes (сокращенно k8s) позволяет управлять (или «оркестрировать») всеми вашими контейнерными рабочими нагрузками, включая выделение ресурсов, работу в сети, балансировку нагрузки, защиту и масштабирование. Docker можно запускать автономно без Kubernetes, но Kubernetes не может работать без службы контейнеров, такой как Docker.

По состоянию на 2021 год Docker будет обладать практически всей рыночной долей в области контейнеризации. На рынке существует множество конкурирующих продуктов Kubernetes, причем самоуправляемые Kubernetes установлены в 50% компаний, опрошенных StackRox.В пятерку лидеров входят самоуправляемые Kubernetes (50%), Amazon EKS (44%), Azure AKS (31%), RedHat OpenShift (22%) и Amazon ECS (20%).

Что такое оркестровка контейнеров?

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

Преимущества оркестровки контейнеров Kubernetes:

  • Обнаружение служб и балансировка нагрузки
  • Автоматически монтируемые системы хранения по вашему выбору
  • Автоматическое развертывание и откат
  • Оптимальное использование ресурсов
  • Самовосстановление Kubernetes (перезапуск отказавших контейнеров; уничтожение тех, которые не отвечают на пользовательские проверки работоспособности)
  • Хранение конфиденциальной информации и управление ею
  • Развертывание и обновление конфигураций без перестройки образов контейнеров

Каковы основные контейнерные инструменты и технологии?

Docker и Kubernetes — громкие имена в контейнерном пространстве.Docker — это контейнерная платформа с открытым исходным кодом. Kubernetes — самый популярный вариант оркестровки контейнеров, хотя существуют альтернативы, такие как Docker Swarm и VMware Tanzu. Крупные облачные провайдеры, включая AWS, Google и Microsoft Azure, также предлагают продукты «контейнеры как услуга» (CaaS).

Когда контейнеры — лучший вариант, а когда стоит подумать о чем-то другом?

Контейнеры

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

Так же, как некоторые физические машины не преобразуются в виртуальные, приложения, требующие много ресурсов, могут не подходить для контейнеризации. Чтобы превратить приложение, потребляющее ресурсы ЦП и ОЗУ, в контейнер, вам нужно разделить принципы его работы. Это потребует времени и денег на разработку с небольшой выгодой или без нее и, следовательно, не будет оправдано.

Контейнерные решения от Rackspace Technology

Специалисты Rackspace Technology обладают обширным опытом в области архитектуры и проектирования решений платформ для контейнеризации.Мы придерживаемся независимого подхода, используя платформу оркестровки контейнеров, которая предоставит вам наибольшую ценность — в Kubernetes, DockerSwarm и Rancher, а также в облачных инструментах, таких как ECS, EKS, AKS и GKE. С самого начала вашей инициативы по контейнеризации наши специалисты будут тесно сотрудничать с вами, чтобы понять архитектуру вашего приложения, а затем спроектировать и построить полное контейнерное решение, которое объединяет сеть, тома, вычислительные ресурсы и многое другое. Начните свое путешествие по контейнеризации сегодня.

CTI

CTICTI

Благодаря нашим многочисленным представительствам по всей стране, мы помогаем нашим клиентам сэкономить на транспортных расходах.

  • Комплексные услуги по ремонту помещений: Портленд, штат Орегон, Риальто, Калифорния,
  • Места хранения: область залива Сан-Франциско, Бойсе, штат Аризона, Феникс, Аризона, Даллас, Техас и Миддлтон, Пенсильвания,
  • .
  • Сверхчистый объект: Санта-Барбра, Калифорния

Intermediate Bulk Containers, Inc.dba Container Technology, IBC Recon Services и Tanks for Wine, Inc. была основана в 1990 году. Мы успешно занимаемся распространением и переработкой упаковки для жидкостей. Мы достигаем наших финансовых целей, продолжая превосходить ожидания как внутри компании, так и за ее пределами. Мы превосходим ожидания наших опытных сотрудников, давая им возможность развивать свою карьеру, вносить изменения в свое сообщество и принимать наилучшие долгосрочные бизнес-решения, ориентированные на получение прибыли. Мы считаем себя и друг друга ответственными за наши результаты.Благодаря уважению, профессионализму и прозрачности мы поддерживаем и вдохновляем друг друга. Внешне мы обеспечиваем исключительное обслуживание клиентов на основе взаимоотношений с добавленной стоимостью, высококачественные продукты и стремимся неуклонно защищать наши океаны и природные ресурсы.

Промышленное и коммерческое

Container Technology, Inc. поставляет бочки, контейнеры для наливных жидкостей от одного галлона до 330 галлонов и системы дозирования для промышленного и коммерческого применения.

Контейнеры средней грузоподъемности для массовых грузов (IBC), сумки и цистерны — это самое безопасное и простое решение для хранения жидкостей, химикатов, фармацевтических препаратов и пищевых продуктов

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

IBC из нержавеющей стали

обладают функциями, которые соответствуют современным отраслевым стандартам или превосходят их, а также предоставляют настраиваемые параметры для удовлетворения ваших конкретных потребностей.

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

У нас есть запасные части высокого качества для портативных контейнеров IBC Totes и All Poly IBC Totes. Мы предлагаем широкий ассортимент клапанов, крышек, адаптеров, инструментов и принадлежностей для IBC.

CTI предлагает новые или бывшие в употреблении стальные бочки емкостью 30 и 55 галлонов.Полиэтиленовые бочки в вариантах с плотной или открытой головкой на 15-55 галлонов. CTI также предлагает барабаны N55 для пищевых продуктов

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

Container Technology предоставляет услуги по переработке и мойке на двух наших предприятиях по очистке на Западном побережье, расположенных в Портленде, штат Орегон, и Риверсайде, штат Калифорния.

Запросить ценовое предложение

Специалисты по контейнерным технологиям всегда готовы помочь. Один из членов нашей команды ответит на ваш запрос в ближайшее время.

Мы покупаем у Шона из Container Technology, потому что там цены конкурентоспособны, они предоставляют мне отличную услугу по доставке моих сумок. Если у меня мало продукта, у них есть все, что мне нужно, пока не появится моя запланированная загрузка.Хотелось бы, чтобы у меня было больше поставщиков, таких как Container Technology.

Рон М.

Мы закупаем восстановленные сумки у Container Technology с 2004 года. За это время Шон и команда Container Technology зарекомендовали себя как надежный и надежный поставщик. Они продолжают поставлять сумки неизменно высокого качества и всегда учитывают наши особые запросы.

Эйми Г.

С Филом и Контейнерными технологиями было здорово работать последние 2 года. Фил обеспечивает отличное обслуживание клиентов с быстрым откликом и своевременным удовлетворением наших требований. Предлагаемые им продукты и услуги соответствуют нашим ожиданиям, а зачастую и превосходят их. Мы планируем и дальше использовать его и надеемся развивать с ним свой бизнес.

Крис G

Надежный поставщик Sierra Chemical Co с 2007 года.Надежный, отзывчивый и конкурентоспособный с упором на качество. Очень рекомендую их продукты и услуги любой компании ».

Рон Э

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

Обзор технологий изолированных контейнеров

Этот пост также доступен на: 日本語 (японский)

Краткое содержание

Хотя большая часть ИТ-индустрии находится в процессе внедрения инфраструктуры на основе контейнеров (облачное решение), совершенно необходимо понимать ограничения этой технологии.Традиционные контейнеры, такие как Docker, Linux Containers (LXC) и Rocket (rkt), на самом деле не изолированы, поскольку они совместно используют ядро ​​ОС хоста. Они ресурсоэффективны, но поверхность атаки и потенциальное воздействие взлома по-прежнему велики, особенно в многопользовательской облачной среде, в которой размещаются контейнеры, принадлежащие разным клиентам. Корень проблемы — слабое разделение контейнеров, когда ОС хоста создает виртуализированное пространство пользователя для каждого контейнера. Были проведены исследования и разработки, направленные на создание действительно изолированных контейнеров.Большинство решений реконструируют границу между контейнерами, чтобы усилить изоляцию. В этом блоге рассматриваются четыре уникальных проекта от IBM, Google, Amazon и OpenStack соответственно, в которых используются разные методы для достижения одной и той же цели, создавая более надежную изоляцию для контейнеров . IBM Nabla создает контейнеры поверх Unikernels, Google gVisor создает специализированное гостевое ядро ​​для запуска контейнеров, Amazon Firecracker — чрезвычайно легкий гипервизор для приложений песочницы, а OpenStack помещает контейнеры в специализированную виртуальную машину, оптимизированную для платформ оркестровки контейнеров.Следующий обзор этого современного исследования должен помочь читателям подготовиться к предстоящим преобразованиям.

Обзор современной контейнерной технологии

Контейнеры — это современный способ упаковки, совместного использования и развертывания приложения. В отличие от монолитного приложения, в котором все функциональные возможности упакованы в единое программное обеспечение, контейнерные приложения или микросервисы предназначены для одноцелевого использования и специализируются только на одной задаче. Контейнер включает в себя все зависимости (например,g., пакеты, библиотеки и двоичные файлы), которые необходимы приложению для выполнения своей задачи. В результате контейнерные приложения не зависят от платформы и могут работать непосредственно в любой операционной системе, независимо от ее версии или установленных пакетов. Это удобство избавляет разработчиков от огромных усилий по адаптации различных версий программного обеспечения для разных платформ или клиентов. Хотя концептуально это не совсем верно, многим людям нравится думать о контейнерах как о «легких виртуальных машинах». Когда контейнер развертывается на хосте, ресурсы каждого контейнера, такие как его файловая система, процесс и сетевой стек, помещаются в виртуально изолированную среду, к которой другие контейнеры не могут получить доступ.Эта архитектура позволяет сотням или тысячам контейнеров работать одновременно в одном кластере, и каждое приложение (или микросервис) можно легко масштабировать путем репликации большего количества экземпляров контейнера.

Под капотом развитие контейнера строится на основе двух ключевых строительных блоков, пространства имен Linux и группы управления Linux (cgroup). Пространство имен создает виртуально изолированное пользовательское пространство и предоставляет приложению выделенные системные ресурсы, такие как файловая система, сетевой стек, идентификатор процесса и идентификатор пользователя.В этом изолированном пространстве пользователя приложение управляет корневым каталогом файловой системы, начиная с PID = 1, и может работать от имени пользователя root. Это абстрактное пользовательское пространство позволяет каждому приложению работать независимо, не мешая другим приложениям на том же хосте. В настоящее время доступно шесть пространств имен: монтирование, межпроцессное взаимодействие (ipc), система разделения времени UNIX (uts), идентификатор процесса (pid), сеть и пользователь. Предлагаются два дополнительных пространства имен, time и syslog, но сообщество Linux все еще определяет спецификации.Cgroup обеспечивает ограничение аппаратных ресурсов, приоритизацию, учет и управление приложением. Примером аппаратных ресурсов, которыми может управлять cgroup, являются ЦП, память, устройство и сеть. Объединяя пространство имен и контрольную группу, мы можем безопасно запускать несколько приложений на одном хосте, при этом каждое приложение находится в своей изолированной среде. Это фундаментальное свойство контейнера.

Основное различие между виртуальной машиной (ВМ) и контейнером состоит в том, что виртуальная машина представляет собой виртуализацию на уровне оборудования, а контейнер — это виртуализация на уровне ОС.Гипервизор виртуальных машин эмулирует аппаратную среду для каждой виртуальной машины, а среда выполнения контейнера эмулирует операционную систему для каждого контейнера. Виртуальные машины совместно используют физическое оборудование хоста, а контейнеры совместно используют как оборудование, так и ядро ​​ОС хоста. Поскольку контейнеры совместно используют больше ресурсов с хоста, их использование хранилища, памяти и циклов ЦП намного эффективнее, чем виртуальная машина. Однако обратная сторона большего совместного использования — более слабая граница доверия между контейнерами и хостом. На рисунке 1 показано архитектурное различие между контейнером и виртуальной машиной.

Рисунок 1. В виртуализации машин гипервизор или монитор виртуальных машин (VMM) обеспечивает изоляцию между каждой гостевой ОС. В контейнерах операционная система хоста обеспечивает изоляцию между каждым контейнером.

* В операционной системе должен работать только VMM типа II. VMM типа I работает на физическом оборудовании.

В общем, изоляция виртуализированного оборудования создает гораздо более строгие границы безопасности, чем изоляция пространства имен. Риск выхода злоумышленника из контейнера (процесса) намного выше, чем вероятность выхода из виртуальной машины.Причина более высокого риска ухода от контейнера кроется в слабой изоляции, которую создают пространство имен и контрольная группа. Linux реализует пространство имен и контрольную группу, связывая новые поля свойств с каждым процессом. Эти поля в файловой системе / proc сообщают ОС хоста, видит ли один процесс другой или какой бюджет процессора / памяти может использовать этот процесс. При просмотре запущенных процессов и потоков из ОС хоста (например, команд top или ps) процесс контейнера выглядит так же, как любой другой процесс на хосте.В общем, традиционные контейнеры, такие как LXC или Docker, не считаются по-настоящему изолированными, поскольку контейнеры на одном хосте используют одно и то же ядро. Поэтому нет ничего удивительного в том, что обнаруживаются уязвимости, связанные с выходом из контейнера. Например, CVE-2014-3519, CVE-2016-5195, CVE-2016-9962, CVE-2017-5123 и CVE-2019-5736 могут привести к отказу контейнера. Большинство эксплойтов ядра должны работать для экранирования контейнеров, поскольку эксплойты ядра обычно приводят к эскалации привилегий и позволяют скомпрометированному процессу получить контроль за пределами предполагаемых пространств имен.Помимо векторов атак из-за уязвимостей программного обеспечения, неправильная конфигурация, такая как развертывание контейнера с чрезмерными привилегиями (например, возможность CAP_SYS_ADMIN, привилегированное разрешение) или критических точек монтирования (например, /var/run/docker.sock), может все привести к выходу из контейнера. Учитывая эти потенциальные катастрофические последствия, следует понимать риск при развертывании контейнеров в многопользовательском кластере или при размещении контейнеров с конфиденциальными данными вместе с другими ненадежными контейнерами.

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

Мы начинаем с представления Unikernel, самой ранней специализированной машины, которая упаковывает приложение с минимальным набором библиотек ОС в единый образ. Концепция unikernel является фундаментальной для многих будущих проектов, направленных на создание безопасных, компактных и оптимизированных образов машин. Затем мы рассмотрим IBM Nabla, проект, направленный на запуск одноядерных приложений, таких как контейнеры, и Google gVisor, проект, который запускает контейнеры в ядре пользовательского пространства. После этих двух unikernel-подобных проектов мы переходим к контейнерным решениям на основе виртуальных машин, Amazon Firecracker и OpenStack Kata.Последний раздел завершает блог сравнением всех упомянутых проектов.

Unikernel

Развитие технологий виртуализации позволило перейти к облачным вычислениям. Гипервизоры, такие как Xen и KVM, являются фундаментальными строительными блоками, на которых работают Amazon Web Service (AWS) и Google Computing Platform (GCP). Хотя современные гипервизоры способны обрабатывать сотни виртуальных машин в кластере, виртуальные машины, созданные на основе традиционных операционных систем общего назначения, обычно не оптимизированы для работы в среде виртуализации.ОС общего назначения предназначена для поддержки как можно большего числа типов приложений, поэтому ее ядро ​​включает в себя все виды драйверов, библиотек протоколов и планировщиков. Однако большинство отдельных виртуальных машин, развернутых сегодня в облаке, предназначены для одного приложения, такого как DNS, прокси или база данных. Поскольку каждое приложение полагается только на небольшое подмножество функций ядра, остальные неиспользуемые функции ядра тратят ресурсы системы и увеличивают поверхность атаки. Чем больше кодовая база, тем больше уязвимостей и ошибок необходимо устранить.Эти проблемы побуждают компьютерных ученых разрабатывать специализированные ОС с минимальными функциональными возможностями ядра для поддержки всего одного приложения.

Исследователи операционных систем впервые предложили идею «Unikernel» в 1990-х годах. Unikernel — это специализированный образ машины с одним адресным пространством, который может работать непосредственно на гипервизорах. Он упаковывает приложение и зависимые от приложения функции ядра в образ. Nemesis и Exokernel — два самых ранних академических проекта unikernel.На рисунке 2 показано, как создается и развертывается образ машины unikernel.

Рисунок 2. Многоцелевые ОС созданы для поддержки всех типов приложений, поэтому многие библиотеки и драйверы предварительно загружены. Unikernels — это специализированные специализированные ОС, предназначенные для поддержки одного приложения.

Unikernels разбивает ядро ​​на несколько библиотек и помещает только библиотеки, зависящие от приложения, в один образ машины. Как и виртуальные машины, юникернели развертываются и запускаются на мониторах виртуальных машин.Из-за своего небольшого размера уникальные ядра могут быстро загружаться и масштабироваться. Наиболее важные свойства Unikernels — это улучшенная безопасность, компактность, высокая оптимизация и быстрая загрузка. Поскольку образы unikernel содержат только библиотеки, зависящие от приложения, а оболочка недоступна, если она специально не включена, она имеет минимальную поверхность атаки, которую могут использовать злоумышленники. Злоумышленникам сложно не только закрепиться в юникернелах, но и влияние компрометации ограничивается одним экземпляром юникерна.Поскольку размер образов unikernel составляет всего несколько мегабайт, unikernel может загружаться за десятки миллисекунд, а сотни экземпляров могут быть запущены на одном хосте. Используя выделение памяти с одним адресным пространством вместо многоуровневой таблицы страниц в большинстве современных ОС, одноядерные приложения имеют меньшую задержку доступа к памяти, чем то же приложение, работающее на виртуальной машине. Поскольку приложения компилируются с ядром при построении образа, компиляторы могут выполнять дополнительную проверку статического типа для оптимизации двоичных файлов.

Unikernel.org ведет список проектов unikernel. Однако со всеми этими выдающимися качествами уникальные ядра не получили особого успеха. Когда Docker приобрел стартап Unikernel, Unikernel Systems, в 2016 году люди думали, что Docker будет упаковывать контейнеры в unikernel. Спустя 3 года никаких признаков интеграции по-прежнему нет. Одна из основных причин такого медленного внедрения заключается в том, что до сих пор нет зрелого инструмента для создания приложений unikernel, и большинство приложений unikernel могут работать только на определенных гипервизорах.Кроме того, для переноса приложения на unikernel может потребоваться перекодирование с использованием других языков и ручное включение зависимых библиотек ядра. Мониторинг или отладка в unikernels либо невозможны, либо приводят к значительному снижению производительности. Все эти ограничения удерживают разработчиков от перехода на уникальные ядра. Следует отметить, что у юникернелей и контейнеров много схожих свойств. И unikernels, и контейнеры являются одноцелевыми изображениями, которые неизменяемы, что означает, что компоненты в изображениях не могут быть обновлены или исправлены, а новый образ всегда создается для обновленного приложения.Unikernels сегодня похожи на эпоху до Docker, когда не было доступной среды выполнения контейнеров, и разработчикам нужно было использовать базовые строительные блоки для изолирования приложения: chroot, unshare и cgroup.

IBM Набла

Исследователи из IBM предложили идею «Unikernel как процесса»: это одноядерное приложение, запускаемое как процесс на специализированном мониторе виртуальной машины. Проект IBM «Контейнеры Nabla» еще больше укрепляет границу доверия unikernel, заменяя монитор общего назначения (e.g., QEMU) с их специфичным для юникерна монитором Nabla Tender. Обоснование этого состоит в том, что гипервызовы между уникальными ядрами и универсальным монитором виртуальных машин (VMM) по-прежнему создают большую поверхность для атак, поэтому использование специального монитора для отдельных ядер с меньшим количеством разрешенных системных вызовов может значительно повысить безопасность. Nabla Tender перехватывает гипервызовы, которые уникальные ядра отправляют в VMM, и переводит их в системные вызовы. Политика seccomp Linux блокирует все другие системные вызовы, в которых Tender не нуждается.Затем unikernel вместе с Nabla Tender запускается как процесс пользовательского пространства на хосте. На рисунке 3 показано, как Nabla создает тонкий интерфейс между приложениями unikernel и хостом.

Рис. 3. Для взаимодействия Nabla с существующими платформами выполнения контейнеров, Nabla реализует OCI-совместимую среду выполнения runnc , которую можно подключить к таким платформам, как Docker и Kubernetes. Источник изображения: Unikernels as Process

Исследователи утверждают, что Nabla Tender использует менее семи системных вызовов для взаимодействия с хостом.Поскольку системные вызовы служат мостом между процессами пользовательского пространства и ядром ОС, чем меньше доступных системных вызовов, тем меньше поверхность атаки, доступная для ядра. Еще одно преимущество запуска unikernel как процесса заключается в том, что приложения unikernel можно отлаживать с помощью большинства инструментов, основанных на процессах, таких как gdb.

Для использования платформ оркестровки контейнеров Nabla также предоставляет среду выполнения Nabla runnc , которая реализует стандарт Open Container Initiative (OCI).Стандарт OCI определяет API между клиентами среды выполнения (например, Docker, Kubectl) и средой выполнения (например, runc). Nabla также предоставляет конструктор изображений для создания образа unikernel, который может запускать runnc. Из-за разницы в файловой системе между unikernels и традиционными контейнерами образы Nabla не соответствуют спецификации образа OCI, и, следовательно, образы Docker несовместимы с runnc. На момент написания проект все еще находится на ранней экспериментальной стадии. Существуют и другие ограничения, такие как отсутствие поддержки монтирования / доступа к файловым системам хоста, добавление нескольких сетевых интерфейсов (необходимых для Kubernetes) или использование образов из других образов unikernel (например,g., MirageOS и включите ОС).

Google gVisor

Google gVisor — это технология «песочницы», на которой работают движок приложений Google Computing Platform (GPC), облачные функции и CloudML. Google осознал риск запуска ненадежных приложений в инфраструктуре общедоступного облака и неэффективность изолирования приложений в песочнице с использованием виртуальных машин и разработал ядро ​​пользовательского пространства для изолирования ненадежных приложений. gVisor помещает приложения в песочницу, перехватывая все системные вызовы от приложений к ядру хоста и обрабатывая их с помощью реализации ядра gVisor Sentry в пространстве пользователя.По сути, он функционирует как комбинация гостевого ядра и VMM. На рисунке 4 показана архитектура gVisor.

Рисунок 4. Реализация ядра gVisor Sentry и реализация файловой системы gVisor Gofer используют небольшое подмножество системных вызовов для взаимодействия с хостом. Источник изображения: Руководство по архитектуре gVisor , Обзор gVisor и платформа

gVisor создает надежную границу безопасности между приложением и его хостом.Эта граница ограничивает системные вызовы, которые могут использовать приложения в пользовательском пространстве. Не полагаясь на виртуализированное оборудование, gVisor работает как хост-процесс, который взаимодействует между изолированным приложением и хостом. Sentry реализует большинство системных вызовов Linux и основные функции ядра, такие как доставка сигналов, управление памятью, сетевой стек и потоковая модель. Sentry реализовал более 70% из 319 системных вызовов Linux для поддержки изолированных приложений. Чтобы Sentry мог взаимодействовать с ядром хоста, он использует менее 20 системных вызовов Linux.Стоит отметить, что у gVisor и Nabla очень похожая стратегия: защита ОС хоста. Оба они используют менее 10% системных вызовов Linux для взаимодействия с ядром хоста. Хотя gVisor создает многоцелевое ядро, а Nabla полагается на юникерны, они оба запускают специализированное гостевое ядро ​​в пользовательском пространстве для поддержки изолированных приложений.

Может возникнуть вопрос, почему gVisor необходимо повторно реализовать другое ядро ​​Linux, в то время как ядро ​​Linux с открытым исходным кодом легко доступно. Ядро gVisor, написанное на Golang, более безопасно, чем ядро ​​Linux, написанное на C, из-за сильных функций безопасности типов и управления памятью в Golang.Еще одним важным преимуществом gVisor является его тесная интеграция с Docker, Kubernetes и стандартом OCI. Большинство образов Docker можно просто извлечь и запустить с помощью gVisor, изменив среду выполнения на gVisor runsc. В Kubernetes вместо изолирования каждого контейнера в изолированной программной среде gVisor можно запустить целый модуль.

Поскольку gVisor все еще находится в зачаточном состоянии, все еще существуют некоторые ограничения. Когда gVisor перехватывает и обрабатывает системный вызов изолированного приложения, всегда возникают накладные расходы, поэтому он не подходит для приложений с тяжелыми системными вызовами.(Обратите внимание, что в Nabla нет таких накладных расходов, поскольку приложения unikernel не выполняют системные вызовы. Nabla использует семь системных вызовов только для обработки вызовов hyercall.) GVisor не имеет прямого доступа к оборудованию (сквозной), поэтому приложения, требующие доступа к оборудованию, такие как графический процессор, не могут запустить в gVisor. Наконец, поскольку gVisor не реализовал все системные вызовы Linux, приложения, использующие нереализованные системные вызовы, не могут работать в gVisor.

Amazon Firecracker

Amazon Firecracker — это технология, на которой сегодня работают AWS Lambda и AWS Fargate.Это VMM, которая создает легкие виртуальные машины (MicroVM) специально для многопользовательских контейнеров и бессерверных операционных моделей. До появления Firecracker функции Lambda и контейнеры Fargate работали внутри выделенных виртуальных машин EC2 для каждого клиента, чтобы обеспечить надежную изоляцию. Хотя виртуальные машины создают надежную изоляцию для контейнеров в общедоступном облаке, использование универсальных виртуальных машин и виртуальных машин для приложений песочницы не очень эффективно с точки зрения ресурсов. Firecracker решает проблемы безопасности и производительности, создавая VMM специально для облачных приложений.Firecracker VMM обеспечивает каждую гостевую виртуальную машину минимальными функциями ОС и эмулируемыми устройствами для повышения безопасности и производительности. Пользователи могут легко создавать образы виртуальных машин, которые запускаются в Firecracker, с помощью двоичного файла ядра Linux и образа файловой системы ext4. Amazon начала разработку Firecracker в 2017 году и сделала его открытым в 2018 году.

Подобно концепции unikernel, только небольшое подмножество устройств и функций предоставляется для поддержки операций с контейнерами. По сравнению с традиционными виртуальными машинами, microVM имеют гораздо меньшую поверхность атаки, объем памяти и время загрузки.Оценка показывает, что microVM Firecracker потребляет ~ 5 МБ памяти и загружается за ~ 125 мс при работе на хосте с 2 ЦП и 256 ГБ ОЗУ. На рисунке 5 показана архитектура Firecracker и границы ее безопасности.

Рисунок 5. Firecracker VMM принудительно устанавливает уровни безопасности, чтобы изолировать приложения каждого пользователя. Источник изображения: Дизайн фейерверка

Firecracker VMM полагается на KVM, и каждый экземпляр Firecracker запускается как процесс пользовательского пространства. Каждый процесс Firecracker заблокирован политиками seccomp, cgroup и namespace, поэтому системные вызовы, аппаратные ресурсы, файловая система и сетевая активность строго ограничены.Внутри каждого процесса Firecracker есть несколько потоков. Поток API обеспечивает плоскость управления между клиентами на хосте и microVM. Поток VMM предоставляет минимальный набор устройств virtIO (сетевых и блочных). Firecracker предоставил только четыре эмулируемых устройства для каждой microVM: virtio-block, virtio-net, последовательную консоль и контроллер клавиатуры с одной кнопкой, используемый только для остановки microVM. В целях безопасности виртуальные машины не имеют механизма для обмена файлами с хостом. Данные на хосте, такие как образы контейнеров, доступны микровиртуальным виртуальным машинам через файловые блочные устройства.Сетевые интерфейсы для виртуальных машин поддерживаются устройствами ответвления через сетевой мост. Все исходящие пакеты копируются на устройство ответвления и ограничиваются политикой контрольной группы. Уровни границ безопасности сводят к минимуму вероятность того, что приложения одного пользователя нарушат работу другого.

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

OpenStack Ката

Увидев проблемы безопасности традиционных контейнеров, Intel в 2015 году запустила свою контейнерную технологию Clear Containers на основе виртуальных машин. Для реализации очистки контейнеров используются аппаратная технология виртуализации Intel® VT и настраиваемый гипервизор QEMU-KVM qemu-lite. высокопроизводительный контейнер на основе виртуальной машины.В конце 2017 года проект очистки контейнеров объединился с Hyper RunV, средой выполнения на основе гипервизора для OCI, чтобы инициировать проект контейнеров Kata. Унаследовав все свойства чистых контейнеров, контейнеры Kata теперь поддерживают более широкий спектр инфраструктур и спецификаций контейнеров.

Контейнер

Kata полностью интегрирован с OCI, Container Runtime Interface (CRI) и Container Networking Interface (CNI). Он поддерживает различные типы сетевых моделей (например, сквозную передачу, MacVTap, мост, зеркальное отображение tc) и настраиваемые гостевые ядра, так что все приложения, требующие специальных сетевых моделей или версий ядра, могут работать на нем.На рисунке 6 показано, как контейнеры внутри виртуальных машин Kata взаимодействуют с существующими платформами оркестровки.

Рисунок 6. Контейнеры Kata полностью интегрированы с Docker и Kubernetes. Источник изображения: Обзор проекта Kata Containers

Kata имеет kata-runtime на хосте для запуска и настройки новых контейнеров. Для каждого контейнера в Kata VM на хосте есть соответствующая Kata Shim. Kata Shim получает запросы API от клиентов (например, от клиентов).g., docker или kubectl) и перенаправляет запросы агенту внутри виртуальной машины Kata через VSock. Контейнеры Kata дополнительно оптимизируют время загрузки виртуальной машины. NEMU — это облегченная версия QEMU, в которой удалено ~ 80% устройств и пакетов. VM-Templating создает клон запущенного экземпляра виртуальной машины Kata и делится ею с другими вновь созданными виртуальными машинами Kata. Это значительно сокращает время загрузки и потребление памяти гостевой виртуальной машины, но может быть уязвимо для атак по побочным каналам между виртуальными машинами, таких как CVE-2015-2877.Возможность горячего подключения позволяет виртуальной машине загружаться с минимальными ресурсами (например, ЦП, памятью, блоком virtio) и добавлять дополнительные ресурсы позже по запросу.

Контейнеры

Kata и Firecracker — это технология песочницы на основе виртуальных машин, предназначенная для облачных приложений. У них одна цель, но разные подходы. Firecracker — это специализированная VMM, которая создает безопасную среду виртуализации для гостевых ОС, а контейнеры Kata — это легкие виртуальные машины, оптимизированные для работы с контейнерами.Были попытки запустить контейнеры Kata на Firecracker VMM. Хотя проект все еще экспериментальный, он потенциально может объединить лучшие черты двух проектов.

Заключение

Мы рассмотрели несколько решений, которые решают проблему слабой изоляции нынешней контейнерной технологии. IBM Nabla — это решение на основе unikernel, которое упаковывает приложения в специализированную виртуальную машину. Google gVisor — это слияние специализированного гипервизора и ядра гостевой ОС, которое обеспечивает безопасный интерфейс между приложениями и их хостом.Amazon Firecracker — это специализированный гипервизор, который предоставляет каждой гостевой ОС минимальный набор оборудования и ресурсов ядра. OpenStack Kata — это высокооптимизированная виртуальная машина со встроенным контейнерным движком, которая может работать на гипервизорах. Трудно сказать, какой из них работает лучше всего, поскольку у всех у них разные плюсы и минусы. В таблице 1 показано параллельное сравнение некоторых важных функций всех четырех проектов. Nabla — ваш лучший выбор, если у вас есть приложения, работающие в unikernels, такие как MirageOS или IncludeOS.В настоящее время gVisor лучше всего интегрирован с Docker и Kubernetes, но из-за неполного покрытия системных вызовов некоторые приложения по-прежнему не могут работать на нем. Firecracker поддерживает настроенные образы гостевой ОС, поэтому это хороший выбор, если вашим приложениям необходимо запускать на настроенной виртуальной машине. Контейнеры Kata полностью соответствуют стандарту OCI и могут работать как на гипервизоре KVM, так и на Xen. Это может упростить развертывание микросервисов в среде гибридных платформ. Хотя может потребоваться некоторое время для того, чтобы одно или несколько решений в конечном итоге были приняты широким кругом пользователей, приятно видеть, что большинство поставщиков облачных услуг приняли меры по устранению проблемы.Для организаций, которые создают локальные облачные платформы, это не конец света. Распространенные практики, такие как быстрое исправление, конфигурация с минимальными привилегиями и сегментация сети, могут эффективно уменьшить поверхность атаки.

Таблица 1. Сравнение всех четырех платформ.

Получайте обновления от

Palo Alto
Networks!

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

5 Контейнерных альтернатив Docker

Хотя в 2018 году на Docker по-прежнему приходилось 83 процента контейнеров, это число ниже, чем в 2017 году — 99 процентов .Другие среды выполнения контейнеров, включая CoreOS rkt , Mesos , lxc и другие, неуклонно растут по мере того, как рынок продолжает развиваться и диверсифицироваться.

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

«Судя по данным, клиенты имеют больший уровень комфорта при использовании« не-Docker »решений в производстве» — отчет Sysdig 2018

В 2018 году 12 процентов производственных контейнеров составили rkt (произносится как «Ракета»).Rkt поддерживает два типа образов: Docker и appc . Преимуществом rkt является его основанный на подах процесс, который работает «из коробки» с Kubernetes (также называемым «rktnetes»). В Kubernetes среду выполнения контейнера rkt можно легко указать:

  $ kubelet --container-runtime = rkt  

Некоторые уникальные функции rkt включают поддержку модулей доверенной платформы (TPM). Он оптимизирован для контейнеров приложений, однако по сравнению с Docker разработчики могут найти меньше сторонних интеграций.В целом совместимость rkt делает его идеальным для переносимости и быстрого развертывания общедоступного облака.

Некоторые потенциальные недостатки включают несоответствие OCI. Rkt больше не занимается разработкой приложений и планирует использовать OCI, но пока не поддерживается. Кроме того, Rklet (CRI) все еще находится в стадии разработки. Red Hat недавно приобрела CoreOS, компанию, стоящую за rkt.

В 2018 году 4% производственных контейнеров составляли Mesos. Mesos, разработанный Apache, предлагает качественную производительность, поддерживая типы образов Docker и appc .Поддержка OCI, скорее всего, ожидается, и есть признаки того, что они будут следовать траектории внедрения Docker.

Говоря о сценариях использования Mesos, консультанте по инфраструктуре и DevOps Рикардо Аравена отмечает: «Лучше всего использовать Mesos со Spark и Flink — фреймворками для приложений с большими данными». Хотя возможны и другие варианты использования, Аравена считает, что эти контейнеры особенно подходят для таких сред.

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

Далее, в 2018 году 1% контейнеров составляли контейнеры Linux LXC. LXC, получивший прозвище «chroot на стероидах», появился еще до того, как Docker набрал обороты. Таким образом, у LXC довольно активное сообщество.

Его три основных компонента включают lxc , среду выполнения, lxd , демон, написанный на Go, который управляет контейнерами и образами, а затем lxfuse , который управляет файловой системой. В то время как LXC является более старым, хорошо известным набором инструментов низкого уровня, LXD расширяет его, предлагая новый пользовательский интерфейс и интерфейс командной строки для управления контейнерами.

Согласно Aquasec, lxd «имитирует опыт работы с виртуальными машинами, но с точки зрения контейнеров» и без серьезных накладных расходов, связанных с виртуальными машинами. Клиенты Windows или MacOS могут настроить демон lxd для доступа.

К недостаткам можно отнести отсутствие интеграции Kubernetes. Кроме того, lxc еще не соответствует требованиям OCI, однако lxcrun , скорее всего, решит эту проблему.

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

Поскольку OpenVZ сосредоточен на контейнерах для целых операционных систем, недостатком является то, что он не идеален для отдельных приложений. Пока нет интеграции CRI или Kubernetes. Говорят, что последняя версия OpenVZ 7 еще не так стабильна, как ее предшественник, OpenVZ 6.

containerd описывается как «стандартная среда выполнения контейнеров с упором на простоту, надежность и переносимость.«Инкубационный проект Cloud Native Computing Foundation, containerd доступен как демон для Linux или Windows.

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

Другие варианты исполнения контейнеров

  • Контейнеры Windows Server.
  • Linux VServer.
  • Контейнеры Hyper-V.
  • Unikernels.
  • контейнеров Java.

Оцените параметры и

Сдерживайте Ваше волнение

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

Контейнерные технологии: Что такое контейнеризация | Плюсы технологии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *