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

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

шаблоны, автоматизация и надежность

Вернуться к корням (ch)

Все началось в 1979, когда родилась концепция виртуализации контейнеров. В UNIX обнаружен так называемый системный вызов chroot. Это упростило первые способы предоставления изолированного дискового пространства для процессов. Три года спустя эта функция была добавлена ​​в BSD (Berkeley Software Distribution).

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

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

Интересный факт - ранние версии Docker использовали LXC в качестве драйвера выполнения контейнера (поддержка упала в версии 1.10).

При чем здесь кит?

Когда Docker вышел на рынок в 2013 году, его популярность начала расти. Их приняли в самых разных группах по интересам. От разработчиков программного обеспечения до операторов услуг. Каждый может получить прибыль от быстрого развертывания и идентичных сред, предоставляемых Docker. Такие фразы, как «Ой, на моей машине сработало», должны уйти в прошлое.

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

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

Как рулевой взял на себя

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

Еще в 2014 они выпустили его под названием Kubernetes. Это оркестровка контейнеров с открытым исходным кодом. Хотя Docker Swarm существует как аналог, он никогда не находил отклика. Google нуждался в чем-то, что отвечало бы новым требованиям к микросервисным инфраструктурам.
Docker упустил такую ​​тему в своей экосистеме. Чем больше компаний использовали Kubernetes, тем больше он проявлялся.

Microsoft на борту

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

Что доставляют в наши дни?

Теперь мы можем получить виртуализацию контейнеров во многих формах. Вы можете установить его на любой тип машины, даже на IoT-устройства. Компании развертывают полные стеки контейнеров, чтобы запускать приложения «за кулисами». Cloud-Provider предлагает широкий спектр от контейнеров по запросу до полнофункциональных кластеров.

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

У Docker как компании не было такого счастливого результата. У них было много финансовых проблем. В конце концов, они страдали от недостатка денег, которые они могли получить от своей продукции. Кажется, что даже под капотом они сталкиваются с проблемами. Многие продукты удалили Docker в качестве исполнителя контейнера. Похоже, нужен независимый метод. Это может занять некоторое время из-за медленного развития CNCF (Cloud Native Computing Foundation).

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

А что может быть дальше?

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

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

С моей точки зрения, операционные системы могут больше использовать контейнеры. Запускать контейнеры - это одно, а быть самим контейнером - совсем другое. Почему бы не работать с операционной системой, которая обеспечивает себя через контейнеры. Например, iOS от Apple предоставляет песочницы для каждого приложения. Это делает разработчиков единой платформой для разработки. С точки зрения безопасности гораздо сложнее скомпрометировать базовые компоненты.
Такие проекты, как Rancher OS, уже экспериментируют с этим. Эти эксперименты по-прежнему сосредоточены на серверной операционной системе, но кто знает, насколько далеко они зайдут.

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