Comments 6
Мне интересно, за что же кидаетесь «палками», как положительными, так и не очень. Возможно, какие-то моменты не понятны, тогда, пожалуйста, укажите в каком месте статьи, поправлю.
Спасибо за статью, материал интересен, но уж шибко теоретический.
Хотелось бы конкретики, примеров, может быть, каких-нибудь практических приёмов, которые приходят с опытом.
Я сейчас как раз строю свою докер-ферму с луно-парком, и по ходу строительства приходится решать различные моменты и подбирать удобные методы работы. Информации по докеру много, но практически вся — либо оторванные от жизни учебные примеры, либо какие-то невнятные конструкции, в которых не понятно, зачем там вообще докер.
Например, недавно открыл для себя утилиту "eatmydata", при использовании которой во время базовой развёртки необходимого софта в контейнере, время сборки серьёзно сокращается. Или освоил проброс трафика в контейрера через lo интерфейс только средствами iptables — нужно отключить userland-proxy и разрешить ядру роутить локальный трафик между интерфейсами, а не отбасывать его как марсианский (net.ipv4.conf.all.route_localnet).
Наверняка подобных мелочей, из которых собирается готовая система, на практике наберётся множество.
Хотелось бы конкретики, примеров, может быть, каких-нибудь практических приёмов, которые приходят с опытом.
Я сейчас как раз строю свою докер-ферму с луно-парком, и по ходу строительства приходится решать различные моменты и подбирать удобные методы работы. Информации по докеру много, но практически вся — либо оторванные от жизни учебные примеры, либо какие-то невнятные конструкции, в которых не понятно, зачем там вообще докер.
Например, недавно открыл для себя утилиту "eatmydata", при использовании которой во время базовой развёртки необходимого софта в контейнере, время сборки серьёзно сокращается. Или освоил проброс трафика в контейрера через lo интерфейс только средствами iptables — нужно отключить userland-proxy и разрешить ядру роутить локальный трафик между интерфейсами, а не отбасывать его как марсианский (net.ipv4.conf.all.route_localnet).
Наверняка подобных мелочей, из которых собирается готовая система, на практике наберётся множество.
Спасибо, за комментарий.
На практике, все получается довольно просто. Определил для себя приоритеты: набор этих утилит я менять не буду (пусть образ живет полгода), этими когда-нибудь займусь (раз в месяц, что-то изменится, придется java обновить), а этими я пользуюсь постоянно (пересобираю каждый день). Логично выделить три типа образов, по времени модификации. Поэтому в моем случае на практике все выходит просто: 3 основных шаблона и 14 завершенных на них образов.
В примере в статье специально подобрал запутанную схему, чтобы показать нюансы методики, когда библиотеку d6 пришлось засунуть в косвенно связанный с ним образ, чтобы не создавать отдельный. Поэтому считаю эту методику не завершенной.
Что же касается тонкостей и мелочей формирования слоев образов, думаю необходима не статья. Все зависит от файловой системы, а не методики. Использовать ту же утилиту apt-get в слоях можно по разному.
На счет информации, The Docker book, статьи с хабра и changelog docker с github — для меня море информации-опыта. Который часто не требуется, пока не столкнешься с конкретными проблемами. Поэтому собраться и написать «летопись», я как-то не планировал.
На практике, все получается довольно просто. Определил для себя приоритеты: набор этих утилит я менять не буду (пусть образ живет полгода), этими когда-нибудь займусь (раз в месяц, что-то изменится, придется java обновить), а этими я пользуюсь постоянно (пересобираю каждый день). Логично выделить три типа образов, по времени модификации. Поэтому в моем случае на практике все выходит просто: 3 основных шаблона и 14 завершенных на них образов.
В примере в статье специально подобрал запутанную схему, чтобы показать нюансы методики, когда библиотеку d6 пришлось засунуть в косвенно связанный с ним образ, чтобы не создавать отдельный. Поэтому считаю эту методику не завершенной.
Что же касается тонкостей и мелочей формирования слоев образов, думаю необходима не статья. Все зависит от файловой системы, а не методики. Использовать ту же утилиту apt-get в слоях можно по разному.
На счет информации, The Docker book, статьи с хабра и changelog docker с github — для меня море информации-опыта. Который часто не требуется, пока не столкнешься с конкретными проблемами. Поэтому собраться и написать «летопись», я как-то не планировал.
Э-э… а практический пример применения методики? x,p, q, с и iddqd — это, конечно, хорошо. Но вот у меня есть apache, nginx, mysql, php, node.js, sphinx и много-много своего кода. Как жить?
Не пойму чем плох вариант когда весь стек живет в одном контейнере, а директория с кодом монтируется в контейнер при запуске.
С выходом новых версий софта не составляет ничего сложного обновить софт и закоммитить изменения.
Я про случай с применением контейнеров для локальной разработки. Держу на компе несколько контейнеров с немного различающимися версиями софта и подключаю их в различных случаях.
С выходом новых версий софта не составляет ничего сложного обновить софт и закоммитить изменения.
Я про случай с применением контейнеров для локальной разработки. Держу на компе несколько контейнеров с немного различающимися версиями софта и подключаю их в различных случаях.
Sign up to leave a comment.
Методика создания образов на примере Docker