6 способов деплоя веб-приложений
Деплой — это процесс развертывания веб-приложения или сайта в рабочей среде: на гостевом хостинге или сервере. Разбираемся, какие есть способы деплоя, в чем их преимущества и недостатки, а также какой из них выбрать в разных ситуациях.
Если вы еще не знаете, что такое деплой и как его проводить, сначала прочитайте наш гайд, а потом возвращайтесь к статье.
Повторное создание
Способ, при котором разработчик сначала отключает старую версию приложения (V1 на картинке), а затем развертывает новую версию (V2 на картинке). При этом в работе приложения возникает перерыв, длительность которого зависит от скорости отключения и повторного запуска.
- Простота
- Состояние приложения полностью обновляется.
- Пользователь не может использовать сервис во время простоя, длительность которого зависит от скорости проведения работ.
Последовательное развертывание
Разработчики постепенно заменяют экземпляры текущей версии приложения на экземпляры новой версии. Процедура выглядит следующим образом: балансировщик нагрузки распределяет трафик между серверами в пуле экземпляров версии V1. Потом развертывается один экземпляр версии V2. Когда новый экземпляр готов принимать трафик (пользователей, которые заходят в приложение), его включают в пул. Затем удаляют и отключают один экземпляр версии V1.
Чтобы увеличить время развертывания, можно изменять эти максимальные значения:
- Количество экземпляров, которые развертываются одновременно
- Увеличение количества экземпляров во время деплоя
- Количество экземпляров, недоступных во время последовательного развертывания.
- Простота
- Экземпляры приложения заменяются постепенно
- Удобно перераспределять данные приложений, сохраняющих информацию о запросах.
- Развертывание и откат к предыдущей версии занимают много времени
- Сложно реализовать поддержку нескольких API
- Отсутствует контроль за трафиком.
Освойте DevOps на интенсиве Хекслета Научитесь автоматизировать окружение, деплоить приложения одной кнопкой одновременно на любое количество машин и разворачивать облачный кластер на Digital Ocean или Yandex Cloud.
Сине-зеленый деплой
Сине-зеленый деплой означает, что синяя версия V2 развертывается параллельно зеленой версии V1 с одинаковым количеством экземпляров. Убедившись, что новая версия работает исправно, разработчики перенаправляют трафик от версии V1 к версии V2 с помощью балансировщика нагрузки.
- Моментальное развертывание и откат
- Так как приложение развертывается целиком, не возникают проблемы из-за одновременного использования двух версий.
- Высокая стоимость, так как для такого деплоя требуется вдвое больше ресурсов
- Перед развертыванием нужно тщательно протестировать платформу
- Сложно работать с приложениями, сохраняющими данные о запросах.
Канареечный релиз
Канареечный релиз позволяет постепенно перенаправить трафик от версии V1 к версии V2. Обычно трафик распределяется пропорционально: например, 90% запросов отправляется версии V1, а 10% — версии V2.
Этот метод используется, если тестов не хватает, или они не дают надежные результаты. Еще он подходит, когда разработчики не уверены в стабильности новой версии.
- Версия доступна части пользователей
- Удобно отслеживать коэффициент ошибок и работу новой версии
- Быстрый откат.
- Медленное развертывание.
A/B-тестирование
Пользователи, которые отвечают заранее определенным условиям, получают доступ к новым функциям. Этот метод похож на стратегию канареечного релиза, но отличается целями. A/B-тестирование — это не только стратегия деплоя, но и способ принятия бизнес-решений на основании статистики. Часто этот способ используется, чтобы оценить эффект изменения и определить, какая версия больше нравится пользователям.
Трафик может распределяться на основании следующих условий:
- Настройки файлов cookie
- Параметры запросов
- Геолокация
- Браузер, размер экрана, ОС и другие технические характеристики
- Язык.
- Параллельная работа нескольких версий
- Полный контроль над распределением трафика.
- Требуется умный балансировщик нагрузки
- Сложно устранять проблемы для конкретного сеанса
- Требуется трассировка распределенных систем.
Скрытое развертывание
Версия V2 развертывается параллельно версии V1. Она тоже получает входящие запросы, но не влияет на реальный трафик. Так можно протестировать нагрузку новой функции. Полный переход на новую версию происходит, когда приложение работает стабильно и отвечает требованиям.
Это сложная стратегия с дополнительными требованиями, которая использует исходящий трафик. Иногда из-за этого возникают ошибки: например, если интернет-магазин проводит скрытое тестирование платежного сервиса, клиент может случайно оплатить заказ дважды. Чтобы этого избежать, придется создать сервис, который имитирует ответ поставщика услуг.
- Работа приложения проверяется на основе реального трафика
- Пользователь не теряет доступ к приложению
- Приложение развертывается только тогда, когда оно отвечает всем требованиям заказчика.
- Высокая стоимость, так как требуется вдвое больше ресурсов
- Результаты могут вводить в заблуждение, поскольку полноценный пользовательский тест не проводится
- Сложность организации
- В некоторых случаях требуется сервис для имитации услуг.
Какую из стратегий деплоя использовать
Выбор стратегии деплоя зависит от потребностей и бюджета. Например, для развертывания на этапе разработки или в промежуточной среде подходит повторное создание или последовательный деплой. Для выпуска готовой версии приложения используется последовательное или сине-зеленое развертывание, но только после проведенного тщательного тестирования.
Сине-зеленое развертывание и скрытый деплой стоят дороже, так как требуют вдвое больше ресурсов. Если тестирование не проводится в нужном объеме, или есть сомнения в отношении функционирования и стабильности приложения, подойдет канареечный релиз, A/B-тестирование или скрытое развертывание. Чтобы протестировать новую функцию на группе пользователей, можно применить фильтр, используя такие параметры, как геолокация, язык, ОС или настройки браузера. Для этого применяют A/B-тестирование.
Скрытое развертывание — сложная и трудоемкая стратегия. Если приложение работает с внешними зависимостями и отправляет выходной трафик почтовым сервисам, банкам или другим партнерам, такие действия требуется имитировать. Однако эта стратегия полезна при переходе на новую базу данных и использовании теневого трафика для мониторинга работы под нагрузкой.
Эта статья — адаптированный перевод материала разработчика Этьена Тремеля, опубликованного в блоге The New Stack.
Бесплатные хостинги для веб-разработчиков
Одним из наиболее популярных направлений разработки сегодня является веб. И когда нужно разместить свой проект где-нибудь, кроме localhost, многие сталкиваются с трудностями, ведь хостинг должен быть быстрым, удобным и, желательно, бесплатным 🙂
В этом списке вы найдете 18 бесплатных сервисов, где легко сможете разместить свой проект и не заплатите ни копейки. Погнали!
Vercel
Данный сервис позволяет собирать и размещать статические веб-сайты на различных фреймворках (поддерживаются как JS-фреймворки, так и, например, генераторы статических сайтов — Hexo, Hugo, Jekyll и другие). Для каждого проекта выделяется несколько бесплатных доменных имен третьего уровня, есть возможность предпросмотра сборки.
Вот что включает в себя бесплатный тариф:
- 50 пользовательских доменов
- 100 Гб файлового пространства
- 100 Гб ежемесячного трафика
- Неограниченное количество проектов
- CLI-интерфейс
- Serverless, CDN, CI/CD
Develop. Preview. Ship. For the best frontend teams – Vercel
Netlify
Netlify — прямой конкурент Vercel. Однако, кроме функций, которые предоставляет предыдущий сервис, тут на бесплатном тарифе присутствует:
- Обработка до 100 отправленных форм в месяц
- До 1000 авторизованных пользователей в месяц
- Аналитика работы сайта
Netlify: All-in-one platform for automating modern web projects
Heroku
Heroku позволяет запускать Full Stack приложения в контейнерах (так называемых Dynos). Поддерживается большое число языков программирования и фреймворков. Главный недостаток — после получаса бездействия проекты, размещенные на бесплатном тарифе, «засыпают», а повторный запуск контейнера требует определенного времени.
На стартовом тарифе доступны:
- 550 часов/месяц работы Dynos (1000 после привязки банковской карты)
- 512 Мб ОЗУ на 1 контейнер
- CI/CD, CLI
- По 1 домену на 1 контейнер
Cloud Application Platform | Heroku
Stormkit
Stormkit позволяет размещать только проекты на JavaScript. Бесплатно доступны:
- 1 проект
- 50 Гб трафика
- Неограниченное количество доменов
- Неограниченное количество сборок
Serverless infrastructure for javascript applications
Hostman
Полноценный хостинг с поддержкой бэкенда и баз данных. Однако бесплатный тариф позволяет разместить до 10 веб-сайтов, и то статических:
- 100 Гб/месяц трафика
- Бесплатные домены и SSL
- CI/CD, CDN
Hostman — cloud platform that deploys and scales your web applications
Glitch
Glitch позиционирует себя как коллаборативный сервис для упрощенной разработки веб-сайтов. В основном здесь находятся проекты на NodeJS, но поддерживается ряд других языков. Приложения запускаются в контейнерах, как на Heroku, и тут так же доступно 1000 бесплатных часов работы приложений в месяц. Однако, если на Heroku проекты заливаются через CLI или Git, здесь присутствует браузерная IDE и терминал.
Glitch: The friendly community where everyone builds the web
Repl.it
Подобен предыдущему сервису. Бесплатно предоставляется 0.5 Гб ОЗУ и 0.5 Гб дискового пространства.
The collaborative browser based IDE
Surge
Хостинг статических сайтов. Бесплатно доступны:
- 1 сайт с 1 доменом третьего уровня
- Неограниченное количество сборок
Firebase
PaaS-сервис от Google, позволяющий разработать бэкенд без написания кода, а также разместить свой статический веб-сайт. Вот что входит в стартовый тариф:
- 10 Гб дискового пространства
- 360 Мб трафика/день
- Базы данных
- Serverless
- Тестирование
- Многое другое
Render
Сервис для размещения статических веб-сайтов. Бесплатно доступны:
- 100 Гб трафика в месяц
- CDN, CI/CD, SSL
Cloud Application Hosting for Developers | Render
GitHub Pages
С помощью этого инструмента из любого репозитория GitHub можно развернуть статический веб-сайт. Поддерживается Jekyll, доступен 1 бесплатный домен 3 уровня, SSL, неограниченный трафик.
GitHub Pages
begin
Хостинг для практически любых веб-приложений на NodeJS или Deno. Бесплатно доступно 5 веб-сайтов, поддерживается Serverless.
Deta
Достаточно интересный проект, предоставляющий возможность размещения веб-приложений на Python и NodeJS. К каждому приложению подключается NoSQL база данных. Главный минус — все взаимодействие с сервисом осуществляется через CLI. Бесплатно доступны:
- 2 Гб дискового пространства, 2 Гб на базу данных
- 50 000 обращений к контейнерам в месяц
- 25 000 обращений к БД в месяц
Deta – A Cloud for the next Billion Ideas.
Fly
Очередной сервис, позволяющий запускать приложения в виртуальных машинах. Со стартовым тарифом вы получите:
- 8 миллионов секунд работы VM в месяц (хватит примерно на 3 VM, запущенных постоянно)
- 160 Гб ежемесячного трафика
- 10 активных SSL-сертификатов
Deploy app servers close to your users · Fly
Fleek
Позволяет размещать статические сайты, перед этим собирая их на ряде генераторов статических сайтов (если нужного нет в списке, можно выбрать Docker-образ, в котором будет осуществляться сборка, и указать все данные для нее). Бесплатный тариф имеет следующие ограничения:
- 3 Гб дискового пространства
- 50 Гб ежемесячного трафика
- 250 минут на сборку в месяц
Fleek: Build. Preview. Deploy. Scale.
Microsoft Azure
У данного достаточно известного сервиса есть бесплатный тариф. На нем можно создать до 10 приложений на базе Azure App Service, а также получить некоторые дополнительные функции. Большинство из них будут работать лишь в первые 12 месяцев пробного периода, но часть предоставляется навсегда.
Create your Azure free account today | Microsoft Azure
Oracle Cloud
Oracle так же, как и Microsoft, предоставляет возможность испробовать функции на бесплатной основе. Навсегда предоставляются:
- 2 виртуальные машины с 1/8 vCPU и 1 Гб ОЗУ
- 2 виртуальных диска общим объемом до 100 Гб, до 5 резервных копий
- 10 Тб/месяц исходящего трафика
Try Oracle Cloud Free Tier
Digital Ocean App Platform
На стартовом тарифе можно разместить до 3 статических веб-сайтов:
- 1 Гб/мес ежемесячного трафика на 1 веб-сайт
- 100 минут/месяц на сборку
- CI/CD, CDN
App Platform
Заключение
На этом подборка бесплатных хостингов заканчивается. Надеюсь, вы уже нашли себе подходящий вариант и готовы разместить свое приложение.
Буду рад, если вы предложите свои варианты — достойные сервисы будут также внесены в этот список.
- Хостинг
- Веб-разработка
Deploy
Деплой (deploy) — это развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Разработчик загружает приложение, написанное на локальном компьютере, в специальное пространство, из которого оно доступно в интернете.
«IT-специалист с нуля» наш лучший курс для старта в IT
Когда сайт загружают на сервер или хостинг, говорят, что его деплоят или «выкатывают». Также процесс называют деплоингом (deploying). Еще есть выражение «отправка в продакшн» или «на прод» — оно описывает этот же процесс.
Продакшн (production) — запущенная версия сайта, та, которую видят пользователи. Так что отправка в продакшн — тоже деплой. Точнее, одна из его разновидностей, потому что разворачивать приложение могут не только для конечных пользователей, но и, например, на тестовом сервере.
Само английское слово deploy в переводе означает «развертывать».
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Для чего нужен деплой
Сайты не пишут непосредственно на серверах: всю работу программисты делают на собственных или рабочих компьютерах. Соответственно, когда приложение написано и протестировано, нужно доставить его на сервер, настроить и запустить там. Так его смогут увидеть пользователи интернета.
Без деплоя код не дойдет до сервера и так и останется на рабочей машине программиста. А писать прямо на сервере — очень плохая идея даже в теории: это сложно, неудобно и может его «уронить». Тем более часто рабочая среда — не один сервер, а сотни разных устройств, и процесс развертывания и запуска в продакшн довольно сложный.
Читайте также Востребованные IT-профессии 2023 года: на кого учиться онлайн
Что именно деплоят
Все, что работает в сети: веб-приложения, сайты, разные сервисы, в том числе те, которые не предназначены для внешнего использования. Даже если речь идет о каком-то локальном сервисе, работающем только во внутренней сети компании, его тоже нужно задеплоить, чтобы он стал доступен в этой сети.
Деплоят не обязательно приложение целиком. Чаще, если речь идет о процессах в коммерческой разработке, различные новые функции и доработки пишут разные программисты. По мере готовности отдельные завершенные части деплоятся. Это удобнее. А разработка распределенных приложений со множеством отдельных частей вообще выглядит как множество независимых деплоев.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Как выглядит жизненный цикл кода
Чтобы лучше понимать, как все происходит и какую роль играет деплой, простыми словами расскажем о процессе разработки в IT-компаниях.
1. Разработчик пишет код. Это может быть принципиально новый сервис или доработка к уже существующему, обновление сайта или что-то еще. Он делает это на локальном компьютере.
2. Когда код готов, разработчик коммитит его: загружает в репозиторий, специальную «общую папку» команды, например на сервисе GitHub. Там его смогут увидеть и прокомментировать другие разработчики — это называется код-ревью.
3. В определенный момент — по расписанию или после успешного коммита, который одобрили другие, — команда решает, что код нужно отправить в продакшн.
4. Создается релиз, публикуется своеобразное сообщение о будущем деплое: код в репозитории маркируется специальным тегом. Это нужно, чтобы избежать случайной отправки в продакшн каких-то изменений, которые внесли в репозиторий уже после сообщения о будущем деплое.
5. В нужное время происходит деплой. Код уходит в продакшн, появляется на серверах, его видят пользователи.
Что входит в деплой
Это зависит от того, что именно развертывают и какими инструментами при этом пользуются. Если речь о простом статическом сайте, где нет сложного бэкенда, достаточно загрузить новые файлы на сервер, обновить старые файлы, подключить зависимости и «собрать» проект. То же самое касается изменений, которые затрагивают только фронтенд — внешнюю часть, которую видит пользователь.
Если же обновляется бэкенд, или серверная часть сайта, все куда сложнее. Нужно как минимум подключить к коду базу данных и соединить составные части приложения друг с другом. Иногда этот процесс бывает довольно долгим.
Когда все готово, новую версию запускают, а старую останавливают. Тут есть свои хитрости, которые позволяют избегать простоев сайта в этот период, но ими пользуются не все. Мы поговорим о них позже.
Деплоймент пошагово: как это выглядит
Вот как примерно выглядит процесс:
- отправка кода на сервер — файлы «приходят» в рабочую среду, чаще всего через Git;
- настройка зависимостей — старые файлы обновляются, в них прописываются связи с новыми частями кода, нововведения интегрируются в структуру;
- сборка — все файлы «собираются» в единый проект, в систему, которая может функционировать;
- миграции — выполнение специальных скриптов для базы данных, которые «готовят» ее к нововведениям, обновляют и настраивают структуру;
- запуск — старая версия останавливается, задеплоенная запускается. После этого приложение начинает работать с новыми функциями.
Автоматизация деплоя
Делать все перечисленное вручную — долгий процесс, который отнимает у программиста время и силы, увеличивает риск ошибки и уровень стресса в команде. В перспективе ручной деплой еще и ухудшает продуктивность: увеличивается срок до выхода в продакшн, сервис развивается медленнее, нововведения выкатывают реже.
Поэтому деплоймент обычно автоматизируют. Сделать это можно несколькими способами, какой выбрать — зависит от стека технологий, бюджета и масштаба проекта:
- с помощью надстроек и утилит, написанных для конкретных языков или библиотек;
- через системы автоматизации и управления, такие как Ansible, или через облачные сервисы для веб-приложений вроде Heroku;
- с помощью оркестраторов, платформ, которые управляют контейнерами, — самым известным примером считается Kubernetes.
Сборка и запуск тоже автоматизируются, уже с помощью других инструментов.
Уровень автоматизации может быть очень разным, вплоть до систем непрерывной доставки, при которой деплой полностью автоматический и не требует участия разработчика.
Избежание простоя: что такое подход Zero Downtime
Выше мы говорили, что в классическом варианте старая версия отключается, а новая запускается и, пока это происходит, сайт простаивает. Посетители не могут им пользоваться. Для крупных проектов деплой занимает много времени, и такой простой критичен, особенно если сайт коммерческий. Поэтому есть способы, позволяющие его не допустить.
При использовании подхода Zero Downtime Deployment сайт не останавливается. Это происходит, потому что в таком случае сначала запускается новая версия, а потом отключается старая.
Звучит просто, но на деле намного сложнее: во избежание ошибок и конфликтов нужно, чтобы старая и новая версия были единообразно написаны, а база данных была совместима с обеими одновременно. Кроме того, понадобятся автоматические системы, которые будут проверять запуск новой версии и переключать трафик на нее. Сам процесс усложняется.
Из-за высоких требований к инфраструктуре таким подходом обычно пользуются большие проекты, у которых есть ресурсы для его реализации.
Как начать деплоить
Проще всего пользоваться сервисами вроде Heroku: бесплатный план ограничен, но поможет разобраться. Если вы хотите потренироваться, можете воспользоваться хостингами: они обычно предлагают решения для настройки окружения, но за них придется платить.
В коммерческих проектах новички обычно не занимаются деплоем — это довольно ответственная задача. В больших компаниях за развертывание отвечает DevOps-инженер, но если проект маленький, эта задача может лечь на бэкендера, тимлида или другого специалиста.
Узнайте больше о процессе разработки на курсах — мы поможем разобраться с нужными технологиями и начать работать по новой специальности.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
Как деплоить приложение на Railway. Гайд для фронтендеров и бэкендеров
Важное предисловие — в этом гайде рассматривается способ деплоя с помощью GitHub, поэтому у вас должен быть свой аккаунт на Railway и на GitHub. Для полноценного понимания текста вы должны уметь работать с Git и знать, как устроен Node.js. Если пока нет — вот наш большой бесплатный курс по Git и профессия Node.js-разработчик. Гайд будет полезен бэкенд и фронтенд-разработчикам — в процессе мы создадим небольшое hello-world приложение. Подробно код нашего приложения можно изучить здесь .
Создание приложения
В качестве примера создадим приложение на фреймворке Fastify . Если вы фронтенд-разработчик и не собираетесь делать бэкенд-приложение, не расстраивайтесь. Дальше я расскажу, как подключить SPA-приложение на React и правильно настроить деплой. Просто следуйте инструкциям.
Для создания приложения на Fastify используйте команду:
Если утилита запрашивает установку дополнительных пакетов, согласитесь — введите y :
Утилита сгенерирует файлы. После этого установите зависимости:
install Проверьте, что приложение работает. Для этого его нужно запустить:
Перейдите по адресу сервера. В случае чего, приложение подскажет нужный адрес:
Теперь все готово для деплоя на Railway.
Первый деплой
Есть несколько способов деплоя: с помощью cli-утилиты и через GitHub. В нашем гайде я расскажу про второй способ.
Создайте репозиторий на GitHub и запушьте туда наше приложение. После этого зайдите в свой аккаунт на Railway и нажмите «Start a New Project». Дальше нужно выбрать «Deploy from Github repo».
Выберите нужный репозиторий с приложением, для этого можно воспользоваться поиском.
Нажмите «Deploy now». Через некоторое время приложение соберется и запустится, а в окне появится статус успешности деплоя.
Дальше нужно перейти на него, а после этого нажать «Deploy logs». В случае успешного выполнения вы должны увидеть логи работы приложения.
Приложение работает, но еще не доступно для внешнего мира. Нужно его привязать к определенному адресу. Закройте окно деплоя и вернитесь в проект, зайдите в настройки (1) и нажмите «Generate Domain» (2).
Появится адрес, по которому нужно будет перейти и дождаться, когда приложение запустится и выведет результат: .
Поздравляю, проект задеплоен и уже можно звать гостей!
Деплой React-приложения
Теперь немного усложним проект, добавим в него SPA-приложение на React. Для этого в директории проекта выполните команду:
Она создаст приложение на React в директории my-app в корне нашего проекта. Имя приложения my-app можно будет заменить на любое другое.
Проверьте, что приложение работает. Для этого перейдите в директорию и запустите React-приложение:
После старта откроется страница в браузере с адресом приложения, по умолчанию это http://localhost:3000 . Проверьте, что вы остановили Fastify-проект, который мы создали ранее, чтобы он не занимал порт. Вы должны увидеть логотип React.
Приложение на React имеет особенность: его нужно собирать. Команда npm start запускает Webpack-сервер, который предназначен для разработки, но не для полноценной работы. Об этом пишет само приложение после запуска:
Чтобы собрать приложение, выполните команду сборки в директории my-app :
После этого появится директория build — это и есть наше собранное React-приложение, подготовленное для работы на проде. Билд не включает в себя вебпак-сервер, поэтому нам нужен какой-то другой сервер, который будет предоставлять клиентам веб-приложение. Этим сервером будет наше приложение на Fastify, которое мы до этого уже создали.
Нужно немного доработать наше Fastify-приложение, чтобы оно умело раздавать фронт. Перейдите в корень проекта, все команды ниже будут выполняться в этой директории.
Для работы со статикой (билдом React-приложения), установите библиотеку:
Отредактируйте файл app.js . В него нужно импортировать установленную библиотеку:
const fastifyStatic = require('@fastify/static'); И добавьте внутри функции подключение нашего React-приложения:
fastify.register(fastifyStatic, root: `$process.cwd()>/my-app/build`, >); Добавьте обработчик по умолчанию, чтобы он возвращал html-страницу:
fastify.setNotFoundHandler((req, res) => res.sendFile('index.html'); >); Это даст возможность открывать React-приложение при любых несуществующих роутах. Полный код файла должен получиться таким:
'use strict' const path = require('path') const AutoLoad = require('@fastify/autoload') const fastifyStatic = require('@fastify/static'); module.exports = async function (fastify, opts) // Place here your custom code! fastify.register(fastifyStatic, root: `$process.cwd()>/my-app/build`, >); fastify.setNotFoundHandler((req, res) => res.sendFile('index.html'); >); // Do not touch the following lines // This loads all plugins defined in plugins // those should be support plugins that are reused // through your application fastify.register(AutoLoad, dir: path.join(__dirname, 'plugins'), options: Object.assign(<>, opts) >); // This loads all plugins defined in routes // define your routes in one of these fastify.register(AutoLoad, dir: path.join(__dirname, 'routes'), options: Object.assign(<>, opts) >); > Код написан с использованием commonJS-модулей. Вы можете переделать код на ES-модули, либо оставить его как есть. Не переживайте, если что-то в коде не понятно. Основная работа уже позади.
Проверьте, что ваше приложение на React остановлено — оно может занимать порт, который нам еще понадобится. Запустите приложение Fastify и откройте его в браузере, добавив к адресу любой путь, например — http://localhost:3000/somepath . Если вы видите приложение на React, то все получилось.
Запушьте изменения в GitHub. На Railway сразу начнется автоматическая сборка приложения — вам нужно перейти в ваш проект и проверить его работу. Вы увидите, что приложение работает, но страница React недоступна. Так происходит, потому что директория build не попадает в репозиторий, а Railway не выполняет билд. В сервисе выполняются стандартные команды для запуска приложения.
Если мы склонируем проект в новую директорию и выполним npm ci , а затем npm start , то приложение на React тоже не будет работать. Это произойдет и с Railway. Перед запуском должно собираться React-приложение. Для решения этой проблемы можно модифицировать package.json . Нужно добавить в него установку зависимостей React-приложения, для этого добавьте в секцию scripts еще одну команду:
Эта команда будет устанавливать зависимости в директории my-app при каждой установке зависимостей в корневом проекте.
Аналогично нужно добавить команду сборки фронтенд приложения:
Либо это можно сделать через настройки проекта Railway. Не забудьте при этом нажать на кнопку (2):
Теперь Railway будет устанавливать зависимости в my-app и делать сборку перед запуском приложения. Запушьте ваши изменения, проверьте работу, проверьте страницу на React.
Если что-то пошло не так, проверьте логи. Если вы правильно указали postinstall , то в логах вы должны видеть запуск установки зависимостей:
Если вы только изучаете программирование и у вас на Railway есть бесплатный аккаунт, рекомендую удалять каждый деплой, чтобы ваше приложение не тратило ресурсы. Изначально вам доступно ограниченное количество ресурсов на сервисе, а если ваши приложения превысят лимит, то придется брать платный тариф или ждать начало нового месяца. То есть каждый месяц лимиты, которые тратит пользователь, сбрасываются, но в таком случае придется ждать.
Готовый проект для деплоя находится здесь .
На Хекслете запускается набор первого онлайн-буткемпа: Всю программу первого онлайн-буткемпа от Хекслета по профессии «Фронтенд-разработчик» можно посмотреть здесь