Пятничный деплой
4.46K 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 DevOps
🎯 Хитрый Kubernetes-совет: используй "Ephemeral Containers" для дебага продовых Pod-ов без рестартов

Обычно, если приложение в Pod’e зависло или ведёт себя странно, — запускают kubectl exec.
Но если контейнер крашится на старте или застрял в init-контейнере, exec уже не поможет.

💡 Решение: Ephemeral Containers
Это временный контейнер, который можно «вживить» в работающий Pod без его пересоздания.

Использование:

kubectl debug pod/<имя> -it --image=busybox


Что это даёт:

- можно зайти в Pod, даже если основной контейнер не запускается
- можно использовать инструменты, которых нет в образе (curl, tcpdump, bash)
- можно дебажить сеть, файловую систему, процессы, не ломая Pod
- идеальный способ разбирать живые инциденты в проде

Эта техника - спасение, когда логов мало, Pod не рестартится, а exec недоступен.
🔥26
Forwarded from /usr/bin
Ключевые различия между Docker и Containerd

Будучи основным компонентом Docker, Containerd стал популярным решением для контейнеризации, постепенно заменяя Docker в архитектуре Kubernetes. Эта статья прольет свет на различия между Docker и Containerd, что позволит лучше понять технологию контейнеризации.
🔥2
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Concurrency, Synchronization and Consistency. Пост №17. Введение в взаимную блокировку (deadlock). Решаем задачу об обедающих философах на Go.

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

Пять философов сидят вокруг круглого стола, перед каждым стоит тарелка спагетти. На столе между каждой парой ближайших философов лежит по одной вилке.

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

Каждый философ может взять ближайшую вилку (если она доступна) или положить — если он уже держит её. Взятие каждой вилки и возвращение её на стол являются раздельными действиями, которые должны выполняться одно за другим.


Задача: разработать алгоритм, при котором ни один из философов не будет голодать, то есть будет вечно чередовать приём пищи и размышления.

🔵 Наивная реализация

Предлагаю сначала ничего не выдумывать, а просто закодировать то что первым приходит в голову.

Go Playground

package main

import (
"fmt"
"sync"
)

func main() {
const philosophers = 5
forks := make([]sync.Mutex, philosophers)

for p := range philosophers {
go philosopher(p, &forks[p], &forks[(p+1)%philosophers])
}

quit := make(chan struct{})
<-quit
}

func philosopher(p int, left *sync.Mutex, right *sync.Mutex) {
for {
left.Lock()
right.Lock()

fmt.Println("Philosopher", p, "Eating...")

left.Unlock()
right.Unlock()

fmt.Println("Philosopher", p, "ate :)")
}
}


Не самый сложный код. Но есть загвоздка - он неправильный. Вилок столько же сколько и философов и когда каждый хватает левую то на столе не остается вилок. Программа зависла навсегда. Конец. У этой проблемы даже есть название - взаимная блокировка.

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

🔵 Просим философов быть менее предсказуемыми

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

Полный код: Go Playground

func philosopher(p int, left *sync.Mutex, right *sync.Mutex) {
for {
if p == 4 {
right.Lock()
left.Lock()
} else {
left.Lock()
right.Lock()
}

fmt.Println("Philosopher", p, "Eating...")
time.Sleep(time.Millisecond)
left.Unlock()
right.Unlock()

fmt.Println("Philosopher", p, "ate :)")
}
}


🔵Добавляем официанта

Вместо того чтобы вносить хак в программу и делать поведение участников непохожим на остальных можно добавить помощника - официанта.

Это классический пример синхронизации через семафор. Каждый философ перед тем как хвататься за вилки просит разрешения у официанта. Если он принял запрос, значит доступ к вилкам есть у 3х или менее философов, а значит мы не попадем во взаимную блокировку.

Полный код: Go Playground

steward := make(chan int, philosophers-1)

...

func philosopher(p int, left *sync.Mutex, right *sync.Mutex, steward chan int) {
for {

steward <- p
left.Lock()
right.Lock()
fmt.Println("Philosopher", p, "Eating...")
time.Sleep(time.Millisecond)

left.Unlock()
right.Unlock()
<-steward

fmt.Println("Philosopher", p, "ate :)")
}
}


🔵 Итоги
В несколько этапов мы прошли путь от решения в лоб до двух решений:
- с хаком в коде (у него есть название, кто знает пишите в комментарии)
- c семафором.

При этом не был рассмотрен вопрос - как сделать решение справедливым, чтобы все кушали поровну? Ставьте 🔥, если увижу ваш интерес - обязательно рассмотрим и этот вопрос.

На этом всё, буду рад вашей ОС и реакциям, особенно интересно узнать был ли пост понятен без предварительной теории. Ее могло быть много, но я осознанно сфокусировался на практике😇
4🔥2
Forwarded from PythonDigest
Как тестировать конфигурацию Nginx: корректность и информационная безопасность
https://habr.com/ru/articles/966914/

При разработке сложной системы часто приходится сталкиваться с необходимостью использования nginx в качестве reverse proxy. Один из частых сценариев использования это роутинг, список правил, регулирующих путь запроса во внутренние системы или путь между внутренними подсистемами.
Forwarded from Код и Капуста
Конструктор рейт лимитеров

Обычно рейт лимитеры состоят из кучи правил, которые нужно как-то комбинировать, и всё быстро превращается в бардак. Поэтому автор задумал сделать rate limiter, который легко собирается как конструктор.

Что значит гибкость для рейт лимитера
- Правильные примитивы - базовые кирпичики, из которых можно собрать что угодно
- Чёткая композиция - чтобы сочетания правил не ломали мозг.

Читаем, просвещаемся

#golang

https://kodikapusta.ru/news/27ld-konstruktor-reit-limiterov
Forwarded from Код и Капуста
Отладка с pprof и k6

Про pprof наверняка все знают. В статье автор еще раз показывает как им пользоваться, но прикольно что он использует k6 для нагрузки своего сервиса. k6 - это тулза от разработчиков графаны, скрипты для нагрузки можно писать на js. А для ограничения ресурсов CPU используется cgroup - это интересный подход для локального нагрузочного тестирования

#golang

https://kodikapusta.ru/news/42i9-otladka-s-pprof-i-k6
⚙️ Генерация CRUD-кода

protoc-gen-crud — это плагин для Protocol Buffers, который генерирует интерфейсы и реализации CRUD-операций.

Он создаёт два файла для каждого proto-файла: общий файл с интерфейсами (.pb.crud.go) и файл с конкретной реализацией для выбранной базы данных.

Поддерживаются основные операции создания, чтения, обновления и удаления как для SQLite, так и для PostgreSQL. Есть возможность работать с уникальными и составными ключами, временными метками, а также частичными обновлениями.

Установка сводится к добавлению плагина в PATH и запуску protoc с указанием параметра --go-crud_out.

➡️ Репозиторий

🔸 Алгоритмы и структуры данных
🔸 Получить консультацию менеджера
🔸 Сайт Академии 🔸 Сайт Proglib

🐸 Библиотека Go-разработчика

#GoToProduction
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevOps Deflope News
ConfigHub официально запустился — это стартап от Brian Grant (оригинальный архитектор Kubernetes), Alexis Richardson (основатель RabbitMQ и Weaveworks) и Jesper Joergensen (бывший продуктовый лид Heroku и топ Twilio). Летом 2024 они были в режиме стелса и только набирали команду, теперь вышли с готовым продуктом.

Проблема, за которую они взялись: управление конфигурациями в облачных системах превратилось в хаос. Настройки разбросаны по десяткам мест от Git-репозиториев и YAML-файлов до облачных сервисов и систем управления секретами. Чем больше мест, где всё это хранится, тем выше риск что-то сломать при изменениях.

ConfigHub предлагает подход Configuration as Data. Традиционные DevOps-тулы требуют, чтобы все изменения шли через пайплайн. ConfigHub позволяет в критической ситуации внести изменения напрямую, а затем автоматически привести всё в порядок и синхронизировать состояние в масштабе.

Продукт уже работает для пользователей Kubernetes, Helm и GitOps.

Учитывая, что команда уже создала Kubernetes, RabbitMQ и популяризировала GitOps, следить за их новым проектом точно стоит.

Источник — пост Alexis Richardson на LinkedIn.
Forwarded from DevOps&SRE Library
The $1,000 AWS mistake

A cautionary tale about AWS VPC networking, NAT Gateways, and how a missing VPC Endpoint turned our S3 data transfers into an expensive lesson.


https://www.geocod.io/code-and-coordinates/2025-11-18-the-1000-aws-mistake
Странно, но уже несколько человек за последние несколько дней спросило меня про комментарии к постам. Добавил, посмотрим, что получится
👍2👎1
Костя Крамлих рассказал как они в Яндекс Облаке сделали сеть надежнее https://habr.com/ru/companies/yandex/articles/920092/
Я от сети далек, но мне понравился подход к решению reliability проблем и, кажется, что его можно использовать примерно везде
🔥2👎1
Forwarded from Безумный кот
😎 Новая версия in-Cloud v1.1.0

Прошло всего два месяца с первого релиза, и мы снова готовы показать, что удалось сделать.

Новое: 😈
Search — поиск ресурсов
ResourceBadge — цветные бейджи с CamelCase
TogglerSegmented — мульти-переключатель
Toggler — переключатель
OwnerRefs — список владельцев ресурса
Events — события ресурса
SecretBase64Plain — отображение секрета с blur

• UI переведен на list-then-watch
(* если у ресурса есть поддержка watch, будет работать по событийной модели, если нет то поллинг)

• Базовые Actions в каждой таблице
• Секреты: автоматический base64-decrypt в UI
• SBOM-отчёты Pod / RS / Deploy / STS
• YamlEditor: readOnly / watch / reload
• Default-фабрики для всех ресурсов: Details, Breadcrumbs, CustomColumnsOverride
• CustomFormPrefill для массивов объектов
• White Label: Logo, Footer, TenantText

Улучшено: ☹️
• Цветовые схемы Badges синхронизированы с поиском
• Labels теперь могут вести на внешние ссылки (в т. ч. Search)
• Убраны мерцания при переходах между страницами
• CustomFormOverride запрещает менять Namespace у уже созданных ресурсов
• Обновлена обработка x-kubernetes-preserve-unknown-fields: true — теперь такие поля открываются во встроенном VSCode-editor с возможностью редактирования

Исправлено: 🙃
• PodLogs больше не зависает при старте

Итог: 😇
Единая модель Default Factory: базовая страница, события и консистентная навигация доступны для каждого ресурса.
Интерфейс стал стабильнее, визуальная тема — согласованнее.
Подготовлена основа для пользовательских фабрик и расширенного поиска.

Полезная информация:
- Информация
- Документация
- Демо стенд
- Исходники на GitHub

Лучшая ваша похвала — это: 🤪
• Вопросы по теме
• Поиск неточностей
• Советы, как сделать лучше
• И, конечно, ⭐️ на GitHub

*демо стенд не оптимизирован под телефоны (будет, но чуть позже)
Please open Telegram to view this post
VIEW IN TELEGRAM
2👎1
Помните, на прошлой неделе Cloudflare упал и уронил половину интернета?

Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.

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

Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.

Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️
👍6
Forwarded from GitHub Open Sauce
safedep/vet

vet — это инструмент безопасности цепочки поставок программного обеспечения с открытым исходным кодом, созданный для разработчиков и специалистов по безопасности

#golag

https://github.com/safedep/vet
Forwarded from DevOps
⚡️ Kubernetes Namespaces: базовое разделение ресурсов в кластере

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

Что такое Namespaces
- Представляют собой «виртуальные кластеры» внутри одного физического.
- Группируют Pods, Services, Deployments, ConfigMaps и другие объекты.
- Полезны для multi-team, multi-project и multi-environment конфигураций.

Зачем они нужны
- Упорядочивают ресурсы и уменьшают хаос в большом кластере.
- Исключают конфликты имён — одинаковые ресурсы могут существовать в разных пространствах.
- Обеспечивают изоляцию команд и повышают безопасность.
- Позволяют держать dev/staging/prod в одном кластере без пересечений.

Стандартные Namespaces
- default — используется, если не указан другой; размещает обычные рабочие нагрузки.
- kube-system — системные компоненты (CoreDNS, kube-proxy).
- kube-public — доступен всем, включая неаутентифицированных пользователей; хранит публичную информацию.
- kube-node-lease — хранит heartbeat-объекты для узлов, повышая производительность контроля состояния.

Работа с Namespaces
- Создание — через YAML или kubectl, используется для группировки и изоляции ресурсов.
- Переключение контекста — позволяет работать в нужном namespace без постоянного указания -n.
- Удаление — очищает пространство вместе со всеми объектами, удобно для сброса окружения.

Типовые use cases
- Разделение окружений: dev/test/prod.
- Изоляция команд.
- Ограничение потребления ресурсов с помощью quotas.
- Границы безопасности через NetworkPolicies.

Resource Quotas
- Ограничивают CPU, RAM и количество объектов внутри namespace.
- Защищают кластер от «пожирания» ресурсов одной командой или сервисом.

Network Policies
- Контролируют сетевой трафик между namespace'ами.
- Используются для разграничения изоляции в multi-tenant конфигурациях.

Best practices
- Разводить окружения по отдельным namespaces.
- Не размещать рабочие нагрузки в kube-system.
- Настраивать RBAC на уровне namespace.
- Использовать понятные naming-conventions.
- Добавлять quotas в общих кластерах.

📎 Полное руководство по Kubernetes: https://codewithdhanian.gumroad.com/l/jwjls
👎7👍21
Forwarded from Мониторим ИТ
Aliaksandr Valialkin - Cost-Effective Monitoring in Kubernetes

В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.

Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
👍7🔥21👎1
🔐 Postgresus - self-hosted инструмент для резервного копирования и мониторинга PostgreSQL базы данных

🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);

Запуск через Docker:
docker run -d 
--name postgresus
-p 4005:4005
-v ./postgresus-data:/postgresus-data
--restart unless-stopped
rostislavdugin/postgresus:latest


📌 GitHub
👍10🔥1