Процесс разработки для Azure Development process for Azure
«Благодаря облаку частные лица и небольшие компании могут практически мгновенно получить доступ к услугам корпоративного класса». «With the cloud, individuals and small businesses can snap their fingers and instantly set up enterprise-class services.»
— Рой Стефан (Roy Stephan) — Roy Stephan
Концепция Vision
Разрабатывайте эффективные приложения ASP .NET Core любым удобным способом, используя Visual Studio или dotnet CLI и Visual Studio Code или подходящий вам редактор. Develop well-designed ASP .NET Core applications the way you like, using Visual Studio or the dotnet CLI and Visual Studio Code or your editor of choice.
Среда разработки приложений ASP.NET Core Development environment for ASP.NET Core apps
Выбор средств разработки: интегрированная среда разработки или редактор Development tools choices: IDE or editor
Предпочитаете ли вы использовать полнофункциональную среду IDE или упрощенный редактор, корпорация Майкрософт предлагает вам удобное решение для разработки приложений ASP.NET Core. Whether you prefer a full and powerful IDE or a lightweight and agile editor, Microsoft has you covered when developing ASP.NET Core applications.
Visual Studio 2019. Visual Studio 2019. Visual Studio 2019 — это лучшая в своем классе интегрированная среда для разработки приложений для ASP.NET Core. Visual Studio 2019 is the best-in-class IDE for developing applications for ASP.NET Core. Она предоставляет ряд функций, повышающих производительность разработчиков. It offers a host of features that increase developer productivity. С ее помощью можно разработать приложение, а затем проанализировать его производительность и другие характеристики. You can use it to develop the application, then analyze its performance and other characteristics. Интегрированный отладчик позволяет приостанавливать выполнение кода и переходить на шаг назад или вперед по коду во время его выполнения. The integrated debugger lets you pause code execution and step back and forth through code on the fly as it’s running. Встроенное средство тестирования позволяет организовывать тесты и их результаты, а также выполнять динамическое модульное тестирование во время написания кода. The built-in test runner lets you organize your tests and their results and can even perform live unit testing while you’re coding. С помощью Live Share вы можете сотрудничать в режиме реального времени с другими разработчиками, что упрощает совместный доступ к сеансу кода по сети. Using Live Share, you can collaborate in real time with other developers, sharing your code session seamlessly over the network. И когда все будет готово, Visual Studio будет содержать все, что необходимо для публикации приложения в Azure или в любом другом месте, где вы можете разместить его. And when you’re ready, Visual Studio includes everything you need to publish your application to Azure or wherever you might host it.
Visual Studio Code и dotnet CLI (кроссплатформенные средства для Mac, Linux и Windows). Visual Studio Code and dotnet CLI (Cross-Platform Tools for Mac, Linux and Windows). Если вам нужен упрощенный кроссплатформенный редактор, поддерживающий любой язык программирования, вы можете использовать Microsoft Visual Studio Code и dotnet CLI. If you prefer a lightweight and cross-platform editor supporting any development language, you can use Microsoft Visual Studio Code and the dotnet CLI. Эти решения обеспечивают простой, но в то же время эффективный рабочий процесс разработки. These products provide a simple yet robust experience that streamlines the developer workflow. Кроме того, Visual Studio Code поддерживает расширения для C# и веб-разработки с функциями IntelliSense и ярлыками задач в редакторе. Additionally, Visual Studio Code supports extensions for C# and web development, providing intellisense and shortcut-tasks within the editor.
Рабочий процесс разработки приложений ASP.NET Core, размещаемых в Azure Development workflow for Azure-hosted ASP.NET Core apps
Жизненный цикл разработки приложений начинается на компьютере каждого разработчика, где разработчик локально пишет код приложения на предпочитаемом языке и тестирует его. The application development lifecycle starts from each developer’s machine, coding the app using their preferred language and testing it locally. Разработчики могут выбирать удобную для них систему управления версиями и настраивать процессы непрерывной интеграции, непрерывной поставки или непрерывного развертывания с использованием сервера сборки или встроенных возможностей Azure. Developers may choose their preferred source control system and can configure Continuous Integration (CI) and/or Continuous Delivery/Deployment (CD) using a build server or based on built-in Azure features.
Чтобы начать разработку приложения ASP.NET Core с поддержкой CI/CD, вы можете использовать Azure DevOps Services или собственный сервер Team Foundation Server (TFS) организации. To get started with developing an ASP.NET Core application using CI/CD, you can use Azure DevOps Services or your organization’s own Team Foundation Server (TFS).
Начальная настройка Initial setup
Чтобы создать конвейер выпуска для приложения, вам необходимо добавить его код в систему управления версиями. To create a release pipeline for your app, you need to have your application code in source control. Настройте локальный репозиторий и подключите его к удаленному репозиторию в командном проекте. Set up a local repository and connect it to a remote repository in a team project. Следуйте указаниям, приведенным ниже: Follow these instructions:
Создайте службу приложений Azure, в которой будет развертываться ваше приложение. Create an Azure App Service where you’ll deploy your application. Создайте веб-приложение, для чего перейдите в колонку «Службы приложений» на портале Azure. Create a Web App by going to the App Services blade on the Azure portal. Нажмите «+Добавить», выберите шаблон веб-приложения, щелкните «Создать» и укажите имя и другие сведения. Click +Add, select the Web App template, click Create, and provide a name and other details. Веб-приложение будет доступно по адресу
Рис. 10-1. Figure 10-1. Создание нового веб-приложения службы приложений Azure на портале Azure. Creating a new Azure App Service Web App in the Azure Portal.
Процесс непрерывной интеграции будет выполнять автоматическую сборку каждый раз при фиксации нового кода в системе управления версиями проекта. Your CI build process will perform an automated build whenever new code is committed to the project’s source control repository. Благодаря этому вы сразу же сможете оценить возможность построения кода (и в идеальном случае прохождения автоматических тестов), а также его последующего развертывания. This gives you immediate feedback that the code builds (and, ideally, passes automated tests) and can potentially be deployed. В результате сборки в рамках процесса непрерывной интеграции создается артефакт пакета веб-развертывания, который публикуется для использования процессом непрерывной поставки. This CI build will produce a web deploy package artifact and publish it for consumption by your CD process.
Реализуйте непрерывную интеграцию, благодаря которой система будет добавлять сборку в очередь каждый раз, когда кто-либо из участников вашей команды фиксирует новый код. Be sure to enable continuous integration so the system will queue a build whenever someone on your team commits new code. Протестируйте сборку и убедитесь, что в качестве одного из артефактов для нее создается пакет веб-развертывания. Test the build and verify that it is producing a web deploy package as one of its artifacts.
После успешной сборки процесс непрерывной поставки будет развертывать результаты сборки непрерывной поставки в вашем веб-приложении Azure. When a build succeeds, your CD process will deploy the results of your CI build to your Azure web app. Чтобы настроить такое поведение, необходимо создать и настроить Выпуск, который будет выполнять развертывание в вашей службе приложений Azure. To configure this, you create and configure a Release, which will deploy to your Azure App Service.
После того как вы настроите конвейер непрерывной интеграции/непрерывной поставки, для развертывания обновлений веб-приложения вам будет достаточно выполнить их и зафиксировать в системе управления версиями. Once your CI/CD pipeline is configured, you can simply make updates to your web app and commit them to source control to have them deployed.
Рабочий процесс разработки приложений ASP.NET Core, размещаемых в Azure Workflow for developing Azure-hosted ASP.NET Core applications
После того как вы настроите учетную запись Azure и процесс непрерывной интеграции/непрерывной поставки, разрабатывать размещаемые в Azure приложения ASP.NET Core будет легко. Once you have configured your Azure account and your CI/CD process, developing Azure-hosted ASP.NET Core applications is simple. Далее описываются общие шаги, которые обычно выполняются при построении приложения ASP.NET Core, размещаемого в службе приложений Azure в качестве веб-приложения, как показано на рис. 10-2. The following are the basic steps you usually take when building an ASP.NET Core app, hosted in Azure App Service as a Web App, as illustrated in Figure 10-2.
Рис. 10-2. Figure 10-2. Пошаговый рабочий процесс построения приложений ASP.NET Core и их размещения в Azure Step-by-step workflow for building ASP.NET Core apps and hosting them in Azure
Шаг 1. Step 1. Внутренний цикл локальной среды разработки Local dev environment inner loop
Разработка приложения ASP.NET Core для развертывания в Azure не отличается от любого другого процесса разработки приложения. Developing your ASP.NET Core application for deployment to Azure is no different from developing your application otherwise. Вы можете использовать удобную для вас среду разработки, будь то Visual Studio 2017 или dotnet CLI и Visual Studio Code или другой предпочтительный редактор. Use the local development environment you’re comfortable with, whether that’s Visual Studio 2017 or the dotnet CLI and Visual Studio Code or your preferred editor. Вы можете писать код, вносить изменения и проводить их отладку, выполнять автоматические тесты, а также локально фиксировать изменения в системе управления версиями до тех пор, пока окончательный вариант не будет готов для публикации в общедоступном репозитории системы управления версиями. You can write code, run and debug your changes, run automated tests, and make local commits to source control until you’re ready to push your changes to your shared source control repository.
Шаг 2. Step 2. Репозиторий кода приложения Application code repository
Как только вы будете готовы поделиться своим кодом с командой, изменения необходимо перенести из локального репозитория системы управления версиями в общедоступный репозиторий команды. Whenever you’re ready to share your code with your team, you should push your changes from your local source repository to your team’s shared source repository. Если вы работаете над отдельной ветвью, этот шаг обычно подразумевает объединение вашего кода с общей ветвью (например, посредством запроса на вытягивание). If you’ve been working in a custom branch, this step usually involves merging your code into a shared branch (perhaps by means of a pull request).
Шаг 3. Step 3. Сервер сборки: Непрерывная интеграция. Build Server: Continuous integration. Сборка, тестирование, упаковка build, test, package
Новая сборка на сервере запускается каждый раз при фиксации изменений в общедоступном репозитории кода приложения. A new build is triggered on the build server whenever a new commit is made to the shared application code repository. В рамках процесса непрерывной интеграции при сборке выполняется полная компиляция приложения и проводятся автоматические тесты, позволяющие убедиться в надлежащей работе всех функций. As part of the CI process, this build should fully compile the application and run automated tests to confirm everything is working as expected. Конечным результатом процесса непрерывной интеграции должна быть упакованная и готовая к развертыванию версия веб-приложения. The end result of the CI process should be a packaged version of the web app, ready for deployment.
Шаг 4. Step 4. Сервер сборки: Непрерывная доставка Build Server: Continuous delivery
После успешной сборки процесс непрерывной поставки выбирает полученные артефакты. Once a build has succeeded, the CD process will pick up the build artifacts produced. К ним относится и пакет веб-развертывания. This will include a web deploy package. Сервер сборки выполнит развертывание этого пакета в службе приложений Azure, заменяя любую существующую службу вновь созданной. The build server will deploy this package to Azure App Service, replacing any existing service with the newly created one. Как правило, этот процесс ориентирован на промежуточную среду, однако некоторые приложения в его рамках развертываются непосредственно в рабочей среде. Typically this step targets a staging environment, but some applications deploy directly to production through a CD process.
Создание Windows Azure Virtual Machine для хостинга web-приложений
Добрый день!
В своей предыдущей статье я рассказывал о том, как можно легко и просто опубликовать веб-приложение, написанное на ASP.NET MVC 4 в новом сервисе Windows Azure Web Sites.
В сегодняшней статье я постараюсь рассказать, как можно расширить границы использования Azure на примере создания в нем виртуальной машины и хостинга на ней веб-приложения.
Шаг 0. Получения доступа.
Для тех, кто поленился перейти по ссылке в начале статьи, я напомню, как можно получить бесплатный доступ к новым возможностям Windows Azure.
Для начала вам надо зарегистрироваться на 90-дневный триал, после чего добавить к своей подписке новые preview-функции (как раз те самые, о которых идет речь). Делается это на странице Предварительный просмотр компонентов, где можно выбрать то, что вы хотите попробовать. В данном случае выбираем Virtual Machine.
Шаг 1. Создание виртуальной машины
После того, как мы получили доступ к компонентам Windows Azure, самое время начать их использовать. Для этого в портале управления выберите пункт Virtual Machines и внизу страницы нажмите большую кнопку плюс (не промахнетесь): 
Нам будет доступно два пункта: Quick Create и From Gallery. На самом деле разница между ними невелика, поэтому рассмотрим более полный путь. Выбираем From Gallery: 
В данном диалоговом окне у нас есть несколько вариантов на выбор. Начнем с того, что помимо готовых образов ОС (видно на скриншоте), нам также предоставляется возможность загрузить свой собственный образ или VHD-диск, из которого впоследствие создастся виртуальная машина. Это будет удобно для крупных проектов, где нужно создать ферму одинаковых машин, не заморачиваясь с настройкой каждой из них. Нас же сейчас это не интересует, поэтому обратим свой взгляд на доступные готовые образы.
На выбор нам предлагается несколько вариантов. Есть Windows Server 2008 R2 (двух версий), линуксовые машинки, специализированный сервер под SQL Server (про этот образ, кстати, недавно писали на хабре) и герой нашего сегодняшнего эксперимента — Windows Server 2012. Почему именно он? Это лично мой выбор. Поскольку я использую Windows Azure пока больше в ознакомительных целях, то я решил, что было бы неплохо попробовать и «новинку сезона» — новый сервер 2012.
Итак, выбираем нужную нам ОС и жмем стрелку снизу. Попадаем на следующий экран мастера создания виртуальной машины: 
Здесь все довольно понятно. Надо указать имя VM, пароль администратора и выбрать одну из предложенных конфигураций будущего «железа». Выбор довольно неплохой и может покрыть большинство требований по производительности для разных типов проекта. Я выбрал Small, что вполне меня устраивает. Идем дальше.
На третьем шаге мастера все тоже довольно понятно: 
Для начала надо определиться с назначением будущей машины. Если мы хотим использовать ее как самостоятельный ресурс (а в данный момент мы именно этого и хотим), то выбираем Standalone. Режим Connect To, как написано в подсказке, позволит нам подключить данную ВМ в некую существующую сеть для разделения нагрузки. Нас это пока не интересует.
Затем надо придумать имя хоста, по которому будет доступна машина. Тут надо не путать имя машины на предыдущем шаге и данное имя хоста. Имя машины — это имя компьютера в Windows. Имя хоста же — это субдомен в домене cloudapp.net, по которому будет осуществляться доступ и управление сервером. Это имя должно быть уникально, поэтому нам тут же в мастере предоставляется подсказка о доступности или занятости того или иного имени.
Остальные поля довольно понятны и особо заострять внимание на них не стоит. Там надо выбрать аккаунт хранилища (либо существующий, либо создать новый), расположение ВМ и подписку, в рамках которой данная машина будет тарифицироваться.
На четвертом шаге вообще ничего делать не нужно, оставляем все как есть: 
Нажимаем на галку внизу, и виртуальная машина начнет создаваться.
Шаг 2. Управление виртуальной машиной
После того, как вы создали виртуальную машину, она будет доступна в соответствующем списке: 
Обязательно дождитесь, когда статус машины сменится с Provisioning на Running. Это будет означать, что машина готова к использованию. Если нажать на ее имя, то откроется панель управления виртуальной машиной: 
Внизу страницы есть кнопка Connect. Она поможет вам получить правильный файл rdp для подключения к этой машине с помощью удаленного рабочего стола. Настало самое время зайти на свеженький сервер и поуправлять им.
Шаг 3. Управление сервером
На самом деле, в этой статье я не буду подробно рассказывать об администрировании Windows Server 2012. Поскольку в названии данной статьи упоминаются web-приложения, вот именно этим мы и займемся — установим IIS.
При первом логине в новый сервер нам откроется окно Server Manager: 
По умолчанию, в Windows Server 2012 службы IIS не включены, поэтому их надо добавить. Выбираем пункт Add roles and features, после чего открывается мастер добавления ролей. Три раза жмем Next (особо любопытные почитают, что там пишут, но сейчас нас это не интересует), и в открывшемся дереве выбираем Web Server (IIS). Далее нам необходимо обязательно выбрать нужные компоненты IIS, которые позволят запускать на нем ASP.NET MVC приложения. Точные параметры настройки я писать не буду, каждый сам решит, что именно ему нужно. Обязательно надо включить ASP.NET, остальное по вкусу.
Жмем несколько раз Next, настраиваем будущую роль как нам надо и после завершения процесса установки наш сервер с радостью готов принимать гостей. Убедиться в этом можно, перейдя по localhost. Должно появиться что-то вроде этого: 
Шаг 4. Открытие доступа
Все здорово, вот мы наконец наладили веб-сервер, разместили на нем какое-то приложение и оно открывается по localhost. Как же теперь открыть его извне? На самом деле все довольно просто. Наверняка вы еще на этапе создания вирутальной машины пытались нажимать на ссылку в панели управления, которая имеет вид .cloudapp.net. И наверняка у вас ничего не отобразилось. Все потому, что к виртуальной машине закрыт доступ извне, причем не на уровне фаерволла самой операционной системы, а на уровне инфраструктуры Windows Azure.
Если вы в панели управления виртуальной машиной посмотрите наверх, то увидите там три пункта меню: Dashboard, Endpoints и Configure. С первым мы разобрались в самом начале, с последним все понятно — там настраиваются параметры «железа», а вот что такое Endpoints давайте разберемся.
В закладке Endpoints мы можем задавать то, какие протоколы и какие порты будут открыты для данной виртуальной машины и на какие физические порты они будут перенаправлены: 
По умолчанию в этом списке будет лишь один порт — тот, по которому вы соединяетесь через Remote Desktop. Причем публичный порт может быть любым, что, видимо, сделано для большей безопасности. Для того, чтобы открывать веб-приложения на данной виртуальной машине, необходимо открыть 80й порт. На скриншоте выше это показано. После этого действия по ссылке .cloudapp.net вы должны будете увидеть ваше собственное приложение. Маленькая победа достигнута.
Шаг 5. Присваиваем собственный домен
На предыдущем шаге мы сделали все, чтобы приложение заработало в облаке и было доступно извне. Однако согласитесь, что было бы совсем не круто, если бы мы могли обращаться к нему только по субдомену и никак бы не могли присвоить свой один или несколько доменов.
Конечно же это сделать возможно и довольно просто. Для этого официальная документация советует два разных пути и оба из них связаны с редактированием зоны DNS. Первый подразумевает под собой то, что вы создаете CNAME запись, в которой указываете, что, например, www.mydomain.com будет перенаправляться на mywinazure.cloudapp.net. Этот метод прост, но слишком уж прямолинеен. Если у вас на сервере размещено несколько веб-приложений, или же на основном домене может быть несколько субдоменов, то этот способ не сработает. Благо, что есть второй, более качественный способ.
В качестве решения, которым, кстати, воспользовался и я, предлагается редактирование A записи в зоне DNS. В панели управления виртуальной машиной, в области справа, вы могли заметить два IP адреса. Один называется приватным и является IP самой машины, а второй — публичный, виртуальный (Virtual IP, VIP). Вот именно его и надо указывать в зоне A для редактируемого домена. В данном случае весь трафик будет посылаться на вашу виртуальную машину, где IIS будет определять домен и выдавать соответствующее приложение (при условии правильной настройки Web Sites в самом IIS). Все просто и очевидно до неприличия, но именно так оно и работает.
Шаг 6. Бонус
В качестве бонуса я расскажу о примере интеграции одного сервиса Windows Azure с другим. Если вы читали предыдущую мою статью, то вы знаете, что в ней я описывал сервис фактов о программировании. В рамках той статьи я описал процесс публикации ASP.NET MVC 4 приложения в облако с использованием Windows Azure Web Sites и Windows Azure SQL Database. Сейчас же, при изучении Virtual Machines, я решил перенести этот же сервис из Web Sites на виртуальную машину, дабы иметь возможность привязать собственный домен, да и вообще иметь все в одном месте (сейчас в ВМ хостится несколько сайтов).
Файлы самого приложения я перенес безболезненно. Но когда я вспомнил о базе, то сначала немного опечалился. Я сразу представил себе, что мне придется сначала скачать дистрибутив, затем отвести под его установку некое место. Запустить службу БД на и без того не самой быстрой машине. Иметь БД и веб-приложение на одном сервере. Переносить данные с одного сервера на другой. Ну и еще несколько подобных неприятностей. Не сказать, чтобы это было прям так уж сложно, но, честно говоря, лениво.
И тут я подумал — а что если я натравлю приложение, размещенное в виртуальной машине, на БД, которая была создана в рамках хостинга сайта на Web Sites? Ведь с точки зрения приложения данная БД точно такая же, как если бы она была установлена на локальном сервере. Сказано — сделано. Я поменял web.config нужным образом, указав в качестве сервера БД тот самый сервер, который у меня существовал в Windows Azure. И что бы вы думали? Оно работает. Теперь у меня есть отдельный сервер приложений и отдельная база данных, которые можно независимо друг от друга замещать, расширять и зеркалить в случае необходимости. Спасибо Azure за такие приятности.
Заключение
На этой приятной ноте я хотел бы закончить рассказ. Надеюсь материал будет полезен начинающим исследователям Azure и поможет определиться с выбором хостинга для своих веб-проектов. На всякий случай хочу написть, что я никоим образом не связан с Microsoft и отражаю только свою личную точку зрения, без какой-либо рекламы.