Настольные приложения в контейнерах: не так безумно, как кажется

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

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

Изоляция приложений

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

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

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

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

Простое удаление нежелательных приложений

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

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

В то же время тот факт, что контейнерные приложения не устанавливаются обычным образом, может быть полезен не только веб-браузерам. Часто приложения зависят от внешнего кода. Например, для приложения Windows может потребоваться визуальная библиотека времени выполнения C или, возможно, SQL Server Express Edition. Проблема с такими зависимостями заключается в том, что удаление приложения может не удалить зависимости.

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

Потенциальное решение для приложений, которым требуется устаревшая ОС

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

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

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

Недостатки настольных приложений в контейнерах

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

Если вам интересно, есть инструменты, которые могут немного упростить управление исправлениями для контейнерных сред. Одним из таких инструментов является Zypper-docker, который позволяет быстро исправлять образы Docker, основанные на SUSE Enterprise Linux или openSUSE.

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

Идея контейнеризации приложений на рабочем столе существует уже довольно давно. Microsoft уже давно предлагает продукт под названием App-V. Хотя технически App-V не является продуктом контейнеризации и не основан на Docker, базовая технология во многом похожа на контейнеры. Таким образом, я склонен думать о виртуализированных приложениях App-V как о чем-то вроде ранней проверки концепции, иллюстрирующей ценность запуска настольных приложений в изолированном пространстве.