olemskoi Jul 27 2016 at 08:59

Ansible-container: новый шаг в управление контейнерами

4 min

29K

Слёрм corporate blogSystem administration*Virtualization*Server Administration*DevOps*

Tutorial

+20

Comments 13

theo Jul 27 2016 at 09:40

Cпасибо за статью. В случае, если Dockerfile мы пишем сами, то у нас есть возможность управлять слоями образа, путем объединения команд под одной инструкцией (например: RUN yum update && yum install… ) и тем самым экономя на размере однотипных образов, как это делать в случае с ansible-container?

P.S. В вашем примере containers.yml не стоит выкидывать порт 9000 на 0.0.0.0 интерфейс, для nginx это не нужно, а вот весь «прогрессивный» мир будет рад увидеть доступный php-fpm для выполнения :)

dmitry_ch Jul 27 2016 at 10:20

Фото котика зеркально повернуто по горизонтали? Надпись Nestle зеркальная. Неудивительно, что у него такое выражение мордочки )

-1

foxmuldercp Jul 27 2016 at 13:31

А я сейчас на рельсах пишу свою панель управления для хостингом приложений, основанную на docker, потому как текущие существующие решения, ээм, немного в этом плане отстали.

dostigai Jul 27 2016 at 15:22

Благодарность Виктору и всему проекту!

Gular Jul 27 2016 at 17:04

Разработчикам Ansible (Red Hat) нужно было назвать этот инструмент «Yet Another Docker Orchestration Tool», потому что, честно говоря, существует так много инструментов для работы над уровнем Docker. :-| Kubernetes, CoreOS, инструменты от Hashicorp, RacherOS.
Что будет, если Docker сделает Dockerfile deprecated?

umputun Jul 27 2016 at 20:41

Что-то я упускаю прелесть этой идеи. В моем понимании построение контейнера, это часть построения сервиса/программы, которое создает артифакты в виде docker image и пушит, и все это происходит в CI системе и, строго говоря, никакого отношения к asnible не имеет. Именно тут нужен Dockerfile, и он нужен на уровне сервиса а не на уровне композа, т.е. каждый сервис строится со своим собственным Dockerfile и никакой зависимости с прочими частями, типа nginx ему не надо.

Сам деплоймент никакого отношения к этим Dockerfile не имеет, он их даже не видит. Все, что ему надо это docker-compose.yml в котором прописано все сервисы, порты, зависимости и прочее. Это (деплоймент) можно делать с помощью ansible (я так и делаю) но никакой хитрости для этого не надо, просто доставить compose файл плюс что надо еще (конфиги, например) и дернуть docker-compose.

В какой модели удобно использовать подход описанный здесь, я не могу себе представить. Это если строить на боевом сервер контейнер? И в этом, странном случае, это можно делать с помощью compose. Единственный, но на мой взгляд сомнительный, плюс это разбиение на роли для сборки образов, но я не очень вижу зачем, например dumb-init иметь в виде роли, но не базовым контейнером.

Кроме того, реализация своего сборщика, это дело муторное и требующее постоянной гонки за обновлениями docker. Даже они сами не поспевают с этим, и compose иногда обновляется сильно позже чем та или иная фича добавилась в докер. А тут теперь надо будет ждать пока и ansible это добавит.

theo Jul 28 2016 at 10:39

В статье прямо пишут о том «зачем» это было придуманно: "...Dockerfile — не более, чем shell-скрипт со своими инструкциями. Не знаю, как вам, но лично я предпочту описать содержимое контейнера в yaml-формате...". Авторам и адептам, «так» легче :)

umputun Jul 28 2016 at 23:33

Dockerfile примерно такой же «shell-script» как и ансибловый yaml. Ну да, там в RUN пиши что надо, но примерно с тем же успехом можно сказать, что и ansible это такой «shell-script» с ssh запускалкой.

Короче, как по мне, так очень странная затея. Понятно, почему это надо ansible, но как (а главное зачем) этим будут пользоваться живые люди я все еще не могу понять. Мотивация «этот язык описания мне нравится больше» мне кажется какой-то неубедительной для введения такого сомнительного велосипеда в свой процесс построения контейнеров.

skandyla Jul 31 2016 at 08:50

Также, никто не мешает запускать плейбук и в самом docker контейнере, предварительно установив там ansible или взяв уже готовый image c ansible.

RUN  yum -y install epel-release \
     && yum -y install ansible \
     && echo -e "[local]\nlocalhost" > /etc/ansible/hosts
RUN  ansible-galaxy install example-role
RUN  ansible-playbook site.yml -c local

полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry. В то время как делать ansible-container run видится актуальным для каких-то тестов разве что...

umputun Jul 31 2016 at 09:18

идея запускать плейбук и в самом docker контейнере мне кажется еще более … диковинной, мягко говоря. Если вдруг по каким-то, совершенно непонятным мне причинам, хочется делать такие странные, полуготовые и мутабельные докер контейнеры и деплоить внутрь код с помощью ansible, то совсем непонятно зачем тут docker вообще, и почему бы не делать это прямо на хост.

> полагаю, что идея(использования ansible-container) приобретает ценность, когда при помощи ansible-container производится только сборка и push в registry

С трудом могу себе представить эту ценность. Возможно, для этого нужны какие-то совсем дикие многофункциональные контейнеры, которые муторно и сложно описать обычным образом, но мне это видится кривой дорогой — я за контейнер-на-сервис, а не контейнер-как-легкая-vm.

skandyla Jul 31 2016 at 21:36

Здесь речь шла о том, что при помощи ansible playbook можно приготовить такой же самый immutable контейнер, просто использовав ansible вместо шела. Это имеет смысл когда на ансибле уже написана автоматизация для сервиса. Ну или, например, для тестирования тех же плейбуков и ролей, но это уже совсем другая история.

В целом я с вами солидарен, преимущества от использования ansible-container для меня не очевидны, если не сказать спорны.

GreenDay Aug 3 2016 at 20:45

Запускать ansible внутри контейнера очень даже можно и нужно. Но не для деплоя чего-то внутри, а для CI и тестов. Я тестирую свои публичные роли внутри докера(именно тот кейс, который вам кажется дикостью — полное разворачивание сервиса внутри докера) в travis'е. Закрытые плейбуки тестируются в докере и CD происходит изнутри контейнера.

А вот делать из ansible dockerfile + docker compose сомнительная вещь, согласен с вами.

umputun Aug 3 2016 at 21:02

Ну это ведь о другом. У меня тоже ansible используется из контейнера по понятным причинам — все зависимости, что ему нужны там, все скрипты и все ключи доступны и прочее. Тут ansible просто еще одна докерезированная штука которая мало отличается от любого другого сервиса. Мой комментарий относился к идее запускать плейбук и в самом docker контейнере для инициализации/создания этого контейнера и именно такой кейс я назвал диковинным.