Недавно я отправился в путешествие, чтобы научиться работать в React.js, и, хотя этот процесс сам по себе был интересным, я решил сделать еще один шаг вперед. Имея ограниченные знания, я обратился в Microsoft Azure, чтобы попытаться загрузить свое веб-приложение React на общедоступный веб-сайт.
Проблема, которую я обнаружил, заключалась в том, что, хотя в Интернете существуют учебные пособия (их много и на Medium!) по созданию хоста службы приложений Azure для приложений Node.js, мне не удалось найти ни одного, которое проходило бы через все необходимый шаг, чтобы запустить его. Обычно они опускали ключевые шаги в конце, чтобы вы могли перенести свой код в Azure, но было мало объяснений того, как его отображать. Мне потребовалось намного больше копания, чтобы, наконец, все встало на свои места. Здесь я представляю вам мой объединенный учебник — ваш сайт должен быть готов к работе в кратчайшие сроки.
Я предполагаю, что вы знаете, как перемещаться по Github, и уже загрузили свой код в собственный репозиторий. Вы также можете посетить мой репозиторий, чтобы увидеть, как я реализовал свой проект (вы найдете некоторый остаточный материал от тестирования всех инструкций ниже), а также мой сайт проекта.
Мы рассмотрим несколько различных методов для достижения одного и того же результата — ваше веб-приложение появится на общедоступном сайте. Я предлагаю прочитать все шаги один раз, а затем следовать шаг за шагом по мере создания развертывания, выбирая желаемый путь по пути.
Использование классического редактора
- Создайте свою учетную запись Azure, если вы еще этого не сделали. Затем создайте новый ресурс службы приложений. Выберите свою подписку и группу ресурсов, создав новую, если хотите. Введите имя своего экземпляра, выбрав Код в качестве параметра публикации, и выберите стек времени выполнения Node.js (поскольку мы создаем приложение React). Важно выбрать операционную систему, с которой вы готовы работать. В зависимости от того, выберете ли вы Linux или Windows, некоторые заключительные шаги будут отличаться. Выберите ближайший к вам регион и пока выберите тарифный план Бесплатный. Затем вы можете завершить процесс создания.
- Пока вы ожидаете развертывания, создайте учетную запись Azure DevOps, если вы еще этого не сделали. Вы захотите создать новый проект (возможно, оставьте его закрытым, если только вы не хотите, чтобы он был общедоступным). Или, если у вас много пайплайнов сборки в одном большом проекте, это тоже нормально — просто до тех пор, пока вы тщательно все отслеживаете.
- Вы увидите пункт меню Pipelines, а также пункт подменю под названием Pipelines. Откройте его и создайте новый конвейер. Здесь у вас есть два варианта: использовать редактор YAML для создания сценария конвейера или использовать классический редактор для создания конвейера вручную. Использование YAML создаст в вашем репозитории файл, содержащий информацию о сборке, который затем запускается всякий раз, когда происходит новая фиксация. Я собираюсь использовать классический редактор, который немного проще настроить и настроить. Если вы хотите использовать редактор YAML, см. отдельные инструкции ниже.
- Откройте классический редактор и выберите GitHub в качестве источника кода. Разрешите DevOps подключиться к вашей учетной записи Github. Используйте кнопку с многоточием (…), чтобы найти репозиторий, содержащий ваше приложение React, а затем выберите свою ветку.
- Когда будет предложено выбрать шаблон, начните с Пустого задания. Затем вам будет представлен редактор, в котором вы можете выбрать блоки для добавления в конвейер развертывания. Первый узел уже настроен для вас под названием «Получить исходники», который загружает код в репозиторий в качестве первого шага конвейера. Первое задание агента также загружено для вас, лишенное всякой жизни.
На момент написания этой статьи не существовало параметра по умолчанию для
развертывания Node.js в Веб-приложение Azure, отсюда и пустое задание. - Можно добавить три или четыре узла, в зависимости от того, какую ОС вы выбрали ранее; это будет объяснено позже. Щелкните значок плюса (+) рядом с элементом задания агента, чтобы добавить новый шаг. Появится меню с возможностью поиска — найдите «npm» и выберите самый простой вариант, опубликованный Microsoft. Затем элемент добавляется в вашу работу. Выберите его и измените, чтобы запустить команду «установить», игнорируя все остальные параметры.
- Добавьте второй элемент «npm». Выберите пользовательскую команду и введите «запустить сборку» в поле команды. Игнорируйте все остальные варианты.
- Добавьте элемент «Опубликовать артефакт». Вам нужно будет ввести два важных параметра: путь для публикации и имя артефакта. Внимательно следите за этими двумя. Я рекомендую «build» и «artifact» соответственно, хотя имя артефакта по умолчанию — «drop».
- Если вы выбрали хост Windows для службы приложений, вам потребуется предоставить файл web.config для настройки параметров маршрутизации для веб-сервера IIS. Убедитесь, что он создан с необходимыми параметрами (см. пример), и поместите его куда-нибудь в свой репозиторий — я оставил свой в папке /src. (Если вы выбрали хост Linux, вы можете пропустить этот шаг, но помните, что в конце необходимо выполнить последний шаг.) Добавьте элемент Копировать файлы непосредственно перед элементом Публикация артефакта, на третьей позиции. Вы можете оставить исходную папку пустой, если у вас есть файл конфигурации в корне; в противном случае укажите его родительский каталог. Введите web.config в поле содержимого и введите свой путь для публикации имени из шага 8 в целевую папку — опять же, сборка является рекомендуемым именем.
Загрузить пример web.config из CodeProject - Сохраните свой трубопровод! Если вы не сохраните его явным образом, ваша работа будет потеряна.
- На панели навигации перейдите в Pipelines › Releases. Теперь вы собираетесь настроить процесс выпуска для скомпилированного результата. Создайте новый конвейер выпуска (не новый выпуск!), и снова начните с пустого конвейера. В редакторе вы найдете два блока с надписью «Артефакты» и «Этапы» — сначала мы добавим артефакт. Добавьте артефакт и выберите Build в качестве типа источника. Вам нужно будет выбрать исходный конвейер сборки, который вы сохранили на шаге 10. Измените исходный псевдоним на что-то легко запоминающееся, например '_artifact' или 'pipeline- результат'. Сохранить это.
- Вернитесь к редактору релиза с двумя полями. Вы заметите, что в правом верхнем углу элемента артефакта есть молния. Щелкните его, чтобы открыть, и включите триггерный переключатель непрерывного развертывания. Это позволит вашему выпуску автоматически запускаться при завершении конвейера сборки. Игнорировать фильтры ветвей.
- Вернувшись в редактор релизов, откройте этап 1, щелкнув ссылку «1 задание, 0 задание». Вас встретит знакомый редактор пайплайнов. Добавьте элемент «Развертывание службы приложений Azure». Выберите свою подписку (подсказка, выберите подключение к услуге, а не фактическую подписку). Выберите тип службы приложений в зависимости от того, какую ОС вы выбрали ранее; Веб-приложение в Windows или Linux. Найдите в списке имя службы приложений. Если вы его не видите, убедитесь, что вы выбрали правильную ОС; подтвердите, что ваш фактический ресурс службы приложений в Azure имеет ОС, которую вы хотели использовать. Наконец, отредактируйте поле ввода пакета/папки. Поскольку вы еще не запустили конвейер, кнопка обзора не поможет. Вместо этого просто введите:
$(System.DefaultWorkingDirectory)/_artifact/artifact
(и замените два каталога в конце соответствующими именами вашего исходного псевдонима (шаг 11). ) и имя артефакта (шаг 8) соответственно). - Наконец, вернитесь к первому конвейеру сборки с шага 10. Теперь вы можете открыть его и запустить. Вы можете следить за тем, как задание агента 1 завершает установку ваших пакетов Node.js, создает производственную версию вашего веб-приложения и сохраняет все это в артефакт. Затем, если вы откроете конвейер выпуска, вы увидите, что он развернут в вашем ресурсе службы приложений Azure.
- Если вы вернетесь к ресурсу Службы приложений и посмотрите на Центр развертывания, вы увидите успешное развертывание из Azure Pipelines. Если вы выбрали основную ОС Windows, все готово к работе. Посещение вашего сайта покажет ваше приложение, и если вы реализуете маршрутизаторы React, при условии, что ваш web.config правильно настроен, ваше приложение React также может обрабатывать эти переходы.
- Если вы выбрали хост-систему Linux, посетить ваш сайт прямо сейчас не получится. Это потому, что вам все еще нужно настроить одну последнюю вещь; Хост Linux должен использовать pm2, диспетчер процессов для JavaScript. Вам нужно будет настроить его на запуск при каждом запуске контейнера. В ресурсе Службы приложений перейдите в раздел Конфигурация, Общие параметры и введите следующую команду запуска:
pm2 serve /home/site/wwwroot — no-daemon — spa
(замените длинные дефисы на пробел и два отдельных дефиса-тире.)
Это указывает хосту использовать правильный каталог в качестве корневого каталога вашего сайта, а флаг — spa указывает, что это одностраничное приложение, поэтому что маршрутизация автоматически направляется в ваш корневой файл index.html вместо фактического поиска несуществующего каталога. Сохраните это и перезапустите службу приложений. Теперь ваш сайт должен работать.
Использование редактора YAML
Если вы решили использовать редактор YAML вместо классического редактора, инструкции будут немного короче, но окончательная настройка будет немного сложнее. Хотя этот метод позволяет выполнить почти немедленную настройку, первоначальное развертывание занимает больше времени, его сложнее настроить позже, и вы ограничены хостом Linux (на данный момент).
- Продолжая с шага 3 классической настройки — выберите свой репозиторий и проект, и DevOps предложит вам выбрать конфигурацию конвейера. Вы можете воспользоваться ярлыком «Node.js React Web App to Linux on Azure», чтобы настроить большую часть того, что вам нужно. К сожалению, на момент написания статьи не было аналога для Windows, и не было простого способа изменить автоматически сгенерированный файл YAML для работы на хостах Windows. Выберите службу приложений, затем проверьте и настройте. Пока не завершайте процесс установки; есть несколько настроек, которые нужно изменить.
- Вы можете изменить версию стека на 12 или 14, если хотите; измените строку в конце документа с надписью «УЗЕЛ | 10.10» на желаемую версию, например «УЗЕЛ | 12-lts». Изучите команду запуска; стандартный не будет работать. Попытка перейти на страницу службы приложений прямо сейчас приведет к ошибке приложения, 502 или 404. Выберите любой (выберите только один!) из вариантов 3, 4 или 5, чтобы изменить свойство StartupCommand. и выберите способ подачи. Вариант 4 - моя рекомендация.
- Метод сборки разработки: измените его на ‘cd /home/site/wwwroot && npm run start’. По умолчанию будет пытаться запустить сервер разработки для размещения вашего кода, но он попытается сделать это из корневой папки, где package.json не существует. Добавление команды change-directory направит команду npm в нужное место.
Запуск на уровне бесплатного пользования займет значительное время, так как он перекомпилирует ваш код разработки в отладочный. включенный режим, поэтому будьте осторожны, ваш сайт может быть недоступен в течение нескольких минут. - Метод диспетчера процессов: измените его на 'pm2 serve /home/site/wwwroot/build — no-daemon — spa', снова заменив длинные дефисы пробелом и двумя дефисами. Этот метод, как и шаг 16 классической настройки, запускает веб-сервер, который обслуживает встроенную версию вашего приложения. Этот метод быстрый и предоставляет больше параметров во время развертывания, но требует более подробной команды.
- Метод Npx Serve: измените его на ‘cd /home/site/wwwroot/build && npx serve’. npx serve автоматически загружает и устанавливает пакет serve, если он не существует, а затем начинает обслуживать производственную сборку вашего приложения из каталога сборки. Однако, если вы создаете одностраничное приложение, вам нужно создать файл конфигурации, чтобы переписать пути обратно к основному приложению. Флаг -spa в pm2 является более простым подходом, поэтому рекомендуется использовать вариант 4 вместо варианта 5.
- Сохраните свой трубопровод! Это вставит файл YAML в ваш репозиторий в новом коммите, который затем будет использоваться для информирования будущих развертываний. После фиксации вы должны увидеть работающий конвейер — вы можете следить за ним, так как шаги сборки выполняются автоматически. Через несколько минут (или дольше, если вы выбрали вариант 3) вы сможете посетить свой сайт.
Как я уже упоминал ранее, все руководства, которые я нашел в Интернете до сих пор, выбирают только один из этих методов для описания и часто не объясняют последние шаги настройки для запуска и работы страницы. Надеюсь, приведенные здесь инструкции помогут вам преодолеть последние препятствия.
Если все пошло по плану, поздравляю! Ваше веб-приложение теперь общедоступно и связано с любыми новыми фиксациями, которые вы делаете в своем репозитории.
В качестве последнего совета вы можете изменить триггеры непрерывной интеграции, чтобы они игнорировали изменения в вашем файле README.md, конфигурации YAML и т. д., если вы того пожелаете. Если вы использовали классический редактор, просто отредактируйте конвейер и найдите пункт меню «Триггеры» рядом с «Задачи и переменные». Затем вы можете добавить исключения из фильтра пути, чтобы игнорировать файлы, которые не должны запускать автоматическую сборку и развертывание. Если вы использовали редактор YAML, отредактируйте конвейер и найдите кнопку с многоточием рядом с кнопками «Переменные» и «Выполнить» вверху. В подменю с многоточием вы найдете пункт меню «Триггеры» — переопределить триггер и аналогичным образом добавить исключения. Обязательно сохраните после добавления фильтров!
Если вам понравился этот урок и вы хотели бы узнать больше о моем опыте работы с React, посетите полную статью о CodeProject. Чтобы этот урок был кратким и содержательным, я решил опустить вопли и стоны, которые вы там найдете.
В любом случае берегите себя и будьте здоровы!
— g96b10
