Использую Docker / Docker Compose для PHP-проекта и хочу понять общепринятый production-подход, а не "запустилось ура!".
Сразу уточню: опыта в it у меня нет, поэтому интересует именно корректная архитектура.
Исходные условия:
PHP-приложение (PHP-FPM)
nginx как фронт
Главная страница - index.php
Статика (css, js, изображения, и тд) лежит рядом с PHP-кодом, строгой директории public/ нет
Я так понисаю что nginx должен отдавать статику.
PHP-FPM должен обрабатывать только .php.
Что я придумал:
1. Весь код в volume на сервере
Проект лежит в named volume
Volume шарится между PHP-FPM и nginx
Обновление через CI (GitHub Actions) и локальный git на сервере.
2. Отдельный app-image (артефакт приложения)
app-image содержит только код проекта
При старте контейнеров код из app-image раскладывается в named volume
Этот volume используется PHP-FPM и nginx
storage (uploads, пользовательские файлы) вынесен в отдельный volume
При деплое через GitHub action volume с кодом должен пересоздаваться и инициализируется заново?
Git на сервере не используется в таком случаи.
3. Один образ с PHP и nginx
Внутри образа PHP-FPM, nginx и код приложения.
Отдельный внешний nginx работает как reverse-proxy
4. Код внутри PHP-image
PHP-image содержит код проекта
При старте контейнера код копируется в volume
Этот volume используется PHP-FPM и nginx
Git на сервере не нужен. ( Туту я еще не подумал про инициализацию volume каждый раз)
5. COPY кода в PHP-FPM и nginx образы
Код дублируется в двух образах
Варианты 3, 4 и 5 выглядят плохо.
Варианты с volume кажутся более правильными, но при этом часто встречаю утверждение, что:
Docker-image должен быть самодостаточным
код приложения должен быть внутри image.
volume допустим только для базы даных ну максимум еще storage.
Вопросы:
Какой подход считается корректным для production?
Есть ли более правильный вариант, о котором я не подумал?
Интересует практический правильный опыт.
Ps. Пока писал вопрос придумал вариант 2.
"А этот пацак думает на языках, окончания которых не знает" (с)
Для вас правильный подход, например, такой:
- подобрать CMS, которая больше понравится
- найти настройки nginx под нее и поставить, как написано
- а не выдумывать слонов на паучьих ножках от полного отсутствия понимания, кто на ком стоит.
У меня нет опыта в IT, поэтому я могу ошибаться в терминах. Я от силы месяц занимаюсь.
В моей схеме nginx принимает запросы от браузера и отдаёт CSS, JS и другие статические файлы, а выполнение PHP-кода передаёт в PHP-FPM. Поэтому я назвал nginx фронтом, а PHP-FPM — бэком. При этом я понимаю, что nginx — это веб-сервер, revers proxy и балансировщик нагрузки.
Если это считается ошибкой, прошу объяснить, в чём именно она заключается и почему.
Что тогда корректно называть фронтом — CSS, JS, HTML, PHP, сам браузер, глаза человека, почему react фронт?
Предлагать использовать CMS в тролльной форме вместо ответа по существу — странно.
Совет «найти настройки nginx под неё и поставить, как написано» не объясняет, как всё работает.
Разве плохо понимать синтаксис nginx и разбираться, что именно делают его директивы?
Даже если есть готовые конфиги, мне важно понимать, как и почему они работают, а не просто скопировать.
У меня нет возможности идти на курсы или обучение.
Это pet-проекты. Я не могу заставить жену писать «правильно», но могу сам пытаться разобраться и осмыслить, как делать корректно.
Sukesada, просто вы пытаетесь изобрести все заново вместо того, чтобы посмотреть, как все это делается последние 30 лет. Без базы. Естественно, блуждаете в фантазиях и никуда не приходите.
Поставьте то, что работает - и копайтесь в нем, разбираясь, как оно работает. Это и будет обучением, а не гордой стойкой в гамаке.
Фронт в общепринятой терминологии - браузер и код, который выполняется в нем. Бэк - на сервере.
Nginx - веб-сервер. Никакого отношения к коду, кроме передачи запросов обработчику, он не имеет вовсе.
Adamos, Спасибо, это уже более дельный ответ. Тогда попробую посмотреть на готовое решение, например, развернуть WordPress и разобраться, как там всё устроено.
Но пока работаю с женой. А у не со структурой ппц. Заставить не могу правильно делать выгонит.
Sukesada, https://wintercms.com/docs/v1.2/docs/setup/installation - вот такое можете глянуть, если ангельского не боитесь.
Современный фреймворк под капотом, грамотно разделенные фронт с бэком, настройка nginx и под статику, и под единый вход. Готовый образ докера, собственно...
не углубляясь: если у вас грамотно разделена статика и PHP код, то шарить между PHP и nginx ничего не нужно. Общие соображения:
1) nginx смотрит на путь. Если путь - в каталог со статикой ( это может быть несколько каталогов, например, отдельные для картинок, для css, для js ), то надо либо отдать запрошенный файл, либо ответить 404. Если какой-то другой - передать запрос на апстрим ( в данном случае PHP-FPM )
2) если PHP занимается генерацией и/или сохранением статики ( например, заливка картинок через админку), то какие-то каталоги, очевидно, должны быть пошарены между контейнерами.
3) bind mount в докере может быть проще в работе, чем volume
"Docker-image должен быть самодостаточным код приложения должен быть внутри image." - это важно, если вы:
1. передаете изменения заказчику и он самостоятельно их разворачивает.
2. Должны запускать код на куче стендов для смоука, ИФТ и т.п.
Если у вас статический прод на одном сервере - нет никакой разницы, какой подход вы используете, чтобы обновить там данные. Вам и докер то там не нужен судя по всему.
Да, там и VPS, по сути, не нужна. Просто жена делает сайт и CRM под свои задачи. Я решил заняться помощью ей. Она вооще прямо на хостинге ковыряла файлы. Сейчас есть git, docker compose dev prod. ci через GitHub action, она на сервер не заходит вобще. Так как vps слабая написал bash скрипт alerta в телегу. Потом наверное Zabbix разверну. Создал playbook ansible, если vps умрет что бы переразвернуть быстро.
К git жену удалось приучить с трудом. При этом сейчас у меня порядка больше, чем у неё в компании — это средний бизнес, где раньше тратили сотни тысяч в месяц на IT, а сейчас уже пару сотен.
Жена не it. она поддержка.
Средний
