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

Купил сервер на хостинге 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