Что мы будем делать?
Планируя проект, вы продумываете все детали своих действий. Их последовательность будет следующей:
Сначала необходимо подготовить весь необходимый для разработки проекта инструментарий:
- подготовить систему контроля версий и протестировать ее;
- создать тестовый образец проекта, на Spring Boot, прикрутить необходимые зависимости, проверить ее запустив и затем выложить в репозиторий, на GitHub;
- создать контейнер Docker и после проверки выложить его в репозиторий на GitHub;
- выполнить все необходимые манипуляции в облачном сервисе Amazon Web Services AWS.
Второй этап архитектурный. Придется немного пройтись по теории предметно-ориентированного проектирования:
- необходимо разобраться с предметной областью, ограниченными контекстами, моделями и сервисами;
- спроектировать продукт/приложение (в нашем случае это экстренная медицинская помощь).
Третий этап технический. Создадим микросервисы, следуя канонам DDD:
- исходя из проектирования, начнем создавать ограниченные контексты, артефакты, агрегаты, модели предметной области;
- создадим операции модели предметной области: входящие (команды, операции) и исходящие операции (события);
- также создадим сервисы модели предметной области: входящие сервисы, исходящие сервисы, сервисы приложения;
- по мере написания будем выкладывать проект на AWS.
Мы пройдем с читателями по всем трем этапам жизненного цикла проекта. Надеемся, это принесет вам пользу и у вас все получится.
Настраиваем Git
Вначале необходимо проделать подготовительные работы и продумать контроль версий программного кода. Мы будем использовать Git и хранить проект на сервисе GitHub. Также потребуется создать репозиторий для будущего проекта.
Устанавливаем Git
Для установки мы воспользуемся операционной системой Ubuntu (20.04 Mate). Инсталляция Git в среде Windows не настолько сложна, ее мы преднамеренно пропустим. Последовательность команд в терминале/консоли на локальном компьютере такова:
У вас должна появиться информация о версии программы:
Задаем данные пользователя
Для начала нам необходимо настроить Git, а именно задать имя пользователя и почтовый адрес:
Вы должны получить примерно такой вывод:
Создаем локальный репозиторий проекта
На своем компьютере создаем локальный каталог (если его еще нет) под названием emc (от английского – emergency medical care):
Каталог нашего проекта инициализирован, настроен и находится под контролем git. Все настройки этого репозитория можно найти в скрытом внутреннем подкаталоге .git.
Создаем учетную запись на GitHub
Заходим на сайт https://github.com/ и регистрируемся. Это несложная – много времени она не отнимет.
Создаем ssh-ключи
На локальной машине должен быть установлен ssh-keygen. В командой строке генерируем ключи:
Результат должен быть таким:
- id_rsa – закрытый ключ;
- id_rsa.pub – открытый ключ;
- known_hosts – при регистрации на других серверах сюда заносятся данные о подключениях.
Создаем репозиторий в своей учетной записи на GitHub
Создаем на GitHub новый репозиторий с таким же именем emc. Предварительно копируем содержимое файла id_rsa.pub из локального каталога .ssh. На GitHub в меню профиля пользователя находим пункт "SSH and GPG keys" и выбираем "New SSH key", задаем имя ключа, а в поле для ключа вставляем скопированное содержимое id_rsa.pub.
Пробуем забросить первые данные проекта в репозиторий на GitHub
Расшифруем некоторые опции команды git:
- git init – инициализируем локальный репозиторий;
- git add . – добавляем (точка означает все файлы) файлы, для отслеживания изменений;
- git touch .gitignore – в этот файл заносится список файлов, которые не будут отслеживаться на изменения;
- git remote add origin – соединим удаленный репозиторий как origin;
- git pull origin master – скачиваем последние изменения с GitHub;
- git push all – отправляем все изменения на GitHub/
Подведем итог
При использовании Git/GitHub все сводится к следующим действиям:
- установить Git локально и проверить на работоспособность;
- настроить ключи SSH;
- создать аккаунт на GitHub;
- создать локальный репозиторий;
- создать удаленный репозиторий на GitHub;
- зафиксировать локальные изменения;
- отправить изменения на удаленный репозиторий (GitHub).
Тестируем заброску проекта Spring Boot на GitHub
Есть разные варианты использования Spring Boot: с командной строки или в составе какой-нибудь интегрированной среды разработки (IDE). Поскольку установить IDE для программиста не так уж сложно, мы преднамеренно не описываем этот процесс.
Создаем первый тестовый проект на Spring Boot
Нам необходимо протестировать работоспособность тестового проекта. Есть различные варианты написания кода на Spring Boot, мы применим STS 4 как готовый фреймворк. Его можно взять отсюда: https://spring.io/tools.
В меню файл выбираем "New", а затем "Spring Starter Project".
Затем выбираем зависимости, которые нам понадобятся, в данном случае достаточно Spring Web.
Далее нажимаем Finish и ждем завершения процесса инициализации нового проекта.
Получаем, примерно, такой проект:
Проверяем тестовый проект на работоспособность
Для теста достаточно, чтобы приложение вывело в браузере текст "Hello World!!!". В проекте создаем класс контроллер. В пакете com.barust.emc
создаем новый класс HelloController
.
Для компиляции и запуска, в окне Package Explorer открываем контекстное меню (правая кнопка мыши), находим пункт Run As и выбираем для запуска команду Spring Boot App.
Фиксируем локальный репозиторий проекта и выкладываем на GitHub
В предыдущих примерах по репозиторию Git мы работали с локальной папкой ~/emc, а теперь попробуем создать новый локальный репозиторий в проекте IDE STS4. В окне Package Explorer открываем контекстное меню, находим пункт Show in и выбираем для запуска команду Terminal (в Windows это Git Bash).
У вас должно появиться дополнительное терминальное окно.
В окне терминала выполняем последовательность предыдущих git-команд:
Конечный результат должен быть таким:
Идем на GitHub и проверяем репозиторий:
Docker
Немного теории
Основу Docker составляют контейнеры, которые собираются из образов. Из образа вы можете создать несколько экземпляров контейнеров, которые будут отличаться портами TCP/UDP и независимостью. Также контейнеры могут взаимодействовать друг с другом. Ниже дается общая схема построения структуры Docker:
- Клиентская часть – основной механизм/программа взаимодействия с Docker посредством терминала (мы будем пользоваться интерфейсом командной строки CLI).
- Демон Docker – он же сервер Docker, управляет образами, контейнерами, сетями и томами.
- Реестр Docker – это удаленный сервер для хранения готовых шаблонов образов, Docker Hub – один из вариантов реестра.
- Docker Compose – если у вас многоконтейнерный проект, он позволяет управлять всеми контейнерами.
Надо учесть, что основу Docker составляют: образы, контейнеры и dockerfile. В dockerfile вы описываете содержимое контейнера. Обычно используются следующие инструкции:
- FROM – родительский образ;
- ENV – переменная окружения;
- WORKDIR – рабочая директория для выполнения инструкций CMD и ENTRYPOINT;
- COPY – копирование файлов и папок из вашей локальной директории в рабочую область образа;
- LABEL – инструкция информационного характера;
- RUN – запускает команды для установки пакетов и библиотек внутри контейнера;
- CMD – указывает на команду для выполнения внутри контейнера, во время запуска;
- ENTRYPOINT – также указывает на команду для выполнения внутри контейнера;
- EXPOSE – определяет порты для внешнего доступа;
- VOLUME – определяет маршрут для хранения данных и доступа к ним.
Dockerfile является как бы сердцем для Docker, указывая своими инструкциями, как построить образ.
Резюме
В этой статье мы подготовили основной необходимый инструментарий: Git/GitHub, SSH, Spring Boot и Docker. В следующей части цикла продолжим знакомство с Docker и на этом завершим подготовительный этап проекта. Думаю, это только начало – дальше будет еще интересней.
Комментарии