STOP Using Vercel for Everything

Большинство разработчиков больше не создают приложения. Вместо этого они собирают подписки, размещая здесь базу данных, их радиус где-то еще, мониторинг хранилища. Я полагаю, поздравляю, ваше простое приложение теперь зависит от семи различных сервисов и ежемесячного счета с эмоциональным ущербом. Эмоциональный ущерб. И самое худшее, вы даже не контролируете это. Если один провайдер выходит из строя, ваше все приложение выходит из строя вместе с ним. Так что давайте это исправим. В этом видео мы возьмем один единственный VPS и запустим на нем все. полноценное Next.js приложение, базу данных PostgreSQL, Redis для кэширования и фоновых задач, мониторинг с помощью Uptime Kuma и, конечно же, надлежащий обратный прокси с HTTPS и реальным доменом. Таким образом, вместо того, чтобы платить за шесть или семь различных сервисов, вы сможете запускать весь свой стек на одной машине примерно за 7 долларов в месяц. Да. Не 70, не 700, а всего семь. И самое лучшее во всем этом то, что вы не будете зависеть от каких-либо внешних сервисов. Никаких неожиданных счетов, только полный контроль. Звучит интересно. Ну, давайте начнем. Хорошо. Итак, прежде чем мы углубимся в архитектуру, настроим наш VPS, установим Docker, создадим все контейнеры для наших сервисов, я хочу сначала упомянуть одну очень важную вещь, и это то, что сторонние управляемые сервисы в целом не являются плохой вещью, потому что есть одна вещь, которую они делают очень, очень хорошо, и это абстрагирование сложности от вас. И это абстрагирование сложности создает легкий путь для доставки ваших функций, ваших функций, вашего приложения, вашего проекта, чего угодно. Но дело в том, что это удобство, которое вы получаете, своего рода обоюдоострый меч. Что я имею в виду под этим? Ну, дело в том, что когда ваше приложение становится успешным и фактически сталкивается с реальной нагрузкой, реальными пользователями и, следовательно, с реальной сложностью, легкий путь, настроенный для вас, больше не будет работать. И легкий путь, сторонний управляемый сервис будет активно бороться против вас. Или, другими словами, вы будете бороться против него. Но есть еще одна вещь, стоимость. Потому что вот в чем дело. Что замечательного в большинстве сторонних управляемых сервисов? Ну, они также заманивают вас бесплатным уровнем, но как только ваше приложение действительно добьется успеха и, следовательно, столкнется с пользователями, этот бесплатный уровень ИСЧЕЗНЕТ. НЕТ. БОЖЕ, ПОЖАЛУЙСТА, НЕТ. НЕТ. И ВМЕСТО ТОГО, ЧТОБЫ СЕЙЧАС платить ноль, вам придется довольно быстро опустошить свой кошелек, как я уже делал довольно часто в прошлом, и платить за удобство. Это означает, что удобство довольно быстро превратится в зависимость. И эта зависимость равна довольно большому риску. Теперь позвольте мне привести реальный пример. Это мое приложение, мой веб-сайт syntaxpath. Я создал его около 3 лет назад, когда запустил свой YouTube-канал. Я уже много раз менял его брендинг, но фундаментальный стек не изменился. И теперь, почему я вам это говорю? Ну, когда я создал этот веб-сайт, у меня было около 2000 подписчиков и, возможно, 100 или 200 активных посетителей в месяц. Веб-сайт не имел никакой связанной с ним сложности, и реальной нагрузки не было. Итак, что я сделал? Ну, я использовал сторонние управляемые сервисы, потому что они предоставляли мне легкий путь. И теперь, давайте перенесемся в 2026 год. Мой YouTube-канал значительно вырос. Веб-сайт, этот веб-сайт значительно вырос, и вместе с ним также выросло использование, а также сложность, связанная с этим приложением, значительно выросла, а удобство, которое я выбрал 3 года назад, теперь превратилось в реальный риск и реальную зависимость, потому что тогда, давайте поговорим о хостинге. Я выбрал Vercel. Vercel имеет очень хороший бесплатный уровень, и они являются создателями Next.js. Так что определенно хорошая идея, верно, использовать Vercel. Да, в начале это было здорово. Я мог просто загрузить свое приложение. Я мгновенно получил HTTPS, кэширование. У меня был CDN перед моим приложением, оптимизация изображений. Все было отлично. Но вот в чем дело. Как только мое приложение, как только мой веб-сайт масштабировался, я больше не мог использовать бесплатный уровень, потому что Vercel запрещает вам заниматься какой-либо коммерческой деятельностью на бесплатном уровне. Это означает, что мне пришлось перейти на профессиональный уровень. Не большая проблема, верно? Я имею в виду, сколько стоит Vercel? Давайте посмотрим. 20 долларов в месяц. Это не проблема, верно? Ну, использование росло довольно быстро. Вместо того, чтобы платить 20 долларов в месяц, это стало 30 долларов в месяц, затем 40 долларов в месяц, 50 долларов в месяц, и в какой-то момент я платил 120 долларов в месяц за относительно простые приложения. Теперь вы можете сказать, что это проблема масштабирования, и, возможно, это тоже правда, но я не единственный, кто получает большие счета. Я имею в виду, посмотрите на этот скриншот. 666 долларов за минуты сборки. Это довольно много. Так вот, что я пытаюсь сказать здесь. Vercel не плох. Это отличный сервис, но в какой-то момент удобство настигнет вас, и вы почувствуете это довольно сильно в своем кармане. И это также именно та причина, по которой я сам стал большим поклонником делать все самостоятельно, самостоятельно размещать все. Потому что да, я больше не получаю удобства, но в то же время я все еще получаю полный контроль. Я не завишу от какого-либо стороннего сервиса. Я завишу только от себя, что также означает, что я экономлю довольно много денег. Но у этого снова есть свои плюсы и минусы, потому что давайте посмотрим на эту диаграмму. Сложность по оси Y, стоимость и ограничения по оси X. Теперь для управляемых платформ все довольно просто. Стоимость и сложность в начале практически равны нулю. Вы можете начать с Vercel бесплатно, и сложности нет. Но как только ваше приложение растет по сложности, использованию, нагрузке и т. д., все идет довольно параболически довольно быстро. стоимость настигнет вас, а удобство, которое у вас было в начале, практически испарится. Теперь давайте посмотрим на сторону VPS. Самостоятельное размещение. Теперь это не так просто. В начале вы сразу же столкнетесь со стоимостью. VPS-машины не бесплатны. Вам придется платить что-то вроде 5 долларов в месяц, 6 долларов в месяц, но это будет определенно ниже, чем любой другой профессиональный уровень от любого другого конкурента. И сложность также несколько выше. Но это все еще управляемо. Как только ваше приложение растет по использованию, нагрузке, сложности, вы увидите, что сложность будет расти, стоимость будет расти, но это не будет параболическим. И в какой-то момент стоимость также выровняется, и сложность также выровняется. А теперь посмотрите на эти две диаграммы. Что выглядит более интересным, управляемые платформы или самостоятельное размещение? Потому что да, опять же, с управляемыми платформами начало очень крутое. Вы получаете легкий путь, но все настигнет вас довольно быстро. С самостоятельным размещением, да, это сложнее. Есть начальная стоимость, но в долгосрочной перспективе вы будете благодарны за то, что приняли решение инвестировать время и деньги, чтобы создать свою собственную систему, которая работает и на которую вы можете полагаться. Итак, теперь вы можете сказать: хорошо, Джен, знаешь что? Ты меня убедил. Я готов самостоятельно разместить весь свой стек. Next.js, PostgreSQL, Redis, возможно, какой-то сервис мониторинга доступности, все это. И опять же, преимущества очень ясны. Во-первых, вы сэкономите много денег. Вы также избежите многих проблем и головной боли в долгосрочной перспективе. И самое главное, вы будете владеть своей собственной инфраструктурой, что является огромным преимуществом. Но как теперь начать? Следует ли вам сначала купить VPS, и какой VPS вам вообще нужен, или, возможно, сначала настроить Docker, или, возможно, Redis, или, возможно, ваше решение для мониторинга доступности, с чего нам начать? Ну, прежде чем мы что-либо сделаем и что-либо настроим, мы должны сначала понять, как будет выглядеть целевая архитектура и как она должна выглядеть, потому что мы хотим сделать все правильно и профессионально. Итак, вот очень хорошая диаграмма, которая объясняет, как будет выглядеть наша целевая архитектура. Все начинается с пользователя, посетителя. Это человек, посещающий сайт в своем браузере. Затем все маршрутизируется через ваш домен. Так что это удобный для человека адрес, который направляет трафик на VPS, потому что, опять же, теоретически вы также можете посетить веб-сайт, используя VPS. Но это означает, что это просто числа. Это нехорошо. Вы всегда хотите использовать красивый домен, например, syntaxpath.com или что-то в этом роде. Как только запрос маршрутизируется через домен или, другими словами, DNS, наш VPS получает удар. И опять же, что такое VPS? Ну, я думаю, спросите ChatGPT. Нет, я шучу. VPS по сути является просто машиной с процессором, небольшим объемом оперативной памяти, небольшим объемом хранилища и подключением к Интернету. Вот и все. Это очень просто. И в этом случае VPS действует как единственный сервер, на котором работает весь самостоятельно размещенный стек, одна машина, которая затем будет размещать все. Опять же, Next.js, Redis, наше решение для мониторинга доступности, PostgreSQL и тому подобное. Затем следующая важная, можно сказать, область — это наш обратный прокси. Обратный прокси очень важен. Так что это, по сути, входная дверь. Он принимает входящий веб-трафик, обрабатывает HTTPS и перенаправляет запросы в правильный внутренний сервис. Как вы видите здесь, настройка обратного прокси очень важна и необходима, потому что вы всегда хотите иметь HTTPS. Это очень важно для безопасности, и вы также хотите перенаправлять запросы в правильный внутренний сервис. Так что либо в ваше приложение Next.js, либо в ваше решение для мониторинга доступности. Затем в качестве следующего шага у нас будет само приложение. Так что Next.js, это фактическое веб-приложение, с которым взаимодействуют пользователи. Затем у нас есть наше решение для мониторинга доступности. Мы будем использовать Uptime Kuma для этого, и это отдельный сервис для проверки работоспособности, мониторинга и страницы состояния. Опять же, очень круто. Есть много сторонних управляемых решений для этого, которые очень, очень дороги. Но поскольку мы будем размещать все на нашем собственном VPS, на нашей собственной машине, мы можем самостоятельно размещать наше решение для мониторинга, что означает, что мы можем сэкономить много денег. Затем в качестве следующего шага мы также будем самостоятельно размещать PostgreSQL. Нашему приложению нужна база данных. Затем в качестве следующего шага мы также будем размещать нашу базу данных PostgreSQL, и она напрямую связана с нашим приложением. Так что это будет основная база данных для постоянных данных приложения, потому что наше приложение, например, может иметь включенную аутентификацию или что-либо, что требует постоянных данных. Затем мы также реализуем или разместим этот слой миграции. Так что одноразовая задача развертывания, которая обновляет схему базы данных до или во время развертывания. Затем мы также будем самостоятельно размещать Redis, и он будет напрямую связан с нашим приложением, и это небольшое быстрое хранилище данных, используемое здесь для ограничения скорости запросов, другими словами, ограничения скорости. И тогда мы, конечно же, также реализуем постоянные тома. Это очень важно. Но что такое постоянные тома? Ну, по сути, тома — это управляемое Docker хранилище, которое сохраняет важные данные, даже если контейнеры перезапускаются или пересоздаются, потому что вы никогда не хотите терять данные. Поверьте мне, я уже много раз совершал эту ошибку. Постоянные тома важны, и поскольку мы будем использовать Docker, их реализация также будет довольно простой. Итак, теперь вы можете сказать: хорошо, Чан, это имеет смысл. Так что на высоком уровне нам нужен домен, потому что мы хотим представить пользователю удобный для человека адрес, а не просто какой-то IP-адрес VPS. Затем, в качестве второго шага, нам нужен сам VPS. И VPS — это, по сути, самая важная вещь во всей этой архитектуре. Если ваш VPS плох, если он небезопасен, если он недостаточно мощный, то все это потерпит неудачу. Вам нужен хороший VPS с хорошей мощностью для поддержки этой архитектуры. Затем нам нужен обратный прокси. Нам нужно маршрутизировать трафик в правильный сервис, сохраняя все безопасным и быстрым. Как только это будет сделано, мы сможем сделать практически все. Мы можем самостоятельно разместить все необходимые нам сервисы. Наше приложение, PostgreSQL, Redis, мониторинг, и все эти сервисы будут работать на одной машине VPS, но в отдельных контейнерах. Это означает, что вы по-прежнему получаете безопасность, можно сказать, независимость, но вы получаете преимущество от того, что вам не нужно делать круговой маршрут сервера, потому что все делается в самом VPS, что является огромным преимуществом. И опять же, наконец, постоянные тома важны для бесперебойной работы всего, даже если вы перезагрузите свой VPS или обновите его или что-то в этом роде. Теперь, чтобы достичь всего этого, не хватает еще одной вещи, и это Docker. Docker очень важен для всей этой настройки и для этой целевой архитектуры, потому что Docker будет, по сути, нашей основой. Теперь я не уверен, знаете ли вы, что такое Docker, и мы углубимся в Docker немного позже более подробно, но вкратце, Docker — это уровень упаковки и выполнения для наших развертываний. Он позволяет нам доставлять наши приложения и сервисы в изолированных и повторяемых средах, потому что опять же, вы хотите иметь согласованные среды, которые безопасны и в то же время изолированы. Так что да, мы будем использовать один VPS, как вы видите здесь, и все будет работать на одном VPS, но каждый сервис будет изолирован в своем собственном Docker-контейнере. Итак, теперь вы можете сказать: хорошо, Ян, круто. Так как же нам теперь начать? Ну, опять же, глядя на эту диаграмму архитектуры, все начинается с пользователя. Ну, у нас уже есть пользователь. Вы — пользователь. Я — пользователь. Так что мы можем пропустить этот шаг. Следующий шаг — настроить домен. Но прежде чем мы настроим домен, нам нужен VPS. Но что вообще делает хороший VPS или, другими словами, провайдер VPS? Ну, как вы видите здесь, довольно много вещей. Во-первых, высокая производительность. Вы не хотите, чтобы ваши размещенные приложения были медленными, а скорее очень быстрыми. И вы можете достичь этого только в том случае, если ваш VPS использует высококачественное оборудование, хранилище NVMe, очень производительный чип, процессор. Все это важно для достижения высокой производительности и, следовательно, очень быстрых приложений. Во-вторых, масштабируемость. Вы должны иметь возможность выбирать самостоятельно, когда обновлять или, другими словами, понижать уровень. Вы хотите иметь возможность обновлять свое оборудование по требованию. Если, например, использование резко возрастает или, другими словами, падает. Это то, что предлагает не каждый провайдер, и, поверьте мне, вам нужен масштабируемый провайдер, если ваше приложение взлетает до небес. В-третьих, безопасность, и вам нужен провайдер, который активно инвестирует в безопасность. Вы не хотите, чтобы вас взломали. Поверьте мне, у меня уже было довольно много опыта с этим. Вы также хотите получать автоматические резервные копии, если это возможно. Теперь, вот честная правда. Большинство провайдеров взимают плату за автоматические резервные копии. Но через секунду я покажу вам провайдера, который предлагает еженедельные автоматические резервные копии бесплатно. О боже. Что вам еще нужно, это гибкость в выборе операционной системы. Есть определенные провайдеры, которые запирают вас, например, в Ubuntu или Debian, но вам нужна возможность выбирать то, что подходит вам и вашим потребностям в инфраструктуре. Также вам нужен полный root-доступ, потому что опять же, мы хотим владеть нашей инфраструктурой. Мы хотим настраивать нашу инфраструктуру, и это возможно только в том случае, если вы получите полный root-доступ. И, наконец, и, вероятно, один из самых важных аспектов — это очень хорошее соотношение цены и качества. Потому что что такое хороший VPS, если цена очень, очень дорогая? Что вы хотите иметь, это золотая середина. Хороший VPS, очень хороший VPS, при этом имея очень хорошую цену, не слишком низкую, не слишком высокую, золотую середину. И именно поэтому я бы рекомендовал вам использовать Hostinger. Hostinger — ведущий провайдер VPS на рынке. Я сам пользуюсь ими уже более пяти лет, и, поверьте мне, они лучшие на рынке. И причина этого довольно проста. Ну, на самом деле есть несколько причин. Во-первых, из коробки вы получаете процессоры AMD EPYC, хранилище NVMe SSD. Опять же, высококачественное оборудование и бесплатные еженедельные резервные копии. Это то, что я упомянул в нашем контрольном списке. Большинство провайдеров взимают плату за автоматические резервные копии, но Hostinger делает это бесплатно, и вы даже получаете 30-дневную гарантию возврата денег. Но теперь, какой план VPS мы должны выбрать? KVM1, KVM2, KVM4, KVM8. Хм. Что лучше всего подходит для наших нужд? Ну, на мой взгляд, моя рекомендация — всегда начинать с KVM2. И причина этого довольно проста. Вы получаете лучший баланс. Вы получаете много высококачественного оборудования за очень, очень хорошую цену. Это идеальная отправная точка. И этого будет достаточно даже для вывода в продакшн. Но давайте посмотрим на детали. Вы получаете два виртуальных ядра процессора, 8 ГБ оперативной памяти, 100 ГБ дискового пространства NVMe и 8 ТБ пропускной способности. Опять же, как вы видите здесь, этого более чем достаточно для нашего случая использования, но также и для реального производственного случая использования с реальной нагрузкой. Но хорошо, что еще мы получаем с Hostinger? Хороший вопрос. С каждым планом, независимо от того, что вы используете, вы всегда получаете процессор AMD EPYC, NVMe, хранилище SSD, центры обработки данных по всему миру. Неважно, где вы находитесь или где вы хотите разместить свой VPS. Через секунду я размещу свой VPS в Литве, но вы также можете выбрать Германию, США, это не имеет значения. Также вы получаете бесплатные еженедельные резервные копии, управление брандмауэром, скорость сети 1 Гбит/с. Это очень важно. Опять же, мы хотим, чтобы у вас был производительный VPS, и именно это мы получаем с Hostinger. И вы даже получаете общедоступный API, AI-ассистента и бесплатный домен на 1 год. Так что, как вы видите здесь, Hostinger — это не шутка. Это лучший провайдер на рынке. Как уже упоминалось, я пользуюсь Hostinger уже несколько лет, и я очень довольный клиент. И что мне также нравится, так это интеграция с ИИ. Иногда я сам не знаю всех ответов. И Коди, встроенный AI-ассистент, всегда помогает мне, когда у меня возникают какие-либо вопросы. И если вы сейчас перейдете по ссылке в описании моего YouTube-канала и нажмете на первую ссылку, вы будете перенаправлены на Hostinger, и моя волшебная ссылка даст вам скидку 10%. Да, вы правильно расслышали, только для вас. И в зависимости от того, когда вы смотрите это видео, Hostinger также может проводить распродажу для вас. Например, прямо сейчас план KVM2 со скидкой 63%, что является отличным предложением. И теперь, без дальнейших церемоний, давайте наконец начнем. Итак, я нажму на волшебную кнопку "Выбрать план". И теперь мы будем перенаправлены. И прежде чем вы выберете что-либо, я хочу, чтобы вы нажали на эту кнопку "Есть промокод" и ввели Jan Marshall полностью заглавными буквами. И если вы нажмете "Применить", вы увидите здесь, что получите скидку 10%. Да, вы правильно расслышали. 10% для вас. Вы увидите код на экране Jan Marshall заглавными буквами, и вы также найдете его в описании YouTube. И теперь мы можем продолжить. Я выберу местоположение сервера. Как упоминалось, я буду использовать Литву, а на следующем шаге нам нужно выбрать операционную систему. Теперь это снова очень важно. Hostinger дает вам возможность выбирать практически любую операционную систему. Debian, Ubuntu, CentOS и так далее. Но для этого видео мы будем использовать Ubuntu. И для версии, пожалуйста, выберите Ubuntu 24.04 LTS. Я нажму "Подтвердить". И это уже все, как вы видите здесь, очень просто. Итак, что я сейчас сделаю, это нажму "Продолжить". Как вы видите здесь, все прошло успешно. Поздравляю. Ваше путешествие начинается сейчас. Йоху. Итак, первый шаг — это теперь обезопасить наш доступ к VPS. Для этого нам нужно создать пароль root. Для этого я нажму "Сгенерировать". И это теперь мой пароль root. Что я хочу, чтобы вы сделали прямо сейчас, это скопировали свой пароль root и сохранили его где-нибудь в Google Docs, в своих заметках. Мне все равно. Но, пожалуйста, не теряйте его. Затем я оставлю этот параметр SSH-ключа пустым, потому что он необязателен и не нужен в нашем случае. Я нажму "Далее". И теперь мы можем добавить дополнительные функции. Я выберу сканер вредоносных программ. И теоретически вы также можете выбрать менеджер Docker, но это не очень нужно. Так что я нажму "Завершить настройку". И это уже все. Hostinger теперь настроит наш VPS, нашу виртуальную частную машину. И тогда мы сможем подключиться к ней из нашего терминала, установить Docker, разместить наше приложение, и тогда мы уже закончим. Как вы видите здесь, Hostinger наконец закончил и создал наш VPS. Итак, что мы можем сделать сейчас, это либо SSH в наш VPS, либо мы можем сначала посмотреть панель управления, и именно это мы и сделаем. Так что, если вы нажмете "Управление VPS", вы будете перенаправлены на панель управления. Итак, KVM2 Ubuntu 24.04, это наш root-доступ, и вместе с ним IP-адрес, пароль root, мы можем перезагрузить VPS, правила брандмауэра, ключ SSH, ноль, это нормально, сканер вредоносных программ активен, что очень хорошо, и затем внутри здесь вы также найдете детали, это означает местоположение сервера, ОС, и, кстати, вы также можете обновить ОС, так что если вы приняли неправильное решение, если вы выбрали неправильную ОС, то вы также можете обновить ее и выбрать правильную. Но все это выглядит идеально для меня, и я думаю, мы можем начать. Итак, что я хочу, чтобы вы сделали прямо сейчас, это нажмите на эту кнопку "Копировать", чтобы скопировать root-доступ. Я нажму "Копировать". Затем я вернусь в свой терминал. Это Warp, но вы можете использовать любой другой терминал. Если вы используете Windows PowerShell или установите Warp, мне все равно. И затем внутри здесь я вставлю то, что я только что скопировал. Итак, SSH root, а затем IP-адрес моего VPS. Если я сейчас нажму Enter, я получу это маленькое предупреждение. По сути, здесь новый хост, новый IP-адрес, к которому мой компьютер никогда не подключался. Так что здесь меня просто спрашивают: "Вы уверены, что хотите продолжить подключение?" Да, это нормально. Я нажму "Да" или выберу "Да". И теперь этот IP-адрес был добавлен навсегда. Отлично. Следующий шаг — добавить пароль. И это пароль VPS, который мы сгенерировали в начале. Вот почему я сказал вам: "Эй, пожалуйста, скопируйте пароль и сохраните его где-нибудь". Я вставлю его сюда и нажму Enter. И как вы видите здесь, мы теперь вошли в VPS. Добро пожаловать в Ubuntu 24.04. И если вы прокрутите вниз, вы также увидите здесь использование, использование памяти, процессы, вошедших пользователей, IPv4-адрес, IPv6-адрес. Это выглядит идеально. Это именно то, что мы хотели. Теперь, если вы по какой-то причине забыли свой пароль и не можете его найти, не волнуйтесь. Вы можете нажать "Изменить обновлено" и затем снова войти в свой терминал. Тем не менее, мы теперь в нашем VPS. Итак, какой следующий шаг? Что нам теперь делать? Должны ли мы установить Docker? Нет, нет, нет. Это огромная ошибка, которую совершают многие люди, и вы хотите ее избежать, потому что сейчас вы хотите сначала создать пользователя. Так что да, мы теперь вошли под пользователем root. Но вы никогда не хотите использовать пользователя root. Вы хотите создать второго пользователя и использовать эту учетную запись пользователя для взаимодействия с вашим VPS. И именно это мы и сделаем. Мы создадим пользователя deploy. Так что, если вы перейдете по ссылке в описании моего YouTube-канала, вы найдете ссылку на репозиторий GitHub. Репозиторий GitHub содержит много пустых файлов, документов, и это руководство по быстрому запуску. Здесь хранятся все команды, которые мы будем использовать в этом видео, потому что набирать все эти команды будет утомительно. Вы совершите много ошибок. Так что просто легче копировать и вставлять все. И давайте будем честными, никто не хочет набирать команды. Так что опять же, ссылка внизу в описании YouTube, вторая или третья ссылка, и тогда вы найдете это маленькое руководство по быстрому запуску. Как вы видите здесь, создайте пользователя deploy. И именно это мы и сделаем. Я скопирую все эти команды. Давайте вернемся. И затем я вставлю их сюда. Опять же, это теперь создаст пользователя deploy. Вы также можете переименовать пользователя, я не знаю, Marshall или user23. Это не имеет значения, но deploy имеет смысл в этом случае. Что я сейчас сделаю, это создам новый пароль для пользователя. Пожалуйста, сделайте то же самое. И опять же, не теряйте пароль, потому что он вам понадобится. Затем я снова введу пароль. И теперь вы также можете ввести имя и тому подобное. Это не очень нужно. Так что я нажму Enter. Enter. Enter. Enter. Это правильно. Да. Enter. И теперь у нас есть новый пользователь под названием deploy. Так что я выйду отсюда. Так что вы можете сказать "выйти". И теперь я войду в VPS, используя пользователя deploy. Так что давайте скажем SSH deploy @ и теперь нам нужен IP-адрес VPS. Для этого давайте вернемся. Я зайду в панель управления Hostinger. Скопирую IP-адрес. Вставлю его сюда. Нажму Enter. И теперь вам нужно ввести пароль. Не пароль root, а вместо этого пароль пользователя deploy, который мы создали буквально 30 секунд назад. Итак, как вы видите здесь, я теперь вошел. И также сказано, что для запуска команды от имени администратора, пользователя root, используйте sudo. Звучит хорошо для меня. Итак, что нам теперь делать? Какой следующий шаг? Ну, следующий шаг — установить Docker. Но, возможно, прежде чем мы установим Docker, вы можете спросить меня: "Эй, Джен, почему мы создали второго пользователя? Почему мы не можем просто использовать root, пользователя root?" Ну, это относительно просто. Пользователь root может делать все на машине, на VPS, и это нежелательно. Одна небольшая опечатка может практически сломать весь сервер. И если root будет скомпрометирован по какой-то странной причине, ну, тогда злоумышленник автоматически получит полный доступ к вашему полному VPS. И это означает полный доступ к вашему полному уровню инфраструктуры. Это нежелательно. И именно поэтому вы всегда хотите создать второго пользователя, который не имеет привилегий root-доступа. Если это имеет смысл. И теперь давайте продолжим с Docker. Итак, это команда для установки Docker на нашей машине. Так что я скопирую все. Давайте вернемся, и я вставлю это сюда. Но теперь вы можете спросить меня: "Подождите, подождите, подождите, подождите. Почему мы используем эти команды? Как вы узнали, что это способ установки Docker?" Ну, это очень просто. Если вы зайдете в Chrome и просто наберете "docker vps install", вы найдете эту ссылку здесь, и там написано "Установить Docker Engine на Ubuntu". И внутри здесь также упоминается та же команда. Так что именно это я и сделал. Я зашел на сайт, скопировал команду и вставил ее в свой документ. И именно это мы теперь скопировали и снова вставили сюда. Так что мы обновим все наши пакеты. Затем мы установим это здесь. Затем мы скачаем Docker. Затем мы снова все обновим. Мы установим Docker CLI, container.io и тому подобное. Так что это очень просто. Теперь нам также нужно добавить наш пароль для нашего пользователя deploy. Так что я добавлю его сюда и нажму Enter. Теперь все будет установлено. Это означает, в основном, Docker. И через секунду вы увидите, что все должно пройти успешно, и у нас будет работать Docker на нашем VPS. И да, как вы видите здесь, все прошло успешно, и Docker был установлен. Сеансы пользователей работают с устаревшими двоичными файлами. Это нормально. И затем соединение с IP-адресом закрыто. Это нормально. Итак, что мы хотим сделать теперь, это снова войти в наш VPS. Мы хотим SSH в наш VPS. Так что я сделаю следующее. SSH deploy @ теперь нам нужен IP-адрес VPS. Я вернусь в Hostinger, скопирую IP-адрес. Вставлю его сюда, нажму Enter, затем снова введу свой пароль. Это пароль пользователя deploy. И теперь я в VPS. Я вошел в VPS. Давайте теперь проверим, все ли прошло успешно. Так что я скажу "docker --version". И если я нажму Enter, вы увидите здесь, что мы успешно установили Docker, потому что мы установили версию 294.0. Отлично. Итак, с чего нам теперь продолжить? Ну, давайте вернемся к нашему руководству по быстрому запуску. И следующий шаг — заблокировать брандмауэр. Это очень важно, потому что вы хотите убедиться, что только определенный трафик разрешен. Вы не хотите говорить: "Эй, я не знаю, кто ты, но вот мой VPS. Ты можешь получить к нему доступ." Нет, нет, нет. Это огромная ошибка. Брандмауэры важны. Опять же, многие люди часто забывают их реализовать. Многие видео не показывают вам, как это сделать. Но в этом видео вы узнаете все. Итак, давайте пока просто скопируем все эти команды. Я вернусь, вставлю их сюда. И теперь, поскольку мы используем sudo, которое дает нам права администратора или, простите, права root, нам также нужно снова добавить или повторно ввести наш пароль. Я сделаю это. И теперь все будет настроено для нас. Здесь говорится, что команда может нарушить существующие SSH-соединения. Это нормально. Я нажму "Да", а затем Enter. И с этим у нас теперь настроен брандмауэр. И теперь вы можете спросить меня: "Эй, Джен, что мы только что сделали здесь? Что мы настроили?" Ну, если вы вернетесь к руководству по быстрому запуску, вы увидите здесь, что первая команда включила SSH. Так что "open SSH" сохраняет удаленный доступ работающим, потому что вы все еще хотите иметь возможность SSH в свой VPS и настраивать его. Другие две команды. Так что ATTCP и 443TCP. Эти команды открывают эти два порта. И эти два порта требуются для HTTP, HTTPS и выдачи сертификатов. Это довольно важно. И затем все остальное остается заблокированным по умолчанию, потому что опять же, вы не хотите открывать свой VPS случайным людям. Будут открыты только эти порты, и они необходимы для работы всего. Так что мы максимизируем безопасность, позволяя при этом работать нашему основному приложению, если это имеет смысл. Так что это выглядит идеально для меня. В качестве следующего шага нам нужно теперь направить наш домен на наш IP-адрес VPS, потому что да, теоретически вы можете получить доступ к своему веб-сайту, просто используя IP-адрес, предоставленный вашим VPS. Но это хорошая идея? Нет, не совсем. Потому что с доменами они дают вам одно явное преимущество. удобный для человека адрес. IP-адрес в конце концов — это просто набор чисел. И именно поэтому мы хотим использовать домен, а не просто IP-адрес VPS. Теперь, прямо сейчас, я предполагаю, что у вас уже есть домен. Если нет, то не волнуйтесь. Я покажу вам, как его получить. На панели управления Hostinger вы найдете кнопку "Домены". И если ваш портфель доменов пуст, что не очень хорошо, то вы можете получить новый домен прямо здесь. Так что я скажу что-то вроде "hostmarshall", я не знаю, что-то вроде этого, и я нажму "Поиск". Давайте посмотрим, что доступно. И знаете что, мне нравится это предложение ИИ "gethostmarshall". Я думаю, я воспользуюсь этим доменом. Так что я добавлю его в свою корзину. Затем для продолжительности я выберу один год. Этого мне достаточно. И теперь я перейду к оформлению заказа. Если я теперь вернусь в свой портфель доменов, вы найдете этот домен здесь, gethostmarshall.com, и он активен. Так что я нажму на эту кнопку с тремя точками и давайте отредактируем нашу зону DNS. И внутри здесь вы теперь увидите что-то интересное. Мы можем теперь управлять нашими записями DNS и также просматривать те, которые уже были созданы. В этом случае два уже были созданы. запись CNAME и эта запись A. Давайте удалим эту запись A, потому что она нам не нужна, и вместо этого создадим новую. Так что, если вы вернетесь к руководству по быстрому запуску, вы увидите здесь, что нам нужно создать две записи. Во-первых, обычную корневую запись для нашего домена. Это будет для нашего домена приложения. И затем мы также создадим запись статуса, и это будет для нашего сервиса мониторинга доступности. Так что давайте вернемся сюда. Для типа, пожалуйста, выберите A. Затем для имени, это будет наш корневой домен, и затем он будет указывать на наш домен VPS. Так что давайте вернемся к VPS, и я скопирую его сюда. Затем я снова перейду к своим доменам. Давайте нажмем на три точки, затем добавим зону DNS, и я вставлю ее сюда. Для TTL я выберу 300, или, другими словами, 5 минут. Я добавлю эту запись и давайте добавим еще одну. Так что для имени, это теперь будет "status". Это будет наш поддомен. Мы по-прежнему будем направлять его на наш VPS, и я оставлю TTL как есть. Так что 300 секунд, или, другими словами, 5 минут. Так что я нажму "Добавить запись". Да, это все нормально. Подтвердить. И теперь мы закончили. Чтобы проверить, работает ли все, я хочу, чтобы вы скопировали свой домен. Так что в моем случае, gethostmarshall.com. И если я вернусь к своему терминалу и открою новую вкладку здесь, и я скажу "dig" и вставлю свой домен сюда, вы увидите, что он теперь указывает на правильный IP-адрес 72.62 и так далее. Это IP-адрес моего VPS. Теперь вы должны увидеть свой собственный IP-адрес, IP-адрес вашего VPS. Так что это выглядит идеально. Я могу снова очистить это. И теперь мы можем продолжить. В качестве следующего шага нам нужно теперь подготовить каталог сервера и файл .env для продакшена. И чтобы сделать это, нам сначала нужно приложение Next.js. Теперь вы, конечно, можете создать свое собственное или вы можете перейти к моему репозиторию GitHub и клонировать репозиторий. Как только вы это сделаете, вы увидите здесь, что это полноценное приложение Next.js с установленным Prisma, Tailwind CSS и множеством крутых и модных вещей. Так что, если я перезапущу свой сервер разработки с помощью "pnpm run dev", вы увидите здесь, что это главная страница, и я бы сказал, что она выглядит довольно красиво. Так что Host Marshall — это приложение Next.js производственного уровня, работающее на VPS Hostinger. Ну, пока еще нет, но скоро оно будет размещено на Hostinger на нашем VPS. И затем здесь с Docker, Caddy, PostgreSQL, Redis и тому подобным. Каждая функция, которую предлагает Vercel, от ISR до потоковой передачи и оптимизации изображений, будет работать на нашем собственном сервере на этом VPS Hostinger. Так что внутри здесь я создал маршрут showcase. И этот маршрут showcase, по сути, демонстрирует многие функции, которые часто работают только на Vercel. Потому что вот в чем дело, многие люди ошибочно полагают, что Vercel предоставляет больше функций или что вы не можете использовать каждую функцию Next.js при самостоятельном размещении. Это неправда. Вы можете использовать ISR, fetch, cache и revalidation, потоковую передачу, серверные действия, оптимизацию изображений. Все это работает на вашем собственном сервере. Вам просто нужно сделать это правильно, настроить. И если вы все настроите правильно, то все эти функции будут работать как на Vercel или даже лучше, в зависимости от того, насколько хороша ваша настройка. Тем не менее, это главная страница или приложение. Опять же, вы можете просто клонировать его и начать сразу. Но да, это теперь закончено. Это приложение, и теперь нам нужно сначала создать каталог приложения на нашем VPS, и именно это мы и сделаем. Теперь, в этом руководстве по быстрому запуску, как вы видите здесь, я, по сути, использую переменные. И чтобы сделать то же самое, вы можете прокрутить вверх, и тогда вы найдете этот маленький раздел. Так что, значения для замены. Запустите это на своей локальной машине и сначала замените заполнители. Итак, что нам нужно? Какие переменные здесь? Давайте посмотрим. Так что мы хотим создать этот каталог приложения. Нам нужен пользователь и каталог приложения. Вот и все. Так что давайте прокрутим вверх сюда. Каталог приложения. Я скопирую это. Теперь, вот что важно. Эти локальные переменные оболочки не переносятся автоматически в свежую SSH-сессию. Если вы откроете новую оболочку, повторно запустите экспорты, которые вам нужны. Так что давайте получим наш каталог приложения. Я скопирую этот экспорт. Я вставлю его сюда. Как вы видите здесь, я в данный момент подключен к своему VPS через SSH, используя пользователя deploy. Я нажму Enter. И затем нам также нужен пользователь. Так что пользователь VPS. Я скопирую это. Давайте вставим это сюда. И теперь эти две переменные установлены. Так что мы можем снова прокрутить вниз. Давайте посмотрим. И мы можем теперь скопировать эти две команды. Так что это создаст новый каталог. И затем мы также установим пользователя. Так что давайте скопируем это. Я вернусь и вставлю это сюда. Мне придется снова аутентифицироваться. Это потому, что я использую sudo. И теперь это уже закончено. У нас теперь есть новый каталог, и опять же, если вы прокрутите вверх, это каталог, и причина, по которой нам нужно использовать sudo, заключается в том, что этот каталог /srv/server защищен. Так что всякий раз, когда вы хотите прикоснуться к нему, вам всегда нужно использовать sudo. Это закончено, и следующий шаг — скопировать шаблон .env с нашей локальной машины. Так что опять же, в этом репозитории GitHub вы найдете файл .env.example. Этот файл .env.example хранит все необходимые переменные среды. Домен приложения, домен статуса, электронная почта Let's Encrypt, URL Better-Of, секрет Better-Of, ключ шифрования серверных действий Next.js и т. д. Теперь я объясню все эти переменные среды немного позже. Давайте пока продолжим с нашим руководством по быстрому запуску. И следующий шаг — скопировать шаблон .env с нашей локальной машины. Что это значит? Ну, это означает, что вместо того, чтобы открывать или переходить в наш VPS, мы хотим запустить эту команду с нашей локальной машины. Так что это VS Code. Я сейчас в этом репозитории, верно? Так что в этой папке "single-vps-hosting" я открою свой терминал здесь. Я снова остановлю сервер разработки. Я в этой директории, как вы видите здесь. И теперь мне нужно выполнить эту команду. И для этого нам нужны три переменные. Пользователь VPS, IP-адрес VPS и каталог приложения. Так что я снова прокручу вверх и скопирую необходимые переменные. И это необходимо, потому что локальные переменные оболочки не переносятся автоматически в свежие SSH-сессии или, другими словами, обычные локальные сессии. Так что всякий раз, когда вы открываете новую оболочку, повторно запускайте экспорты, которые вам все еще нужны. И нам нужны эти три переменные. IP-адрес VPS, пользователь VPS и каталог приложения. Теперь IP-адрес VPS в настоящее время имеет заполнитель. Так что я вернусь в Hostinger, скопирую IP-адрес VPS и вставлю его сюда. Теперь я скопирую эти три переменные, эти три команды экспорта и вставлю их в свой терминал. Это теперь закончено, что означает, что я могу снова прокрутить вниз и скопировать команды. Так что эта команда SCP env.example и так далее. Я теперь вставлю ее сюда. И мне нужно теперь ввести свой пароль. Опять же, это пароль пользователя deploy, а не нашего пользователя root. Я нажму Enter. И теперь это было успешно. Что мы только что сделали здесь? Вы можете спросить меня, потому что мы теперь выполнили эту команду, но мы выполнили ее с нашей локальной машины, а не с нашего VPS. И что вообще означает SCP? Хороший вопрос. Так что, по сути, SCP означает Secure Copy, и он просто копирует файлы между машинами через SSH. Так что мы теперь на нашей локальной машине. Мы скопировали этот файл .env.example и затем, по сути, вставили его в наш VPS, используя SSH. Поскольку это закончено, мы можем теперь снова вернуться к нашему VPS и создать реальный файл .env для продакшена. Для этого я скопирую эти две команды. Опять же, пожалуйста, убедитесь, что эта переменная установлена: app_directory, и затем я вставлю ее сюда. Итак, cd app_directory, а затем cp .env.example .env. Это выглядит хорошо для меня. И следующий шаг — сгенерировать два важных секрета. Мы используем их через секунду. Так что давайте скопируем эти две команды. Это будет использовать OpenSSL. И затем я вставлю это сюда. Опять же, эта сессия в настоящее время подключена к моему серверу через SSH, как вы видите внизу слева. Теперь у нас есть два секрета, что отлично. Я скопирую оба этих секрета и сохраню их в своем приложении для заметок. Давайте вернемся, и следующий шаг — отредактировать наш .env на стороне сервера. Для этого я скопирую эту команду. Давайте вернемся, и я вставлю ее сюда. Теперь это откроет редактор. И как вы видите здесь, это, по сути, наш файл .env.example. Так что опять же, мы сделали это безопасное копирование через SSH. И с этим мы затем создали наш файл .env и скопировали все переменные из файла примера и вставили их в этот файл .env. И теперь нам нужно заполнить это. Давайте начнем с домена приложения. Я удалю этот демо-домен. И вместо этого я перейду в Hostinger и скопирую свой домен прямо здесь. Давайте вернемся, и я вставлю его сюда. Давайте продолжим с доменом статуса. Это будет поддомен. Так что status.gethostmarshall.com. В качестве следующего шага нам нужно обновить электронную почту Let's Encrypt. Теперь вы можете спросить меня: "Эй, Джен, зачем это вообще нужно?" Хм? Так что, по сути, эта переменная нужна для работы HTTPS. Так что Let's Encrypt — это, по сути, наш центр сертификации. Он затем создаст и выдаст этот сертификат, сертификат HTTPS, а затем Caddy, наш обратный прокси, который мы настроим позже, затем, по сути, будет общаться с ACME, ACME, и ACME — это язык или, другими словами, процедура, которую наш сервер использует для общения с Let's Encrypt. Так что позже снова у нас будет Let's Encrypt, это будет наш орган выдачи. Затем Caddy, наш обратный прокси, будет общаться с ACME, а затем ACME — это то, что наш сервер будет использовать для общения с Let's Encrypt. Вот как все работает. Теперь, если это звучит запутанно, то в конце концов просто постарайтесь запомнить, что это нужно для правильной работы HTTPS. Так что я добавлю свою реальную электронную почту сюда. В качестве следующего шага нам нужно обновить URL Better-Of. Так что это будет https, а затем в моем случае gethostmarshall.com. Затем нам нужно установить секрет Better-Of, а также ключ шифрования серверных действий Next.js. Теперь вы можете спросить меня: "Эй, Джен, как мы можем получить эти два ключа?" Ну, прежде чем мы откроем этот редактор, мы уже создали их. И именно поэтому я сказал вам: "Эй, пожалуйста, скопируйте эти секреты, потому что они нам понадобятся через секунду". Опять же, если мы вернемся к руководству по быстрому запуску, вы увидите здесь "Сгенерировать два важных секрета hex32", а затем "base64". Теперь, если вы их потеряли, то это нормально. Во-первых, нам нужно установить секрет Better-Of. Для этого вы можете зайти на сайт Better-Of, нажать "Установка", и здесь вы можете сгенерировать ключ секрета. Так что я нажму "Сгенерировать", а затем скопирую этот ключ. Давайте вернемся, и я обновлю эту переменную среды Better-Of значением, которое я только что скопировал. Давайте сделаем то же самое для ключа шифрования серверных действий Next.js. Для этого мы можем вернуться к нашему руководству по быстрому запуску. Нам нужно создать ключ base64. Так что я сделаю, это создам еще одну сессию терминала. Вставлю команду сюда. Скопирую ключ и вернусь в редактор. Я теперь удалю этот заполнитель. И теперь это тоже установлено. Но теперь вы можете спросить меня: "Эй, Джен, зачем нам вообще нужен этот ключ шифрования серверных действий Next.js?" Хороший вопрос. Если вы зайдете в документацию Next.js, вы найдете этот раздел. При самостоятельном размещении вашего приложения Next.js на нескольких серверах каждый экземпляр сервера может в конечном итоге иметь разный ключ шифрования, что приводит к потенциальным несоответствиям. Чтобы смягчить это, вы можете переопределить ключ шифрования, используя эту переменную среды. Указание этой переменной гарантирует, что ваши ключи шифрования будут постоянными между сборками, и все экземпляры сервера будут использовать один и тот же ключ. Вот почему мы устанавливаем эту переменную среды. И очень важно, чтобы эта переменная была закодирована в base64. Вот почему мы использовали эту команду здесь, base64. Теперь это тоже выглядит хорошо для меня. У нас теперь есть имя базы данных PostgreSQL, пользователь PostgreSQL, пароль PostgreSQL. Теперь нам нужно заменить это реальным паролем. Так что позвольте мне обновить его. Для этого я просто найду генератор паролей. И давайте сделаем это немного длиннее. Я думаю, что-то вроде этого выглядит хорошо. И затем я скопирую этот пароль. Так что давайте вернемся, и затем я вставлю его сюда. Остальное выглядит хорошо для меня. URL базы данных в порядке. URL Redis выглядит хорошо. Если вы теперь снова скажете "nano .env", вы увидите здесь, что все переменные среды были обновлены. Так что снова Ctrl+O, затем Enter и Ctrl+X. Теперь, пожалуйста, убедитесь, что вы сохраняете хост базы данных как PostgreSQL, потому что мы создаем базу данных PostgreSQL, а не MySQL. Также сохраняйте хост Redis как Redis, как вы видите здесь. URL Better-Of должен соответствовать нашему реальному публичному URL приложения. И это уже все. В качестве следующего шага мы можем наконец собрать и отправить наше приложение и перенести изображения в реестр контейнеров GitHub. Но прежде чем мы это сделаем, нам также нужен Dockerfile, а также файл Docker Compose. Теперь, поскольку Docker является очень важной частью всей нашей архитектуры, я также решил создать документ, который подробно объясняет нашу настройку Docker. Так что, как вы видите здесь, этот проект хочет модель развертывания, которая является воспроизводимой, легко объяснимой, реалистичной для самостоятельно размещенного VPS и достаточно гибкой для запуска нескольких сервисов, а не только одного.

XJS приложение, потому что мы хотим самостоятельно разместить весь наш стек, а не только скучное веб-приложение. И это приводит к простой идее. Соберите образы Docker один раз, отправьте эти образы в реестр, другими словами, в реестр контейнеров GitHub, загрузите их на VPS, а затем запустите весь стек с помощью Docker Compose. И вместо того, чтобы помещать все в один контейнер, стек разделен по ответственности. Это означает несколько контейнеров. Приложение запускает NextJS. Postgress хранит реляционные данные. Radis поддерживает инфраструктуру приложения. Uptimekuma обрабатывает мониторинг. Katti является общедоступной точкой входа в веб и migrate запускает миграции Prisma как одноразовый операционный шаг. Это означает, что в конце дня мы создадим 1 2 3 4 5 шесть контейнеров, и эти контейнеры будут работать на одном VPS. Это означает, что мы оптимизируем затраты, не забывая о безопасности и масштабируемости. Итак, вот общая картина. Здесь есть две отдельные задачи. Во-первых, мы соберем образы, и это будет обрабатываться нашим файлом Docker, и это даст два результата. Образ раннера для нашего приложения, а затем образ мигратора для развертывания миграции Prisma, потому что опять же в этом приложении я настроил Prisma. Это мой предпочтительный ORM. Второй шаг — запустить службы вместе, и эта задача обрабатывается docker compose. Итак, снова у нас есть две основные процедуры. Сам образ Docker или образы Docker, а затем docker compose, который затем запускает службы, и вы можете сказать, что он их оркестрирует, если это имеет смысл. Итак, файл production compos выбирает, какие образы запускать, внедряет конфигурацию времени выполнения, подключает службы к общей сети, сохраняет данные с помощью именованных томов и предоставляет только общедоступную точку входа. Теперь, если вы снова скачаете мой репозиторий, если вы его клонируете, вы уже найдете внутри Dockerfile. Этот Dockerfile похож на чертеж, и он предназначен для последующего создания образа Docker. Так что, если вы вернетесь к этому документу, вы увидите здесь, что наш Dockerfile создает многоэтапную сборку Docker. Это означает, что один файл создает несколько промежуточных этапов, а окончательные образы копируют только те части, которые действительно необходимы. Базовый этап дает каждому последующему этапу одинаковую отправную точку, ту же версию узла, тот же рабочий каталог и ту же настройку зависимостей на уровне ОС. А затем этот проект устанавливает там OpenSSL, потому что Prisma в нем нуждается. Размещение этого в базе избегает повторения одной и той же настройки системного пакета на каждом этапе. Теперь это очень важная оптимизация. Большинство людей очень путаются с многоэтапными сборками Docker. Это потому, что они немного более продвинуты, но они меняют правила игры, потому что они оптимизируют все и делают сборку намного быстрее. Затем второй этап — зависимости. И этап зависимостей устанавливает зависимости узла один раз, и это потому, что установка пакетов дорога, и Docker может хорошо кэшировать ее, если файлы манифеста не изменятся. А затем у нас также есть этап сборки. И этап сборки создает готовый к производству вывод NextJS. Он повторно использует модули узла из нашего этапа зависимостей. Он копирует полный исходный код приложения, генерирует клиент Prisma и делает все это. Затем у нас есть еще один этап, этап мигратора. И это создает отдельный образ только для развертывания миграции Prisma. Теперь это может выглядеть немного странно. Зачем нам отдельный образ только для мигратора? Ну, это относительно просто. Здесь не включено полное время выполнения приложения. Он копирует только то, что необходимо для выполнения миграции. Это означает зависимости, файлы схемы Prisma, конфигурацию Prisma и метаданные пакета. Таким образом, это разделение полезно, потому что миграция схемы — это не то же самое, что обслуживание веб-трафика. Опять же, наличие отдельных контейнеров очень мощно, потому что с помощью этого вы создаете независимость, достигая безопасности и производительности. И последний этап — это этап запуска, и это образ, который фактически обслуживает приложение. Он начинается с образа узла вместо повторного использования образа сборщика, и это означает, что окончательный образ времени выполнения остается меньше, что снова довольно круто. И если я сейчас открою Dockerfile, вы увидите то же самое. Так что все, что я только что упомянул, было настроено здесь. Например, прямо здесь я сначала установил версию NodeJS. Так 24130 slim. И это потому, что это последняя LTS-версия NodeJS. Затем здесь эта общая база поддерживает этапы сборки на одной и той же версии. И это также включает OpenSSL. И это потому, что OpenSSL снова нужен для Prisma. Затем первый этап — установить все зависимости PNPM, как вы видите здесь. Затем второй этап — собрать приложение Next JS. И я также установил эту версию развертывания. Так что это значение передается в сборку Next JS. Таким образом, окончательный артефакт может нести идентификатор развертывания без изменения кода приложения. А затем этот сборщик повторно использует этап зависимостей, чтобы мы не загружали пакеты дважды. Опять же, это очень важная оптимизация. А затем мы наконец генерируем клиент Prisma перед сборкой Next JS. Таким образом, автономный вывод может отслеживать его. Затем это наш третий этап, образ миграции, как вы видите здесь. Так что образ миграции намеренно мал и сфокусирован. Ему нужен только Prisma. А затем это этап четыре. Запуск приложения NextJS. Так рабочая директория app node env port 3000, а затем hostname 000000, и это все. Так что, как вы видите здесь, это все еще относительно простой Dockerfile. Как я уже создавал гораздо более сложные, но в то же время у нас есть очень важные оптимизации, как вы видите здесь. У нас есть многоэтапная сборка, и это не то, что вы увидите каждый день. Но это только одна часть нашей архитектуры Docker, потому что, как упоминалось, у нас также есть файл compose, и этот файл compose определяет стек VPS. Так что он отвечает на такие вопросы, как какие службы существуют. Итак, nextjs, postgress, radius, caddy и т. д. Какой образ использует каждая служба, какие значения env получает каждая служба, какие порты являются общедоступными, какие тома сохраняют данные и какие службы должны ждать других. Итак, снова, какие службы мы используем? Мы используем Postgress. Это наша база данных. Затем мы также используем Reddus. Это просто наша внутренняя служба поддержки для ограничения скорости. Затем у нас также есть наше приложение NextJS. Затем у нас также есть эта служба миграции, и она предназначена для повторного запуска образа миграции для Prisma. Конечно, у нас также есть служба uptime Kuma. Это наша собственная служба мониторинга и Kaddy. И Kaddy — это наша общедоступная точка входа, наш обратный прокси, и это единственная служба, которая публикует общедоступные порты. Она привязывается к 80 и 443 443. Она считывает значения, связанные с доменом, из нашего файла env и тому подобное. Теперь одна вещь, которую вы также должны осознать, это то, что большинство служб являются только внутренними. Так что в продакшене только caddy будет доступен из Интернета, postquest не будет иметь никаких портов. То же самое верно и для radius, нашего приложения и uptimekuma. Так что все заблокировано на нашем VPS. Наше приложение может подключаться к нашей базе данных, но никакая внешняя служба не может к ней подключиться, потому что нет общедоступных портов. И причина, по которой Caddy является общедоступной точкой входа, заключается в том, что это обратный прокси. Он обрабатывает маршрутизацию доменов, завершение HTTPS и поведение общедоступной точки входа. Он должен быть общедоступным, а остальное можно заблокировать. И, как упоминалось, у нас, конечно, также есть постоянные тома. Это означает, что данные postquest, данные radis, данные caddy и т. д. И это необходимо, потому что контейнеры одноразовые. Теоретически вы можете взять контейнер. Представим, что это контейнер, и вы можете просто сломать его и выбросить. Это контейнер, и именно поэтому вам нужны постоянные тома. Так что именованные тома хранят состояние, которое должно пережить замену контейнера. И, как упоминалось, у нас есть наш том postquest, наш том radius, наш том nextjs, наш том kuma, наш том caddy, и они очень важны. Так что, как вы видите здесь, это файл docker compose, это файл yaml, я знаю, что не всем нравится yaml, он немного сложен, но эй, я все объясню. Итак, снова, это файл docker compose для нашего продакшн-развертывания, и только ki доступен из Интернета. Так что здесь я определил все службы. Первая — Postgress. Это образ, который мы будем использовать. Мы запускаемся, если не остановлены. Затем здесь все переменные среды. Postquest DB, Postgress user. И эти переменные среды устанавливаются в нашем файле ENV, как вы уже знаете, на стороне VPS. Затем тома. Это местоположение нашего тома. Проверка работоспособности. Как вы видите здесь, интервал, время ожидания, достигнутые. Как упоминалось, этот файл compost практически определяет, как все должно работать, как все должно быть, я бы сказал, оркестрировано. Вы увидите здесь, что Reddus очень похож. Опять же, это частное для сети Docker. Он существует как служба поддержки. Мы снова определили образ, команду, перезапуск, если не остановлен, тома, местоположение тома, интервал проверки работоспособности, повторные попытки. То же самое верно и для нашего приложения Next JS. Образ перезапуска зависит от, и это теперь зависит от Postgress и Reddus, потому что мы хотим подключить наше приложение к этим двум службам, а Caddy, например, здесь очень интересен, потому что Caddy предоставляет общедоступные порты. Так что, если я прокручу немного вниз, вы увидите здесь порты, и это означает, что Caddy теперь общедоступен. Остальные не общедоступны, потому что мы не открыли никаких портов. Мы также добавили здесь расположение тома. Мы также говорим, что caddy зависит от того, что наше приложение запущено, что kuma запущено. Так что это очень важно. Опять же, этот файл compos раскладывает все. Он практически говорит нашей системе, как все должно работать и когда что-то должно запускаться, когда что-то должно перезапускаться и т. д. Это чертеж всего. И поскольку мы наконец-то закончили с этим, мы можем перейти к фазе шесть. Итак, что нам теперь нужно сделать, это запустить это на нашей локальной машине из корня репозитория, и это то, что мы сделаем. И для этого мы хотим войти в реестр контейнеров GitHub. Другими словами, давайте перейдем на github.com. Оказавшись на GitHub, нажмите "Настройки", а затем в настройках прокрутите вниз до "Настройки разработчика". Здесь вы можете нажать "Персональный токен доступа" и я хочу, чтобы вы создали классический токен. Затем здесь я сгенерирую новый токен. И снова я хочу сгенерировать классический токен. Теперь, во-первых, нам нужно добавить сюда имя. Итак, я скажу Hostinger VPS Host Marshall. Затем для истечения срока действия это достаточно для этого видео. Затем, позвольте мне немного увеличить масштаб. Давайте прокрутим немного вниз. И нам нужно выбрать области действия. И нам нужно выбрать эту область действия "запись пакетов" и "удаление пакетов". Таким образом, это позволит нам загружать пакеты в реестр пакетов GitHub. Это закончено. Давайте прокрутим вниз, и я нажму "сгенерировать токен". Давайте скопируем этот токен. И я буквально просто вставлю его куда-нибудь. Итак, давайте откроем файл ENV, и я вставлю его ниже, чтобы не потерять его. Давайте вернемся к нашему краткому руководству. И здесь нам нужно запустить эту команду. Но чтобы запустить ее, нам нужно установить две переменные. Токен реестра контейнеров GitHub, а затем имя пользователя GitHub. Для этого, пожалуйста, снова прокрутите вверх. И теперь нам нужно обновить наш токен реестра контейнеров GitHub. Итак, я вставлю то, что я скопировал несколько мгновений назад, мой токен. И, пожалуйста, создайте свой собственный, потому что я удалю свой пакет после этого видео. Так что этого больше не будет. И здесь вы увидите, что у нас есть еще одно имя переменной, которое очень похоже. Токен чтения реестра контейнеров GitHub. В чем разница? Ну, вот в чем дело. Теоретически, вы хотели бы создать токен для чтения, а затем токен с правами записи, но это не очень нужно. Так что я просто повторно использую токен, потому что этот токен уже имеет все необходимые разрешения. Теперь нам также нужно добавить наше имя пользователя GitHub. Для этого, пожалуйста, перейдите на GitHub, скопируйте свое имя пользователя, а затем удалите заполнитель и вставьте свое настоящее имя пользователя. Теперь вы также можете спросить меня: "Эй, Ян, когда мы создали этот токен здесь, мы как бы выбрали разрешения, и это называлось пакетом. Но здесь это называется реестром контейнеров GitHub. В чем разница? Ну, по сути, реестр контейнеров GitHub является частью системы хостинга пакетов GitHub. Так что это практически подсистема. Всякий раз, когда вы слышите о хостинге пакетов, вы также можете думать о реестре контейнеров GitHub. Это практически одно и то же. Это подсистема, суб-функция. И используя эту функцию реестра контейнеров GitHub, вы можете хранить такие вещи, как образы Docker, пакеты npm и просто артефакты в целом. И поскольку это закончено, я также скопирую эти три команды экспорта. И вот в чем дело, вам больше не нужно идти на свой VPS. Нет, нет, нет. Вместо этого мы хотим запустить эти команды локально. Для этого я хочу, чтобы вы открыли свой терминал. И, пожалуйста, убедитесь, что вы находитесь в правильной директории. Так что в моем случае, single VPS hostinger. И это тоже репозиторий git. Это означает, что я отправил этот код. Тем не менее, я сейчас вставлю эти три команды сюда. И теперь мы можем прокрутить вниз и скопировать нужную команду. Так что эта, я сейчас скопирую это. Давайте откроем терминал, и я вставлю это сюда. И, как вы видите здесь, вход выполнен успешно. Теперь, если вы получили ошибку прямо сейчас, это означает, что вы, вероятно, еще не установили Docker Desktop. Так что, пожалуйста, установите его. Он нужен для того, чтобы все работало правильно. И снова, Docker Desktop бесплатен в использовании. Он не платный или что-то в этом роде. Перейдите на сайт Docker, нажмите огромную кнопку загрузки, а затем вы можете продолжить с этим видео. Так что я снова закрою это. Давайте вернемся. И прежде чем мы перейдем к следующему шагу, вы также можете спросить меня: "Эй, Ян, что сделала эта команда? Ну, во-первых, мы установили echo GitHub container registry token. Ну, эта команда практически выводит наш токен из нашей среды. Затем эта вертикальная линия, это оператор конвейера. Он передает токен следующей команде. Другими словами, этой. Затем, как следующий шаг, мы устанавливаем docker login github container registry.io. Это подключает наш локальный клиент Docker к реестру контейнеров GitHub. Вот почему вам нужно установить Docker Desktop, чтобы все работало. Затем этот -u github container registry username. Это говорит Docker, под какой учетной записью GitHub войти. И затем, наконец, эта команда -password. Она считывает токен из стандартного ввода вместо того, чтобы отображать его в истории оболочки. Так что это закончено, и следующий шаг — собрать и отправить образ приложения для типичной архитектуры VPS. Теперь причина, по которой я говорю "типичная архитектура VPS", заключается в том, что если вы не определите платформу в этой команде, образ Docker будет собран для вашей платформы, если это имеет смысл. Например, я использую MacBook, и у этого MacBook есть чип M. Это означает, что он использует архитектуру ARM. Наш VPS не использует или не имеет чипа M, Apple M чипа, а вместо этого чипа AMD. И этот чип AMD полагается на архитектуру AMD 64. Так что это причина, по которой нам нужно определить платформу. Мы хотим убедиться, что собранный образ правильный для нашего VPS. Так что, если бы вы определили эту платформу, он собрал бы образ для вашей конкретной платформы. И поскольку архитектура ARM не та же, что и архитектура AMD 64, вы получите ошибку, которую не хотите. И с этим разобрались, мы можем наконец выполнить эту команду. И для этого нам нужно установить две переменные: тег образа и образ приложения. Итак, давайте прокрутим вверх до нашего небольшого, я полагаю, обзора переменных. И здесь вы найдете тег образа и образ приложения. Теперь интересная вещь заключается в том, что, например, образ приложения зависит от нескольких других переменных. Корневой каталог образа, тег образа, а затем корневой каталог образа требует имя пользователя GitHub. Так что, чтобы сэкономить время, я буквально скопирую все эти переменные. Открою свой терминал, свой локальный терминал. Опять же, не подключайтесь к своему VPS по SSH. Откройте свой локальный терминал и, пожалуйста, перейдите в свою правильную директорию. И затем я вставлю все эти команды сюда. С этим разобрались, теперь мы можем прокрутить вниз и скопировать команду. Так что эта, docker build x. Я скопирую ее, а затем вставлю в свой терминал. Опять же, я не подключен к своему VPS по SSH. Все это теперь происходит локально. Теперь вся эта сборка, вероятно, займет несколько минут, две или три минуты. Так что, пока это работает, мы также можем изучить команду. Что мы только что вставили в наш терминал? Итак, во-первых, мы установили docker build x build, и это использует docker build x, который поддерживает современные многоэтапные сборки и кроссплатформенные сборки. Затем эта команда --platform собирает для общей архитектуры Linux VPS x8664. А затем эта цель --t runner говорит Docker остановиться на этапе раннера в Dockerfile, который является окончательным образом времени выполнения Next JS. Затем эта сборка arc deployment version. Это передает наш тег выпуска в сборку. И затем, наконец, --push загружает готовый образ прямо в наш реестр контейнеров GitHub. И точка в конце, вот эта, означает использовать текущий корневой каталог репозитория в качестве контекста сборки. И это все. Если я теперь снова открою свой терминал, вы увидите, что все прошло успешно, что, конечно, всегда желательно. И как следующий шаг, мы можем собрать и отправить образ миграции. Я скопирую команду и вставлю ее сюда. Теперь это, по сути, снова делает то же самое. Так что он использует тот же поток сборки, что и выше, но теперь для контейнера миграции вместо нашего образа приложения. Это все. И именно поэтому цель установлена на migrator. Так что он выбирает этап мигратора из Dockerfile. И это все. Так что, если я теперь снова открою свой терминал, вы увидите здесь, что он теперь отправляет все необходимые слои. И как только это будет сделано, мы сможем продолжить. И почему это важно? Ну, потому что VPS нужно только загружать образы, а не собирать их. Это важно помнить. Вот почему вся эта концепция реестра контейнеров GitHub так мощна. Она экономит много времени. Она экономит много ресурсов, что означает, что она экономит вам много денег. И раннер — это фактический образ времени выполнения NextJS. А затем мигратор существует только для запуска Prisma migrate deploy. Это все. Так что, если я теперь снова открою свой терминал, вы увидите здесь, что он еще не закончен. Эй, это нормально. Без проблем. Давайте подождем, пока он закончится. Наш образ мигратора также наконец-то собран, что означает, что мы можем перейти к фазе 7, которая заключается в копировании файлов развертывания на VPS. И вот что важно. Вы хотите снова сделать это с вашей локальной машины, а не с вашего VPS. Так что мы будем использовать эту команду save copy, которая затем безопасно скопирует файлы через SSH. Это не должно быть чем-то новым для вас, ребята, потому что мы уже использовали эту команду раньше. И мы скопируем два файла. Этот файл docker compose.pro. Итак, docker.compose. Мы уже смотрели на этот файл. А затем также этот файл caddy. И этот файл caddy нужен для самого caddy. Наш обратный прокси. Так что здесь установлен наш email let's encrypt, наш домен приложения. Затем заголовки обратный прокси app 3000. Это порт домена статуса, потому что мы также хотим проксировать наш сервис мониторинга статуса uptime. Так что это идеально. А также порт и также порт 3001. И это потому, что порт 3000 уже занят нашим доменом приложения. Это закончено. Давайте снова прокрутим вниз. Я скопирую команду safe copy. Давайте откроем терминал, и я вставлю ее сюда. Теперь, вот в чем дело. Эта команда снова полагается на три переменные. Теоретически, эти переменные уже должны быть доступны в этой сессии терминала. Но если нет, снова, просто прокрутите вверх, скопируйте все эти команды, эти переменные, и вставьте их сюда. Но я сейчас нажму Enter. Мне придется снова ввести свой пароль, потому что снова мы хотим сейчас практически SSH на наш VPS, а затем скопировать файлы прямо сюда. Мне нужно добавить пароль пользователя deploy, а не пароль root. Так что, пожалуйста, убедитесь, что вы это сделали. И теперь мы скопировали файл docker compose и файл caddy. Отлично. Так какой следующий шаг? Ну, следующий шаг — проверить все на стороне VPS. И это то, что я сделаю. Так что я скопирую эти две команды. Давайте вернемся к нашему оригинальному терминалу. Так что здесь я сейчас подключен к VPS по SSH. Я скопирую эти две команды. Вернитесь, вставьте их сюда. И давайте посмотрим. Как вы видите здесь, у нас есть файл av. Envy.ample caddy file и docker compose. Это именно то, что вы хотите видеть. Как следующий шаг, мы можем продолжить с фазой 8, которая заключается в загрузке образов, запуске инфраструктуры, запуске миграций и запуске приложения, а с этим и caddy. Так что, если в вашей текущей оболочке VPS нет всех переменных образа, что нормально, то, пожалуйста, снова прокрутите вверх и скопируйте все эти. Так что вам нужен ваш GitHub username, токен чтения, образ приложения, а затем образ миграции. Итак, что я сейчас сделал, это обновил все эти переменные. Я сейчас скопирую эти четыре команды и вставлю их в свой терминал. Опять же, это терминал, где я подключен к VPS по SSH. Также я вернусь в корневую директорию. Так что cd do/. Теперь я вернулся в корневую директорию, и мы можем продолжить. Итак, нам нужно создать deploy.inv env на VPS, чтобы наш compost знал, какие теги образов запускать. Так что нам нужно перейти в директорию приложения, а затем мы создадим этот файл. Так что я скопирую эти команды. Давайте вернемся, и я вставлю их сюда. Это закончено. Давайте продолжим. Итак, используя эти команды, мы сначала переходим в директорию приложения, а затем создаем этот файл deploy.env env, и используя этот EOF, мы можем создать многострочный файл из оболочки, а затем это две переменные, хранящиеся в этом файле env: образ приложения и образ миграции. Поскольку это закончено, мы можем заблокировать VPS в нашем реестре контейнеров GitHub. Так что я скопирую эту команду. Давайте вернемся, и я вставлю ее сюда. Как вы видите здесь, вход выполнен успешно, что важно. И это очень похоже на предыдущую команду, которую мы уже запускали, но вместо того, чтобы делать все локально, мы сделали это на нашем VPS. Так что это блокирует клиент Docker VPS в реестре контейнеров GitHub. И прежде чем мы заблокировали наш локальный клиент Docker в реестре контейнеров GitHub. Вот почему эта команда так похожа. Это практически то же самое, но вместо того, чтобы делать это локально, мы теперь делаем все на нашем VPS. И поскольку это закончено, мы также можем наконец загрузить оба образа: образ приложения и образ миграции. Так что я скопирую эти две команды. Давайте вернемся к нашему терминалу, который подключен к VPS по SSH, и я вставлю их сюда. И мы получили ошибку. Подождите, что? Ответ об ошибке от демона. Х, в чем проблема? Давайте снова вернемся, и я все еще раз проверю. Итак, мы экспортировали все эти переменные, и я вижу ошибку. О боже. Как для образа приложения и образа миграции, нам нужно добавить наш тег, но я оставил заполнитель как есть, что нехорошо. Но эй, это легко исправить. Что вы хотите сделать, это снова открыть ваш обычный терминал, а не терминал вашего VPS. И здесь вы можете сказать get, затем rev reface --short, а затем uppercase T, и это даст вам ваш тег. Так что в моем случае c4b и т. д. Я скопирую его. Закрою свой терминал, а затем это будет app- а затем то, что я только что скопировал. А затем для образа миграции это будет migrate- то, что я только что скопировал. Это закончено. Я снова скопирую все эти экспорты. Давайте вернемся. Я все очищу. Вставлю их сюда. Это мой терминал SSH. Я подключен к VPS по SSH. И теперь здесь нам нужно снова обновить наш файл deploy.v. Так что я просто скопирую все здесь. И я только что понял, что я также уже перешел в директорию приложения. Так что мне не нужно переходить в директорию приложения. Я просто скажу cat, а затем deploy envir. Я скопирую его, а затем вставлю сюда. Так что теперь это обновлено правильными переменными. И теперь давайте снова загрузим оба образа. Так что я скопирую эти две команды. Давайте вернемся, и я вставлю их сюда. И теперь это должно быть успешно. Так что docker pull app image и docker pull migration image. И, как вы видите здесь, он теперь загружается из моего репозитория. Загрузка завершена. Загрузка завершена. Загрузка завершена. И, как вы видите здесь, все прошло успешно. Так что мы скачали оба образа, и он также здесь скачал новый образ для этого репозитория контейнеров GitHub. Теперь что именно мы здесь сделали? Ну, docker pull загружает точные тегированные образы из реестра контейнеров GitHub. Вот почему нам нужно было добавить наш тег сюда. заполнитель не сработал. Он не ссылался на правильный контейнер. И предварительная загрузка делает развертывание более явным и легким для отладки. И это также подтверждает правильность имен образов и разрешений реестра перед тем, как compose запустит контейнеры. И поскольку это закончено, мы также можем запустить наши инфраструктурные службы. Другими словами, Postgress, radus и uptimekuma, потому что наше приложение, наше приложение Next JS, например, зависит от postgress и radius. Так что, если я открою файл docker compost и прокручу немного вверх. Так что давайте посмотрим app. Затем вы увидите здесь, что это приложение, наше приложение Next JS, зависит от Postgress и radus. И условие заключается в том, что обе службы работоспособны. Это означает, что они должны работать. Так что я снова закрою это и давайте прокрутим вниз. И теперь я скопирую эту команду. Так что давайте вернемся к нашему терминалу VPS, и я вставлю ее сюда. Но теперь вы можете спросить меня: "Эй, Ян, как бы, в целом я понимаю, что делает эта команда, но что именно она делает? Ну, docker compose запускает службу, определенную в нашем файле docker compose, том, который я вам показывал секунду назад. Затем этот --envile.env загружает наши настройки приложения времени выполнения, такие как наши домены, учетные данные базы данных. Так что в целом все наши переменные среды, те, которые мы определили в нашем файле env.example, а затем позже скопировали на наш VPS. Затем этот --env file deploy.invy. Он загружает теги образов, которые мы хотим, чтобы это развертывание использовало. А затем этот - fd docker compose file. Это говорит compose, какой файл читать, потому что снова этот файл docker compose практически раскладывает все. А затем этот up-d запускает контейнеры в режиме отсоединения, так что они продолжают работать в фоновом режиме. А затем в конце этот postgress radius и uptime kuma просто запускают эти службы первыми, и это все. Так что, если я теперь вернусь, вы увидите здесь, что все было загружено и все было создано. И следующий шаг — один раз запустить миграции. Так что я скопирую эту команду. Это снова очень похоже. И я вставлю ее сюда в свой терминал VPS. И под терминалом VPS я просто имею в виду, что эта оболочка в настоящее время подключена к VPS по SSH. И эта команда относительно интересна, потому что она запускает одноразовый контейнер миграции, который мы создали в начале, а затем внутри контейнера образ запускает prisma migrate deploy, и этот --rm удаляет контейнер после завершения всего, потому что он на самом деле не нужен. Так что, если мы теперь вернемся, вы увидите здесь, что все прошло успешно. Так что схема Prisma загружена из schema.prisma, источник данных Prisma DB, база данных Postquest, миграция не найдена в миграциях Prisma, нет ожидающих миграций для применения, и это нормально. Так что, если мы теперь вернемся, следующий шаг — запустить общедоступное приложение и прокси-сервер наконец, потому что мы сначала запустили все нижележащие службы, от которых зависит наше приложение. Затем у нас была миграция. Это означает, что она подготовила все для нас. И теперь мы можем наконец запустить наше приложение, а с ним и прокси-сервер, который затем практически соединит наш VPS с внешним миром, а с ним и наше приложение. Так что я скопирую команду. Давайте вернемся, и я вставлю ее сюда. Так что, как упоминалось, это запустит фактический контейнер приложения NextJS, а затем обратный прокси-сервер Caddy, который также является своим собственным контейнером, а затем Caddy будет перенаправлять входящий веб-трафик на наш внутренний контейнер приложения, и поскольку Caddy также является единственной общедоступной службой, у него есть два общедоступных порта: 80 и 443, и это все. Так что, если мы теперь вернемся, вы увидите здесь, что все работоспособно, что очень важно. Так что, если мы вернемся, последний шаг — проверить стек. Я скопирую команду. Давайте вернемся. Я вставлю ее сюда. И, как вы видите здесь, все работает. Так что работоспособно, работоспособно, работоспособно и работоспособно uptime kuma, radis, postgress, caddy и app. Это именно то, что я хотел увидеть. Наконец, что мы можем сделать, это также необязательная очистка. Так что эта команда удалит висячие образы Docker, которые больше не привязаны к тегу. А затем этот -f в конце пропускает запрос подтверждения. Опять же, это необязательно. Вам не нужно запускать эту команду. Я не буду этого делать. Но если вы хотите продолжить, ничего не сломается. Все будет работать. Вы просто оптимизируете все еще больше. Но знаете что? Я думаю, пора все протестировать. Работает ли наше приложение? Кто знает? Так что давайте вернемся к панели управления Hostinger. Это мой домен. Я скопирую домен. Вернусь в Chrome и открою его в новой вкладке. И что у нас здесь? Этот сайт не может обеспечить безопасное соединение. Подождите, что? Мы настроили Caddy. Caddy должен фактически реализовать HTTPS. Ошибка SSL-протокола. Хм. Похоже, мы допустили ошибку. И знаете что? Думаю, я знаю, в чем проблема. Так что я сейчас нахожусь в директории приложения. И здесь я скажу nano.env. И если я открою это, вы увидите что-то интересное. У нас все еще старые заполнители. Домен приложения, домен статуса, email let's encrypt. Это не правильные значения. Теперь, честно говоря, я не совсем уверен, в чем проблема, потому что теоретически мы все настроили. Так что, да, я не знаю, но, думаю, давайте обновим еще раз. Так что я вернусь, скопирую домен приложения. Пожалуйста, не копируйте https или что-то в этом роде, просто ваш домен. Затем я удалю этот заполнитель. Так что теперь это равно gethostmarshall.com. Затем я обновлю этот домен статуса. Это будет status.get gethostmarshall.com. Затем я обновлю email. Важно, чтобы это был настоящий email. Затем я обновлю URL лучшей стороны. Это может быть HTTPS. Это не проблема. Теперь мне нужно обновить оба секрета: секрет лучшей стороны и ключ шифрования серверных действий Next. Так что я сначала открою веб-сайт лучшей стороны. Нажмите на документацию, установку, и здесь я сгенерирую секрет. Я скопирую его, а затем заменю фиктивный ключ настоящим секретом. Как следующий шаг, мне нужно сгенерировать ключ base64. Так что я скопирую эту команду, открою SSL вокруг base64. Я открою новую вкладку терминала, вставлю ее сюда и скопирую этот секретный ключ. Я закрою вкладку терминала и обновлю этот ключ шифрования серверных действий Next и заменю его тем, что я только что сгенерировал. Затем postquest DB в порядке, пользователь в порядке, пароль не в порядке. Мне нужен более сильный пароль. Так что я зайду в Chrome и скажу генератор паролей. Так что я скопирую пароль, вернусь, а затем заменю этот заполнитель тем, что я только что скопировал. И остальное выглядит хорошо. Так что я сейчас сделаю, это нажму Ctrl O, затем Enter и Ctrl X. Так что, если я снова скажу nano env, я все равно должен увидеть все обновленные значения, и да, это правильно. Так что снова Ctrl O Enter, вам не нужно перезапускать приложение, но эй, какая разница, давайте также перезапустим его. Одна вещь, которую я также сделаю, это добавлю флаг force recreate. Так что up-recreate, а затем app и caddy. Я скопирую эту команду. Давайте вернемся. И вот в чем дело. Я не буду делать это в этой сессии оболочки. Что я сделаю, это скажу exit. Я фактически даже открою новую вкладку терминала, новую сессию оболочки. И здесь я теперь скажу ssh deploy at мой IP-сервер. Я затем добавлю свой пароль для пользователя deploy. И здесь я сначала перейду в директорию приложения. Так что я прокручу вверх. Здесь у нас все наши переменные. И это моя директория приложения. Я скопирую это и скажу cd directory приложения. Я сейчас в директории приложения. Что означает, что я могу снова прокрутить вниз. Да, я знаю, немного раздражает. И теперь я скопирую эту команду, где я сказал force recreate. Я скопирую ее. Вернусь и вставлю ее сюда. Так что это теперь воссоздаст все контейнеры. Так что radius app caddy и т. д. И знаете что? Теперь пора все протестировать. Я сделаю горячее обновление, и это наше приложение. Это Host Marshall? Да. Разве это не круто видеть? И знаете что? Мы можем протестировать это. Я нажму на витрину и посмотрим, например, работают ли серверные действия. Джон Фишер, привет, как дела? Я подпишу гостевую книгу, и у нас есть сообщение. Это означает, что серверные действия работают. И если я сделаю горячее обновление, вы увидите что-то интересное. Это все еще здесь. Это потому, что это хранится в памяти и сбрасывается при перезапуске контейнера. Это огромное преимущество VPS или долгоживущих серверов в целом. Если бы вы использовали versel и с ним серверную архитектуру, то это не сработало бы, потому что бессерверная функция может жить только 30 секунд. Так что, если бы вы сейчас сохранили это сообщение в памяти, оно было бы потеряно. Оно было бы удалено через 30 секунд. Но здесь теоретически это могло бы жить 30 дней, 1 месяц, 1 год. Если вы не перезапустите свой контейнер, это просто останется сохраненным, что очень мощно. Что мы также можем сделать, это проверить, работает ли наша база данных. Так что я аутентифицируюсь Ян Маршалл. Я добавлю свой email и, конечно же, пароль. И если я теперь нажму "создать учетную запись", вы увидите здесь, что все прошло успешно. Так что вошел как Ян Маршалл, панель управления, выйти. Так что наша база данных также работает. Наш ORM работает. Caddy работает. Postquest работает. Better off работает. Hostinger, конечно, тоже работает, что очень важно. Так что в целом мы закончили с нашей основной сборкой, хотя мы также можем проверить uptimekuma. Так что давайте скажем status.gethostmarshall.com, и это теперь uptimekuma. Мне придется сначала создать учетную запись администратора. Это нормально. Мое имя пользователя будет jan marshall. Затем я сгенерирую пароль, и это все. Так что это теперь моя учетная запись. Я сохраню все, и мы можем добавить новый монитор. Так что вверху слева я нажму "добавить монитор", дружелюбное имя. Это будет просто, я думаю, host marshall. Затем нам нужно добавить URL. Это get host marshall. Так что я скопирую его и вставлю сюда. И остальное выглядит хорошо. Нам не нужно настраивать прокси. Нам не нужно настраивать уведомления. Я сейчас просто нажму "сохранить". И теперь вы увидите что-то интересное: работает. Все работает. У нас есть зеленая полоса. И это потому, что теперь uptimekuma будет выполнять проверку работоспособности нашего приложения каждые 60 секунд. И если она успешна, это означает, что наше приложение работает и функционирует. Мы также можем создать страницу статуса. Так что я нажму "страницы статуса". Затем я нажму "новая страница статуса". Для имени это будет, я думаю, public-page, а для слаг это будет то же самое. Так что public-page я нажму "далее". И теперь дело в том, что я могу добавить группу. Так что я нажму "добавить группу", а затем я добавлю host marshall. Я сохраню это. И теперь у нас есть общедоступная страница. Это означает, что если я скопирую это и открою в новой вкладке инкогнито, то любой сможет просмотреть статус host marshall. И, как вы видите здесь, Host Marshall работает отлично. Он работает, и все системы в рабочем состоянии. И да, все, мы теперь смогли самостоятельно разместить весь наш стек на одном VPS, на одном волшебном VPS. Как вы видели, Hostinger, но также и Docker — это два очень мощных инструмента. Docker позволяет нам самостоятельно размещать все на одном VPS, предоставленном Hostinger, при этом контейнеризируя. и с помощью этого изолируя каждую отдельную службу, что является огромным преимуществом. Я хочу еще раз поблагодарить Hostinger за то, что сделали это огромное видео возможным. Я надеюсь, вы смогли многому научиться. Опять же, Hostinger — лучший провайдер VPS на рынке. Они предоставляют лучшую производительность, лучшие цены и лучшую поддержку на рынке. И снова, соотношение цены и качества просто зашкаливает. Также, если вы используете ссылку внизу в описании моего YouTube, вы получите скидку 10%. И также, пожалуйста, не забудьте использовать мой промокод Jan Marshall, полностью заглавными буквами. Вы снова увидите его на экране. И да, это все. Я надеюсь, вам понравилось видео. Я надеюсь, вы смогли многому научиться. Пожалуйста, не забудьте поставить лайк и подписаться. Это будет для меня очень много значить и для моего сердца. Так что, пожалуйста, сделайте это. Еще раз спасибо, Hostinger, за то, что сделали это видео возможным и являетесь супер хорошим провайдером VPS, а также отличным хостом доменов. И с этим разобрались, хорошего вам дня и увидимся в следующем видео. Конец связи. Пока-пока.