Блин не успел

Ок спасибо думал узнаю что то новое

А что новое то?

я не оч понял что ты хочешь узнать

Привет. Может быть кто подскажет по Kubernetes вариант решения следующей задачи: есть бесконечно пополняемая очередь (work queue в терминологии k8s), например RabbitMQ. Необходимо сделать параллельные консьюмеры, которые бы обрабатывали эту очередь постоянно (не одноразовые джобы). Ньюанс в том, что для предотвращения утечки памяти, консьюмеры принято (например в PHP) перезапускать через некоторе время или некоторое количество обработанных сообщений. Вопрос, как это ложится на Job абстракцию k8s? Там есть только restart: OnFailure | Never, а перезапуск имеет Success код (т.е. k8s не перезапустит такой Job) или может впринципе тут подход с Job неверный? И надо использовать нечто другое

можно просто не использовать php

PHP тут как пример, это может быть любой другой ЯП

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

вам повезло :) продолжаю изучение вопроса - судя по всему вместо Job надо использовать https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/ - ReplicationController, который даже в случае успешного завершения контейнера будет его перезапускать, держа постоянно N реплик

deployment с обработчиками и не периться

сдохнет - куб его переподымет

вам повезло :) продолжаю изучение вопроса - судя по всему вместо Job надо использовать https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/ - ReplicationController, который даже в случае успешного завершения контейнера будет его перезапускать, держа постоянно N реплик

RC в сыром виде лучше не использовать, лучше пусть с ним deployment работает

спасибо за совет

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

спасибо за совет

deployment управляет rc (на этом так же реализован механизм обновлений/откатов), а rc управляет уже pod`ами

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

👍 спасибо

Подскажите, network alias действует внутри сети networks. А если задать networks external, то alias распространяется на все external подсети?

Пример: Есть некая сеть mynet с прокси Есть две подсети с разными окружениями - prod и stage, которые работают через общий прокси. И выходит, что бэк с prod периодически пишет в базу или кеш на stage. Как их разрулить?

Пример: Есть некая сеть mynet с прокси Есть две подсети с разными окружениями - prod и stage, которые работают через общий прокси. И выходит, что бэк с prod периодически пишет в базу или кеш на stage. Как их разрулить?

networks: my-network: external: name: my-network

да, так и написано

да, так и написано

А теперь рассказывайте, как так у вас вышло что ваш prod может дотянуться до stage сервера БД и ещё в кэш кучу навалить ? Или можете показать docker-compose.yml что бы ускорить процесс получения совета

А теперь рассказывайте, как так у вас вышло что ваш prod может дотянуться до stage сервера БД и ещё в кэш кучу навалить ? Или можете показать docker-compose.yml что бы ускорить процесс получения совета

Эти два окружения висели на одном сервере. Вот docker-compose: version: '2' services: proxy: image: nginx container_name: stage-proxy restart: always depends_on: - app expose: - 80 environment: VIRTUAL_HOST: stage.loc volumes: - ./config/nginx:/etc/nginx/conf.d:ro - ./logs/nginx/:/var/log/nginx:rw networks: stage: aliases: - proxy app: image: stage container_name: stage-cms restart: always depends_on: - mysql environment: YII_ENV: prod MYSQL_HOST: mysql MYSQL_DATABASE: web MYSQL_USER: web MYSQL_PASSWORD: web networks: stage: aliases: - app mysql: image: mysql:5.7 container_name: stage-mysql restart: always ports: - "3306:3306" volumes: - ./config/mysql/mysql.cnf:/etc/mysql/mysql.conf.d/mysqld.cnf:ro - ./data/mysql:/var/lib/mysql - ./logs/mysql:/var/log/mysql environment: MYSQL_ROOT_PASSWORD: web MYSQL_DATABASE: web MYSQL_USER: web MYSQL_PASSWORD: web command: mysqld --character-set-server=utf8 --collation-server=utf8_general_ci networks: stage: aliases: - mysql memcached: image: memcached container_name: stage-memcached restart: always ports: - "11211:11211" networks: stage: aliases: - memcached networks: stage: external: name: srv_mynet

хмм... странно. Почему-то прокси оказался вообще в другой сети version: '2' services: proxy: image: neilpang/nginx-proxy container_name: proxy restart: always ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/tmp/docker.sock:ro - /srv/proxy/certs:/etc/nginx/certs:Z - /srv/proxy/conf.d:/etc/nginx/conf.d - /srv/logs/nginx:/var/log/nginx:rw networks: worknet: networks: worknet:

как он вообще тогда запросы проксирует... 😅

Эти два окружения висели на одном сервере. Вот docker-compose: version: '2' services: proxy: image: nginx container_name: stage-proxy restart: always depends_on: - app expose: - 80 environment: VIRTUAL_HOST: stage.loc volumes: - ./config/nginx:/etc/nginx/conf.d:ro - ./logs/nginx/:/var/log/nginx:rw networks: stage: aliases: - proxy app: image: stage container_name: stage-cms restart: always depends_on: - mysql environment: YII_ENV: prod MYSQL_HOST: mysql MYSQL_DATABASE: web MYSQL_USER: web MYSQL_PASSWORD: web networks: stage: aliases: - app mysql: image: mysql:5.7 container_name: stage-mysql restart: always ports: - "3306:3306" volumes: - ./config/mysql/mysql.cnf:/etc/mysql/mysql.conf.d/mysqld.cnf:ro - ./data/mysql:/var/lib/mysql - ./logs/mysql:/var/log/mysql environment: MYSQL_ROOT_PASSWORD: web MYSQL_DATABASE: web MYSQL_USER: web MYSQL_PASSWORD: web command: mysqld --character-set-server=utf8 --collation-server=utf8_general_ci networks: stage: aliases: - mysql memcached: image: memcached container_name: stage-memcached restart: always ports: - "11211:11211" networks: stage: aliases: - memcached networks: stage: external: name: srv_mynet

name: srv_mynet в последней строке замените на name: stage это первое

хмм... странно. Почему-то прокси оказался вообще в другой сети version: '2' services: proxy: image: neilpang/nginx-proxy container_name: proxy restart: always ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/tmp/docker.sock:ro - /srv/proxy/certs:/etc/nginx/certs:Z - /srv/proxy/conf.d:/etc/nginx/conf.d - /srv/logs/nginx:/var/log/nginx:rw networks: worknet: networks: worknet:

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

name: srv_mynet в последней строке замените на name: stage это первое

networks: stage: external: name: stage ?

А!!! Дошло. Дайте угадаю. Если у меня запущен prod тоже с networks: stage: external: name: srv_mynet То контейнеры и попадают все в одну сеть с одинаковыми алиасами. И гадят друг другу к кеш?

А!!! Дошло. Дайте угадаю. Если у меня запущен prod тоже с networks: stage: external: name: srv_mynet То контейнеры и попадают все в одну сеть с одинаковыми алиасами. И гадят друг другу к кеш?

А ты сообразительный, схватываешь налету, будем следить за твоими успехами

А ты сообразительный, схватываешь налету, будем следить за твоими успехами

Понятно. Как-то я не так разобрался в работе external )) Спасибо огромное!

Понятно. Как-то я не так разобрался в работе external )) Спасибо огромное!

Держи нас в курсе своих успехов

https://www.9tut.com/

https://www.certprepare.com/

а как докер по дефолту ротирует логи?

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

чтобы не уперлось в диск

docker info | grep Logging

если там json-file то никак

если там json-file то никак

Есть опции для ротации

при json-file

но по умолчанию не врублены

docker 18.09, ubuntu 18.04. docker0 внезапно молча не получает IP адреса при втором docker run. WTF?

Jan 21 11:10:56 mail-01 systemd-resolved[576]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP. Jan 21 11:12:29 mail-01 containerd[765]: time="2019-01-21T11:12:29.876309899Z" level=info msg="shim reaped" id=05ba750d091771f25d947b24fe8880855b22f35af7e89a620e2833294d057632 Jan 21 11:12:29 mail-01 dockerd[762]: time="2019-01-21T11:12:29.886174422Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/tasks/delete type="*events.TaskDelete" Jan 21 11:12:29 mail-01 systemd-networkd[551]: veth2134c0d: Lost carrier Jan 21 11:12:29 mail-01 kernel: [ 430.870508] docker0: port 1(veth2134c0d) entered disabled state Jan 21 11:12:29 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:29 mail-01 kernel: [ 430.874626] veth1314dca: renamed from eth0 Jan 21 11:12:29 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:29 mail-01 kernel: [ 430.883386] docker0: port 1(veth2134c0d) entered disabled state Jan 21 11:12:29 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:29 mail-01 networkd-dispatcher[729]: WARNING:Unknown index 8 seen, reloading interface list Jan 21 11:12:29 mail-01 kernel: [ 430.884972] device veth2134c0d left promiscuous mode Jan 21 11:12:29 mail-01 kernel: [ 430.884976] docker0: port 1(veth2134c0d) entered disabled state Jan 21 11:12:29 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:29 mail-01 networkd-dispatcher[729]: ERROR:Unknown interface index 8 seen even after reload Jan 21 11:12:29 mail-01 systemd-udevd[2074]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 21 11:12:29 mail-01 systemd-udevd[2074]: link_config: could not get ethtool features for veth1314dca Jan 21 11:12:29 mail-01 systemd-udevd[2074]: Could not set offload features of veth1314dca: No such device Jan 21 11:12:30 mail-01 systemd-networkd[551]: docker0: Lost carrier Jan 21 11:12:30 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:30 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:31 mail-01 kernel: [ 432.351338] docker0: port 1(veth0f62306) entered blocking state Jan 21 11:12:31 mail-01 kernel: [ 432.351341] docker0: port 1(veth0f62306) entered disabled state Jan 21 11:12:31 mail-01 kernel: [ 432.351549] device veth0f62306 entered promiscuous mode Jan 21 11:12:31 mail-01 systemd-udevd[2099]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 21 11:12:31 mail-01 systemd-udevd[2099]: Could not generate persistent MAC address for veth665811e: No such file or directory Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:31 mail-01 networkd-dispatcher[729]: WARNING:Unknown index 11 seen, reloading interface list Jan 21 11:12:31 mail-01 kernel: [ 432.366023] IPv6: ADDRCONF(NETDEV_UP): veth0f62306: link is not ready Jan 21 11:12:31 mail-01 kernel: [ 432.366029] docker0: port 1(veth0f62306) entered blocking state Jan 21 11:12:31 mail-01 kernel: [ 432.366031] docker0: port 1(veth0f62306) entered forwarding state Jan 21 11:12:31 mail-01 kernel: [ 432.366066] docker0: port 1(veth0f62306) entered disabled state Jan 21 11:12:31 mail-01 systemd-udevd[2101]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. Jan 21 11:12:31 mail-01 systemd-udevd[2101]: Could not generate persistent MAC address for veth0f62306: No such file or directory Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth0f62306: Link is not managed by us

Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth665811e: IPv6 successfully enabled Jan 21 11:12:31 mail-01 kernel: [ 432.375218] IPv6: ADDRCONF(NETDEV_CHANGE): veth0f62306: link becomes ready Jan 21 11:12:31 mail-01 kernel: [ 432.375233] docker0: port 1(veth0f62306) entered blocking state Jan 21 11:12:31 mail-01 kernel: [ 432.375235] docker0: port 1(veth0f62306) entered forwarding state Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth665811e: Gained carrier Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth0f62306: Gained carrier Jan 21 11:12:31 mail-01 systemd-networkd[551]: docker0: Gained carrier Jan 21 11:12:31 mail-01 systemd-networkd[551]: docker0: Configured Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:31 mail-01 containerd[765]: time="2019-01-21T11:12:31.420049344Z" level=info msg="shim containerd-shim started" address="/containerd-shim/moby/04426fea1c317318342d664388f5330fc5de25235b3c73598f16479107d373fe/shim.sock" debug=false pid=2111 Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:31 mail-01 kernel: [ 432.632066] docker0: port 1(veth0f62306) entered disabled state Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth665811e: Lost carrier Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth0f62306: Lost carrier Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:31 mail-01 kernel: [ 432.636146] eth0: renamed from veth665811e Jan 21 11:12:31 mail-01 systemd-networkd[551]: veth0f62306: Gained carrier Jan 21 11:12:31 mail-01 kernel: [ 432.636652] docker0: port 1(veth0f62306) entered blocking state Jan 21 11:12:31 mail-01 kernel: [ 432.636654] docker0: port 1(veth0f62306) entered forwarding state Jan 21 11:12:31 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:12:33 mail-01 systemd-networkd[551]: veth0f62306: Gained IPv6LL Jan 21 11:12:33 mail-01 systemd-networkd[551]: veth0f62306: Configured Jan 21 11:12:33 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Jan 21 11:12:33 mail-01 systemd-timesyncd[540]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com). Jan 21 11:13:31 mail-01 systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 2184 (check_disk) Jan 21 11:13:31 mail-01 systemd[1]: Mounting Arbitrary Executable File Formats File System... Jan 21 11:13:31 mail-01 systemd[1]: Mounted Arbitrary Executable File Formats File System.

Да, тупо на втором запуске не

Jan 21 11:12:29 mail-01 systemd-timesyncd[540]: Network configuration changed, trying to establish connection. Вот то смущает и что то с днс валидатором

Да, тупо на втором запуске не

дядь так это apparmor выЁ**ся

отключи и попробуй еще раз

ytf

Короче. Первые же контейнер после остановки почему-то вбивает у docker0 адрес. Пока грешу на dhcp

Jan 21 13:25:49 mail-01 systemd-networkd[555]: docker0: Lost carrier

Короче. Первые же контейнер после остановки почему-то вбивает у docker0 адрес. Пока грешу на dhcp

apparmor стопарни и посмотри

systemd охуенен.

Че серьзно ?да быть того не может?

apparmor стопарни и посмотри

Да нету у меня его

Всем привет! Кто может сказать, как убить зависший наглухо контейнер? Висит на командах docker stop, docker rm -f, docker system prune, docker kill -s 9. Контейнер был запущен в сварме, и после удаление сервиса стало вот так. Также есть одна сетка, которая видится по docker network ls, но докер говорит, что она не существует, если я пытаюсь ее удалить. К ней присоединены повисшие контейнеры.

дисконнект от сети тех контейнеров тоже виснет

service docker restart

мягче способов нет?

хотя вроде все мягкие я уже попробовал

hard reset по питанию

hard reset по питанию

ростелеком так уже в Екатеринбурге сделал. Ребутнули датацентр

ради одного контейнера?

service docker restart

+ 1. Возникали такие кейсы, где-то до 18 версии докера

ради одного контейнера?

может в вим застряли

docker 18.09, ubuntu 18.04. docker0 внезапно молча не получает IP адреса при втором docker run. WTF?

Убил netplan и cloudinit и всё заработало...

А подтвердите кто-нибудь или опровергните. Ubuntu 18.04. Docker 18.09. Если сеть через netplan и cloud.init — docker0 теряет свой IP после первого же отработавшео контейнера (сборка например). Я так и не понял — netplan или cloud.init

А подтвердите кто-нибудь или опровергните. Ubuntu 18.04. Docker 18.09. Если сеть через netplan и cloud.init — docker0 теряет свой IP после первого же отработавшео контейнера (сборка например). Я так и не понял — netplan или cloud.init

все нормально, но я разворавичал ubuntu через cloud init

привет! слушайте, я не могу в этом чёртовом кубернетесе разобратся

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

я не могу понять как мне один node pool выделить под балансировщики

tains and toleratios

но это не про этот чат

а какой чят про этот ужас?

а какой чят про этот ужас?

@kubernetes_ru

да уж, кубернетес это вам не докер. спасибо!

да уж, кубернетес это вам не докер. спасибо!

как и любой оркестрации есть свои особенности

она какая-то запредельно особенная

пиши туда