Зоопарк у разработчиков

то возможно ли (удобно ли) использовать его только на машине разработчика?

конечно возможно

Или такое решается другими путями?

virtual environment:
python-venv
virtphp

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

А можно в двух словах. Вот человек работает над проектом, установлены php и apache, результат он видит и по мере отправляет на сервер git. Если я добавляю docker в котором нужная версия php то как её видит веб сервер? С отправкой, насколько я понимаю, проще: можно перейти в каталог докера и оттуда отправить?

Для таких целей нужен пакетный менеджер, который это умеет. Докеры, виртуалэнвы, виртуалки и отдельные сервера — костыли и каменный век.

docker volumes, суть в том что проект лежит у тебя в каталоге на диске и монтируется в docker контейнер, в котором уже есть apache/nginx для локальной разработки. Правишь файлы в каталоге, запускаешь docker, смотришь результат, если все устраивает отправляешь в git

То есть у каждой версии свой веб сервер? Спасибо, в целом понятно.

Да, думаю если поискать то на dockerhub должны быть готовые сборки web+php/python с разными версиями последних, на их основе можно под себя собирать

Связка pip и virtualenv — это в каком-то смысле и есть пакетный менеджер, умеющий в несколько версий. Nix, конечно, хорош концептуально, но то, что при внесении в какую-нибудь библиотеку микропатча, не влияющего на ABI, лишаешься бинарных кэшей — не самое практичное на свете решение.

Да,мы поняли, Nix умеет в симлинки)

Ну не стесняйся, я же вижу, что ты хочешь это сказать :)

Скорее так: веб-сервер упакован в контейнер, а ты просто запускаешь нужный контейнер в нужный момент времени, прокинув ему файлы проекта.

нужен пакетный менеджер

дискасс: докер - это пакетный менеджер

Собственно, контейнер существует ради некой версии php (в данном случае). То есть в нём есть php, и, в идеале, больше ничего. Но поскольку хостовый веб сервер, насколько я понимаю, не может использовать php из контейнера, то по большой нужде туда прилагается таковой собственный.

Но у меня возник ещё вопрос, а в контейнере язык со всеми модулями? И если какого не хватает, то установку модуля вписывать в файл описания?

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

Насколько я понимаю, для таких целей и нужен docker

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

Например, какие-то новые образы не работают в старых версиях докера (принуждая, например, делать seccomp=unconfined), или в старых ископаемых версиях, например, libc используются сисколы, отсутствующие в новых ядрах.

То есть, ответ присутствует в твоем вопросе: да, «но в некотором диапазоне» :))

1. Как в Dockerfile написано, так и будет.
2. В вашем случае может пригодиться подход, когда есть несколько образов. Базовый — содержит, например, апач, php и модули нужные примерно всегда. На его основе создаются дочерние образы, с модулями, нужные в конкретно этом проекте. Таким образом каждый образ содержит ровно то, что нужно, но при этом не нужно руками обновлять одно и то же, в сотнях почти одинаковых образов.

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

Нет, это датацентр.

Можно докер использовать.

Про другие пути не знаю. Ну виртуалки разве что, но вряд ли это будет удобней.

Нет, в этом случае пакетный менеджер - ты.

Собственно, контейнер существует ради некой версии php (в данном случае). То есть в нём есть php, и, в идеале, больше ничего.

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

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

Почему не может? Я по PHP не спец, но вроде там или через CGI или через FastCGI идёт связь с веб-сервером. Нет никакой проблемы с хостового веб-сервера «достучаться» до контейнера.

Другой вопрос - что если уж докер использовать, то по-полной и от хоста вообще ничего не требовать (ну кроме, собственно, самого докера). Чтобы весь стек поднимался одной командой - с PHP, апачем и мускулем, или что там у вас. Ну для начала можете и частично использовать, потом постепенно разберётесь, как вам удобней.

Но у меня возник ещё вопрос, а в контейнере язык со всеми модулями? И если какого не хватает, то установку модуля вписывать в файл описания?

Да, так делать - правильно.

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

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

Туда еще и всякие БД можно подтянуть через композ, если нужны специфичные.

Могу в личку (почту, например) более подробно рассказать применительно к твоей задаче, если ты, конечно, можешь раскрывать подробности.

докер - это пакетный менеджер

Юниксвей: «все есть файл».
Линуксвей: «все есть пакетный менеджер».
Начиная с tar, install, make и sh, проходя «классические» ПМ для всяких дебов с рпмами, зацепив офисы, редакторы всего, браузеры, DE с их темами и иконпаками, суперблокноты типа vscode, затронув примерно все ЯП (maven, cpan, pear, pip, триллион жаваскриптового говна, cargo, bundler, whatever) и по самый docker и vagrant. Плох тот софт, что не умеет ставить пакеты.

поставить несколько версий php или python

pyenv
phpenv

В целом более-менее понятно. Если и описывать то не частный случай а в общем виде. Если это имеет смысл то в виде статьи, например, можно будет по результату описать.

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

Ну обычно же напрямую же php не дёргают, а через php-fpm. А у него уже есть сокет(файл)/порт который можно вывести из контейнера в систему.

Ну обычно же напрямую же php не дёргают, а через php-fpm. А у него уже есть сокет(файл)/порт который можно вывести из контейнера в систему.

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

Так «философия» докера — один exe'шник на контейнер. Так что в одном контейнере он запускает php-fpm, в другом nginx, в третьем mysql.
И все они взаимодействует друг с другом через сокеты/порты.
Так что это всё в духе докера.
//Потом ещё докер-композе.

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

Так-то так.. Но всё же «браузеры», на основе которых уже делают «суперблокноты» — это уже не «пакетные менеджеры», а что-то типа «ОС», т.к. кроссплатформенно и всё барахло таскают с собой и в своё окружение уже ставят пакеты.
Так что «каждая программа стремится стать ОС». Современные браузеры в чём-то пошли по пути Emacs.

Точно, это Emacs-way или даже шире Lisp-way. Всё же жаваскрипт создавался под впечатлением от Scheme.

А ещё была поговорка «любая достаточно сложная программа на C или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp».

Слишком сложно..

«каждая программа стремится стать ОС» -> «любая достаточно сложная программа на C содержит Lisp»

Есть только один путь — Lisp-way и все идут по нему.

Сложилось затруднение. Не основе этого описания делаю один контейнер. Nginx на хосте, mysql текущий, всё сильно проще потому что в эксплуатации докер пока не предполагается и задача только ликвидировать^W возглавить "${SUBJ}".

Первый контейнер получается исправно, в nginx вижу phpinfo. Но пересоздавать контейнер при каждом редактировании кажется не очень эффективным и решаю держать скрипты php вне контейнера, монтируя с типом bind. Первый оставляю как образец.

Но у второго контейнера nginx показывает «Bad Gateway». Открыл в нём шелл но команды ps там нет. Есть ls, уже хорошо, с монтированием я кажется справился и содержимое index.php меняется при изменении на хосте.

Выглядит так что никто не слушает заданный порт, но в информации о конетйнерах 9002 есть:

ad@devel04:~$ docker ps
CONTAINER ID   IMAGE                           COMMAND                  CREATED        STATUS        PORTS                                                                                            NAMES
6bccd746ecc6   example2_php                    "docker-php-entrypoi…"   17 hours ago   Up 17 hours   9000/tcp, 0.0.0.0:9002->9002/tcp, :::9002->9002/tcp                                              example2_php_1
9cb33ab554db   example_php                     "docker-php-entrypoi…"   22 hours ago   Up 22 hours   0.0.0.0:9000->9000/tcp, :::9000->9000/tcp                                                        example_php_1
685c7c464341   portainer/portainer-ce:latest   "/portainer"             47 hours ago   Up 47 hours   0.0.0.0:8000->8000/tcp, :::8000->8000/tcp, 0.0.0.0:9443->9443/tcp, :::9443->9443/tcp, 9000/tcp   portainer

У второго порт 9002 назван но в выводе присутствует и 9000, хотя в конфигурации его нет:

ad@devel04:/var/www/test_docker$ grep '^[^#]' example-2/docker-compose.yml
version: '2'
services:
    php:
        build: ./images/php
        volumes:
            - ./www:/var/www
            - "type=bind,source=/var/www/test_docker/example-2/www/,target=/var/www/"
        ports:
            - "9002:9002"

ad@devel04:/var/www/test_docker$ grep '^[^#]' example-2/images/php/Dockerfile
FROM php:7.1-fpm
RUN apt-get update && apt-get install -y \
        curl \
        wget \
        git \
        libfreetype6-dev \
        libjpeg62-turbo-dev \
        libmcrypt-dev \
    && docker-php-ext-install -j$(nproc) iconv mcrypt mbstring mysqli pdo_mysql zip \
    && docker-php-ext-configure gd --with-freetype-dir=/usr/include/ --with-jpeg-dir=/usr/include/ \
    && docker-php-ext-install -j$(nproc) gd
RUN curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
ADD php.ini /usr/local/etc/php/conf.d/40-custom.ini
WORKDIR /var/www
CMD ["php-fpm"]

Разницы между докер-файлами нет:

ad@devel04:/var/www/test_docker$ diff  example*/images/php/Dockerfile
ad@devel04:/var/www/test_docker$

Разница между docker-compose минимальна, добавлено монтирование и изменён порт:

ad@devel04:/var/www/test_docker$ diff example*/docker-compose.yml
11d10
<             - "type=bind,source=/var/www/test_docker/example-2/www/,target=/var/www/"
13c12
<             - "9002:9002"
---
>             - "9000:9000"
ad@devel04:/var/www/test_docker$ 

В nginx разница тоже минимальна:

ad@devel04:~$ diff /etc/nginx/sites-enabled/hello-*
7c7
<     server_name hello-2.dev;
---
>     server_name hello.dev;
9c9
<     root /var/www/hello-2.dev;
---
>     root /var/www/hello.dev;
15c15
<         fastcgi_pass 127.0.0.1:9002;
---
>         fastcgi_pass 127.0.0.1:9000;
ad@devel04:~$ 

nmap показывает на 127.0.0.1 порты 9000 и 9002 одинаково открытыми. Что я мог потерять?

пересоздавать контейнер при каждом редактировании кажется не очень эффективным

Я как раз на эту тему написал годный мануал неделю назад.

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

Достаточно просто пробросить каталог с сырцами в nginx как volume. Вот прям как есть: монтируешь каталог с пхп в www нджинкса. Там в мануале как раз подобное с Vue делается.

Про сборку контейнера с пхп и, правда, ларавелем, можно посмотреть вот тут.

Я не спец по PHP, но почему-то мне кажется, что в докерфайле ты что-то делаешь не совсем верно.

Достаточно просто пробросить каталог с сырцами в nginx как volume.

Вот тут я вру, наверное. Если там надо еще композером что-то собирать предварительно…

Используй laradock или что то подобное, у PHP есть php7.1-apache тег.

Ну сомнительно что тебе нужны будут старые версии, дело в том что по настоящему старых версий и в Docker нету, поэтому придется их собирать, а проще это сделать на своей системе.

Для установки множества различных версий Python и PHP можно использовать сторонние репозитории

Для Python: https://launchpad.net/~deadsnakes/ archive/ubuntu/ppa

Для PHP: https://launchpad.net/~ondrej/ archive/ubuntu/php

Где есть версии от php5.6 до php8.2

Мне странно что два контейнера по сути одинаковы но у второго нет ожидаемого поведения. И странно что при docker ps у второго упоминается 9000.

по настоящему старых версий и в Docker нету

Ну оно хранится в слоях, на самом деле. Пока не очистишь. Плюс никто не мешает вешать на каждую версию тег… Только непонятно, зачем.

Так ты же сам пишешь, что у второго контейнера изменен порт на 9000.

Не, 9000 у первого, у второго задано 9002 но после запуска в выводе docker ps присутствует 9000. Выше первый блок это как раз docker ps. Колонка ports:

9000/tcp, 0.0.0.0:9002->9002/tcp, :::9002->9002/tcp
0.0.0.0:9000->9000/tcp, :::9000->9000/tcp

Если у первого ты делаешь 9000:9000, а у второго ты ничего не менял, то надо сделать 9000:9002, а не 9002:9002

ERROR: for php  Cannot start service php: driver failed programming external connectivity on endpoint example2_php_1 (43d676f272f8fbca296ad74fd837703a5d499c0c19045c1447058abca6863353): Bind for 0.0.0.0:9000 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

Или первый надо остановить? Это два каталога в которых лежит похожая конфигурация. Таких может быть много.

Ну для начала попробуй прибить все лишние(а они все лишние, давай начнём с чистого листа) контейнеры. Потом уже будем дальше смотреть.

failed programming external connectivity on endpoint example2_php_1

Ты пытаешься повторно запустить первый вариант, в котором 9000:9000 прописано.

Остановил первый, пересоздал второй с 9002:9002 и с 9000:9002, в обоих случаях Bad Gateway.

пересоздал второй с 9002:9002 и с 9000:9002

одновременно?

Погоди. У меня два каталога с конфигурациями. В первом я делаю docker-compose up -d. Потом во втором делаю то же самое. Почему второй использует настройки первого?

Нет, после пробы я его останавливаю и делаю docker system prune чтобы шло с чистого листа.

Почему второй использует настройки первого?

Да не, это я наверное перепутал)

Вобщем делай docker-compose down в обоих каталогах. Потом точно посмотри что в первом прописано 9000:9000, а во втором 9000:9002 и запусти обратно.

Если не работает, то показывай docker-compose logs

Ну шо там у тебя творится-то, рассказывай.

Сделал 9002:9000, заработало. Насколько я понял, первое число это внешний порт а второе внутренний. Спасибо.

первое число это внешний порт а второе внутренний

Вроде да. Хотя я постоянно путаю :)