докер будет работать под kvm?

Да

Да

спасибо

@olegos76 в любом случае спс за ответы ?

?

я правильно понимаю, что проблема зомби всё еще реальна? и что сейчас есть флаг —init, который корректно проблему решает?

это я к тому, что dumb-init / tini можно не использовать, запуская контейнеры, которые могут генерировать зомби с флагом —init

и еще один вопрос очень часто в dockerfile добавлен gosu если я всё правильно понял, то он дает возможность динамически создавать пользователя с нужными uid/gid и от него запускать процессы? примерно таким скриптом #!/bin/sh USER_ID=${LOCAL_USER_ID:-1000} echo "Starting with UID : $USER_ID" addgroup -g $USER_ID group && adduser -u $USER_ID -D -G group user exec gosu user "$@"

подскажите, правильно ли я думаю?))

просто мне не удалось воспроизвести проблему вот отсюда: https://github.com/tianon/gosu#why для alpine, tty работает правильно

Всем привет. Есть вопрос. Есть кучка сервисов с прописанными healthcheck. Хочется уметь дожидаться пока все контейнеры из указанных в docker-compose.yml станут healthy. Есть что-то готовое на эту тему или свой велосипед делать?

а можно докер в lxc хостить?

можно

и докер в докер можно

у лкси есть профайл lxc.aa_profile = lxc-container-default-with-nesting

а дальше гуглить и тыкать

Всем привет. Есть вопрос. Есть кучка сервисов с прописанными healthcheck. Хочется уметь дожидаться пока все контейнеры из указанных в docker-compose.yml станут healthy. Есть что-то готовое на эту тему или свой велосипед делать?

V2.1 condition healty?

V2.1 condition healty?

У меня 3.1, а там его уже нет

Что мешает понизить?

Ничего. Как и написать скрипт. Вопрос был в наличие готового решения, для потеницально распространенной проблемы.

А смысл повышать версию и городить wait скрипты, если не используется swarm?

А смысл фиксироваться на конкретной версии, если мне нужно решение одной задачи, которое занимает 20 строк?

Смысл в том, что версия новее под другие задачи и если они не требуются, то смысл городить огород?)

всем привет! а подскажите, как грамотно реализовать такую идею: есть несколько вполне полноценных докерфайлов, которые надо разными способами компоновать. наследованием это не решается ((( есть какой то способ инклюдов? ЗЫ: сборка идёт в гитлаб-си-ай

всем привет! а подскажите, как грамотно реализовать такую идею: есть несколько вполне полноценных докерфайлов, которые надо разными способами компоновать. наследованием это не решается ((( есть какой то способ инклюдов? ЗЫ: сборка идёт в гитлаб-си-ай

может через docker-compose build?

может через docker-compose build?

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

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

использую его на локальных окружениях разработчиков, в docker-compose файле описываю зависимости (некоторые образы нужно собирать с разными флагами, например с именем хоста). Примерно так: https://pastebin.com/vXTu06Pa Команду по сборке запихнул в Makefile: ... dc-build: ## Сборка docker-образов согласно инструкциям из docker-compose.yml docker-compose build ... Разработчику достаточно запускить на своей машине make dc-build

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

Чтобы использовать docker-compose в гитлаб-си-ай (если у вас тип раннера докер) то возможно придется пересобрать базовый контейнер... У меня например весь CI выполняется в контейнерах: image: registry.gitlab.lc:5000/develop/ed/tmaier-dc-ssh:latest services: - registry.gitlab.lc:5000/develop/ed/my-docker-dind:latest ....

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

собственно в контейнере tmaier-dc-ssh:latest и есть установленный docker-compose + ssh, которые мне нужны были

ага... спасибо! а "context: ./workspace" - это, собственно, там он ищет докерфайл? а если они у меня в разных проектах находятся?

ага... спасибо! а "context: ./workspace" - это, собственно, там он ищет докерфайл? а если они у меня в разных проектах находятся?

да, контекст это где докерфайл лежит а как быть с разными проектами - тут уж я вам не подскажу, не сталкивался - у меня все в одном месте... У себя, например, я в основном проекте создал папку docker, а внутри нее еще штук 15 каталогов для каждого нужного контейнера и внутрь сложил докерфайлы + зависимости: http://joxi.ru/L214d0VH6zYx9m

понятно)) спасибо!

понятно)) спасибо!

пожалуйста, рад помочь)

Есть такой вопрос МОжно ли посмотреть логи сети сворма?

Суть - у нас есть туча нод (8-10 шт) все в сворме весь этот рой развёрнут в облаке Есть один внешний IP адрес Мы порт к бд прокидываем В логах базы у нас подключение только с внутреннего адреса docker-сети

Хочется узнать, какой реальный был адрес

Есть у кого-нибудь мысли, как это можно сделать?

#note оставлю чтобы вернуться к сообщению, интересен тоже ответ

можно

спасибо

Суть - у нас есть туча нод (8-10 шт) все в сворме весь этот рой развёрнут в облаке Есть один внешний IP адрес Мы порт к бд прокидываем В логах базы у нас подключение только с внутреннего адреса docker-сети

> логах базы у нас подключение только с внутреннего адреса docker-сети адрес тот один и тот же? т.е это прокси? может стоит там смотреть?

Адрес да, один и тот же так вот как мне показалось - в роли проксятника сворм

Если же это не докер такой адрес присваивает - то это у облака NAT так настроен, что вся внешка с одного адреса прилетает

А знает кто, какой смысл в VOLUME директивах в Dockerfile'ах? Просто если изображение собранное с такой директивой назапускать несколько раз, то докер просто создаст несколько локальных volume'ов с длинными хешами вместо имен. Т.е. эти volume'ы никак не шейрятся между контейнерами этого изображения, а просто создаются заново.

изображение?

охладите трахание ?

А знает кто, какой смысл в VOLUME директивах в Dockerfile'ах? Просто если изображение собранное с такой директивой назапускать несколько раз, то докер просто создаст несколько локальных volume'ов с длинными хешами вместо имен. Т.е. эти volume'ы никак не шейрятся между контейнерами этого изображения, а просто создаются заново.

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

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

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

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

Volume from можно делать

а, точно же! тогда да, есть смысл. я просто был под впечатлением, что volume описаный в Dockerfile'е шейрится на все контейнеры образа, но как оказалось нет. ну ладно, и так нормально, спасибо :)

ну в целом, идея в том, чтоб персистентные какие-то вещи выделять в volume

а кто нибудь юзает номад в ec2? не сталкивался ли с проблемой когда прибил номад клиент на 2й сетевой интерфейс network_interface = eth1, а после запуска таски он все равно сабака на eth0 его привязывает. При этом отдельно докер нормально контейнеры запускает на отдельных интерфейсах.

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

Если имя останется то же, то вроде сохранится

А знает кто, какой смысл в VOLUME директивах в Dockerfile'ах? Просто если изображение собранное с такой директивой назапускать несколько раз, то докер просто создаст несколько локальных volume'ов с длинными хешами вместо имен. Т.е. эти volume'ы никак не шейрятся между контейнерами этого изображения, а просто создаются заново.

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

т.к мы тут не имеем дело со слоями

Если имя останется то же, то вроде сохранится

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

может кому приходилось graylog сетапить?

может кому приходилось graylog сетапить?

Так есть же elk который неплохо работает с gelf драйвером, зачем graylog?

ERROR: S client not available

может кому приходилось graylog сетапить?

приходилось, делал так https://pastebin.com/Sht0QBr1

парни, подскажите

как правильно пушить ебаный образ в ебаный репозиторий

если ебаный образ уже залит до этого был

А был залит ёбано или не ёбано?

хуй знает, давно было

я его вроде заливаю

но когда делаю docker-compose pull

он за секунду все обновляет

что просто невозможно

потому что заливается 130 метров

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

docker push и docker-compose pull на двух разных хостах?

одын

так он у тебя локально уже есть

ты ж его пушил

лол

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

он че упоротый

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

бля

прибей у себя все образы

сделай пулл

или на другой машине попробуй

вас понял

принято

Кто знает, можно ли как-то управлять порядком деплоя/обновления сервисов при использовании docker stack deploy ? нужен эдакий аналог "depends_on"...

С таким вопросами надо на йобаном

)