Задание для Docker для практики

Простое задание: удалить докер из системы и заменить всё что в нём было установлено на нормальный способ установки.

Подними в нем OpenVPN сервер, настрой NAT, подключись клиентом, проверь работоспособность, потом сможешь готовый образ скинуть на VPS и у тебя будет тоннель.

Настрой в докере build chain своего дистрибутива, собери там пакеты. Тогда ненужно будет ставить кучу мусора на свой хост. Но вообще дистры для этого обычно имеют готовые решения типа schroot.

Запусти в докере СУБД. Базы для разработки намного удобнее держать в докере, ты не зависишь от меинтенеров дистрибутива в выборе версий, и можно держать сразу много версий СУБД.

Можешь потыкать NextCloud, настрой внешнюю базу в другом контейнере, используй dockercompose для их быстрого развертывания и запуска.

Дайте Простое задание для Docker из жизни так сказать.

простое

из жизни

Противоречие! Посмотри, например, как десктопный клиент телеги собирается «простое из жизни» )

А так, вот:

• сделать контейнер, в котором понадобится собрать одну из зависимостей из исходников
• организовать сборку
• потом подчистить ненужное
• в ходе процесса минифицировать количество слоёв

Ищешь любое приложение на любимом или нелюбимом языке на гитхабе и докеризируешь его

Всем привет!

Шалом!

Дайте Простое задание для Docker из жизни так сказать.

С помощью композера поднять кластер ELK по всем канонам и мониторинг для него на Prometheus с отрисовкой основных жизненных показателей в Grafana, поднять слой Vector, настроить на нем нормализацию данных и запись в эласт, не забыв про мониторинг нагрузки на слое, дальше используя любые логогенераторы (формата Nginx например ) прогнать данные с нормальным рейтом, дедуплицировать на Vector, выкинуть ненужное, сложить красивый JSON в ELK и настроить визуализацию в Grafana.

ELK
Grafana

ELG какой-то получается.

ELG

Само по себе это ниаличие Kibana не отменяет, просто сделал упор на «G» потому что это принесет в практикум еще и некоторое эстетическое удовольствие при условии прямоты рук)

Напиши замену докера.

Отмену докера.

Ну пока ничего лучше не придумали.

Но и хуже тоже.

Ну пока ничего лучше не придумали.

А как же Podman ?

Нормальная тема. Но я больше про концепцию.

а вектор тогда нафига если L - Logstash?

а вектор тогда нафига если L - Logstash?

Ну очевидно же что бы осознать что «L» теперь несколько лишняя стала как и «FB» тащемта. Вроде еще канает, но уже не то пальто)

Нужно жить в ногу со временем

Затем же, зачем и всё остальное ненужно в этом списке, включая докер. :)

Как бы ты строил инфраструктуру для логгирования с нуля сегодня? По схеме из своего первого сообщения?

остальное ненужно в этом списке

Каковы альтернативы? Очень итересно. Kafka + ClickHouse + Superset?

Как бы ты строил инфраструктуру для логгирования с нуля сегодня?

Это сильно зависит от конкретного случая и ресурсов, которые можно задействовать на пайплайн. Какой EPS хотя бы? Логи более менее вменяемые или крайне разнородные? Какие потребности у аналитиков?

По схеме из своего первого сообщения?

Я специально «привел средний по больнице» частный случай, довольно универсальный, тренировочный и синтетический. Как бы строил зависит от многих вещей. Как минимум добавление слоя «Kafka» в эту схему если в этом будет потребность.

Альтернатива чему? Описанный стек настолько редко необходим и для настолько узких задач, что рассматривать его как настройку для «посмотреть» бессмысленно.

Компания маленькая, аналитиков как таковых можно сказать что и нет, логи тупо расбросаны где как, смотрятся ad hoc. Гигабайты оперативы тратить не хочется. Особо человеческих ресурсов на это тоже нет, всё делается по большому счёту в побочное время. Пока план - складывать централизованно логи в loki и вроде в grafana есть какая-то интеграция с ним, там как-то просматривать/искать для начала.

Объёмы - отдельные сервисы генерят несколько десятков гигабайтов текста в день, но это от дурости, но пока надо складывать что есть хотя бы за неделю, а лучше за месяц. В сжатом виде, иначе никак. Если сверху оценить - 100 ГБ в день. Если мусор почистить, думаю, будет 10 МБ в день. Но кто его чистить будет…

Альтернатива чему? Описанный стек настолько редко необходим и для настолько узких задач

Это практически дефолтный продакшн-стек для логанализа, за исключением того, что я в угоду времени выкинул logstash и filebeat заменив их на прогрессивный Vector. Использование логов nginx тоже частный случай, тут можно подставть любые логи, какие душе угодно.

Если сверху оценить - 100 ГБ в день. Если мусор почистить, думаю, будет 10 МБ в день. Но кто его чистить будет…

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

О том и речь, что затраты ресурсов и времени на подобный стек анализа в 99% случаев не нужны.

Это тоже самое, что ставить zabbix для мониторинга СУБД, с которой никто, кроме этого самого zabbix'а не работает. И нагрузка есть, и графики красивые, но смысла ноль.

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

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

Не нужно это только сычам@админам-локалхоста.

Все альфачи@девопсы-ынтерпрайза так говорят, чтобы объяснить собственную востребованность. :) Особенно громко говорят, когда несмотря на все затраченные на подобную инфру ресурсы, проект закрывают.

когда несмотря на все затраченные на подобную инфру ресурсы, проект закрывают.

Наш проект работает с 2004 и пережил на себе всю эволюцию от нескольких серваков, поддерживемых полупьяными волосатыми маргиналами в худи с принтами КиШ, до крупного энтерпрайза с оромным штатом ITшников и десятками тысяч серверов, живет, в х не дует и будет жить дальше. Такие дела.

Я где-то сказал, что использование ELK приводит к закрытию проектов? Если у вас в проекте достаточно свободных ресурсов и/или проект попадает в тот 1%, которым подобный анализ действительно нужен, почему бы ему не работать?

А так же спасибо за наглядную иллюстрацию парадокса выжившего.

Так кто же спорит? Пусть ТАК живёт. Есть другие пути ))

Они нужны буквально всем

))

Есть другие пути ))

Например?

Нейронки ))

админам дебажащим работу сервисов, аналитикам вытаскивающим аналитику, в том числе метрики для бизнеса, безопасникам цедящим свои события и триггерящиеся по ним.

Админы имеют свои стенды.
Аналитики работают с подготовленными данными.
Безопасники работают с аномалиями.

А вообще это не здесь надо обсуждать ))

Это практически дефолтный продакшн-стек для логанализа,

Прочёл тред. У тебя всё «по старинке». Вопросов не имею. Просто я взбрыкнул на «поддерживемых полупьяными волосатыми маргиналами в худи с принтами КиШ».
Теперь ты можешь так писать и о себе ))

Просто я взбрыкнул на «поддерживемых полупьяными волосатыми маргиналами в худи с принтами КиШ».

Лул, я примерно таким и был в то время, совершенно напрасно ты триггернулся на это.

Теперь ты можешь так писать и о себе ))

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

Верю. Я о том, что всякие Elastic и SQL для аналитиков - это прошлый век. Как и ЛОР, с его ручным маргинальным модерированием, это прекрасно показывает.

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

А я не делаю, я теперь треплюсь )) Меня совет директоров слушает с умным видом и неограниченными возможностями )))

Бизнес, он как дитё, смотрящее рекламу :)

Пробовал на днях поюзать Prometheus - как несвежего поел. Особенно порадовало состояние экспортера для JMX, такое ощущение, что это корявое поделие будет первым, что сломается в любой непонятной ситуации, и из-за подключения в виде агента утащит за собой основное приложение.

Сабж вообще можно использовать в реальной жизни? Или он чисто для поиграться?

тогда проще и дешевле это все упаковать в ClickHouse, тогда будет профит, в хранении с сжатием и в скорости поиска и в целом в эксплуатации такого решения.

LOKI же. Хранить логи в clickhouse конечно можно, но но у ж очень через одно место в нем select’ы сделаны - памяти будет уходить безумное количество

Сабж вообще можно использовать в реальной жизни? Или он чисто для поиграться?

prometheus - это сейчас практически стандарт для realtime мониторинга. Очень простое (экспортеры пишутся практически за несколько минут) и универсальное.