Docker vs. Kubernetes: Давайте жить дружно
В мире современного ПО мало что может сравниться по крутости с Docker и Kubernetes.
Возьмем, к примеру, Docker. Название самой платформы, по сути, уже стало нарицательным и часто используется для обозначения технологии контейнеризации как таковой. Сегодня можно запросто услышать, как разработчик говорит «докер», имея в виду контейнеры в целом, и скорее всего он считает Docker лучшей платформой контейнеризации.
Kubernetes, в свою очередь, называют одной из самых скоростных платформ за всю историю ПО с открытым исходным кодом, и в действительности так оно и есть. Изначально компания Google разрабатывала инструмент для внутреннего пользования под названием Borg, который затем разросся до платформы контейнерной оркестрации с открытым исходным кодом, известной как Kubernetes.
Хотя первопроходцы уже получили хороший гандикап, многие ИТ-специалисты и организации только начинают осваивать контейнеры, технологии контейнерной оркестрации и сопутствующие тренды. В этой статье мы объясним, что такое и Docker, и Kubernetes, а также с чем их едят, разберем главные тренды и сценарии использования, расскажем об основных принципах их работы и ответим на самые животрепещущие вопросы, например: «Обязательно ли я должен выбрать одно или другое?» (спойлер: нет, не обязательно, и мы сейчас объясним, почему).
Docker и контейнеры
Согласно собственному определению Docker, образ контейнера — это «легкий, автономный, исполняемый программный пакет, в котором есть всё необходимое для его выполнения: код, среда выполнения, служебные программы, системные библиотеки и настройки».
Главная причина, по которой название Docker стало нарицательным среди платформ контейнеризации, заключается в том, что Docker первым научился упаковывать расширенные функции ядра Linux вместе, тем самым позволив командам разработчиков быстрее создавать упаковываемые продукты, способные работать на разных серверах.
Контейнеры Docker существенно облегчили жизнь разработчиков, которые теперь могут одинаково эффективно работать в локальных, тестовых, промежуточных и продуктивных средах, везде запуская один и тот же готовый продукт или образ контейнера Docker.
Это ускорило разработку и развертывание: вместо того, чтобы строить с нуля целый сервер для запуска сервиса или приложения, можно запустить образ контейнера Docker на хосте и, задействовав немного ресурсов хоста, запустить сервис или приложение, даже в нескольких средах.
Разница особенно заметна при сравнении с образами традиционных виртуальных машин: контейнеры весят меньше и эфемерны, а значит их можно разворачивать и сворачивать по мере увеличения или уменьшения ресурсов или масштабирования приложения.
Контейнеризация дает много преимуществ в эпоху DevOps, облачных архитектур и набирающих популярность распределенных вычислительных сред, что поспособствовало быстрому и широкому распространению Docker.
Kubernetes и контейнерная оркестрация
Конечно, контейнеризированные процессы могут быть сложными. Первые адепты Docker очень скоро обнаружили, что они заполнили контейнеры сотнями или даже тысячами рабочих нагрузок. Всё это быстро привело к проблемам эксплуатации, ведь масштабируемость стоит денег.
Когда у вас 10 контейнеров и четыре приложения, контейнерная оркестрация — это не повод для беспокойства. Но если у вас 1 000 контейнеров и четыре сотни сервисов, то все уже не так просто. Еще немного, и черт ногу сломит.
Добро пожаловать в эпоху Kubernetes и контейнерной оркестрации. Kubernetes — это инструмент, автоматизирующий развертывание, масштабирование и управление контейнерными приложениями. Автоматизация — ключевое слово и одна из причин, по которой Kubernetes становится все более популярным среди инженеров и других специалистов, отвечающих за работоспособность веб-сайтов, инфраструктур и эксплуатацию систем. Kubernetes позволяет управлять непрерывной оркестрацией тысяч контейнеров, т.е. ваши сервисы будут всегда доступны.
На первых порах организации использовали один из нескольких инструментов с открытым исходным кодом, в том числе Kubernetes, или создавали собственные для управления контейнерами в масштабе. Однако Kubernetes постепенно становится для оркестрации тем, чем Docker уже стал для контейнеризации, т.е. именем нарицательным.
По сути Docker и Kubernetes не исключают, а, наоборот, дополняют друг друга как части более крупной системы, и вопрос выбора между ними просто не стоит. К слову, недавний опрос, проведенный организацией The New Stack, показал, что переход на контейнеры приводит к внедрению Kubernetes, причем оба процесса неразрывно связаны между собой. (Мы подробнее осветим эту тему ниже в обзоре рынка.)
Kubernetes vs. Docker Swarm
О Docker и Kubernetes закрепилось ложное представление как о конкурентах (либо одно, либо другое), но, как говорится, нет дыма без огня. Дело в том, что в экосистеме Docker есть собственное решение для контейнерной оркестрации Docker Swarm — функциональный аналог Kubernetes.
Кто бы ни одержал безоговорочную победу в контейнерной оркестрации, Kubernetes был как никогда к этому близок в 2018 г. Доказательства? Docker добавил мощную поддержку для Kubernetes в начале года, выпустив официальный релиз Docker Enterprise Edition 2.0, которой позволяет пользователям запускать Kubernetes и Docker Swarm на одном кластере.
Иногда, если речь идет не о продуктивной среде, а только о средах разработки или тестирования, использовать контейнеры Docker можно и без Kubernetes. Принято считать, что Docker Swarm легче использовать, тогда как большинству пользователей освоение Kubernetes дается куда труднее.
Однако стоит организациям переместить огромные контейнеризированные рабочие нагрузки в продуктивную среду, сразу становится понятно, что нет ничего лучше Kubernetes (статистические данные будут уже через пару строк). Теперь, когда Docker облегчил бизнесу использование Kubernetes, у этого легендарного дуэта появится еще больше фанатов.
Обзор рынка контейнеризации
Давайте немного сменим тему и посмотрим на ценность контейнеров в долларовом эквиваленте. По прогнозам исследовательской группы 451 Research, рынок контейнеров приложений вырастет с запланированных 1,5 млрд долл. США в 2018 году до 2,7 млрд долл. США в 2020 году. Неплохо, учитывая, что Docker существует всего лишь пять лет, а Kubernetes 1.0 вышел в июле 2015 года.
Достоверные данные о доле рынка контейнеризации достаточно сложно найти, потому что рынок еще только формируется, но приведенные выше цифры указывают на то, что он стремительно растет.
Например, исследовательская группа 451 Research во время ежеквартального опроса Voice of the Enterprise обнаружила, что 23,7% респондентов уже применяют контейнеризацию, а недавний опрос, проведенный компанией New Relic, показал, что эта тенденция гораздо ярче прослеживается среди пользователей публичного облака: 26% респондентов предпочитают пользоваться контейнерами, а 39% — контейнерной оркестрацией. Кроме того, группа 451 Research отмечает, что все больше компаний используют контейнеры в продуктивной среде, т.е. мы сейчас переживаем переходный период, и скоро еще больше компаний будут использовать контейнеры уже не только в средах разработки и тестирования, но и в продуктивной среде.
В марте 2018 года по случаю пятилетнего юбилея Docker компания подвела итоги: скачано 37 млрд контейнеров, 3,5 млн приложений упаковано в контейнеры Docker, более 450 клиентов пользуются корпоративной версией Enterprise Edition.
Kubernetes тоже продолжает завоевывать мир. Организация New Stack опубликовала электронную книгу «Текущее состояние экосистемы Kubernetes», где собран богатый пользовательский опыт и, в частности, сказано, что многие организации не осознают, насколько важна оркестрация, пока не начнут развертывать контейнеры в продуктивной среде.
Данные исследования можно посмотреть на сайте New Stack: 60% организаций, активно использующих контейнеры в продуктивной среде, используют и Kubernetes, а еще 19% — только начали использовать Kubernetes в продуктивной среде. Аналогично, 58% компаний, которые только начинают использовать контейнеры в продуктивной среде, сообщают, что только начали использовать в ней и Kubernetes. При этом 22% респондентов пока думают, стоит ли переходить на Kubernetes.
Последние тренды: Docker и контейнеры
Чем же обусловлен такой спрос на контейнеры? Рассмотрим несколько значимых и часто пересекающихся примеров, когда точно стоит использовать контейнеры:
Последние тренды: Kubernetes и оркестрация
Возможно, главной причиной перехода на Kubernetes, на самом деле, стало внедрение контейнеров. Как уже было сказано выше, многие организации осознают, что использование внушительного количества контейнеров, особенно в продуктивной среде, требует хорошей оркестрации.
Помимо этого, еще несколько трендов повлияли на развитие Kubernetes.
Хотя Docker и Kubernetes появились относительно недавно, они стремительно развиваются и демонстрируют внушительный потенциал. Многие компании и команды DevOps только начинают вгрызаться в этот гранит, и им точно понадобятся крепкие зубы.
Что умеет Kubernetes, чего не умеет Docker
Если вы недавно познакомились с Docker, возможно, вы уже слышали о Kubernetes. Если вы не до конца понимаете связь, различия или схожесть этих технологий, эта статья для вас.
Мы расскажем, зачем нужен Kubernetes, если вы уже пользуетесь Docker-контейнерами. Так что же такого можно сделать в Kubernetes, чего нельзя достичь средствами Docker?
Что такое Kubernetes и сравнение его с Docker
Kubernetes — это платформа для оркестрации контейнеров, которая позволяет построить распределенную отказоустойчивую систему. Kubernetes автоматически управляет жизненным циклом контейнеров, поддерживает стабильное состояние системы и распределяет нагрузку по разным узлам.
Kubernetes и Docker нельзя сравнивать напрямую. Docker — инструмент для создания и запуска контейнеров, а Kubernetes — оркестратор, инструмент для управления контейнерами. Kubernetes позволяет построить кластер (Cluster) — распределенную отказоустойчивую систему, в то время как Docker работает на отдельном узле.
Важно понимать, что в этой статье мы говорим о простых Docker-контейнерах, без применения оркестратора Docker Swarm.
Главное преимущество Kubernetes — автоматизация
Основное преимущество Kubernetes перед простыми Docker-контейнерами можно описать одним словом — автоматизация. Но под этой автоматизацией понимается много различных возможностей, о которых мы расскажем далее и приведем несколько конкретных примеров.
Нужно отметить, что все эти автоматизации можно сделать и без Kubernetes, но для этого придется использовать много отдельных инструментов, настраивать их и писать скрипты. Например, для автоматизации выкатки обновлений приложений можно использовать Ansible — систему управления конфигурациями. Такая система может обновить все инстансы приложения и убедиться, что оно работает. Но для этого она должна знать, какие хосты сейчас работают, как к ним обратиться, на каких именно хостах работают инстансы нужного приложения. Для этого придется писать скрипты, которые будут за этим следить.
Заниматься поддержкой этих скриптов и инструментов придется самостоятельно. Иногда могут возникать проблемы, например, если у одного из инструментов выйдет новая версия, которая несовместима с другими инструментами. Или для новой версии инструмента придется переписывать скрипты, потому что поменяется логика работы этого инструмента.
Единое управление всеми узлами
Когда в инфраструктуре становится много узлов (серверов, на которых работают контейнеры), ими нужно централизованно управлять. Удобней всего иметь центральную точку управления, которая может принять команды и выполнить действия вне зависимости от того, на каком узле находятся контейнеры.
Docker работает в рамках отдельных узлов. Если у вас несколько узлов, то на каждом из них запущен докер-демон, который ничего не знает о существовании других узлов. Каждый демон знает лишь о том, что происходит на его узле. И поэтому обычными докер-контейнерами сложно управлять централизованно.
У Kubernetes есть центральная точка управления — API-сервер. В кластере может быть много узлов, контейнеров и настроек, но всеми ими можно управлять через единый сервер. В кластер можно отправить команду (например, чтобы обновить наше приложение), и Kubernetes сам найдет, на каких узлах оно находится, и обновит его.
Управление конфигурациями и конфиденциальными данными
Приложениям часто требуются файлы настроек, переменные окружения или конфиденциальные данные (логины, пароли, токены и т. п.). Обычно такие файлы хранятся отдельно от приложений. Если приложение работает на нескольких узлах, нужно распространить эти файлы настроек на все узлы. Причем если настройки изменятся, их снова нужно обновить на всех узлах.
Docker. Так как докер-демон работает отдельно на каждом узле, все манипуляции по доставке и синхронизации этих файлов между узлами нужно проводить вручную. К тому же у Docker-контейнеров нет возможности хранения конфиденциальных данных в зашифрованном виде. Докер может использовать только переменные окружения.
В Kubernetes есть средство для центрального управления конфигурациями — ConfigsMaps для настроек и Secrets для конфиденциальных данных. Если разместить в них свои настройки, то приложения смогут получить к ним доступ из любого узла.
Автомасштабирование узлов
Технология контейнеризации позволяет легко масштабировать приложение. Если нагрузка на приложение растет, можно запустить дополнительные экземпляры, чтобы приложение не зависало. Но отслеживать изменение нагрузки вручную неправильно, гораздо удобнее это автоматизировать. Здесь под масштабированием мы имеем в виду как увеличение количества контейнеров, так и подключение дополнительных узлов, если ресурсов существующих узлов становится недостаточно.
Docker. Контейнеры не могут автомасштабироваться. Так как каждый докер-демон работает только в рамках своего узла, он не знает, что происходит на остальных. Докер-демон не может следить за нагрузкой, создавать дополнительные контейнеры или подключать новые узлы.
Kubernetes умеет автомасшабироваться. «Из коробки» он умеет масштабировать количество контейнеров, и дополнительно можно настроить подключение новых узлов. Когда нагрузка на приложение возрастет, Kubernetes добавит новые инстансы приложения, а при необходимости и подключит новые узлы. Когда нагрузка спадет, Kubernetes завершит лишние контейнеры и освободит узлы.
Обновления приложений и откаты
Приложения часто дорабатываются и изменяются. При обновлении контейнерного приложения нужно обновить инстансы на всех узлах. При этом на время обновления нужно сделать так, чтобы обновляемый контейнер не получал запросы, то есть его нужно вывести из балансировки нагрузки. Также часто требуется выполнять обновление без простоев по методу Rolling-Update, то есть чтобы все инстансы обновлялись последовательно и приложение было доступно в любой момент времени.
Другая задача — откат обновлений. Иногда для быстрого устранения ошибки нужно откатить обновление, чтобы потом спокойно разбираться и устранять ошибку. По сути, эта процедура аналогична обновлению, просто в обратном направлении.
В Docker нужно обновлять отдельно каждый контейнер. У контейнеров нет средства, чтобы одной или несколькими командами обновить все инстансы. Нужно найти все узлы, на которых работает приложение, и обновлять их по очереди.
Kubernetes. Чтобы выкатить новую версию приложения в Kubernetes, достаточно в Deployment-файле указать новую версию в имени образа. При этом если нужно выполнить обновление по типу Rolling-Update, это тоже достаточно указать в Deployment-файле. Если после обновления нужно откатиться, достаточно выполнить команду rollout, и Kubernetes сам откатит все контейнеры.
Система хранения данных
Многим приложениям нужен доступ к хранилищу постоянных данных. Так как контейнеры по своей природе изолированны, обычно настроить доступ к хранилищу не самая тривиальная задача.
У Docker есть тома (Volumes), которые нужны для упрощения работы с постоянными данными. Но в любом случае тома нужно дополнительно настраивать, причем делать это придется для каждого контейнера отдельно. Например, у нас есть сетевое хранилище Ceph. Чтобы подключить его к контейнеру, сначала нужно создать том, подключить его ко всем узлам с контейнерами и потом смонтировать этот том в каждый отдельный контейнер.
Kubernetes намного упрощает работу с дисками. Полностью «из коробки» подключить диски не получится, тут все равно потребуется некоторая настройка и дополнительные инструменты. Но сделать это гораздо проще за счет объектов PersistentVolume и PersistentVolumeClaim. Сначала нужно создать том и настроить его один раз, а потом каждый контейнер может самостоятельно запрашивать ресурсы, без необходимости дополнительных манипуляций. Подробнее об этом механизме читайте в нашей статье про основы Kubernetes.
Распределение нагрузки и маршрутизация трафика из внешней сети
Если у приложения есть несколько инстансов, то, чтобы обратиться к приложению, нужно знать его адреса. Причем внешние сервисы, которые обращаются к приложению, даже не должны знать, сколько инстансов у приложения, где они запущены и так далее. Они должны взаимодействовать с приложением как с единой сущностью, не задумываясь об его инстансах.
Другая задача — маршрутизация трафика из внешней сети. Если приложение должно быть доступно из интернета или любой другой внешней сети, необходимо настроить маршрутизацию. Чтобы внешний трафик правильно распределялся по нужным сервисам и приложениям.
Docker. В простых докер-контейнерах нет возможности распределять нагрузку между инстансами приложения. Например, приложение хочет обратиться к сервису. Чтобы это сделать, оно должно знать IP-адрес этого сервиса. А если у сервиса несколько инстансов, то приложение должно знать все адреса и само решать, в какой именно инстанс обратиться. Если один из контейнеров сервиса перезапустится и получит новый адрес, приложение должно как-то об этом узнать. Это неудобный и неправильный подход к разработке.
Проблема усугубляется, если к сервису нужно обращаться из внешней сети. Для этого придется поддерживать в актуальном состоянии и еще и таблицу маршрутизации для внешнего трафика.
Kubernetes берет распределение трафика на себя. Если рассматривать пример выше, то Kubernetes позволяет над всеми инстансами сервиса создать единый объект типа Service. Этот объект сам следит за всеми инстансами, и, если контейнер перезапускается, он сам обновит информацию о его новом адресе. И чтобы приложение могло обратиться к сервису, достаточно знать одно доменное имя, которое будет всегда постоянным.
Также Kubernetes умеет перенаправлять внешний трафик в контейнеры. Для этого нужно установить и настроить Ingress Controller, но это гораздо проще, чем самостоятельно настраивать и поддерживать маршрутизацию. Kubernetes позволяет сделать так, чтобы к приложениям можно было обращаться по доменным именам или URL-путям. Ingress Controller сам будет перенаправлять трафик на нужный инстанс контейнера.
Чем еще хорош Kubernetes
Кроме автоматизации, есть еще несколько особенностей, которые выделяют Kubernetes перед обычными докер-контейнерами.
Когда использовать Kubernetes, а когда достаточно Docker-контейнеров?
Если у вас мало контейнеров и они все работают на одном узле, вам будет достаточно простых Docker-контейнеров. Kubernetes нужен, когда у вас много контейнеров и узлов, которыми нужно управлять. Также Kubernetes подходит, если вам нужна распределенная отказоустойчивая система.
Kubernetes против Docker
Создавайте, отправляйте и масштабируйте приложения быстрее с помощью контейнерных технологий, которые эффективнее работают вместе.
Kubernetes против Docker, вопрос
Беседа на тему Kubernetes против Docker часто обрамлена как «или. или»: Что использовать — Kubernetes или Docker? Это все равно, что сравнивать яблоки с яблочным пирогом. Мысль о выборе между ними является распространенным заблуждением.
Различие между Kubernetes и Docker легче понять, если сформулировать его как вопрос типа «друг с другом». Дело в том, что вам не нужно выбирать Kubernetes или Docker — это принципиально разные технологии, которые хорошо работают вместе для создания, отправки и масштабирования контейнерных приложений.
Docker и рост контейнеризации
Docker — это технология с открытым исходным кодом и формат файлов контейнеров для автоматизации развертывания приложений в виде портативных, самодостаточных контейнеров, которые могут работать в облаке или локальных средах. Docker, Inc., хотя и имеет похожее название, является одной из компаний, которая развивает технологию Docker с открытым исходным кодом для работы на Linux и Windows в сотрудничестве с такими поставщиками облачных вычислений, как Корпорация Майкрософт.
Хотя идея изолирования сред не нова и существуют другие типы контейнерного программного обеспечения, за последние годы служба Docker превратилась в формат контейнеров по умолчанию. Docker оснащен функцией Docker Engine, которая является средой выполнения. Она позволяет создавать и запускать контейнеры на любой машине разработки, а затем сохранять или передавать образы контейнеров через реестр контейнеров, например Docker Hub или Реестр контейнеров Azure.
По мере того как приложения растут и начинают включать контейнеры, развернутые на разных серверах, работать с ними становится все сложнее. Хотя Docker предоставляет открытый стандарт для упаковки и распространения контейнерных приложений, потенциальные сложности могут быстро нарастать. Как вы координируете и планируете использование большого количества контейнеров? Как все контейнеры в вашем приложении взаимодействуют друг с другом? Как вы масштабируете множество экземпляров контейнера? Здесь Kubernetes может быть полезным.
Оркестрация контейнеров и Kubernetes
Kubernetes — это программное обеспечение с открытым исходным кодом, которое предоставляет API для управления места и способа выполнения этих контейнеров. Оно позволяет запускать контейнеры и рабочие нагрузки Docker и помогает справляться с некоторыми сложностями при перемещении для масштабирования нескольких контейнеров, развернутых на нескольких серверах.
Kubernetes позволяет координировать целый кластер виртуальных машин и планировать запуск контейнеров на таких виртуальных машинах в зависимости от доступных вычислительных ресурсов и потребностей каждого контейнера в таких ресурсах. Контейнеры объединяются в объекты pod — это основная единица операций в Kubernetes. Эти контейнеры и объекты pod можно масштабировать до желаемого состояния и управлять их жизненным циклом, таким образом поддерживая работоспособность своих приложений.
В чем разница между Docker и Kubernetes?
Хотя Kubernetes обычно сравнивают с Docker, более подходящим сравнением является Kubernetes против Docker. Docker Swarm. Docker Swarm — это технология оркестрации Docker, которая фокусируется на кластеризации контейнеров Docker, плотно интегрированная в экосистему Docker и использующая собственный API.
Принципиальное различие между Kubernetes и Docker заключается в том, что Kubernetes предназначен для работы через кластер, в то время как Docker работает на одном узле. Служба Kubernetes более обширна, чем Docker Swarm, и предназначена для эффективной координации кластеров узлов в масштабировании в процессе производства. Kubernetes pod — это единицы планирования, которые могут содержать один или несколько контейнеров в экосистеме Kubernetes и распределяются между узлами для обеспечения высокой доступности.
Kubernetes и Docker работают лучше сообща.
В то время как задача контейнеров состоит в том, чтобы кодировать и сразу запускать их в любом месте, Kubernetes предоставляет возможности для организации всех ресурсов контейнера и управления ими с одного уровня управления. Он поможет вам с сетевыми технологиями, балансированием нагрузки, обеспечении безопасности и масштабированием на всех узлах Kubernetes, на которых работают ваши контейнеры. Kubernetes также имеет встроенный механизм изоляции, как, например, пространства имен. Этот механизм позволяет группировать ресурсы контейнера по разрешениям доступа, промежуточным средам и т. д. Эти конструкции облегчают ИТ-отделам получение доступа к ресурсам самообслуживания, а разработчикам — сотрудничество даже на самых сложных архитектурах микрослужб, не смешивая все приложения в своей среде разработки. Сочетание методов DevOps с контейнерами и Kubernetes также обеспечивает основу архитектуры микрослужб, которая способствует быстрой доставке и масштабируемой оркестрации собственных облачных приложений.
Словом, используйте Kubernetes с Docker, чтобы:
Kubernetes и Docker работают сообща. Docker предоставляет открытый стандарт для упаковки и распространения контейнерных приложений. Docker позволяет собирать и выполнять контейнеры, а также хранить образы контейнеров и предоставлять к ним доступ. Docker можно легко запустить на кластере Kubernetes, но Kubernetes сам по себе не является полноценным решением. Для оптимизации Kubernetes в процессе производства, внедрите дополнительные инструменты и службы для управления безопасностью, системой управления, идентификацией и доступом наряду с непрерывной интеграцией/непрерывным развертыванием (CI/CD) рабочих процессов и других методов DevOps.
Архитектуры решений Kubernetes и Docker в производстве
Микрослужбы с AKS
Служба Azure Kubernetes позволяет быстро развернуть архитектуру с микрослужбами и эффективно управлять ею. Горизонтальное масштабирование, самовосстановление, балансировка нагрузки, управление секретами — со Службой Azure Kubernetes все это выполняется быстро и просто.
Защищенный процесс DevOps для AKS
DevOps и Kubernetes — вместе эффективнее. Внедрив безопасный процесс DevOps вместе с Kubernetes в Azure, вы сможете достичь баланса между скоростью и безопасностью и быстрее доставлять код в нужном масштабе.
Используйте преимущества, которые несет Kubernetes в Azure
Служба Azure Kubernetes (AKS) упрощает развертывание контейнерных приложений и управление ими. AKS предоставляет бессерверную платформу Kubernetes со встроенными возможностями CI/CD, а также безопасностью и управлением корпоративного уровня. Обеспечьте совместную работу специалистов по разработке и эксплуатации на единой платформе, позволяющей оперативно и уверенно создавать, доставлять и масштабировать приложения.
