Создание окружения для веб-разработки на основе Docker

    Под катом расскажу как я усовершенствовал автоматическое создание и разворачивание окружения для веб-разработки на основе Docker, Fig, DNSMasq и nsenter. По сути, это разворачивание LAMP сервера и запись о нем в DNSMasq, но приоритетами являются незасоренность хост-машины ненужным софтом типа web-, db-серверов на хост машине и минимальное количество команд для запуска

    Предисловие


    В предыдущей статье http://habrahabr.ru/post/236573/ я рассказывал как организовать быстрое разворачивание окружения для веб-разработки на основе VirtualBox, тогда же, более опытные хабрапользователи посоветовали мне посмотреть в сторону Docker. После этого я открыл ман и начал экспериментировать, собрав для себя три контейнера с разными версиями PHP (5.3, 5.4 и 5.5), которыми успешно и удобно пользовался. Было желание в будущем переписать bootstrap-скрипт на более вменяемом языке и как-то все это организовать да написать ман. Но, как всегда, руки к этому не доходили и, скорее всего, никогда бы не дошли если бы на кануне Рождества я случайно не удалил бы домашнюю директорию docker-а. Да, бывает. В итоге все было переписано, переорганизовано и выложено на GitHub.

    Что нам потребуется?


    1. Docker.IO (https://www.docker.com/)
    2. fig (http://www.fig.sh)
    3. DNSMasq (http://www.thekelleys.org.uk/dnsmasq/doc.html)
    4. nsenter (https://github.com/jpetazzo/nsenter)


    Что происходит?


    При запуске через скрипт с помощью fig разворачиваются и линкуются все нужные контейнеры. После этого, если указан файл с дампом базы, дамп заливается в созданную БД в контейнере. Далее добавляются записи о контейнерах в конфиг DNSMasq и перезапускается демон.
    При выключении с помощью скрипта база данных обратно дампится в файл, убираются записи из конфига DNSMasq и перезапускается демон.

    Как это настроить?


    Требуется минимальная настройка DNSMasq:
    # cat /etc/dnsmasq.conf | grep -E -v '^(#.*)?$'
    listen-address=127.0.0.1
    

    Для работы всего этого добра клонируем репозиторий https://github.com/dvapelnik/efig и ищем там папочку .efig, которую кладем в папку с проектом. В этой папке уже есть:
    1. logs — директория для логов веб-сервера
    2. xd_profile, xd_trace — две директории для файлов XDebug
    3. db — директория для работы с базами данных с двумя скриптами для деплоя и бекапа
    4. efig.yml — конфиг для fig
    5. efig.conf — конфиг самого efig
    6. httpd.conf — конфиг apache2
    7. efig.sh — сам скрипт efig для работы

    В efig.yml нужно указать название базы данных, имя пользователя для базы данных и пароль. Если нужно, то и базу данных для тестов. Для того, база данных корректно разворачивалась и дампилась обратно следует указать как связаны названия баз данных с файлами с дампами.
    E_DB_DUMP имя файла для основной базы данных
    E_DB_NAME имя основной базы данных
    E_DB_TEST_DUMP имя файла тестовой базы данных
    E_DB_TEST_NAME имя тестовой базы данных

    Если тестовая база данных не нужна, то две последние строки можем комментировать и убрать имя тестовой базы данных из переменной DB_NAME. Файлы с дампами будут искаться относительно папки db.
    httpd.conf конфигурируем для своего приложения.
    В efig.conf указываются следующие значения
    PROJECT_NAME название проекта (будет использовано в URL)
    FIG_CONF имя конфига для fig
    SUBDOMAINS_ENABLED нужно ли создавать поддомены для каждого контейнера
    DNS_ZONE DNS зона для проектов, изначально используется .doc
    MAIN_CONTAINER_NAME имя главного контейнера, изначально web (берем с fig-конфига)
    DB_CONTAINER_NAME имя контейнера ДБ, изначально db (берем с fig-конфига)
    DNSMASQ_CONFIG_PATH путь к конфигу DNSMasq

    Дополнение к SUBDOMAINS_ENABLED
    Например, чтобы к контейнеру БД можно было обращаться по доменному имени (например, http://db.myproject.doc/, а не по IP, который постоянно будет изменять при каждом запуске).


    А теперь со всеми этими конфигами, папками и скриптами мы попробуем взлететь попробуем запустить


    Для того, чтобы взлететь, нужно перейти в папку .efig и запустить скрипт через sudo:
    sudo ./efig.sh
    

    В это время запускаются контейнеры, разворачиваются БД, дописываются в /etc/dnsmasq.conf записи о новых контейнерах и перезапускается демон. После этого можем смело заходить по ссылочке в браузере http://project.doc/ и наблюдать свой проект уже в браузере.
    Для того, чтобы отключить-удалить контейнеры и обратно забекапить базы пишем, находять в той же папке (.efig), следующее:
    sudo ./efig.sh rm
    

    Базы сдампятся обратно в файлы, контейнеры остановятся и удалятся — все чисто, как и задумывалось.

    Какие образы необходимо использовать для контейнеров?


    В качестве веб-контейнеров советую использовать образы, которые однообразно конфигурировались (на DockerHub доступны образы, основанные на Debian/Ubuntu с раными версиями PHP (5.3, 5.4, 5.5, 5.6)). Пакеты для PHP подбирались с учетом требованый YiiFramework (1, 2), При необходимости можно добавить и другие, необходимые для разработки, пакеты. В качетсве db-контейнеров я использую образ от sameersbn.

    А попрактиковаться?


    Можете попробовать развернуть, к примеру, ту же Joomla CMS (она первой пришла мне в голову как CMS, которую легко развернуть и она сама сгенерирует БД):
    1. Клонируем репоз efig с гитхаба
    2. Тянем архив Joomla CMS
    3. Распаковываем
    4. Копируем .efig в папку с Joomla CMS
    5. Указываем в .efig/efig.yml параметры для БД
    6. Запускаем это дело cd .efig/ && sudo bash ./efig.sh
    7. Радуемся жизни Смотрим/устанавливаем
    8. Останавливаем-удаляем cd .efig/ && sudo bash ./efig.sh rm


    Прошлое, настоящее и будущее?


    Как минимум, это писалось для себя чтобы умпростить разворачивание приложений хотя бы для того, чтобы запустить. Не знаю как кого, но меня утруждает создавать где-то новый поддомен и выливать туда файлы или использовать подпапки для разных проектов. К тому же хотелось иметь все 4 версии PHP. По мере запросов и своих потребностей я буду допиливать то, что уже есть. Планирую прикрутить поддержку PostgreSQL, но поскольку сам его пока не использую, то и не прикручивал. Скрипт обкатывался на Ubuntu OS, но я не думаю, что на других Linux-дистрибутивах должны возникнуть проблемы. Проверить на других дистрибутивах возможности не было.

    Ссылки?


    1. Репозиторий проекта на GitHub: https://github.com/dvapelnik/efig
    2. Репозиторий образов для Docker на GitHub: https://github.com/dvapelnik/docker-lap
    3. Репозиторий образов для Docker на DockerHub: https://registry.hub.docker.com/u/dvapelnik/docker-lap/


    Подводные камни?


    1. Если дампа базы нет и база генерируется сама (миграции, разворачивание как у Joomla CSM, прочее), то при отключении контейнеров база сдампится, но сдампится она под пользователем root. Это вызвано тем, что в контейнереми дампим фактически под рутов контейнера. Можно перед запуском создать пустой файл, в который будет сдамплена БД при выключении — вот такой workaroud. Аналогичная ситуация с веб-контейнерами. Если монтировать в контейнер папку, то все файлы, которые будут создаваться из контейнера, будут созданы рутом. Описываю workaround, который использовал я: в контейнере создается пользователь donkey с таким UID и GID, как у моего пользователя, под которым я буду вести разработку. Он у меня равен 1000. Если UID і GID вашего пользователя отличается от 1000, то нужно взять соответствующий Dockerfile и заменить там UID и GID этого пользователя и пересобрать образ. Для э образов баз данных это не особо критично, но при дампе это вылезает боком. Потому такой костыль.
    2. Возникает резонный вопрос: как добраться до базы данных внутри контейнера? Логично и именно для этого я сделал опцию для создания доменных имен всем контейнерам SUBDOMAINS_ENABLED. Если флаг установлен 1, то для всех контейнеров будет создано по записи в конфиге DNSMasq в виде CONTAINER_NAME.PROJECT_NAME.DNS_ZONE. Контейнер выплевывает наружу порт для доступа к базам и к ним можно добраться, используя этот домен, порт и данные о пользователе, которые были прописаны в efig.conf
    Метки:
    Поделиться публикацией
    Комментарии 59
    • –3
      Веб сошелся клином на PHP, как я посмотрю.
      • 0
        Рискну предположить, что нет, но такое мнение очень не популярно.
        • 0
          Мэйнстрим в России. Не хватает популяризаторов других языков в вебе.
          • +4
            На примере с LAMP можно же и другие окружения собрать.
            • +1
              По статистике — да, все же именно PHP преобладает в Web. По сути вся нужная информация как это все подружить с Ruby или Python есть в документации к fig. Но как по мне эта штука довольно стремная. Мне как-то не по душе подобные подходы.
            • +10
              — nsenter с появления docker 1.3 бесполезная утилита — есть родной docker exec
              — fig плохо масштабируем и интересен исключительно командой fig up (звучит по русски красиво)
              — сама статья может быть написана в одну строчку — скачайте файлы моего проекта и запустите что то там чтобы увидеть непонятно что
              • 0
                1. информацию о docker exec я учту, спасибо. я видел команду, но не разбирался в новых изюминках
                2. мне масштабировани fig-ом как-то вообще не к телу. мне важно было написать удобочитаемый конфиг для оркестрирования нескольких машин ибо в формате команды docker run как-то вообще нечитаемо
                3. относительно статьи в одну строку: я не считаю, что надо было приводить сам код и пояснения к нему если он доступен в репозитории и не кроет в себе никаких загадок
                • +3
                  относительно 3, речь не об описании кода, я честно прочел статью, но так и не понял ни о чем она, ни какие проблемы решает.
                  • +1
                    Как минимум, это писалось для себя чтобы умпростить разворачивание приложений хотя бы для того, чтобы запустить. Не знаю как кого, но меня утруждает создавать где-то новый поддомен и выливать туда файлы или использовать подпапки для разных проектов. К тому же хотелось иметь все 4 версии PHP.

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

                    и еще относительно 1: только что проверил репозитории Ubuntu — обновления для docker.io не наблюдаются и у меня у самого Docker version 1.0.1, build 990021a
                • +1
                  Для оркестрирования 1+ виртуалки — советую посмотреть на тот же ansible.com (ничего кроме питона на целевой машине не надо, все делается через ssh по авторизации по ключу, windows тоже поддерживается, там большой набор функционала на борту), еще есть chef/puppet, но я их пока не крутил.
                  Я вчера за 3 команды и один конфиг поднял, обновил и поставил nginx/apache/php/pfp-pm на десяток виртуалок на lxc.
                  • 0
                    Хотя ansible и fig/docker решают похожие задачи, решают они их принципиально по-разному.
                    Ansible это универсальная штука, чтобы приводить состояние машинок в требуемое, для вашего приложения, путем дергания их внутренностей с помощью абстрактных правил по ssh. Docker собирает контейнеры «с нуля», упаковывая операционку вместе с приложением. Поэтому степень контроля тут в разы выше и есть возможности для различных оптимизаций. В целом, деплой через ansible занимает минуты, в то время как docker все делает за секунды.
                    • 0
                      Подождите. я НЕ говорил о том, что ansible собирает докер образ.
                      Я говорил исключительно об оркестрации 1+n виртуалок этим п/о, чтобы не морочиться каждый раз, настраивая типовые сервисы.
                      Но идея использовать для этого Ansible не лишена здравого смысла — у меня сценарий — облачная виртуалка с ansible рулит настройками lxc контейнеров внутри неё. Никто не мешает заменить контейнер на всё, что может выполнять питон по ssh.
                • 0
                  А какие альтернативы Fig вы предложите?
                • 0
                  docker exec работает, пока что, гораздо менее удобно чем docker-enter, который использует nsenter
                  • 0
                    приведите минимальный пример в чём docker exec менее удобен?
                    • 0
                      Да элементарно mc не запускается из-за отсутствия переменных окружения. А с docker-enter оно просто работает. Не могу сказать в чём именно дело, даже не вникал, пока использую docker-enter, так как работает нормально со всеми приложениями изначально.
                      • 0
                        добавьте себе в .bash_aliases

                        denter() {
                        CONTAINER=$1
                        shift 1
                        docker exec -it "$CONTAINER" su — ice -c 'script -q /dev/null'
                        }

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

                        denter имяконтейнера

                        и переменные будут и заодно tty нормально работать — можно tmux запустить
                        только имя пользователя ice смените на root или что там у вас в контейнерах прописано
                        • 0
                          А я и не сомневался, что это можно решить)
                          Просто оно у меня и так работает, разве что автодополнения названия контейнера в docker-enter нет по Tab, вот это единственный минус, который и вашему решению будет тоже присущ.
                • +2
                  Для убунту свежая версия докера называется lxc-docker и ее устанка описана на оф. сайте
                  • –1
                    На будущее: если цель иметь различные версии php/python/ruby и их библиотек,
                    нет смысла собирать отдельные контейнеры — достаточно phpbrew/rvm/virtualenv.
                    • 0
                      на самом деле нет, контейнеры решают эти задачи для любого софта, написали в Dockerfile что хотите ubuntu, подключили пару репозиториев и поставили нужные пакеты, и в идеале тоже самое у вас в продакшене — значит шанс что вы словите какие то ошибки от использования разных окружений при разработки и в продашкене меньше
                      • +1
                        Прекрасно знаю что такое контейнеры и пользуюсь ими.
                        Мой комментарий относится к:
                        К тому же хотелось иметь все 4 версии PHP


                        То есть, если цель только иметь различные версии, то отдельные контейнеры для этого избыточны.
                        • 0
                          я к тому что вам тогда надо будет и в продакшене использовать phpbrew/rvm/virtualenv, что скорее всего не так
                          в результате у вас получится что вы тестируете в одном окружении, а запускаете в другом (прич).
                          ну и второе — в проектах же скорее всего не только php используется, как минимум еще нужна база, может быть что-то еще для чего нет возможности ставить разные версии одного софта
                          ЗЫ поправьте если не прав — phpbrew нужно запускать команды чтобы переключить версию php?

                          • 0
                            ну и второе — в проектах же скорее всего не только php используется, как минимум еще нужна база, может быть что-то еще для чего нет возможности ставить разные версии одного софта
                            Если надо, то разные контейнеры.
                            В статье написано, что контейнеры отличаются только версией PHP.

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

                            И еще раз повторюсь: я не утверждаю что этот способ единственный верный и подойдет в 100% случаев (хотя за несколько лет фейлов не было).
                            Я всего лишь предложил более «дешевую» альтернативу для локальной разработки, не более.
                            Если контейнер предполагается для последущей репликации, то тут уж на ваш выбор.
                            • 0
                              Сори, сразу провтыкал.
                              ЗЫ поправьте если не прав — phpbrew нужно запускать команды чтобы переключить версию php?
                              Есть несколько вариантов:
                              — ручное переключение (командой)
                              — назначение нужной версии дефолтной
                              — rc-файл (при открытии директории автоматически установится указанная в файле версия)
                              • 0
                                а каким образом с помощью phpbrew сожно указать веб-серверу какую версию php нужно использовать для конкретного виртуального хоста?
                                • 0
                                  Никаким: phpbrew рулит PHP, не более.
                                  Какую версию использовать для хоста задается в настройках web-сервера.
                                  • 0
                                    для хоста или виртуального хоста?
                                    • 0
                                      Коль речь про web-сервер, очевидно что виртуального.
                                      • 0
                                        Вы понимаете, что когда речь идет о веб-сервере, то имеет место быть и хост и виртуальный хост? именно в контексте веб-сервера?
                                        подскажите пожалуйста как указать версию PHP для виртуального хоста?
                                        • 0
                                          Не занимайтесь словоблудием: вы спросили «какую версию php нужно использовать для конкретного виртуального хоста», очевидно же что ответ был про виртуальный.

                                          подскажите пожалуйста как указать версию 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

                                          На самом деле работы на несколько минут.
                                          • 0
                                            мне кажется мы друг друга не поняли
                                            >> Какую версию использовать для хоста задается в настройках web-сервера.

                                            я так понимаю, что Вы имели в виду не phpbrew, верно?
                                            о том, что методами, описанными по ссылочкам, можно указать для веб-сервера несколько версий php я знаю
                                            спасибо
                                            • 0
                                              я так понимаю, что Вы имели в виду не 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, то я ответил еще в самом начале.
                                              • 0
                                                спасибо за подробности. все встало на места
                                                надо руками пощупать в паре с nginx
                                                сейчас мне нужна вариация консольных версий php и меня вчера очень удивил тот факт, что в зависимостях php5 был и apache и mysql сервера, но я думаю, что можно использовать не php5 за основу, а php5-cli и будет phpbrew все равно будет разруливать версии
                                                • 0
                                                  спасибо за подробности. все встало на места
                                                  На здоровье.

                                                  меня вчера очень удивил тот факт, что в зависимостях 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  
                                                  


                                                  Будут вопросы, обращайтесь.
                        • –1
                          Почему в экосистеме Docker повально используются образы на Ubuntu? Разве это не губит всю затею?

                          Мне представляется, что преимущество Docker раскрывается при использовании в контейнерах минималистичной CoreOS: в каждый контейнер устанавливаются те и только те средства, которые требуются для работы контейнеризуемого сервиса. И не нужно в каждом контейнере крутить армию бесполезных демонов.
                          • 0
                            вы бы хоть попробовали прежде чем говорить — вот прям сейчас смотрю в список процессов и кроме dbus только то что описано для запуска в Dockerfile
                            • +5
                              нет, не губит. CoreOS используется (если есть сильное желание испол-зовать именно CoreOS) не внутри контейнера, но на хоствовой машине. Демоны запускаются только те, которые вы велели запустить и никакой «армии бесполезных демонов» там само по себе не зародится.
                              • 0
                                Благодарю за разъяснения.
                              • 0
                                на DockerHub есть минималистичный debootstrap (размером всего 87.02 MB) для убунты, в котором нет лишнего софта, утилит и демонов. есть debootstrap для дебиана (навскидку нашел этот образ размером 122.6 MB)
                              • +1
                                А почему не использовать datavolumes вместо дампов?
                                • 0
                                  я считаю, что это было бы излишеством ибо тогда нужно было бы хранить всю папку для БД в своей директории при отключении окружения. да, это решило бы вопрос с разворачиванием дампов, но это породило бы дерево новых папок, которые не нужны. я осознанно отказался от предложеной Вами идеи в пользу дампов только из-за чистоты
                                  • 0
                                    Я так понимаю, можно просто создать Data Volume Container, и использовать его в качестве хранилища. Получается, что тогда он будет лежать вместе с другими контейнерами, а не в текущей папке.
                                    • 0
                                      есть несколько вариантов:
                                      • можно для каждого указывать локальную директорию хранения (-v) — например, нужно хост-директорию (хост-файл) пробросить в контейнер или же сохранить данные между запусками контейнера (для примера, можно вынести папку для хранения БД в файловую систему хоста и тогда базы будут сохраняться между запускати контейнера для баз данных),
                                      • можно завести какой-то контейнер и в него пробрасывать папочки (--volumes-from) — например, если данные нужно расшарить между несколькими работающими одновременно контейнерами
                                • 0
                                  Интересно, но как то замороченно у вас получилось.
                                  Вот пилил нечто похожее на Ubuntu 14.04 для своих целей.
                                  Вкратце — в контейнере стандартный LAMP, проекты на хостовой машине лежат в директориях с определенной структурой и после старта контейнера все стартуется bash-скриптом который создает в mysql пользователя, разворачивает дамп бд, подключает кастомный php.ini и стартует сервисы. С dnsmasq решил не заморачиваться т.к. проще прокинуть 80 порт на хост-машину и один раз прописать в /etc/hosts соответствие.
                                  Тут описал поподробнее.
                                  • 0
                                    о, так с Вашей статьи в блоге все и началось. изначально у меня приблизительно так оно и было.

                                    у меня был LAMP-образ, в проекте была дополнительная папка .docker с определенной струкрутой, был файл, который инициализировал запуск контейнера, прокидывал туда папки и конфиг для веб-сервера и прописывал в DNSMasq; и был файл, который запускался уже в контейнере и он уже создавал пользователя, БД на mysql-сервера хост-машины. все работало, все было круто, но для меня оно все равно было неким нагромождением допиленного неструктурированного кода, который нужно было когда-то переписать. потом я познакомился с Fig, разобался с линкованием, случайно удалил свои репозитории и пришлось «рукам дойти» для переписывания этого всего добра.

                                    не использование DNSMasq хорошо когда у Вас один проект и вы его можете спело повесить на http://localhost:80/, но если их несколько (можно вести несколько проектов; можно вести один и параллельно пилить что-то для себя; можно вести один проект, вести что-то для себя и изучать параллельно что-то третье новое для себя), то да, можно раскидать на несколько портов на интерфейсе хост-машины и не париться, но нужно будет запоминать порты — это уже не гуд, осмысленные доменные имена намного лучше, чем номера портов.

                                    на самом деле действий для развоначивания проекта в моем варианте не намного больше и их нужно произвести единожды для проекта — дальше его просто нужно запустить и остановить. при этом не нужно выходить за рамки папки с проектом
                                    • 0
                                      хех, я и забыл. Прошу прощения за повторение.

                                      Я просто обычно да, с одним проектом в один момент времени работаю. Кстати, конфиг файлы для апача также хранить в директории с проектом и их подключать при старте. Тогда станет возможной работа нескольких хостов в одном docker-контейнере.
                                      • 0
                                        А так разве можно?
                                        В смысле, это не рекомендуется обычно. Вообще ок такое проворачивать?
                                        • 0
                                          Ну вообще то это мое локальное dev-окружение и я волен настраивать все это так как мне это удобно. Поднимать 2 и более контейнеров с одинаковым окружением просто для того чтобы одновременно поднять несколько хостов и разруливать их на разных портах мне кажется намного более не ок чем поднимать несколько хостов на одном контейнере.
                                          • 0
                                            смешались в кучу люди кони…

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

                                            представим ситуацию: вы запускаете два проекта в одном контейнере. так думаю, что эти проекты у Вас должны быть доступными на отдельных виртуальных хостах. верно же? а как к ним иметь доступ? либо прописывать в /etc/hosts либо в локальный DNS. это реализуемо, но я думаю, что не стоит делать зва проекта зависимыми один от другого: вы хостите добавить проект — вы отключаете контейнер, правите конфиг, добавляете проект, запускаете контейнер. с отключением проекта аналогичная обратная ситуация.

                                            это будет ограничивать Вас в действиях (для того, чтобы налету добавлять проекты Вам нужно будет монтировать папку с проектами в контейнер дабы просто добавить новый проект в папку либ отключать-включать контейнер; руками заливать/очищать бамп БД). почему бы это не автоматизировать и не создавать для каждого проекта свою независимую от других набор контейнеров для разработки. а может, для некоторых проектов нужно будет больше, чем LAMP? нужно memcached добавить (я, кстати, хочу убрать вынести его со своих контейнеров и линковать официальный если это будет нужно), или там PostgreSQL, или Redis. Или просто нужно запустить посмотреть на какой-то проект, то зачем быть зависимым от других уже запущенных проектов в том же контейнере

                                            я считаю, что лучше разделять на отдельные контейнеры — они не так много ресурсов потребляют
                                  • 0
                                    как деплоить свой код в такую систему? после каждой правки в IDE запускать scp или ftp?
                                    • 0
                                      docs.docker.com/userguide/dockervolumes/

                                      При запуске (docker run) вставить вот такой флаг: -v /путь/на/хосте:/путь/в/контейнере
                                      Так же можно делать и в fig
                                      • 0
                                        оно само даплоится через проброс локальной папки в контейнер (в моем случае папка с проектом будет доступна в контейнере в директории /var/www)
                                      • –3
                                        Я просто оставлю это здесь.
                                        Ссылки на то, где можно сделать все проще
                                        Demo потыкать: deploy4me.com/en/demo/index.html
                                        Видео посмотреть: youtu.be/hqiKfu4ux_4
                                        Блох на Хабре: habrahabr.ru/company/d4m/
                                        • 0
                                          минусы:
                                          Платно: deploy4me.com/en/pricing.html
                                          Разворачивается облаке, что несколько затрудняет оффлайн разработку
                                          • 0
                                            Для разработки в облаках есть куча различных вариантов.
                                            Те же Heroku и Openshift для деплоя или Cloud9 где IDE с веб-сервером в одном флаконе.
                                            Но в посте речь как раз идет об оффлайн разработке. Так в первом случае коммитить код на каждый чих очень утомительно и нерационально, а во втором случае не всем (пока) подойдут онлайн-IDE для повседневной работы.
                                          • 0
                                            убираются записи из конфига DNSMasq и перезапускается демон

                                            Перезапускать не требуется, достаточно HUP-нуть.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.