Как правильно организовать разработку на Laravel + Docker?

Question

[TAnonim]

Приветствую! Работаю над своим проектом, достаточно долго цикл моей разработки происходил по схеме "написал/обновил код -> запустил и протестировал в vagrant/homestead -> залил по ftp в production на свой vds". Знаю, ужасная схема.
Начитался статей про преимущества git, CI/CD, Docker, автоматическое тестирование и развертывание, теперь хочу использовать эти технологии и в своем проекте. С теорией всё примерно ясно, но как применять всё это на практике представляю пока что смутно. Прошел несколько getting-started гайдов по Docker, научился базовым вещам, запускать под Docker nginx со статичным веб-сайтом.
Конкретный вопрос: как должен выглядеть "правильный" ход разработки на Laravel + Docker? Мне не понятно, как использовать Docker вместе Laravel, потому что в приложении используется куча разных компонентов: nginx, php-fpm, git, composer, psql, redis, npm/yarn. Какие должны быть контейнеры для этого всего, как они должны взаимодействовать и каков должен быть итоговый результат в production? В vagrant всё это было установлено внутри одной vm, то есть напоминало vds-сервер, но в Docker, насколько я понял совсем другая философия.

Читал насчет laradock, но в статье на хабре почему-то говорят, что это не очень - есть проблемы с автоматизацией и запуском на production, не знаю, правда ли это.

Буду благодарен за ваши советы и помощь!

Comments

[JhaoDa]

Ларавел-то в тэгах зачем?

[TAnonim]

JhaoDa, может быть потому, что мой проект на laravel и меня интересует как использовать docker именно с laravel-приложением?

[JhaoDa]

TAnonim, если заменить ларавел на любой другой фреймворк, то что изменится?

[TAnonim]

JhaoDa, структура проекта, возможно, набор используемых модулей. И было бы довольно странно задавать вопрос "как использовать docker с любым фреймворком".
Я перечитал разные статьи, где авторы используют микрофреймворк flask, так там достаточно скачать один контейнер и все готово.

Answer 1

[Дмитрий Шицков]

У вас маленький проект и полноценный CI/CD к нему применить сложно - мало смысла в контейниризации, если нет необходимости скейлиться, балансировать и обеспечивать выживаемость сервиса. Разработка должна идти с использованием связки контейнеров с nginx, php-fpm, redis, postgresql и т.д. - при локальной разработке всё помещается в docker-compose.

В проде - в вашем случае можно обойтись просто docker или с использованием того же docker-compose. В больших проектах на проде будет, например, kubernetes, nomad или docker swarm. Все контейнеры деплоятся и конфигурируются единожды. Ваш CI/CD должен собирать контейнер на основе alpine и php-fpm (для PHP) или nodejs (для nodejs, соответственно) с вашим проектом, желательно в пару стейджей для минимизации размеров окончательного образа, т.к. не нужен вам в проде композер, git, yarn, npm и прочие промежуточные штуки. И уже этот минимальный контейнер уезжает на прод.

Comments

[TAnonim]

Спасибо большое за ваш ответ! Да, проект небольшой, но хочется на его примере разобраться со всеми этими вещами, обучение - одна из целей. А можно подробнее насчет контейнеров, nginx, php-fpm, redis, psql - это всё отдельные контейнеры, которые связываются между собой docker-compose? А в каком из них лежит сам исходный код laravel-приложения?

[Дмитрий Шицков]

TAnonim, да, все так. Один контейнер - 1 сервис. Ваше приложение, так же сервис. Но оно не работает без php, поэтому берете за основу php-fpm контейнер и надстраиваете свой. По возможности все зависимости проекта ставятся в первую очередь, а код проекта копируется в контейнере как можно позже. Таким образом можно будет использовать кеширование слоев докера при пересборках. Локальный докерфайла может отличаться от продового - с целью ускорения сборки можно пренебречь размерами контейнера и написать туда все необходимые зависимости, как для сборки, так и для работы приложения.

[TAnonim]

Дмитрий Шицков, Спасибо!

[Дмитрий]

Дмитрий Шицков, свое приложение следует совать в контейнер с php-fpm только если подразумевается использование консольных команд (artisan и т.п.), но веб-сервер должен использовать отдельный контейнер с php-fpm, иначе будет очень сложно переключить версию php.
У меня, например, для разный сайтов веб-сервер использует контейнеры с разными версиями php.

[Дмитрий Шицков]

Дмитрий, я описывал ситуацию подходящую для последующего деплоя контейнера на прод.
Да и в целом в чем сложность сменить версию php? Всего-то циферку поменять в докерфайле, или взять уже собственный подготовленный базовый образ

Answer 2

[andrei_pro]

Вот как пример docker-compose.yaml в корень проекта с ларой.

version: '2'
services:

  app:
    build:
      context: ./docker/services/app
      dockerfile: ./Dockerfile
    working_dir: /var/www
    volumes:
      - ./:/var/www
    env_file: ./.env
    depends_on:
      - mysql
    restart: always

  routine:
    build:
      context: ./docker/services/routine
      dockerfile: ./Dockerfile
    working_dir: /var/www
    volumes_from:
      - app
    env_file: ./.env
    depends_on:
    - app
    restart: always

  web:
    build:
      context: ./docker/services/web
      dockerfile: ./Dockerfile
    working_dir: /var/www
    ports:
      - 80:80
      - 443:443
    restart: always
    volumes_from:
      - app

  mysql:
    image: mysql:5.7
    volumes:
      - mysql-db:/var/lib/mysql
    environment:
      - "MYSQL_ROOT_PASSWORD=rootpass"
      - "MYSQL_DATABASE=db"
      - "MYSQL_USER=user"
      - "MYSQL_PASSWORD=pass"
    restart: always
    ports:
      - 3306:3306

volumes:
  mysql-db:
    driver: local

Дальше нужно создать папки в docker/services и там папки с Dockerfile и конфигом.

Как пример app в нем композер и нода для билда (это не тру подход, но можно юзать. Нужно все в отдельные контейнеры):

FROM php:7.1-fpm

RUN apt-get update \
    && apt-get install -y \
        git gnupg ssh cron nano supervisor \
        libmcrypt-dev libfreetype6-dev libjpeg62-turbo-dev libpq-dev \
        libjpeg-dev libpng-dev zlib1g-dev libmagickwand-dev --no-install-recommends \
    && pecl install imagick \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-enable imagick \
    && docker-php-ext-install gd mcrypt mbstring pdo pdo_mysql pdo_pgsql zip bcmath

RUN cd ~ \
    && curl -sL https://deb.nodesource.com/setup_10.x | bash - \
    && apt-get install -y nodejs \
    && apt-get install -y build-essential

RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

mysql:
FROM mysql

И другие контейнеры web там конфиг nginx, routine там имидж от app для выполнения тасков из очереди.

Comments

[TAnonim]

Спасибо за ваш ответ!
Скажите, пожалуйста, а команды, которые находятся в секции RUN, т.е. установка расширений php, composer и т.д. происходит каждый раз при запуске контейнера или как?

[andrei_pro]

TAnonim, Один раз при сборке, Если Dockerfile поменяются только тогда ребилд и только отдельных участков

[TAnonim]

andrei_pro, а еще небольшой вопрос по практической части, при перезапуске контейнера с бд/redis все данные удаляются или нет?

[metajiji]

Рекомендую переделать все на alpine образы и будете приятно удивлены, насколько меньше будут весить ваши образы:)

[andrei_pro]

TAnonim, если подключите volume, то данные сохранятся.

Answer 3

[Антон Сашнин]

Рекомендую https://laradock.io/

Answer 4

[hostadmin]

Тоже методом тыка изучал аналогичную связку (правда с Yii2). В итоге получилась такая конфигурация:

1. Контейнер Nginx (дефолтный)
   
2. Контейнер с certbot (получать сертификаты)
   
3. Контейнер PHP-FPM с запуском очередей (черзе supervisord), composer'ом
   
4. Контейнер CRON для запуска всяких задач
   
5. Контейнер с postfix+dkim для руления почтой
   
6. Контейнер для NAT'а трафика по IPv6
   

Пока вся разработка летит в мастер-ветку git. Выгрузка из "разработки" на сервак происходит с помощью Deployer. В принципе, после настройки всё работает как часы.

Код лежит отдельно от контейнера. Деплоить код в контейнере это уже другой уровень (да и совсем это не стандартная практика), лично у меня пока не было необходимости.

Задача была, чтобы максимально просто можно было переехать на другой хост, с правкой одного конфига (.env файла).

ПС. Самый гемор с контейнерами, это чёртовы права на файлы между хостом и контейнером.

Comments

[hostadmin]

Забыл написать. При деплое, Deployer перезагружает nginx, заходит в контейнер с php-fpm, запускает composer install, чистит кэш yii и самого php.

[Tronyx]

hostadmin, только код и зависимости уже должны быть внутри контейнера. Как откат будешь делать если криво залил? А если всё вместе, то 1 командой за пару секунд запустится старый рабочий контейнер с правильной версией кода и всего окружения.

[hostadmin]

Tronyx, зачем? Используется деплой через volume докера.

Answer 5

[Дмитрий]

Поддерживаю Антона насчет https://laradock.io/
Рекомендую посмотреть/клонировать мою ветку https://github.com/dlnsk/laradock/tree/laradock_cl... (она не очень свежая). Я там сделал простенькую консольную утилиту, которая существенно упрощает запуск artisan, npm и др. в контейнере. Создал PR, но ребята что-то не чешутся (решили на Go переписать, но так ничего и не сделали), а я сижу и не жужжу... ;)