И само собой не видит никаких пробросов

Книженцию свою открыл )

Короче, есть 4 варианта работы сети

И есть такой режим работы как host

В данном случае будет использоваться внешний ИП адрес хост машины для конкретного докера

В этом случае, я как понимаю всё заработает

Ну или можно дописать внутренний айпи адрес докер-сети хоста

Ооккей, спасибо, пошел копаться

через докеркомпоуз могу настроить?

Да, кажется могу

networks: code-network: driver: bridge

#whois Привет, занимаюсь разработкой одного проекта на ноде, который пока ещё не готов к релизу. Некоторое время занимался разработкой на питоне и перле. Достаточно близко знаком и с администрированием. Начал своё знакомство с докером относительно недавно. Базово умею писать свои докерфайлы и собирать контейнеры. Говорю всем, что умею читать документацию. Попеременно нахожусь в Санкт-Петербурге и Москве.

👍

#whois Привет, занимаюсь разработкой одного проекта на ноде, который пока ещё не готов к релизу. Некоторое время занимался разработкой на питоне и перле. Достаточно близко знаком и с администрированием. Начал своё знакомство с докером относительно недавно. Базово умею писать свои докерфайлы и собирать контейнеры. Говорю всем, что умею читать документацию. Попеременно нахожусь в Санкт-Петербурге и Москве.

Возможно будет ещё интересна группа @nodejs_ru, плюс ещё докладчика ищем )

Возможно будет ещё интересна группа @nodejs_ru, плюс ещё докладчика ищем )

О, когда митап? :)

Да хоть завтра :) Но как соберём ещё два хороших доклада

Да хоть завтра :) Но как соберём ещё два хороших доклада

Надо просто в Node.js запинить обьявление по поиску докладчиков.

Было :) на первое апреля отпинили прост

Возможно будет ещё интересна группа @nodejs_ru, плюс ещё докладчика ищем )

Спасибо. Но пока буду группы добавлять постепенно, иначе никакого времени работать не хватит 😊

Кто нибудь запускал докер на Андроиде?

О, извращения

Кто нибудь запускал докер на Андроиде?

Думаю изи

Кто нибудь запускал докер на Андроиде?

Не получится, фич ядра не хватает

Докер есть обертка над окружением

Не получится, фич ядра не хватает

Еще пишут что можно какой то плагин накатить, может кто пробовал

я накатил этот плагин на утюг, после этого он научился летать и прибился к косяку пролетающих мимо утюгов, вступивших в SpaceX

я накатил этот плагин на утюг, после этого он научился летать и прибился к косяку пролетающих мимо утюгов, вступивших в SpaceX

у меня кофеварка под докером, по контейнеру для разного вида кофе

Вроде баг на это был, что контейнер с молоком не всегда в одной сети

а кто-нибудь тут dcos юзает?

кстати про сети в докере. Все же знают про флажок для демона докера, при котором можно рестартить демон, не зависимо от контейнеров, то есть они продолжат работу Так вот, ктонибудь сталкивался что если через docker-compose задеплоить конфиг, а как известно докер композ создает под каждый свой проект сеть projectname_default в которую добавляет все контейнеры чтобы они видели себя, то вот когда демон рестартится то все контейнеры вылетают из этой сети, и в итоге нужно рестартить эти контейнеры, то есть рестартить можно без композа, рестарт контейнера приводит к его возврату в эту сеть. Есть ли адекватный способ удержать контейнеры в сети при рестрате демона в таком режиме?

Ребят, подскажите как верно настроить xdebug на машине с docker. Возмжно я где-то неверно просто рассуждаю. Есть контейнер с nginx (1). Есть контейнер с php-fpm (2). Настройки xdebug xdebug.remote_enable=on xdebug.remote_autostart=on xdebug.remote_connect_back=1 xdebug.xdebug.remote_port=9002 Запрос идет через проброс порта (docker ports) в контейнер nginx Оттуда идет в контейнер php через links по имени контейнера Получается, что xdebug модуль пытается отдать управление на порт 9002 в контейнер nginx А слушает 9002 IDE на хост системе моей (mac os) Пробовал пробросить порт 9002 c хост системы в nginx контейнер, но не работает (подозреваю, что проброс порта docker не позволяет больше никому слушать порт, хотя IDE не говорит, что порт занят)

там дело в том, что надо указывать адрес сервера

но делать это через широковещательный адрес

вот тут все работает https://joenyland.github.io/blog/debug-a-php-app-in-a-docker-container-using-xdebug/

спасибо

вот еще более детальное

https://gist.github.com/chadrien/c90927ec2d160ffea9c4

http://laradock.io/ можете еще подсмотреть как это реализовано в специализированной сборке для laravel проектов, там и дока есть и конфиги и может еще чего интересного для пхп найдете

ларадок слегка небестпрактисес

а набор костылей

есть в нем такое, но с последнего раза когда я туда заглядывал там многое улучшили

ага, спасибо, за ссылки, посомтрю как они конфигурировали

FROM mailhog/mailhog Maintainer Mahmoud Zalt <mahmoud@zalt.me> CMD ["Mailhog"] EXPOSE 1025 8025

наверное поэтому.

меня смутило наличие args

когда используется env

эт как купить самолет, но поехать поездом

докер-компоуз по дефолту хватает .env файл из корня

почему бы этим не пользоваться и пробросить только определенные ключи в сервисы через environment:

докер-компоуз по дефолту хватает .env файл из корня

о я не знал ) надо попробывать

ларавел кстати тоже умеет .env файл из корня читать, занимательно что они этим действительно не пользуются, все в .env прописал что меняется и радуешься жизни

Всем привет! Ребят, подскажите, как правильно поднять несколько окружений на одной хост-машине? Например, есть несколько docker-compose файлов (для develop.lc, testing.lc и staging.lc). В файлах перечислены необходимые сервисы (контейнеры с кодом + nginx + php-fpm + redis + memcached) Когда я запускаю одну их таких связок командой docker-compose -f docker-compose-staging.yml up -d то вторую связку запустить уже не получается (что ожидаемо): ERROR: for nginx Cannot start service nginx: driver failed ....: Error starting userland proxy: listen tcp 0.0.0.0:443: bind: address already in use как выйти из данной ситуации? использовать нестандартные порты?

не пробрасывать порты на хост машину

или пробрасывать на разные порты

web: env_file: - web-variables.env

если цель - стейджинг ради стейджинга - можно и заморочиться

но в целом обычно это задача CI переключать стейджи и чекать работоспособность

разница между продом, девом и тестом только в переменных окружения

не пробрасывать порты на хост машину

простите, а как тогда попасть на сайт в браузере? по ip-докер контейнера? или тут без consul не обойтись? или перед всеми связками ставить еще один контейнер с nginx-proxy?

разница между продом, девом и тестом только в переменных окружения

так и есть, + на деве еще запускается пару контейнеров с композером и npm

если все это надо на одной машине с достпуом из вне, да, ставь реверс прокси

смысл докера в изоляции контейнеров

если стартанул дев стейдж - оно просто подняло сеть, внутри него сервисы и пробежалось

если все стейджи нужны одновременно - обычно докер тут не причем, проблема в кабине

просто у нас например develop конфиг юзается только разрабами локально, testing конфиг юзается только jenkins’om и как бы там не нужен доступ из вне, он внутри в докер сети все поднял, протестил, вырубил. А для staging отдельный сервер. Но на staging’e там несколько проектов и они разруливаются nginx’om.

для этих целей именитые вагрантологи строят свои солюшены с солью и/или шефом

вопрос в понимании контекста

дев стейдж - машина разработчика

тест - отдельный хост в закрытой сети

прод - сервер в дмз

вопрос в понимании сетей я бы сказал ) можно и все на одной тачке поднять изолировано и научить докер композ соединять это в одну сеть

это три разные машины, для которых указывается разная цель сборки, основанная на стейдже

если у вас отличается прод и дев - эт обычно пахнет отладкой

разница должна быть только в скейле, но не в наборе сервисов

app: image: node:6 restart: always networks: staging: aliases: - projectname-staging default: aliases: - app композ вот так умеет, он может конкетить контейнер не только в дефолтную сеть но и к соседней существующей, у нас все app контейнеры под своим уникальным именем конектятся к сети стейдж машины, в которой поднят nginx который уже смотрит на внешку и реверсит на эти контейнеры запросы.

получается что на ружу только nginx контейнер смотрит, а все остальные изолированы

это означает что нет изоляции, и вы не отловите баги на смене версий

просто у нас например develop конфиг юзается только разрабами локально, testing конфиг юзается только jenkins’om и как бы там не нужен доступ из вне, он внутри в докер сети все поднял, протестил, вырубил. А для staging отдельный сервер. Но на staging’e там несколько проектов и они разруливаются nginx’om.

у нас тоже девелоп юзается локально на машинах разработчиков, однако еще есть на отдельном сервере (!) dev окружение, которое используется QA при тестировании после тестирования на отдельном dev окружении приложение тестируется на staging. (Разница между dev и staging только в зависимостях из composer.json и package.json, на стейдж устанавливаем с ключами --no-dev и --production)

а теперь возникла все эти "окружения" поднять на одном физическом хосте

скорее действительно "проблема в кабине" ((((