Пятничный деплой
4.47K subscribers
1.41K photos
29 videos
167 files
7.78K links
Подборка ссылок, статей и постов из мира DevOps\SRE\разработки. Если вы хотите прислать фидбек, интересную статью или просто поболтать пишите @count0ru https://xn--r1a.website/s/count0_digest
Download Telegram
Forwarded from The After Times
Кроме воровства мемов я ещё иногда занимаюсь айти. Со временем эта история переросла в собственную книгу. Релиз во второй половине января.
Проверить доступность можно по ссылке
👍8👎2
InfraDev Community приглашает на Cloud Fail ((Over)): специальный новогодний выпуск InfraDev Meetup.
Без фейлов не обходится ни один крутой продукт, ну а истории успеха — «за ширмой» оказываются историями поисков и ошибок с удачным концом.
Поговорим про то, какие проблемы возникают под капотом инфраструктурных продуктов, как они решаются и какие уроки из этого получаются.

Спикеры:
☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech.
☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud.
☁️Секретный доклад: подробности добавим позднее.
Подробнее о докладах читайте на странице мероприятия.

Когда: 18 декабря, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).

Приходите на встречу или участвуйте онлайн.

Зарегистрироваться.
👎21👍1🔥1
Forwarded from Кубернетичек
https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs/

Попалась замечательная статья. Много по полочкам разложено. Особенно упомянули формулу расчёта cpu weight для cgroupv2, которую хотят дополнительно разжевать https://github.com/kubernetes/website/pull/52793/files.

Но есть нюанс (не в претензию к статье, она отличная)
What's this static policy about?
With static, Kubernetes can give certain containers exclusive access to CPU cores ... Nothing else would be allowed to run on those cores. That's really useful for apps that don't play well with CPU sharing or need strong cache locality


Это не совсем так. cpu manager обеспечивает изоляцию только между pod'ами kubernetes, а не между всеми процессами в ОС. Служебные процессы могут и будут селиться на данные cpu.

https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy

This policy manages a shared pool of CPUs that initially contains all CPUs in the node.... This
shared pool is the set of CPUs on which any containers in BestEffort and Burstable pods run. Containers in Guaranteed pods with fractional CPU requests also run on CPUs in the shared pool.


Вообще непонятно, зачем так сложно писать в доке. Я сам пропустил это, пока на практике не столкнулся, что "эксклюзивность" не эксклюзивная в рамках всей ноды. И даже не всех контейнеров, а только которые контролирует kubernetes. Лишь когда перечитывал доку с какого-то раза, обратил внимание на shared pool.

У Datadog это упомянули, кстати, тоже можно почитать, но на мой вкус она не так интересно читается https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/
2👍2👎1
Как и зачем мониторить внешний трафик в K8s 🥵?

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

Как? Ответ — Istio

Но что делать с сертификатами? Смотрим дальше ↘️
Для рецепта нам понадобится ещё и cert-manager, установленный в кластер

☝️ Disclaimer: пример является упрощённым и не учитывает все возможные детали, а скорее является идеей, как вы можете реализовать подобное у себя

Итак, у нас есть внешний сервис, взаимодействия с которым мы хотим отслеживать, и работает он только по HTTPS

🔸 сначала его опишем, чтобы Istio знал про него:
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: example.com
namespace: istio-system
spec:
hosts:
- example.com
ports:
- number: 443
name: https
protocol: HTTPS
resolution: DNS


Создадим свой доверенный certificate authority

🔸 ClusterIssuer для подписи:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: selfsigned
spec:
selfSigned: {}


🔸 дальше certificate с isCA=true
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ca
namespace: cert-manager
spec:
isCA: true
commonName: ca
secretName: ca-secret
duration: 175200h
privateKey:
algorithm: RSA
size: 2048
issuerRef:
name: selfsigned
kind: ClusterIssuer
group: cert-manager.io


🔸 и ClusterIssuer для выдачи сертификатов уже на целевые хосты:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: server-issuer
spec:
ca:
secretName: ca-secret


🔸 создадим ещё сам сертификат на целевой хост:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: egress-server-cert
namespace: istio-egress
spec:
commonName: egress-server-cert
secretName: egress-server-cert-secret
duration: 8760h
privateKey:
algorithm: RSA
size: 2048
dnsNames:
- example.com
issuerRef:
name: server-issuer
kind: ClusterIssuer
group: cert-manager.io


Дальше используем в egress gateway:
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: gateway
namespace: istio-egress
spec:
selector:
app: istio-egressgateway
istio: egressgateway
servers:
- hosts:
- '*'
port:
name: https-port
number: 443
protocol: HTTPS
tls:
credentialName: egress-server-cert-secret # здесь будет сертификат для tls
mode: SIMPLE


Теперь нужно заставить приложения доверять сертификату. Для этого нужно будет в сервисы добавить этот CA как доверенный

Например, в файл /etc/ssl/certs/ca-certificates.crt

Например:
RUN curl 'https://my.internal.storage/CA.crt' -o '/usr/local/share/ca-certificates/CA.crt'
RUN /usr/sbin/update-ca-certificates


Как это делать для каждого конкретного сервиса — каждый решает сам. Базово можно скриптом пробежаться по нужным репозиториям и в Dockerfile добавить скачивание нужного CA

И когда это будет сделано и сервисы задеплоены, опишем VirtualService, чтобы ходить на внешний хост через egress gateway:
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
name: example.com
namespace: default
spec:
hosts:
- example.com
tls:
- match:
- port: 443
sniHosts:
- example.com
route:
- destination:
host: istio-egressgateway.istio-egress.svc.cluster.local


И DestinationRule не забыть описать:
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
name: example.com
namespace: istio-system
spec:
host: example.com
trafficPolicy:
portLevelSettings:
- port:
number: 443
tls:
mode: SIMPLE


В итоге получим метрики общения с внешней системой без дополнительной инструментации сервисов 👍

Конечно же Istio может помимо этого добавить больше интересных механик: retry, circuit breaker, rate limiter и так далее
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Telco Cloud: дискуссия об облачной инфраструктуре, которая отвечает строгим требованиям телекоммуникационного сектора.

Компания «Инфосистемы Джет» приглашает на дискуссию о Telco Cloud — облачной платформе, созданной по стандартам телеком-индустрии. Эти отработанные технологии могут использоваться не только для операторов, но и для других отраслей: финтеха, ритейла, логистики и промышленности.

На дискуссии эксперты обсудят:

• Технологические особенности телеком-облака, которые отличают его от частных облаков;
• Use-cases на базе Telco Cloud: IoT, Edge Computing, AI/ML, Private 5G и SD-WAN;
• Применимость архитектурные паттернов телекома для задач из других отраслей;
• «Идеальное облако» по мнению экспертов и различные подходы.

Мероприятие будет полезно техническим директорам, руководителям ИТ-отделов и бизнес-направлений, архитекторам облачных платформ, а также DevOps-инженерам.

Записаться на дискуссию можно по ссылке.
👎1
зато постмортем напишут потом в домашней атмосфере!
🔥6
CF снова пал. Не хотел бы я быть тем инженером что за него отвечает
👍8🔥3
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Concurrency, Synchronization and Consistency. Пост №18. Golang sync.Mutex internals

В прошлом посте мы решали практическую задачку и использовали язык Go. Его основная особенность - наличие собственного рантайма в рамках которого происходит управление и планирование горутин - потоков исполнения не связанных явно 1к1 с потоками ОС.

А если у языка собственный рантайм и "собственные" потоки, то и должны быть "собственные" примитивы синхронизации, умеющие работать с горутинами. И они действительно есть. Основным примитивом синхронизации в Go является sync.Mutex.

У ребят из VictoriaMetrics получился великолепный разбор внутреннего устройства sync.Mutex c красивыми иллюстрациями и кодом. Я бы не смог рассказать лучше, а пересказывать копируя материал не хочется. Тем более, что многие приемы и детали упоминал ранее, только в контексте POSIX.
Поэтому советую освежить в памяти предыдущие посты цикла. Увидите, что многие идеи и оптимизации придуманные для ОС были использованы в рантайме Go. Уровень абстракции выше, а проблемы и вызовы такие же😊

Внутри вас ждёт:
- Внутреннее представление sync.Mutex.
- Как выглядят Fast path и Slow path в sync.Mutex (в том числе в ассемблере).
- Как sync.Mutex пытается обеспечить справедливость и избегать голодания.
- Как происходит Unlock.

https://victoriametrics.com/blog/go-sync-mutex/

-----

Если вам понравился пост, поддержите его реакциями и комментариями. Мне важно увидеть вашу обратную связь. Спасибо!

P.S. Следующая публикация вероятнее всего будет на Хабре, выпуск намечен на следующую неделю. Будем как в прошлый раз писать свои велосипеды в погоне повторить эталонные реализации, оценивать результаты бенчмарками и профилями😊
🔥2👍1
Cloudflare выложили разбор вчерашнего инцидента

Cloudflare outage on December 5, 2025
https://blog.cloudflare.com/5-december-2025-outage/

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

Как и писал CTO (https://xn--r1a.website/tech_b0lt_Genona/5926), они катили изменения для того, что бы закрыть свежую и нашумевшую уязвимость React'а (https://xn--r1a.website/tech_b0lt_Genona/5918, https://xn--r1a.website/tech_b0lt_Genona/5923)

Для этого они провели два действия:

- Они обнаружили что балалайка, котрая тестирует их WAF не поддерживает нужный размер буфера тела HTTP-запроса, поэтому они её отключили (нужен был 1 MB, а умела только 128 KB)

- Выкатили практически моментально на все сервера изменения. Если я понял правильно, то они так настроили/сделали систему конфигурации после прошлого отвала - https://xn--r1a.website/tech_b0lt_Genona/5885

Как и в прошлый раз, сейчас тоже упоминаются две реализации их прокси - FL1 (старая, я не помню на чём, но там есть Lua) и FL2 (новая на Rust)

FL1 стало плохо после отключения балалайки, которая тестировала WAF и его правила, и начала "пятисотить". Происходило это из-за того, что поломался кусок, который отвечал за правила (Lua часть)

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)


И это объясняет почему у части работало всё нормально, а у части нет. Проблем не было у тех чей трафик шёл через FL2

> Customers that have their web assets served by our older FL1 proxy AND had the Cloudflare Managed Ruleset deployed were impacted

> Customers that did not have the configuration above applied were not impacted. Customer traffic served by our China network was also not impacted.

Когда CF увидели, что всё посыпалось, то вообще должна была отработать система "отката". Но что-то пошло не так 🌝

Правила, когда отрабатывают, то выполняются определённые действия (в том числе и к трафику)

> Typical actions are “block”, “log”, or “skip”. Another type of action is “execute”, which is used to trigger evaluation of another ruleset.

Но как выяснилось они никогда не откатывали аварийно правила с типом execute и при откате сломавшего всё нового правила возникла ошибка в логике

if rule_result.action == "execute" then
rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end


> This code expects that, if the ruleset has action=”execute”, the “rule_result.execute” object will exist. However, because the rule had been skipped, the rule_result.execute object did not exist, and Lua returned an error due to attempting to look up a value in a nil value.

В FL2 проблемы не существовало такой, потому что, цитирую

> This is a straightforward error in the code, which had existed undetected for many years. This type of code error is prevented by languages with strong type systems.

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

Короче, растпобеда случилась 🗿
🔥7
Forwarded from DevOps&SRE Library
Container CPU Requests & Limits Explained with GOMAXPROCS Tuning

In this article, we’re going to cover a few things that might’ve puzzled you if you’ve been running your applications, especially Go applications, in Kubernetes:

- How Kubernetes and the Linux kernel handle CPU stuff for containers
- What the Go runtime does with CPU, and whether you should bother setting GOMAXPROCS
- Which metrics are actually worth paying attention to

Maybe you’ve seen some of these metrics before while keeping an eye on your applications, but didn’t fully know what to make of them. This should help clear that up.


https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs
👍1
Forwarded from /usr/bin
zerobyte

Zerobyte — это инструмент автоматизации резервного копирования, который помогает сохранять данные в нескольких хранилищах. Он создан на основе Restic и имеет веб-интерфейс для планирования, управления и мониторинга зашифрованного резервного копирования вашего удаленного хранилища.

Репыч на Гитхаб
🔥3
Forwarded from /usr/bin
Балансировка нагрузки: проблемы, решения, практические рекомендации

Один сервер — это точка отказа. Рано или поздно он не выдержит. Как только появляется второй, третий, десятый сервер, возникает вопрос: кто будет раздавать им работу? Эту роль и берет на себя балансировщик нагрузки.

Но это не тупая раздача запросов по очереди. Хороший балансировщик — это мозг. Он должен чувствовать пульс системы: какой сервер отвечает быстро, а какой начал тормозить. Он должен понимать, что запросы одного пользователя лучше отправлять в одно и то же место. Ошибка в этой логике — и вся система превращается в хаос из ошибок и потерянных сессий.


В этой статье на Хабре разобрана матчасть по возможным вариантам балансировки нагрузки.

@usr_bin_linux
Forwarded from DevOps
⚡️ CACHING STRATEGIES В СИСТЕМНОМ ДИЗАЙНЕ

Кэширование хранит часто используемые данные в быстром слое, обычно в памяти.
Это снижает нагрузку на базу данных и ускоряет ответы системы.
Один из самых эффективных способов улучшить производительность, масштабируемость и сократить расходы.

ПОЧЕМУ КЭШИРОВАНИЕ ВАЖНО
Экономит запросы к базе
Уменьшает задержку
Справляется с высоким количеством чтений
Укрепляет стабильность при нагрузках
Снижает стоимость инфраструктуры

1) CLIENT-SIDE CACHING
Хранение данных в браузере пользователя.
Используются cookies, localStorage, service workers.
Меньше повторных загрузок статических ресурсов.

2) CDN CACHING
Статические файлы лежат на глобальных edge-серверах.
CSS, JS, изображения, видео, шрифты.
Меньше задержка у глобальных пользователей и разгрузка основного сервера.

3) APPLICATION-LEVEL CACHING
Кэш внутри приложения.
Например, структуры в памяти вроде LRU cache.
Очень быстро, но работает в рамках одного сервера.

4) DISTRIBUTED CACHING
Общий кэш для множества серверов.
Инструменты: Redis, Memcached.
Подходит для горизонтального масштабирования и устраняет дублирование кэша.

5) DATABASE QUERY CACHING
Базы хранят результаты частых запросов.
MySQL Query Cache, Postgres внутренний кэш, MongoDB WiredTiger.
Ускоряет повторные чтения.

6) WRITE-BEHIND
Запись идет в кэш, а в базу — асинхронно.
Снижает задержку записи.
Подходит для систем с высокой нагрузкой на запись.

7) WRITE-THROUGH
Записи попадают в кэш и базу одновременно.
Гарантирует консистентность.
Немного медленнее из-за двойной записи.

8) CACHE-ASIDE
Приложение сначала проверяет кэш.
Если промах — идет в базу, затем помещает результат в кэш.
Гибкий и самый популярный вариант.

9) READ-THROUGH
Приложение всегда читает из кэша.
При промахе сам кэш получает данные из базы.
Кэш всегда остается обновленным.

10) TTL И ПОЛИТИКИ ИСТЕЧЕНИЯ
Каждая запись имеет срок жизни.
TTL, LRU, LFU, FIFO — разные режимы очистки данных.

11) INVALDATION
Ручное удаление ключей, удаление по шаблону, автоматическое истечение по TTL или лимиту памяти.

12) MULTI-LAYERED CACHING
Несколько уровней сразу: браузер, CDN, распределенный кэш, кэш приложения.
Полезно для глобальных систем с большим трафиком.

Совет
Кэширование помогает добиться высокой скорости, низкой нагрузки на базу и хорошей масштабируемости.
Стратегию нужно подбирать исходя из размеров системы, интенсивности запросов и требований к консистентности.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Forwarded from DevOps
🐧 Продвинутый Linux/DevOps совет: используйте `systemd-run` для мгновенного запуска задач в изолированных временных сервисах - без написания unit-файлов.

Фишка:
systemd-run позволяет запускать команды как полноценные systemd-сервисы "на лету".
Это идеальный инструмент для временных задач, отладки, ограничения ресурсов и тестирования поведения в боевых условиях.

Примеры:

1) Запуск команды в отдельном cgroup с лимитом CPU:
systemd-run --scope -p CPUQuota=20% bash -c "make build"

2) Запуск периодической задачи без cron:
systemd-run --on-calendar="hourly" /usr/local/bin/cleanup.sh

3) Проверка сервиса в sandbox-режиме:
systemd-run --property=PrivateTmp=yes --property=ProtectSystem=strict bash

4) Изоляция для небезопасной команды:
systemd-run -p NoNewPrivileges=yes -p PrivateDevices=yes ./script.sh

Чем полезно:
- Не нужно создавать и чистить unit-файлы
- Команда получает все преимущества systemd: логи, cgroups, sandbox
- Отлично подходит DevOps-инженерам для тестов и временных задач
- Позволяет гарантировать безопасность и стабильность окружения

Если вы ещё не используете systemd-run как «одноразовый unit-файл», попробуйте - это один из самых недооценённых инструментов systemd.
🔥4👍1
Forwarded from Код и Капуста
Умереть от датарейс

Go часто хвалят за простоту написания высококонкурентных программ. Однако поражает то, как много возможностей Go предоставляет разработчикам, чтобы они сами себе навредили.

Статья с примерами гонок и других ошибок при написании конкурентного кода

#golang

https://kodikapusta.ru/news/etpu-umeret-ot-datareis
Forwarded from k8s (in)security (Дмитрий Евдокимов)
songbird - простенький CLI инструмент, упрощающий жизнь и работу с NetworkPolicy (к сожалению, только нативными). А именно данный инструмент позволяет:
1) Проверять достижимость между Pods или к конкретному адресу через анализ NetworkPolicy. То есть помогает ответить на вопрос "а они вообще могут общаться друг с другом или нет?"
2) Сгенерировать NetworkPolicy для общения между двумя сервисами
3) Отобразить все сетевые политики, которые влияют на выбранный Pod

P.S. Определенно ряд мыслей мы подсмотрим для Luntry, расширив поддержкой Calico и Cilium ;)
1👍1
Forwarded from DevOps FM
От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:

helm repo update


2. Разворачиваем базовое окружение для инфраструктуры:
cub space create infra


3. Устанавливаем Helm-чарт через ConfigHub:


cub helm install --space infra \
--use-placeholder=false \
--namespace monitoring \
prometheus prometheus-community/kube-prometheus-stack \
--version 79.6.1


• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:
cub space create dev
cub space create prod

2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev

cub unit get --space dev prometheus --data-only


Prod

cub unit get --space prod prometheus --data-only


Получаем готовый YAML, а не шаблон или переменную.

Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов

cub unit list --space "*" \
--resource-type monitoring.coreos.com/v1/Prometheus \
--where-data "spec.image ~ '.*registry.compromised.com.*'"


Поиск образов

cub unit list --space "*" \
--resource-type monitoring.coreos.com/v1/Prometheus \
--where-data "spec.image ~ '.*quay.io.*'"


👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍2🔥2
Forwarded from /usr/bin
Разбираем подводные камни, ошибки и лучшие практики при разработке Kubernetes-операторов

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


Читать дальше на Хабре.
Forwarded from DevOps
🚀 Удобное управление CI/CD с Pipedash

Pipedash — это настольное приложение, которое объединяет CI/CD пайплайны из различных провайдеров в одном интерфейсе. Вместо того чтобы переключаться между разными панелями управления, вы можете отслеживать статус всех своих пайплайнов в одном месте. Приложение поддерживает GitHub Actions, GitLab CI, Jenkins и другие.

🚀 Основные моменты:
- Объединяет данные из нескольких CI/CD провайдеров
- Автоматическое обновление статусов пайплайнов
- Поддержка плагинов для добавления новых провайдеров
- Локальное хранение данных без аналитики и телеметрии
- Доступно для macOS, Windows и Linux

📌 GitHub: https://github.com/hcavarsan/pipedash

#rust
🔥5
Forwarded from Загадки DevOpsa
Лучшие практики и технологии DevOps в 2025 году

17 декабря в 17:00 в прямом эфире на Twitch у нас большой созвон по девопсу!

В гости заглянут сразу двое:
Вячеслав Федосеев и Александр Крылов
Будем честно меряться тем, чем реально пользуемся в работе, сравнивать, спорить и много шутить. Разберём по полочкам:

1) Инструменты, которые крутим каждый день:
👉🏻 kubectl vs k9s vs Lens vs kube-dashboard — кто у кого выигрывает в 2025?
👉🏻 bash vs fish vs другие расширения CLI — где продуктивность, а где фан?

2) Сервисы, без которых не живём в проде:
👉🏻 grafana + loki + prometheus vs zabbix + ELK (и вся «семья»: vector/click, victoria metrics, psql, mimir) — что брать под разные сценарии.
👉🏻 GitHub Actions vs Jenkins vs GitLab CI — где скорость, где боль, а где надёжность.

Обсудим самое жаркое по-девопсерски

И да, ещё раз для тех, кто любит напоминалки: 17 декабря, 17:00

Сс
ылку на трансляцию, как всегда, скину накануне)
👎4👍1🔥1