Потеря в пути: отладка потерянных пакетов из-за отрицательной длины заголовка
Ранее я писал о создании сетевых балансировщиков нагрузки с планировщиком maglev, который мы используем для входа в наши кластеры Kubernetes. На момент написания этой заметки мы использовали инкапсуляцию Foo-over-UDP с виртуальными интерфейсами, по одному для каждой версии интернет-протокола на каждом рабочем узле.
Чтобы сократить трудозатраты на управление узлами-директорами трафика, мы недавно перешли на использование встроенной поддержки инкапсуляции в IP Virtual Server (IPVS). К нашему удивлению, вместо плавного перехода мы наблюдали значительное снижение пропускной способности и отказы в выполнении API-запросов. В этом посте я расскажу о наблюдаемом эффекте, поиске первопричины в течение нескольких недель и окончательном решении проблемы.
https://blog.cloudflare.com/lost-in-transit-debugging-dropped-packets-from-negative-header-lengths
#devops #девопс
Подпишись 👉@i_DevOps
Ранее я писал о создании сетевых балансировщиков нагрузки с планировщиком maglev, который мы используем для входа в наши кластеры Kubernetes. На момент написания этой заметки мы использовали инкапсуляцию Foo-over-UDP с виртуальными интерфейсами, по одному для каждой версии интернет-протокола на каждом рабочем узле.
Чтобы сократить трудозатраты на управление узлами-директорами трафика, мы недавно перешли на использование встроенной поддержки инкапсуляции в IP Virtual Server (IPVS). К нашему удивлению, вместо плавного перехода мы наблюдали значительное снижение пропускной способности и отказы в выполнении API-запросов. В этом посте я расскажу о наблюдаемом эффекте, поиске первопричины в течение нескольких недель и окончательном решении проблемы.
https://blog.cloudflare.com/lost-in-transit-debugging-dropped-packets-from-negative-header-lengths
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Анализ энергозависимой памяти на узле Google Kubernetes Engine
В компании Spotify мы используем контейнерные рабочие нагрузки на производстве по всей организации в пяти регионах, где наши основные продакшены находятся в Google Kubernetes Engine (GKE) на Google Cloud Platform (GCP). Если мы обнаруживаем подозрительное поведение наших рабочих нагрузок, мы должны иметь возможность быстро проанализировать его и определить, не произошло ли что-то вредоносное. Сегодня мы используем коммерческие решения для мониторинга, но также проводим собственные исследования, чтобы найти варианты и альтернативные методы.
https://engineering.atspotify.com/2023/06/analyzing-volatile-memory-on-a-google-kubernetes-engine-node/
#devops #девопс
Подпишись 👉@i_DevOps
В компании Spotify мы используем контейнерные рабочие нагрузки на производстве по всей организации в пяти регионах, где наши основные продакшены находятся в Google Kubernetes Engine (GKE) на Google Cloud Platform (GCP). Если мы обнаруживаем подозрительное поведение наших рабочих нагрузок, мы должны иметь возможность быстро проанализировать его и определить, не произошло ли что-то вредоносное. Сегодня мы используем коммерческие решения для мониторинга, но также проводим собственные исследования, чтобы найти варианты и альтернативные методы.
https://engineering.atspotify.com/2023/06/analyzing-volatile-memory-on-a-google-kubernetes-engine-node/
#devops #девопс
Подпишись 👉@i_DevOps
👍2❤1
Автоматизация AWS SSO с помощью Terraform
Использование Terraform для автоматизации установки и настройки ресурсов SSO, упрощения управления пользователями и повышения уровня безопасности.
https://medium.com/cloud-native-daily/automate-aws-sso-using-terraform-2f219a45c16f
#devops #девопс
Подпишись 👉@i_DevOps
Использование Terraform для автоматизации установки и настройки ресурсов SSO, упрощения управления пользователями и повышения уровня безопасности.
https://medium.com/cloud-native-daily/automate-aws-sso-using-terraform-2f219a45c16f
#devops #девопс
Подпишись 👉@i_DevOps
👍5
Лучшие практики мониторинга статических веб-приложений
Статические сайты в настоящее время являются популярным решением для многих легких веб-приложений, таких как корпоративные сайты, блоги, сайты объявлений о работе и хранилища документации. В статической веб-архитектуре страницы генерируются и предварительно рендерятся во время сборки из файлов разметки и обычно кэшируются в сети доставки контента (CDN) для эффективной доставки. Это позволяет командам экономить на управлении серверами и обеспечивает быструю загрузку страниц.
https://www.datadoghq.com/blog/static-web-application-monitoring-best-practices/
#devops #девопс
Подпишись 👉@i_DevOps
Статические сайты в настоящее время являются популярным решением для многих легких веб-приложений, таких как корпоративные сайты, блоги, сайты объявлений о работе и хранилища документации. В статической веб-архитектуре страницы генерируются и предварительно рендерятся во время сборки из файлов разметки и обычно кэшируются в сети доставки контента (CDN) для эффективной доставки. Это позволяет командам экономить на управлении серверами и обеспечивает быструю загрузку страниц.
https://www.datadoghq.com/blog/static-web-application-monitoring-best-practices/
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Решение проблем, вызванных Out Of Memory (OOM) Killer в Linux
Узнайте, как события Out Of Memory создавали проблемы для нашей команды и как мы их решали.
События Out of memory (OOM) часто встречаются в среде Linux, когда есть программы, занимающие много памяти. Redpanda - одна из таких программ, поскольку она использует библиотеку Seastar, которая пытается использовать все аппаратное обеспечение до предела.
Существует специальная функциональность ядра, называемая Out Of Memory Killer (OOM Killer), которая помогает поддерживать работоспособность Linux-машин, убивая самый большой процесс с наименьшим приоритетом. OOM Killer может распознавать и учитывать процессы, которые имеют ограничения в Linux cgroups.
Если вы не указываете входные параметры, Redpanda считывает доступную аппаратную память и выделяет не менее 1,5 Гб для операционной системы (ОС), а остальное делит поровну для каждого ядра машины, чтобы максимизировать эффективность работы распределителя памяти Seastar. Если Redpanda запущена вместе с другими программами, операционной системе Linux может не хватить памяти.
https://redpanda.com/blog/solve-out-of-memory-killer-events
#devops #девопс
Подпишись 👉@i_DevOps
Узнайте, как события Out Of Memory создавали проблемы для нашей команды и как мы их решали.
События Out of memory (OOM) часто встречаются в среде Linux, когда есть программы, занимающие много памяти. Redpanda - одна из таких программ, поскольку она использует библиотеку Seastar, которая пытается использовать все аппаратное обеспечение до предела.
Существует специальная функциональность ядра, называемая Out Of Memory Killer (OOM Killer), которая помогает поддерживать работоспособность Linux-машин, убивая самый большой процесс с наименьшим приоритетом. OOM Killer может распознавать и учитывать процессы, которые имеют ограничения в Linux cgroups.
Если вы не указываете входные параметры, Redpanda считывает доступную аппаратную память и выделяет не менее 1,5 Гб для операционной системы (ОС), а остальное делит поровну для каждого ядра машины, чтобы максимизировать эффективность работы распределителя памяти Seastar. Если Redpanda запущена вместе с другими программами, операционной системе Linux может не хватить памяти.
https://redpanda.com/blog/solve-out-of-memory-killer-events
#devops #девопс
Подпишись 👉@i_DevOps
👍2
Простой способ понять Docker
Docker известен во всем мире как поставщик контейнерных услуг с открытым исходным кодом, который отлично справляется с упаковкой приложений и их компонентов, а также зависимостей, упрощая процесс развертывания. Это мощный и универсальный инструмент, который упрощает создание, запуск и управление программными приложениями. Однако прежде чем мы погрузимся во внутреннюю работу Docker, давайте разберемся в фундаментальной концепции контейнеров.
https://julia.hashnode.dev/an-easy-way-to-understand-docker
#devops #девопс
Подпишись 👉@i_DevOps
Docker известен во всем мире как поставщик контейнерных услуг с открытым исходным кодом, который отлично справляется с упаковкой приложений и их компонентов, а также зависимостей, упрощая процесс развертывания. Это мощный и универсальный инструмент, который упрощает создание, запуск и управление программными приложениями. Однако прежде чем мы погрузимся во внутреннюю работу Docker, давайте разберемся в фундаментальной концепции контейнеров.
https://julia.hashnode.dev/an-easy-way-to-understand-docker
#devops #девопс
Подпишись 👉@i_DevOps
Защита сред AWS с помощью Terraform, Vault и Veeam
Я рад представить вам первую статью из серии блогов, посвященных оптимизации управления облачной инфраструктурой, безопасности данных и автоматизации резервного копирования в среде AWS. В этом посте я предоставлю вам пошаговое руководство по использованию Terraform, Hashicorp Vault и Veeam на AWS.
Давайте начнем!
https://julia.hashnode.dev/secure-your-aws-environments-with-terraform-vault-and-veeam
#devops #девопс
Подпишись 👉@i_DevOps
Я рад представить вам первую статью из серии блогов, посвященных оптимизации управления облачной инфраструктурой, безопасности данных и автоматизации резервного копирования в среде AWS. В этом посте я предоставлю вам пошаговое руководство по использованию Terraform, Hashicorp Vault и Veeam на AWS.
Давайте начнем!
https://julia.hashnode.dev/secure-your-aws-environments-with-terraform-vault-and-veeam
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Как использовать роли Ansible
В этом блоге вы узнаете об основах ролей Ansible. С помощью Ansible Roles вы можете повторно использовать созданный вами контент Ansible и делиться им с другими пользователями. Вы узнаете об Ansible Roles шаг за шагом на примерах.
https://mydeveloperplanet.com/2023/03/01/how-to-use-ansible-roles/
#devops #девопс
Подпишись 👉@i_DevOps
В этом блоге вы узнаете об основах ролей Ansible. С помощью Ansible Roles вы можете повторно использовать созданный вами контент Ansible и делиться им с другими пользователями. Вы узнаете об Ansible Roles шаг за шагом на примерах.
https://mydeveloperplanet.com/2023/03/01/how-to-use-ansible-roles/
#devops #девопс
Подпишись 👉@i_DevOps
👍3
🗄️Подборка каналов для каждого безопасника и сетевика
🛡ZeroDay - уроки по кибербезопасности и хакингу от нуля до профи, вирусы, взломы, osint, криптография и свежие новости
🌐 Серверная Админа - большое количество уроков и статей по устройству компьютерных сетей. Кладезь информации для безопасника
🛡ZeroDay - уроки по кибербезопасности и хакингу от нуля до профи, вирусы, взломы, osint, криптография и свежие новости
🌐 Серверная Админа - большое количество уроков и статей по устройству компьютерных сетей. Кладезь информации для безопасника
Вышел релиз GitLab 16.7 с GitLab Duo Code Suggestions в общем доступе и бета-версией каталога CI/CD
https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/
#devops #девопс
Подпишись 👉@i_DevOps
https://about.gitlab.com/releases/2023/12/21/gitlab-16-7-released/
#devops #девопс
Подпишись 👉@i_DevOps
GitLab
GitLab 16.7 released with general availability of GitLab Duo Code Suggestions and CI/CD Catalog in Beta
GitLab 16.7 released with general availability of GitLab Duo Code Suggestions, CI/CD Catalog in Beta, new drill-down view from Insights report charts, SAST results in MR changes view, and much more!
👍3
Sre-checklist
Контрольный список для всех, кто занимается проектированием надежности сайта
🎯 Цель: Дать командам и отдельным людям представление о том, что нужно учитывать и к чему стремиться в области SRE и в работе.
Примечание: эти контрольные списки составлены с учетом моего мнения. Они основаны на моем собственном мнении и опыте и не являются универсальной истиной (да! 😄). Поэтому вы должны сомневаться во всем, что здесь прочитаете, и вы можете высказать свое собственное мнение по этому вопросу, начав обсуждение или предложив изменения в проект
🚧 Вы можете сказать, что этот репозиторий все еще находится в процессе разработки. Я бы не стал рассматривать его как полный исходный код на данный момент или что-то близкое к этому. Вклад в проект более чем приветствуется!
https://github.com/bregman-arie/sre-checklist
#devops #девопс
Подпишись 👉@i_DevOps
Контрольный список для всех, кто занимается проектированием надежности сайта
🎯 Цель: Дать командам и отдельным людям представление о том, что нужно учитывать и к чему стремиться в области SRE и в работе.
Примечание: эти контрольные списки составлены с учетом моего мнения. Они основаны на моем собственном мнении и опыте и не являются универсальной истиной (да! 😄). Поэтому вы должны сомневаться во всем, что здесь прочитаете, и вы можете высказать свое собственное мнение по этому вопросу, начав обсуждение или предложив изменения в проект
🚧 Вы можете сказать, что этот репозиторий все еще находится в процессе разработки. Я бы не стал рассматривать его как полный исходный код на данный момент или что-то близкое к этому. Вклад в проект более чем приветствуется!
https://github.com/bregman-arie/sre-checklist
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Руководство по GitOps: ArgoCD против Flux
GitOps стал чрезвычайно популярным способом управления инфраструктурой и приложениями Kubernetes. Используя Git в качестве единого источника, GitOps позволяет использовать инфраструктуру как код и автоматизировать развертывание приложений в Kubernetes. Этот подход сегодня используют многие компании, поэтому я хотел поделиться нашим путешествием по GitOps в серии постов на эту тему.
https://www.codereliant.io/gitops-guide-argocd-vs-flux/
#devops #девопс
Подпишись 👉@i_DevOps
GitOps стал чрезвычайно популярным способом управления инфраструктурой и приложениями Kubernetes. Используя Git в качестве единого источника, GitOps позволяет использовать инфраструктуру как код и автоматизировать развертывание приложений в Kubernetes. Этот подход сегодня используют многие компании, поэтому я хотел поделиться нашим путешествием по GitOps в серии постов на эту тему.
https://www.codereliant.io/gitops-guide-argocd-vs-flux/
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Пробки в облаке: Перегрузки снижают надежность ваших приложений?
Представьте себе оживленную систему автомагистралей - сложную сеть дорог, мостов, туннелей и перекрестков, каждая из которых рассчитана на определенный объем движения. А теперь подумайте о событиях, которые приводят к пробкам: авариях, дорожных работах или внезапном наплыве автомобилей. Эти происшествия вызывают заторы на дорогах, и часто затор на одном участке шоссе вызывает затор на другом. Например, затор на мосту может привести к затору на дороге, ведущей к нему. Заторы создают множество проблем, начиная от задержек и увеличения времени в пути и заканчивая раздражением водителей из-за потерянного времени и слишком большого количества сожженного топлива. Такие сбои в работе наносят ущерб не только водителям, но и всей экономике. Задерживаются товары, нарушается предоставление услуг, поскольку сотрудники приходят на работу с опозданием (и в раздражении).
https://blog.fluxninja.com/blog/traffic-jams-in-the-cloud-unveiling-the-true-enemy-of-reliability
#devops #девопс
Подпишись 👉@i_DevOps
Представьте себе оживленную систему автомагистралей - сложную сеть дорог, мостов, туннелей и перекрестков, каждая из которых рассчитана на определенный объем движения. А теперь подумайте о событиях, которые приводят к пробкам: авариях, дорожных работах или внезапном наплыве автомобилей. Эти происшествия вызывают заторы на дорогах, и часто затор на одном участке шоссе вызывает затор на другом. Например, затор на мосту может привести к затору на дороге, ведущей к нему. Заторы создают множество проблем, начиная от задержек и увеличения времени в пути и заканчивая раздражением водителей из-за потерянного времени и слишком большого количества сожженного топлива. Такие сбои в работе наносят ущерб не только водителям, но и всей экономике. Задерживаются товары, нарушается предоставление услуг, поскольку сотрудники приходят на работу с опозданием (и в раздражении).
https://blog.fluxninja.com/blog/traffic-jams-in-the-cloud-unveiling-the-true-enemy-of-reliability
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Притормози! Глубокое погружение в ограничение скорости
В этом посте мы обсудим важность и реализацию механизмов ограничения скорости для повышения надежности API.
Что такое ограничение скорости? Это механизм контроля, определяющий, как часто пользователь может обращаться к вашему API в течение определенного времени.
Итак, почему вас должно волновать ограничение скорости? Рассмотрим ситуацию, когда к вашему API поступает огромное количество запросов за короткий промежуток времени. Это может быть связано с резким увеличением трафика пользователей, сбоем, вызывающим повторные запросы, или даже попыткой перегрузить вашу систему с помощью DDOS-атаки. Без ограничения скорости ваша система может быть перегружена, что приведет к медленным ответам или, что еще хуже, к полному отказу в обслуживании.
Но преимущества ограничения скорости выходят за рамки просто защиты вашей системы. Это также инструмент для управления использованием сервиса. Оно помогает применять политики использования API, контролировать квоты API и даже предлагать клиентам многоуровневые планы использования. Проще говоря, ограничение скорости - это ключевой игрок в эффективном управлении API.
https://www.codereliant.io/rate-limiting-deep-dive/
#devops #девопс
Подпишись 👉@i_DevOps
В этом посте мы обсудим важность и реализацию механизмов ограничения скорости для повышения надежности API.
Что такое ограничение скорости? Это механизм контроля, определяющий, как часто пользователь может обращаться к вашему API в течение определенного времени.
Итак, почему вас должно волновать ограничение скорости? Рассмотрим ситуацию, когда к вашему API поступает огромное количество запросов за короткий промежуток времени. Это может быть связано с резким увеличением трафика пользователей, сбоем, вызывающим повторные запросы, или даже попыткой перегрузить вашу систему с помощью DDOS-атаки. Без ограничения скорости ваша система может быть перегружена, что приведет к медленным ответам или, что еще хуже, к полному отказу в обслуживании.
Но преимущества ограничения скорости выходят за рамки просто защиты вашей системы. Это также инструмент для управления использованием сервиса. Оно помогает применять политики использования API, контролировать квоты API и даже предлагать клиентам многоуровневые планы использования. Проще говоря, ограничение скорости - это ключевой игрок в эффективном управлении API.
https://www.codereliant.io/rate-limiting-deep-dive/
#devops #девопс
Подпишись 👉@i_DevOps
👍6
Faasd
Это переосмысленный OpenFaaS, но без стоимости и сложности Kubernetes. Он работает на одном хосте с очень скромными требованиями, что делает его быстрым и простым в управлении. Под капотом он использует containerd и Container Networking Interface (CNI) вместе с теми же основными компонентами OpenFaaS из основного проекта.
https://github.com/openfaas/faasd
#devops #девопс
Подпишись 👉@i_DevOps
Это переосмысленный OpenFaaS, но без стоимости и сложности Kubernetes. Он работает на одном хосте с очень скромными требованиями, что делает его быстрым и простым в управлении. Под капотом он использует containerd и Container Networking Interface (CNI) вместе с теми же основными компонентами OpenFaaS из основного проекта.
https://github.com/openfaas/faasd
#devops #девопс
Подпишись 👉@i_DevOps
👍4❤2
Devops-exercises
Вопросы для собеседования по DevOps
Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization.
https://github.com/bregman-arie/devops-exercises
#devops #девопс
Подпишись 👉@i_DevOps
Вопросы для собеседования по DevOps
Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization.
https://github.com/bregman-arie/devops-exercises
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Pipeline CI/CD, объясненный простыми словами
Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.
Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.
Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена.
Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене
#devops #девопс
Подпишись 👉@i_DevOps
Раздел 1 - SDLC с CI/CD
Жизненный цикл разработки программного обеспечения (SDLC) состоит из нескольких ключевых этапов: разработка, тестирование, развертывание и сопровождение. CI/CD автоматизирует и интегрирует эти этапы, чтобы обеспечить более быстрые и надежные релизы.
Когда код размещается в git-репозитории, он запускает автоматизированный процесс сборки и тестирования. Для проверки кода запускаются сквозные (e2e) тесты. Если тесты пройдены, код может быть автоматически развернут на этапе staging/продакшен. Если обнаружены проблемы, код возвращается в разработку для исправления ошибок. Такая автоматизация обеспечивает быструю обратную связь с разработчиками и снижает риск появления ошибок в продакшене.
Раздел 2 - Разница между CI и CD
Непрерывная интеграция (CI) автоматизирует процесс сборки, тестирования и слияния. Она запускает тесты при коммите кода, чтобы обнаружить проблемы интеграции на ранней стадии. Это стимулирует частые коммиты кода и быструю обратную связь.
Continuous Delivery (CD) автоматизирует процессы выпуска, такие как изменение инфраструктуры и развертывание. Она обеспечивает надежный выпуск программного обеспечения в любое время благодаря автоматизированным рабочим процессам. CD также может автоматизировать ручное тестирование и этапы утверждения, необходимые перед развертыванием продакшена.
Раздел 3 - CI/CD Pipeline
Типичный pipeline CI/CD состоит из нескольких взаимосвязанных этапов:
- Разработчик коммитит изменения кода в системе контроля исходного кода
- CI-сервер обнаруживает изменения и запускает сборку
- Код компилируется, тестируется (модульные, интеграционные тесты)
- Результаты тестирования сообщаются разработчику
- При успешном завершении артефакты развертываются в среде staging.
- Дальнейшее тестирование может быть проведено в среде staging перед выпуском.
- Система CD развертывает одобренные изменения в продакшене
#devops #девопс
Подпишись 👉@i_DevOps
👍11❤1
BlazingMQ
Современная высокопроизводительная система очередей сообщений с открытым исходным кодом
BlazingMQ - это фреймворк распределенных очередей сообщений с открытым исходным кодом, который ориентирован на эффективность, надежность и богатый набор функций для современных рабочих процессов.
В основе BlazingMQ лежат долговечные, отказоустойчивые, высокопроизводительные и высокодоступные очереди, а также такие функции, как различные стратегии маршрутизации сообщений (например, рабочие очереди, приоритетные, веерные, широковещательные и т. д.), сжатие, высокая согласованность, обнаружение ядовитых пилюль и т. д.
Очереди сообщений обычно обеспечивают слабосвязанный, асинхронный канал связи ("очередь") между прикладными сервисами (производителями и потребителями), которые отправляют сообщения друг другу. Можно представить это как почтовый ящик для связи между прикладными программами, где "производитель" опускает сообщение в почтовый ящик, а "потребитель" забирает его по своему усмотрению. Сообщения, помещенные в очередь, хранятся до тех пор, пока получатель не получит и не обработает их. Другими словами, приложения-производители и приложения-потребители могут временно и пространственно изолироваться друг от друга, используя очередь сообщений для облегчения взаимодействия.
Внутренняя часть BlazingMQ (брокеры сообщений) была реализована на C++, а клиентские библиотеки доступны на C++, Java и Python.
BlazingMQ - активно развивающийся проект, который был продакшен в Bloomberg в течение 8 с лишним лет.
Этот репозиторий содержит брокер сообщений BlazingMQ, клиентскую библиотеку BlazingMQ C++ и инструмент командной строки BlazingMQ, а клиентскую библиотеку BlazingMQ Java можно найти в этом репозитории.
https://github.com/bloomberg/blazingmq
#devops #девопс
Подпишись 👉@i_DevOps
Современная высокопроизводительная система очередей сообщений с открытым исходным кодом
BlazingMQ - это фреймворк распределенных очередей сообщений с открытым исходным кодом, который ориентирован на эффективность, надежность и богатый набор функций для современных рабочих процессов.
В основе BlazingMQ лежат долговечные, отказоустойчивые, высокопроизводительные и высокодоступные очереди, а также такие функции, как различные стратегии маршрутизации сообщений (например, рабочие очереди, приоритетные, веерные, широковещательные и т. д.), сжатие, высокая согласованность, обнаружение ядовитых пилюль и т. д.
Очереди сообщений обычно обеспечивают слабосвязанный, асинхронный канал связи ("очередь") между прикладными сервисами (производителями и потребителями), которые отправляют сообщения друг другу. Можно представить это как почтовый ящик для связи между прикладными программами, где "производитель" опускает сообщение в почтовый ящик, а "потребитель" забирает его по своему усмотрению. Сообщения, помещенные в очередь, хранятся до тех пор, пока получатель не получит и не обработает их. Другими словами, приложения-производители и приложения-потребители могут временно и пространственно изолироваться друг от друга, используя очередь сообщений для облегчения взаимодействия.
Внутренняя часть BlazingMQ (брокеры сообщений) была реализована на C++, а клиентские библиотеки доступны на C++, Java и Python.
BlazingMQ - активно развивающийся проект, который был продакшен в Bloomberg в течение 8 с лишним лет.
Этот репозиторий содержит брокер сообщений BlazingMQ, клиентскую библиотеку BlazingMQ C++ и инструмент командной строки BlazingMQ, а клиентскую библиотеку BlazingMQ Java можно найти в этом репозитории.
https://github.com/bloomberg/blazingmq
#devops #девопс
Подпишись 👉@i_DevOps
👍1
Создание успешной команды SRE
Успешные приемы, позволяющие вашей команде SRE приносить пользу
Когда я пришел в Mission Lane, я был одним из двух инженеров по надежности сайтов (SRE); вторым был мой начальник, руководитель группы SRE и впоследствии директор организации по платформам. Нам было поручено создать команду SRE, которая занималась бы вопросами наблюдаемости и опыта разработчиков. Это положило начало трехлетнему пути, в ходе которого была создана успешная организация SRE, приносящая огромную пользу Mission Lane. Команда SRE состояла из четырех человек, которые поддерживали 250 микросервисов, 130 разработчиков, сотни релизов в различных средах каждый день и около миллиарда журналов и трассировок каждый день.
https://blog.hans-knecht.com/building-a-successful-sre-team-283232bc2694
#devops #девопс
Подпишись 👉@i_DevOps
Успешные приемы, позволяющие вашей команде SRE приносить пользу
Когда я пришел в Mission Lane, я был одним из двух инженеров по надежности сайтов (SRE); вторым был мой начальник, руководитель группы SRE и впоследствии директор организации по платформам. Нам было поручено создать команду SRE, которая занималась бы вопросами наблюдаемости и опыта разработчиков. Это положило начало трехлетнему пути, в ходе которого была создана успешная организация SRE, приносящая огромную пользу Mission Lane. Команда SRE состояла из четырех человек, которые поддерживали 250 микросервисов, 130 разработчиков, сотни релизов в различных средах каждый день и около миллиарда журналов и трассировок каждый день.
https://blog.hans-knecht.com/building-a-successful-sre-team-283232bc2694
#devops #девопс
Подпишись 👉@i_DevOps
👍6
This media is not supported in your browser
VIEW IN TELEGRAM
TFTUI - The Terraform textual UI
С помощью последней версии вы можете легко визуализировать полное дерево состояний, получая более глубокое представление о текущей конфигурации вашей инфраструктуры. Кроме того, возможность поиска по дереву и просмотра отдельных состояний ресурсов позволяет сосредоточиться на конкретных деталях для более эффективного анализа и управления. Также можно выбрать конкретные ресурсы и выполнить такие действия, как удаление. Наконец, теперь вы можете создавать и применять планы прямо из пользовательского интерфейса.
Ключевые особенности
Комплексное отображение всего дерева состояний Terraform
Удобный просмотр и навигация по состоянию одного ресурса
Поиск по дереву состояний и определениям ресурсов
Создавайте планы, отображайте их в полном объеме и применяйте их непосредственно из интерфейса TUI
Выбор одного/нескольких ресурсов
Операции над ресурсами: восстановление, очистка, удаление, уничтожение
Поддержка Terraform (например, terragrunt)
https://github.com/idoavrah/terraform-tui
#devops #девопс
Подпишись 👉@i_DevOps
С помощью последней версии вы можете легко визуализировать полное дерево состояний, получая более глубокое представление о текущей конфигурации вашей инфраструктуры. Кроме того, возможность поиска по дереву и просмотра отдельных состояний ресурсов позволяет сосредоточиться на конкретных деталях для более эффективного анализа и управления. Также можно выбрать конкретные ресурсы и выполнить такие действия, как удаление. Наконец, теперь вы можете создавать и применять планы прямо из пользовательского интерфейса.
Ключевые особенности
Комплексное отображение всего дерева состояний Terraform
Удобный просмотр и навигация по состоянию одного ресурса
Поиск по дереву состояний и определениям ресурсов
Создавайте планы, отображайте их в полном объеме и применяйте их непосредственно из интерфейса TUI
Выбор одного/нескольких ресурсов
Операции над ресурсами: восстановление, очистка, удаление, уничтожение
Поддержка Terraform (например, terragrunt)
https://github.com/idoavrah/terraform-tui
#devops #девопс
Подпишись 👉@i_DevOps
👍4
Современная безопасность контейнерных приложений
Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.
Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:
научиться строить безопасный деплой,
автоматизировать проверки безопасности,
понимать проблемы и обсуждать их в команде.
Если вы столкнулись с новыми реалиями и требованиями безопасности и не знаете, с чего начать, эта статья может вам пригодиться. В качестве примеров будем рассматривать продукты и инфраструктуру Yandex Cloud, но большинство рекомендаций универсальны и не привязаны к конкретным сервисам.
https://habr.com/ru/companies/oleg-bunin/articles/786930/
#devops #девопс
Подпишись 👉@i_DevOps
Чем раньше команда задумается о проблеме безопасности, тем лучше. В этой статье обсудим, какие проблемы ИБ есть в стандартном контейнерном приложении, поговорим о безопасности использования Docker, Kubernetes и Terraform и разберём, как можно встроить проверки в стандартный пайплайн деплоя.
Материал написан и дополнен по мотивам выступления Любови Гринкевич и Алексея Миртова из Yandex Cloud на DevOpsConf. Он будет интересен DevOps-инженерам, специалистам по безопасности, владельцам продуктов и всем, кто хочет:
научиться строить безопасный деплой,
автоматизировать проверки безопасности,
понимать проблемы и обсуждать их в команде.
Если вы столкнулись с новыми реалиями и требованиями безопасности и не знаете, с чего начать, эта статья может вам пригодиться. В качестве примеров будем рассматривать продукты и инфраструктуру Yandex Cloud, но большинство рекомендаций универсальны и не привязаны к конкретным сервисам.
https://habr.com/ru/companies/oleg-bunin/articles/786930/
#devops #девопс
Подпишись 👉@i_DevOps
🔥4