Аренда сервера за крипту ⇪

Купил сервер на хостинге hostry.com за 6 баксов в месяц. Этот сервис принимает криптовалюту в качестве платёжного средства, поэтому оплатил с помощью BTC. Hostry сотрудничает с какими-то coinpayments, которые собирают какую-то комиссию. С перевода $10 получился $1 комиссии, надеюсь, что это не 10%, а фиксированная или какая-то логарифмическая шкала, а иначе — ужас-ужас.

Оплачивал с помощью кошелька Electrum, относительно удобная штука. Есть приложения для всех платформ.

Настройка сервера и Nginx ⇪

После покупки сервера администратору чаще всего предоставляется доступ к нему по протоколу SSH и пароль от root. Доступ к серверу по паролю обыкновенно считается небезопасным, поэтому предпочтительнее настроить доступ по криптографическому ключу.

Nginx — это самый популярный на данный момент веб-сервер в Интернете. Самая базовая его установка на сервер осуществляется буквально в одну команду:

sudo apt install nginx

Настройка сервера Nginx после нескольких попыток сводится к редактированию файлов в директории /etc/nginx/sites-available/.

Создадим файлик в этой директории, назовём его my-server. В этом файлике нужно будет прописать следующий текст:

server {

        server_name www.project.ru;
        # root /var/www/my-project;
        # index index.html;

        location / {
                include proxy_params;
                proxy_pass http://unix:/tmp/project.sock;
                # try_files $uri $uri/ =404;
        }

Давайте разбираться, что здесь что. Файлы конфигурации Nginx состоят из директив — прямых команд серверу и контекстов — групп команд из директив, ограниченных фигурными скобками.

У меня тут задан один контекст server и в нём прописана директива server_name project.ru. В этой директиве нужно будет указать название вашего сервера и его доменное имя.

Следом идут две закомментированные директивы, которые нужны в случае, когда веб-сервер просто поставляет файлики из какой-то директории пользователю по запросу. Директива root указывает путь к проекту, а директива index — основную веб-страницу. Поскольку мой сайт работает как веб-приложение на Flask (о чём далее), то мне эти директивы не нужны.

Контекст location / говорит что делать, когда пользователь обращается по корневому адресу нашего домена. В закоменнтированной строке вновь указана директива в случае простого веб-сайта из веб-страниц. В моём случае указаны две директивы. Директива include подключает внешние директивы, а proxy_pass указывает куда передать запрос, поступивший на /. В данном случае он уходит на специальный файлик на сервере.

После того, как первоначальная конфигурация сервера закончена, необходимо создать символическую ссылку на эту конфигурацию в директории sites-enabled:

ln -s /etc/nginx/sites-available/<your-config> /etc/nginx/sites-enabled/<your-config>

Не забудем удалить конфигурацию default, которая находится в sites-enabled по умолчанию. После изменения и применения настроек нужно обязательно перезапускать сервис Nginx:

sudo nginx -s reload

Покупка доменного имени и настройка DNS ⇪

Доменное имя я покупал на reg.ru. Получилось дёшево и сердито, суммарно вышло в 199 рублей на год. Там нужно оставить свои персональные данные и скан задницы выслать, но, судя по всему, везде так. В противном случае домены уводятся, и доказать, что это твой домен, не получится.

Дальше нужно было зафиксировать, что теперь имя brink-liaison.ru указывает на мой сервер. Для этого в сервисе reg.ru после покупки домена нужно было указать ресурсные записи, а именно www -> <ip-адрес сервера>. Затем можно подождать 24 часа, пока ресурсные записи во всей системе DNS изменятся и начнут указывать на нужный сервер, а можно походить по ссылочкам отсюда и потыкать везде "flush".

В процессе выяснилось, что, оказывается, поисковики считают www.domain и domain разными доменами. Поэтому, чтобы было получше для SEO (я пока не разобрался), рекомендуют настроить перенаправление от чего-то одного к другому. Немного почитав мануалы, мне показалось, что правильнее будет настроить перенаправление от brink-liaison.ru к www.brink-liaison.ru. А для этого нужно будет немного пошаманить в настройках Nginx (см. выше). А именно нужно будет в том самом файле конфигурации /etc/nginx/sites-available/my-server добавить следующий контекст:

server {
        server_name project.ru
        return 301 $scheme://www.project.ru$request_uri;
}

Здесь нужно обратить внимание на то, что project.ru теперь без поддомена www. и, по существу, этот контекст отвечает за перенаправления всех запросов, попавших на project.ru в аналогичный URL на домене www.project.ru

Настройка HTTPS ⇪

Оказалось, что сделать это совсем несложно. Идём на Let's Encrypt, скроллим до "With Shell Access", переходим по ссылке на Certbot, выбираем там свою систему (моя — Nginx на Ubuntu 20.04) и далее следуем инструкциям.

Certbot сам всё сделает, сформирует запрос, получит сертификат, сам его пропишет в нужные контексты в конфиге Nginx. Одно удовольствие.

Python и Flask ⇪

Сайт сделан на Flask с использованием дополнительной библиотеки Flask-FlatPages. Этот сайт представляет собой набор Markdown-файлов, которые рендерятся в готовые HTML-страницы. Оформление сделано с помощью библиотеки Flask-Bootstrap с минимальными изменениями в CSS.

Для текстового блога пока подходит. Дополнительно, естественно, можно будет навертеть любую желаемую функциональность, хоть приложения в Dash

GitHub и cron ⇪

У меня есть локальные репозитории, где я редактирую Markdown-файлики и потом пушу их в удалённый приватный репозиторий на GitHub. На сервере же настроена кронджоба, которая каждый час делает git pull с этого удалённого репозитория и перезапускает WSGI-сервер.

Чтобы настроить кронджобу используется утилита crontab. Пользуясь сайтом crontab.guru, можно подобрать нужную периодичность для обновления. Команда в кронджобе в конечном итоге выглядит так:

30 * * * * /path/to/my/shell/script.sh

А скрипт, который выполняется каждый час на тридцатой минуте выглядит вот так:

#!/bin/bash
cd /path/to/project/
git pull
systemctl restart project.service