Разворачиваем приложение в кластере Kubernetes под управлением Deckhouse c помощью werf

В статье мы рассмотрим, как подступиться к миру Kubernetes в первый раз — развернуть кластер под управлением платформы Deckhouse, разработать и подготовить приложение, развернуть его с помощью утилиты werf, предназначенной для построения рабочего процесса по принципам CI/CD, а также настроить сертификаты для доступа по HTTPS.

https://habr.com/ru/companies/flant/articles/759040/

#devops #девопс

Подпишись 👉 @i_DevOps

Linux Kernel Defence Map

Linux Kernel Defence Map показывает взаимосвязь между классами уязвимостей, методами эксплуатации, механизмами обнаружения ошибок и технологиями защиты.

https://github.com/a13xp0p0v/linux-kernel-defence-map

#devops #девопс

Подпишись 👉 @i_DevOps

Legacy PHP-FPM в Kubernetes

Каждая стратегия масштабирования имеет свои плюсы и минусы. Почему бы не начать комбинировать их и оставить только плюсы? Поговорим об этом — как сделать хорошо, когда нельзя просто закопать — в контексте PHP.

Статья написана по мотивам моего доклада на Saint HighLoad++ 2023.

Меня зовут Игорь Титов, я системный инженер в Garage Eight. Расскажу, как мы переносили страшного старого монстра — legacy PHP-FPM-приложение — в Kubernetes и сколько при этом съели ёжиков.

https://habr.com/ru/companies/oleg-bunin/articles/762742/

#devops #девопс

Подпишись 👉 @i_DevOps

Open sysConf'23

Welcome message
Самат. Вводная по Kubernetes
Виктор. Мексиканская стена
Алексей. Черный пояс по Linux
Амир. Как построить AppSec и ничего не сломать
Ильяс. eBPF. Сниффер трафика веб сервера
Есенай. Нагрузочное тестирование Jmeter
Маргулан. Делаем XDR из дефолтного линукса
Ильяс. Real Estate Investment Fundamentals
Женя. Be yourself - Be focused
The End

https://www.youtube.com/watch?v=isl6kGAzkPc

#devops #девопс

Подпишись 👉 @i_DevOps

Единый ход в AWS, Terraform и Terragrunt

Данное репо содержит примеры кода, приведенные в статье Medium "AWS Single Sign-on (SSO), Terraform и Terragrunt".

Приведенный код демонстрирует использование профилей AWS при использовании Terraform или Terragrunt с помощью метода переменных окружения или метода блоков провайдера Terraform. Хотя в данной статье рассматривается настройка профилей AWS при использовании SSO с помощью IAM Identity Center, она работает и со стандартными профилями учетных данных (ключ доступа и секретный ключ доступа).

Оба метода - Terraform и Terragrunt - очень похожи. В обоих случаях можно установить переменную окружения AWS_PROFILE с нужным профилем.

В качестве альтернативы можно использовать блок провайдера в Terraform или сгенерировать блок провайдера в Terragrunt. В Terragrunt также есть возможность загрузки переменных через внешние YAML-файлы.

Код для каждого из этих четырех методов находится в отдельной папке. Они просто развертывают общий SSM-параметр с помощью общего модуля ssm-string-parameter.

Кроме того, в двух дополнительных папках находится бэкэнд S3. Это сделано для демонстрации проблем, с которыми вы можете столкнуться, как описано в статье.

https://github.com/oliverschenk/aws-sso-terraform-terragrunt

#devops #девопс

Подпишись 👉 @i_DevOps

Добро пожаловать в Dagger, программируемый CI/CD-движок, запускающий конвейеры в контейнерах.

https://dagger.io/

#devops #девопс

Подпишись 👉 @i_DevOps

Understanding the Terraform Check Block Feature

https://masterpoint.io/updates/understanding-terraform-check/

#devops #девопс

Подпишись 👉 @i_DevOps

Kubernetes ingress как обратный прокси для приложения, работающего вне кластера

Допустим, у нас есть приложение, работающее на отдельной виртуальной машине. У нас также есть кластер Kubernetes, на котором запущено несколько приложений, доступ к которым осуществляется через ingress. Мы хотим получить доступ к нашему приложению, работающему на отдельной виртуальной машине (вне кластера K8s), используя тот же домен, который мы используем для доступа ко всем остальным приложениям, работающим на кластере Kubernetes, не перемещая приложение на кластер K8s.

В этой статье будет показано, как разместить приложение, работающее вне кластера K8s, за ингрессом, работающим на кластере K8s. Таким образом, приложение, работающее вне кластера K8s, будет доступно через тот же домен, который мы используем для доступа к приложениям, работающим на кластере K8s.

https://medium.com/linux-shots/kubernetes-ingress-as-reverse-proxy-to-application-running-outside-cluster-206b6003f9cb

#devops #девопс

Подпишись 👉 @i_DevOps

Резервное копирование и восстановление контейнеров с помощью API контрольных точек Kubernetes

В версии Kubernetes v1.25 в качестве альфа-функции был представлен API проверки контейнеров (Container Checkpointing API). Она позволяет создавать резервные копии и восстанавливать контейнеры, запущенные в подсистемах, без их остановки.

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

https://martinheinz.dev/blog/85

#devops #девопс

Подпишись 👉 @i_DevOps

Релиз GitLab 16.4 принес более 100 улучшений на платформе DevSecOps, в том числе: настраиваемые роли, рабочие области для частных проектов, массовые обновления статусов уязвимостей.

https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/

#devops #девопс

Подпишись 👉 @i_DevOps

Альтернативы Docker: 10 альтернатив Docker для SaaS-приложений

Технология Docker настолько изменила ландшафт управления инфраструктурой, что Docker стал синонимом контейнеров. Хотя Docker является наиболее часто используемой контейнерной технологией, существует несколько других альтернатив Docker. В этом блоге мы рассмотрим альтернативы Docker для вашего SaaS-приложения.

https://dzone.com/articles/docker-alternatives-10-alternatives-to-docker-for

#devops #девопс

Подпишись 👉 @i_DevOps

Устраняем ошибки, связанные с 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