Kudu: Деплой веб-проектов при помощи Git

Деплой приложения — неизбежный этап в жизненном цикле приложения. Так или иначе вы выполняете деплой, когда показываете приложение миру.

В индустрии нет единого мнения об инструментах для развертывания. Рассмотрим некоторые из них:

  1. FTP — один из древнейших способов деплоя приложения на сервер. Этот способ очень медленный. Кроме того, невозможно обеспечить атомарность обновления. А если в процессе обновления прервалось соединение, то обновиться только часть приложения. Какие будут последствия, остается только догадываться.
  2. File share — во многом аналог предыдущего способа. В целом немного быстрее, но атомарность обновления также не гарантируется.
  3. Ctrl+C, Ctrl+V через Remote Desktop — да-да, до сих пор встречаю людей, которые подключаются к продакшн-серверу по RDP и просто копируют туда архив с файлами. Мы не будем всерьез рассматрвиать этот метод как одну из альтернатив :-)
  4. WebDeploy — инструмент от Microsoft, набирающий популярность. Позволяет создавать пакеты, а затем атомарно деплоить их на сервер. Поддерживаются дополнительные плюшки в виде деплоя БД и других артефактов. Вполне рабочий вариант, за исключением того, что порой бывает весьма капризен. А неинформативные сообщения об ошибках сжирают часы на отладку процесса деплоя.

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

Как процесс деплоя должен выглядеть в идеале:

  1. Собираем рабочую копию проекта.
  2. Атомарно отправляем изменения на сервер.
  3. Приложение обновляется.

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

Проект Kudu

Проект Kudu появился как часть инфраструктуры Azure для деплоя Azure Websites, используя Git. Использовать в качестве транспорта для деплоя Git − известную большинству разработчиков систему контроля версий − отличная идея! Не нужно изучать новый синтаксис или структуру пакета, вы уже знакомы с этим.

Kudu работает гениально просто:

  1. Вы устанавливаете консоль Kudu на ваш сервер. На самом деле это простое приложение, которое добавляется в IIS.
  2. Через веб-интерфейс добавляете новый проект.
  3. Kudu самостоятельно создает для этого проекта веб-сайт в IIS и все необходимые папки.
  4. Для каждого проекта вы получаете ссылку на Git-репозиторий.
  5. Для деплоя приложения вы пушите все изменения в этот репозиторий.

Если ваше приложение находится в Azure Websites, все это для вас уже готово − вам лишь остается отправить изменения в репозиторий.

Настройка Kudu на локальном сервере

Установка и настройка Kudu — процесс простой и безболезненный. Ниже несколько шагов, которые нужно для этого выполнить.

Шаг 1: Загружаем и устанавливаем Kudu

Загружаем последнюю версию проекта с GitHub:

git clone https://github.com/projectkudu/kudu

Запускаем Visual Studio и открываем проект Kudu.sln. Собираем. Можно также обойтись без Visual Studio — запустить build.cmd и скрипт соберет проект для вас.

Kudu.Web — это проект, который нужно разместить в IIS после сборки.

Шаг 2: Настраиваем права доступа

Обратимся к созданному сайту через браузер — в нем пока нет ни одного приложения. На странице Admin можно увидеть расположение приложение Kudu, а также папку, в которую будут размещены все новые приложения.

По умолчанию папка для приложений — app. Можно изменить этот путь в настройках Web.config для Kudu.Web.

Следует убедиться, что текущий пользователь в IIS имеет права на запись в эту папку. Иначе Kudu не сможет создавать и деплоить проекты.

Шаг 3: Создаем новый проект

В Kudu Dashboard переходим на страницу Create Application и указываем имя приложения. Нажимаем Create applciation.

При создании приложения Kudu создает в IIS два приложения — kudu_имяприложения и kudu_service_имяприложения.

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

Шаг 4: Деплоим

Клонируем репозиторий проекта:

git clone http://localhost:45857/coolapp.git

Добавляем файлы в папку проекта и выполняем коммит:

git commit -am “Initial commit”

Пушим изменения.

git push origin master

Проверяем результат:

Бонус

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