Приветствую тебя на треке Java, друг! Мы немного заморочились и подготовили для тебя "скелет" проекта, который поможет тебе быстрее сориентироваться в Gradle и не париться о DevOps-штучках. Ниже для тебя подготовлена памятка-инструкция.
Краткий ликбез
- Логи всех подов тут: https://info-bcs.codenrock.com/k8s/all-namespaces/pods. Сверху в выпадашке нужно выбрать свой namespace (Gitlab-login)
- Читай обязательно логи джобы Release
- Два и более одновременно запущенных пайплайнов в твоем проекте — зло
- Пайплайны тут: Gitlab → Your project → CI/CD → Pipelines
- Helm-чарты не изменяем
- Настройки и переменные окружения лежат в
helm/java-task/values.yaml - У проекта 5 минут на шаге Release, чтобы успешно запуститься
- Успешность запуска проекта напрямую зависит от readiness & liveness probes
- Порт, который слушается в твоем сервисе и в поле
service.portфайлаhelm/java-task/values.yaml, должны совпадать - Всегда можно обратиться за помощью к организаторам
А вот некраткий ликбез:
Все настройки, которые ты можешь использовать в своем проекте, находятся в файле helm/java-task/values.yaml.
Как уже было упомянуто в ТЗ, ты можешь выбрать одиночное или микросервисное решение.
Если твой выбор пал на микросервисное, то тебе достаточно в файле helm/java-task/values.yaml раскомментировать следующий блок:
- shortName: scaled
extraValues:
key3: value1
key4: value2Для удобства в приложении доступна переменная окружения APP_MODE со значениями single и scaled соответственно.
Используй ее, если хочешь управлять бинами, которые нужны только в одном из сервисов. Такой пример уже есть в проекте.
Независимо от выбранного решения (одиночное или микросервисное) на каждый из инстансов сервиса проекта выделяется по 0,5 vCPU и 1024 MB RAM.
Для решения задачи тебе могут пригодиться дополнительные инструменты. Вот что мы предоставляем:
Когда ты захочешь использовать, например, Memcached, то отправляйся в файл helm/java-task/values.yaml
и переключи соответствующий флаг в true:
memcached:
enabled: trueИспользуй переменные окружения, которые предопределены в Helm-чартах твоего проекта. Вот их список:
Kafka:
kafka_hostkafka_port
Redis:
redis_hostredis_portredis_user
PostgreSQL:
postgresql_hostpostgresql_portpostgresql_databasepostgresql_userpostgresql_password
Memcached:
memcached_hostmemcached_port
Они всегда будут пробрасываться в твой контейнер. А использовать их или нет — уже решать тебе :)
Да, друг. Мы это предусмотрели. Помнишь, я выше рассказывал про путь одиночки и путь микросервиса?
Под каждым из них есть блок extraValues, в который в формате key: value можно пробросить сколько угодно
переменных окружения для каждого из твоего "классов".
Твой сервис будет проверяться на валидность данных и после нагружаться мощными тестами.
Чтобы не произошло недопонимания, не забудь в файле helm/java-task/values.yaml
в переменной memberService указать правильный "класс" своего сервиса.
На основе этого автоматически определяется адрес твоего сервиса, в котором выставлен API.
А теперь расскажу тебе про флоу разработки, в который ты погрузишься на эти 2 дня. После твоего первого коммита в репозиторий автоматически запустится pipeline. Рекомендую тебе смотреть в нем логи каждого шага. Мы постарались оставить там только полезную информацию и убрали техническую.
Впредь каждый твой коммит будет порождать новый pipeline.
Пожалуйста, следи, чтоб их не было запущено больше двух одновременно. Это только замедлит твою работу. Если вдруг у тебя их запустилось больше одного, то просто отмени "старые" и оставь жить самый "свежий".
Верим, что ты не хочешь ломать процесс раскатки сервиса, но вдруг ты любопытный и захочешь что-то изменить в Helm-чартах. Да, этот шаг просто проверяет Helm-чарты, которые у тебя уже готовы, на валидность.
Сборка Java-приложения на базе 11 версии Java с помощью Gradle версии 7.2.
На выходе этой сборки ожидаем только один jar-файл в папке build\libs, будь добр, следи за этим.
В "скелете" со Spring Boot это уже настроено, можешь посмотреть в build.gradle. В Gradle-плагинах,
используемых другими фреймворками (например, Gradle Shadow), отключение "лишних" jar-файлов настраивается
по-своему.
Как раз этот шаг и ожидает, что к нему придет один jar-файл, который запакуется в готовый docker-контейнер для дальнейшей раскатки в Kubernetes.
Мы настроили здесь примитивное версионирование по порядковому номеру билда. Свои образы ты можешь найти в Gitlab → Your project → Packages & Registries → Container registry.
Один из долгих шагов. Тут твой сервис будет выкачен в среду оркестрации Kubernetes с помощью Helm-чартов, которые лежат в проекте. У твоего проекта будет суммарно всего 5 минут на успешный запуск. Как только job'a стартовала, скорее беги смотреть логи в https://info-bcs.codenrock.com/k8s/all-namespaces/pods. Сверху выбирай свой логин из Gitlab, открывай поды и наблюдай за логами:
Когда он успешно запустится (напомню о важности readiness & liveness probes), пойдет проверка метода API на валидность данных. Успешно прошел эту проверку и job в pipeline стал зеленым? Поздравляю! Скорее смотри следующий шаг, там запустятся нагрузочные тесты. Не повезло и он стал красным? Посмотри логи verifier-java, это может помочь. А твой проект тем временем удалится из Kubernetes.
Подсказка: Логи можно не просто смотреть в браузере, но и скачать одной кнопкой Download (сверху-справа над логами).
Нагрузочные тесты. Ммм. Как много в этой фразе... Как много нагрузки в этой фразе. И нагружать мы будем с помощью утилиты K6. Если не слышал о такой, велкам - https://k6.io/ Пройдут тесты удачно или нет, в любом случае этот отчет попадет в общую таблицу результатов.
На этом шаге при любом раскладе твой проект удалится из Kubernetes. После удаления уже нельзя будет посмотреть даже логи. Теперь исправляй потенциальные ошибки и коммить заново :)