Files
SergObsidian/WORK & PROJECTS/Mol/Серверы/Alfa cloud readme.md
2025-03-07 13:48:57 +05:00

8.9 KiB
Raw Blame History

Общая информация

Alfa Cloud — серверный API, который предоставляет доступ к управлению контейнерами и конфигурацией облаков Alfa с поддержкой нескольких облачных серверов.

Данный документ нужен для разработки полноценного фронтенда управления контейнерами.

Все запросы должны производиться только из админки Mol. Метод авторизации каждого запроса - Basic Auth (обычный логин и пароль). Учётные данные можно менять регулярно, для этого существует специальный запрос. Учётные данные НЕ синхронизированы с основными учётными данными MOL (и для безопасности и отсутствия необходимости синхронизации всех юзеров. Нужен только главный админ).

Точки подключения:

GET:

	/servers — получить список активных серверов (для разворачивания новых клиентов)
	/servers/{server_id} — получить подробную информацию о сервере
		(TODO: с параметрами мониторинга и нагрузкой в реальном времени)
	/clients — получить список контейнеров клиентов со всеми подробностями (поддерживается пагинация). С флагом доступностью контейнера. На фронте можно сделать прямой переход на облако клиента.
	/clients/{id}/demo_enable - применение таблиц демо-данных (demo seeder)
	/clients/{id}/demo_disable - удаление демо-данных (demo inverse seeder)
	/clients/{id}/maintain_enable - включить страницу "Техническое обслуживание" у клиента
	/clients/{id}/maintain_disable - отключить страницу "Техническое обслуживание"
	/clients/{id}/send_success - отправить письмо клиенту с успешной регистрацией облака с логином и паролем
	/clients/{id}/send_expire - отправить письмо клиенту о скором истечении использования (можно/нужно автоматизировать)
	/clients/{id}/expire_dates_history - история изменения продлений дат пользователя

	

POST:

	/servers/ — создать сервер в БД (при наличии id - обновление)
	/clients/ — создать клиента (при наличии id - обновление данных, здесь не нужно отправлять пароль, а задавать его командой ниже)
		при создании - после проверки сразу вернётся id.
		во время создания нужно таймером опрашивать
			/clients/{id}/createlog и получать актуальный лог о создании контейнера (поднимать ws пока не будем). За окончание создания отвечает статус "completed" => "ok | error".
			
	/clients/{id}/owner_password — задать новый пароль администратора лаборатории
	/clients/{id}/expire_date - обновление крайней даты использования системы
		TODO: перенос данных клиента с одного сервера на другой
		TODO: /cloud_admin_password - задать пароль для подключения к API

DELETE

	/clients/{id} — редкая функция — запуск очистки пользовательских конфигов с серверов
	/servers/{server_id}  не реализовано, да и пока что не надо. Тут нужно просто удаление информации о сервере из БД.

Команды менеджмента контейнеров и деплоя (GET)

	/servers/check_host/{host_ip} - проверить доступность и настроенность сервера для деплоя. Применяется при создании и добавления сервера
	/servers/{server_id}/images - список доступных версий образов на сервере (для переключения или создания пользователя)
	/servers/{server_id}/reboot_server - перезапуск сервера
	/clients/{id}/reboot - попытка перезапуска контейнера пользователя
	/server/{server_id}/deploy - пересоздание ВСЕХ конфигов и перезапуск серверного кластера (действие, применяющееся после билда и/или смены версий). После этого необходимо сделать migrate_all
	/clients/{id}/createlog - Получить лог создания контейнера


	POST /containers/build_prod_for_all/ - получение нового кода из ветки master на ВСЕХ серверах, сборка новых образов версии, отправка в БД всех лабораторий информации о новой версии (form-data):
		- version: 1.3-master
		- info: Описание версии и новых функций (желательно в .md)

	GET /clients/{subdomain}/update_to/{version} - вызов переключения образа на выбранную версию из-под интерфейса клиента.



	/containers/{server_id}/build_dev/{new_version} - получение кода из ветки dev, сборка фронта и нового образа (промежуточная версия/хотфикс)
	/containers/{server_id}/build_prod/{new_version} - получение кода из ветки master, сборка нового образа (промежуточная версия/хотфикс)

	/containers/{server_id}/prune - удалить неиспользуемые версии образов (images prune -a) (docker system prune -a --volumes --force)
	/clients/{id}/switch/{image_name} - принудительно переключить клиента на образ другой версии
	/server/{server_id}/switch_all/{image_name} - принудительно переключить всех клиентов на образ другой версии
	/clients/{id}/migrate - запустить обновление БД клиента (artisan migrate)
	/server/{server_id}/migrate_all - запустить обновление БД у всех клиентов на сервере
	/clients/{id}/move_to/{server_id} - переместить клиента на другой сервер
	/clients/{id}/copy_to/{client_id} - установить окружение клиента и БД в базу другого пользователя ТОЛЬКО на stage-сервер. Клиент - DEMO либо TEST.
	

Идеи:

  • Получать количество пользователей в каждой системе для общего списка клиентов
  • При билде образов автоматически вычислять версию и приписывать -dev или -master
    • Также версию образа можно тащить пользователям в интерфейс

TODO: Добавить таблицу с настройками облака в каждую пользовательскую таблицу!

  • Проверка на уровне системы настройки "Техническое обслуживание" и показ блокирующей страницы
  • Проверка на крайнюю дату использования и блокировка системы.
  • Проверка на показ “турбостарта” при запуске
  • Проверка на вопрос “краткого туториала”

Server requirements: git docker+compose nginx mariadb / postgresql certbot && certbox-nginx nginx can bash nginx authorized key from master API nginx sudo NOPASSWD docker (remote cmd exec)

Every server directories (nginx 775): /srv/git — current code (composer install && npm run build) /srv/docker docker-compose.yml and Dockerfile (copy all from /srv/git without .git) /srv/clients/client1/.env — client files mount dir (+ date.timezone in php.ini (/etc/php/{PHP version}/fpm/php.ini)