Данный пример содержит упрощенный вариант приложения с собственным набором контейнеров, цепочкой CI и минимальным набором контейнеров.
Приложение является примитивным REST сервисом, обрабатывающим только два запроса:
- http://app.com/items - возвращает JSON массив абстрактных эелементов
- http://app.com/items/7 - возвращает JSON одного из эелементов
Приложение использует базу данных Postgresql и in-memory хранилище Redis (для кеширования) запросов.
Приложение состоит из набора четырёх контейнеров:
- web_sample001 - фронтэнд приложения (Nginx)
- app_sample001 - сервер приложения (PHP-FPM)
- db_sample001 - СУБД (Postgresql)
- redis_sample001 - кеш (Redis)
Набор контейнеров управляется docker-compose.
Этот пример устанавливает в качестве домена на котором работает приложение домен app.com, однако можно использовать любой удобные или же не использовать символьное имя вовсе.
Конфигурация параметров контейнеров и приложения производится через переменные окружения.
Фронтэнд приложения (Nginx).
Образ контейнера базируется на образе nginx:alpine из dockerhub. Образ содержит файл конфигурации хоста Nginx (nginx.app.conf).
https://hub.docker.com/_/nginx
Сервер приложения.
Образ контейнера базируется на образе php:7.4.3-fpm из dockerhub. Образ содержит приложение, состоящее в данном примере из единственного файла app.php и папку с зависимостями приложения vendor. Так же в образ устанавливаются расширения PHP: pdo, pdo_pgsql, redis (PECL redis).
Образ postgres:10.12 из dockerhub.
https://hub.docker.com/_/postgres
Образ redis:5.0.7 из dockerhub.
https://hub.docker.com/_/redis
- docker-compose.yaml - шаблон docker-compose.yaml
- Dockerfile.nginx - шаблон образа контейнера фронтэнд
- Dockerfile.php-fpm - шаблон образа контейнера сервера приложения
- .gitlab-ci.yml - шаблон конфигурации СI в формате Gitlab CI (https://docs.gitlab.com/ee/ci/)
- app.env - готовая конфигурация приложения/контейнеров
- app.php - готовое приложение
- composer.json - готовая конфигурация зависимостей приложения
- migration.sql - готовый скрипт миграции базы данных
- nginx.app.conf - готовая конфигурация Nginx
- README.md - вы это читаете
- sample001.postman_collection.json - экспортированная конфигурация Postman (https://www.postman.com/). Postman с этой конфигурацией можно использовать для проверки работоспособности приложения.
-
Дополнить шаблон образа Dockerfile.nginx таким образом чтобы после сборки образ содержал файл конфигурации виртуального хоста приложения nginx.app.conf.
-
Дополнить шаблон образа Dockerfile.php-fpm таким образом чтобы после сборки образ содержал:
- приложение - app.php
- папку зависимостей приложения - vendor; эта папка создается вызовом команды composer update, которая для своей работы используют конфигурацию зависимостей composer.json (https://getcomposer.org/);
- необходимые для работы приложения модули php: pgsql, pdo, pdo_pgsql, redis
-
Дополнить шаблон docker-compose.yaml таким образом чтобы он:
- использовал кастомные образы фронтенда и сервера приложения полученные в результате двух предыдущих шагов
- внедрял в окружения сервисов app_sample001 и db_sample001 переменные окружения из файла app.env
- запускал сервисы в следующей последовательности: db_sample001 и redis_sample001, затем app_sample001, последним web_sample001 ; ожидание реального запуска соответствующего программного обеспечения в контейнерах реализовывать не обязательно
-
Дополнить шаблон конфигурации CI .gitlab-ci.yml таким образом чтобы в ходе выполнения цепочки CI выполнялись следующие действия:
- На шаге build: Сборка зависимостей приложения с помощью composer
- На шаге build: Сборка образов Dockerfile.nginx и Dockerfile.php-fpm
- На шаге build: Загрузка собранных образов в репозиторий образов проекта
- На шаге deploy: Выгрузка необходимых образов на production сервер
- На шаге deploy: Запуск набора контейнеров docker-compose с форсированным пересозданием их
- На шаге migrate: Выполнить на базе данных приложения скрипт migration/sql
- Цепочка CI должна использовать ветку master репозитория
- Цепочка CI должна запускаться после создания в репозитории нового тега, т.е. после выполнения команд:
git tag TAG_NAME git push origin TAG_NAME
- PHP 7.4 - устанавливается из репозиториев
- PHP composer - устанавливается из репозиториев
- Docker - устанавливается из репозиториев
- docker-compose - https://docs.docker.com/compose/install/
- Gitlab CE - локальная установка: https://hub.docker.com/r/gitlab/gitlab-ce/
- gitlab-runner - устанавливается из репозиториев (может быть запущен локально или в виртуальной машине)
- Postman - опционально https://www.postman.com/
Данный пример сильно упрощен по сравнения с CI реальных сервисов. Структура работающих сервисов отличается от примера следующим:
- Не используются базы данных или же хранилища запущенные в контейнерах; их место занимают соответствующие конекторы к кластерам
- Для всех сервисов используются только кастомные образы (образы dockerhub не используются нигде)
- Все используемые образы вынесены в самостоятельные проекты и для их сборки используются собственные цепочки CI
- Конфигурации сервисов отделены от их исходного кода и имеют собственные проекты
- Композиции наборов образов отеделены от исходного кода сервисов и имеют собственные проекты
- Финальная цепочка CI работает с множеством репозиториев для объединения конфигурации, кода, образов
- В отличии от этого примера значительную часть цепочки CI составляют тесты приложения перед продуктовым запуском
- В ходе выполения цепочек CI используется автоматическое версионирование
- В ходе выполнения миграции используется версионирование
- Для миграций выполняются тесты в ходе CI
- Цепочки CI выполняются параллельно множеством агентов, а не одним как в этом примере
- Приложение состоит не из одного файла :) и имеет более обширные зависимости