у меня параноя по другому поводу: пускай я использую облачный сервер от провадере «X» — не может/будет ли он читать мою информацию на арендуемом сервере (ключи для шифрования трафика, ключи OpenVPN)?
я считаю, что поднимать 1+ контейнеров для нескольких проектов будет корректнее в плане независимости отдного проекта от другого
представим ситуацию: вы запускаете два проекта в одном контейнере. так думаю, что эти проекты у Вас должны быть доступными на отдельных виртуальных хостах. верно же? а как к ним иметь доступ? либо прописывать в /etc/hosts либо в локальный DNS. это реализуемо, но я думаю, что не стоит делать зва проекта зависимыми один от другого: вы хостите добавить проект — вы отключаете контейнер, правите конфиг, добавляете проект, запускаете контейнер. с отключением проекта аналогичная обратная ситуация.
это будет ограничивать Вас в действиях (для того, чтобы налету добавлять проекты Вам нужно будет монтировать папку с проектами в контейнер дабы просто добавить новый проект в папку либ отключать-включать контейнер; руками заливать/очищать бамп БД). почему бы это не автоматизировать и не создавать для каждого проекта свою независимую от других набор контейнеров для разработки. а может, для некоторых проектов нужно будет больше, чем LAMP? нужно memcached добавить (я, кстати, хочу убрать вынести его со своих контейнеров и линковать официальный если это будет нужно), или там PostgreSQL, или Redis. Или просто нужно запустить посмотреть на какой-то проект, то зачем быть зависимым от других уже запущенных проектов в том же контейнере
я считаю, что лучше разделять на отдельные контейнеры — они не так много ресурсов потребляют
вот вы вспомнили о тестировании на удаленном сервере. сейчас я придумываю как сделать приемочное тестирование на хост-машине из-под контейнера. но пока ничего толкового не приходит в голову ибо, скорее всего, это невозможно. тоесть, невозможно из-под докера запустить firefox на хост-машине. а поднимать в докере xserver как-не нерезонно
а что Вы скажете о приемочном тестировании в докере? понимаю, что юнит-тесты раскрутить не проблема и можно проводить приемочные тесты в фантоме, но вопрос именно о firefox
докер — это инструмент, который работает с lxc-контейнерами и предоставляет расширенній API для работы. на сколько мне известно, то lxc зависим от конфигурации системы и его не так уж просто перенести на другой хост. докер же делает возможным в несколько команд развернуть контейнер, который крутился на одном хосте, развернуть на другом. идея докера состоит в том, чтобы именно упаковать некое приложение или приложения и запустить его в изолированном контейнере.
для примера, можно без особых проблем на одном хосте в контейнерах запустить несколько версий серверов БД и иметь доступ к ним через разные порты
лично для себя докер мне удобен тем, что я могу экспериментировать с софтом, вести веб-разработку и при этом держать хост-машину в чистоте
немного уточню
Да, слои — это подобие коммитов в `git`, но только вот слой создается не при каждом изменении nginx.conf, а в двух случаях:
1. вы пишете свой Dockerfile, по которому билдите свой образ и при этом каждая запись в `Dockerfile` (`ADD`, `COPY`, `RUN`) будет генерировать новый слой. имейте в виду, что если вы пишете
RUN echo "Hello"
RUN echo "World"
RUN echo "My name is Vasya!"
RUN echo "Bye!"
то будет сгенерировано 4 слоя — каждый слой увеличивает размер результируючего образа в результате записи новых мета-данных. я специально привел в пример команды, которые в принципе (за исключением записи в `~/.bash_history`, но я не уверен, что он пишется во время билда образа) не должны ничего писать в файловую систему. потому все, что Вы будете делать через команду RUN лучше записывать в виде одной большой команды:
этом случае будет создано один слой
2. если Вы идете другим путем: можно запустить контейнер с интерактивной консолью `docker run -it imagename /bin/bash` (по сути Вы будете находиться в комендной оболочке контейнера), что-то там устанавливать, настраивать и писать. когда вы произведете некоторые нужные Вам действия (установите тот же `nginx` и настроите его), то Вы можете сделать коммит этих изменений в следуюющий слой (аналог коммита в `git`). при этом у Вас в дереве слоев образа добавится новый слой с изменениями. каждый слой можно тегировать — это и есть названия образов. можно смотрить изменения, которые были произведены (`diff`).
но я не советую использовать второй вариант поскольку если нужно будет поделиться этим образои или перенести или забекапить, то вам придется передавать его полностью. в случае же когда Вы пишете `Dockerfile`, вы все Ваши дейсвтия, производимые непосредственно в консоли, записываете командой `RUN` и дополнительно, если требуется, добавление файлов (готовых конфигов, к примеру). потом по этму файлу (наборов файлов если требуется `Dockerfile` + файлы конфигов, которые вы прописали в `Dockerfile` с помощью команд `ADD`, `COPY`) можно сбилдить образ, этими файлами проще поделиться — они намного меньше, чем результируючий образ — и другой человек тоже сбилдит образ на основе этих файлов
спасибо за подробности. все встало на места
надо руками пощупать в паре с nginx
сейчас мне нужна вариация консольных версий php и меня вчера очень удивил тот факт, что в зависимостях php5 был и apache и mysql сервера, но я думаю, что можно использовать не php5 за основу, а php5-cli и будет phpbrew все равно будет разруливать версии
>> Какую версию использовать для хоста задается в настройках web-сервера.
я так понимаю, что Вы имели в виду не phpbrew, верно?
о том, что методами, описанными по ссылочкам, можно указать для веб-сервера несколько версий php я знаю
спасибо
Вы понимаете, что когда речь идет о веб-сервере, то имеет место быть и хост и виртуальный хост? именно в контексте веб-сервера?
подскажите пожалуйста как указать версию PHP для виртуального хоста?
спасибо за статью
я считаю, что поднимать 1+ контейнеров для нескольких проектов будет корректнее в плане независимости отдного проекта от другого
представим ситуацию: вы запускаете два проекта в одном контейнере. так думаю, что эти проекты у Вас должны быть доступными на отдельных виртуальных хостах. верно же? а как к ним иметь доступ? либо прописывать в /etc/hosts либо в локальный DNS. это реализуемо, но я думаю, что не стоит делать зва проекта зависимыми один от другого: вы хостите добавить проект — вы отключаете контейнер, правите конфиг, добавляете проект, запускаете контейнер. с отключением проекта аналогичная обратная ситуация.
это будет ограничивать Вас в действиях (для того, чтобы налету добавлять проекты Вам нужно будет монтировать папку с проектами в контейнер дабы просто добавить новый проект в папку либ отключать-включать контейнер; руками заливать/очищать бамп БД). почему бы это не автоматизировать и не создавать для каждого проекта свою независимую от других набор контейнеров для разработки. а может, для некоторых проектов нужно будет больше, чем LAMP? нужно memcached добавить (я, кстати, хочу убрать вынести его со своих контейнеров и линковать официальный если это будет нужно), или там PostgreSQL, или Redis. Или просто нужно запустить посмотреть на какой-то проект, то зачем быть зависимым от других уже запущенных проектов в том же контейнере
я считаю, что лучше разделять на отдельные контейнеры — они не так много ресурсов потребляют
а что Вы скажете о приемочном тестировании в докере? понимаю, что юнит-тесты раскрутить не проблема и можно проводить приемочные тесты в фантоме, но вопрос именно о firefox
для примера, можно без особых проблем на одном хосте в контейнерах запустить несколько версий серверов БД и иметь доступ к ним через разные порты
лично для себя докер мне удобен тем, что я могу экспериментировать с софтом, вести веб-разработку и при этом держать хост-машину в чистоте
Да, слои — это подобие коммитов в `git`, но только вот слой создается не при каждом изменении nginx.conf, а в двух случаях:
1. вы пишете свой Dockerfile, по которому билдите свой образ и при этом каждая запись в `Dockerfile` (`ADD`, `COPY`, `RUN`) будет генерировать новый слой. имейте в виду, что если вы пишете
то будет сгенерировано 4 слоя — каждый слой увеличивает размер результируючего образа в результате записи новых мета-данных. я специально привел в пример команды, которые в принципе (за исключением записи в `~/.bash_history`, но я не уверен, что он пишется во время билда образа) не должны ничего писать в файловую систему. потому все, что Вы будете делать через команду RUN лучше записывать в виде одной большой команды:
этом случае будет создано один слой
2. если Вы идете другим путем: можно запустить контейнер с интерактивной консолью `docker run -it imagename /bin/bash` (по сути Вы будете находиться в комендной оболочке контейнера), что-то там устанавливать, настраивать и писать. когда вы произведете некоторые нужные Вам действия (установите тот же `nginx` и настроите его), то Вы можете сделать коммит этих изменений в следуюющий слой (аналог коммита в `git`). при этом у Вас в дереве слоев образа добавится новый слой с изменениями. каждый слой можно тегировать — это и есть названия образов. можно смотрить изменения, которые были произведены (`diff`).
но я не советую использовать второй вариант поскольку если нужно будет поделиться этим образои или перенести или забекапить, то вам придется передавать его полностью. в случае же когда Вы пишете `Dockerfile`, вы все Ваши дейсвтия, производимые непосредственно в консоли, записываете командой `RUN` и дополнительно, если требуется, добавление файлов (готовых конфигов, к примеру). потом по этму файлу (наборов файлов если требуется `Dockerfile` + файлы конфигов, которые вы прописали в `Dockerfile` с помощью команд `ADD`, `COPY`) можно сбилдить образ, этими файлами проще поделиться — они намного меньше, чем результируючий образ — и другой человек тоже сбилдит образ на основе этих файлов
надо руками пощупать в паре с nginx
сейчас мне нужна вариация консольных версий php и меня вчера очень удивил тот факт, что в зависимостях php5 был и apache и mysql сервера, но я думаю, что можно использовать не php5 за основу, а php5-cli и будет phpbrew все равно будет разруливать версии
я так понимаю, что Вы имели в виду не phpbrew, верно?
о том, что методами, описанными по ссылочкам, можно указать для веб-сервера несколько версий php я знаю
спасибо
подскажите пожалуйста как указать версию PHP для виртуального хоста?
0.0.0.0указывает на то, что созданный сервер будет доступен на всех интерфейсах контейнерано Вы здесь ссылочкой не ошиблись случаем? там в релизах даже бетой не пахнет — недавно только 0.0.0.alpha вышла
Платно: deploy4me.com/en/pricing.html
Разворачивается облаке, что несколько затрудняет оффлайн разработку