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

Контейнерные технологии имеют длительную историю. Еще в 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 и в других средах.
• Распределенные выделенные микросервисы: вместо монолитного стека на одной большой выделенной машине, приложения могут быть разбиты на более мелкие независимые части, которые можно динамически развертывать и управлять.
• Высокая эффективность и компактность использования ресурсов.

разбираемся с Docker, Kubernetes и другими инструментами

Цитируя разработчиков Docker, «контейнер — это стандартная единица программного обеспечения, в которую упаковано приложение со всеми необходимыми для его работы зависимостями — кодом приложения, средой запуска, системными инструментами, библиотеками и настройками».

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

На рынке существует немало решений, представляющих среды запуска контейнеров и оркестрации, таких как CoreOS rkt, LXC, OpenVZ, containerd, Apache Mesos и Docker Swarm. Однако более 4/5 контейнеров запускается в среде Docker, а для оркестрации более половины пользователей выбрали Kubernetes. Об этих системах мы и поговорим.

Чем полезны контейнеры

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

Техническим же специалистам контейнеры прежде всего полюбились за возможность упаковать приложение вместе с его средой запуска, решая тем самым проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика и в последующих окружениях рано или поздно приведёт к сбоям, и нужно будет как минимум потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало! ¯\_(ツ)_/¯».

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

Чем контейнеры отличаются от виртуальных машин

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

• Контейнеры требуют значительно меньше ресурсов для своей работы, что положительно сказывается на производительности и бюджете.
• Контейнеры можно запускать только в той же операционной системе, что стоит на host-системе — то есть запустить Windows-контейнер на host-системе с Linux не получится (на персональных устройствах это ограничение обходится с помощью технологии виртуализации). Однако это не относится к разным дистрибутивам одной и той же ОС, например Ubuntu и Alpine Linux.
• Контейнеры предоставляют меньшую степень изоляции, поскольку используют ядро host-системы, что потенциально создаёт бóльшие риски в эксплуатации при небрежном отношении к безопасности.

Основные принципы контейнеризации приложений

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

1 контейнер — 1 сервис

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

Неизменность образа

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

Утилизируемость контейнеров

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

Отчётность

Контейнер должен иметь точки проверки состояния его готовности (readiness probe) и жизнеспособности (liveness probe), предоставлять логи для отслеживания состояния запущенного в нём приложения.

Управляемость

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

Самодостаточность

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

Лимитирование ресурсов

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

Docker

Когда мы говорим о контейнерах в современных IT-системах, прежде всего мы подразумеваем Docker — open-source-технологию, благодаря своей популярности ставшую в IT синонимом слова «контейнер».

Основные сущности Docker

Dockerfile

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

Image

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

Instance

Запущенный экземпляр образа, минимальная единица деплоя в Docker.

Volume

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

Registry

Репозиторий, используемый для хранения Docker-образов. Registry может быть как публичным, так и приватным, защищённым механизмом аутентификации.

Процесс разработки в среде Docker

Типичный процесс разработки в среде Docker выглядит следующим образом: разработчики устанавливают на свои машины Docker, загружают собранный заранее образ с установленной средой сборки и выполнения приложения, а затем запускают контейнер командой, которая также пробросит в него директорию с исходниками. Для установки Docker не требуется особого железа — он может быть установлен на вполне заурядной машине. Однако у него имеются ограничения по версиям ОС — Windows 7 64bit или выше для ПК с поддержкой Hyper-V, macOS Sierra 10.12 для устройств от Apple и версией ядра 3.10 для систем с Linux. Контейнеры Docker являются родной технологией для ОС Linux и запускаются на других с помощью виртуальных машин под её управлением.

Инструкции по установке Docker на разных платформах: Windows, Mac, Linux Ubuntu.

Чтобы запустить ваш первый контейнер на Docker, после его установки введите в командной строке docker run hello-world — эта команда загрузит образ hello-world с Docker hub’а (публично доступный Docker registry), создаст контейнер, используя этот образ, и выдаст приветственную фразу:

Hello from Docker!
This message shows that your installation appears to be working correctly.
...

Оркестрирование контейнеров: Kubernetes

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

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

Основные сущности, которыми оперирует Kubernetes

Node (master и slave)

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

Namespace

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

Pod

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

ReplicaSet

Объект, описывающий и контролирующий соответствие запущенного на кластере количества реплик Pod’ов. Установка количества реплик больше одной требуется для повышения отказоустойчивости и масштабирования приложения. Общепринято создавать ReplicaSet с помощью Deployment.

Deployment

Объект, декларативно описывающий Pod’ы, количество реплик и стратегию их замены при обновлении параметров.

StatefulSet

Действует по тому же принципу, что и ReplicaSet, однако дополнительно позволяет описывать и сохранять при перезапуске уникальный сетевой адрес Pod’ов или их дисковое хранилище.

DaemonSet

Объект, обеспечивающий контроль за тем, что на каждой ноде (или нескольких выбранных) будет запущено по экземпляру указанного Pod’а.

Job и CronJob

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

Label и Selector

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

Service

Инструмент для публикации приложения в качестве сетевого сервиса, в том числе реализующий балансировку нагрузки между Pod’ами приложения.

Если сравнить объекты Docker и Kubernetes, то станет понятна разница в задачах, решаемых этими инструментами: можно сказать, что Docker управляет контейнерами, в то время как Kubernetes управляет самим Docker.

Управление конфигурацией (Configuration/Complexity Management)

Развитие IT-систем ведёт ко всё большему их усложнению, и это порождает проблемы управления — даже на небольшом количестве серверов или контейнеров ручное управление приложением превращает практически любое изменение конфигурации в трудовой подвиг, а на десятках или сотнях делает его абсолютно невозможным. К счастью, новые проблемы ведут и к новым решениям — в этом разделе мы расскажем о некоторых инструментах управления конфигурацией (configuration management) или, как ещё принято говорить, управления сложностью (complexity management). Они используются для установки, управления и обновления приложений Kubernetes: например, с их помощью можно описать приложение, состоящее из фронтенда, бэкенда и всех необходимых для их работы сервисов, таких как объекты Kubernetes, контейнеры с веб-серверами, базами данных, серверами очередей и т. д.

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

Kustomize

Благодаря популярности у пользователей и своей простоте, начиная с версии Kubernetes 1.14, Kustomize является встроенным инструментом управления конфигурацией. Для описания приложений использует чистый язык разметки YAML без возможности шаблонизации и использования параметров, что является одновременно его сильной и слабой сторонами, упрощая процесс настройки и вместе с тем сильно его ограничивая.

Ansible

Многофункциональный инструмент, для которого конфигурация Kubernetes-приложений — лишь одно из великого множества применений, реализованная с помощью специального модуля интеграции. Например, Ansible может быть использован для настройки виртуальных машин, развертывания облачной инфраструктуры, выполнения бэкапов и т.д. Его универсальность позволяет решать разнообразные задачи, связанные с IT-проектами, одним инструментом — но ценой меньшей функциональности в отношении управления конфигурацией приложений Kubernetes. Для описания использует YAML и язык шаблонов Jinja2.

Управляйте хранилищами данных в автоматизированном режиме с помощью модулей интеграции Ansible NetApp.

Jsonnet

Также как и Ansible, Jsonnet не является чем-то специфичным для Kubernetes, однако многие знакомы с ним именно благодаря K8s. Jsonnet описывает объекты с помощью расширенного JSON, включающего комментарии, текстовые блоки, параметры, переменные, условные включения и функции. Очень мощный и гибкий инструмент.

Helm

Пакетный менеджер приложений Kubernetes. Этот инструмент описывает приложения в виде декларативных диаграмм (charts), создающихся с помощью языка разметки YAML и шаблонов Golang. Helm обладает широкой базой готовых диаграмм, даёт возможность версионировать конфигурации и переключаться между версиями релизов, т. е. откатывать конфигурацию. Из всех приведенных здесь инструментов является наиболее функциональным в отношении управления приложениями Kubernetes и одновременно обладает наиболее сложным способом описания конфигурации из-за шаблонов Golang, весьма требователен к пользовательским навыкам.

В этой статье перечислены лишь те инструменты, что наиболее заслуживают внимания по нашему мнению. Помимо них существует ещё с добрый десяток решений для задач управления конфигурацией в Kubernetes: такие как Kapitan, Ksonnet, Replicated Ship и т. д. При выборе менеджера управления конфигурацией мы рекомендуем определиться с требованиями, предъявляемыми к нему, и руководствоваться принципом разумной достаточности, не используя без нужды излишне сложный инструмент — хорошим путем будет начать с чего-то простого, дополнительно задействуя более мощный инструмент, когда возникнет необходимость.

Платформы для хостинга контейнеров

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

Своё железо (bare metal)

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

Облачные решения (SaaS)

Крупные облачные провайдеры предоставляют своим клиентам сервисы для запуска контейнеров — готовые среды, обёрнутые удобным интерфейсом управления. Построенные по такому принципу решения называются Software as a Service (SaaS). Они не требуют никаких капитальных затрат, поскольку вся инфраструктура арендуется, а конфигурация создаётся в минимальном объёме, относящемуся исключительно к запускаемому приложению. Сами же кластеры настраиваются провайдером по указанному пользователем небольшому объему параметров. SaaS-решения — оптимальный вариант для стартап-компаний, небольших и развивающихся проектов. Самым большим минусом этого решения можно назвать повышенную в сравнении с bare metal стоимость при условии многолетнего использования.

Тремя наиболее популярными облачными платформами на сегодня являются Amazon Web Services, Microsoft Azure и Google Cloud. Все три провайдера имеют доступный в виде сервиса Kubernetes, и все три из них предлагают пробный период пользования сервисами, выдавая депозит на сумму 200–300 $. Чтобы оценить удобство и качество облачных решений и сравнить друг с другом их поставщиков, вам даже не придется тратить свои деньги.

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

Заключение

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

Рассказывает Сергей Бродин. Текст подготовили вместе с NetApp

Что такое контейнер Docker? Определение

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

Контейнеры Docker: еще одна форма виртуализации

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

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

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

Сравнение организации контейнеров и виртуальных машин. Источник: Docker. Компания, которая поддерживает и разрабатывает код Docker, просто известна как Docker. Компания получила 40 миллионов долларов венчурного финансирования от Sequoia Capital в сентябре 2014 года. Платформа состоит из Docker Engine, инструмента для выполнения и упаковки программного обеспечения, и Docker Hub, службы для обмена приложениями в облаке.

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

Подход компании также ускоряет разработку и тестирование приложений.

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

Портативность и масштабируемость

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

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

Обновлено Коннором Крэйвеном в августе 2019 г.

Читать далее

Что такое контейнер? Определение, преимущества и варианты использования

облако

2 июня 2020 г.

2 июня 2020 г.

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

• Что такое контейнер?
• Преимущества контейнеров
• Для чего используются контейнеры?
• Контейнеры и виртуальные машины
• Типы контейнеров

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

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

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

Контейнеризация дает множество преимуществ.

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

Примечание. В фоновом режиме контейнеры требуют совместимости с архитектурой ЦП, на которой они работают, для правильной работы. К счастью, многие инструменты, такие как Docker Buildx, обеспечивают совместимость сборки с несколькими архитектурами.

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

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

Для чего используются контейнеры?

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

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

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

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

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

Чтобы узнать больше о контейнерах и виртуальных машинах и о том, как они появились, прочитайте этот пост Лиама Рэндалла, вице-президента по технической коммерциализации: Эволюция инфраструктуры: как мы пришли к контейнерам .

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

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

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

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

Типы контейнеров

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

Контейнеры были реализованы по-разному на протяжении многих лет. Самой ранней реализацией контейнеризации был системный вызов, сделанный в 1979 по имени « chroot», , который просто изолировал файловые системы запущенных процессов. В течение следующих нескольких десятилетий на сцене появилось несколько новых участников. Virtuozzo разработала первое коммерческое контейнерное решение в 2000 году. Вскоре после этого у FreeBSD, Solaris и сообщества Linux появились собственные решения для реализации контейнеров. Большинство этих решений были построены на основе ядра Linux, но потребность в контейнерах Microsoft Windows была признана.

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

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

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

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

С нетерпением жду

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