чет вы все антипаттерны собрали

А в чём минус хостинга на контейнерах?

Наоборот - изоляция сайтов

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

нет, проблемы с хостингом никакой нет

проблема в том что вы завязываетесь на USER-id

а еще монтируете конфиги снаружи

это вот не правильно, по хорошему ваши контейнеры должны настраиваться из ENV параметров

а монтировать в контейнер надо либо хранилище с какими нить upload_dir, либо tmpfs для временного шлака

tmpfs сам ведь монтируется?

У меня в контейнер также монтируется директория с сайтом, которая лежит на хосте.

В противном случае клиент не сможет получить доступ к файлам сайта

У меня в контейнер также монтируется директория с сайтом, которая лежит на хосте.

это тоже антипаттерн

в контейнере должен быть сайт, read-only

файлы сайта же

чтобы контейнер можно было на любом другом хосте запустить с теми же параметрами и все работало

ну файлы сайта желательно хранить на какой нить хранилке

типа gluster, на худой конец в nfs

в контейнере должен быть сайт, read-only

Так всё равно придётся откуда-то монтировать файлы сайта в контейнер

файлы сайта уже должны быть в контейнере

Так всё равно придётся откуда-то монтировать файлы сайта в контейнер

не в контейнер, а в имедж

при билде

вне контейнера могут быть скажем залитые юзером файлы

и их нужно менеджить отдельно

но сами файлы сайта - должны быть в самом образе

как и конфиги

но сами файлы сайта - должны быть в самом образе

Всё равно залитые юзером файлы должен кто-то как-то читать

Поэтому нужен будет доступ к этим файлам на хосте

Поэтому нужен будет доступ к этим файлам на хосте

ты просто прикипел к неправильной модели архитектуры

Всё равно залитые юзером файлы должен кто-то как-то читать

по файлам сайта - ceph, gluster,nfs, volume контейнер

Поэтому нужен будет доступ к этим файлам на хосте

еще раз, доступ к ним отдельная тема, как его сделать другой вопрос, но сам сайт - должен быть внутри image

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

не в контейнер, а в имедж

Тогда у меня будет очень большое кол-во images

Тогда у меня будет очень большое кол-во images

а имеджи должны быть не у тебя

вернее они будут у тебя, ты их хранишь да

в этом весь смысл докера

у тебя есть на каждый сервис по имеджу

Тогда у меня будет очень большое кол-во images

будут, но по месту будет то же самое, они же слоеные

они же кешируются

то есть базовый образ будет один

а вот все остальное доброе которое клиентское..его и так и так будет дофига

У меня уже сейчас есть большое кол-во базовых образов. А файлы клиентов можно хранить в volume. Но вдруг клиенту срочно понадобится доступ к этим файлам по FTP/SFTP

И всё

У меня уже сейчас есть большое кол-во базовых образов. А файлы клиентов можно хранить в volume. Но вдруг клиенту срочно понадобится доступ к этим файлам по FTP/SFTP

доступ на чтение? - код лежит в их хомике. что-то поправить - надо билдить имедж с новым кодом

Я так понимаю файло хранить отдельно для пользователей, чекать изменения, собирать образы и их использовать

У меня уже сейчас есть большое кол-во базовых образов. А файлы клиентов можно хранить в volume. Но вдруг клиенту срочно понадобится доступ к этим файлам по FTP/SFTP

если код клиентов не раскатывается через нормальные процессы CI то докер вам не нужен и будет только создавать геморрой

если клиентов мало и вы не можете сделать распределенную систему хранения - докер вам тоже скорее всего не нужен

Большинство клиентов - пользователи CMS (Drupal, Wordpress,Joomla и иже с ними)

А по поводу опыта распределенной системы. Вы как ее используете прям на докер хостах или отдельный кластер?

поставим вопрос иначе: зачем вам вообще докер?

поставим вопрос иначе: зачем вам вообще докер?

1) Возможность жёстко лимитировать ресурсы (оперативная память и ресурсы процессора) 2)Сайты в контейнерах изолированы друг от друга, и если на один сайт проникает вирус, то на второй он не проникнет. 3)Возможность использовать различные версии PHP в режиме mod_php (Apache)

> если на один сайт проникает вирус, то на второй он не проникнет как же он не проникнет, если у вас все прокинуто вольюмами

> если на один сайт проникает вирус, то на второй он не проникнет как же он не проникнет, если у вас все прокинуто вольюмами

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

Вы могли обычные виртуалки делать

Kvm

Потому что то что вы делаете с докером считается некорректным

> если на один сайт проникает вирус, то на второй он не проникнет как же он не проникнет, если у вас все прокинуто вольюмами

В одном контейнере примонтирован только один сайт. В контейнере нет файлов других сайтов.

ну или chroot вроде тоже подошел бы

просто так получается что постоянно надо писать против ветра и постоянно будут вопросы, а на них будут отвечать, что вы хотите от докера странного =)

И всё же, подход с images - это подход при разработке серьёзного проекта, а моя задача - это хостинг обычных сайтов. Была идея хранить данные сайтов в volumes и также иметь отдельный контейнер с SSH сервером, к которому были бы примонтированы все волюмы

Чтобы была возможность доступа по SFTP

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

Просто нужно это совместно реализовать, сам, кстати, тоже планирую использовать кубер для хостинга сайтов

и еще. вы с базой данных что думаете делать? Отдельно выносить или использовать так же в контейнерах?

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

Я уже использую images, только у меня в images лежит набор ПО. У меня общий на всех контейнер с БД.

Ну а чем плохо запихнуть сайты/файлы в контейнер?

Ну а чем плохо запихнуть сайты/файлы в контейнер?

У юзеров не будет доступа к файлам сайтов

У них будет отдельный доступ, просто какой-то фтп сервер, куда они будут их складывать. Нет?

ERROR: S client not available

Соответственно, нужно периодичски проверять изменения в этих дирректориях и генерить имаджи

какое то тоже сомнительное решение

У них будет отдельный доступ, просто какой-то фтп сервер, куда они будут их складывать. Нет?

У меня была идея сделать отдельный контейнер с SSH сервером. К этому контейнеру примонтироватьвсе volumes

Ну а какое хорошее на ваш взгляд?

докер для такого сценария не юзать

он ничего не дает

И чем оно отличается от проверок в гите и генерации образа?

проще нарубить процессов php

он ничего не дает

Кроме возможности запуска нескольких apache с разными версиями php

вам проще каждый сайт пихать в свою виртуалку

или взять что то типа proxmox

там хоть под капотом тот же LXC но сама концепция отличается

вам она больше подойдет

там хоть под капотом тот же LXC но сама концепция отличается

А чем отличается их концепция от моей?

в proxmox контейнеры это типа виртуалок, с ссш и прочим хламом

и мигрировать их вам будет легко

все одним большим куском

А чем отличается их концепция от моей?

lxc персистед

докер - пер процесс

вообще конечно ovz попахивает

ага

в proxmox контейнеры это типа виртуалок, с ссш и прочим хламом

Так вот именно что виртуалки с SSH мне не нужны. Мне нужна виртуалка, где стоит только Apache/php-fpm

это вот их кейс как раз

ну не ставьте тогда ссш и все ))

Так вот именно что виртуалки с SSH мне не нужны. Мне нужна виртуалка, где стоит только Apache/php-fpm

а сфтп куда?

ну если сфтп то ссш нужен )

вы уж определитесь, ссш нужен или нет

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

если у вас stateless приложения

ну сайты являются stateless приложением?

если у вас stateful приложения но с нормальной кластеризацией

Один провайдер уже выпустил хостинг на LXD