Linux в 25 лет

0
43
Linux в 25 лет

Linux переделал центр обработки данных и создал облако; теперь это революция разработки приложений и доставки

Если в течение 25 лет в Linux существовала одна константа, это изменение. Само ядро ​​прошло через десятки ревизий; Появились дистрибутивы Linux для большинства случаев использования; и культура Linux превратилась из проекта хобби в выходные дни в основу всемирной ИТ-инфраструктуры.

Теперь мы видим первые версии следующей волны изменения Linux. Контейнерные, одно-ядерные и другие эксперименты с формой перестраивают Linux изнутри, открывая незапланированные возможности того, как операционная система с открытым исходным кодом, которая могла (и сделала!), Могла сделать это снова и снова.

Контейнер (r) Linux

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

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

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

Вскоре после того, как Докер взлетел, люди начали экспериментировать с радикальной концепцией.

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

Для этого было больше причин, чем простое новизна. Например, сокращенный Linux будет легче управлять и поддерживать, легче защищаться от атак и легче освещаться перед лицом Heartbleed или Shellshock. Это также означало, как отметил Мэтт Асай , Linux, который был более привлекательным для разработчиков, а не администраторов систем или операционных систем.

Успех Docker и эксперименты CoreOS вдохновили другие дистрибутивы Linux на подобные идеи.

Red Hat построила поддержку в своей линейке продуктов для запуска контейнеров в масштабе (см. OpenShift) и открыла собственную породу Linux-концентратора, ориентированного на контейнер, а также Red Hat Atomic Host.

В некотором смысле Atomic Host во многом похож на CoreOS: упрощенная версия Linux, которая управляет контейнерами и мало что делает. Но идея Red Hat заключалась не только в создании минимальной системы и ее оставлении.

Вместо этого Red Hat использовал Atomic Host в качестве основы для создания полного дистрибутива Linux, используя контейнеры для управления установками программного обеспечения на платформе.

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

Canonical сделала то же самое со своей системой упаковки приложений Snappy, а также с контейнером.

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

Unikernels: Только достаточно и не более

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

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

Один из способов использования Linux в качестве основы для unikernel - это «библиотечная ОС». Здесь ядро ​​Linux по сути превращается в гигантскую библиотеку кодов, которая связана с приложением. Графен Библиотека OS является один проект , который использует этот подход и может быть скомпилирован для встраивания «родные, немодифицированные приложения Linux» в загрузочном ядре.

Еще один выдающийся пример unikernels и Linux - это Docker.

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

Первоначально запуск Docker на рабочем столе включал загрузку полного дистрибутива Linux на базе VirtualBox. Теперь он включает использование собственной технологии виртуализации каждой платформы для загрузки пользовательского ядра Linux со встроенным Docker Engine .

Не все на борту с unikernel в качестве дороги впереди. Интерес Докера к другим ядрам, в частности, вызвал волну недавней критики. Брайан Кэнтрилл из Joyent утверждал, что unikernel « непригодны для производства » - по его мнению, недостатки намного перевешивают выгоды. Все работает в одном процессе; unikernel трудно отлаживать; они создают зависимости от языка и стека разработки, используемых для создания unikernel.

Алекс Полви из CoreOS был скептически настроен по многим причинам. Но план Докера до сих пор был нацелен на конкретный вариант использования - рабочий стол - и не предназначен для односторонней замены поведения контейнеров.

Всегда есть следующий шаг

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

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

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

С unikernel и Linux будущее заключается в том, чтобы выяснить, где эти две работают лучше всего и почему.

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

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

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

Источник: https://www.itworld.com/article/3109238/linux/linux-at-25-containers-and-unikernels-prove-less-is-more.html