переношу сайт клиента в докер, что заложить сразу чтоб потом не плакать

Переношу клиентский wordpress в докер (был на голом сервере), чтоб потом обновлять и бэкапить по-человечески. Собрала для себя список «заложить сразу, а не потом», делюсь, потому что «потом» обычно случается после того, как что-то легло:

• named volumes для данных (wp-content, база), не bind абы куда
  
• restart: unless-stopped, а то после ребута сервера сайт не поднимется сам
  
• mem_limit каждому контейнеру, чтоб один не утащил остальных
  
• бэкап volume ДО первого обновления, а не после
  
• логи с max-size, иначе диск забьётся тихо
  

Что ещё вы жалели, что не заложили сразу при переезде в докер? Собираю грабли заранее.

kate_ekb healthcheck бы добавил в список — чтоб «контейнер жив, но приложение висит» ловилось, а не считалось рабочим. я на этом попадал: docker ps зелёный, а сайт 502. и .env отдельным файлом, не в compose открытым текстом, а то потом креды в гит уедут вместе с yaml.

kate_ekb как свежепострадавший добавлю: права на volume) я папку рутом создал, контейнер под своим юзером — permission denied и вечный рестарт. так что named volume как ты и советуешь, тогда docker сам права разрулит. записываю твой список, у меня как раз следующий сайт на очереди.

nesterov принято, дописываю: бэкап не разовый «перед апдейтом», а по cron в другое место + проверка разворотом. tema_py healthcheck и env_file добавила. max_nn права на volume — да, это первый же затык у всех. вот и собрали чеклист переезда в докер силами троих пострадавших и одного Нестерова)

kate_ekb список хороший. одна поправка по сути: «бэкап volume до первого обновления» — мало. бэкап по расписанию и проверка, что он разворачивается. переезд в докер часто усыпляет: «теперь всё в volume, надёжно». volume это удобство, а не сохранность, диск один и тот же. дамп в другое место — вот сохранность.

kate_ekb к вашему чеклисту переезда в докер одно, вечно последнее в списке: перед миграцией сделайте дамп СТАРОГО, до того как трогать. люди переносят, ломают на полпути, а отката нет — старое уже разобрали. дамп исходного состояния в другое место, потом миграция. и после — проверка, что из него встаёт, а не «вроде перенёс».

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

max_nn, к фиксации версий полезно добавить порядок работы с логами. У остановленного, но не удалённого контейнера docker logs обычно ещё доступен; после удаления судьба логов зависит от выбранного драйвера и хранения. Поэтому заранее стоит решить, что сохранять вне контейнера и как долго. Где у тебя сейчас лежат логи приложения — в stdout или в отдельном файле?

max_nn писал:
Какая часть переноса сейчас сложнее: постоянные данные, конфигурация или само обновление?

Данные. Не потому что дамп сложно снять — а потому что старый сайт живёт, пока ты переезжаешь.

Свежий пример из этого же переезда. Подняла всё на новом сервере, проверила, сижу довольная. Захожу на старый посмотреть — а там за сутки три заказа и два комментария. Дамп-то вчерашний. Повезло, что это был тестовый прогон, а не боевое переключение: иначе объясняла бы клиенту, куда девались его заказы, а это разговор, после которого клиенты уходят.

С тех пор порядок жёсткий:

1. Сначала полный подъём на новом месте: сайт открывается, формы отправляются, админка пускает. Старый при этом работает, его никто не трогает.
2. За сутки до переключения опускаю TTL у A-записи до 300. Это пункт, который все вспоминают уже после: пока TTL сутки, половина посетителей ещё долго ходит на старый сервер и оставляет там заказы, которых на новом нет и не будет.
3. В час X на старом включается maintenance mode и снимается финальный дамп — только базы, файлы за это время не меняются:

mysqldump -u wp -p wp > final-$(date +%F).sql

4. Разворачиваю дамп на новом, переключаю DNS, проверяю с телефона через мобильный интернет — домашний резолвер обожает кэшировать старую запись и делать вид, что «ничего не работает».
5. Старый сервер не сношу неделю. Выключенный, но целый. Откат тогда — это power on, а не ночь с бэкапом.

По обновлениям с фиксацией версий согласна, добавлю два своих правила. Первое: никакого :latest и даже никакого :6 — только полный тег, wordpress:6.6.2-php8.2-fpm, и mariadb так же. Второе: никаких автообновлялок на клиентском проде. watchtower и компания — для домашних сервисов, где ты сам себе заказчик. У платящего клиента обновление это событие: pull на копии с другими портами, прогон, глазами по сайту, и только потом боевой. Один :latest как-то притащил мне мажорный mariadb, который отказался подниматься на старых данных. С тех пор это не привычка, а религия.

По разделению — да: nginx, wordpress-fpm и mariadb отдельными сервисами, тогда образ вордпресса обновляется, а базу ты даже не перезапускаешь. Только не увлекайся в обратную сторону: однажды видела compose, где на каждый плагин завели свой контейнер. Вордпресс — не микросервисы, ему так не надо)

Так что в чеклист из первого поста добавляются две строки: TTL опустить заранее и старое не разбирать неделю. Обе стоят ноль рублей и срабатывают ровно один раз — но какой.

А у кого-нибудь получалось переехать совсем без maintenance-окна, на живом трафике? У меня — нет, и я с этим смирилась.

kate_ekb писал:
За сутки до переключения опускаю TTL у A-записи до 300

это правильно, но как на гарантию на ttl бы не рассчитывала. мобильные операторы и часть резолверов кладут на него с прибором: зажимают минимум сутки, а браузеры кэшируют вообще как хотят. я так переносила open webui для одной конторы — ttl опущен заранее, dns переключен, сижу довольная. через сутки смотрю в логи старого сервера, а там живые люди. одна девушка ещё два дня документы грузила в старый инстанс, пока у неё кэш не протух.

с тех пор старый сервер после переключения не гашу, а оставляю на пару дней проксёй на новый: nginx с proxy_pass, или проброс портов, если лень конфиг трогать. «опоздавшие» тогда попадают сразу на свежую базу, а не на maintenance. и плюс у этого побочный: дельта после финального дампа перестаёт существовать как класс, всё пишется в новое место с первой минуты.

maintenance-заглушка красивая, но пользователь, который второй день видит «ведутся работы», звонит клиенту, а не ждёт)

max_nn писал:
тогда docker сам права разрулит

разрулит — ровно один раз, при первом создании. пустой named volume docker наполняет содержимым каталога из образа вместе с владельцем, оттуда и магия. но если в самом образе каталог рутовый, а процесс внутри ходит под своим юзером — получишь тот же permission denied, только уже в красивом именованном томе. так что перед переездом глянь, под каким uid живёт приложение в образе, это решает, будешь ты chown делать или нет.

и ещё: том у тебя уже создан с кривым наполнением. права на хосте поправишь, а внутри тома как было, так и останется — первое наполнение не перезаписывается. если переезд свежий и ценного там пока нет: compose down, docker volume rm, поднять заново.

отдельно про вечный рестарт: restart: unless-stopped — самый преданный процесс на сервере, будет поднимать твой падающий контейнер до скончания времён) хорошо хоть причина в логах лежала на виду, а не «сайт не открывается, хз».

masha_spb, прокся на пару дней — беру, это лучше моей заглушки. чтобы идея не осталась словами, конфиг на старый сервер:

server {
    listen 80;
    server_name site.ru;

    location / {
        proxy_pass http://NEW_IP;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

две строки тут критичные. Host — без него wordpress на новом не поймёт, кого звали, и отдаст дефолтный vhost или уедет в редирект. X-Forwarded-For — без него в логах нового все «опоздавшие» будут с адресом старого сервера, и fail2ban рано или поздно забанит твою же проксю.

DNS к этому моменту уже смотрит на новый адрес, конфиг ловит только застрявший кэш. пара дней — и старый гасится совсем.

max_nn, раз следующий сайт на очереди — впиши этот пункт в план сразу, пока чеклист горячий. и отпишись потом, сколько народу пришло через проксю: у меня статистики по «опоздавшим» нет, любопытно, много ли их на самом деле.

masha_spb писал:
одна девушка ещё два дня документы грузила в старый инстанс

ради таких девушек прокся и держится) только в тот конфиг на старом добавь proxy_set_header X-Real-IP $remote_addr; и X-Forwarded-For, а на новом set_real_ip_from со старым адресом — иначе в логах все посетители съедутся на один ip прокси, как в общагу. и потом объясняй клиенту, почему вся страна заходит с одного адреса.

masha_spb, мне такой позвонил в субботу, когда я на даче. DNS уже переключён, а у него открывается старый сервер.

теперь «пару дней» — только прикидка. смотрю обращения в access.log старого сайта: пока туда приходят посетители, оставляю nginx передавать запросы на новый сервер. календарь за них DNS-кэш не очистит)

Катя, прочитал про старый сервер и сразу подумал о ярлыке 1С на рабочем столе. Сервер уже считается «бывшим», а для сотрудника ничего не изменилось: двойной щелчок, знакомая база, можно проводить накладную. Только на новом месте этой накладной уже нет.

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

У вас с проксированием проще для самого пользователя: он может даже не заметить старый адрес. А в логах старого сервера как отличаете оставшихся посетителей от ботов и служебных проверок?

misha_1c, по одному access.log людей от ботов надёжно не отделить. Человек может открыть каталог магазина и ничего не заказать — все запросы будут GET. А бот может отправлять формы и загружать страницу вместе с картинками. Поэтому «нет POST — нет посетителей» здесь не работает.

Я бы посмотрела, какие страницы ещё запрашивают на старом адресе, в какое время и с какими результатами. Известные проверки доступности можно выделить отдельно, но остальные запросы не стоит автоматически объявлять сканерами.

Важнее проверить сам перенос: старый nginx действительно передаёт запросы на новый сайт, а старая копия приложения больше не принимает изменения. И отдельно проверить форму заказа, вход и загрузку файла — не только главную страницу.

Срок отключения старого сервера лучше согласовать заранее, с учётом прежних DNS-настроек и оставшихся обращений. Одни сутки без заказов не доказывают, что все уже попадают на новый адрес. Для вашей 1С мысль та же: старый ярлык не должен вести в базу, где ещё можно продолжать работу.

masha_spb, согласовать срок — самое больное место, да. Я у клиентов старую базу после переезда не «прошу не трогать», а снимаю с публикации и убираю из списков на рабочих местах. Один раз пожалел, оставил «на всякий случай» — через неделю нашлись две накладные, проведённые не туда. С тех пор «всякий случай» — это выгруженный dt на диске, а не живая база. Форму заказа, кстати, проверяете тестовым заказом до самой оплаты?

misha_1c, до самой оплаты, иначе не считается. У меня был переезд, где форма работала, заказ падал в базу, письма уходили — а платёж молча не проходил: callback от эквайринга был зашит на старый домен в личном кабинете банка. Обнаружил это не я, а покупатель, у которого «оплата зависла». С тех пор тестовый заказ оплачиваю настоящей картой, потом делаю возврат. Пара рублей комиссии — дешёвая страховка)

И да, dt на диске вместо живой «запасной» базы — это ровно то же, что у нас с maintenance: запасной вариант не должен уметь принимать работу.

маш, у вас с мишей переезды звучат как детективы с продолжением) у меня тест обычно «ну вроде открылось». покупатель с настоящей картой в роли краш-теста — это сильно, уважаю