Не сработает. Это все контейнеры в один PID namespace кинет, отдельный от хоста.
хмм, точно
Vadim
George
Кмк, коллеге достаточно inotify,но он и между контейнерами работает
George
Но я не уверен, что там особые опции именно на маунт не нужны
𝚔𝚟𝚊𝚙𝚜
George
Может кто подскажет?
Andrey
Может кто подскажет?
Зацени, какой великолепный блог пост я только что нашёл.
https://william-yeh.net/post/2019/06/inotify-in-containers/
Max
Цель — нужно следить за файлами в папке, подмонтированной к контейнеру через hostPath, и отправлять их в google cloud storage, когда в них перестали писать (сейчас проверяется изменился ли размер спустя 5 минут, но это говнометод), а я хочу проверять по тому, открыт ли этот файл каким-либо процессом или нет
Max
inotify!
а оно работает, если один контейнер пишет в эту папку (hostPath), а читает из этой папки другой контейнер, тоже через hostPath?
Andrey
а оно работает, если один контейнер пишет в эту папку (hostPath), а читает из этой папки другой контейнер, тоже через hostPath?
Тебе же детектить write нужно. Сработает отлично.
Max
Тебе же детектить write нужно. Сработает отлично.
мне нужно детектить факт того, что в файл перестали писать и больше НЕ будут
George
а оно работает, если один контейнер пишет в эту папку (hostPath), а читает из этой папки другой контейнер, тоже через hostPath?
Там в целом особенности с hostpath
George
Типа rprivate
𝚔𝚟𝚊𝚙𝚜
Зацени, какой великолепный блог пост я только что нашёл.
https://william-yeh.net/post/2019/06/inotify-in-containers/
kubefuse + inotify = оператор
George
В принципе айнотифай это умеет
George
Т.к. повторюсь, что там есть разные режимы монтирования (когда один контейнер не видит изменения другого)
Yulia
День добрый!
Создаю ингресс с такой аннотацией:
ingress:
enabled: true
annotations:
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
kubernetes.io/ingress.class: nginx
hosts:
- name: my.domain.name
tls:
- secretName: mysecret
hosts:
- my.domain.name
Мне казалось, что cert-issuer создаст подписанный letsencryptом сертификат и создаст секрет с ним.
Но наблюдаю, что создался секрет с самоподписным сертом.
чяднт?
Pavel
Clusterisshuer создал?
Pavel
И смотри логи серт маннджера если кривой поставил там не будет финальной стадии. Смотри состояние цертов
Pavel
по статье мыла создавал и получи самоподписный церт
Pavel
Удаляй и делай по оригинальной статье от разрабов
Yulia
Удаляй и делай по оригинальной статье от разрабов
Статья - от разрабов кубера или cert-manager?
Pavel
Cert-manager
Pavel
У мейлов статья устарела
Max
Там в целом особенности с hostpath
я проверил, по inotify приходит ивент IN_CLOSE_WRITE в случае использования hostPath, все норм. Но есть проблема. Когда я перезапускаю этот скрипт, который следит за ивентами, во время его перезапуска может прилететь этот ивент закрытия файла и я его пропущу. Как быть?
Мне нужно на старте скрипта пройтись по всем файлам и проверить, нет ли среди них тех, в которые уже никто не пишет и они не открыты другими процессами, и залить их в облако. Именно поэтому было бы суперудобно заюзать lsof на старте, а потом следить за inotify
G72K
Цель — нужно следить за файлами в папке, подмонтированной к контейнеру через hostPath, и отправлять их в google cloud storage, когда в них перестали писать (сейчас проверяется изменился ли размер спустя 5 минут, но это говнометод), а я хочу проверять по тому, открыт ли этот файл каким-либо процессом или нет
Есть план что делать делать если пока файл льется в гугл, его снова открыли и начали писать?
Max
Есть план что делать делать если пока файл льется в гугл, его снова открыли и начали писать?
это невозможно в нашем случае
Max
у нас если файл закрыли, то в него точно не полезут больше
Max
короче, за hostPID спасибо, это решило мою проблему
Max
lsof заработал внутри контейнера
G72K
я проверил, по inotify приходит ивент IN_CLOSE_WRITE в случае использования hostPath, все норм. Но есть проблема. Когда я перезапускаю этот скрипт, который следит за ивентами, во время его перезапуска может прилететь этот ивент закрытия файла и я его пропущу. Как быть?
Мне нужно на старте скрипта пройтись по всем файлам и проверить, нет ли среди них тех, в которые уже никто не пишет и они не открыты другими процессами, и залить их в облако. Именно поэтому было бы суперудобно заюзать lsof на старте, а потом следить за inotify
Наоборот, сначала inotify подписаться, потом по lsof пройтись. А то все равно окно останется, когда события пропустите
G72K
Все равно коряво. Если нужны файлы в гцп пусть приложение само их туда шлёт или хотя бы умеет хук дергать "файл ХХХ готов"
Max
Все равно коряво. Если нужны файлы в гцп пусть приложение само их туда шлёт или хотя бы умеет хук дергать "файл ХХХ готов"
я бы с радостью сделал и то и другое, но у нас нет такой возможности)
Max
приложение, которое пишет файлы, не нами написано и исходников нет
Max
так что не за что зацепиться
G72K
Свой Dropbox недоделанный писать тоже так себе решение
Max
да понятно)
Max
ну мы в реальном мире живем)
Max
да и на самом деле это решение универсальное, так как у нас есть как минимум два типа приложений, которые пишут файлы
Max
и под каждый допиливать было бы неудобно
Max
а так они "нативно" срут файлы, а мы их своим недоскриптом заливаем по красоте
Max
я бы заюзал что-то вроде gcs fuse и примонтировал прямо в эти контейнеры, но там тоже куча ньюансов. Нам нужно чтобы в gcs файл загружался только когда он окончательно записан (и изменений не будет)
Max
потому что там после google cloud storage срабатывает пайплайн, который обрабатывает этот файл, после того как он загрузится
G72K
Это костыли и изолента. Что нибудь отвалится. Например у ядра есть максимум на inotify и докер очень любит их использовать . Вы забьете своей синкалкой все что есть, докер повиснет, все развалится , не спать , в офис ехать и проч. Зачем это надо? Если легко нельзя то надо отвечать "нет такое сделать нельзя" :)
Max
Max
И по крону раз в минуту буду проверять, есть ли файлы, которые еще не загружены (а значит не удалены) и не открыты ли другими процессами
Leo
Все для людей
George
Перехват любых системных вызовов внутри линукса. Сложно? Да. Эффективно? Да!
Max
> Например у ядра есть максимум на inotify и докер очень любит их использовать
да, уже с этим столкнулись. Ничего кстати не упало, к счастью
George
И по крону раз в минуту буду проверять, есть ли файлы, которые еще не загружены (а значит не удалены) и не открыты ли другими процессами
Есть риски, что игра закрыла файл, потом открыла и начала дописывать ?
George
Теоретически экспешен хендлер в игре может себя так везти.
Max
оно если и будет, то создаст новый файл
George
Т.е. вы действительно накостылили общий путь. А частный - разобраться в базе приложения или в логах и найти момент, когда файл гарантированно закрыт
Max
Andrey
@vrutkovs
Рекомендуешь?
https://getfedora.org/coreos/
Vadim
только смотри внимательнее, там теперь Ignition 3.0, старые конфиги надо немного переделать (выкинуть сеть, например)
Andrey
только смотри внимательнее, там теперь Ignition 3.0, старые конфиги надо немного переделать (выкинуть сеть, например)
Не, мы только присматривались к Container Linux, а теперь будем СМОТРЕТЬ.
G72K
G72K
Не, мы только присматривались к Container Linux, а теперь будем СМОТРЕТЬ.
Когда опеншифт на этом сделают, тогда можно смотреть:)
Vadim
Когда опеншифт на этом сделают, тогда можно смотреть:)
ну OCP4 уже на тех же игнишенах, но пока сборки на основе FCOS нет
Vadim
но вообще https://typhoon.psdn.io/cl/bare-metal/ должен работать и на FCOS, если правильные конфиги сгенерить