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

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

Проблемы, которые вдохновили контейнеры:

Представьте, что вы программируете простую игру для своих друзей. Вы кодируете его на Python 2.0, используя такие-то библиотеки и пакеты, на рабочем столе Ubuntu Linux. После некоторой борьбы вы, наконец, финишируете. Взволнованный, вы отправляете свои файлы своим друзьям, чтобы они похвастались. За исключением одного сообщения, которое вы отвечаете: «игра не запускается». Это работало нормально на вашей установке, но не на их? Что дает?

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

Частичное решение:

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

Контейнерное решение:

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

Возвращаясь к примеру с игрой на Python, вы разрабатывали свою игру в Ubuntu, но ваш друг использовал дистрибутив Fedora Linux. Одно заметное различие между ними заключается в том, что они используют разные менеджеры пакетов по умолчанию, APT и RPM соответственно. Чтобы решить эту проблему, вы создаете образ контейнера, в котором указано, какой менеджер пакетов вам нужен. Вуаля! Ваш друг запускает собственный экземпляр контейнера, и теперь ваше приложение безупречно работает на его компьютере. Самое приятное то, что ваш друг может просто удалить контейнер, когда он закончит с ним.

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

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

История:

Термин контейнер был введен в 2008 году компанией Google и Linux Kernel Project, однако первые итерации этой технологии появились в 1979 году как команда Chroot в операционной системе Bell Unix. Chroot, сокращение от change root, позволял разработчикам создавать дополнительный корневой каталог для своих приложений. Поскольку программы не могут перемещаться за пределы корневого каталога, любые программы, размещенные в этих вторичных каталогах, не могут получить доступ к файлам за пределами их ограниченной области. Chroot был относительно удобен для создания песочниц для тестирования кода, но его использование было громоздким.

Общие сценарии терминала и их зависимости, такие как «cd, ls и grep», необходимо было скопировать в псевдокаталог, если разработчик хотел использовать их в песочнице. Бремя установки делало их chкорни неприятными для работы. Кроме того, они не были достаточно безопасными для производства.

Со временем простая концепция chroot превратилась в настоящую контейнеризацию. В 1999 году Билл Чесвик, исследователь из Bell Labs, стал первым разработчиком, продвинувшим технологию после 20 лет застоя. Чтобы отслеживать, как хакеры перемещаются по компьютерным системам, он превратил каталоги, сгенерированные chroot, в изолированные среды с низкими ставками, чтобы хакеры могли атаковать и играть в них (также известные как приманки). Эти модифицированные корневые каталоги имели свои собственные сети, файловые системы, учетные записи пользователей и т. д., все они были защищены от основной системы. Со временем эти протоконтейнеры стали называть «тюрьмами».

Вдохновленная работой Чесвика, в 2004 году проприетарная ОС Solaris от Oracle улучшила «тюрьмы», представив зоны Solaris, которые позволили пользователям регулировать объем потребляемых ими вычислительных ресурсов. Но технология по-прежнему не была удобной для пользователя и ограничивалась закрытой коммерческой системой. Google изменил все это в 2006 году. Мегакорпорация представила свою контейнероподобную технологию для развертывания изолированных подсистем, называемых cgroups. В отличие от Solaris, Google открыл исходный код и к 2008 году объединил свою технологию с Linux, создав проект Linux Container, от которого происходит термин контейнер.

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

Оставалось решить только одну проблему — удобный способ объединить требования к среде для простоты использования и повторного развертывания. Создание моментальных снимков контейнера по-прежнему было ручным и болезненным процессом. Google представил свой проект Let Me Contain That For You, который управлял и развертывал новые контейнеры из файлов конфигурации по мере необходимости, но он оставлял желать лучшего.

К счастью, в 2008 году небольшой стартап dotCloud начал работу над решением под названием Docker для быстрой настройки и развертывания контейнеров для своего облачного сервиса. Изначально dotCloud не стремился популяризировать контейнеры. Вместо этого он создал конкурента Heroku, который позволил компаниям развертывать многоязычные серверы и службы. Docker был просто внутренним инструментом, который позволил их первоначальным усилиям. К 2013 году они решили полностью отдать предпочтение Docker и открыли свой код. Его простой интерфейс и интуитивно понятная структура сделали его популярным программным обеспечением для настройки и создания контейнеров. Всего через год Google решил перенаправить свои ресурсы на поддержку проекта.

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

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

Вот и все. Удачного взлома :)

Дополнительные материалы на PlainEnglish.io. Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord . Заинтересованы в хакинге роста? Ознакомьтесь с разделом Схема.