Tuna — обзор возможностей работы в команде аналога ngrok

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

Если вы не знаете что такое Tuna, вот пара статей, где я расказывал об этом:

Страница создания Команды
Страница создания Команды

Какие есть тарифы? 🎁

Какие у нас есть тарифы:

  • Хобби - бесплатно
  • Разработчик - 299р. в месяц или 2990р. в год
  • Команда - 599р. в месяц или 5990р. в год / за каждого учасника
Tuna — обзор возможностей работы в команде аналога ngrok

Я одинокий ☝ разработчик зачем мне Команда?

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

Поэтому, если вы уже пользуетесь Tuna на тарифе Разработчик и вам недостаточно, к примеру, 1-го статично TCP порта, а они используются не только для проброса TCP трафика, но и для SSH туннелей и для Trigger туннелей, то самое время перейти на тариф Команда.

Команда - это слишком дорого 💸

Если мы будем сравнивать Tuna vs. Ngrok, то увидим, что за подобный функционал у последнего придётся заплатить уже 20$ (~2000р.) за пользователя, против 599 рублей. Но если у вас много сотрудников, мы всегда готовы обсудить скидку на ваши объёмы 🙂.

Какие преимущества есть для компаний? 🏢

Оплата по счёту 🫰

Помимо возможности централизованной оплаты за всех участников, в Команде доступна оплата банковским переводом, что часто является ключевым ограничением для закупок услуг компаниями или ИП.

  • Добавьте E-mail бухгалтера в контакты команды
  • Укажите реквизиты организации для выставления счёта
  • Дождитесь пока администратор подтвердит реквизиты (в рабочее время обычно не дольше 10-ти минут)
  • На странице управления подпиской укажите платёжное средство - Банковский перевод
  • Нажмите купить подписку (сформируется счёт и отправится всем контактам из 1-го пункта)
  • После поступления денег подписка автоматически активируется
Пример добавления организации vc.ru

RBAC / Ролевая модель распределения прав доступа 🙄

В компаниях всегда нужно разграничивать права доступа, поэтому RBAC, как правило, является фундаментальной фичей.

Какие роли есть у нас:

  • Основатель - создатель команды. Имеет все привилегии, может приглашать/удалять членов команды, назначать роли всем кроме основателя, управлять подпиской, менять настройки команды, просматривать аудит логи, просматривать и управлять ресурсами членов команды (туннели/порты/домены), просматривать статистику. Участник с такой ролью может быть только 1, его роль нельзя изменить и его нельзя удалить.
  • Владелец - также имеет все привилегии в команде, но таких участников может быть много, может приглашать/удалять членов команды, назначать роли всем кроме основателя, управлять подпиской, менять настройки команды, просматривать аудит логи, просматривать и управлять ресурсами членов команды (туннели/порты/домены), просматривать статистику.
  • Администратор - может приглашать членов команды, удалять Участников и Администраторов, назначать роли Участникам и Администраторам, просматривать и управлять ресурсами членов команды (туннели/порты/домены), просматривать статистику.
  • Пользователь - знает только название команды в которой он состоит и может использовать свой токен в этой команде.
Управления ролями пользователей 

Помимо этого вы можете указать будет ли пользователь учитываться в подписке. Можно добавить пользователя, но отключить его, т.е. не платить за него.

Когда это полезно?

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

Статистика и управление ресурсами 📊

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

Ещё можно посмотреть все запущенные сейчас туннели, ссылки и их авторов, а также удалить активный туннель любого участника. Можно видеть и удалять домены и порты. Вы всегда сможете проконтролировать кто и что публикует, на каком домене или порту.

Аудит логи 🧐

Последнее время много новостей о ИБ, так что мы не отстаём от трендов 🙂. Помимо ресурсов, что используются в реальном времени можно посмотреть историю создания/удаления/изменения ресурсов, ролей и других событий в команде.

Журнал событий в команде
Журнал событий в команде

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

Какие есть живые примеры? 🐷

Ранее я описывал пример, как можно применять tuna в компании, но сейчас решил поделиться живим примером из практики 1-го из наших клиентов. Компания знаимается разработкой (естественно), есть небольшая команда 5-10 разработчиков. Одно из приложений на PHP, локально запускается в Docker с помощью docker-compose.

Вот как ребята всё организовали, спасибо им, что поделились. В корне проекта есть главный docker-compose.yml файл, где описан запуск сервисов. Локальное окружение каждый разработчик переопределяет через .env файл и docker-compose.override.yml, которые находятся в .gitignore.

Примерное содержимое docker-compose.yml:

--- name: app services: nginx: image: nginx:1.27-alpine container_name: nginx ports: - "8080:80" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf depends_on: - php php: image: private-repo/php container_name: php volumes: - ./:/api - ./tmp/composer:/composer working_dir: /api depends_on: - db - rabbitmq - mongo db: image: postgres:16-alpine container_name: db ports: - "54320:5432" volumes: - ./initdb:/docker-entrypoint-initdb.d:ro - postgres:/var/lib/postgresql/data environment: POSTGRES_USER: local POSTGRES_PASSWORD: local POSTGRES_DATABASE: local rabbitmq: image: rabbitmq:3-management-alpine container_name: rabbitmq hostname: rabbit volumes: - rabbitmq:/var/lib/rabbitmq ports: - "5672:5672" - "15672:15672" mongo: image: mongo:6 container_name: mongo volumes: - mongodb:/data/db environment: MONGO_INITDB_ROOT_USERNAME: root MONGO_INITDB_ROOT_PASSWORD: root1234 MONGO_INITDB_DATABASE: local swagger: image: swaggerapi/swagger-ui:v4.18.0 container_name: swagger ports: - "8088:8080" volumes: - ./:/app depends_on: - php environment: URL: http://127.0.0.1:8080/dev/swagger.json BASE_URL: "" volumes: postgres: mongodb: rabbitmq:

Тут описаны все сервисы которые одинаковы для всех разработчиков.

Примерное содержимое docker-compose.override.yml:

--- web: image: private-repo/ui:latest container_name: web ports: - "3000:3000" redis: image: redis:7-alpine container_name: redis depends_on: - web tuna-web: image: yuccastream/tuna:latest container_name: tuna-web command: http web:3000 depends_on: - web - nginx - php env_file: ".env" environment: - TUNA_SUBDOMAIN=${USER}-web - TUNA_INSPECT=true - TUNA_INSPECT_ADDR=0.0.0.0:4041 ports: - "4041:4041" tuna-api: image: yuccastream/tuna:latest container_name: tuna-api command: http nginx:80 depends_on: - nginx - php env_file: ".env" environment: - TUNA_SUBDOMAIN=${USER}-api - TUNA_INSPECT=true - TUNA_INSPECT_ADDR=0.0.0.0:4040 ports: - "4040:4040"

Тут описаны все сервисы которые уникальны для всех разработчиков. Хочу заметить, что переменная ${USER} в TUNA_SUBDOMAIN сделает так, что новому сотруднику не надо ничего переназначать, он может прямо скопровать этот пример, и в итоге у всех сотрудников зарезервируются уникальные поддомены. А по имени домена сразу будет понятно какого сотрудника стенд.

Tuna — обзор возможностей работы в команде аналога ngrok

Примерное содержимое .env:

TUNA_TOKEN=tt_***

Также есть Makefile, который упрощает запуск и сводит всё к одной короткой команде:

.DEFAULT_GOAL := help .PHONY: help help: ## Справка по командам @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-30s\033[0m %s\n", $$1, $$2}' .PHONY: up up: ## Запуск локального стенда для разработки в docker @echo "===> exec: docker compose -f docker-compose.yml -f docker-compose.override.yml up -d" @docker compose -f docker-compose.yml -f docker-compose.override.yml up -d .PHONY: down down: ## Остановка локального стенда для разработки в docker @echo "===> exec: docker compose -f docker-compose.yml -f docker-compose.override.yml down" @docker compose -f docker-compose.yml -f docker-compose.override.yml down .PHONY: clean clean: ## Очистить все данные включая файлы базы данных, вольюмы docker и прочее @echo "===> exec: docker compose -f docker-compose.yml -f docker-compose.override.yml down -v" @docker compose -f docker-compose.yml -f docker-compose.override.yml down -v @echo "===> exec: rm -rf ./tmp ./var ./vendor" @rm -rf ./tmp ./var ./vendor .PHONY: bootstrap bootstrap: ## Установить зависимости @docker compose exec -ti php composer install .PHONY: links links: ## Узнать ссылки от tuna @docker compose logs tuna-api tuna-web| grep "Forwarding"

В консоли:

Tuna — обзор возможностей работы в команде аналога ngrok

Итого, что имеется:

  • Простой запуск make up и остановка make down локально стенда
  • Локальный стенд автоматически публикуется наружу
  • Любой участник с ролью Администратора и выше, может сразу видеть стенды коллег

И это только 1 случай, на самом деле функций ребята используют больше. Периодически шарят доступ к локальной базе друг другу, QA стали оперативнее тестировать фичи и баги, парное программирование несколько упростилось.

Выводы

  • Тариф с командами полезен всем, не только компаниям
  • Компании могут оплачивать по счёту
  • Расширенные лимиты и функции
  • Командная разработка может ускориться и стать проще
  • Даже для ИБ есть фишки

На этом у меня всё, спасибо что дочитали до конца 🙂

Контакты

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

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

11
2 комментария

Мне это все очень напоминает библиотеку frp с гитхаба.
Конечно все конфиги файликами, но есть значительные плюсы:

1. self-hosted. трафик не идёт через вас, что достаточно важно, мало кто настраивает шифрование на коннекты к БД. ну и плюс можно подобрать оптимальные локации под дц/клиентов)
2. открытый исходный код == бесплатный
3. инфосек: никто не видит внутреннюю инфраструктуру.
поломают ваш сервис — влезут сразу в самые беззащитные сервисы, я бы очень не хотел доверять инфру кому-то снаружи.

Что получаем взамен него за деньги — логи и RBAC 🙂
Статистика по сервисам в вебе у frp тоже есть.
Каких-то ещё фич не вижу — штуки вроде Tuna SSH не уникальны, в frp тоже есть SSH Tunnel Gateway.

Может есть что-то, чего я не учитываю? Сравнение с ngrok вы выигрываете, но вот с опенсорсом я пока не уверен 🙂

Ответить

А какой смысл сравнивать SaaS сервис и опенсорс, который надо хостить? Вы же не сравниваете "Итальянский ресторан" и "поесть дома" ? Если для вас заниматься селлф-хостингом всего подряд это "значительные плюсы" то это совсем не так для кучи других людей) Первое что приходит на ум это Sentry, попробуйте развернуть это самостоятельно (postgres, redis, clickhouse, zookeeper, kafka, rabbitmq и 40 микросервисов + кронджобы) и вы поймёте, что проще и даже дешевле купить подписку. Да куча людей даже тот-же postgres как услугу покупает часто, просто потому, что проще и дешевле заплатить, чем возиться самому))
Что касается frp, ну помимо него есть ещё пара десятков такого-же опенсорса, есть даже репозиторий с списком алитернатив.
SSH Tunnel Gateway - не тоже самое, что и Tuna SSH tunnel, можете тут сравнить https://tuna.am/docs/tunnels/ssh/

Ответить