Возможно будет ещё интересна группа @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)

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

ERROR: S client not available

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

помню в одной из первых моих контор, перед деплоем дергали стресс тесты

тестировщики на других проектах вставали отделом и уходили пить кофе

потому что начинало а) тормозить, б) запускать зомби сжирающих всю память в) ловить рейс-кондишенс

простое предложение разнести дев, тест и стресс на три разных машинки было встречено "кабиной" вопросом а зачем нам тратить бабки

когда показали, что происходит на стресс-тесте, да, дали еще две машинки и работа пошла

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

и по нескольку раз, синдром пионера

спасибо за рекомендации, буду либо упрощать, либо разносить все это на разные физические машины

Такой вопрос, у меня есть три контейнера, к примеру frontend, backend, backend2. frontend запускает веб-сервер на порту 8080, и соответственно я открываю в браузере localhost:8080 и у меня открывается сайт, но некоторые запросы со страницы должны идти в контейнер backend, при этом контейнеры backend и backend2 посылают друг другу запросы. Так вот, как мне настроить нетворкинг так, чтобы подобная схема работала?

завести приватную и публичную сетку

есть туториал как такое оформить?

пройти в документацию по докеру, там описано

https://docs.docker.com/compose/networking/#links

иногда, чтобы понять вещь, надо просто прочитать мануал от корки до корки, понятно, нет времени, в этом случае работает вагрант как носимый image

спасибо, посмотрю

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

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

Парни. А что за ошибка ERROR: build path /opt/glpi/test/glpi:latest either does not exist, is not accessible, or is not a valid URL. Это при запуске docker-compos -f glpi.yml up -d

что в glpi.yml написано?

ставлю чай на то что перепутал ключ image с ключом build

glpi: build: test/glpi ports: - "8080:80"

блин

понял

все сори

исправил криво

идиот...(

А вообще есть какие то правильные правила оформления yml файла в плане пробелов?

я просто заметил что необходимо в некоторых местах ставить по 2, а в некоторых по 4 пробела

это норма?