Что такое контейнер в информатике кратко

Обновлено: 04.07.2024

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

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

Wikimedia Foundation . 2010 .

Полезное

Смотреть что такое "Контейнер (программирование)" в других словарях:

Агрегирование (программирование) — В этой статье не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена. Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники … Википедия

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

Монада (программирование) — У этого термина существуют и другие значения, см. Монада (значения). Монада в программировании это абстракция линейной цепочки связанных вычислений. Её основное назначение инкапсуляция функций с побочным эффектом от чистых функций, а… … Википедия

Стандартная библиотека шаблонов — Стандартная библиотека языка программирования C++ fstream iomanip ios iostream sstream Стандартная библиотека шаблонов … Википедия

Boost (библиотека) — Boost Тип библиотека (программирование) Написана на С++ Операционная система Кроссплатформенный Последняя версия Boo … Википедия

Boost — Тип библиотека (программирование) Написана на С++ Операционная система Кроссплатформенный Последняя версия Boost 1.52.0 (05.11.2012) … Википедия

Библиотека Boost — Boost Тип библиотека (программирование) Написана на С++ ОС Кроссплатформенный Версия Boost 1.39.0 02.05.2009 … Википедия

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

C++ — У этого термина существуют и другие значения, см. C. См. также: Си (язык программирования) C++ Семантика: мультипарадигмальный: объектно ориентированное, обобщённое, процедурное, метапрограммирование Тип исполнения: компилируемый Появился в … Википедия

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

Ядро и ОС

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

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

Виртуальная машина

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

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

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

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

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

cgroups

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 контейнеры

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 контейнер состоит из слоёв образов, при этом бинарные файлы упакованы в один пакет. В базовом образе содержится операционная система, она может отличаться от ОС хоста.

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

Поверх базового образа лежит ещё несколько образов, каждый из них является частью контейнера. Например, следующим после базового, может быть образ, который содержит 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 для контейнеров), и много чего ещё.

Почему именно контейнеры

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

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

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

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

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

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

Администрирование

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

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

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

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

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

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

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

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

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

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

Помимо Spotify контейнеры для разработки своих сервисов используют такие компании, как Yelp, Airbnb, Google, Microsoft, Lyft, eBay, PayPal и многие другие.

Система управления контейнерами (система оркестровки) — это веб-панель администрирования, которая руководит работой контейнеров. Примером может быть открытая платформа Kubernetes , разработанная Google.

Есть и другие решения — Docker, Rancher, OpenShift и так далее.

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

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

Все говорят, что контейнеры – это круто. Но они бывают разные: системные и контейнеры приложений, сертифицированные и кастомные. В этой публикации рассказываем о том, для чего нужен каждый тип.

🐳 Виды контейнеров: когда какой использовать

Системный контейнер – один из старых примеров технологии контейнеров. Системный контейнер похож на виртуальную машину: идеален для хранения операционной системы и запуска нескольких процессов. Системные контейнеры используются для традиционных и монолитных приложений – в одном контейнере архитектура, инструменты и конфигурации.

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

Схема: контейнер приложения (слева) и контейнер системы

Схема: контейнер приложения (слева) и контейнер системы

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

Сравнение системного контейнера и виртуальной машины. Как видите, они во многом похожи

Сравнение системного контейнера и виртуальной машины. Как видите, они во многом похожи

Ещё один вариант – использование системных контейнеров Virtuozzo и контейнеров приложений Docker во вложенной архитектуре. Внутри платформы различные типы контейнеров могут использоваться для разных целей:

  • сертифицированные управляемые контейнеры;
  • elastic VPS;
  • кастомные Docker-контейнеры;
  • Docker Engine CE;
  • кластер Kubernetes.

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

Самый распространенный вариант. Обычно предлагается несколько предварительно сконфигурированных и управляемых программных стеков, позволяющих создавать гибкие топологии с необходимым софтом (Java, PHP, Node.js, Ruby, Python или Go), балансировщик нагрузки, база данных и прочее.

Панель управляемого контейнера

Панель управляемого контейнера

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

Взаимодействие оркестратора с образами

Взаимодействие оркестратора с образами

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

Настройка под Elastic VPS образа с CentOS 7.7

Настройка под Elastic VPS образа с CentOS 7.7

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

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

Работа оркестратора с кастомными образами

Работа оркестратора с кастомными образами

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

Настройка пользовательского контейнера

Настройка пользовательского контейнера

Docker Engine Community Edition работает внутри системных контейнеров, но в то же время имеет полную совместимость с нативной экосистемой Docker.

Взаимодействие оркерстратора с образами Docker Engine

Взаимодействие оркерстратора с образами Docker Engine

Такая интеграция позволяет работать с основными инструментами контейнерной технологии Docker:

    – работает с Dockerfile и запускает pre-built образы контейнеров. – хранит и предоставляет доступ к многочисленным общедоступным и частным образам, предназначенным для развертывания в Docker Engine.
    – помогает собирать приложения, состоящие из нескольких компонентов, где все необходимые конфигурации объявляются в одном compose-файле.
    – представляет собой несколько независимых Docker узлов, объединенных в кластер.

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

🐳 Виды контейнеров: когда какой использовать

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

В рамках курса данного факультета вы освоите технологии Docker, Kubernetes, работу с виртуальными машинами, облачные технологии и микросервисную архитектуру.

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

Читайте также: