Install Node.js on Shared Hosting
To use almost any development tool, based on JavaScript, you’ll need npm and Node.js. While your hosting provider may tell you, this wasn’t possible, you can still give it a try.
To install npm and Node.js, SSH access is necessary. Ask your hosting provider to enable SSH on your account. On many shared hosting accounts, you’ll be able to create SSH Keys trough cPanel and access your account via Terminal.
example (SiteGround Hosting):
Install Node.js on Siteground Shared Hosting
From your /home folder, follow the instructions (copy/paste line by line):
Установка и настройка Node.js
Если вы используете Node.js как средство серверной разработки для своего сайта или web-приложения, то эта статья для вас, поскольку в ней мы рассмотрим настройку данной программной платформы и правильную организацию структуры папок для корректного функционирования вашего проекта.
Для начала вам необходимо установить Node.js на свой аккаунт. Скачать любую версию Node.js можно с официального репозитория https://nodejs.org/dist/. На момент написания данного руководства, последним релизом являлась версия v10.6.0, скачать её можно здесь.
Выбирать нужно версию для Linux, битность x64, архиватор GZIP. Скачиваем файл https://nodejs.org/dist/v10.6.0/node-v10.6.0-linux-x64.tar.gz
Для нужной версии вы сможете также установить и необходимые модули (см. ниже).
На хостинге функционирование Node.js реализовано через специальную библиотеку Passenger, которая осуществляет взаимодействие Вашего сайта с обработчиком Node.js
Рассмотрим структуру папок и файлов. Мы предлагаем реализовать ее примерно следующим образом:
- site-name.com (корневая папка вашего сайта)
- htdocs
- www
Ваша цель — создать идентичную структуру и разместить файлы в соответствующих схеме директориях. Далее мы наполним их содержимым.
Чтобы сразу начать пользоваться необходимой вам версией Node (при условии, что Вы уже получили доступ по SSH), можете ввести следующие команды в терминале для загрузки и распаковки архива с файлами:
Чтобы Passenger мог взаимодействовать с Node.js, в файле .htaccess (мы рекомендуем располагать его здесь ./site-name.com/htdocs/www/.htaccess) необходимо прописать следующее:
- Вместо hostXXXXXXX вы прописываете номер своего аккаунта
- site-name.com — это имя папки с вашим проектом
- app.js — название файла, который запускает работу серверной части (вы можете назвать его как захотите, главное, пропишите соответствующее имя в .htaccess)
- PassengerNodejs — путь до исполняемого файла Node.js
- PassengerFriendlyErrorPages — опция для отображения ошибок, в случае, когда приложение работает не корректно, или не запускается (по умолчанию — PassengerFriendlyErrorPages off). Данная опция выводит сообщения об ошибке, некоторые предложения по решению проблемы, трассировку и дамп переменных среды выполнения. Рекомендуется включать эту опцию только на этапе разработки. После её окончания удалите или закомментируйте в .htaccess эту опцию.
При разработке любого сайта или приложения разработчики допускают ошибки. По умолчанию, они записываются в папку logs, которая находится в корне сайта. Также, убедитесь, что у вас включена данная опция в панели управления. Во вкладке «Домены»→«Прикрепление домена», рядом с надписью «Лог-файлы веб сервера» есть переключатель, который включает/выключает данную опцию. После включения, логи начнут писаться в течение 5 минут (при обычной загруженности сервера).
Файлы restart.txt и always_restart.txt необходимы для того, чтобы при внесении вами каких-либо изменений в рабочие файлы (к примеру, app.js) Passenger, применяя правила записанные в .htaccess, мог перехватывать их и применять в работе сайта. Отличие заключается в том, что restart.txt сработает только один раз, а always_restart.txt перезапускает процесы веб-сервера при каждом поступившем запросе. Рекомендуется использовать always_restart.txt только при разработке. После того, как разработка проекта будет завершена, не забудьте удалить этот файл, чтобы избежать задержек при отображении страницы посетителям.
Если Вы уверены в том, что ваш код работает без багов, но всё-равно видите ошибки на странице, можно принудительно завершить все процессы с помощью следующей команды через SSH-соединение:
После чего перезагрузить страницу.
И напоследок, осталось добавить скрипт для запуска Node в app.js. Ниже представлен код с официального сайта Node.js (в дальнейшем вы можете изменять его по своему усмотрению, сейчас мы лишь хотим убедиться, что всё работает):
Итак, все настройки произведены. Откройте сайт в новой вкладке. Если выводится Hello world, то всё работает, как и ожидалось. В противном случае, ещё раз пройдите по вышеприведённому алгоритму действий. Возможно, вы что то упустили.
Чтобы установить какой-либо модуль в директорию с файлами приложения, при этом используя установленную версию Node.js, необходимо для начала прописать путь до исполняемого файла node в .bash_profile (он лежит в корне вашего аккаунта). После этого вы сможете обращаться к нему из любой директории вашего проекта.
Итак, откройте .bash_profile и допишите следующую строку:
Для примера, рассмотрим подключение модуля mysql для работы с базой данных (предварительно, создайте таблицу под любым названием и поместите туда несколько записей). Чтобы установить даный модуль, зайдите через SSH-соединение в директорию «nodejs_app/www» и введите в терминале команду:
Таким обазом создастся файл package.json с данными о вашем приложении. После этого наберите команду:
Вы увидите, что автоматически создастся новая директория «node_modules» и подгрузятся необходимые нам для работы файлы.
Также, рекомендуем загрузить 2 часто используемых модуля — fs (для работы с файлами) и util (для красивого вывода объектов в консоль)
Далее, открываем файл нашего приложения app.js и добавляем следующий код:
В коде выше мы, с помощью модуля fs, создаём новый файл debug.log, в который будем помещать вывод функции console.log
Далее, переопределяем саму функцию console.log, задействуя поток на запись.
Теперь, при помощи модуля mysql, подключаемся к своей БД и выбираем все записи из нужной нам таблицы, прописывая их в созданный нами файл.
Проверим, всё ли сработало: перезагрузите страницу своего сайта и откройте файл debug.log — вы должны увидеть вывод всех записей из таблицы.
Для запуска приложений Node.js через crontab создайте shell скрипт и определите в нём переменную окружения PATH исходя из ваших требований, или можно указать полный путь к бинарному файлу nodejs и скрипту. Простейший Shell скрипт для запуска nodejs приложения:
Или команда для запуска целиком:
Удачной работы! Если возникнут вопросы — напишите нам, пожалуйста, тикет из панели управления хостингом, раздел «Помощь и поддержка».
Настройка Node.js
В статье будет рассмотрена настройка Node.JS.
Сначала необходимо подключится к аккаунту по протоколу SSH.
Подключение к аккаунту
Если Вы пользуетесь OS Windows, то, скорее всего, Вам подойдет SSH-клиент PuTTy (статью по настройке можно прочитать здесь). Когда настроите, можно переходить на шаг 2.
Если Вы пользуетесь OS Linux или OS X, подойдет обычный терминал, который присутствует во всех Unix-подобных операционных системах. Подключиться можно следующей командой:
Где username — логин, username.beget.tech — адрес сервера (посмотреть его можно в блоке Техническая информация на главной странице панели управления).
Переход в Docker
Далее нужно перейти в виртуальное окружении Docker. Запуск Node.js осуществляется только внутри Docker контейнера. Для этого, после подключения по SSH необходимо ввести команду:
А также ввести свой пароль для подключения к SSH. В строке терминала будет отображено, что теперь мы находимся в Docker окружении:
На хостинге уже установлены Node.js и npm.
Установка Node.js другой версии
На данный момент, на виртуальном хостинге, максимальная поддерживаемая версия — 17.9.1. NodeJS версии 18.0 и выше работать не будет.
Учитывайте эту информацию при выборе версии.
Установка Node.js производится в каталог .local Вашей учётной записи:
Загрузим дистрибутив и распакуем его:
Удалите загруженный дистрибутив:
/.local.
Инструкция по предоставлению общего доступа приведена в этой статье.
Создание каталога проекта
Теперь нужно перейти в каталог сайта, в рассматриваемом примере имя каталога — node:
Необходимо создать каталог для проекта и вложенный в него каталог tmp, в рассматриваемом примере имя каталога — HelloWorld:
Для корректной отдачи статического контента средствами Nginx создается ссылка public, указывающая на public_html:
С помощью любого текстового редактора (например, nano или vim) необходимо создать файл app.js в каталоге проекта HelloWorld со следующим содержимым:
Далее, если вы находитесь в каталоге проекта HelloWorld, необходимо вернутся в каталог node
Создание .htaccess
Затем нужно создать файл .htaccess. В общем виде его содержимое выглядит следующим образом:
Если вы установили новую версию NodeJS, то .htaccess будет следующим:
Если вы решили воспользоваться предустановленным NodeJS, то .htaccess будет следующим:
Для того, чтобы Passenger перечитал конфиг, необходимо создать файл tmp/restart.txt. Cделать это нужно в директории, указанной в качестве PassengerAppRoot в файле .htaccess ранее.
Для проверки работоспособности откройте сайт в браузере:
Также для проверки работоспособности можно выполнить следующую команду:
В листинге процессов присутствует модуль Apache Passenger.
Удачной работы! Если возникнут вопросы — напишите нам, пожалуйста, тикет из Панели управления аккаунта, раздел «Помощь и поддержка».
Хостинг Node.js https сервера с авто-обновляемым SSL в облаке и как я настроил цикл разработки (+ git, react)
Начну с того, что однажды мне захотелось создать приложение. Желание такое возникло из-за того, что я люблю читать, а нормальных книжных агрегаторов на просторах русского интернета просто нет. Собственно из боли поиска чего бы почитать и попыток вспомнить как называлась та книжка, которую я недавно читал и на какой же главе я остановился, родилось желание сделать веб-приложение, в котором всё это было бы возможно и удобно. Стоит отметить, что никакого опыта разработки, программирования и т.п. у меня не было, моя работа вообще с этим не связана. Тем не менее желание перебороло лень и переросло в конкретные действия, своеобразное хобби.
Не буду рассказывать как я изучал javascript, node.js, react, html, css и т.п., перейдём к тому, к чему я пришел на данный момент, чем хотел бы с вами поделится и, конечно, послушать конструктивную критику специалистов.
Как и многие я тренировался на собственном ПК на localhost:3000, создавал front/back-end’ы, верстал, работал с api и т.д., но меня всегда тревожила мысль а том, как же всё это потом перенести на хостинг? Будет ли оно работать? Нужно ли будет переписывать из-за этого код? И самое главное, нельзя ли всё настроить так, чтобы я мог работать над приложением с любого ПК и легко переносить всё на хостинг на production? Об этом я и расскажу.
Выбор хостинга
На своё хобби я готов был тратить 10$ в месяц, поэтому выбирал тот хостинг, с которым планировал и остаться в будущем. Как я и говорил, до этого у меня был 0 опыт, в том числе и с хостингом сайтов. Я попробовал и отказался от следующих:
Jelastic: красивый и удобный интерфейс, вроде всё интуитивно, масштабируемо и понятно. Тем не менее столкнулся с трудностями при настройке (nginx почему-то из vps не хотел работать, только их отдельным модулем) и подключении SSL(и автоматическом обновлении) к русскоязычном домену стандартными средствами (обещали баг пофиксить, но я не хочу ждать)
Облачный хостинг REG.RU: тут же у меня и домен, поэтому решение казалось логичным, однако у них не было отдельно настроенного PostgreSQL, а так как с администрированием базы мне связываться не хотелось, начал искать дальше.
AWS и Google облака: попробовал, всё вроде хорошо, но вспомнил про наши «замечательные» законы и требование размешать данные пользователей на сервера в РФ. У этих ребят, к сожалению, серверов в РФ не оказалось. Не юрист, но от греха решил поискать облака с серверами в РФ. Если же ваше приложение маловероятно будет иметь проблемы с законом, то хороший выбор.
Облака с серверами в РФ хоть и были, но хотелось всё же что-то, что избавит меня от необходимости погружаться в администрирование PostgreSQL. Порыв немного наткнулся на не так давно ставшие доступными Яндекс.Облака, попробовал, вроде всё просто и удобно, поэтому остановился пока на них. Стоит отметить, что хостинг PostgreSQL у них сразу идёт с 1core и 4гб RAM, что по стоимости около 2к рублей в месяц, поэтому на время разработки и невысокой нагрузки я планирую запустить PostgreSQL на VPS за
300р, а с повышением нагрузки перенести базу и пусть Яндекс занимается администрированием и обновлением.
Настройка Яндекс.Облака
Virtual Private Cloud
1) Создаём каталог под свой сайт:
2) Создаём Virtual Private Cloud:
Главное что он даёт для меня на текущем этапе — это IP для доступа к созданному ресурсу из вне. С подсетями, зонами, изоляцией и отказоустойчивостью ознакомился поверхностно, при необходимости наверстаю.
3) Создаём подсеть и присваиваем ей внутренний IP (как я понял, это примерно как локальная сеть)
4) Переходим на вкладку IP и резервируем себе статический IP.
По нему мы будем подключаться из дома и других мест. Вероятно можно и с динамическим работать, но я не разбирался в каких случаях он меняется.
Compute Cloud
Тут у нас будут происходить вычисления 🙂 То есть мы создадим виртуальную машину с Linux (я выбрал ubuntu 18.04), установим node.js приложения и postgreSQL.
Жмём создать ВМ, выкручиваем все настройки на минимум, так как при разработке нагрузки не будет (когда наше приложение выйдет в свет, тогда и подкрутим побольше, ну и будем мониторить по графикам).
Проблемный момент, с которым я столкнулся на этом этапе, это SSH:
Что это и зачем понятия не имел, поэтому пошел изучать. Оказалось — это просто метод доступа, но не по паролю, а по сгенерированному SSH ключу. Чтобы собственно его сгенерировать, скачиваем и устанавливаем Putty как нам советуют.
Запускаем C:\Program Files\PuTTY\puttygen.exe
Нажимаем кнопку Generate и водим мышкой, чтобы придать случайности сгенерированному ключа (как я понял). Далее копируем появившуюся строку начинающуюся с ssh-rsa куда-нибудь в текстовый файл и жмём Save private key, Save public key. Скопированный в текстовый файл ключ вставляем в поле SSH ключ открытой страницы Яндекса. Логин указываем root, иначе у вас не будет доступа при работе с графической файловой системой приложения по которому будете подключаться к облаку из дома/работы (возможно и есть способ, но я не разбирался).
Как заметил andreymal, лучше не использовать root, чтобы китайские боты не подобрали пароль к вашему облаку, но так как в яндекс.облаке доступ только по SSH, то жить вроде можно.
Приложение на хостинге же стоит запускать исключительно не root пользователем, чтобы не позволить злоумышленникам выполнять вредный код через возможные уязвимости в вашем приложении.
Подключаемся к облаку с ПК и выбираем бесплатный SSH клиент
Стандартный Putty позволяет работать только командной строкой, а так как мне пользователю windows это непривычно, то я начал искать клиент с псевдо-проводником. Сначала я попробовал Mobaxterm, но он после какого-то времени простоя отключается, проводник вообще зависает, поэтому сейчас работаю с bitvise ssh и пока проблем как у Mobaxterm не наблюдаю.
Настройка bitvise ssh
Тут в поле Server>Host указываем наш внешний IP облака. Порт 22. Нажимаем client key manager>import указываем в нём сгенерированный Putty ранее private ключ. Может ещё потребоваться ключевая фраза, выберите что-нибудь что не забудете. Закрываем это окошко и в поле authentication указываем username: root, method publick key, client key — выбираем импортированный ранее. Жмём login и если мы всё сделали правильно, то подключимся к облаку:
Устанавливаем Node.js
Тут я рекомендую пользоваться инструкциями digitalocean.com, они очень подробны и многие есть на русском. Обычно я так и гуглю «digitalocean ubuntu 18.04 node.js» или что вы там захотите установить или настроить.
Как установить Node.js можно почитать тут.
Если коротко, то заходим на nodesource (тут последние версии node.js можно установить), листаем сюда:
Копируем и по-очереди запускаем команды:
Проверяем как установилось командой
Нам покажет версию node.js
Нам покажет версию менеджера пакетов для node.js.
Далее идём в папку /opt/mysuperapp (my_super_app_name — эту папку вы должны создать). Каталог opt был выбран в качестве места расположения приложения после долгих гуглений «где уместно положить файлы node.js приложения в ubuntu».
Наконец-таки создаём файл server.js, который будет входной точкой приложения и вставляем туда код простого сервера на node.js:
Порт 80 — это для http запросов, 443 — для https. Пока у нас сервер на http.
Сохраняем всё и запускаем командной:
В консоли должно появиться строка ‘Server running at localhost:80/’
Теперь можно открыть браузер, ввести внешний IP (тот что в облаке яндекса у вашей ВМ ubuntu) и мы увидим «Hello World!»
Делаем всё удобно или цикл разработки с помощью git
Всё вроде работает, но мы же не будем работать всё время подключаясь к облаку. К тому же вдруг мы будем в будущем работать не одни.
Github
Github — это место, где будет лежать код нашего приложения. Если коротко, принцип работы для одного человека следующий:
- На домашнем ПК разрабатываем наше приложение.
- Сохраняем и в один клик выгружаем код на Github.
- На хостинге или на другом ПК скачиваем наше приложение с github, перезагружаем сервер (если это хостинг) и новая версия нашего веб-приложения доступна во всемирной паутине.
Собственно регистрируемся на Github и создаём private репозиторий для нашего приложения (он будет доступен только нам):
Копируем строку github.com/ReTWi/mysuperapp.git для скачивания приложения.
- Возвращаемся в командную строку bitvise, останавливаем приложение нажав ctrl+c (если оно ещё работает).
- Переходим в каталог /opt и удаляем созданную нами папку с приложением
Проверяем всё ли хорошо установилось:
Должна показаться версия git.
Заполняем данные git (так и не понял зачем, но видимо могут быть какие-то занудные предупреждения).
Наконец-таки загружаем наше приложение на хостинг командой:
(тут должна быть ссылка на ваше приложение )
В каталоге /opt появится новый mysuperapp, где будут находится файлы нашего приложения загруженные из github.
Теперь пора повторить тоже самое для ПК и замкнуть цепочку ПК(разные) —> Github —> Хостинг
Visual studio code
Для начала выберем редактор исходного кода, где будем работать. Я выбрал Visual studio code, так он прост, удобен, в нём много плагинов и можно настроить синхронизацию настроек если вы работаете с нескольких устройств. Собственно скачиваем, устанавливаем, запускаем, выбираем общую папку приложений, так как git clone создаст нам свою.
Плагины я использую следующие:
Устанавливаем git для ПК.
Открываем консоль в VScode с помощью ctrl+shift+` или terminal>new terminal
В консоли windows плохо с русскими символами и чтобы не было крякозяблов нужно открыть file>preferences>settings, ввести в поле terminal.integrated.shellArgs.windows, нажать
И добавить строку «terminal.integrated.shellArgs.windows»: [«-NoExit», «/c», «chcp 65001»],
Повторяем команду для загрузки файлов с github:
В VScode нажимаем File>Open Folder и открываем папку нашего приложения.
Создаём файл server.js с тем же кодом простого сервера:
Устанавливаем nodemon для автоматической перезагрузки сервера при изменениях в коде:
i — сокращение от install
g — глобальная установка (чтобы было доступно в консоли), а не только для нашего приложения.
Открываем в браузере localhost:80/ или просто localhost:80 и видим Hello World.
Теперь настало время проверить нашу цепочку ПК>Github>Hosting.
Скачиваем Github desktop для большего удобства, подключаем свой github аккаунт, затем нажимаем файл add local repository и указываем каталог нашего приложения.
В приложении мы видим изменения которые мы сделали по сравнению с загруженной с Github версией (мы добавили server.js):
Жмём «commit to master»>«push origin», таким образом загружая файлы с ПК на Github.
Заходим в браузере на наш github аккаунт и видим загруженный файл server.js:
Потренируемся ещё немного, в VScode заменим строку «res.end(‘Hello World !\n’);» на «res.end(‘OmNomNom’);». Увидим, что сервер сам перезагрузился:
Проверим в браузере и увидим там сделанные нами изменения «OmNomNom».
Desktop github тоже покажет нам что мы поменяли строку:
Опять жмём «commit to master»>«push origin», чтобы отправить файлы на github.
Переключаемся на командную строку хостинга.
Останавливаем наше приложение, если оно ещё запущено (ctrl+c).
Скачиваем наше обновлённое приложение командами:
Первая сохранит наши данные, чтобы постоянно не вводить логин и пароль. В дальнейшем нам достаточно будет git pull.
Установим pm2 — нечто похожее на nodemon, только для хостинга:
Запустим приложение с помощью pm2, которые при следующем git pull на хостинге сам перезагрузит наш сервер:
Откроем браузер по нашему внешнему IP облака и увидим наше «OmNomNom».
Таким образом мы замкнули цепочку работы с приложением и быстрым его развёртыванием на хостинге.
Создаём временные SSL сертификаты для HTTPS на localhost и хостинга
В поле domains, ip… вписываем сначала localhost, нажимаем generate и скачиваем 2 файла по кнопке:
Сохраняем их у нас в проекте в папке ssl/localhost.
Повторяем процедуру для внешнего IP Облака и сохраняем в ssl/myapp.
Запускаем более сложный https сервер node.js
- client — тут будет лежать наш front-end. У меня react.
- logs — сюда будут падать логи на хостинге
- node_modules — модули node.js
- private — ваши приватные файлы, я там храню SSH доступы к облаку
- server — ваш backend
- ssl — ssl сертификаты для работы https на localhost и на хостинге
- .babelrc — настройки сборки react приложения webpack’om (позволяет использовать более современный JS при разработке frontend)
- .gitignore — файлы, которые не будут перемещаться на github (git их как бы не видит)
- client.js — точка входа для генерации react сборки
- package.json — используемые вами node_modeles и различные снипеты команд.
- package-lock.json — изменения в модулях (насколько я понял, по файлу будет проверяться одинаковые ли у вас установлены модули на хостинге и на ПК).
- pm2-watch.json — настройки запуска pm2 для хостинга
- README.md — обложка для github
- server.js — точка запуска нашего backend сервера Node.js
- webpack.config.js — конфигурация сборки react
.gitignore
Тут мы указываем те файлы/папки, которые мы не хотим выгружать на github. Они будут только на данном устройстве и git не будет отслеживать/показывать их изменения. Открываем и вставляем:
Так как github не выгружает пустые папки, то можно внутрь что-нибудь положить, к примеру пустой файл .gitkeep. Сохраняем файл и закрываем.
package.json
Открываем и вставляем следующее (после // добавил комментарии)
Остановлюсь на двух основных фрэймворках/библиотеках выбранных для приложения:
Fastify был выбран в качестве альтернативы express.js, так как в первом уже есть экспериментальная поддержка htpp2, он активно развивается и мне кажется у него больше будущего, нежели у express.js, который стал очень неповоротлив и кое-как развивается. С другой стороны express.js уже долгое время в работе и по нему вам легче будет найти информацию.
React был выбран так как мне с ним было проще работать, понять и пробовать всё своими руками. Vue — показался уже чем-то со своими правилами, направлением. Хотя во Vue может и меньше придётся писать что-то своими руками, но так как приоритет сделан на обучении и для человека ранее не программировавшего react пошел как-то легче.
Сохраняем файл package.json и устанавливаем все модули указанные в dependencies командой:
У нас появится папка node_modules, в которой будут все модули для нашего приложения.
client — пока пустая папка
logs — внутри лежит файл .gitkeep, чтобы папка перекочевала на хостинг и логи успешно туда падали. При разработке мы всё будем выводить в консоль.
public
Тут статические файлы нашего сайта будут лежать, изображения там, фавиконки и т.д.
Отдельно остановимся на двух файлах:
index.html:
— тут у нас подгружается react-фронтэнд и рендерится в тег по его id.
isProd.js содержит единственную строку «module.exports = false»
Так как он находится в исключениях .gitignore, то не переносится. Соответственно на ПК мы устанавливаем его в false, а на хостинге в true. Затем используем этот файл, чтобы понять в какой мы сейчас среде (разработка/продакшн). Мне показалось наиболее удобным, к тому же можно частично в коде поменять при разработке и проверить работу модулей в продакшне.
ssl — там лежат сохранённые ранее сертификаты в папках localhost и myapp
.babelrc
Настройки для создания нашего react_bundle с поддержкой браузеров используемых более >0.25% пользователей.
client.js
Рендерит наш фронтэнд в div с тегом cookies.
pm2-watch.json — позволяет на хостинге командой «npm run server» запустить сервер с отслеживанием изменений в коде и автоматической перезагрузкой.
webpack.config.js
Сборщик реакт приложения:
Если коротко, то он открывает файл client.js и все что у него внутри, собирая react_bundle и помещая его в папку public, откуда потом через открытый index.html он будет загружен.
server.js
Папка server
Тут лежит на бэкэнд и все пути.
logger.js — в зависимости от среды isProd логирует или в консоль или в errors.log
server/api/
open.js — сюда добавляем наши пути.
После настройки и проверки всего на Localhost, просто выгружаем всё на github, а оттуда git pull на хостинг. Всё что на хостинге нужно будет сделать, это установить модули node.js командой «npm i» и создать файл isProd.js
Автоматически обновляемый SSL
Когда вы купите себе домен и привяжете его к IP облака, пример инструкции для REG.RU, можно установить на сервере автоматически обновляемый бесплатный SSL для работы сайта по https.
Наш сервер работает без nginx. Возможно он понадобится нам в будущем как балансировщик нагрузки или более быстрый HTTP-сервер для раздачи статических файлов, но пока необходимости я в нём не вижу. Балансировка нагрузки пока нам не требуется, а касательно скорости раздачи статики сравнений я не нашел.
Перед установкой в папке ssl создадим папку .well-known, а в ней acme-challenge. Получится /opt/myapp/ssl/.well-known/acme-challenge
Для установке на сервере с node.js без nginx автоматически обновляемого SSL переходим по ссылке. По очереди выполняем команды в консоли хостинга:
Выбираем второй способ проверки, который разместит в папке /opt/myapp/ssl/.well-known/acme-challenge определённый файл, а после подтверждения владельца сервера его удалит.
Указываем по запросу наш домен, к примеру: «example.com» и путь к ssl папке нашего приложения (сервер настроен так, что отдаст созданный ботом файл) «/opt/myapp/ssl».
Бот сам настроит cron-задачу для обновления сертификата до срока его истечения в течение 90-дней.
Не думал, что займёт столько времени всё написать, к 4 часам ночи уже мог что-то упустить :/
Интересно мнение хабравчан и специалистов, кто осилил это полотно или прочитал какие-то отдельные моменты. Как у вас устроен цикл разработки? Есть ли какие-то моменты в которых я ошибаюсь или поступаю не лучшим образом?