Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
Гора родила мышь, а я наконец родил статью на основе материала, про который рассказывал весной на PHDays 2025 и CodeFest 15.
https://habr.com/ru/articles/872918/
#api #oauth #my_publication
https://habr.com/ru/articles/872918/
#api #oauth #my_publication
Хабр
Токены доступа и API Gateway: как обеспечить безопасность запросов
Распределенные системы (aka микросервисы) набрали популярность и применяются все шире в современных реалиях. Сервисов становится больше, привычные задачи для них решаются сложнее, усложнились и...
Forwarded from Безумный кот
Прошло всего два месяца с первого релиза, и мы снова готовы показать, что удалось сделать.
Новое:
• 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
Forwarded from HABR FEED + OPENNET
Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше #habr
https://habr.com/ru/companies/flant/articles/970498/
Tags: nelm, helm, werf, open source, devops, kubernetes, cicd
Author: ilya-lesikov (Флант)
https://habr.com/ru/companies/flant/articles/970498/
Tags: nelm, helm, werf, open source, devops, kubernetes, cicd
Author: ilya-lesikov (Флант)
Хабр
Nelm vs Helm 4: что изменилось с новым релизом Helm и почему Nelm всё ещё лучше
Недавно вышел Helm 4, и это отличный повод снова сравнить его с нашей альтернативой — Nelm . В статье смотрим на новые возможности обоих проектов, детально разбираем их отличия и объясняем, что ждёт...
👍3
Forwarded from запуск завтра
Помните, на прошлой неделе Cloudflare упал и уронил половину интернета?
Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.
Круто, что они опубликовали его прямо в день падения. Обычно, одни согласования с юристами занимают дни.
Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.
Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️
Они пишут одни из лучших post-mortem’ов в индустрии. Последний — не исключение.
Круто, что они опубликовали его прямо в день падения. Обычно, одни согласования с юристами занимают дни.
Но самое впечатляющее для меня в этой истории — вот этот комментарий пользователя eastdakota на форуме hacker news.
Это Мэтью Принс, основатель и генеральный директор компании, которая обслуживает 20% всего интернет-трафика, рассказывает, как он сначала сидел на созвоне по починке аварии, а потом пригласил к себе домой бывшего техдира (тот захватил сына, показать, какая у папы работа) и главного юриста компании и они на троих сообразили текст в гугл-доке. Задали в нем вопросы технарям компании. Заказали еды. Включили ответы на вопросы в текст. Дали вычитать технарям. И опубликовали. И получился пост-мортем. ❤️
👍6
Forwarded from GitHub Open Sauce
safedep/vet
vet — это инструмент безопасности цепочки поставок программного обеспечения с открытым исходным кодом, созданный для разработчиков и специалистов по безопасности
#golag
https://github.com/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 или
- Переключение контекста — позволяет работать в нужном namespace без постоянного указания
- Удаление — очищает пространство вместе со всеми объектами, удобно для сброса окружения.
Типовые use cases
- Разделение окружений: dev/test/prod.
- Изоляция команд.
- Ограничение потребления ресурсов с помощью quotas.
- Границы безопасности через NetworkPolicies.
Resource Quotas
- Ограничивают CPU, RAM и количество объектов внутри namespace.
- Защищают кластер от «пожирания» ресурсов одной командой или сервисом.
Network Policies
- Контролируют сетевой трафик между namespace'ами.
- Используются для разграничения изоляции в multi-tenant конфигурациях.
Best practices
- Разводить окружения по отдельным namespaces.
- Не размещать рабочие нагрузки в
- Настраивать RBAC на уровне namespace.
- Использовать понятные naming-conventions.
- Добавлять quotas в общих кластерах.
📎 Полное руководство по Kubernetes: https://codewithdhanian.gumroad.com/l/jwjls
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👍2❤1
Forwarded from Мониторим ИТ
Aliaksandr Valialkin - Cost-Effective Monitoring in Kubernetes
В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.
Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
В этой записи доклада с Kubernetes Community Days Warsaw 2025 Александр Валялкин, соучредитель и технический директор VictoriaMetrics, объясняет, как создать экономичную, быструю и масштабируемую систему мониторинга.
Александр делится практическими советами о том, как современные системы мониторинга могут оставаться простыми, не жертвуя глубиной хранения. Также рассказывает про распространённые ошибки, связанные со сложными системами мониторинга, и показывает, как инструменты с открытым исходным кодом на основе Go могут обеспечить производительность и прозрачность при масштабировании.
👍7🔥2❤1👎1
🔐 Postgresus - self-hosted инструмент для резервного копирования и мониторинга PostgreSQL базы данных
🔥 Возможности:
- создание бекапов по расписанию для PostgreSQL 13-18;
- уведомления в Telegram, Slack, Discord, если бекап сломался или база недоступна;
- хранение бекапов локально, в S3 или Google Drive;
- health check базы данных раз в минуту;
- Apache 2.0 лицензия (полностью открытый);
Запуск через Docker:
📌 GitHub
🔥 Возможности:
- создание бекапов по расписанию для 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
Forwarded from linkmeup
Екатерина Истошина из Т-Банка и её история о том, как за год дежурные команды перешли от нервного тика и бесконечных инциндентов к контролю хаоса. Причём всё в цифрах, с конкретными тулами и без воды.
https://youtu.be/ccTMT2zgBtg
https://youtu.be/ccTMT2zgBtg
YouTube
Безнадежная надежность. Истошина Екатерина. Т-Банк
Год назад наши дежурные команды днем и ночью героически тушили бесконечные инциденты, ребята боялись дежурств, выгорали.
Расскажу о том, что нам помогло за год перейти от хаоса к контролю: инструменты и процессы, провалы и победы.
Цифры, инсайты и готовые…
Расскажу о том, что нам помогло за год перейти от хаоса к контролю: инструменты и процессы, провалы и победы.
Цифры, инсайты и готовые…
Forwarded from DevOps
Что умеет:
- следит за локальными и удалёнными Docker-хостами в одном окне
- умно перезапускает контейнеры с настраиваемой логикой повторов
- шлёт алерты в Telegram, Slack, Discord, Gotify и почту
- обновляет контейнеры по расписанию
- позволяет разворачивать Docker Run и Compose-пресеты прямо из UI
- показывает health-чеки и события в реальном времени
Github: https://github.com/darthnorse/dockmon
@pythonl
Please open Telegram to view this post
VIEW IN TELEGRAM
👎6👍2
Forwarded from Находки в опенсорсе
git-lfs: храним большие файлы в репозитории правильно
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
https://www.youtube.com/watch?v=82wj6y2rmR4
Вы сталкивались с проблемой, что рабочий проект клонируется 10 минут?
А когда начинаешь разбираться: почему так? То оказывается, что внутри десятки непережатых картинок для фронта, которые еще и менялись регулярно (а значит, оставили след в истории git навсегда).
Данная проблема влияет не только на локальное использование, ведь мы на самом деле довольно редко делаем
git clone с нуля, но и самое главное – на скорость всех наших сборок (если мы не используем fetch-depth: 1 или аналог, а использовать их надо). Решение: использовать git-lfs!
Я пригласил замечательного Олега Чирухина @tg_1red2black, чтобы обсудить:
- Как работает git-lfs на базовом уровне?
- Как мигрировать на него с базового сетапа?
- Как он устроен внутри? Поднимаем https://github.com/git-lfs/lfs-test-server и детально смотрим, что там внутри происходит
Ну и конечно чуть-чуть глянули исходники, они, кстати, на #go 🌚️️️️
Обсуждение: как вы храните большие файлы в рабочих проектах? Насколько большие файлы вы храните?
| Поддержать | YouTube | GitHub | Чат |
YouTube
Находки в опенсорсе: git-lfs, не засоряй репозиторий большими файлами зря! #git
GigaCode – AI-ассистент разработчика c агентным режимом. Это полноценный помощник разработчика, способный понимать контекст проекта и выполнять задачи от анализа до готового решения. Ассистент сам открывает нужные файлы, вносит изменения, запускает тесты…
🔥3👍1
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, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.
Без фейлов не обходится ни один крутой продукт, ну а истории успеха — «за ширмой» оказываются историями поисков и ошибок с удачным концом.
Поговорим про то, какие проблемы возникают под капотом инфраструктурных продуктов, как они решаются и какие уроки из этого получаются.
Спикеры:
☁️Василий Степанов, руководитель направления инфраструктурных сервисов, VK Cloud, VK Tech.
☁️Константин Крамлих, руководитель поднаправления сетевых продуктов, Yandex.Cloud.
☁️Секретный доклад: подробности добавим позднее.
Подробнее о докладах читайте на странице мероприятия.
Когда: 18 декабря, с 18:00 до 23:59
Где: Москва, Ленинградский пр., 70, офис VK Tech, БЦ «Алкон» (количество мест ограничено).
Приходите на встречу или участвуйте онлайн.
Зарегистрироваться.
👎2❤1👍1🔥1
Forwarded from Кубернетичек
https://victoriametrics.com/blog/kubernetes-cpu-go-gomaxprocs/
Попалась замечательная статья. Много по полочкам разложено. Особенно упомянули формулу расчёта cpu weight для cgroupv2, которую хотят дополнительно разжевать https://github.com/kubernetes/website/pull/52793/files.
Но есть нюанс (не в претензию к статье, она отличная)
Это не совсем так. cpu manager обеспечивает изоляцию только между pod'ами kubernetes, а не между всеми процессами в ОС. Служебные процессы могут и будут селиться на данные cpu.
https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy
Вообще непонятно, зачем так сложно писать в доке. Я сам пропустил это, пока на практике не столкнулся, что "эксклюзивность" не эксклюзивная в рамках всей ноды. И даже не всех контейнеров, а только которые контролирует kubernetes. Лишь когда перечитывал доку с какого-то раза, обратил внимание на shared pool.
У Datadog это упомянули, кстати, тоже можно почитать, но на мой вкус она не так интересно читается https://www.datadoghq.com/blog/kubernetes-cpu-requests-limits/
Попалась замечательная статья. Много по полочкам разложено. Особенно упомянули формулу расчёта 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/
VictoriaMetrics
Container CPU Requests & Limits Explained with GOMAXPROCS Tuning
When running Go apps in Kubernetes, default CPU thread scheduling can conflict with cgroup CPU limits. The runtime sees all host CPUs, but the container may only be allowed a fraction of one. This often leads to early throttling. Properly configuring GOMAXPROCS…
❤2👍2👎1
Forwarded from Kubernetes и кот Лихачева
Как и зачем мониторить внешний трафик в K8s 🥵 ?
Обычно внешний трафик зашифрован, и сложно понимать, что происходит внутри
Как? Ответ —
Но что делать с сертификатами? Смотрим дальше↘️
Для рецепта нам понадобится ещё и
☝️ Disclaimer: пример является упрощённым и не учитывает все возможные детали, а скорее является идеей, как вы можете реализовать подобное у себя
Итак, у нас есть внешний сервис, взаимодействия с которым мы хотим отслеживать, и работает он только по
🔸 сначала его опишем, чтобы
Создадим свой доверенный
🔸
🔸 дальше
🔸 и
🔸 создадим ещё сам сертификат на целевой хост:
Дальше используем в
Теперь нужно заставить приложения доверять сертификату. Для этого нужно будет в сервисы добавить этот
Например, в файл
Например:
Как это делать для каждого конкретного сервиса — каждый решает сам. Базово можно скриптом пробежаться по нужным репозиториям и в
И когда это будет сделано и сервисы задеплоены, опишем
И
В итоге получим метрики общения с внешней системой без дополнительной инструментации сервисов👍
Конечно же Istio может помимо этого добавить больше интересных механик:
Обычно внешний трафик зашифрован, и сложно понимать, что происходит внутри
HTTPS-соединений. Инструментировать все сервисы нормальной телеметрией может быть долго и накладно, а видеть внешние зависимости хочется...Как? Ответ —
IstioНо что делать с сертификатами? Смотрим дальше
Для рецепта нам понадобится ещё и
cert-manager, установленный в кластерИтак, у нас есть внешний сервис, взаимодействия с которым мы хотим отслеживать, и работает он только по
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=trueapiVersion: 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-инженерам.
Записаться на дискуссию можно по ссылке.
Компания «Инфосистемы Джет» приглашает на дискуссию о Telco Cloud — облачной платформе, созданной по стандартам телеком-индустрии. Эти отработанные технологии могут использоваться не только для операторов, но и для других отраслей: финтеха, ритейла, логистики и промышленности.
На дискуссии эксперты обсудят:
• Технологические особенности телеком-облака, которые отличают его от частных облаков;
• Use-cases на базе Telco Cloud: IoT, Edge Computing, AI/ML, Private 5G и SD-WAN;
• Применимость архитектурные паттернов телекома для задач из других отраслей;
• «Идеальное облако» по мнению экспертов и различные подходы.
Мероприятие будет полезно техническим директорам, руководителям ИТ-отделов и бизнес-направлений, архитекторам облачных платформ, а также DevOps-инженерам.
Записаться на дискуссию можно по ссылке.
👎1
Forwarded from лес, горы и кубернетис
CF снова пал. Не хотел бы я быть тем инженером что за него отвечает
👍8🔥3
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Concurrency, Synchronization and Consistency. Пост №18. Golang sync.Mutex internals
В прошлом посте мы решали практическую задачку и использовали язык Go. Его основная особенность - наличие собственного рантайма в рамках которого происходит управление и планирование горутин - потоков исполнения не связанных явно 1к1 с потоками ОС.
А если у языка собственный рантайм и "собственные" потоки, то и должны быть "собственные" примитивы синхронизации, умеющие работать с горутинами. И они действительно есть. Основным примитивом синхронизации в Go является
У ребят из VictoriaMetrics получился великолепный разбор внутреннего устройства
Поэтому советую освежить в памяти предыдущие посты цикла. Увидите, что многие идеи и оптимизации придуманные для ОС были использованы в рантайме Go. Уровень абстракции выше, а проблемы и вызовы такие же😊
Внутри вас ждёт:
- Внутреннее представление
- Как выглядят
- Как
- Как происходит
https://victoriametrics.com/blog/go-sync-mutex/
-----
Если вам понравился пост, поддержите его реакциями и комментариями. Мне важно увидеть вашу обратную связь. Спасибо!
P.S. Следующая публикация вероятнее всего будет на Хабре, выпуск намечен на следующую неделю. Будем как в прошлый раз писать свои велосипеды в погоне повторить эталонные реализации, оценивать результаты бенчмарками и профилями😊
В прошлом посте мы решали практическую задачку и использовали язык 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. Следующая публикация вероятнее всего будет на Хабре, выпуск намечен на следующую неделю. Будем как в прошлый раз писать свои велосипеды в погоне повторить эталонные реализации, оценивать результаты бенчмарками и профилями😊
VictoriaMetrics
Go sync.Mutex: Normal and Starvation Mode
Mutex in Go has two main flows: Lock and Unlock and 2 modes: Normal and Starvation Mode. The state field of mutex is a 32-bit integer that represents the current state, it’s divided into multiple bits that encode various pieces of information about the mutex.
🔥2👍1