Инфраструктура и поставка
Инфраструктура geek.moscow объединяет приложения продукта, сервисы разработки, мониторинг и почту. Эта страница описывает назначение окружений и процесс поставки; подробности отдельных сервисов вынесены в самостоятельные разделы.
Публичные адреса проекта
| Сервис | Адрес | Назначение |
|---|---|---|
| Прототип | geek.moscow | Адрес приложения для подачи решения |
| Документация | docs.geek.moscow | Этот сайт: обзор продукта, архитектуры, экранов и эксплуатации |
| Административный контур | admin.geek.moscow | Admin UI и Gateway в профиле admin; вход только для операторов |
| API | api.geek.moscow | Публичный Gateway; интерфейс обращается к нему с того же origin |
| Почтовый ящик демонстрации | mail.geek.moscow | Mailpit за basic auth: сюда попадают все письма подтверждения и восстановления |
| GitLab | gitlab.geek.moscow | Репозитории, изменения, проверки и организация CI/CD |
| Container Registry | registry.geek.moscow | Endpoint контейнерного реестра; может требовать аутентификацию |
| Grafana | grafana.geek.moscow | Панели мониторинга публичного стенда, папка geek.moscow |
| Prometheus | prometheus.geek.moscow | Сырые метрики и алерты, HTTP basic auth |
| Эмулятор ФСП | fsp.geek.moscow | Контракт API реестра достижений; методы /v1/* защищены токеном |
| Дизайн-система | design-system.geek.moscow | Storybook: каталог компонентов и визуальные проверки |
| Брендбук | brandbook.geek.moscow | Правила бренда и примеры интерфейса |
Адреса обозначают назначение ресурсов. Доступность конкретной версии приложения, анонимный доступ и состояние сборок учитываются отдельно в статусе проекта.
Окружения
| Окружение | Роль |
|---|---|
| Рабочая станция | Исходники, документация, локальные инструменты и управление окружениями |
| Внутренний продуктовый стенд | Приложения продукта, публичный и административный профили Gateway, восемь бизнес-сервисов, хранилища и фоновые процессы |
| Внутренний мониторинг | Prometheus, Grafana и наблюдение за узлами и Gateway |
Публичный узел nubble-prod-01 |
Отдельный k3s-узел с полной платформой: geek.moscow, api., admin., fsp., mail. и docs.geek.moscow; опубликован 10 октября 2026 года |
| Stage | Отдельный узел k3s с GitLab CE, его реестрами и Grafana |
| Yandex Cloud Managed Kubernetes | Прежнее размещение страницы ожидания, Storybook и брендбука; Storybook и брендбук переезжают на design-system.geek.moscow и brandbook.geek.moscow |
Внутренние компоненты используют собственные DNS и сертификаты; публичные сервисы получают домены проекта и сертификаты Let's Encrypt. На публичном узле платформа работает в пространствах имён geek-api, geek, geek-admin, fsp-mock и geek-docs: 25 подов продукта, PostgreSQL 16, RabbitMQ, Redis и задание миграций. База публичного стенда создана чистой, с собственными секретами, и заполнена демонстрационными данными через публичный API от имени самих пользователей: 9 инженеров с 10 анкетами и 5 компаний с 12 вакансиями. Учётные записи перечислены на странице доступов.
Размещение приложений
Основной frontend обслуживает оболочку и подключаемые модули. Запросы /auth/* и /api/v1/* направляются в публичный Gateway. Административное приложение использует отдельный Gateway в профиле admin со своими сессиями и разрешёнными маршрутами.
Backend включает Identity, Candidates, Employers, Opportunities, Recruitment, Chat, Notifications и Backoffice. PostgreSQL, RabbitMQ, Redis, workers и задания миграций находятся в серверном окружении. Браузер не обращается к их внутренним интерфейсам напрямую.
Внутреннее размещение административного контура
Admin UI и Admin Gateway можно вынести за внутренний ingress с доступом через корпоративный VPN, сохранив публичный вход в основной продукт. Сетевые правила должны закрывать административный интерфейс, авторизацию и API, включая альтернативные пути к сервису. Служебные права продолжают проверяться после подключения к VPN. Вариант настройки и существующее ограничение внутреннего стенда описаны в разделе админки; корпоративный SSO — в разделе Keycloak и OIDC.
Сборка и артефакты
Приложения собираются в Docker-образы; статические frontend-приложения обслуживаются Caddy. Версия образа привязана к первым восьми символам SHA коммита. Плавающий тег :latest не применяется, чтобы было понятно, какую ревизию проверяют, запускают или возвращают при откате.
В исходных процедурах используются реестры контейнеров и npm Yandex Cloud. GitLab предоставляет отдельные Container Registry и Package Registry; факт установки реестра не подтверждает перенос в него всех артефактов. Фактическое место публикации задаётся конфигурацией конкретного проекта.
Секреты хранятся отдельно от исходников и передаются приложениям через настройки окружения и Kubernetes Secrets. Их значения не входят в публичную документацию.
Процесс поставки
- Подготовить ревизию приложения и выполнить проверки, соответствующие изменению.
- Собрать образ или пакет и опубликовать версию в реестр.
- Указать новый образ в манифестах; при необходимости выполнить миграции.
- Развернуть приложение и дождаться готовности компонентов.
- Проверить ключевые пользовательские сценарии и метрики.
- Зафиксировать версию, окружение и результат выпуска.
Образы собираются на сборочном узле команды из снимков репозиториев и переносятся на публичный узел напрямую в containerd, без промежуточного реестра; манифесты применяются kustomize через kubectl, автоматическая синхронизация Argo CD не используется. Сайт документации собирается тем же путём: генератор превращает Markdown в статический сайт, который обслуживает Caddy. Построение непрерывного процесса вынесено в раздел GitLab и CI/CD.
Мониторинг и почта
Grafana и Prometheus наблюдают за публичным стендом: десять панелей в папке geek.moscow покрывают Gateway, аутентификацию, backend-сервисы, хранилища, Kubernetes, узел и внешние пробы. Учётные записи для просмотра приведены на странице доступов.
Почта: Identity создаёт задания подтверждения email и восстановления пароля, worker передаёт письма по SMTP. На публичном стенде SMTP-приёмником служит Mailpit, поэтому письма видны в ящике mail.geek.moscow и не уходят реальным адресатам; настроенный Postfix подтверждён владельцем проекта.
Что ещё нужно зафиксировать для stage
Исходные материалы stage описывают установку GitLab и Grafana в отдельной ветке инфраструктуры. Для законченного CI/CD требуется зафиксировать runner, файлы конвейеров, реальные результаты проверок и доставку каждого приложения. Для мониторинга — datasource, панели и правила оповещения.
Эти пробелы не заполняются предположениями о выполненных настройках. Сводка готовности — в статусе проекта, первичные материалы — в каталоге источников.