Как упростить и убыстрить процесс переноса правок с docker на прод?
Собираю сайты на wordpress в docker.
1. Выгружаю с git свою wordpress-сборку docker-а
2. Выгружаю с git чистую тему
3. Верстаю\программирую используя npm
4. Выгружаю готовую тему с бд в git-проект
5. Создаю VDS-сервер
6. Загружаю туда чистый wordpress
7. Выгружаю из git созданную тему с базой
8. Создаю mysql базу, выгружаю в нее базу попутно меняя localhost на рабочий домен
9. Отправляю с помощью rsync /uploads и /plugins на VDS
И все бы ничего. Но при малейшей правке в теме надо сделать половину пунктов туда-и-обратно.
С докером конечно очень удобно. Но раньше, используя просто ftp и внося правки прямо на проде я тратил гораздо меньше времени.
Товарищи программисты, поделитесь пожалуйста, как (чем) вы ускоряете процесс при использовании докера, внося правки только на локалхосте?
но я не использую плагины с сериализованными данными.
Ты сможешь не использовать. но их использует ВП. (хотя наверняка ты просто не знаешь как работают используемые тобой плагины и темы).
Но ОК, больше не буду мешать ходить по граблям и пытаться вразумить.
То, что вам нужно называется "автоматизация доставки и развёртывания". CI/CD и прочее. На вашем сервере один раз настраиваете деплой с гит-репозитория и далее просто вносите ваши изменения в репозиторий, а дальше по скрипту всё само задеплоится. Только не забудьте настроить и отладить процесс отката изменений на любую другую версию.
Спасибо, вникаю в тему.
Раньше я на рабочем VPS вручную конфигурировал nginx + mysql. А на локалке собрал себе конфиг docker-compose.
Получается на VPS я тоже буду собирать сервер на докере.
А как быть с крупными файлами и директориями с множественными файлами? Их, я так полагаю, не передают через git. Их все также отправлять с помощью rsync например?
Получается на VPS я тоже буду собирать сервер на докере.
На самом деле без разницы есть докер на сервер или нет. Докер - лишь способ упаковки зависимостей и создания фиксированного окружения. Вариантов CI/CD с докером куча. В командах и проектах от средних и больше обычно применяется следующий механизм:
Гит-сервер с репозиториями (свой или в чужом облаке) - гитхаб, гитлаб, битбакет и т.п.
Репозиторий контейнеров
Отдельный CI/CD сервер
По событию в репозитории для данного проекта запускается пайплайн с задачами: получение зависимостей, компиляция, сборка, авто тестирование и всего такого прочего на CI/CD сервере (в т.ч. сборка контейнеров и их публикация в репозитории контейнеров)
Если все автотесты и проверки проходят успешно - дальше запускается процесс доставки и развёртывания на сервере (либо автоматически либо вручную по отдельной кнопке тим/тех лидами или ПМ)
Скрипт подключается по SSH к серверу или серверам по очереди, останавливает запущенные приложения, получает свежие образы докера или другие артефакты сборки приложения и запускает приложения снова
А как быть с крупными файлами и директориями с множественными файлами? Их, я так полагаю, не передают через git. Их все также отправлять с помощью rsync например?
Зависит от того, что это за файлы. Для больших файлов есть git-lfs. Если же файлы - артефакты/результаты сборки - они временно хранятся в системе CI/CD и доступны в скриптах задач пайплайнов для доставки и развёртывания приложений.
Можете спокойно потренироваться в github или gitlab CI/CD процессах и разобраться во всём. Можно даже скачать и поставить в виртуалку полноценный экземпляр gitlab для экспериментов.
В моём понимании то, что Вы перечислили, делается один раз на старте. А доработки - это git push на рабочей копии, git pull на боевом. Хотя и сказано, что git - это не инструмент для деплоя, но для простых проектов этого хватает ( если исключить из рассмотрения минифицированные css и js файлы )
Поэтому неясно, о какой половине пунктов Вы говорите
С рабочего проекта приходится забирать себе базу данных (так как в нее клиент может внести за прошедшее время изменения например в текста) и директорию /uploads (так вероятнее всего появились новые файлы).
Я делаю mysqldump прямо в тему. Потом тему через push отправляю в гит. /uploads переношу с помощь rsync.
В докере бд забираю через pull-темы. Делаю замену .sql файла и запускаю docker-compose up, перед этим удалив старую бд.
Вадим Яндутов, если уж Вы /uploads переносите через rsync , то почему дамп базы не переносите так же? И то, и и то не должно попадать в гит по одинаковой причине.
Смотрите, как это вижу я:
1) есть тема Wordpress. Она в гите, тут вопросов нет
2) есть частные интеграции этой темы в виде сайтов заказчиков. Интеграция состоит из:
а) темы,
б) (на старте) чистой инсталляции Wordpress,
в) плагинов, добавленных заказчиком,
г) файлов, добавленных заказчиком,
д) данных в БД, добавленных заказчиком,
е) конфигурации ( в частности, какие-то изменения в .htaccess) .
При этом в гите, по-хорошему, должен отслеживаться только пункт 2.а - то есть частные доработки темы специально под этого заказчика. А остальное - чем-то автоматизировано (и это "что-то" под капотом может использовать rsync как транспорт ).
Это всё к тому, что на вопрос из заголовка ответ даже с ручными манипуляциями сводится к: git pull && wp dbi migrate
( для миграций можно и другой плагин поискать, я посмотрел первый попавшийся )
но только при правильном разделении, что есть что.