Comments 23
Круто! А что технически делает галочка «Разрешить управление ядром ОС»?
У нас в облаке 2 типа виртуализации: контейнерная и гипервизорная. Галочка включает гипервизорную (VM) виртуализацию, которая требуется для работы Docker с подходящим ему ядром ОС. Также с этой опцией можно обновлять ядро ОС и ставить модули самостоятельно. С другой стороны контейнерная виртуализация эффективнее использует ресурсы оборудования.
А как вы решаете ситуации, когда нужно выстроить иерархию слинкованных контейнеров, а потом один из них перезапустить?
Например database->back-end->api->ui и нужно пересобрать database.
Например database->back-end->api->ui и нужно пересобрать database.
В такой ситуации лучше использовать какой-нибудь оркестратор и service-discovery. А еще лучше — software defined network типа flannel или Kubernetes, который позволит все эти контейнеры разнести по разным хостам.
Ну или посмотреть в сторону CoreOS (с тем же flannel).
Сейчас у меня на продекшене это делается через skydock/skydns (т.е. service discovery), но никому не советую так делать.
Ну или посмотреть в сторону CoreOS (с тем же flannel).
Сейчас у меня на продекшене это делается через skydock/skydns (т.е. service discovery), но никому не советую так делать.
Мой опыт пользования сабжем говорит о том, что он для решения таких задач не предназначен. Это просто пускалка сервисов в изолированном окружении. Хорошо подходит для тех, кому разделения процессов на уровне ядра — недостаточно или для софта, у которого конфликтующие зависимости.
Есть конечно у докера привлекательные бизнес-возможности: можно гарантированно рабочий компонент системы быстренько запаковать и развернуть. Но поддерживать и отлаживать эти контейнеры — процедуры не всегда тривиальный и обычно не приносящие радости и удовольствия.
Так и выходит — боссы радуются, админы недоумевают.
имхо.
Есть конечно у докера привлекательные бизнес-возможности: можно гарантированно рабочий компонент системы быстренько запаковать и развернуть. Но поддерживать и отлаживать эти контейнеры — процедуры не всегда тривиальный и обычно не приносящие радости и удовольствия.
Так и выходит — боссы радуются, админы недоумевают.
имхо.
А у вас планируется поддержка CoreOS?
Да, но позже. Необходимо сделать качественную интеграцию с облаком. Пока CoreOS не готова к применению в Enterprise, хотя безусловно очень интересна.
Если будете тестировать, пожалуйста, сделайте анонс — обязательно приму участие.
хорошо. Новость будет в нашем блоге на Хабре, в Сообществе InfoboxCloud и в официальной группе на Facebook. Можно читать где удобно.
Встречный вопрос хабровчанам: нужен шаблон CentOS 7 с Docker? В принципе не так важно, на чем запускать Docker контейнеры, но RHEL 7 уже официально поддерживает Docker. Нужен такой шаблон или Ubuntu с Docker достаточно? Если нужен, то зачем? На первый взгляд — т.к. у CentOS 7 ускорилась сетевая подсистема — было бы полезно. А вы как думаете? (если нужен — сделаем)
Не подскажите, как можно параметризовать докер-контейнер на этапе сборки?
Н-р:
— у меня в одном месте интернет через прокси и приходится его явно прописывать, ну н-р:
— в другом прокси нет и команда выглядит:
при этом естественно хочется иметь один Docker файл для обоих случаев, нужно только уметь передавать туда параметр из cmd-line.
Н-р:
— у меня в одном месте интернет через прокси и приходится его явно прописывать, ну н-р:
RUN pip --proxy http://1.1.1.1:80/ install uwsgi— в другом прокси нет и команда выглядит:
RUN pip install uwsgiпри этом естественно хочется иметь один Docker файл для обоих случаев, нужно только уметь передавать туда параметр из cmd-line.
В таком случае лучше использовать какую-то утилиту для шаблонов, которая будет генерировать Dockerfile в зависимости от окружения.
Т.е. будет Dockerfile.template
И на этапе сборки сначала генерируется Dockerfile, а затем уже выполняется сборка образа.
Почти такой подход у меня применяется для того, чтобы обновлять образы при деплое — подставляется хеш коммита в определенную строчку.
Иметь один Dockerfile не получится из-за того, что он должен не зависить от окружения by design.
Логичнее всего было бы сделать базовый образ для uwsgi, запушить в registry и использовать уже его.
Т.е. будет Dockerfile.template
{% if proxy %}
RUN pip --proxy http://1.1.1.1:80/ install uwsgi
{% else %}
RUN pip install uwsgi
{% endif %}
И на этапе сборки сначала генерируется Dockerfile, а затем уже выполняется сборка образа.
Почти такой подход у меня применяется для того, чтобы обновлять образы при деплое — подставляется хеш коммита в определенную строчку.
Иметь один Dockerfile не получится из-за того, что он должен не зависить от окружения by design.
Логичнее всего было бы сделать базовый образ для uwsgi, запушить в registry и использовать уже его.
Соберите bash скрипт с вашими командами и конфиг который будет этот скрипт параметризовать. Складываете скрипты в ту же директорию что и докерфаил и когда вы выполняете
Ваш скрипт улетит серверу вместе с докерфаилом.
Вообще идеология докера предполагает что бы по изменению докерфаила всегда можно было отследить изменения контейнера, но прямо сейчас есть несколько проблем, которые не позволяют использовать этот подход. В итоге большинство базовых образов собраны с помощью дополнительный bash скриптов.
docker build .
Ваш скрипт улетит серверу вместе с докерфаилом.
Вообще идеология докера предполагает что бы по изменению докерфаила всегда можно было отследить изменения контейнера, но прямо сейчас есть несколько проблем, которые не позволяют использовать этот подход. В итоге большинство базовых образов собраны с помощью дополнительный bash скриптов.
Астрологи объявили неделю докера на хабре, количество постов о нем увеличено вдвое.
И знаете, это здорово!
И знаете, это здорово!
Жаль, что конструкция
docker build git@github.com:somename/somerepo/somepath не работает
docker build git@github.com:somename/somerepo/somepath не работает
хочу заметить: поскольку каждая строка в Dockerfile — это отдельный коммит, то результирующий образ будет весить несколько больше, чем в случае если все команды писать в одну строку через "&&" или использовать скрипт установки и настройки, типа как в Vagrantfile
хочу спросить: у меня в роли хост-ОС Ubuntu 14.04. я пытался запустить CentOS контейнер. он запустился, все хорошо, но одно «но»: когда я пытался установить ПО (кажется, LAMP), из репозиториев он подтягивал мне пакеты для одной версии ядра, а при запуске искал среди установленных пакетов искал пакеты для другой версии ядра. на сколько я понял, то он использовал версию ядра хоста для установи, а потом пытался искать по той версии, которая записана у него где-то. я перелинковывал папки, но толку не вышло — все болотистей и болотистей получался результат. потому пришел к выводу, что в докере нужно использовать ту же ветвь дистрибутивов, что и на хосте. у меня на хосте убунта и в контейнерах корректно запускаются дистрибутивы убунты и дебиана. это правда или я что-то делал не так?
хочу спросить: у меня в роли хост-ОС Ubuntu 14.04. я пытался запустить CentOS контейнер. он запустился, все хорошо, но одно «но»: когда я пытался установить ПО (кажется, LAMP), из репозиториев он подтягивал мне пакеты для одной версии ядра, а при запуске искал среди установленных пакетов искал пакеты для другой версии ядра. на сколько я понял, то он использовал версию ядра хоста для установи, а потом пытался искать по той версии, которая записана у него где-то. я перелинковывал папки, но толку не вышло — все болотистей и болотистей получался результат. потому пришел к выводу, что в докере нужно использовать ту же ветвь дистрибутивов, что и на хосте. у меня на хосте убунта и в контейнерах корректно запускаются дистрибутивы убунты и дебиана. это правда или я что-то делал не так?
Все верно, докер использует ядро хоста.
У меня с хостами arch linux (3.16.4) и centos 6.5 (2.6.32) запуск и установка софта в контейнерах с busybox, ubuntu и centos разных версий проблем не вызывала. Почему у вас LAMP зависит от ядра? Мне такое кажется, как минимум, странным. Обычно такие вещи тянут зависимости не дальше libc.
будет свободная минутка — попробую воспроизвести ситуацию и отпишуть
скачал centos:centos6, установил там LAMP. кажется, все запустилось даже и не ругалось. не вспомню что я еще тогда устанавливал.
в любом случае, остаюсь на debian-контейнерах для веб-разработки — если работает, то не буду трогать
в любом случае, остаюсь на debian-контейнерах для веб-разработки — если работает, то не буду трогать
Если всё работает и устраивает, то можно и не париться. От добра добра не ищут.
У меня самая, пожалуй, неприятная вещь, связанная с докером — это ркн. При выполнении
У меня самая, пожалуй, неприятная вещь, связанная с докером — это ркн. При выполнении
docker pull периодически попадаю на заблокированный ipшник cloudflare. При использовании в скриптах это крайне неудобно. А заворачивать трафик с серверов на cloudflare через vpn пока лень.Sign up to leave a comment.
Погружаемся в Docker: Dockerfile и коммуникация между контейнерами