Transmission внутри контейнера должен запускаться не в daemon-режиме, а foreground. см. https://hub.docker.com/r/magnaz/transmission/~/dockerfile/

Я создал образ andyceo/phpdevenv

Наш образ внутри компании немного отличается, но тем не менее суть ясна — там находятся все нужные для работы инструменты. Вот этот образ и разворачиваем разработчику через Ansible, он выгружает туда код из IDE, и запускает сборку (скрипт для сборки проекта находится в самом проекте).

Ну а продакшен отличается, есть образы-сборщики и Докерфайл для продакшен-сборки. Образ-сборщик поднимается, в нем настроен Docker-in-Docker, и собирает проект, создает продакшен-имадж, который потом разворачивается для тестировщиков и далее, через Ansible.

Подробнее про andyceo/phpdevenv уже отвечал здесь

Если есть еще вопросы, отвечу.

Ну для себя сразу по тегам таски и роли я разбить не смог, только спустя какое-то время, проанализировав, что чаще всего из плейбука мне надо, я пометил тегами. Теперь не надо выполнять весь плейбук, когда хочешь всего лишь поднять контейнеры, например.

Это вы ошиблись, про git clone не я писал. Напротив, у нас даже накатывание проекта для разработчика происходит через докер.

Удаленная установка на машину разработчика — возможно это удобно в офисе.

Да, а еще и на тест-сервер, и на прод-сервер.

Да, вот только у ансиблса задачи сильно фрагментированы обычно, а плейбуки — что-то типа монолита, причем по несколько штук на разные случаю

Используйте теги и будет счастье! --tags='docker-orchestrate', --skip-tags='ssl' например.

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

Согласен полностью, в свое время просто исплевался, работало нестабильно. Сейчас вроде более-менее устаканилось все.

Я не против Ansible, но, на мой взгляд, это тупиковый путь, потому что требует держать в контейнере как минимум 2 процесса. Например, php и sshd (поправьте меня, если это не так

sshd был нужен, но теперь благодаря Ansible-container не нужен.

php не был нужен никогда, нужен python — но почти в любой Linux-системе установлен по умолчанию. Вкратце, Ansible работает так: видит таск, генерирует python-скрипт на этот таск и заливает на удаленную машину, затем там его выполняет. Но может и напрямую выполнить любую shell-команду, см. raw module.

Но это не вписывается в бест практис 1 контейнер = 1 процесс.

Ну, не хочу холиворить, но все-таки бест практис или нет, сильно зависит от задачи. Посмотрите например на официальный докер-образ Gitlab. Очень здорово сделали, что упаковали все в один контейнер, и теперь я могу поднять этого монстра одной командой. Если бы все было в разных контейнерах, настройка и установка всего этого было бы таким же адом, как и установка в систему через пакеты.

Да и свой phpdevenv мне нравится — все что надо у разработчика есть. Один процесс в контейнере или несколько — не имеет значения, докер заточен для упаковки и доставки приложений (или если угодно сервисов), и если сервису надо несколько процессов, то пусть так и будет.

Ansible это хорошо, но это дополнительный компонент со всеми вытекающими.

Если вам надо админить несколько разработческих машин, машины тестировщиков и еще и прод, то Ansible или аналоги необходимы, если не хотите делать все руками. А раз он все равно нужен, то почему бы его и не использовать?

Кстати, compose научился создавать контейнеры на разных хостах и связывать их в одну сетку? А ансиблом эта задача решается, можно сказать, «из коробки».

Да, в случае с docker-compose при подключении внешних конфигов бывают неудобства с несовпадением User ID в контейнере и на хост машине, но это решается через chown, chmod (или аналоги).

Вот тут не понял. Значит надо ДО волшебной команды docker-compose up -d все-таки что-то сделать руками? Ну тогда опять же, Ansible рулит.

Не хочу продвигать этот Ансибл, но он реально позволяет сделать жизнь проще. Как и Докер. Для каждой задачи — свой инструмент.

PS: Забыл дописать. В моей роли docker есть примеры с преднастроенными контейнерами. Вот пример для Nginx:

# Nginx
# @see https://hub.docker.com/_/nginx/
# You should copy config files before create container!
# You should place virtual host configs in nginx/conf.d directory
- name: nginx
enabled: yes
image: nginx
tag: 1.10.1
state: started
hostname: nginx
detach: True
restart_policy: always
net: docknet
ports:
- 80:80
- 443:443
volumes:
- /data/ssl:/ssl:ro
- /data/nginx/htpasswds:/etc/nginx/htpasswds:ro
- /data/nginx/conf.d:/etc/nginx/conf.d:ro
- /data/nginx/fastcgi_params:/etc/nginx/fastcgi_params:ro
- /data/nginx/proxy_headers:/etc/nginx/proxy_headers:ro
- /data/nginx/proxy_params:/etc/nginx/proxy_params:ro
- /data/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
- /data/nginx/default-content:/usr/share/nginx/html:ro
- /data/nginx/cache:/var/cache/nginx:rw
- /data/nginx/logs:/var/log/nginx:rw



Как видно, синтаксис почти совместим с compose, и можно с минимальными правками поднимать контейнеры compose'ом вместо Ansible.

Для разработки любых php-проектов, в том числе и друпал я, например, создал образ andyceo/phpdevenv

Поднимаешь, стучишься по ssh — и у тебя готовая почти полноценная виртуалка. «Почти» потому, что вместо процесса init, который используется в Linux для старта ядра и управления всеми остальными процессами, здесь используется supervisord. Поэтому не работают команды

sudo service restart nginx

например, а вместо них надо использовать

supervisorctl restart nginx

. Остальное все как в свежеустановленной Ubuntu на виртуалке.

По поводу compose-файла. Для управления контейнерами я использую Ansible вместо compose, потому что compose не может создать нужные папки, файлы с нужными правами (в которых лежат кастомные настройки для Nginx, например) ДО старта контейнеров. Поэтому у меня есть Ansible-роль configurator, которая управляет папками и файлами, и после нее выполняется роль docker, которая поднимает контейнеры. Эта роль в плане управления контейнерами почти как compose, с той разницей, что может еще и установить докер, и compose, и создать пользовательскую docker-сетку (надеюсь, вы уже не линкуете контейнеры через link, а используете встроенный в докер dns?)

И да, я бы тоже не назвал свою работу «open-source инициативой» :)

Подобные приложения уже написаны, Ansible называется.

Я, например, написал пару ролей, первая configurator делает то же самое с папками, файлами, конфигами.

Вторая docker ставит докер и docker-compose, если они не установлены, и управляет контейнерами.

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

Попробуйте Git Bash — https://git-scm.com/download/win
Основные утилиты командной строки Linux там есть: ssh, awk, grep, git.

Недавно открыл для себя «Йога — поиск силы» Ошо. Хорошо разъясняет суть процесса, с использованием йогических терминов.

Да, Ansible — мощная штука!

Я заморочался и создал несколько ролей, которые можно повторно использовать, в основном, это касается веб-разработки и LAMP-стека: github.com/andyceo/ansible-roles Еще несколько ролей можно найти на Ansible Galaxy, сервисе, куда можно закачивать свои роли, чтобы все ими могли пользоваться.

Еще долго думал, в каком виде хранить все свои настройки для всех хостов в виде одного репозитория, и вот пока пришел к этому: github.com/andyceo/ansible-example

Об использовании Ansible для разработке под Друпал я рассказывал на последнем Drupal-кемпе в Москве, вот доклад, кому интересно: 2014.drupalcampmsk.ru/program/sessions/ispolzovanie-ansible-dlya-upravleniya-serverami-i-drupal

Да, привет) вот и у меня что-то смутное в голове шевельнулось, решил написать.

Мы не могли столкнуться с этим в РИА, т.к. там использовался Drupal 6. который хранит сессии в БД.

Может ты столкнулся с этим, во время работы в РИА, но в другом проекте? :)

Хорошие такие грабельки…

Ни одного комментария про «Игру Эндера»? :)

Ну, в целом-то, статья сводится к призыву: планируйте! Прежде чем что-то делать, надо бы прикинуть что к чему. Посчитать, помоделировать. Найти цель. Затем написать шаги, с помощью которых вы планируете прийти к цели. Затем сделать первый шаг. Оглянуться на план: вы сделали шаг, и ситуация изменилась — ваш план нужно обновить. Иногда нужно обновить и цели… Затем снова сделать шаг. И так далее, пока цель не будет достигнута.

А вы забываете, что если не будет Дохода, то будет только минус. — Расход. И никому этот минус не нужен.

А почему вы не смотрите с другой стороны? Разве не лучше, чтобы пользователи получили новые функции как можно быстрее, и быстрее с помощью них решили свои насущные проблемы? Разве это не большее благо, чем счастливый разработчик? И да, люди согласны за это платить, за быстрое и качественное разрешение своих проблем. И платить хорошие деньги. Поэтому стремление руководства к прибыли — это стремление к максимизации блага.