Единый ход в 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
Данное репо содержит примеры кода, приведенные в статье 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
👍3
Добро пожаловать в Dagger, программируемый CI/CD-движок, запускающий конвейеры в контейнерах.
https://dagger.io/
#devops #девопс
Подпишись 👉 @i_DevOps
https://dagger.io/
#devops #девопс
Подпишись 👉 @i_DevOps
👍4
Understanding the Terraform Check Block Feature
https://masterpoint.io/updates/understanding-terraform-check/
#devops #девопс
Подпишись 👉 @i_DevOps
https://masterpoint.io/updates/understanding-terraform-check/
#devops #девопс
Подпишись 👉 @i_DevOps
👍2
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
Допустим, у нас есть приложение, работающее на отдельной виртуальной машине. У нас также есть кластер 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
👍3
Резервное копирование и восстановление контейнеров с помощью API контрольных точек Kubernetes
В версии Kubernetes v1.25 в качестве альфа-функции был представлен API проверки контейнеров (Container Checkpointing API). Она позволяет создавать резервные копии и восстанавливать контейнеры, запущенные в подсистемах, без их остановки.
В первую очередь эта функция предназначена для криминалистического анализа, но в целом резервное копирование и восстановление - это то, чем может воспользоваться любой пользователь Kubernetes.
https://martinheinz.dev/blog/85
#devops #девопс
Подпишись 👉 @i_DevOps
В версии Kubernetes v1.25 в качестве альфа-функции был представлен API проверки контейнеров (Container Checkpointing API). Она позволяет создавать резервные копии и восстанавливать контейнеры, запущенные в подсистемах, без их остановки.
В первую очередь эта функция предназначена для криминалистического анализа, но в целом резервное копирование и восстановление - это то, чем может воспользоваться любой пользователь Kubernetes.
https://martinheinz.dev/blog/85
#devops #девопс
Подпишись 👉 @i_DevOps
👍5
Релиз GitLab 16.4 принес более 100 улучшений на платформе DevSecOps, в том числе: настраиваемые роли, рабочие области для частных проектов, массовые обновления статусов уязвимостей.
https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/
#devops #девопс
Подпишись 👉 @i_DevOps
https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/
#devops #девопс
Подпишись 👉 @i_DevOps
👍4
Альтернативы Docker: 10 альтернатив Docker для SaaS-приложений
Технология Docker настолько изменила ландшафт управления инфраструктурой, что Docker стал синонимом контейнеров. Хотя Docker является наиболее часто используемой контейнерной технологией, существует несколько других альтернатив Docker. В этом блоге мы рассмотрим альтернативы Docker для вашего SaaS-приложения.
https://dzone.com/articles/docker-alternatives-10-alternatives-to-docker-for
#devops #девопс
Подпишись 👉 @i_DevOps
Технология Docker настолько изменила ландшафт управления инфраструктурой, что Docker стал синонимом контейнеров. Хотя Docker является наиболее часто используемой контейнерной технологией, существует несколько других альтернатив Docker. В этом блоге мы рассмотрим альтернативы Docker для вашего SaaS-приложения.
https://dzone.com/articles/docker-alternatives-10-alternatives-to-docker-for
#devops #девопс
Подпишись 👉 @i_DevOps
👍1👎1
Устраняем ошибки, связанные с 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