Оркестрация приложений на маленьком домашнем сервере. Что можете посоветовать?
Описание ситуации:
Есть маленький домашний сервер. (1 физическая машина) На нем хочется иметь несколько маленьких-маленьких приложений (node.js, базы данных, frontend приложения etc.)
При этом некоторые из приложений должны коммуницировать между собой, иметь общие ресурсы.
Например, приложение А умеет загружать пользовательские файлы на диск и хранить их где-то. Приложение В умеет читать некоторые их загруженных файлов и делать какую-то чертовщину с ними (например перекодировать их ffmpeg'ом), приложение С умеет вызывать приложение D через rest-api и делать что-то там.
Плюс ко всему этому все эти приложения (как серверные, так и фронтовую часть) нужно как-то деплоить на сервер.
Вопрос: что можно использовать, чтобы все это как-то организовать?
Можно ничего не использовать совсем и все делать в лоб:
- приложения деплоятся через scp/rsync/git clone etc.
- при запуске приложения A ему передается через переменную окружения путь в файловой системе до общей папки
- то же самое и для приложения Б
- С запускается с PORT=4444
- D с чем-то вроде API_URL=localhost:4444
Но это все разрастается в не очень удобный бардак.
Сейчас все это частично решается через docker-compose (конфигурируются порты и пути в ФС). Но это решение не покрывает все вопросы (все еще не ясно как это все деплоить). Плюс docker-compose имеет непонятный статус.
С k8s толком опыта нет, но кажется оно может решить часть проблем. С другой стороны кажется k8s решает обратную проблему (1 приложение на много машин, а не много приложений на одной машине). Вообщем не могу понять, насколько это приемлемое решение. Можете подсказать насколько разумно тут это использовать?
Плюс k8s это про контейнеры, а мне кажется контейнеры-то и не нужны особо.
Как могло бы выглядить идеальное решение:
- единое место для конфигурации ресурсов (порты, файловая система, load balancers и т.д.)
- возможность деплоить приложения (как фронт, так и бэк)
- минимальный мониторинг всего этого
- open-source решение
- типизация на стороне приложений (чтобы можно было на тайпскрипте написать import {listenPort} from './config') и тайпскрипт бы меня понял
- если бы для всего этого был бы удобный UI (напр. web UI) тоже было бы здорово иметь
Разумно ли пытаться тут применять k8s? Или это натягивание совы на глобус?
Если разумно, то что можете посоветовать использовать для собственно поднятия k8s? minikube? microk8s?
У меня в похожей ситуации сложился такой набор инструментов:
- контейнеризация - докер
- конфигурация и запуск контейнеров - docker compose
- web IU к докеру - Portainer
- деплой - Gitlab CI
Оркестрация кубом в пределах одного физического сервера скорее прихоть, чем необходимость. Можно поиграться разве что для знакомства с системой. И k8s скорее всего точно мимо - впустую потраченные ресурсы одного сервера. minikube, k3s и подобные будут лучшим выбором.
Для поставки в куб все равно придется организовать сборку и публикацию контейнеров. Для доставки и helm хватит.
Что бы посоветовал - baremetal с оркестрация через Ansible.
Как вариант - гипервизор: виртуалки или lxс; возможно Proxmox. Просто на случай необходимости в изоляции или разных конфигураций ОС.
Román Mirilaczvili, нет, очень-очень поверхностно знаком с Nomad, был полностью вытеснен k8s там где я с ним пересекался.
Могу лишь сказать - комьюнити, инструментов и решений под Nomad меньше. Nomad - он "другой". Он так же оркестрирует несколькими серверами, но позволяет развертывать на них не только контейнеры, но и виртуальные машины, приложения на Java и прочие. Довольно прост в развертывании и использовании.
Средний
