можно погуглить по baseimage

https://github.com/phusion/baseimage-docker

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

version: '2' services: php: image: "diphost/php:$(VERSION)" volumes: - /users/code/vasya/php56:/app - /users/shared:/shared nginx: image: "nginx:$(VERSION)" volumes: - /users/code/vasya/php56:/app - /users/shared:/shared ssh: image: "diphost/php:$(VERSION)" volumes: - /users/code/vasya/php56:/app - /users/shared:/shared command: sshd

сматри чо получаетя

мне это решение идеологически не нравится, впрочем (baseimage)

у тя есть самоосбранные контейнера с php

в них кроме самого php есть нужный набор софта

ssh cron чо там еще

клиент ssh-ится туда

запускает чо ему надо

а теперь представь, что таких полсотни на ноду/сервер

а теперь представь, что таких полсотни на ноду/сервер

да. так и будет

фил ?

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

но потом всё будет круче

по части управления/администрирования/обновления

использовать шаред php будет невозможно это да.

и типичного щареда когда у тя один инстанс впахивает на 100000500000 клиентов на одном сервере не получится

будет изоляция между клиентами

а значит потребления памяти

а значит нужна дедубликация памяти

и она вроде ка кпоявляется

тут или буквально 5 контейнеров на сервер, но тогда не будет вот этих извращений с 2 версии пхп для доступа по ssh на проект или же каждому свой пхп и прочее (и тогда нужно много оперативки)

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

по идее там в своп же уйдёт, да?

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

это будет дешевле, чем оперативку

zmem это как бы и есть свап. но свап сделанный на памяти...

но как быстро оно сдохнет от свопа - я не знаю

и там прямо в одном образе будут и апаче и nginx и обе версии пхп и openssh

ну это совсем уж

ну это совсем уж

ну, можно оставить только то, что нужно

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

фил ?

что? :) клинт не хочет ничего запускать. он хочет чтобы оно уже было

оно и не будет

где тут клтиент что запускает то ?

единственное что ему будет рвать шаблон что он не будет видеть в top процессы от php-fpm

кстати, я знаю, что DO , во-первых, не оверселлит оперативку, а во-вторых, контейнеры запускаются не на сетевых дисках, а на тех, что непосредственно подключены к серверу... не знаю, насколько DO ориентир, но вот так

вероятно, лучше всего купить двухголовую материнку , что-нибудь там с 24 слотами оперативки и набить их 32 гигабайтными модулями RDIMM

ну и получится достаточно низкая стоимость гигабайта

tree users users └── vasya ├── php56 │ └── index.php └── php7 └── index.php

ssh смонтирован так вот ssh: restart: always image: "diphost/php:$(VERSION)" volumes: - /users/code/vasya:/app - /users/shared:/shared command: sshd

то есть он заходит такой по ssh

и видит /app/php56 и /app/php7

кстати, про restart: always

там ведь нельзя порядок загрузки определить?

верно?

что за чем стартует

там ведь нельзя порядок загрузки определить?

вообще можно, но нельзя...

и видит /app/php56 и /app/php7

а

я понял

ssh то у нас будет от одной из версий.

вот поэтому через systemd мне больше нравится это делать

#shredhosting #hosting #diphost Смотрите. На самом деле как таковой проблемы нет. Есть три варианта глобально: 1. Я не использую докер для классических услуг шареда. Имею проблему со сборкой php 6-7 версий в одном флаконе. Таки собрав их так, я теряю смысл выделять в докер fpm и apache. Т.е. остается только допсервисы , о чем я писал выше. 2. Я делаю разные версии php на докерах и просто держу 6-7 докеров с кроном и shh на разных например IP (или как прокину), предлагая клиенту коннектится с разными реквизитами. И тогда всё очень легко, но неуверсальненько и клиент всегда путать будет. 3. Вариант (2), но phpXXX - это враперы делающие docker exex в предзапущенные докеры с нужной версией. Но латенси... Как-то так

кстати, я знаю, что DO , во-первых, не оверселлит оперативку, а во-вторых, контейнеры запускаются не на сетевых дисках, а на тех, что непосредственно подключены к серверу... не знаю, насколько DO ориентир, но вот так

её пока почти никто не умеет оверселить. всё быстрее упирается в ядро. а вот как он оверселит проц нам неизвестно

Вариант 3 грустно

хм

есть еще вариант

Вариант 2 можно сделать с указанием в имени хоста версии

собирать php в папки

Вариант 3 грустно

@smilingnavern расскажи нам

/php56 /php57

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

Вариант 2 можно сделать с указанием в имени хоста версии

это детали

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

но если очень надо - можно и несколько через baseimage (или аналогичные проекты)

собирать php в папки

На FreeBSD я так и делаю. И делаю симлинки. Но у debian неплохая обвязочка в пакете с php (хотя и пиздец было в ней разобраться), я наверное в его стиле просто с суффиксами сделаю типа в одном месте php56, php70 и так далее

ERROR: S client not available

так вот

version: '2' services: php: restart: always image: "diphost/php56" volumes: - /users/code/vasya/php56:/app - /users/shared:/shared command: /php56/php-fpm /app volumes_from: - php56 ssh: restart: always image: "diphost/php:$(VERSION)" volumes: - /users/code/vasya:/app - /users/shared:/shared command: sshd volumes_from: - php56 - php7 php56: image: "diphost/php56" volume: - /php56 php56: image: "diphost/php7" volume: - /php7

и ? какая мысль?

папки с пыхом

собранные с prefix /php{version}

предоставляеют сервис php нужной версии

Если я так смогу их собрать, зачем мне докер в итоге?

а в базовом образе есть системное окружение

для просто ты перебсорки.

вышла бяка для php56 пересобрал контейнер с php56

ну я так на сборке и буду делать

дак вопрос в том сколько персобирать же

и в том что бы контейнеры были одинаковыми несмотря на наличие "услуг"

вот если бы всё это не требовало кастомайза самого php, вот это бы было дело, а в итоге то всё одно php прийдётся менять, чтоб они смогли вконце заработать вместе

@smilingnavern расскажи нам

Привет:) ну с кроном и правда грустно. Самый простой вариант тягать по хттп вгет/курл. Либо делать отдельный ssh контейнер. Вон уже упоминали флант, у них же был проект https://github.com/flant/pam_docker который еще не успели затестить, но вроде он частично решает то, что нужно

Привет:) ну с кроном и правда грустно. Самый простой вариант тягать по хттп вгет/курл. Либо делать отдельный ssh контейнер. Вон уже упоминали флант, у них же был проект https://github.com/flant/pam_docker который еще не успели затестить, но вроде он частично решает то, что нужно

плюсую.

Привет:) ну с кроном и правда грустно. Самый простой вариант тягать по хттп вгет/курл. Либо делать отдельный ssh контейнер. Вон уже упоминали флант, у них же был проект https://github.com/flant/pam_docker который еще не успели затестить, но вроде он частично решает то, что нужно

я тебя призвал чтобы не быть испорченным телефоном и ты сам сказал именно то, что сказал ;)

Привет:) ну с кроном и правда грустно. Самый простой вариант тягать по хттп вгет/курл. Либо делать отдельный ssh контейнер. Вон уже упоминали флант, у них же был проект https://github.com/flant/pam_docker который еще не успели затестить, но вроде он частично решает то, что нужно

Однако флант это лок версии на юзера

пам_докер это способ избежать вообще логина в хостовую систему

а внутри контейнера одного держать допустим несколько php-cli

что не очень удобно, но уже лучше

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

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

не увидел связи

Это к теме что отдельные крон контейнеры не оч

Это к теме что отдельные крон контейнеры не оч

Не, нет контейнера с кроном

крон работает на хосте

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

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

ну по крайней мере так выглядит на бумаге

Меня напрягает стоимость завертывания неймспейса. Пусть и через pam

Я вообще не понимаю зачем сущность , которая вторгается в систему

Это какой-то манки патчинг