Устраняем ошибки, связанные с SIGSEGV: ошибка сегментирования в контейнерах Linux (код возврата 139)
Сигнал SIGSEGV, применяемый в Linux, означает нарушение сегментирования в рамках работающего процесса. Ошибки сегментирования возникают из-за того, что программа пытается обратиться к участку памяти, который пока не выделен. Это может произойти из-за бага, случайно вкравшегося в код, либо из-за того, что внутри системы происходит некая вредоносная активность.
Сигналы SIGSEGV возникают на уровне операционной системы, но столкнуться с ними также вполне можно и в контексте контейнерных технологий, например, Docker и Kubernetes. Когда контейнер завершает работу, выдав код возврата 139, дело именно в том, что он получил сигнал SIGSEGV. Операционная система завершает процесс контейнера, чтобы предохраниться от нарушения целостности памяти.
Если ваши контейнеры то и дело завершают работу с кодом возврата, то важно исследовать, что именно вызывает ошибки сегментирования. Часто следы ведут к программным ошибкам в языках, открывающих вам прямой доступ к памяти. Если такая ошибка возникает в том контейнере, где выполняется сторонний образ, то виной тому может быть баг в стороннем софте или несовместимость образа со средой.
В этой статье будет объяснено, что представляют собой сигналы SIGSEGV, как они влияют на работу ваших контейнеров с Linux в Kubernetes. Также я подскажу, как отлаживать ошибки сегментации в вашем приложении, а если они возникают – как с ними справляться.
Rus https://habr.com/ru/companies/timeweb/articles/763062/
Eng https://www.airplane.dev/blog/sigsegv-segmentation-fault-linux-containers-exit-code-139
#devops #девопс
Подпишись 👉 @i_DevOps
Сигнал SIGSEGV, применяемый в Linux, означает нарушение сегментирования в рамках работающего процесса. Ошибки сегментирования возникают из-за того, что программа пытается обратиться к участку памяти, который пока не выделен. Это может произойти из-за бага, случайно вкравшегося в код, либо из-за того, что внутри системы происходит некая вредоносная активность.
Сигналы SIGSEGV возникают на уровне операционной системы, но столкнуться с ними также вполне можно и в контексте контейнерных технологий, например, Docker и Kubernetes. Когда контейнер завершает работу, выдав код возврата 139, дело именно в том, что он получил сигнал SIGSEGV. Операционная система завершает процесс контейнера, чтобы предохраниться от нарушения целостности памяти.
Если ваши контейнеры то и дело завершают работу с кодом возврата, то важно исследовать, что именно вызывает ошибки сегментирования. Часто следы ведут к программным ошибкам в языках, открывающих вам прямой доступ к памяти. Если такая ошибка возникает в том контейнере, где выполняется сторонний образ, то виной тому может быть баг в стороннем софте или несовместимость образа со средой.
В этой статье будет объяснено, что представляют собой сигналы SIGSEGV, как они влияют на работу ваших контейнеров с Linux в Kubernetes. Также я подскажу, как отлаживать ошибки сегментации в вашем приложении, а если они возникают – как с ними справляться.
Rus https://habr.com/ru/companies/timeweb/articles/763062/
Eng https://www.airplane.dev/blog/sigsegv-segmentation-fault-linux-containers-exit-code-139
#devops #девопс
Подпишись 👉 @i_DevOps
👍1
Ansible На Русском Языке
- Автоконфигурирование для DevOps
- Полный Курс на Простом Языке
- Установка на Ubuntu и CentOS
- Установка на Amazon Linux через PIP
- Подключение к серверам LINUX
- Подключение к серверам WINDOWS
- Правила создания файла Inventory
- Запуск Ad-Hoc Комманд- Правила Формата YAML- Перенос переменных в group_vars
- Первые Playbook
- Переменные - Debug, Set_fact, Register
- Блоки и Условия – Block-When
- Циклы – Loop, With_Items, Until, With_fileglob
- Шаблоны - Jinja Template
- Создание Ролей - Roles
- Внешние переменные - extra-vars
- Использование Import, Include
- Перенаправление выполнения Task из Playbook на определённый сервер - delegate_to
- Перехват и Контроль ошибок
- Хранение Секретовvault
- Dynamic Inventory AWS - Amazon Web Services
- Создание ресурсов AWS - Amazon Web Services
https://www.youtube.com/playlist?list=PLg5SS_4L6LYufspdPupdynbMQTBnZd31N
#devops #девопс
Подпишись 👉 @i_DevOps
- Автоконфигурирование для DevOps
- Полный Курс на Простом Языке
- Установка на Ubuntu и CentOS
- Установка на Amazon Linux через PIP
- Подключение к серверам LINUX
- Подключение к серверам WINDOWS
- Правила создания файла Inventory
- Запуск Ad-Hoc Комманд- Правила Формата YAML- Перенос переменных в group_vars
- Первые Playbook
- Переменные - Debug, Set_fact, Register
- Блоки и Условия – Block-When
- Циклы – Loop, With_Items, Until, With_fileglob
- Шаблоны - Jinja Template
- Создание Ролей - Roles
- Внешние переменные - extra-vars
- Использование Import, Include
- Перенаправление выполнения Task из Playbook на определённый сервер - delegate_to
- Перехват и Контроль ошибок
- Хранение Секретовvault
- Dynamic Inventory AWS - Amazon Web Services
- Создание ресурсов AWS - Amazon Web Services
https://www.youtube.com/playlist?list=PLg5SS_4L6LYufspdPupdynbMQTBnZd31N
#devops #девопс
Подпишись 👉 @i_DevOps
👍8
K8s ASA: Интерфейс хранения данных
Как и большинство серверов API, одной из основных функций сервера API Kubernetes, если не главной, является получение данных, их хранение и последующее возвращение по запросу. Сегодня мы сосредоточимся на том, как сервер API хранит данные.
https://danielmangum.com/posts/k8s-asa-the-storage-interface/
#devops #девопс
Подпишись 👉@i_DevOps
Как и большинство серверов API, одной из основных функций сервера API Kubernetes, если не главной, является получение данных, их хранение и последующее возвращение по запросу. Сегодня мы сосредоточимся на том, как сервер API хранит данные.
https://danielmangum.com/posts/k8s-asa-the-storage-interface/
#devops #девопс
Подпишись 👉@i_DevOps
👍1
TerraVision
Это инструмент CLI, преобразующий код Terraform в профессиональные диаграммы облачной архитектуры и решающий проблему поддержания в актуальном состоянии самого важного документа облачных проектов - архитектурного документа. В условиях, когда высокая скорость выпуска релизов является нормой, диаграммы архитектуры, сгенерированные машиной, более точны, чем диаграммы, нарисованные облачным архитектором в произвольной форме, которые уже не соответствуют реальности. Terravision безопасно работает на 100% на стороне клиента без зависимости от Terraform или доступа к облачной среде, динамически анализируя условно созданные ресурсы и переменные и генерируя автоматическую визуальную схему архитектуры. Terravision разработан как инструмент "Документы как код" (DaC), который может быть включен в CI/CD конвейер для обновления диаграмм архитектуры после завершения фаз конвейера сборки/тестирования/релиза и дополнения других генераторов документов, таких как readthedocs.io, наряду с ним. В настоящее время поддерживается облако AWS, а в скором времени - Google и Azure.
https://github.com/patrickchugh/terravision
#devops #девопс
Подпишись 👉@i_DevOps
Это инструмент CLI, преобразующий код Terraform в профессиональные диаграммы облачной архитектуры и решающий проблему поддержания в актуальном состоянии самого важного документа облачных проектов - архитектурного документа. В условиях, когда высокая скорость выпуска релизов является нормой, диаграммы архитектуры, сгенерированные машиной, более точны, чем диаграммы, нарисованные облачным архитектором в произвольной форме, которые уже не соответствуют реальности. Terravision безопасно работает на 100% на стороне клиента без зависимости от Terraform или доступа к облачной среде, динамически анализируя условно созданные ресурсы и переменные и генерируя автоматическую визуальную схему архитектуры. Terravision разработан как инструмент "Документы как код" (DaC), который может быть включен в CI/CD конвейер для обновления диаграмм архитектуры после завершения фаз конвейера сборки/тестирования/релиза и дополнения других генераторов документов, таких как readthedocs.io, наряду с ним. В настоящее время поддерживается облако AWS, а в скором времени - Google и Azure.
https://github.com/patrickchugh/terravision
#devops #девопс
Подпишись 👉@i_DevOps
👍6❤1
Отладка Terraform Provider: Пошаговое руководство
Terraform - это инструмент компании HashiCorp для создания инфраструктуры как кода (IAC). Он позволяет определять ресурсы и инфраструктуру в человекочитаемых, декларативных конфигурационных файлах и управлять жизненным циклом инфраструктуры. Плагины Terraform позволяют Terraform взаимодействовать с облачными платформами и другими сервисами через их API. Эти плагины называются провайдерами. Многие провайдеры были написаны HashiCorp и сообществами разработчиков с открытым исходным кодом.
https://medium.com/@narinderkaurmakkar1/terraform-provider-debugging-a-step-by-step-guide-8c6d771637a1
#devops #девопс
Подпишись 👉@i_DevOps
Terraform - это инструмент компании HashiCorp для создания инфраструктуры как кода (IAC). Он позволяет определять ресурсы и инфраструктуру в человекочитаемых, декларативных конфигурационных файлах и управлять жизненным циклом инфраструктуры. Плагины Terraform позволяют Terraform взаимодействовать с облачными платформами и другими сервисами через их API. Эти плагины называются провайдерами. Многие провайдеры были написаны HashiCorp и сообществами разработчиков с открытым исходным кодом.
https://medium.com/@narinderkaurmakkar1/terraform-provider-debugging-a-step-by-step-guide-8c6d771637a1
#devops #девопс
Подпишись 👉@i_DevOps
👍4
etcdadm - это инструмент командной строки для управления кластером etcd. С его помощью можно легко создать новый кластер, добавить участника или удалить участника из существующего кластера. Его пользовательский интерфейс вдохновлен kubeadm.
https://github.com/kubernetes-sigs/etcdadm
#devops #девопс
Подпишись 👉@i_DevOps
https://github.com/kubernetes-sigs/etcdadm
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Практические истории из наших SRE-будней
Современная веб-инфраструктура состоит из множества компонентов разного назначения, имеющих очевидные и не очень взаимосвязи. Это становится особенно хорошо видно при эксплуатации приложений, использующих разные программные стеки, что с приходом микросервисов стало встречаться буквально на каждом шагу. Ко всеобщему «веселью» добавляются и внешние факторы (сторонние API, сервисы и т.п.), что усложняют и без того непростую картину.
В общем, даже если эти приложения и будут объединены общими архитектурными идеями и решениями, для устранения необычных проблем в них зачастую приходится пробираться через очередные незнакомые дебри. Случатся ли такие проблемы — лишь вопрос времени. Вот таким примерам из нашей последней практики и посвящена эта статья. В ролях: Golang, Sentry, RabbitMQ, nginx, PostgreSQL и другие.
🔹 Часть 1 https://habr.com/ru/company/flant/blog/471892/
🔹 Часть 2 https://habr.com/ru/company/flant/blog/510486/
🔹 Часть 3 https://habr.com/ru/company/flant/blog/531686/
🔹 Часть 4 https://habr.com/ru/company/flant/blog/558346/
🔹 Часть 5 https://habr.com/ru/company/flant/blog/648175/
🔹 Часть 6 https://habr.com/ru/company/flant/blog/662459/
#devops #девопс
Подпишись 👉@i_DevOps
Современная веб-инфраструктура состоит из множества компонентов разного назначения, имеющих очевидные и не очень взаимосвязи. Это становится особенно хорошо видно при эксплуатации приложений, использующих разные программные стеки, что с приходом микросервисов стало встречаться буквально на каждом шагу. Ко всеобщему «веселью» добавляются и внешние факторы (сторонние API, сервисы и т.п.), что усложняют и без того непростую картину.
В общем, даже если эти приложения и будут объединены общими архитектурными идеями и решениями, для устранения необычных проблем в них зачастую приходится пробираться через очередные незнакомые дебри. Случатся ли такие проблемы — лишь вопрос времени. Вот таким примерам из нашей последней практики и посвящена эта статья. В ролях: Golang, Sentry, RabbitMQ, nginx, PostgreSQL и другие.
🔹 Часть 1 https://habr.com/ru/company/flant/blog/471892/
🔹 Часть 2 https://habr.com/ru/company/flant/blog/510486/
🔹 Часть 3 https://habr.com/ru/company/flant/blog/531686/
🔹 Часть 4 https://habr.com/ru/company/flant/blog/558346/
🔹 Часть 5 https://habr.com/ru/company/flant/blog/648175/
🔹 Часть 6 https://habr.com/ru/company/flant/blog/662459/
#devops #девопс
Подпишись 👉@i_DevOps
👍3😁1
_Наглядное_руководство_по_устранению_неполадок_в_развертывании_Kubernetes.pdf
789.6 KB
Наглядное руководство по устранению неполадок в развертывании Kubernetes
#devops #девопс
Подпишись 👉@i_DevOps
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Media is too big
VIEW IN TELEGRAM
Мониторинг СronJob в Kuberenetes / Анна Гобрусева (Ozon)
В докладе расскажу, как устроен мониторинг в Ozon в целом, и как мы организовали мониторинг CronJob в Kubernetes на базе готовых решений Prometheus-Thanos-Grafana и Kube-state-metrics при наличии давно сформированной инфраструктуры мониторинга.
источник
#devops #девопс
Подпишись 👉@i_DevOps
В докладе расскажу, как устроен мониторинг в Ozon в целом, и как мы организовали мониторинг CronJob в Kubernetes на базе готовых решений Prometheus-Thanos-Grafana и Kube-state-metrics при наличии давно сформированной инфраструктуры мониторинга.
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍5
История о жрущем память API-сервере Kubernetes
Наша команда занимается сопровождением кластеров Kubernetes внутри компании. Мы стараемся построить модель предоставления кластера как услуги, насколько это возможно в наших реалиях. Несколько месяцев назад коллеги, работающие с одним из кластеров Kubernetes в dev-окружении, обратились с проблемой недоступности API-сервера Kubernetes (далее kube-api). Dev-среды обычно не подключены к дежурной смене, и решением проблем занимаются владельцы или, если проблемы нестандартные, обращаются к профильным специалистам. В ходе диагностики оказалось, что kube-api стал потреблять значительно больше памяти. Это приводило к возникновению ошибки с OOM.
Давайте будем честными — если бы это произошло в production-окружении, мы, скорее всего, закинули бы больше памяти и успешно бы забыли про проблему. Но dev-стенд не имеет жёстких SLA с финансовой ответственностью, и это дало нам возможность и время разобраться с прожорливым kube-api.
https://habr.com/ru/companies/rtlabs/articles/732858/
#devops #девопс
Подпишись 👉@i_DevOps
Наша команда занимается сопровождением кластеров Kubernetes внутри компании. Мы стараемся построить модель предоставления кластера как услуги, насколько это возможно в наших реалиях. Несколько месяцев назад коллеги, работающие с одним из кластеров Kubernetes в dev-окружении, обратились с проблемой недоступности API-сервера Kubernetes (далее kube-api). Dev-среды обычно не подключены к дежурной смене, и решением проблем занимаются владельцы или, если проблемы нестандартные, обращаются к профильным специалистам. В ходе диагностики оказалось, что kube-api стал потреблять значительно больше памяти. Это приводило к возникновению ошибки с OOM.
Давайте будем честными — если бы это произошло в production-окружении, мы, скорее всего, закинули бы больше памяти и успешно бы забыли про проблему. Но dev-стенд не имеет жёстких SLA с финансовой ответственностью, и это дало нам возможность и время разобраться с прожорливым kube-api.
https://habr.com/ru/companies/rtlabs/articles/732858/
#devops #девопс
Подпишись 👉@i_DevOps
👍7
Media is too big
VIEW IN TELEGRAM
Обзор архитектуры быстрого сборщика логов на Go
Владимир Витковский (Ozon)
Поговорим о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.
Расскажем, как c помощью этого инструмента мы сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.
источник
#devops #девопс
Подпишись 👉@i_DevOps
Владимир Витковский (Ozon)
Поговорим о лучших практиках, на которых основан очень быстрый сборщик логов, используемый в Ozon.
Расскажем, как c помощью этого инструмента мы сократили издержки на сбор логов в 10 раз по CPU и добились 100% доставляемости логов.
источник
#devops #девопс
Подпишись 👉@i_DevOps
❤3👍1
Как происходит утечка секретов в конвейерах CI/CD
Утечка секретов в конвейерах CI/CD происходит регулярно. Рабочие процессы непрерывной интеграции/развертывания (CI/CD) обычно требуют от разработчиков предоставления достоверных учетных данных для сторонних ресурсов, с которыми взаимодействует конвейер. Хотите автоматически развернуть изменения кода на экземпляре EC2? Предоставьте ключ доступа к AWS. Хотите развернуть артефакт в NPM? Предоставьте ключ API NPM.
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/
#devops #девопс
Подпишись 👉@i_DevOps
Утечка секретов в конвейерах CI/CD происходит регулярно. Рабочие процессы непрерывной интеграции/развертывания (CI/CD) обычно требуют от разработчиков предоставления достоверных учетных данных для сторонних ресурсов, с которыми взаимодействует конвейер. Хотите автоматически развернуть изменения кода на экземпляре EC2? Предоставьте ключ доступа к AWS. Хотите развернуть артефакт в NPM? Предоставьте ключ API NPM.
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/
#devops #девопс
Подпишись 👉@i_DevOps
👍5
Media is too big
VIEW IN TELEGRAM
Деобфускация и анализ клиентского JavaScript‑кода для обнаружения DOM‑based XSS
Андрей Козлов
Основная цель доклада — описание нового, разработанного докладчиком, автоматизированного метода анализа JavaScript‑кода, использующего статический и динамический анализ, а также сравнение результатов его работы с существующими автоматизированными сканерами веб‑уязвимостей
источник
#devops #девопс
Подпишись 👉@i_DevOps
Андрей Козлов
Основная цель доклада — описание нового, разработанного докладчиком, автоматизированного метода анализа JavaScript‑кода, использующего статический и динамический анализ, а также сравнение результатов его работы с существующими автоматизированными сканерами веб‑уязвимостей
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍3
Как быстрее выполнять запросы Loki metric с более точными результатами
Сегодня я хочу поговорить о метрических запросах. Точнее, я хочу рассказать о важной концепции, которая сделает ваши запросы быстрее, даст более точные результаты и сделает ваших операторов Grafana Loki (таких, как я) намного счастливее.
https://grafana.com/blog/2023/07/05/how-to-run-faster-loki-metric-queries-with-more-accurate-results/
#devops #девопс
Подпишись 👉@i_DevOps
Сегодня я хочу поговорить о метрических запросах. Точнее, я хочу рассказать о важной концепции, которая сделает ваши запросы быстрее, даст более точные результаты и сделает ваших операторов Grafana Loki (таких, как я) намного счастливее.
count_over_time({app=”foo”}[1m])https://grafana.com/blog/2023/07/05/how-to-run-faster-loki-metric-queries-with-more-accurate-results/
#devops #девопс
Подпишись 👉@i_DevOps
👍3❤1
Мониторинг AWS Lambda — полное руководство по Serverless подходу
Бессерверные вычисления коренным образом изменили подход к разработке программного обеспечения, сместив акцент с управления серверами на создание бизнес-логики, приносящей реальную пользу.
https://aws.plainenglish.io/aws-lambda-monitoring-a-full-guide-3cc68c6052fd
#devops #девопс
Подпишись 👉@i_DevOps
Бессерверные вычисления коренным образом изменили подход к разработке программного обеспечения, сместив акцент с управления серверами на создание бизнес-логики, приносящей реальную пользу.
https://aws.plainenglish.io/aws-lambda-monitoring-a-full-guide-3cc68c6052fd
#devops #девопс
Подпишись 👉@i_DevOps
👍1
Сегодня у меня для вас рекомендация — два полезных канала для системных администраторов:
📚 @it_secur — Литература для системных администраторов и ИБ специалистов любого уровня и направления. Читайте, развивайтесь, практикуйте.
👨🏻💻 @infosecurity — Авторский Telegram канал, посвященный информационной безопасности, OSINT и социальной
📚 @it_secur — Литература для системных администраторов и ИБ специалистов любого уровня и направления. Читайте, развивайтесь, практикуйте.
👨🏻💻 @infosecurity — Авторский Telegram канал, посвященный информационной безопасности, OSINT и социальной
Media is too big
VIEW IN TELEGRAM
Capacity planning — сколько серверов нужно в будущем и как они нагружены сейчас
Евгений Сударчиков
Этот рассказ про разработку сервиса анализа и планирования Capacity на сравнительно большом количестве серверов. В рассказе будут детали:
* какие метрики нужны, как собираются и сколько их;
* как используются метрики RPS и стресс-тестов;
* куда все это собирается, как агрегируется, сколько занимает места;
* в итоге, как и чем строится прогноз нужного количества серверов.
источник
#devops #девопс
Подпишись 👉@i_DevOps
Евгений Сударчиков
Этот рассказ про разработку сервиса анализа и планирования Capacity на сравнительно большом количестве серверов. В рассказе будут детали:
* какие метрики нужны, как собираются и сколько их;
* как используются метрики RPS и стресс-тестов;
* куда все это собирается, как агрегируется, сколько занимает места;
* в итоге, как и чем строится прогноз нужного количества серверов.
источник
#devops #девопс
Подпишись 👉@i_DevOps
👍3