Модератор форума
Участник
-
Автор темы
- #1
Вы когда - нибудь задумывались над тем, что бы развернуть свой проект, написанный на spring boot где - то кроме своего домашнего компьютера? Вы считаете, что интернет должен увидеть ваш полет фантазии, воплощенный в код? Тогда добро пожаловать под кат!
В этом цикле статей мы довольно подробно рассмотрим так называемый процесс "непрерывной разработки" в контексте разработки spring boot приложений. Сегодня же, мы начнем с конфигурации GitLab.
Для начала стоит определиться с вводными:
У нас уже есть хоть какая - то работающая версия приложения на спринге. Предположим, это будет простой сокращатель ссылок. В купе с "бэкендом" еще было бы не плохо иметь и простенький фронт - статичная html / css страничка, которая стандартными средствами js будет отправлять нам на сервер url который нужно сократить, и получать короткий url в ответ. Для управления запросами будем использовать старый добрый Nginx. Так же, для хранения данных будем использовать PostgreSQL. Кэш...? Вещь хорошая, но для упрощения общей архитектуры пока не будем забивать им себе голову. Приступим :)
Перед тем как начинать разбираться с CI/CD было бы неплохо нарисовать диаграмму взаимодействия компонентов системы, что бы, так сказать, "формализовать" архитектуру:
Глядя на схему выше, можно справедливо заметить, что для такого хоровода компонентов нам потребуется никто иной, как docker! Просто докер, без каких либо излишеств в виде terraform и k8s. Не сегодня :)
Вот уже намечается план: берем каждый компонент, пишем для него докер файл, потом докер компоуз, потом собираем по отдельности, потом загружаем все на сервер, потом..... Погодите - ка, вы же не собираетесь делать это все вручную? Нет? В таком случае, мы вплотную подошли к главному герою сегодняшней статьи: CI/CD.
Первым делом, стоит завести группу репозиториев на гитлабе. Не думаю, что у кого - то возникнут с этим сложности, тем более, что я оставляю линк на собственный проект, где будет находиться весь учебный материал. Там вы можете ознакомиться с примерной архитектурой того, как это все должно выглядеть:
Начнем создавать проекты. Всего их будет 2: фронтенд и бэкенд. Оба будут автоматически собираемые, в последствии получившиеся артефакты будут храниться в gitlab registry. Что? Что еще за Registy? Спокойно, сейчас объясню) Мы уже выяснили, что конечный результат нашей работы, это развернутые на сервере docker контейнеры, которые связаны друг с другом. Так вот, если бы мы собирали все ручками и ручками загружали бы образы докера на сервер, то в качестве registry, выступал бы Docker Desktop. Но так как мы тут с вами условились, что мы работаем на бога автоматизации, то подразумевается, что сборка и хранение докер образов должна быть перенесена с локальной машины в другое место. И это "другое место", не что иное, как GitLab registy! Это буквально аналог хранилища образов в Docker Desktop. Находится он по пути: Deploy (Боковая панель слева) -> Container Registry.
Перейдем в Container Registry:
Мдаа, пустовато конечно... Но ничего, скоро именно здесь, будут лежать собранные образы наших приложений! Как вы уже могли догадаться, для того, что бы загрузить сюда docker image's у нас должен быть какой - то доступ, что бы registry нас узнавал, и давал зеленый свет нашим действиям.
Для получения этих прав перейдем в Settings (Боковая панель слева) -> Reposiotry. Там нам понадобится категория Deploy tokens, кликаем на Expand, add token. Задаем токену имя. Я назову его kafif_token (why not?). Expiration date оставлю пустым, в поле Username укажу myAwesomeKafifToken. Права токена: read_repository, read_registry, write_registry. После этого можно нажимать Create deploy token. ВАЖНО!!! Сохраните высветившиеся данные где-нибудь в надежном месте, после того как вы перезагрузите / выйдите с этой страницы, вы больше не сможете увидеть сгенерированный пароль.
Полученные данные являются "чувствительной информацией" и не подлежат распространению. Почему? Самый простой пример - получив данные Deploy token'a злоумышленник сможет подгрузить к вам в registry зараженную версию image, и с высокой долей вероятности вы не заметите этого и пропустите такой контейнер в продакшн, и пиши пропало ваши данные....
Тогда, как же нам их безопасно подсунуть докеру при подключении к Registry? Для этого существует такая замечательная вещь, как креды/секреты/защищенные переменные среды. Называйте как хотите). Для того что бы проставить их таким образом, что бы они были видны целой группе репозиториев (бэкенду и фронтенду), мы должны (находясь в группе репозиториев, а не в конкретном, это важно!) обратиться на вкладку Settings -> CI/CD -> Variables, Expand.
Добавим две переменные:
CI_DOCKER_REGISTRY_USERNAME
CI_DOCKER_REGISTRY_PASSWORD
Выбираем у обеих переменных Masked. Это нужно для того, что бы коллеги - приколисты не смогли получить значения переменных командой echo "$CI_DOCKER_REGISTRY_USERNAME", к примеру. Вместо значения переменной в консоли пайплайна будет красоваться гордая надпись [Masked], явно намекающая, что не один коллега такой умный. Кхм. Продолжим. Остальные настройки оставляем по дефолту: Project Variable - да, и Expand variable reference - тоже да. Ну и заполняем пары Key - Value, конечно же)
Поздравляю! Только что вы настроили окружение, в котором будет происходить сброка и загрузка контейнеров в реджистри.
В следующей статье мы рассмотрим создание простого воркера, его базовую настройку и напишем простой пайплайн, который будет выводить, уже по сложившейся традиции комьюнити программистов "Hello World" в консоль)
До скорых встреч!
В этом цикле статей мы довольно подробно рассмотрим так называемый процесс "непрерывной разработки" в контексте разработки spring boot приложений. Сегодня же, мы начнем с конфигурации GitLab.
Для начала стоит определиться с вводными:
У нас уже есть хоть какая - то работающая версия приложения на спринге. Предположим, это будет простой сокращатель ссылок. В купе с "бэкендом" еще было бы не плохо иметь и простенький фронт - статичная html / css страничка, которая стандартными средствами js будет отправлять нам на сервер url который нужно сократить, и получать короткий url в ответ. Для управления запросами будем использовать старый добрый Nginx. Так же, для хранения данных будем использовать PostgreSQL. Кэш...? Вещь хорошая, но для упрощения общей архитектуры пока не будем забивать им себе голову. Приступим :)
Перед тем как начинать разбираться с CI/CD было бы неплохо нарисовать диаграмму взаимодействия компонентов системы, что бы, так сказать, "формализовать" архитектуру:
Глядя на схему выше, можно справедливо заметить, что для такого хоровода компонентов нам потребуется никто иной, как docker! Просто докер, без каких либо излишеств в виде terraform и k8s. Не сегодня :)
Вот уже намечается план: берем каждый компонент, пишем для него докер файл, потом докер компоуз, потом собираем по отдельности, потом загружаем все на сервер, потом..... Погодите - ка, вы же не собираетесь делать это все вручную? Нет? В таком случае, мы вплотную подошли к главному герою сегодняшней статьи: CI/CD.
Первым делом, стоит завести группу репозиториев на гитлабе. Не думаю, что у кого - то возникнут с этим сложности, тем более, что я оставляю линк на собственный проект, где будет находиться весь учебный материал. Там вы можете ознакомиться с примерной архитектурой того, как это все должно выглядеть:
Пожалуйста, авторизуйтесь для просмотра ссылки.
.Начнем создавать проекты. Всего их будет 2: фронтенд и бэкенд. Оба будут автоматически собираемые, в последствии получившиеся артефакты будут храниться в gitlab registry. Что? Что еще за Registy? Спокойно, сейчас объясню) Мы уже выяснили, что конечный результат нашей работы, это развернутые на сервере docker контейнеры, которые связаны друг с другом. Так вот, если бы мы собирали все ручками и ручками загружали бы образы докера на сервер, то в качестве registry, выступал бы Docker Desktop. Но так как мы тут с вами условились, что мы работаем на бога автоматизации, то подразумевается, что сборка и хранение докер образов должна быть перенесена с локальной машины в другое место. И это "другое место", не что иное, как GitLab registy! Это буквально аналог хранилища образов в Docker Desktop. Находится он по пути: Deploy (Боковая панель слева) -> Container Registry.
Перейдем в Container Registry:
Мдаа, пустовато конечно... Но ничего, скоро именно здесь, будут лежать собранные образы наших приложений! Как вы уже могли догадаться, для того, что бы загрузить сюда docker image's у нас должен быть какой - то доступ, что бы registry нас узнавал, и давал зеленый свет нашим действиям.
Для получения этих прав перейдем в Settings (Боковая панель слева) -> Reposiotry. Там нам понадобится категория Deploy tokens, кликаем на Expand, add token. Задаем токену имя. Я назову его kafif_token (why not?). Expiration date оставлю пустым, в поле Username укажу myAwesomeKafifToken. Права токена: read_repository, read_registry, write_registry. После этого можно нажимать Create deploy token. ВАЖНО!!! Сохраните высветившиеся данные где-нибудь в надежном месте, после того как вы перезагрузите / выйдите с этой страницы, вы больше не сможете увидеть сгенерированный пароль.
Полученные данные являются "чувствительной информацией" и не подлежат распространению. Почему? Самый простой пример - получив данные Deploy token'a злоумышленник сможет подгрузить к вам в registry зараженную версию image, и с высокой долей вероятности вы не заметите этого и пропустите такой контейнер в продакшн, и пиши пропало ваши данные....
Тогда, как же нам их безопасно подсунуть докеру при подключении к Registry? Для этого существует такая замечательная вещь, как креды/секреты/защищенные переменные среды. Называйте как хотите). Для того что бы проставить их таким образом, что бы они были видны целой группе репозиториев (бэкенду и фронтенду), мы должны (находясь в группе репозиториев, а не в конкретном, это важно!) обратиться на вкладку Settings -> CI/CD -> Variables, Expand.
Добавим две переменные:
CI_DOCKER_REGISTRY_USERNAME
CI_DOCKER_REGISTRY_PASSWORD
Выбираем у обеих переменных Masked. Это нужно для того, что бы коллеги - приколисты не смогли получить значения переменных командой echo "$CI_DOCKER_REGISTRY_USERNAME", к примеру. Вместо значения переменной в консоли пайплайна будет красоваться гордая надпись [Masked], явно намекающая, что не один коллега такой умный. Кхм. Продолжим. Остальные настройки оставляем по дефолту: Project Variable - да, и Expand variable reference - тоже да. Ну и заполняем пары Key - Value, конечно же)
Поздравляю! Только что вы настроили окружение, в котором будет происходить сброка и загрузка контейнеров в реджистри.
В следующей статье мы рассмотрим создание простого воркера, его базовую настройку и напишем простой пайплайн, который будет выводить, уже по сложившейся традиции комьюнити программистов "Hello World" в консоль)
До скорых встреч!
Последнее редактирование: