Comments 12
на контейнере поднят весь необходимый мне софт
Это противоречит идеологии докера «один контейнер — один сервис (служба, софтина)». Отсюда возникает вопрос — а чем вас не устраивает просто виртуальная машина, собранная по конфигам. Какой-нибудь Vagrant с шефом или с пачкой bash-скриптов. Тем более что boot2docker это и есть виртуальная машина и вы не получаете всех плюшек паравиртуализации контейнерами, которые есть на линуксе.
Про софт: порой просто чтобы запустить простейший ресурс на nodejs необходимо весьма немалое количество софта — в моем случае обычно это и g++ и ruby (sass) и еще куча всего.
Идеология докера не заключается в этой фразе — «одна служба один контейнер» порой для работы одной службы необходимо для ее обслуживания поднять еще 10 служб.
Правильней рассматривать идеологию докера что это stateless виртуальная машина с очень быстрым стартом. (Я например часто использую докеры по аналогии с gnu утилитами — передаю в stdin контейнера данные — читаю из stdout)
Теперь про плюшки паравиртуализации и тп.
Так уж получилось, что моей рабочей машиной является macbook и boot2docker это необходимое зло, а весь софт который я пишу работает на linux серверах.
Часто в режиме отработал по запросу и закрылся: отсюда каждый раз под запрос поднимать виртуальную машину не вариант — долго, держать пачку виртуальных машин включенными тоже не вариант — очень уж большая пачка получается.
В интернете есть куча дискуссий на тему чем докер лучше-хуже виртуальной машины и решать что использовать вам.
В моем конкретном случае докер удобнее и лучше.
Решать использовать ли при разработке шефы вагранты и тп тоже вам — моя статья не об этом и никаким образом не запрещает этого делать.
Идеология докера не заключается в этой фразе — «одна служба один контейнер» порой для работы одной службы необходимо для ее обслуживания поднять еще 10 служб.
Правильней рассматривать идеологию докера что это stateless виртуальная машина с очень быстрым стартом. (Я например часто использую докеры по аналогии с gnu утилитами — передаю в stdin контейнера данные — читаю из stdout)
Теперь про плюшки паравиртуализации и тп.
Так уж получилось, что моей рабочей машиной является macbook и boot2docker это необходимое зло, а весь софт который я пишу работает на linux серверах.
Часто в режиме отработал по запросу и закрылся: отсюда каждый раз под запрос поднимать виртуальную машину не вариант — долго, держать пачку виртуальных машин включенными тоже не вариант — очень уж большая пачка получается.
В интернете есть куча дискуссий на тему чем докер лучше-хуже виртуальной машины и решать что использовать вам.
В моем конкретном случае докер удобнее и лучше.
Решать использовать ли при разработке шефы вагранты и тп тоже вам — моя статья не об этом и никаким образом не запрещает этого делать.
Не самое логичное и идейно-верное использование докера. Сама философия проекта как раз не в том чтобы сделать максимально укомплектованную виртуалку а в том чтобы сделать контейнер с минимально необходимым для его работы окружением. Фактически, проще было сделать полноценную виртуалку и потом при необходимости использовать ее образ.
Нет, конечно задача решается, но приспосабливать один инструмент под задачи другого — не лучший подход.
Нет, конечно задача решается, но приспосабливать один инструмент под задачи другого — не лучший подход.
В моей статье нет ни слова о том, что надо максимально докоумплектовывать докер контейнер, в ней вообще об этом не говорится,
более того я не использую софт выходящий за рамки стандартного, либо уже установленного в системе, либо необходимого для билда проекта.
netcat обычно уже стоит на любом linux,
grunt и его плагины выступают как make для веб проектов
Поэтому я не вижу каким образом мой пример использование докера нарушает идею сделать минимальное окружение для работы с контейнером.
более того я не использую софт выходящий за рамки стандартного, либо уже установленного в системе, либо необходимого для билда проекта.
netcat обычно уже стоит на любом linux,
grunt и его плагины выступают как make для веб проектов
Поэтому я не вижу каким образом мой пример использование докера нарушает идею сделать минимальное окружение для работы с контейнером.
В принципе вы ответили на комментарий выше уже более универсально.
Вообще тема интересная, возможно некоторое ложное впечатление как раз и сложилось из-за недостатка информации по вашему пути использования. Пишите еще.
Вообще тема интересная, возможно некоторое ложное впечатление как раз и сложилось из-за недостатка информации по вашему пути использования. Пишите еще.
Да тема интересная, да и сами докеры вначале пути — пока они очень удобны для использования в рамках одного хоста, и требуют дополнительных усилий при работе на разных, (почти все имеющиеся технологии связи контейнеров в рамках разных машин нарушают основную по мне вещь — неизменность окружения в контейнере либо требуют дополнительных контейнеров)
думаю в скором времени эти вопросы будут решены средствами самого докера и всем будет хорошо :-)
думаю в скором времени эти вопросы будут решены средствами самого докера и всем будет хорошо :-)
Вообще я дальнейшее развитие виртуализации вижу еще более интересным — автономные контейнеры, способные прозрачно использовать ресурсы других контейнеров по популярным протоколам. Ну либо еще интересная была бы концепция разделения ресурсов и приложений в рамках одной платформы, когда контейнеры по сути выступают потребителями общего ресурса, и вся эта радость прозрачно логируется.
Решил абсолютно ту же самую проблему чуть проще:
Локальный код монтируется через NFS в такую же папку внутри boot2docker, что и локально.
Например, путь к коду получается /Users/user/projects/someproject и на OS X, и внутри boot2docker.
Если у вас другие пути, то простым -v "$PWD":"$PWD" (описано ниже) будет не обойтись
Когда меняется файл локально, мы делаем «touch» того-же файла удаленно, чтобы ядро подхватило. inotify не видит «чужие» изменения в NFS, но видит те, которые сделала система локально. Никаких http клиентов и серверов, а также суррогатного файла не нужно при таком подходе.
Локальный код монтируется через NFS в такую же папку внутри boot2docker, что и локально.
Например, путь к коду получается /Users/user/projects/someproject и на OS X, и внутри boot2docker.
Если у вас другие пути, то простым -v "$PWD":"$PWD" (описано ниже) будет не обойтись
Когда меняется файл локально, мы делаем «touch» того-же файла удаленно, чтобы ядро подхватило. inotify не видит «чужие» изменения в NFS, но видит те, которые сделала система локально. Никаких http клиентов и серверов, а также суррогатного файла не нужно при таком подходе.
function fswatch_propagate_pwd_changes_to_docker () {
echo "Starting fswatch on $PWD"
# tracking previous not to get into endless loop of changing the same file
local previous=''
fswatch -r "$PWD" | while read file; do
if [[ previous != "$file" ]]; then
docker run --rm -v "$PWD":"$PWD" busybox touch "$file"
fi
previous="$file"
done
}
Да действительно проще, такой вопрос а после рестарта boot2docker заново перемонтируете nfs или он изменения в fstab запоминает?
Не решал еще эту проблему. Пока монтирую руками, но это делать нужно редко, лишь один раз при рестарте boot2docker. Системные файлы у него не поменять, т.к. образ системы read-only.
Пока, к сожалению, мне видится что единственный способ это сделать — собирать образ boot2docker вручную с нужными изменениями. Надеюсь, есть что-то попроще и красивее.
Пока, к сожалению, мне видится что единственный способ это сделать — собирать образ boot2docker вручную с нужными изменениями. Надеюсь, есть что-то попроще и красивее.
Кстати, чтобы touch не создавал файлы, которые удаляются, нужно использовать touch -c
На всякий случай, если будут еще изменения в функции, вынес ее в gist, чтобы комментарии лишние вроде этого не плодить
gist.github.com/ikatson/7c6a7e84339305090457
На всякий случай, если будут еще изменения в функции, вынес ее в gist, чтобы комментарии лишние вроде этого не плодить
gist.github.com/ikatson/7c6a7e84339305090457
Sign up to leave a comment.
Docker контейнеры для web-разработчика под OS X