Как разделить окружение для сборки и запуска сервиса в Docker сегодня и как это cделать завтра

Не соглашусь.

Как минимум:
1. Не всё можно поставить в образ через менеджер пакетов.
2. Теряется кэширование слоёв. В итоге каждый раз ставим всё заново, что увеличивает общее время сборки.

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

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

Начинали мы с совсем небольшого количества отдельных виртуальных машин. Поэтому ничего не нужно было тестировать на предмет совместимости.

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Про упаковку зависимостей есть, а про cgroups и прочее уже хорошо сказал bsideup. Удобство и простота использования короче.

Docker in production: «Когда ты это кушаешь, тебе, как минимум, не противно, особенно если знаешь, как готовить»

Docker — в случае микросервисов на Java — это не средство виртуализации (хотя тут правильнее говорить о контейнеризации), это, вкупе со средствами оркестрации, инструмент дистрибуции и менеджмента. Например, Docker тебе даёт из коробки инструменты для изоляции ресурсов, унифицированный API для управления жизненным циклом конкретных экземпляров сервисов, и так далее.

Получаем управление обратно в Jenkins Pipeline

Пока что не было потребности. У нас в основном довольно короткий и линейный цикл поставки, поэтому проще или запустить весь цикл с начала, или использовать поправленный ручками Replay. Подробнее есть у меня в презентации. Видео, к сожалению, выступления нет.

Получаем управление обратно в Jenkins Pipeline

Он вполне себе ок на чтение. Нам больше пока от него ничего и не нужно, поскольку имеем автоматическую настройку, заскриптованную через Ansible. Ставили его из исходников через собственный Update Center, но можно и через официальный экспериментальный.

Тестируй плагины для Gradle правильно

Ценное замечание, после которого пример заработал. Обновил соответствующий раздел статьи.

Пишем собственный шлюз для Thrift API

Мы изучали возможности thrift-а и его применение в реальной жизни, а потом стало по-спортивному интересно, и проект пилился под выступление на конференции. Ну а уже после материал был обёрнут в статью.

Пишем собственный шлюз для Thrift API

Да, хороший проект. Правда подход IDL-first мне импонирует больше.

Docker в банке. Видео с лекции Александра Тарасова из Альфа-Банка

>Какие базовые образы вы используете? Пробовали ли alpie?
Debian, Ubuntu, Alpine. Образы в основном собираем сами и кладём в приватный репозиторий.

>Как связываете контейнеры?
В основном nginx на том же хосте работает как прокси, либо через клиентский экземпляр consul-а (HTTP + DNS).

>dns через дирижёра?
Есть локальные клиенты на каждом сервере, где требуется discovery.

>как боритесь с падением nginx при запуске если dns не доступен?
Nginx конфигурируется с помощью consul template, который не использует DNS, и строго говоря nginx зависит от consul-a лишь через сгенерированный конфигурационный файл, который просто не будет обновляться, если с последним возникнут какие-либо проблемы.

Docker в банке. Видео с лекции Александра Тарасова из Альфа-Банка

В 18:00 многие ещё работают, а до места ещё добраться нужно.
Ну а если не смогли попасть — смотрите видео, а возникшие вопросы всегда можно задать докладчику.

Свой облачный хостинг за 5 минут. Часть 1: Ansible, Docker, Docker Swarm

У рядовых рабочих вопросов есть огромное количество нюансов, которые совсем не очевидны когда ты только начинаешь использовать Docker. Появление Machine, Swarm, Compose, Network, Orca, плагинов для Docker Engine обусловлено тем, что при использовании докера на реальных проектах существует масса проблем, особенно если ты переходишь к микросервисной архитектуре и количество контейнеров начинает расти.

Свой облачный хостинг за 5 минут. Часть 1: Ansible, Docker, Docker Swarm

Ну почему нет? У нас есть законченный пилотный проект. Конечно одним докером дело не заканчивается. Ещё как минимум нужна оркестрация (мы пока сидим целиком на ansible, но уже смотрим на kubernetes и иже с ним) и service discovery (используем consul). Сейчас докер пилит собственные решения, но судя по тому, что я видел (тот же swarm), они ещё достаточно сырые.

У меня пока нет статьи на эту тему, но есть слайды с выступления на ITGM.

Как я писал аудит запуска Docker-контейнеров на Go

Спасибо за замечание! Действительно, в самом верху описания есть не очень заметная ссылка на Dockerfile.

Как я писал аудит запуска Docker-контейнеров на Go

Machine нужен для быстрой конфигурации сервера (например, в облаке), на котором ты потом хочешь запускать контейнеры. Это другая задача, и, хотя сейчас там есть возможность получения информации по машине с помощью команды inspect, я не думаю, что в рамках этого проекта будут сделаны общие мониторинг и статистика.

Как я писал аудит запуска Docker-контейнеров на Go

Так устроен registrator, который имеет модульную структуру, и каждый модуль реализует этот интерфейс, потому как мастер-системы разные.