Использовать mysql в контейнере docker в продакшене или нет?

Question

[iRedds]

Поставлена задача перевести сайты с шаред хостинга на VPS и запустить их в изолированных docker контейнерах.
Я дела не имел с докером ранее, поэтому придумал такое решение:
nginx (прокси) -> [контейнер 1(apache + php + mysql)] <= volume(сайт 1 + база1)
nginx (прокси) -> [контейнер 2(apache + php + mysql)] <= volume(сайт 2 + база2)
Но получил совет, что mysql в контейнере для продакшена не тру.
Скажите, в чем могут проблемы/подводные камни размещения mysql в контейнере, при том, что сама база будет находится на хосте докера.

Answer 1

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

mysql в контейнере для продакшена тру. Вот вам совет.

Только контейнеров у вас будет 4 (при условии что хост один):

• nginx
  
• apache
  
• php
  
• mysql
  

Только вопросы к вам такие:
- а нафига вам тут апач?
- а зачем изолированные контейнеры этим сайтам?

Comments

[hOtRush]

Ну и вечный вопрос костылестроения на докере - как раздавать статику nginx'ом из контейнера с пхп)

[iRedds]

Т.к. сайты с шареда, то там наследие в виде mod_rewrite и прочего .htaccess.
Изолирование сайтов от хоста и друг друга требование заказчика.
Но разве можно разделять apache и php в разные контейнеры?
И почему 4 контейнера лучше чем 1?
зыЖ nginx я поставил непосредственно на хостовую машину. (Есть ли смысл его пихать в контейнер?)

[Sanes]

iRedds, изолируйте на уровне пользователя. В чем проблема?

[iRedds]

Sanes, аргументом было то, что если будет взломано окружение в контейнере, то хостовая система не пострадает.
Чтобы мне парировать, нужно не только разбираться хорошо в этом вопросе, но и приводить правильные аргументы со своей стороны. Но если бы я разбирался, то не спрашивал как поступить.

[metajiji]

Если решили все в докер, то почему бы и нет? В кубиках же деплоят и все тру.
Оборачиваете каждый сайт в docker-conpose, 1 программа = 1 контейнер, а 1 сайт это ещё и 1 вольюм и 1 юзер сеть(docker link все никак не выпилят, но он уже deprecate) в общем все как в kubetnetes pods.
Помните о вольюмах и ресурсах, больше серверов баз данных - больше потребление памяти.

И важно, с докером вы получите крутой Профит в виде крайне быстрого старта окружения с фиксированными версиями. Но самое важное сможете все это тестировать локально или где вам удобно.
Для автоматизации деплоя не обязательно docker-compose, можно и ansible/etc.

Кстати nginx тоже не нужно ставить на хост, запускайте его в контейнере с опцией --net host, а конфигурации в фольюм, но думаю итак очевидно, что все генерируемые контейнером данные нужно складывать в вольюмы.

Answer 2

[Sanes]

LAMP/LEMP стек заворачивать в докер это глупость. Разные версии PHP сделать не проблема, MySQL достаточно свежей версии 5.6 или 5.7.

Comments

[iRedds]

А что можно заворачивать в докер на ваш взгляд?

[Дмитрий Евграфович]

Почему глупость?

[Sanes]

Дмитрий Евграфович, зачем всё усложнять?

[Дмитрий Евграфович]

Sanes, мда

Answer 3

[part_os]

Не переходи пока у вас не будет опыта по пониманию что это такое и как это пнуть что бы взлетело в 3 часа ночи.

Answer 4

[⚡ Kotobotov ⚡]

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

Comments

[iRedds]

А если пробросить директорию c базой в контейнер с СУБД с хоста?

[⚡ Kotobotov ⚡]

iRedds, это типовое решение.
еще вариант делают просто взаимодействие разных микросервисов, и база также работает как один из таких микросервисов.

[metajiji]

⚡ Kotobotov ⚡, ничего не пропадает при перезапусках. С чего вы взяли? У вас же при рестарте ос файлы не исчезают с дисков. :)
А вот если удалить ос, то и файлы удалятся.
Не вводите в заблуждение людей.
Внутренности контейнера будут удалены, если их удалить, а удалить их можно удалив контейнер. Другими словами start/stop ничего не удаляет, а вот rm да ещё как удаляет. Для тех кто забыл про вольюмы есть несколько варианто, например docker stop, docker cp, docker run -v. Ну или не дай бог docker commit

[⚡ Kotobotov ⚡]

metajiji, ну ты поставь бд в контейнере и посмотри как это работает

[metajiji]

⚡ Kotobotov ⚡, каждый день работаю с postges, mariadb и другими подобными демонами и проблем не имею ;)

[⚡ Kotobotov ⚡]

metajiji, лень спорить, разберись просто подробнее с чем и как ты работаешь.

[metajiji]

⚡ Kotobotov ⚡, давай я тебе расскажу как это работает и ты поймешь :)
Итак по порядку,
1. Images - Образы. Они состоят из слоев - layers. Слои создаются при сборке образа, это когда ты пишешь docker build. Образ собирается из Dockerfile, 1 строка из этого файла = 1 слой, найти их можно в /var/lib/docker/images/
2. Containers - Контейнеры. Они тоже состоят из слоев, но есть 1 нюанс, они состоят из image + 1 слой, который сейчас исполняется (runtime), /var/lib/docker/containers/, создаются контейнеры командой docker run или docker create. После создания контейнера файловая система собирается из слоев используя технологию overlay, даже если под капотом lvm, aufs или другие. Суть в том, что каждый последующий слой перекрывает файлы нижних слоев, runtime слой самый верхний.
3. Мы уже поняли, что все Containers это почти image, но только находящиеся в runtime, так вот можно из контейнера создать image командой docker commit. А для этого нужно остановить контейнер выполнив docker stop, при вашем концепте работы все удалилось бы! И да, вопрос как ребутнуть сервер, не останавливая контейнеры? Ы?! Конечно же все это не так, команда docker stop никогда ничего не удаляет, удаляет только docker rm. Если после того, как у вас контейнер остановился и вы его не видите в docker ps это вовсе не значит, то контейнер был удален! docker ps - показывает только Running контейнеры, а ваш stopped контейнер можно найти так: docker ps -a, а потом запустить docker start, уверяю вас, файлы будут внутри целые - они живут в runtime слое, который кстати можно конвертировать в image, если это будет необходимо :)

Выводы,
Создаем контейнер с базой docker run -d --name db mysql
Работаем с ним, а потом вдруг понимаем, что файлы-то от базы внутри контейнера, что делать? Все просто:

docker stop db
docker cp db:/var/lib/mysql /volumes/mysql-data
docker stop db  # Файлы базы по прежнему живы.
docker commit db mysql-bkp  # Это делать не обязательно, но вдруг что-то забыли еще скопировать
docker rm db  # теперь файлы базы удалены, но у нас есть image с этими файлами.
docker run -d --name db -v /volumes/mysql-data:/var/lib/mysql mysql

И о чудо, в новом контейнере файлы базы на месте, просто магия какая-то :)

Если все устраивает, то можно удалить образ со старым контейнером, который мы сделали на предыдущем шаге:
docker rmi mysql-bkp

Если вдруг выяснилось, что забыли скопировать, например /etc/my.cnf из контейнера, то делаем так:

docker create --name mysql-old mysql-bkp  # создали контейнер, но не запустили
docker cp mysql-old:/etc/my.cnf ~/my.cnf_old  # скопировали файл из контейнера на хост
docker rm mysql-old  # Удалили контейнер

Теперь у нас есть файл ~/my.cnf_old :)

Answer 5

[ewolf]

Пара советов:
1. Подумайте об отказе от Apache - он в 2018 году ничего вам не даёт. Возможно, у вас завязаны на него какие-то правила роутинга - попробуйте перевести их на nginx
2. Не запускайте всё в одном контейнере: сделайте по контейнеру на процесс (отдельно на PHP, отдельно nginx) . Это даст вам возможность использовать стандартные имаджи. Если уж всё-таки оставите апач, тогда у вас будет контейнер с Apache+PHP, так как скорее всего вы используете модуль врача, но повторюсь - постарайтесь от апача отказаться.
3. Постарайтесь отказаться от волумов в продакшен для кода. Собирайте свой имадж на базе стандартного с добавлением в него вашего кода на этапе сборки. Посмотрите про это статьи. Так у вас будет возможность деплоить контейнер целиком, а не подкладывать ему папку с кодом. Это сделает систему стабильнее и переносимей.
4. Вам не нужен MySql в контейнере: во-первых это оверхед иметь отдельный инстанс MySql на каждый сайт. Во-вторых, вам нужно обеспечить персистанс данных, что означает использование volume. Это сложнее и имеет свои недостатки: медленнее и т.д. Запустите MySql на отдельном сервере или даже на том же, где докер, но не в контейнере - сэкономите ресурсы и нервы. Когда разберётесь, посмотрите на докеризацию базы ещё раз.

Answer 6

[Станислав Бодро́в]

Скажите, в чем могут проблемы/подводные камни размещения mysql в контейнере, при том, что сама база будет находится на хосте докера.

Будь готов, что будет жрать место на диске как из пистолета. В остальном проблем нет. Возможный оверхед от использования базы в контейнере, компенсируется никакущими настройками сервера базы (ты же не занимался профилированием сервера под текущий профиль нагрузки?) и кривизной самой базы (в планировщике кто-нибудь отлаживал запросы?). Поэтому беспокоиться не стоит.
Best practice говорит не хранить данные в контейнеры, поэтому файло базы надо выставить наружу контейнера, использую механизм volume.