Comments 59
Веб сошелся клином на PHP, как я посмотрю.
Рискну предположить, что нет, но такое мнение очень не популярно.
Мэйнстрим в России. Не хватает популяризаторов других языков в вебе.
На примере с LAMP можно же и другие окружения собрать.
По статистике — да, все же именно PHP преобладает в Web. По сути вся нужная информация как это все подружить с Ruby или Python есть в документации к fig. Но как по мне эта штука довольно стремная. Мне как-то не по душе подобные подходы.
— nsenter с появления docker 1.3 бесполезная утилита — есть родной docker exec
— fig плохо масштабируем и интересен исключительно командой fig up (звучит по русски красиво)
— сама статья может быть написана в одну строчку — скачайте файлы моего проекта и запустите что то там чтобы увидеть непонятно что
— fig плохо масштабируем и интересен исключительно командой fig up (звучит по русски красиво)
— сама статья может быть написана в одну строчку — скачайте файлы моего проекта и запустите что то там чтобы увидеть непонятно что
- информацию о docker exec я учту, спасибо. я видел команду, но не разбирался в новых изюминках
- мне масштабировани fig-ом как-то вообще не к телу. мне важно было написать удобочитаемый конфиг для оркестрирования нескольких машин ибо в формате команды docker run как-то вообще нечитаемо
- относительно статьи в одну строку: я не считаю, что надо было приводить сам код и пояснения к нему если он доступен в репозитории и не кроет в себе никаких загадок
относительно 3, речь не об описании кода, я честно прочел статью, но так и не понял ни о чем она, ни какие проблемы решает.
Как минимум, это писалось для себя чтобы умпростить разворачивание приложений хотя бы для того, чтобы запустить. Не знаю как кого, но меня утруждает создавать где-то новый поддомен и выливать туда файлы или использовать подпапки для разных проектов. К тому же хотелось иметь все 4 версии PHP.
но для Вас опишу более подробно. инструмент позволяет в несколько действий (копирование папочки к проекту, редактирование двух конфигов, копирование дампа базы, запуск скрипта) развернуть приложение в отдельных контейнерах и зайти на свой проект через браузер по ссылочке. я ответил на Ваш вопрос?
и еще относительно 1: только что проверил репозитории Ubuntu — обновления для docker.io не наблюдаются и у меня у самого
Docker version 1.0.1, build 990021a
docker с каждой версией становится проще и обновляется чаще, чем убунта. поэтому есть смысл подключить их репозиторий docs.docker.com/installation/ubuntulinux/#docker-maintained-package-installation
Для оркестрирования 1+ виртуалки — советую посмотреть на тот же ansible.com (ничего кроме питона на целевой машине не надо, все делается через ssh по авторизации по ключу, windows тоже поддерживается, там большой набор функционала на борту), еще есть chef/puppet, но я их пока не крутил.
Я вчера за 3 команды и один конфиг поднял, обновил и поставил nginx/apache/php/pfp-pm на десяток виртуалок на lxc.
Я вчера за 3 команды и один конфиг поднял, обновил и поставил nginx/apache/php/pfp-pm на десяток виртуалок на lxc.
Хотя ansible и fig/docker решают похожие задачи, решают они их принципиально по-разному.
Ansible это универсальная штука, чтобы приводить состояние машинок в требуемое, для вашего приложения, путем дергания их внутренностей с помощью абстрактных правил по ssh. Docker собирает контейнеры «с нуля», упаковывая операционку вместе с приложением. Поэтому степень контроля тут в разы выше и есть возможности для различных оптимизаций. В целом, деплой через ansible занимает минуты, в то время как docker все делает за секунды.
Ansible это универсальная штука, чтобы приводить состояние машинок в требуемое, для вашего приложения, путем дергания их внутренностей с помощью абстрактных правил по ssh. Docker собирает контейнеры «с нуля», упаковывая операционку вместе с приложением. Поэтому степень контроля тут в разы выше и есть возможности для различных оптимизаций. В целом, деплой через ansible занимает минуты, в то время как docker все делает за секунды.
Подождите. я НЕ говорил о том, что ansible собирает докер образ.
Я говорил исключительно об оркестрации 1+n виртуалок этим п/о, чтобы не морочиться каждый раз, настраивая типовые сервисы.
Но идея использовать для этого Ansible не лишена здравого смысла — у меня сценарий — облачная виртуалка с ansible рулит настройками lxc контейнеров внутри неё. Никто не мешает заменить контейнер на всё, что может выполнять питон по ssh.
Я говорил исключительно об оркестрации 1+n виртуалок этим п/о, чтобы не морочиться каждый раз, настраивая типовые сервисы.
Но идея использовать для этого Ansible не лишена здравого смысла — у меня сценарий — облачная виртуалка с ansible рулит настройками lxc контейнеров внутри неё. Никто не мешает заменить контейнер на всё, что может выполнять питон по ssh.
А какие альтернативы Fig вы предложите?
docker exec работает, пока что, гораздо менее удобно чем docker-enter, который использует nsenter
приведите минимальный пример в чём docker exec менее удобен?
Да элементарно mc не запускается из-за отсутствия переменных окружения. А с docker-enter оно просто работает. Не могу сказать в чём именно дело, даже не вникал, пока использую docker-enter, так как работает нормально со всеми приложениями изначально.
добавьте себе в .bash_aliases
denter() {
CONTAINER=$1
shift 1
docker exec -it "$CONTAINER" su — ice -c 'script -q /dev/null'
}
и пользуйтесь наздоровье из командной строки
denter имяконтейнера
и переменные будут и заодно tty нормально работать — можно tmux запустить
только имя пользователя ice смените на root или что там у вас в контейнерах прописано
denter() {
CONTAINER=$1
shift 1
docker exec -it "$CONTAINER" su — ice -c 'script -q /dev/null'
}
и пользуйтесь наздоровье из командной строки
denter имяконтейнера
и переменные будут и заодно tty нормально работать — можно tmux запустить
только имя пользователя ice смените на root или что там у вас в контейнерах прописано
Для убунту свежая версия докера называется lxc-docker и ее устанка описана на оф. сайте
На будущее: если цель иметь различные версии php/python/ruby и их библиотек,
нет смысла собирать отдельные контейнеры — достаточно phpbrew/rvm/virtualenv.
нет смысла собирать отдельные контейнеры — достаточно phpbrew/rvm/virtualenv.
на самом деле нет, контейнеры решают эти задачи для любого софта, написали в Dockerfile что хотите ubuntu, подключили пару репозиториев и поставили нужные пакеты, и в идеале тоже самое у вас в продакшене — значит шанс что вы словите какие то ошибки от использования разных окружений при разработки и в продашкене меньше
Прекрасно знаю что такое контейнеры и пользуюсь ими.
Мой комментарий относится к:
То есть, если цель только иметь различные версии, то отдельные контейнеры для этого избыточны.
Мой комментарий относится к:
К тому же хотелось иметь все 4 версии PHP
То есть, если цель только иметь различные версии, то отдельные контейнеры для этого избыточны.
я к тому что вам тогда надо будет и в продакшене использовать phpbrew/rvm/virtualenv, что скорее всего не так
в результате у вас получится что вы тестируете в одном окружении, а запускаете в другом (прич).
ну и второе — в проектах же скорее всего не только php используется, как минимум еще нужна база, может быть что-то еще для чего нет возможности ставить разные версии одного софта
ЗЫ поправьте если не прав — phpbrew нужно запускать команды чтобы переключить версию php?
в результате у вас получится что вы тестируете в одном окружении, а запускаете в другом (прич).
ну и второе — в проектах же скорее всего не только php используется, как минимум еще нужна база, может быть что-то еще для чего нет возможности ставить разные версии одного софта
ЗЫ поправьте если не прав — phpbrew нужно запускать команды чтобы переключить версию php?
ну и второе — в проектах же скорее всего не только php используется, как минимум еще нужна база, может быть что-то еще для чего нет возможности ставить разные версии одного софтаЕсли надо, то разные контейнеры.
В статье написано, что контейнеры отличаются только версией PHP.
в результате у вас получится что вы тестируете в одном окружении, а запускаете в другомНе совсем так.
Все окружение будет идентичным, за исключением что сам транслятор и его либы будут лежать в другой директории, которая автоматически прописываться в $PATH.
И еще раз повторюсь: я не утверждаю что этот способ единственный верный и подойдет в 100% случаев (хотя за несколько лет фейлов не было).
Я всего лишь предложил более «дешевую» альтернативу для локальной разработки, не более.
Если контейнер предполагается для последущей репликации, то тут уж на ваш выбор.
Сори, сразу провтыкал.
— ручное переключение (командой)
— назначение нужной версии дефолтной
— rc-файл (при открытии директории автоматически установится указанная в файле версия)
ЗЫ поправьте если не прав — phpbrew нужно запускать команды чтобы переключить версию php?Есть несколько вариантов:
— ручное переключение (командой)
— назначение нужной версии дефолтной
— rc-файл (при открытии директории автоматически установится указанная в файле версия)
а каким образом с помощью phpbrew сожно указать веб-серверу какую версию php нужно использовать для конкретного виртуального хоста?
Никаким: phpbrew рулит PHP, не более.
Какую версию использовать для хоста задается в настройках web-сервера.
Какую версию использовать для хоста задается в настройках web-сервера.
для хоста или виртуального хоста?
Коль речь про web-сервер, очевидно что виртуального.
Вы понимаете, что когда речь идет о веб-сервере, то имеет место быть и хост и виртуальный хост? именно в контексте веб-сервера?
подскажите пожалуйста как указать версию PHP для виртуального хоста?
подскажите пожалуйста как указать версию PHP для виртуального хоста?
Не занимайтесь словоблудием: вы спросили «какую версию php нужно использовать для конкретного виртуального хоста», очевидно же что ответ был про виртуальный.
linuxplayer.org/2011/05/intall-multiple-version-of-php-on-one-server
На самом деле работы на несколько минут.
подскажите пожалуйста как указать версию PHP для виртуального хоста?marcelog.github.io/articles/configure_nginx_php_5.3_5.2_fastcgi.html
linuxplayer.org/2011/05/intall-multiple-version-of-php-on-one-server
На самом деле работы на несколько минут.
мне кажется мы друг друга не поняли
я так понимаю, что Вы имели в виду не phpbrew, верно?
о том, что методами, описанными по ссылочкам, можно указать для веб-сервера несколько версий php я знаю
спасибо
>> Какую версию использовать для хоста задается в настройках web-сервера.
я так понимаю, что Вы имели в виду не phpbrew, верно?
о том, что методами, описанными по ссылочкам, можно указать для веб-сервера несколько версий php я знаю
спасибо
я так понимаю, что Вы имели в виду не phpbrew, верно?Или я не понимаю вашего вопроса, или вы не понимаете моего ответа )
Eдинственная задача phpbrew — упрощение установки различных версий php так, чтоб они не мешали друг другу (имели независимые конфиги/наборы рассширений/etc).
Допустим вы установили PHP 5.5 и 5.6, получаете:
/opt/phpbrew/php/php-5.5
/opt/phpbrew/php/php-5.6
Окрываете /opt/phpbrew/php/php-5.6/etc/php-fpm.conf и меняете listen = 127.0.0.1:9000 на listen = 127.0.0.1:9001
В итоге PHP 5.5 слушает дефолтный 127.0.0.1:9000, а 5.6 слушает 127.0.0.1:9001.
Открываете конфиг nginx и в нужном вхосте указываете нужный адрес. Вот и вся магия.
Если вопрос был можно ли это сделать средствами phpbrew, то я ответил еще в самом начале.
спасибо за подробности. все встало на места
надо руками пощупать в паре с nginx
сейчас мне нужна вариация консольных версий php и меня вчера очень удивил тот факт, что в зависимостях php5 был и apache и mysql сервера, но я думаю, что можно использовать не php5 за основу, а php5-cli и будет phpbrew все равно будет разруливать версии
надо руками пощупать в паре с nginx
сейчас мне нужна вариация консольных версий php и меня вчера очень удивил тот факт, что в зависимостях php5 был и apache и mysql сервера, но я думаю, что можно использовать не php5 за основу, а php5-cli и будет phpbrew все равно будет разруливать версии
спасибо за подробности. все встало на местаНа здоровье.
меня вчера очень удивил тот факт, что в зависимостях php5 был и apache и mysql сервераЕсли у вас потребность исключительно в cli, то и ставить надо php5-cli вместо дефолтного пакета php.
В консоли с phpbrew все просто:
phpbrew use php-5.4.33 # switch version temporarily
phpbrew switch php-5.6.4 # switch default php version
phpbrew ext install mcrypt
phpbrew ext disable xcache
Будут вопросы, обращайтесь.
Почему в экосистеме Docker повально используются образы на Ubuntu? Разве это не губит всю затею?
Мне представляется, что преимущество Docker раскрывается при использовании в контейнерах минималистичной CoreOS: в каждый контейнер устанавливаются те и только те средства, которые требуются для работы контейнеризуемого сервиса. И не нужно в каждом контейнере крутить армию бесполезных демонов.
Мне представляется, что преимущество Docker раскрывается при использовании в контейнерах минималистичной CoreOS: в каждый контейнер устанавливаются те и только те средства, которые требуются для работы контейнеризуемого сервиса. И не нужно в каждом контейнере крутить армию бесполезных демонов.
вы бы хоть попробовали прежде чем говорить — вот прям сейчас смотрю в список процессов и кроме dbus только то что описано для запуска в Dockerfile
нет, не губит. CoreOS используется (если есть сильное желание испол-зовать именно CoreOS) не внутри контейнера, но на хоствовой машине. Демоны запускаются только те, которые вы велели запустить и никакой «армии бесполезных демонов» там само по себе не зародится.
А почему не использовать datavolumes вместо дампов?
я считаю, что это было бы излишеством ибо тогда нужно было бы хранить всю папку для БД в своей директории при отключении окружения. да, это решило бы вопрос с разворачиванием дампов, но это породило бы дерево новых папок, которые не нужны. я осознанно отказался от предложеной Вами идеи в пользу дампов только из-за чистоты
Я так понимаю, можно просто создать Data Volume Container, и использовать его в качестве хранилища. Получается, что тогда он будет лежать вместе с другими контейнерами, а не в текущей папке.
есть несколько вариантов:
- можно для каждого указывать локальную директорию хранения (-v) — например, нужно хост-директорию (хост-файл) пробросить в контейнер или же сохранить данные между запусками контейнера (для примера, можно вынести папку для хранения БД в файловую систему хоста и тогда базы будут сохраняться между запускати контейнера для баз данных),
- можно завести какой-то контейнер и в него пробрасывать папочки (--volumes-from) — например, если данные нужно расшарить между несколькими работающими одновременно контейнерами
Интересно, но как то замороченно у вас получилось.
Вот пилил нечто похожее на Ubuntu 14.04 для своих целей.
Вкратце — в контейнере стандартный LAMP, проекты на хостовой машине лежат в директориях с определенной структурой и после старта контейнера все стартуется bash-скриптом который создает в mysql пользователя, разворачивает дамп бд, подключает кастомный php.ini и стартует сервисы. С dnsmasq решил не заморачиваться т.к. проще прокинуть 80 порт на хост-машину и один раз прописать в /etc/hosts соответствие.
Тут описал поподробнее.
Вот пилил нечто похожее на Ubuntu 14.04 для своих целей.
Вкратце — в контейнере стандартный LAMP, проекты на хостовой машине лежат в директориях с определенной структурой и после старта контейнера все стартуется bash-скриптом который создает в mysql пользователя, разворачивает дамп бд, подключает кастомный php.ini и стартует сервисы. С dnsmasq решил не заморачиваться т.к. проще прокинуть 80 порт на хост-машину и один раз прописать в /etc/hosts соответствие.
Тут описал поподробнее.
о, так с Вашей статьи в блоге все и началось. изначально у меня приблизительно так оно и было.
у меня был LAMP-образ, в проекте была дополнительная папка .docker с определенной струкрутой, был файл, который инициализировал запуск контейнера, прокидывал туда папки и конфиг для веб-сервера и прописывал в DNSMasq; и был файл, который запускался уже в контейнере и он уже создавал пользователя, БД на mysql-сервера хост-машины. все работало, все было круто, но для меня оно все равно было неким нагромождением допиленного неструктурированного кода, который нужно было когда-то переписать. потом я познакомился с Fig, разобался с линкованием, случайно удалил свои репозитории и пришлось «рукам дойти» для переписывания этого всего добра.
не использование DNSMasq хорошо когда у Вас один проект и вы его можете спело повесить на http://localhost:80/, но если их несколько (можно вести несколько проектов; можно вести один и параллельно пилить что-то для себя; можно вести один проект, вести что-то для себя и изучать параллельно что-то третье новое для себя), то да, можно раскидать на несколько портов на интерфейсе хост-машины и не париться, но нужно будет запоминать порты — это уже не гуд, осмысленные доменные имена намного лучше, чем номера портов.
на самом деле действий для развоначивания проекта в моем варианте не намного больше и их нужно произвести единожды для проекта — дальше его просто нужно запустить и остановить. при этом не нужно выходить за рамки папки с проектом
у меня был LAMP-образ, в проекте была дополнительная папка .docker с определенной струкрутой, был файл, который инициализировал запуск контейнера, прокидывал туда папки и конфиг для веб-сервера и прописывал в DNSMasq; и был файл, который запускался уже в контейнере и он уже создавал пользователя, БД на mysql-сервера хост-машины. все работало, все было круто, но для меня оно все равно было неким нагромождением допиленного неструктурированного кода, который нужно было когда-то переписать. потом я познакомился с Fig, разобался с линкованием, случайно удалил свои репозитории и пришлось «рукам дойти» для переписывания этого всего добра.
не использование DNSMasq хорошо когда у Вас один проект и вы его можете спело повесить на http://localhost:80/, но если их несколько (можно вести несколько проектов; можно вести один и параллельно пилить что-то для себя; можно вести один проект, вести что-то для себя и изучать параллельно что-то третье новое для себя), то да, можно раскидать на несколько портов на интерфейсе хост-машины и не париться, но нужно будет запоминать порты — это уже не гуд, осмысленные доменные имена намного лучше, чем номера портов.
на самом деле действий для развоначивания проекта в моем варианте не намного больше и их нужно произвести единожды для проекта — дальше его просто нужно запустить и остановить. при этом не нужно выходить за рамки папки с проектом
хех, я и забыл. Прошу прощения за повторение.
Я просто обычно да, с одним проектом в один момент времени работаю. Кстати, конфиг файлы для апача также хранить в директории с проектом и их подключать при старте. Тогда станет возможной работа нескольких хостов в одном docker-контейнере.
Я просто обычно да, с одним проектом в один момент времени работаю. Кстати, конфиг файлы для апача также хранить в директории с проектом и их подключать при старте. Тогда станет возможной работа нескольких хостов в одном docker-контейнере.
А так разве можно?
В смысле, это не рекомендуется обычно. Вообще ок такое проворачивать?
В смысле, это не рекомендуется обычно. Вообще ок такое проворачивать?
Ну вообще то это мое локальное dev-окружение и я волен настраивать все это так как мне это удобно. Поднимать 2 и более контейнеров с одинаковым окружением просто для того чтобы одновременно поднять несколько хостов и разруливать их на разных портах мне кажется намного более не ок чем поднимать несколько хостов на одном контейнере.
смешались в кучу люди кони…
я считаю, что поднимать 1+ контейнеров для нескольких проектов будет корректнее в плане независимости отдного проекта от другого
представим ситуацию: вы запускаете два проекта в одном контейнере. так думаю, что эти проекты у Вас должны быть доступными на отдельных виртуальных хостах. верно же? а как к ним иметь доступ? либо прописывать в /etc/hosts либо в локальный DNS. это реализуемо, но я думаю, что не стоит делать зва проекта зависимыми один от другого: вы хостите добавить проект — вы отключаете контейнер, правите конфиг, добавляете проект, запускаете контейнер. с отключением проекта аналогичная обратная ситуация.
это будет ограничивать Вас в действиях (для того, чтобы налету добавлять проекты Вам нужно будет монтировать папку с проектами в контейнер дабы просто добавить новый проект в папку либ отключать-включать контейнер; руками заливать/очищать бамп БД). почему бы это не автоматизировать и не создавать для каждого проекта свою независимую от других набор контейнеров для разработки. а может, для некоторых проектов нужно будет больше, чем LAMP? нужно memcached добавить (я, кстати, хочу убрать вынести его со своих контейнеров и линковать официальный если это будет нужно), или там PostgreSQL, или Redis. Или просто нужно запустить посмотреть на какой-то проект, то зачем быть зависимым от других уже запущенных проектов в том же контейнере
я считаю, что лучше разделять на отдельные контейнеры — они не так много ресурсов потребляют
я считаю, что поднимать 1+ контейнеров для нескольких проектов будет корректнее в плане независимости отдного проекта от другого
представим ситуацию: вы запускаете два проекта в одном контейнере. так думаю, что эти проекты у Вас должны быть доступными на отдельных виртуальных хостах. верно же? а как к ним иметь доступ? либо прописывать в /etc/hosts либо в локальный DNS. это реализуемо, но я думаю, что не стоит делать зва проекта зависимыми один от другого: вы хостите добавить проект — вы отключаете контейнер, правите конфиг, добавляете проект, запускаете контейнер. с отключением проекта аналогичная обратная ситуация.
это будет ограничивать Вас в действиях (для того, чтобы налету добавлять проекты Вам нужно будет монтировать папку с проектами в контейнер дабы просто добавить новый проект в папку либ отключать-включать контейнер; руками заливать/очищать бамп БД). почему бы это не автоматизировать и не создавать для каждого проекта свою независимую от других набор контейнеров для разработки. а может, для некоторых проектов нужно будет больше, чем LAMP? нужно memcached добавить (я, кстати, хочу убрать вынести его со своих контейнеров и линковать официальный если это будет нужно), или там PostgreSQL, или Redis. Или просто нужно запустить посмотреть на какой-то проект, то зачем быть зависимым от других уже запущенных проектов в том же контейнере
я считаю, что лучше разделять на отдельные контейнеры — они не так много ресурсов потребляют
как деплоить свой код в такую систему? после каждой правки в IDE запускать scp или ftp?
docs.docker.com/userguide/dockervolumes/
При запуске (docker run) вставить вот такой флаг: -v /путь/на/хосте:/путь/в/контейнере
Так же можно делать и в fig
При запуске (docker run) вставить вот такой флаг: -v /путь/на/хосте:/путь/в/контейнере
Так же можно делать и в fig
оно само даплоится через проброс локальной папки в контейнер (в моем случае папка с проектом будет доступна в контейнере в директории /var/www)
Я просто оставлю это здесь.
Ссылки на то, где можно сделать все проще
Demo потыкать: deploy4me.com/en/demo/index.html
Видео посмотреть: youtu.be/hqiKfu4ux_4
Блох на Хабре: habrahabr.ru/company/d4m/
Видео посмотреть: youtu.be/hqiKfu4ux_4
Блох на Хабре: habrahabr.ru/company/d4m/
минусы:
Платно: deploy4me.com/en/pricing.html
Разворачивается облаке, что несколько затрудняет оффлайн разработку
Платно: deploy4me.com/en/pricing.html
Разворачивается облаке, что несколько затрудняет оффлайн разработку
Для разработки в облаках есть куча различных вариантов.
Те же Heroku и Openshift для деплоя или Cloud9 где IDE с веб-сервером в одном флаконе.
Но в посте речь как раз идет об оффлайн разработке. Так в первом случае коммитить код на каждый чих очень утомительно и нерационально, а во втором случае не всем (пока) подойдут онлайн-IDE для повседневной работы.
Те же Heroku и Openshift для деплоя или Cloud9 где IDE с веб-сервером в одном флаконе.
Но в посте речь как раз идет об оффлайн разработке. Так в первом случае коммитить код на каждый чих очень утомительно и нерационально, а во втором случае не всем (пока) подойдут онлайн-IDE для повседневной работы.
убираются записи из конфига DNSMasq и перезапускается демон
Перезапускать не требуется, достаточно HUP-нуть.
Sign up to leave a comment.
Создание окружения для веб-разработки на основе Docker