А есть какой-то актуальный гайд для настройки wildcard ssl? А то куча старых гайдов для старой версии, где нет wildcard

О, вот тут я где-то ныл

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

но я не агитирую, конечно

Ну от вайлдкарда нет смысла, когда тебе серты генерятся автоматом

вот как-то да. Træfik умеет всё сам

+ один и тот же вайлдкард будет генериться на разных хостах и вероятность блока выше

а не возникнет проблем с a.b.c.d.domain.com?

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

Вот этого не знал, посмотрю обязательно

а не возникнет проблем с a.b.c.d.domain.com?

Вот как раз с вайлкардом только и возникнет

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

хочу ЕЛК стек вынести в отдельный композ, чтобы запускать его первым, перед запуском основного композа с сервисами.

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

Да, можно

external: true

@hitmaker есть подозрения, что у неё плохо с докером ?

@hitmaker есть подозрения, что у неё плохо с докером ?

Мы отправили её (или его) на курсы повышения квалификации :)

Мы отправили её (или его) на курсы повышения квалификации :)

был бы у меня такой "докер", я бы вообще в IT не любил бы ?

Ребят, а в одном докер-компоузе для myql-имиджа можно как-то несколько баз создавать? Сейчас у меня костыль - прокидывается sql-файлик в /docker-entrypoint-initdb.d, где уже «create database if not exist» делается

Ребят, а в одном докер-компоузе для myql-имиджа можно как-то несколько баз создавать? Сейчас у меня костыль - прокидывается sql-файлик в /docker-entrypoint-initdb.d, где уже «create database if not exist» делается

это не костыль, что не так? но лучше наверное под каждую бд свой контейнер.

я бы тоже под каждую своё сделал

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

это не костыль, что не так? но лучше наверное под каждую бд свой контейнер.

Просто сейчас есть кучка микросервисов и в облаке у них крутятся отдельные базы в инстансе cloudSQL, сейчас разрабам нужно локально покрутить и вот совсем не хочется под каждый микросервис делать столько же контейнеров с базами =(

Господа, у docker service update ключ --args - это аргументы, которые будут переданы в entrypoint? То есть, если по аналогии, то то, что в конце вызова команд типа docker run, docker service create после имени образа?

Args у билда только

Env тебе нужен

Args у билда только

https://docs.docker.com/engine/reference/commandline/service_update/#usage ?

а блин, затупил)) да, это аргументы для —command

Я не про --build-arg же.

не для энтрипоинта, а для комманд

Хм. А у меня, вроде, к энтрипоинту применилось тоже.

Там вот такое: ENTRYPOINT ["/usr/local/bin/php", "/app/bin/worker"] CMD [] И, насколько я понял, то, что я передал в --args передалось как нужно и стало аргументом воркера.

извиняюсь за тупой вопрос, но как правильно обратится из контейнера к хосту по сети?

извиняюсь за тупой вопрос, но как правильно обратится из контейнера к хосту по сети?

по айпишнику хоста

а универсального решения нет? ип то может менятся, хостнейм тоже

запусти контейнер с --net=host и ходи на 127.0.0.1

Мне нужно послать письмо арендодателю. Имя и фамилия могут поменяться. Адрес тоже. Хочу универсальный способ.

тогда я наружу все порты контейнера выставлю, разве нет?

да

а нет ли какого нибудь зарезервированного хостнейма в докере, чтоб резолвился в хост систему?

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

а нет ли какого нибудь зарезервированного хостнейма в докере, чтоб резолвился в хост систему?

host.docker.internal

Либо я не понял вопрос

Спасибо, вроде то, завтра попробую

это только в маргинальных docker-for-mac и docker-for-windows

в кубере, в обычном докере, в сворме - нет такого

https://github.com/docker/for-linux/issues/264

Там вот такое: ENTRYPOINT ["/usr/local/bin/php", "/app/bin/worker"] CMD [] И, насколько я понял, то, что я передал в --args передалось как нужно и стало аргументом воркера.

так commands "добавляется" к entrypoint, вот оно и сработало

так commands "добавляется" к entrypoint, вот оно и сработало

Ну. Мне это и нужно было.

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

ну только если у тебя CMD будет не пустым, то будет другой результат

Я понимаю.

Хотя не до конца. А каким он будет, если CMD будет не пустым? CMD заменит entrypoint ведь?

Фу, стоп. --args заменит CMD, да?

ентрипоинт не заменяется кмд заменяется

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

Фу, стоп. --args заменит CMD, да?

Никто ничего не заменяет

"Складывается", ну в доке есть инфа

Никто ничего не заменяет

Ну, то есть, я выше верно написал. --args заменит то, что было указано в CMD в докерфайле. Либо то, что было указано последним аргументом при создании сервиса. Ок, понял, спасибо.

Нет, не понял)

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

То есть, изначально получается набор для запуска вида ENTRYPOINT + CMD. Если указать последним аргументом docker service create ... some-command, то будет ENTRYPOINT + some-command. А если при обновлении указать docker service update --args some-command2, то будет ENTRYPOINT+some-command2

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

Я переопределение назвал заменой. В данном контексте это не сильно меняет смысл.

Аргументы добавляются к command

А не заменяют.

А комманд к энтрипойнту

Ок, понял. А команду при запуске сервиса или при обновлении переопределить нельзя, я так понимаю? по крайней мере, аргумента для этого не вижу пока.

Можно

Как?

Как при создании - понятно. Как при обновлении?

https://docs.docker.com/engine/reference/commandline/service_update/ Вот тут не вижу про команду.

Видать при обновлении нет) я особо руками не создаю сервисы, нах надо

Описываешь всё в манифесте и эпплай

Видать при обновлении нет) я особо руками не создаю сервисы, нах надо

Кстати, а можешь посоветовать почитать про хорошие практики по управлению Swarm и его сервисами?

Не уверен, не подскажу

Devops toolkit разве что, но я больше по докам/гитхабу руку набивал

Ну я просто пока руками в CLI создаю сервисы. Но я так понял, что можно и из docker-compose.yml, и из конфигов (те, что в docker service inspect), по идее. Вот хочу посмотреть какие практики есть, т.к. мы сейчас на микросервисы переезжаем и мне как раз надо разобраться с тем, как лучше всего это дело огранизовать чтобы потом минимум боли было.

Я только из ямлов разворачиваю, да не только я, оно так устроенно

Вот надо почитать как это лучше делать потому, что очевидно, что работа руками - это не то, как оно должно работать когда будет в продакшене :)

кто использует coreos?

Вот надо почитать как это лучше делать потому, что очевидно, что работа руками - это не то, как оно должно работать когда будет в продакшене :)

Так композом не пользовался что-ли?

Так композом не пользовался что-ли?

Пользовался. Но всегда воспринимал его как средство для оркестрации стека. А у нас большая пачка маленьких сервисов, которые независимы друг от друга. Впрочем я их с помощью compose как минимум в группы собирать планирую, т.к. они по внешним источникам данных различаются.

Просто вдруг над compose ещё какой-то уровень абстракции по-хорошему нужен.