Tuna — обзор возможностей работы в команде аналога ngrok
В этой статье я подробно расскажу о фишках и преимуществах при работе с Tuna в команде: что вы получите, кейсы применения и чего ждать в будущем.
Если вы не знаете что такое Tuna, вот пара статей, где я расказывал об этом:
Какие есть тарифы? 🎁
Какие у нас есть тарифы:
- Хобби - бесплатно
- Разработчик - 299р. в месяц или 2990р. в год
- Команда - 599р. в месяц или 5990р. в год / за каждого учасника
Я одинокий ☝ разработчик зачем мне Команда?
Нет никаких ограничений в количестве участников в команде и вы можете иметь команду на себя одного, но в тарифе Команда, вы получите увеличенные лимиты и расширенные возможности.
- Больше одновременных туннелей - 10 в Команде, против 5 в Разработчик и 1 в Хобби.
- Больше статичных TCP портов - 5 в Команде, против 1 в Разработчик и 0 в Хобби.
- Больше своих доменов - 10 в Команде, против 1 в Разработчик и 0 в Хобби.
- Больше статичных поддоменов - 20 в Команде, против 10 в Разработчик и 0 в Хобби.
- Политики трафика - доступно только в Команде.
Поэтому, если вы уже пользуетесь Tuna на тарифе Разработчик и вам недостаточно, к примеру, 1-го статично TCP порта, а они используются не только для проброса TCP трафика, но и для SSH туннелей и для Trigger туннелей, то самое время перейти на тариф Команда.
Команда - это слишком дорого 💸
Какие преимущества есть для компаний? 🏢
Оплата по счёту 🫰
Помимо возможности централизованной оплаты за всех участников, в Команде доступна оплата банковским переводом, что часто является ключевым ограничением для закупок услуг компаниями или ИП.
- Добавьте E-mail бухгалтера в контакты команды
- Укажите реквизиты организации для выставления счёта
- Дождитесь пока администратор подтвердит реквизиты (в рабочее время обычно не дольше 10-ти минут)
- На странице управления подпиской укажите платёжное средство - Банковский перевод
- Нажмите купить подписку (сформируется счёт и отправится всем контактам из 1-го пункта)
- После поступления денег подписка автоматически активируется
RBAC / Ролевая модель распределения прав доступа 🙄
В компаниях всегда нужно разграничивать права доступа, поэтому RBAC, как правило, является фундаментальной фичей.
Какие роли есть у нас:
- Основатель - создатель команды. Имеет все привилегии, может приглашать/удалять членов команды, назначать роли всем кроме основателя, управлять подпиской, менять настройки команды, просматривать аудит логи, просматривать и управлять ресурсами членов команды (туннели/порты/домены), просматривать статистику. Участник с такой ролью может быть только 1, его роль нельзя изменить и его нельзя удалить.
- Владелец - также имеет все привилегии в команде, но таких участников может быть много, может приглашать/удалять членов команды, назначать роли всем кроме основателя, управлять подпиской, менять настройки команды, просматривать аудит логи, просматривать и управлять ресурсами членов команды (туннели/порты/домены), просматривать статистику.
- Администратор - может приглашать членов команды, удалять Участников и Администраторов, назначать роли Участникам и Администраторам, просматривать и управлять ресурсами членов команды (туннели/порты/домены), просматривать статистику.
- Пользователь - знает только название команды в которой он состоит и может использовать свой токен в этой команде.
Помимо этого вы можете указать будет ли пользователь учитываться в подписке. Можно добавить пользователя, но отключить его, т.е. не платить за него.
Когда это полезно?
Например, руководитель создаёт команду и приглашает в нее разработчиков, покупает подписку на количество разработчиков, но не платит за себя, так как сам туннелями он не пользуется, при этом имеет полный контроль.
Статистика и управление ресурсами 📊
Вы можете просматривать статистику по тем ресурсам, что используют участники, сколько занято портов, доменов, сколько было создано туннелей и так далее. Мы также будем развивать и добавлять новые метрики, дополнять текущие.
Ещё можно посмотреть все запущенные сейчас туннели, ссылки и их авторов, а также удалить активный туннель любого участника. Можно видеть и удалять домены и порты. Вы всегда сможете проконтролировать кто и что публикует, на каком домене или порту.
Аудит логи 🧐
Последнее время много новостей о ИБ, так что мы не отстаём от трендов 🙂. Помимо ресурсов, что используются в реальном времени можно посмотреть историю создания/удаления/изменения ресурсов, ролей и других событий в команде.
Сейчас мы добавили лишь базовые события, но функционал будет развиваться под потребности пользователей.
Какие есть живые примеры? 🐷
Ранее я описывал пример, как можно применять tuna в компании, но сейчас решил поделиться живим примером из практики 1-го из наших клиентов. Компания знаимается разработкой (естественно), есть небольшая команда 5-10 разработчиков. Одно из приложений на PHP, локально запускается в Docker с помощью docker-compose.
Вот как ребята всё организовали, спасибо им, что поделились. В корне проекта есть главный docker-compose.yml файл, где описан запуск сервисов. Локальное окружение каждый разработчик переопределяет через .env файл и docker-compose.override.yml, которые находятся в .gitignore.
Примерное содержимое docker-compose.yml:
Тут описаны все сервисы которые одинаковы для всех разработчиков.
Примерное содержимое docker-compose.override.yml:
Тут описаны все сервисы которые уникальны для всех разработчиков. Хочу заметить, что переменная ${USER} в TUNA_SUBDOMAIN сделает так, что новому сотруднику не надо ничего переназначать, он может прямо скопровать этот пример, и в итоге у всех сотрудников зарезервируются уникальные поддомены. А по имени домена сразу будет понятно какого сотрудника стенд.
Примерное содержимое .env:
Также есть Makefile, который упрощает запуск и сводит всё к одной короткой команде:
В консоли:
Итого, что имеется:
- Простой запуск make up и остановка make down локально стенда
- Локальный стенд автоматически публикуется наружу
- Любой участник с ролью Администратора и выше, может сразу видеть стенды коллег
И это только 1 случай, на самом деле функций ребята используют больше. Периодически шарят доступ к локальной базе друг другу, QA стали оперативнее тестировать фичи и баги, парное программирование несколько упростилось.
Выводы
- Тариф с командами полезен всем, не только компаниям
- Компании могут оплачивать по счёту
- Расширенные лимиты и функции
- Командная разработка может ускориться и стать проще
- Даже для ИБ есть фишки
На этом у меня всё, спасибо что дочитали до конца 🙂
Контакты
Подробнее можете посмотреть всё на сайте https://tuna.am, в документации и блоге надеюсь вам понравится работать с tuna.
Если возникли вопросы, можете задать их нам по почте info@tuna.am, тут в коментариях или нашем чате в telegram.
Мне это все очень напоминает библиотеку 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/