Yucca CCTV

Setup Nginx + Let's Encrypt reverse proxy before Yucca

2023-09-29T09:41:33.504Z

In this tutorial I will describe how to set up Nginx and issue a Let's Encrypt SSL certificate that will be automatically renewed. Nginx will act as a simple Web server in front of Yucca to terminate the SSL session and redirect from port 80 to 443.

Why install Nginx at all, since Yucca itself can terminate SSL and even has flags? This is true, but when you occupy port 443 it will be inaccessible to other software, you will have to use some other one, and there will also be no redirect from HTTP to HTTPS - if this suits you, then you can safely skip the section with installing and configuring Nginx Step 1 and go straight to Step 2 .

I will do all the steps on Ubuntu Server 22.04, but everything will work the same on SUSE, CentOS, Fedora, Debian and so on. Unless everyone will have their own package manager, but I hope you can tell the difference between apt and zypper :)

Step 0. Preparation

And so we need:

Host with a white IP address
Domain or subdomain that looks at this address
Yucca installed

In the instructions I will use the domain foobar.yuccastream.com , your domain will be different.

nslookup foobar.yuccastream.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	foobar.yuccastream.com
Address: 128.140.2.103

So I have Yucca, which is available at http://foobar.yuccastream.com:9910

Step 1. Install and configure Nginx

Install nginx:

sudo apt install nginx

Check http://foobar.yuccastream.com

Next, create a configuration file for Yucca:

sudo nano /etc/nginx/conf.d/yucca.conf

⚠️ You need to replace the domain foobar.yuccastream.com with your own.

upstream yucca_upstream {
  server 127.0.0.1:9910 fail_timeout=0;
}

server {
  listen 80;
  server_name foobar.yuccastream.com;
  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://yucca_upstream;
  }
}

Save the file and check the configuration is correct:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

If everything is correct you will see syntax is ok

Update nginx configuration:

nginx -s reload

We refresh the page and see the Yucca web interface http://foobar.yuccastream.com

Step 2. Install Certbot and issue a letsencrypt certificate

Install packages:

sudo apt install certbot python3-certbot-nginx

We issue a certificate for our domain:

⚠️ You need to replace the domain foobar.yuccastream.com with your own.

sudo certbot --nginx -d foobar.yuccastream.com

Certbot will ask you to enter your E-mail (1), I recommend entering your real mailbox, if the certificate expires and does not renew automatically Let's Encrypt will send you a notification about this. You will also need to agree to the terms and conditions (2), (3). Next, certbot itself will find the required configuration file with the required domain, configure the SSL section and redirect, and show you a link at the output.

You can see what happened in the end in the file /etc/nginx/conf.d/yucca.conf

upstream yucca_upstream {
  server 127.0.0.1:9910 fail_timeout=0;
}

server {
  server_name foobar.yuccastream.com;
  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://yucca_upstream;
  }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/foobar.yuccastream.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/foobar.yuccastream.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = foobar.yuccastream.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    server_name foobar.yuccastream.com;
    return 404; # managed by Certbot
}

I recommend checking that certbot has created a timer for certificate renewal, it must be active:

sudo systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Fri 2023-09-22 11:54:02 UTC; 7min ago
    Trigger: Fri 2023-09-22 14:13:25 UTC; 2h 11min left
   Triggers: ● certbot.service

Sep 22 11:54:02 foobar systemd[1]: Started Run certbot twice daily.

We update the page http://foobar.yuccastream.com and see that everything works via HTTPS, the redirect also works.

Step 3. Security setup

We configured access via HTTPS via nginx, but Yucca is still available via HTTP at http://foobar.yuccastream.com:9910 . This is due to this default setting:

listen_address = ":9910"

Go to the Yucca configuration file and edit this parameter:

sudo nano /opt/yucca/yucca.toml

We make Yucca listen only to localhost:

listen_address = "127.0.0.1:9910"

And reboot the Yucca server:

 sudo systemctl restart yucca

We check, now there is nothing at http://foobar.yuccastream.com:9910 , but here https://foobar.yuccastream.com everything works.

Thanks for using Yucca :)

If you have any questions, you can ask them in our community chat on Telegram @yuccastream or email us at info@yucca.app

Настройка Nginx + Let's Encrypt обратный прокси перед Yucca

2023-09-22T13:53:25.654Z

В этой инструкции я опишу как настроить Nginx и выпустить Let's Encrypt SSL сертификат, который будет автоматически продлеваться. Nginx будет выступать как простой Web сервер перед Yucca для терминации SSL сессии и редиректа с 80 на 443 порт.

Зачем вообще устанавливать Nginx, ведь Yucca и сама может терминировать SSL и даже флаги есть? Это верно, но когда вы займёте 443 порт он будет недоступен для другого ПО, придется использовать какой-то другой, а так же не будет редиректа с HTTP на HTTPS – если вас это устраивает, то можете смело пропускать секцию с установкой и настройкой Nginx Шаг 1 и сразу перейти на Шаг 2.

Все действия я буду проделывать на Ubuntu Server 22.04, но всё тоже самое будет работать и на SUSE, CentOS, Fedora, Debian и так далее. Разве что пакетный менеджер у всех будет свой, но я надеюсь вы отличите apt от zypper :)

Шаг 0. Подготовка

И так нам понадобится:

Хост с белым IP адресом
Домен или поддомен который смотрит на этот адрес
Установленная Yucca

В инструкции я буду использовать домен foobar.yuccastream.com, ваш домен будет отличаться.

nslookup foobar.yuccastream.com
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
Name:	foobar.yuccastream.com
Address: 128.140.2.103

Итак у меня есть Yucca, которая доступна по адресу http://foobar.yuccastream.com:9910

Шаг 1. Установка и настройка Nginx

Устанавливаем nginx:

sudo apt install nginx

Проверяем http://foobar.yuccastream.com

Далее создаём конфигурационный файл для Yucca:

sudo nano /etc/nginx/conf.d/yucca.conf

⚠️ Домен foobar.yuccastream.com вам нужно заменить на свой.

upstream yucca_upstream {
  server 127.0.0.1:9910 fail_timeout=0;
}

server {
  listen 80;
  server_name foobar.yuccastream.com;
  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://yucca_upstream;
  }
}

Сохраните файл и проверьте корректность конфигурации:

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Если всё корректно вы увидите syntax is ok

Обновляем конфигурацию nginx:

nginx -s reload

Обновляем страничку и видим уже веб интерфейс Yucca http://foobar.yuccastream.com

Шаг 2. Установка Certbot и выпуск letsencrypt сертификата

Устанавливаем пакеты:

sudo apt install certbot python3-certbot-nginx

Выпускаем сертификат для нашего домена:

⚠️ Домен foobar.yuccastream.com вам нужно заменить на свой.

sudo certbot --nginx -d foobar.yuccastream.com

Сertbot попросит ввести E-mail (1), рекомендую ввести ваш реальный ящик, в случае если сертификат будет истекать и не продлиться автоматически Let's Encrypt пришлёт вам об этом уведомление. Также нужно будет согласится с условиями и правилами (2), (3). Далее certbot сам найдёт нужный конфигурационный файл с нужным доменом, настроит секцию с SSL и редирект, на выходе покажет вам ссылку.

Можете посмотреть что в итоге получилось в файле /etc/nginx/conf.d/yucca.conf

upstream yucca_upstream {
  server 127.0.0.1:9910 fail_timeout=0;
}

server {
  server_name foobar.yuccastream.com;
  location / {
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://yucca_upstream;
  }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/foobar.yuccastream.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/foobar.yuccastream.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = foobar.yuccastream.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

    listen 80;
    server_name foobar.yuccastream.com;
    return 404; # managed by Certbot
}

Рекомендую проверить, что certbot создал таймер для продления сертификата, он должен быть активен:

sudo systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Fri 2023-09-22 11:54:02 UTC; 7min ago
    Trigger: Fri 2023-09-22 14:13:25 UTC; 2h 11min left
   Triggers: ● certbot.service

Sep 22 11:54:02 foobar systemd[1]: Started Run certbot twice daily.

Обновляем стринцу http://foobar.yuccastream.com и видим что всё работает уже через HTTPS, редирект тоже работает.

Шаг 3. Настройка безопасности

Мы настроили досту по HTTPS через nginx, но Yucca до сих пор доступна по HTTP на адресе http://foobar.yuccastream.com:9910. Это связанно вот с этой настройкой по умолчанию:

listen_address = ":9910"

Идём в конфигурационный файл Yucca и правим этот параметр:

sudo nano /opt/yucca/yucca.toml

Делаем так, чтобы Yucca слушала только localhost:

listen_address = "127.0.0.1:9910"

И перезагружаем сервер Yucca:

 sudo systemctl restart yucca

Проверяем, теперь по адресу http://foobar.yuccastream.com:9910 ничего нет, а тут https://foobar.yuccastream.com всё работает.

Спасибо что используете Yucca :)

Если у вас есть какие либо вопросы вы можете задать их в нашем чате сообщества в Телеграм @yuccastream или нам на почту info@yucca.app

Как мы тестировали платежи, а в итоге сделали свой ngrok

2023-08-26T08:16:53.754Z

Способов интеграций с платежной системой бывает несколько, мы используем самый простой и очевидный – получение сообщения о проведенном или отмененном платеже на публичный endpoint нашего сервиса или просто – webhook.

Процесс выгляди так:

пользователь кликает по кнопке Купить
мы получаем событие, создаем счет на оплату в платежной системе
создаем счет на оплату в своей системе
перенаправляем пользователя в платежную систему

Если пользователь совершил платеж или отменил его, мы получаем статус от платежной системы с указанием номера счета с которым дальше и работаем - обновляем статус или реализуем саму покупку товара.

В реализации нет никаких сложностей – изучаем документацию платежной системы, реализуем нужные методы, публикуем, проверяем. Но что делать если документация сервиса не очень хороша, клиента под нужный язык нет или он не поддерживается, ну или просто хотим удостовериться, что все работает корректно до того, как это представить пользователям? Для получения событий, отправляемых платежной системой, нам нужно иметь какой-то endpoint, который был бы доступен публично, в случае тестовых сред или производственного окружения с этим никаких проблем нет, теперь надо разобраться, как организовать локальное окружение, которое бы позволяло комфортно вести разработку.

Вариант 1. Использовать свой IP-адрес

Тут может быть стразу несколько сложностей. Во первых сейчас мы живём в 2023-м году, а значит ipv6 ещё не заменил ipv4 и дефицит публичных IP адресов остаётся актуальной проблемой. От сюда проблема- публичного адреса нет и провайдер не может его дать, так как сам во всю использует CGNAT. Но даже если есть публичный IP тогда вам нужен маршрутизатор в настройках которого вы сможете настроить проброс порта на свою локальную машину. Если же вы решили пойти поработать в кафе, то это становится не возможно в принципе.

Плюсы

бесплатно

Минусы:

нужен публичный IP адрес
маршрутизаторы разные отсюда могут быть разные ограничения
сложность настройки самому
при изменении места работы меняется адрес
платежной системе может быть нужен SSL

Вариант 2. Разрабатывать в облаке

Разработкой в облаке уже никого не удивишь, есть такие решения как Telepresence, Garden, DevSpace, okteto. Типичный процесс работы с подобными системами выглядит следующим образом – я создаю какой-то файл-манифест, в котором описываю свой проект и способ его развертывания, запускаю какую-то команду up, стенд поднимается, мне предоставляется публичная ссылка, по условной команде dev мой сервис, запущенный в облаке, переключается в режим разработки – открываются нужные порты в облачную среду, запускается синхронизация файлов, теперь я могу зайти внутрь этого виртуального окружения и запускать/отлаживать свое приложение.

Плюсы:

статичные адреса для окружений – это удобно при интеграции с платежными системами, где надо указывать адрес входящих сообщений об изменении статуса платежа
все уже настроено и работает
изолировано от локального окружения, более безопасно
многокомпонентные проекты проще тестировать
можно запускать сколько угодно тестовых стендов
не нужно переживать за поддержку инструмента

Минусы:

для старта могут потребоваться дополнительные узкоспециализированные знания
в случае бесплатных решений – нужно самому сопровождать
в случае платных решений – стоят деньги, в режиме экономии подобные сервисы вряд ли будут в приоритете
сложность в отладке проблем

Вариант 3. Использовать готовый сервис

Еще один вариант – открывать туннель в свою локальную сеть, чтобы все запросы на публичный адрес попадали напрямую в мой сервис. Тут тоже разнообразие сервисов и, наверное, самый известный – это ngrok, есть еще inlets, tunnelin, localxpose.

Работают эти все решения по одному принципу – некоторый консольный клиент при запуске подключается к какому-то публичному хосту и открывает сессию, которой присваивает публичный адрес, запрос пользователя к этому адресу сначала идет на этот публичный хост, а потом через открытую с консольным клиентом сессию попадает в уже пользовательский сервис.

Плюсы:

статичные адреса
удобство локальной разработки – мы просто предоставляем публичный доступ к конкретному порту сервиса, никакая синхронизация не нужна, никакие дополнительные среды для этого поднимать не надо, все локально
легковесное решение – клиент предоставляется в виде консольного приложения под любые архитектуры и операционные системы

Минусы:

статичные адреса только по платной подписке
ограниченное время работы туннеля в бесплатном режиме
если вы в России и у вас нет не российской карты, вы не можете купить подписку

Вариант 4. ngrok своими руками (грубо говоря)

Можно арендовать свой небольшой сервер у любого провайдера и пробрость порт по SSH. Технические детали описывать не буду, статей на эту тему много, например тут.

Плюсы:

статичные адреса
относительно дёшево
распространенное решение, много статей на эту тему и если возникнет проблема, с большой долей вероятности можно найти ответ на Stack Overflow

Минусы:

нет автоматизации процесса

нужен SSH клиент на рабочей станции, с Windows будет сложно
платежной системе может быть нужен SSL

Результат

В итоге недолгих обсуждений мы решили и сделали свой сервис – tuna, у него низкая цена относительно конкурентов, статичные домены, встроенный файловый и SSH-сервер – в целом все, что нам самим может пригодиться в работе.

Работать с сервисом несложно – после первичной настройки запускаем команду tuna http 8080 и получаем ссылку на наш сервис, которую и используем в конфигурации платежной системы тестового магазина:

Чтобы получить статичный домен нужно передать соответствующий флаг, поэтому запускать нужно так – tuna http 8080 --subdomain=my-service-lev, команда стала чуть больше, но все еще понятна, однако каждый раз вспоминать порт сервиса и привязанный к оплате домен неудобно, поэтому дополнительно локально мы используем такой инструмент как direnv.

Все наши серверные приложения конфигурируются с помощью переменных окружения, поэтому мы взяли за правило в каждом репозитории создавать файл .envrc, который содержит неперсонализированные настройки тестовой среды, которые актуализируются и применяются при каждом запуске сервиса, вот пример содержимого такого файла:

export SERVER_ENVIRONMENT=local

# Чтение файла .env
dotenv

При каждом запуске мы даем понять сервису, что он работает в локальном окружении, поэтому часть функционала расширена или просто отключена. Последней строкой мы даем понять direnv, что нужно прочитать пользовательские персонализированные настройки из файла .env – этот файл ни в коем случае не должен попасть в репозиторий, у каждого разработчика этот файл свой (проверьте содержимое .gitignore, что файл .env там указан), как правило в этом файле перечислены тестовые пароли, ключи, почтовые ящики.

Ну, а теперь соединяем все вместе, содержимое файла .envrc:

export SERVER_ENVIRONMENT=local
export TUNA_PORT=8080

# Чтение файла .env
dotenv

В добавленной строке мы даем понять tuna на каком порту работает наш сервис – это настройка универсальна для всех, поэтому храним в общем файле. А так выглядит содержимое моего файла .env:

export TUNA_SUBDOMAIN=my-service-lev

У каждого разработчика свой тестовый магазин и в нем задан свой адрес для получения входящих сообщений платежной системы, поэтому эту настройку храним в своем файле настроек.

Все готово, теперь при запуске команды tuna http я получу нужный статичный домен, который смотрит на нужный локальный сервис, осталось дело за малым – проверить что весь функционал оплаты работает корректно и отдать на ревью.

Есть у tuna и дополнительный полезный функционал, о нем расскажу ниже.

Инспектор запросов

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

Файловый сервер

Часто надо поделиться каким-то файлом и приходится загружать его в Google Drive или Telegram. Встроенный файловый сервер позволяет легко расшарить любой каталог на вашем компьютере, скопировать ссылку и дать её другу. Работает всё также просто, нужно просто добавить 1 флаг и указать путь к желаемому каталогу, в ответ вы получаете ссылку, перейдя по которой можно увидеть содержимое вашего каталога и скачать любой файл:

tuna http --file-server ./

SSH сервер

Когда вы хотите получить техническую поддержку от друга или какой либо компании, но не можете предоставить подключение по SSH или ленитесь настраивать, то в tuna достаточно написать:

tuna ssh

Будет запущен встроенный SSH-server, а в терминале вы увидите короткую инструкцию для подключения:

Отправляете это вашему другу/тех. поддержке и когда он подключится, это вы тоже увидите.

Другое

Также можно настраивать аутентификацию, задать разрешённые подсети, добавлять заголовки, включать CORS, пробрасывать TCP порт, указать в назначении сторонний IP, в общем, функционал получился достаточно богатый, да и запланировано еще много интересного.

А ещё у нас есть хосты (через который строится туннель) в России, а это значит, что трафик не будет делать огромный крюк через дата центры в Европе или Америке.

Цена

Сервис можно оплатить рублями через сервис Юкасса, а цена более чем приятная.

На бесплатном тарифе вы сможете попробовать большую часть функционала, а за 299 рублей в месяц получаете полный доступ ко всем функциям. При оформлении годовой подписки получаете 2 месяца в подарок.

Подробнее можете посмотреть всё на сайте https://tuna.am/#pricing, надеюсь вам понравится работать с tuna и спасибо, что дочитали до конца 🙂

Если у вас возникли вопросы, можете задать их нам по почте info@tuna.am

Автоматизация в Gitlab

2023-04-25T06:33:06.159Z

Привет всем, Лев у микрофона. В Gitlab'е у нас хранится все – документация, задачи, код, артефакты. Мы, хоть и благодарны за этот инструмент, но платить по 29 долларов за человека не хотим, поэтому так повелось, что у нас есть некоторая пачка сервисов, которая упрощает нам жизнь, о них и расскажу.

gitlab-webhook-setter

Небольшая утилита, которая, имея токен и конфигурационный файл, актуализирует настройки Webhook во всех наших репозиториях, групповых интеграции у нас нет, поэтому выкручиваемся так.

gitlab-telegram-bot

Один из наших основных помощников – небольшой сервер, который получает события от Gitlab и отправляем нам сообщения в Telegram, так мы видим новые комментарии, новые задачи, движения Merge Request'ов:

У нас небольшая команда и работаем мы в свободное время, поэтому видя, как кто-то что-то делает появляется мотивация и самому добавить новый функционал в проект.

remindme

Не то чтобы напрямую относится к Gitlab'у, но описано и запускается именно там через Sheduled Jobs, с помощью этого приложения мы напоминаем в Telegram о необходимости провести общий созвон:

pullreminders

Когда мы только начинали работу над Юккой, было сложно сработаться из-за разного ритма работы и разного опыта, поэтому мы запретили пуши в мастер и любые вливания изменений без аппрува Merge Request, а pullreminders занимался тем, что по субботам напоминал кому и что нужно проверить перед попаданием в мастер.

pullninja

Это наш основной помощник, он отвечает за целую пачку задач, эти маленькие кусочки функционала мы называем плагинами, вот некоторые из них:

areas – добавляет на MR лейблы относительно измененных файлов, так проще понять, какого рода изменения здесь произведены относительно мастера;
default milestone – задачи созданные без указания Milestone попадают в Backlog – отдельный Milestone для всех непрошеных задач;
epic link – задачи с лейблом kind/feature и kind/bug могут быть автоматически слинкованы с задачей kind/epic, если у них есть общий групповой лейбл, так мы все мелкие задачи собираем в одну большую;
require due date – задачи в некоторых проектах требуют указания Due Date, если дата не задана, будет добавлен соответствующий лейбл, так проще найти подобные задачи среди всех проектов;
require matching label – каждая из задач в нашем трекере требует наличия двух характеристик – тип задачи и приоритет, если одного из них нет, то будет создан соответствующий лейбл, по которому, опять же, просто найти неописанные задачи;
size – на каждый MR накидывается лейбл описывающий общий размер изменений;
watinig for info – задачи помечаются специальным лейблом, если у них отсутствует описание;
welcome – с помощью этого плагина мы приветствуем пользователей и поздравляем с первым Merge Request в нашем репозитории с документацией.

Выглядит все примерно так:

Помимо перечисленных плагинов были и экспериментальные, от которых мы отказались со временем, так как сработались и дополнительный контроль в виде автоматизации не требуется, например, плагин freeze, который добавлял в Pipeline шаг в статусе Failed, что блокировали вливание изменений в мастер.

Некоторые инструменты мы открыли и вы можете свободно их использовать (остальные, со временем, откроем тоже):

Ну и напоследок, если хочется получать уведомления в Telegram, но не хочется что-то дополнительно запускать самому, переходите в раздел Settings -> Webhooks вашего проекта в Gitlab и добавляйте туда новый webhook с такими параметрами:

URL: https://gitlab.yuccastream.com/telegram?chat_id=1234567890 (где 1234567890 - это идентификатор вашего чата/контакта в Telegram, куда будут приходить уведомления)
Trigger – установите флаги: issue events, comments, merge request events.

И не забудьте пригласить к себе в чат нашего бота Pull Ninja (@Testico_Bot), сообщения будут отправляться от его имени.