6 шаблонов приложений Docker .NET для начала работы с контейнерами

Это первый блог из трех статей, посвященных автоматическому развертыванию приложений .NET в контейнерах Linux и Windows .

В этом блоге мы расскажем о развертывании базовых приложений ASP.NET и ASP.NET MVC в контейнерах Linux с использованием HyperForm, платформы автоматизации развертывания, которая упрощает переход приложений к контейнерам. Блог охватывает 6 шаблонов приложений, которые включают Nginx и Apache HTTP для обратного прокси.

Для запуска и управления простыми приложениями Docker ASP.NET «Hello MVC» и «Hello Web» на 18 различных облаках и платформах виртуализации (включая HyperGrid, vSphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, DigitalOcean, IBM SoftLayer и т. д.), убедитесь, что вы либо:

• Зарегистрируйтесь в HyperForm SaaS — http://dchq.io или
• Загрузите HyperForm On-Premise Standard Edition бесплатно — http://dchq.co/hyperform-on-premise.html

Фон

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

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

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

Инфраструктура подключаемых модулей, основанная на пользовательских сценариях, которые могут быть написаны на BASH, PowerShell, Perl, Ruby или Python, обеспечивает расширенное развертывание приложений и ускоряет интеграцию с любыми внешними службами, включая решения для хранилищ, сетей или мониторинга.

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

Зачем возиться с контейнерами?

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

• Переносимость приложений — контейнеры Docker работают одинаково на любом хосте Linux. Это устраняет проблему развертывания приложений в другой вычислительной инфраструктуре (например, на локальной машине разработчика, виртуальной машине vSphere или в облаке).
• Более высокая плотность серверов. Облегченная природа контейнеров позволяет разработчикам оптимизировать использование серверов для рабочих нагрузок своих приложений, запуская большее количество контейнеров на одном хосте, обеспечивая при этом те же преимущества изоляции и распределения ресурсов, что и у виртуальных машин.

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

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

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

Конкретизация

• Виртуальные машины : время загрузки как ОС, так и приложения
• Контейнеры : только время создания приложения — т.е. время для ускорения процессов Linux

Распределение ресурсов

• Виртуальные машины : обычно жесткие . Виртуальный ЦП и память обычно предварительно выделяются для ВМ, и их сложно изменить после предоставления — в зависимости от используемой платформы виртуализации или поставщика облачных услуг.
• Контейнеры : как правило, гибкие . Максимальные пределы ЦП и памяти могут быть определены для контейнеров при желании (используя параметры cpu_shares и mem_limit). По умолчанию контейнеры могут продолжать использовать ресурсы, доступные на базовом компьютере. С помощью HyperForm можно также определить минимальные пределы для ЦП и памяти, что позволяет пользователям размещать рабочие нагрузки приложений на компьютерах, на которых достаточно ресурсов ЦП и памяти. Вы можете прочитать больше об этом здесь: http://dchq.co/docker-compose.html#docker-nodejs .

Сборка образов Docker с использованием microsoft / aspnet: 1.0.0-rc1-final

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

Конечно, если вы используете Docker Hub, у вас есть возможность использовать функцию Automated Builds . Однако, если вы используете личный реестр , HyperForm может обеспечить необходимую автоматизацию построения образа.

Примеры ASP.NET, использованные в этом блоге, были клонированы из официальных проектов Microsoft на GitHub:

• https://github.com/aspnet/Home/tree/dev/samples/1.0.0-rc1-final/HelloMvc
• https://github.com/aspnet/Home/tree/dev/samples/1.0.0-rc1-final/HelloWeb

После входа в HyperForm (либо размещенную версию DCHQ.io, либо локальную версию) пользователь может перейти к пункту « Автоматизация» > « Сборка изображения» и нажать кнопку « +» , чтобы создать новую сборку образа файла Dockerfile (Git / GitHub / BitBucket) .
Укажите необходимые значения следующим образом:

• URL Git — (например, https://github.com/dchqinc/docker-aspnet-hellomvc.git или https://github.com/dchqinc/docker-aspnet-helloweb )
• Git Branch — это поле является необязательным, но пользователь может указать ветку из проекта GitHub. Ветвь по умолчанию — главная.
• Git Credentials — пользователь может безопасно хранить учетные данные в частном репозитории GitHub в HyperForm. Это можно сделать, перейдя в облачные провайдеры и нажав +, чтобы выбрать учетные данные
• Кластер — создание образов Docker организовано с помощью агента HyperForm. В результате пользователю необходимо выбрать кластер, в котором агент будет использоваться для выполнения построения образов Docker. Если кластер еще не создан, обратитесь к этому разделу, чтобы зарегистрировать уже запущенные узлы или автоматизировать подготовку новой виртуальной инфраструктуры.
• Push to Registry — пользователь может отправить только что созданный образ в общедоступный или частный репозиторий на Docker Hub, Nexus, Artifactory или Quay. Чтобы зарегистрировать учетную запись реестра Docker, пользователь должен перейти к облачным провайдерам и нажать +, чтобы выбрать Docker Registries.
• Репозиторий — это имя репозитория, в которое будет помещено изображение. Например, наше изображение было помещено в dchq / php-example: latest
• Тег — это имя тега, которое вы хотели бы дать для нового изображения. Поддерживаемые имена тегов в HyperForm включают в себя:
  • {{date}} — форматированная дата
  • {{timestamp}} — полная отметка времени
• Выражение Cron — пользователь может планировать создание образов Docker, используя готовые выражения cron. Это облегчает ежедневные и ночные сборки для пользователей.
• Плагины до сборки и плагины после сборки — пользователь может запускать плагины на машинах, используемых для запуска сборок образа — например, установка библиотек Linux или запуск сценариев очистки сборки после образа.
• Кто может управлять — пользователь может пометить эту сборку как частную или поделиться ею с другими пользователями или группами.

После заполнения обязательных полей пользователь может нажать « Сохранить» .

Затем пользователь может нажать кнопку « Play», чтобы создать образ Docker по запросу. Вот фактический файл Docker, используемый для создания образа Docker для приложения Hello.NET Web.

https://github.com/dchqinc/docker-aspnet-helloweb/blob/master/Dockerfile

Создание шаблонов приложений на основе YAML, которые можно повторно использовать на любом хосте Linux, работающем где угодно

HyperForm полностью совместим с Docker Compose ( https://docs.docker.com/compose/compose-file/ ).

Платформа, тем не менее, предоставляет базовые ( необязательные ) усовершенствования Docker Compose, поддерживающие расширенные плагины, которые можно запускать на более чем 20 различных этапах жизненного цикла, чтобы обеспечить обнаружение служб, контейнеризацию на лету и автоматизацию хранения приложений.

Он также поддерживает перекрестные привязки переменных среды изображения, автоматический поиск и внедрение IP-адреса контейнера и дополнительные параметры, такие как mem_min, publish_all, cluster_size и registry_id. Инфраструктура обнаружения служб заботится о переконфигурировании балансировщиков нагрузки и других компонентов приложения, когда кластер масштабируется или уменьшается или когда контейнеры останавливаются / запускаются.

Чтобы создать шаблон приложения, пользователь может войти в HyperForm (либо размещенную версию DCHQ.io, либо локальную версию), перейти к « Чертежам» > « Приложение / Машина» и затем нажать кнопку « +» , чтобы создать новый шаблон Docker Compose .

Мы создали 6 шаблонов приложений для базовых приложений ASP.NET «Hello MVC» и «Hello Web», но с различными веб-серверами для обратного прокси-сервера и балансировки нагрузки.

Докер ASP.NET Привет MVC

Docker ASP.NET Привет MVC с Nginx

Docker ASP.NET Привет MVC с Apache HTTP

Docker ASP.NET Hello Web

Docker ASP.NET Hello Web с помощью Nginx

Docker ASP.NET Hello Web с использованием Apache HTTP

Привязки переменных среды к изображениям

Пользователь может создавать привязки переменных среды между изображениями, делая ссылку на переменную среды другого изображения или значения контейнера. Например, подключаемый модуль, используемый в контейнере Apache HTTP, ссылается на частный IP-адрес контейнера ASP.NET-контейнера BalancerMembers = BalancerMember http: // {{aspnet-mvc | container_private_ip}}: 5004 — в котором IP-адрес контейнера ASP.NET Hello MVC-контейнера автоматически извлекается и внедряется в файл конфигурации Apache HTTP.

Вот список поддерживаемых значений переменных среды:

• {{буквенно-цифровой | 8}} — создает случайную 8-символьную буквенно-цифровую строку. Это наиболее полезно для создания случайных паролей.
• {{Имя изображения | ip}} — позволяет ввести IP-адрес хоста контейнера в качестве значения для переменной среды. Это наиболее полезно для разрешения уровня промежуточного программного обеспечения устанавливать соединение с базой данных.
• {{Имя изображения | имя_контейнера}} или {{Имя изображения | container_ip}} — позволяет ввести имя контейнера в качестве значения для переменной среды. Это наиболее полезно для разрешения уровня промежуточного программного обеспечения устанавливать безопасное соединение с базой данных (без предоставления порта базы данных).
• {{Имя изображения | container_private_ip}} — позволяет ввести внутренний IP-адрес контейнера в качестве значения для переменной среды. Это наиболее полезно для разрешения уровня промежуточного программного обеспечения устанавливать безопасное соединение с базой данных (без предоставления порта базы данных).
• {{Имя изображения | port_Port Number}} — позволяет ввести номер порта контейнера в качестве значения для переменной среды. Это наиболее полезно для разрешения уровня промежуточного программного обеспечения устанавливать соединение с базой данных. В этом случае указанный номер порта должен быть внутренним номером порта, то есть не внешним портом, который выделен для контейнера. Например, {{PostgreSQL | port_5432}} будет преобразован в фактический внешний порт, который позволит промежуточному программному обеспечению установить соединение с базой данных.
• {{Имя изображения | Имя переменной среды}} — позволяет ввести значение переменной окружения изображения в переменную окружения другого изображения. Варианты использования здесь бесконечны — так как большинство многоуровневых приложений будут иметь зависимости между изображениями.

Использование плагинов и параметра хоста для развертывания высокодоступного приложения Docker Java

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

• host1, host2, host3 и т. д. — случайным образом выбирает хост в дата-центре (или кластере) для развертывания контейнера
• IP-адрес 1, IP-адрес 2 и т. Д. — позволяет пользователю указать фактические IP-адреса для использования при развертывании контейнера
• Имя хоста 1, Имя хоста 2 и т. Д. — позволяет пользователю указать фактические имена хостов, которые будут использоваться для развертывания контейнеров
• Подстановочные знаки (например, «db- » или «app-srv- ») — для указания подстановочных знаков для использования в имени хоста

Использование этапов жизненного цикла плагина для обнаружения службы Docker

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

Вы заметите, что подключаемый модуль HTTP Nginx и Apache выполняется во время следующих этапов или событий:

• При создании HTTP-контейнера Nginx или Apache — в этом случае IP-адреса контейнеров серверов приложений внедряются в файл конфигурации по умолчанию, чтобы упростить распределение нагрузки для нужных сервисов.
• Когда кластер серверов приложений ASP.NET масштабируется или масштабируется — в этом случае обновленные IP- адреса контейнеров серверов приложений внедряются в файл конфигурации по умолчанию, чтобы упростить распределение нагрузки для нужных сервисов.
• Когда серверы приложений ASP.NET останавливаются или запускаются — в этом случае обновленные IP- адреса контейнеров серверов приложений внедряются в файл конфигурации по умолчанию, чтобы упростить распределение нагрузки для нужных сервисов.

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

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

• on_create — выполняет плагин при создании контейнера
• on_start — запускает плагин после запуска контейнера
• on_stop — выполняет плагин до остановки контейнера
• on_destroy — выполняет плагин перед уничтожением контейнера
• pre_create — выполняет плагин перед созданием контейнера
• post_create — выполняет плагин после того, как контейнер создан и запущен
• post_start [: Node] — запускает плагин после запуска другого контейнера
• post_stop [: Node] — запускает плагин после остановки другого контейнера
• post_destroy [: Node] — запускает плагин после уничтожения другого контейнера
• post_scale_out [: Node] — запускает плагин после масштабирования другого кластера
• post_scale_in [: Node] — запускает плагин после масштабирования другого кластера
• cron (0 1 1 * *?) — планирует плагин на основе указанного выражения cron. Вот несколько примеров для выражений cron.
• exec_on_machine — выполняет плагин на базовой машине. Этот жизненный цикл может использоваться с другими жизненными циклами контейнера. Например, exec_on_machine pre_create выполнит плагин на машине перед созданием контейнера.

Предоставление базовой инфраструктуры в любом облаке

После сохранения приложения пользователь может развернуть приложение в кластере (или пуле серверов), который уже доступен, или предоставить инфраструктуру на 18 различных конечных точках облака, включая HyperGrid, VMware vSphere, OpenStack, CloudStack, Amazon Web Services, Rackspace Microsoft Azure, DigitalOcean, IBM SoftLayer и многие другие.

Для получения подробных инструкций по автоматизации обеспечения инфраструктуры, пожалуйста, обратитесь к подробной документации здесь:
http://dchq.co/docker-infrastructure-as-a-service.html

Записанная демонстрация в этом блоге использует кластер подготовленных виртуальных машин в Microsoft Azure Resource Manager. Инструкции по автоматизации подготовки виртуальных машин в ARM с использованием шаблонов YAML многократного использования см. В подробной документации здесь.

http://dchq.co/docker-azure-resource-manager.html

Развертывание приложения ASP.NET в кластере HyperGrid

Пользователь может развернуть приложения ASP.NET в любом из доступных кластеров. На платформе HyperForm SaaS ( http://dchq.io ) — общедоступный кластер, настроенный на инфраструктуру HyperGrid, доступен для бесплатного развертывания приложений (до 2 ГБ памяти). Этот кластер предназначен только для развертываний DEV / TEST и обновляется каждые 2-3 месяца.

Чтобы развернуть приложение в кластере HyperGrid, пользователь может перейти на страницу библиотеки , нажать « Настроить» и затем выбрать доступный кластер HyperGrid .

Доступ к терминалу в браузере для работающих контейнеров

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

Например, для развертывания ASP.NET мы использовали командную строку, чтобы убедиться, что код приложения действительно находится в каталоге / app .

Мониторинг загрузки процессора, памяти и ввода / вывода работающих контейнеров

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

Пользователь может выполнять исторический анализ мониторинга и соотносить проблемы с обновлениями контейнеров или создавать развертывания. Это можно сделать, нажав на ссылку Статистика . Пользовательский диапазон дат может быть выбран для исторического просмотра процессора, памяти и ввода / вывода.

Замена (повторное развертывание) контейнеров, когда новые изображения помещаются в реестр

Для разработчиков, желающих следовать модели «неизменяемых» контейнеров, перестраивая образы Docker, содержащие код приложения, и увеличивая количество новых контейнеров при каждом обновлении приложения, HyperForm предоставляет рабочий процесс автоматической замены контейнера, который извлекает это последнее изображение в реестр и заменяет работающий контейнер на последнее изображение.

Чтобы настроить профиль повторного развертывания (или замены) контейнера, пользователь может выбрать « Профиль повторного развертывания контейнера» в меню « Действие» .

Затем пользователь может выбрать один из сохраненных реестров Docker и ввести имя изображения, которое следует использовать при замене работающего контейнера. Чтобы зарегистрировать учетную запись Docker Hub, Nexus, Artifactory или Quay , пользователь должен перейти к облачным провайдерам и нажать +, чтобы выбрать Docker Registries .

Масштабирование приложения ASP.NET

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

Чтобы масштабировать кластер контейнеров ASP.NET от 1 до 2, пользователь может щелкнуть меню « Действия» запущенного приложения и затем выбрать « Уменьшить масштаб» . Затем пользователь может указать новый размер кластера и нажать « Запустить сейчас» .

Подключаемый модуль обнаружения служб, настроенный для балансировщика нагрузки (т. Е. Nginx или Apache HTTP), будет автоматически запущен для внедрения IP-адресов контейнеров новых серверов приложений в файл конфигурации по умолчанию, чтобы упростить балансировку нагрузки для нужных служб.

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

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

Выполнение дополнительных модулей для обновления приложения

Если пользователь хотел бы внести простые изменения в приложение ASP.NET, используя динамическую компиляцию ASP.NET ( https://msdn.microsoft.com/en-us/library/ms366723.aspx ), тогда пользовательский скрипт-плагин в может быть вызван, чтобы сделать такие обновления.

Инфраструктура подключаемых модулей, основанная на пользовательских сценариях, которые могут быть написаны на BASH, PowerShell, Perl, Ruby или Python, обеспечивает расширенное развертывание приложений и ускоряет интеграцию с любыми внешними службами, включая решения для хранилищ, сетей или мониторинга.

Чтобы сделать это, пользователь должен сначала создать плагин, перейдя в « Чертежи» > « Плагины» .

Затем на странице приложения пользователь может выбрать « Запуск плагинов» из меню « Действия» .

Пользователь может затем найти плагин и при необходимости переопределить доступные аргументы (например, URL для получения последних файлов ASP.NET). Поскольку в этом примере используется динамическая компиляция ASP.NET, перезапуск контейнера не требуется. Однако для других обновлений, требующих быстрого перезапуска контейнера, можно выбрать переключатель Перезапуск .

Вывод

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

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

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

Для запуска и управления простыми приложениями Docker ASP.NET «Hello MVC» и «Hello Web» на 18 различных облаках и платформах виртуализации (включая HyperGrid, vSphere, OpenStack, AWS, Rackspace, Microsoft Azure, Google Compute Engine, DigitalOcean, IBM SoftLayer и т. д.), убедитесь, что вы либо:

• Зарегистрируйтесь в HyperForm SaaS — http://dchq.io или
• Загрузите HyperForm On-Premise Standard Edition бесплатно — http://dchq.co/hyperform-on-premise.html