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

Где можно посмотреть production ready docker stack compose файлы для обучения?

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

Друзья, если есть кто из московского ланита - вашу маршрутку эвакуируют от м Рижская

Ребята, что используете для nginx + letsencrypt?

certbot

через docker logs смотри, а так /var/lib/docker/container/xxxxx/ для каждого контейнера

в логах контейнера все норм. если чтото и падает то до контейнера не доходит дело

проблема только после рестарта виртуалки?

Ребята, что используете для nginx + letsencrypt?

Вкратце 2 вольюма - для ключей и для http верификации.

Спрошу еще раз. Подскажите пожалуйста в docker swarm. Как можно сделать что запросы outbound (в интернет), шли с worker ip адреса если даже запрос идет с manager? Я с сетями на вы)

проблема только после рестарта виртуалки?

ну да

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

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

Подскажите, есть named volume от одного проекта, хочу заюзать его внутри docker-compose другого проекта. Пробовал делать через volumes: в корне но он создаёт новый. Что впринципе и понятно. В доке не нашёл нужной опции. Это возможно ?

Нужно переименовать, docker compose называет вольюмы project_volumename

Переименовать не очень просто, т.к. нативной команды нет.

https://github.com/moby/moby/issues/31154

Чтобы на остальные сервисы не влияло, вперед ставлю другой nginx который форвардит запросы куда нужно.

1.И получается на каждый сервис по одному nginx ? 2.Т.е. у меня сейчас 4 сервиса = 5 nginx контейнеров в итоге. Так все делают или есть еще способы ? 3. А если 2 сервиса API а остальные 2 это админки, то в любом случае нужно все 4 + 1 поднимать ?

Нет, я имел в виду 1 прокся + 1 статика.

Если не хочешь чтобы при обновлении статики остальные дергались

Т.е. для статики будет выделенный nginx, остальное как раньше будет.

Собственно nginx нужен для 1) SSL 2) Статики 3) Раскидывать запросы по остальным сервисам, возможно с балансировкой нагрузки.

Можно функцию 2 вынести на отдельный контейнер.

Нет, я имел в виду 1 прокся + 1 статика.

Правильно ли я понял ?

Я не совсем понял, сейчас app-ы свою статику сами отдают?

Тогда в этом случае, нужно чтобы статика из app1 и app2 монтировалась в volume, чтобы nginx знал, откуда тащить данные при сборке.

Статика она на то и статика, что не меняется. При сборке image-ов собирай всю статику в один контейнер.

Статика она на то и статика, что не меняется. При сборке image-ов собирай всю статику в один контейнер.

js, css тоже статика. Она внутри приложения находится же. Не будет же приложение отдавать их. Я вот эту задачу пытаюсь решить.

И потом изображения могут заливаться с App2 или App1 и тогда их нужно куда-то класть. Без volume не обойтись короче.

Ну если заливать, то да. А js/css можно при сборке контейнера брать. Обновил приложение - пересобрал контейнер.

Вот в этом случае проблема в том, что каждое приложение в gitlab создаётся по своему пайплайну. И получается, что в каждый пайплайн придётся добавить еще одну джобу, которая будет лезть в репозиторий каждого приложения чтобы достать оттуда данные для сборки нового контейнера nginx и пушить его на прод. Я просто незнаю насколько это будет правильно. Нужно как-то это все запихать в текущий workflow

В моем случае там 2 репо с админками.

А хранить все эти файлы в подключаемом volume для nginx плохая идея ? Там какой-то оверхед будет на доступ к ФС ?

Минимальный, не стоит даже на это обращать внимания

Идея норм если нужно разделяемые данные между контейнерами

Ток масштабировать не удобно

Мне кажется если нужны совсем разделямые данные, то лучше заюзать распределенные фс, все-таки волюмы не под это проектировались) А оверхед на фс минимальный в докере, вот замечательная pdf-ка, никто, кстати обновленную не встречал? https://arxiv.org/pdf/1709.10140.pdf

Идея норм если нужно разделяемые данные между контейнерами

А как насчёт варианта c использованием multi-stage билдов ?: На проде для nginx Dockerfile прописать: FROM app1 AS data1 FROM app2 AS data2 FROM nginx COPY --from=data1 /usr/src/app/public /data/ COPY --from=data2 /usr/src/app/public /data/ И получается что волюмы будут использоваться только для загружаемой статики из app1 или app2

А статика в виде js, css будет юзаться уже изнутри nginx

В принципе должно работать.

Всем привет! Создаю overlay сеть: docker network create —driver=overlay —attachable —subnet=10.0.1.0/28 —gateway=10.0.1.14 net1 Далее в логе при попытке старта контейнера с любым адресом из диапазона 10.0.1.1-10.0.1.8 (docker run -d —ip 10.0.1.1 —network net1 —name test01 imageName) с привязкой к данной сети наблюдаю странное: error="failed to allocate network IP for task to9p0clfwhtpe1ya7a0a1y7do network 1xg1jmizjpv3e9l6vuxjgwxxc: could not allocate IP from IPAM: Address already in use" При этом с адресом 10.0.1.9 и далее стартует нормально. Пробовал с разными сетями, масками и гейтвеями, везде одно и тоже, первые 8 адресов взять себе нельзя. В официальной документации и интернетах по этому поводу информации не нашел... Подскажите, эти адреса реально зарезевированы докером для неких внутренних нужд? Или я где-то ошибаюсь при настройке?

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

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

Народ, подскажите пожалуйста, для Ubuntu 16.04 (LTS) какой репозиторий с докером будет использовать каноничнее? dockerproject.org или download.docker.com? Также никак не могу определиться с драйвером хранения: aufs или overlay2 (или вообще devicemapper)

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

давайте еще бутерброт из 100 обстракций сделаем

Хорошего предложение, но опоздал: все уже сделано)

Коллеги. На следующей неделе к нам приедет Docker Captain Филип Эстес и согласился сделать доклад/презентацию про Istio. Так же будут выступать коллеги из Авито. Связаться с @DenisIzmaylov не получилось поэтому сделали отдельную группу. Аудитория не очень большая. Будем рады видеть всех. https://www.meetup.com/Enterprise-Containers/events/248693819/

Народ, подскажите пожалуйста, для Ubuntu 16.04 (LTS) какой репозиторий с докером будет использовать каноничнее? dockerproject.org или download.docker.com? Также никак не могу определиться с драйвером хранения: aufs или overlay2 (или вообще devicemapper)

тут и думать не нужно, только оверлей2

А версия самого докера?

давайте еще бутерброт из 100 обстракций сделаем

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

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

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

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

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

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

че за бред, чем прямая настройка ngnx хуже? тоже самое будет по сути

Тем, что nginx часто не один и не на одном сервере.

че за бред, чем прямая настройка ngnx хуже? тоже самое будет по сути

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

"Я могу так и без докера" или "я могу так и без образа" "я могу так без дополнительной роли" это не аргумент в пользу того, что %product_name% не нужен

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

слушайте, у них даже на оф сайте докер хабо, есть вариант со стандартным ngnx видимо востребованый всетаки способ

слушайте, у них даже на оф сайте докер хабо, есть вариант со стандартным ngnx видимо востребованый всетаки способ

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

ниче ты не объяснил, прогнал пургу и все

В каком месте конкретно пурга?

в том, что даже сам смысл этого контейнера не подразумевате проксирование всего. Таким образом, не понимая даже сути работы метода, мне объясняют про его приемущества

это сейчас на албанском было? про какой ты контейнер сейчас говоришь?

скинь ссылку

Как вы объясняли мне приемущества метода не зная про какой контейнер речь? https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion/ хотя продолжение разговора не требуется

Как вы объясняли мне приемущества метода не зная про какой контейнер речь? https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion/ хотя продолжение разговора не требуется

тут в названии есть слово companion, я тебе даже раскрою секрет, это подразумевает, что вместе с ним ты используешь https://github.com/jwilder/nginx-proxy цитирую "letsencrypt-nginx-proxy-companion is a lightweight companion container for the nginx-proxy. "

ниже почитай, там есть про вариант без прокси

в том, что даже сам смысл этого контейнера не подразумевате проксирование всего. Таким образом, не понимая даже сути работы метода, мне объясняют про его приемущества

смысл этого контейнера ПОДРАЗУМЕВАЕТ проксирование всего

смысл этого контейнера ПОДРАЗУМЕВАЕТ проксирование всего

ниже пролистай

ниже почитай, там есть про вариант без прокси

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

что тебе не понятно то осталось?

с тобой все понятно. Вопрос как сделать Х, ответ тебе не нужен Х использу Y с гонорм, как будто сам господь бог снизошол до ответа

ты НЕ прав, он(jwilder/nginx-proxy) ПОДРАЗУМЕВАЕТ проксирование всего, а jrcs/letsencrypt-nginx-proxy-companion создан как компаньён для него, когда у тебя сотни доменов, это УДОБНО

там ниже вариант для чистого контейнера ngnx

я не говорил используй то или это, я объяснил и разжевал зачем существует схема X

там ниже вариант для чистого контейнера ngnx

иииии что?

ничего, я спрашивал про второй вариант, зачем мне инфа про первый вообще?

nginx-proxy + letsencrypt-nginx-proxy-companion работают НЕ ТОЛКЬО если позади NGINX и любой другой APP

это верно

но вот как раз в случае если у тебя и так на фронте nginx тупо использовать еще и прокси на том же nginx