крон не умеет в зависимости

крон не умеет шедюлить чаще, чем раз в минуту

этого достаточно?

Ну нам не нужны зависимости, и не надо чаще раза в минуту

Как видишь все индивидуально )

несомненно

Ну т.е. впринципе через маунт должно нормально прицепиться?

Если кому интересно, то заработало вот так: tmpfs: - /path/to/folder:size=512M,rw,nosuid,nodev,relatime,mode=1777

Если кому интересно, то заработало вот так: tmpfs: - /path/to/folder:size=512M,rw,nosuid,nodev,relatime,mode=1777

?

подскажите плиз в чем трабла поднимаю контейнер для статы nginxa docker run -p 9113:9113 fish/nginx-exporter -nginx.scrape_uri=http://x.x.x.x/nginx_status стату отдает, все хорошо, но когда запускаю его в compose то почему-то данные он хочет брать из локали compose nginx_exporter: image: fish/nginx-exporter container_name: nginx-exporter ports: - '9113:9113' command: - 'nginx.scrape_uri=http://x.x.x.x/nginx_status' Пробовал compose 3 / 3.1 / 2 Как будто он не понимают мой аргумент, хоть проверил через inspect и он там есть.

подскажите плиз в чем трабла поднимаю контейнер для статы nginxa docker run -p 9113:9113 fish/nginx-exporter -nginx.scrape_uri=http://x.x.x.x/nginx_status стату отдает, все хорошо, но когда запускаю его в compose то почему-то данные он хочет брать из локали compose nginx_exporter: image: fish/nginx-exporter container_name: nginx-exporter ports: - '9113:9113' command: - 'nginx.scrape_uri=http://x.x.x.x/nginx_status' Пробовал compose 3 / 3.1 / 2 Как будто он не понимают мой аргумент, хоть проверил через inspect и он там есть.

Что значит локаль компоуз?

Что значит локаль компоуз?

вот ошибка ``` time="2019-06-17T14:27:08Z" level=error msg="Error scraping nginx: Error scraping nginx: Get http://localhost/nginx_status: dial tcp 127.0.0.1:80: getsockopt: connection refused" source="nginx_exporter.go:170" ``` В ней видно что http://localhost/nginx_status

подскажите плиз в чем трабла поднимаю контейнер для статы nginxa docker run -p 9113:9113 fish/nginx-exporter -nginx.scrape_uri=http://x.x.x.x/nginx_status стату отдает, все хорошо, но когда запускаю его в compose то почему-то данные он хочет брать из локали compose nginx_exporter: image: fish/nginx-exporter container_name: nginx-exporter ports: - '9113:9113' command: - 'nginx.scrape_uri=http://x.x.x.x/nginx_status' Пробовал compose 3 / 3.1 / 2 Как будто он не понимают мой аргумент, хоть проверил через inspect и он там есть.

entrypoint vs cmd, sh vs [....]

https://m.habr.com/ru/company/southbridge/blog/329138/

Кто нибудь здесь слышал о каком нибудь боте для интеграции между гитхабом/гитлабом и джирой? Например для автоматического проставления версий, закрытия тасок, и так далее

https://docs.gitlab.com/ee/user/project/integrations/jira.html оф.дока гитлаба по интеграции с джирой

Кто нибудь здесь слышал о каком нибудь боте для интеграции между гитхабом/гитлабом и джирой? Например для автоматического проставления версий, закрытия тасок, и так далее

А причем тут докер ?

@ru_gitlab

Кто нибудь здесь слышал о каком нибудь боте для интеграции между гитхабом/гитлабом и джирой? Например для автоматического проставления версий, закрытия тасок, и так далее

гитлаб из коробки предоставляет интеграцию с жирой

Товарищи, скажите, пожалуйста, а команда docker commit коммитит то, что есть в Волюмах, автоматически генерированных? https://docs.docker.com/engine/reference/commandline/save/ тут пишут, что в имидж не попадает то, что во внешних прокинутых волюмах, но относится ли это к волюму автоматически созданному докером, когда я делаю docker run без Указания какого-то волюма?

Товарищи, скажите, пожалуйста, а команда docker commit коммитит то, что есть в Волюмах, автоматически генерированных? https://docs.docker.com/engine/reference/commandline/save/ тут пишут, что в имидж не попадает то, что во внешних прокинутых волюмах, но относится ли это к волюму автоматически созданному докером, когда я делаю docker run без Указания какого-то волюма?

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

т.е. он в образ не закоммитится (очевидно)

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

ну, как бы логично

а зачем тебе ?

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

ну, как бы логично

Ну у меня есть разрабы, которые над жирой что-то там пишут. И нужен образ, в котором уже настреон проект, есть некоторые юзеры, плагины, бизнес-процессы, вот это все. А это все кроме внутренней базы данных, еще и в файлах в волюме лежит. То есть скриптами в докер-файле всю хрень не прописать, а надо руками протыкать и настроить.

ну, т.е. это типа фикстуры получается?

ну, я повторюсь - наполняй вольюм при старте контейнера

либо ты идешь в направлении полностью своего образа

это не сложно

ну, т.е. это типа фикстуры получается?

Ну что-то вроде того. На совсем понимаю, про наполнение волюма при старте контейнера. Я не вижу пути аавтоматизировать это кроме как распространять образ с архивом волюма и перед стартом контейнера разархивировать архив волюма в /var/lib/docker.

Ну что-то вроде того. На совсем понимаю, про наполнение волюма при старте контейнера. Я не вижу пути аавтоматизировать это кроме как распространять образ с архивом волюма и перед стартом контейнера разархивировать архив волюма в /var/lib/docker.

Нет

Просто ты делаешь стартовый скрипт внутри контейнера

В нем условный cp /home/fixture /path_to_where_volume_mounted

Посмотри на контейнер с постгресом - как он бд инициализирует

Блин, точно, есть же add. Точно!

Просто ты делаешь стартовый скрипт внутри контейнера

Спасибо! ЧТо-то недодуплил

Блин, точно, есть же add. Точно!

Адд в докерфайле немного не то, ну, да ладно

какой сигнал посылает docker приложению при обновлении сервиса? kill -9?

какой сигнал посылает docker приложению при обновлении сервиса? kill -9?

Два

Сначала term потом kill

Или наоборот

Не помню

а както изменить можно?

из оркестратора, или мб в докер-композе

что изменить?

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

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

нет, никак

Доброе утро всем! Какое-то жутко аномальное поведение наблюдаю в последние несколько дней с кластером Swarm. Было 3 менеджер ноды, столько-же слейвов, все прекрасно работало, репликация несколько раз отрабатывала и сама переезжала на другого менеджера, когда отваливался Leader. Но потом, сервисы начали хуевничать и ничего не оставалось как плавно ребутать ноды, так как другого способа решить возникшую проблему не было. Речь о 2менеджер нодах и 1 слеве, начал постепенно ребутать их, сначала слев, потом менеджера который в Reacheble, дождался пока все поднимется, проверил доступность, статус кластера, развртку и все было ок, затем начал ребутать Leader ноду и она просто сдохла, после того как я смог получить доступ к терминалу, она волялась в режиме восстановления, который просто тупо не отрабатывал, прошерстив журналы, единственное что могло быть не так - это ошибка GlusterFS, но он был примонтирован в отдельный каталог, не содержал ни системных файлов, ни сервисов, ничего критичного, что могло повлиять на систему, только volumes контейнеров лежали на нём. Нода так и не поднялась, никакие танцы с бубнами не помогли, загружать пробовал с разными версиями ядра, все бестолку. После этого я обнаружил, что автоматической репликации не произошло, я залез на второго менеджера docker node ls выдавал ошибку, кластер не собирался и предлагал подождать пока появится Leader. В ребутнул docker.service и при помощи docker swarm init --force-new-cluster оживил свой кластер. Но жить с 2-мя менеджерами совсем не дело, поэтому я хотел назначить 3-го, делаю ещё одну ноду, уже новую, на ней закидываю запрос на Leader на прецепление нового managera и тут кластер рассыпается снова, не могу посмотреть статус нод, ничего. Ребутаться я сразу не стал и попробовал перезапустить docker.service, все повисло, весело минут 5, без результатов, отменяю ещё пару попыток, причем тоже самое поведенеи и на новом managere, все команды работают, нагрузке на сервере никакой, но вот docker.service никак не ребутается, не останавливается и не выдаёт ошибок, просто висит. Ну я взял и ребутнул этого Leadera и конечно-же он повторил учесть 1-го своего собрата, а тот новый manager так и весит. Помогите чем сможете пожалуйста, вдруг кто-то сталкивался с похожим поведением, или может у кого есть мысли какие по этому поводу, в идеале хочется избежать этого в будущем.

https://docs.docker.com/engine/reference/commandline/stop/

The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.

Доброе утро всем! Какое-то жутко аномальное поведение наблюдаю в последние несколько дней с кластером Swarm. Было 3 менеджер ноды, столько-же слейвов, все прекрасно работало, репликация несколько раз отрабатывала и сама переезжала на другого менеджера, когда отваливался Leader. Но потом, сервисы начали хуевничать и ничего не оставалось как плавно ребутать ноды, так как другого способа решить возникшую проблему не было. Речь о 2менеджер нодах и 1 слеве, начал постепенно ребутать их, сначала слев, потом менеджера который в Reacheble, дождался пока все поднимется, проверил доступность, статус кластера, развртку и все было ок, затем начал ребутать Leader ноду и она просто сдохла, после того как я смог получить доступ к терминалу, она волялась в режиме восстановления, который просто тупо не отрабатывал, прошерстив журналы, единственное что могло быть не так - это ошибка GlusterFS, но он был примонтирован в отдельный каталог, не содержал ни системных файлов, ни сервисов, ничего критичного, что могло повлиять на систему, только volumes контейнеров лежали на нём. Нода так и не поднялась, никакие танцы с бубнами не помогли, загружать пробовал с разными версиями ядра, все бестолку. После этого я обнаружил, что автоматической репликации не произошло, я залез на второго менеджера docker node ls выдавал ошибку, кластер не собирался и предлагал подождать пока появится Leader. В ребутнул docker.service и при помощи docker swarm init --force-new-cluster оживил свой кластер. Но жить с 2-мя менеджерами совсем не дело, поэтому я хотел назначить 3-го, делаю ещё одну ноду, уже новую, на ней закидываю запрос на Leader на прецепление нового managera и тут кластер рассыпается снова, не могу посмотреть статус нод, ничего. Ребутаться я сразу не стал и попробовал перезапустить docker.service, все повисло, весело минут 5, без результатов, отменяю ещё пару попыток, причем тоже самое поведенеи и на новом managere, все команды работают, нагрузке на сервере никакой, но вот docker.service никак не ребутается, не останавливается и не выдаёт ошибок, просто висит. Ну я взял и ребутнул этого Leadera и конечно-же он повторил учесть 1-го своего собрата, а тот новый manager так и весит. Помогите чем сможете пожалуйста, вдруг кто-то сталкивался с похожим поведением, или может у кого есть мысли какие по этому поводу, в идеале хочется избежать этого в будущем.

tl;dr, сорри

https://stackoverflow.com/questions/50898134/what-does-docker-stopsignal-do

есть еще такая ботва, но я ее не юзал

@Ozyab

Сори, что так длинно, короче не описать никак(

есть еще такая ботва, но я ее не юзал

ок, посмотрю-попробую ?

Доброе утро всем! Какое-то жутко аномальное поведение наблюдаю в последние несколько дней с кластером Swarm. Было 3 менеджер ноды, столько-же слейвов, все прекрасно работало, репликация несколько раз отрабатывала и сама переезжала на другого менеджера, когда отваливался Leader. Но потом, сервисы начали хуевничать и ничего не оставалось как плавно ребутать ноды, так как другого способа решить возникшую проблему не было. Речь о 2менеджер нодах и 1 слеве, начал постепенно ребутать их, сначала слев, потом менеджера который в Reacheble, дождался пока все поднимется, проверил доступность, статус кластера, развртку и все было ок, затем начал ребутать Leader ноду и она просто сдохла, после того как я смог получить доступ к терминалу, она волялась в режиме восстановления, который просто тупо не отрабатывал, прошерстив журналы, единственное что могло быть не так - это ошибка GlusterFS, но он был примонтирован в отдельный каталог, не содержал ни системных файлов, ни сервисов, ничего критичного, что могло повлиять на систему, только volumes контейнеров лежали на нём. Нода так и не поднялась, никакие танцы с бубнами не помогли, загружать пробовал с разными версиями ядра, все бестолку. После этого я обнаружил, что автоматической репликации не произошло, я залез на второго менеджера docker node ls выдавал ошибку, кластер не собирался и предлагал подождать пока появится Leader. В ребутнул docker.service и при помощи docker swarm init --force-new-cluster оживил свой кластер. Но жить с 2-мя менеджерами совсем не дело, поэтому я хотел назначить 3-го, делаю ещё одну ноду, уже новую, на ней закидываю запрос на Leader на прецепление нового managera и тут кластер рассыпается снова, не могу посмотреть статус нод, ничего. Ребутаться я сразу не стал и попробовал перезапустить docker.service, все повисло, весело минут 5, без результатов, отменяю ещё пару попыток, причем тоже самое поведенеи и на новом managere, все команды работают, нагрузке на сервере никакой, но вот docker.service никак не ребутается, не останавливается и не выдаёт ошибок, просто висит. Ну я взял и ребутнул этого Leadera и конечно-же он повторил учесть 1-го своего собрата, а тот новый manager так и весит. Помогите чем сможете пожалуйста, вдруг кто-то сталкивался с похожим поведением, или может у кого есть мысли какие по этому поводу, в идеале хочется избежать этого в будущем.

так

это в облаке или на баре метал?

Господа, приветствую! Поскажите плз бест-практис работы с файрволом. Сервисы поднимаются docker-compose. Вопрос в ограничении доступа к сервисам только с определенных IP. Как такие задачи решаются? Что то ничего из коробки не нагуглилось.. Делать извращения типа комментов напротив ports в docker-compose.yml, который парсить и создавать правила в DOCKER-USER?

ооооо

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

кратко - проще всего все сувать в хост нетворк моде.

как бонус - у тебя летенси по сети становится внятный

спасибо за подсказку, лейтенси надо будет потестить, не думал что ощутимая разница..

это в облаке или на баре метал?

Нет не в облаке

Нет не в облаке

больше про ноды расскажи

спасибо за подсказку, лейтенси надо будет потестить, не думал что ощутимая разница..

так вот

хост моде - и ты можешь управлять файрволлом нормально. Вешаешь условный сервис на порт 8000 и ты в iptables можешь легко настроить правила. Это тебе не DOCKER-USER цепочку насиловать

что еще сказать... теоретически ты можешь публиковать все сервисы внутри бриджей, а снаружи ходить в какой-нибудь traefik/nginx, которым все закрыто, но в операционном разрезе это сложно, т.е. дорого и ведет к ошибкам конфигурации

больше про ноды расскажи

Всего 6 нод, 3 из них Manager, 3 Slave, по ресурсам все с запасом, на вырост, почти все контейнеры которые на них крутились были жестко ограниченны по рессурсам и жестко раскатываолись на заданных нодах. Отдельно на всех нодах был поднят GlusterFS для того, чтобы хранить на нем Volume самих контейеров и иметь доступ к ним со всех нод, он монтировался в /opt и хранил там непорсредственно volumes, развертка через модуль GlusterFS не увенчалась успехом, поэтому лежали они там через mount points. Что ещё нужно по нодам предоставить из инфы?

Да вроде никакого криминала

Да вроде никакого криминала

Криминала не было, по сетям тоже. Все разврнуто локально почти, внутри закрытого периметра

Также на slave нодах docker.service свалился в deactivating, ошибка подключения к Swarm

Также на slave нодах docker.service свалился в deactivating, ошибка подключения к Swarm

Нет идей

2 Leader вешел из ребута, спустя полтора часа, но Swarm рассыпался, сейчас повторно перепнул его, но на Slave нодах deactivate сервиса, не хочет сервис перезагружать