Вот подумал я и, пожалуй, соглашусь. Монолиты иногда кладут в контейнеры и множат инстансы. Вот тогда начинается тихий ужас, т.к. они вообще не созданы для этого. Появляется supervisord внутри или, например, фреймворк сам начинает контролировать свои форки и плодит 20 процессов внутри одного контейнера и каждый из них ведёт себя как отдельное ПО со своими логами.
На заре развития Докера, когда я его не любил, я тоже так делал. Чистый докер тяжело управляется, стыковать контейнеры друг с другом сложно и долго, поэтому Supervisor был спасением и получался эдакий «быстрый Vagrant».
Особенно для пользователя, который потратил 4 килобакса на новый ноут и он умер от пылинки. Можно как-нибудь ещё 50 баксов доплатить (цена пары ужинов в каких-нибудь Нью-Йорках) за нормальную влаго-пылезащиту. Кстати есть внешние накладки, немного, но спасают.
Это конечно тот ещё холивар, но Safari вообще невозможно пользоваться. Когда классическая Опера умерла, я долго страдал и сидел на хроме. Сейчас есть Vivaldi и я снова почувствовал тепло ламповых двухтысячных. VOX вернул ощущение «winamp», осталось реанимировать Total Commander под OSX и я снова стану счастливым. :)
Тут уже не в моде дело. Из своего опыта могу сказать, что если контейнеры «пошли» в жизнь и вокруг выросла зрелая экосистема их обслуживания, то остановиться уже невозможно. Начинаешь тихо ненавидеть всё прочее, включая всевозможные lambda functions, потому что там нет и половины того, что уже настроил для Kubernetes. А это огромный список мелочей, начиная с весьма развитого CI/CD и заканчивая красивыми визуализациями происходящего внутри каждого контейнера.
А ещё есть service mesh networks и так далее. Стоит только начать…
Стандарта нет, есть некие общие принципы.
— Логи «снимаются» с докера (rsyslog, fluentd, ...). Способы реализации разные. Можно изнутри Kubernetes это делать, а можно снаружи, собирая просто логи докера на каждой ноде прямо на хосте, настраивая это всё через оркестратор типа Chef/Salt/whatever.
— собранные логи «умно» пересылаются в какой-либо аггрегатор, с учётом его производительности. Здесь тоже сетап может сильно отличаться. Если логов мало и они качественные (согласованный json), то можно прямо в ElasticSearch слать в нужный индекс. Если их много, можно сначала в какую-то промежуточную точку сбора вроде Kafka, а затем уже в конечную (это может быть какой-то SAAS, не обязательно ElasticSearch).
— потом выводятся в каких-нибудь вьюхах. Kibana/Graphana, тут кому что ближе к телу. Сильно зависит от знания технологии и наличия свободного времени. Можно наворотить нереально красивые и полезные графики. Но большинство просто использует поиск и фильтрацию.
— а поверх настраиваются оповещения о событиях.
Нет, не противоречат. Просто приложение не должно самостоятельно этим заниматься. Вся сборка логов должна быть автоматизирована одним инструментом сразу для всех контейнеров вне их самих. Rsyslog, fluentd, logstash, что-то из этой серии.
В крупноблочных или монолитных приложениях легче отслеживаются проблемы, если всё выполняется в одном потоке. Конечно всё это выжимка опыта работы, включающая и до-докерную эру, однако с множеством мелких программ в одном проекте приходят новые сложности. Зоопарк технологий, фреймворков, всё это очень усложняет понимание сути происходящего.
И да, и нет. Не совсем очевидно, если вы привыкли пользовать kubectl apply. Всё-таки Kubernetes — система немного отличающаяся от просто операционки. Механизм гарантирует применение отличий и за всё время использования я ни разу не сталкивался с какими-то неожиданными эффектами. И именно поэтому поведение Helm вызывает удивление.
Имея встроенный механизм в Kubernetes, разработчики не стали его использовать.
С точки зрения разработки Helm, мне лично не кажется хорошей идеей _запретить_ людям пользоваться kubectl. Очевидно, что существует вагон и тележка случаев, для которых Helm не проектировался. Но установка конкретной версии конфигурации должна гарантировать, что она вся будет применена, а не только какие-то куски, которые отличаются от предыдущей.
Да и с пакетом дебиан в убунту параллель не совсем удачная. Тут скорее иное: если вы ставите Nginx 1.15, затем редактируете какой-то его файл (не конфигурацию, а именно файл пакета), а затем снова ставите Nginx 1.16 (да или даже 1.15 заново), то врядли вы ожидаете, что apt-get оставит ваш файл нетронутым, верно? Особенно если он именно отчитывается, что поставил и перезапустил пакет, а не просто «эта версия уже установлена».
На заре развития Докера, когда я его не любил, я тоже так делал. Чистый докер тяжело управляется, стыковать контейнеры друг с другом сложно и долго, поэтому Supervisor был спасением и получался эдакий «быстрый Vagrant».
А ещё есть service mesh networks и так далее. Стоит только начать…
примерно так
— Логи «снимаются» с докера (rsyslog, fluentd, ...). Способы реализации разные. Можно изнутри Kubernetes это делать, а можно снаружи, собирая просто логи докера на каждой ноде прямо на хосте, настраивая это всё через оркестратор типа Chef/Salt/whatever.
— собранные логи «умно» пересылаются в какой-либо аггрегатор, с учётом его производительности. Здесь тоже сетап может сильно отличаться. Если логов мало и они качественные (согласованный json), то можно прямо в ElasticSearch слать в нужный индекс. Если их много, можно сначала в какую-то промежуточную точку сбора вроде Kafka, а затем уже в конечную (это может быть какой-то SAAS, не обязательно ElasticSearch).
— потом выводятся в каких-нибудь вьюхах. Kibana/Graphana, тут кому что ближе к телу. Сильно зависит от знания технологии и наличия свободного времени. Можно наворотить нереально красивые и полезные графики. Но большинство просто использует поиск и фильтрацию.
— а поверх настраиваются оповещения о событиях.
Я слаботеплокровный, ноги стынут, особенно когда всякую чушь сочиняю :)
Вы совершенно правы, но это уже сильно индивидуальный выбор, да и стоит денег.
Все будет хорошо до первого исключения на 100 строк с другим логом внутри
В крупноблочных или монолитных приложениях легче отслеживаются проблемы, если всё выполняется в одном потоке. Конечно всё это выжимка опыта работы, включающая и до-докерную эру, однако с множеством мелких программ в одном проекте приходят новые сложности. Зоопарк технологий, фреймворков, всё это очень усложняет понимание сути происходящего.
Я уточнил, точно я. :D Вообще сам чек-лист у меня по-английски хранится, возможно это ощущается. Остальной текст написан сразу по-русски.
Имея встроенный механизм в Kubernetes, разработчики не стали его использовать.
С точки зрения разработки Helm, мне лично не кажется хорошей идеей _запретить_ людям пользоваться kubectl. Очевидно, что существует вагон и тележка случаев, для которых Helm не проектировался. Но установка конкретной версии конфигурации должна гарантировать, что она вся будет применена, а не только какие-то куски, которые отличаются от предыдущей.
Да и с пакетом дебиан в убунту параллель не совсем удачная. Тут скорее иное: если вы ставите Nginx 1.15, затем редактируете какой-то его файл (не конфигурацию, а именно файл пакета), а затем снова ставите Nginx 1.16 (да или даже 1.15 заново), то врядли вы ожидаете, что apt-get оставит ваш файл нетронутым, верно? Особенно если он именно отчитывается, что поставил и перезапустил пакет, а не просто «эта версия уже установлена».