Работа со службами веб-приложений Azure.

Службы веб-приложений Azure позволяют запускать критически важные веб-приложения в Microsoft Azure без управления серверами. Они предлагают несколько функций, помогающих командам DevOps запускать и запускать приложения без сложных конфигураций. В предыдущей статье мы рассмотрели, как создать план Azure Web App и App Service. В этой статье мы сосредоточимся на некоторых ключевых функциях служб веб-приложений, таких как определение собственного URL-адреса для использования веб-приложения, настройка для поддержания производительности приложения при высокой загрузке платформы, а также , которые позволяют команда разработчиков для работы над обновлениями и позволяет легко перейти к производству.

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

Настройка личного домена

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

Существует несколько способов создания личного домена, каждый из которых включает настройку либо создания записи A в общедоступном DNS для общедоступного IP-адреса, либо создания записи CNAME в общедоступном DNS, указывающей на общедоступное имя (<webapp>.azurewebsites. сеть).

Второй шаг — нажать на пункт «Пользовательские домены». На новой странице нажмите Добавить имя хоста. Используйте запись DNS, созданную ранее (в нашем примере www, которая была CNAME для ap171.azurewebsites.net ) и нажмите Validate. Если обе проверки внизу прошли успешно, нажмите «Добавить имя хоста».

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

Настройка развертывания с помощью GitHub

В предыдущей статье мы настроили базовый веб-сайт, создав простую HTML-страницу и импортировав ее с помощью FTP. Однако службы веб-приложений предлагают более элегантные и профессиональные решения, такие как Visual Studio Team Services, GitHub и Bitbucket, и это лишь некоторые из них.

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

Первый шаг — нажать «Слоты развертывания», затем нажать кнопку «Добавить слот». В новом блейде мы пометим этот первый слот как Staging и начнем его с нуля.

После создания нового справа отобразится список всех существующих слотов. Нажмите на первую запись — в нашем примере это будет (имя формируется в следующем формате: <web-app-name>+<Slot-Name>).

Нажмите на , который мы только что создали, и основной блейд изменится на Staging. Все изменения с этого момента выполняются в этой среде, а не в рабочей среде. Нажмите «Параметры разработки».

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

Здесь важно понимать, что происходит. Мы работаем над отдельной производственной средой и будем настраивать автоматические обновления в этой промежуточной области, поступающие с GitHub. С точки зрения Dev/Ops, как только они выпускают новые обновления на GitHub, их можно тестировать в тестовой зоне. Когда мы закончим код и будем готовы перейти к продакшену, мы промежуточную версию на продакшн. Важно отметить, что конфигурация GitHub имеет слот Staging и не будет перемещена в рабочую среду даже после замены.

Вот пошаговое руководство по настройке параметров развертывания в недавно созданном промежуточном слоте.

1. В пункте выберите GitHub из списка.
2. В пункте нажмите «Авторизовать», а на новой странице введите учетные данные GitHub и подтвердите авторизацию.
3. В пункте выбираем один из проектов GitHub, в нашем случае Azure
4. В пункте по умолчанию выбран master
5. В элементе администратор может выбрать тест, который необходимо выполнить, выбрав количество пользователей, исходное местоположение и продолжительность. Этот тест будет выполняться после каждого развертывания

После определения мы можем проверить статус, снова щелкнув элемент «Параметры разработки», и в это время будет показано состояние синхронизации. В приведенном ниже примере мы видим применяемые обновления.

Если мы проверим URL-адрес текущего приложения, мы сможем увидеть обновления на лету. Если мы отправим новые обновления на GitHub, промежуточная среда будет обновлена автоматически. Этот процесс развертывания помогает команде разработчиков тестировать свои изменения на лету, не влияя на производственную среду.

Когда подготовка кода завершена и нам нужно перейти к производству, мы можем нажать «Слоты развертывания», а затем нажать «Обмен».

В подкачки мы можем определить тип подкачки, а также источник и цель операций. Новая колонка Preview Changes позволяет проверить различия между Stage и Production. Цель состоит в том, чтобы оставить среды с одинаковыми настройками, чтобы сделать плавный переход между средами.

Управление автомасштабированием

Одной из ключевых особенностей Azure Web App Services является возможность иметь гибкую инфраструктуру, в которой администратор может увеличивать и уменьшать масштаб на основе правил, определенных администратором. Эта гибкость использует преимущества эластичности Azure и помогает бизнесу достигать своих целей без покупки нового оборудования или выполнения сложной настройки — все выполняется динамически с помощью служб веб-приложений.

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

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

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

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

Управление защитой

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

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

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

После создания первой резервной копии будет показан список всех доступных резервных копий. Администратор может щелкнуть любую резервную копию и загрузить весь пакет в виде ZIP-файла. Существует также вариант « Восстановить», где вы можете выбрать любую предыдущую резервную копию или даже выбрать учетную запись хранения с файлами резервных копий (расширение.zip). Восстановление можно выполнить на рабочий или на другой.

С помощью Web App Services вы можете делать гораздо больше

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

Имейте в виду, что мы еще не коснулись сути служб веб-приложений. На платформе доступно множество инструментов и ресурсов, которые помогают командам DevOps запускать веб-приложения в Microsoft Azure.