0sennijLis

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

Как упомянуто выше, обратный прокси маршрутизирует пользовательские запросы на соответствующий сервер (при условии, конечно, что вы используете несколько серверов). На этом месте те, кто использует один сервер с одним экземпляром приложения, вполне справедливо зададутся вопросом, имеет ли вообще смысл внедрять обратный прокси-сервер. Ответ: да, смысл есть.
Обратный прокси будет полезен и в инсталляциях с одним сервером, за счёт предоставления таких своих преимуществ как: ограничение скорости, IP-фильтрация и контроль доступа, аутентификация, проверка запросов и кэширование.

Ingress контроллер

Если в двух словах, то в мире Kubernetes ingress контроллер является обратным прокси (кстати именно поэтому тот же Istio в прошлой статье был упомянут в контексте перечисления вариантов обратных прокси).

Он действует по принципу обратного прокси, маршрутизируя трафик из внешней сети к целевому сервису в пределах кластера Kubernetes, и позволяя вам настроить балансировщик нагрузки HTTP и HTTPS для кластера.

Чтобы лучше понять принцип работы, давайте сделаем шаг назад и попробуем разобраться, что такое Ingress.

Kubernetes Ingress - это объект API, задача которого определять как приходящий трафик из интернета будет направляться на внутренние сервисы кластера, которые затем в свою очередь будут отправлять запросы Pod'ам. Сам по себе Ingress не имеет влияния на систему, представляя собой просто набор правил для Ingress контроллера. Для проведения аналогии можно сравнить Ingress с автомобилем, у которого снят двигатель, а Ingress контроллер с самим двигателем, то есть при наличие Ingress ресурса, без установленного контроллера, работать ничего не будет.

Ingress контроллер принимает трафик снаружи Kubernetes платформы, и распределяет его по Pod'ам внутри платформы, таким образом накладывая еще один уровень абстракции на маршрутизацию трафика. Контроллеры Ingress преобразуют конфигурации из ресурсов Ingress в правила маршрутизации, распознаваемые и реализуемые обратными прокси-серверами.

Обычно Ingress контроллеры используются для предоставления доступа к множеству сервисов через единую точку входа (DNS-имя или IP-адрес).

В частности, входные контроллеры используются для:

• предоставления нескольких служб под одним DNS-именем

• реализации маршрутизации на основе пути, при которой разные URL-адреса сопоставляются с разными службами

• реализации маршрутизации на основе хоста, при которой разные имена хостов сопоставляются с разными службами

• реализации базовой аутентификации, или других методы контроля доступа для ваших приложений.

• включения ограничения скорости для ваших приложения

Заключение

Если ingress контроллер делает практически ту же самую работу, что и обратный прокси (обрабатывает входящий трафик и перенаправляет на соответствующий сервер/сервис), то чем они отличаются?
Ingress контроллер - это частный случай прокси-сервера, предназначенный для работы в кластерах Kubernetes. Он находится не на границе инфраструктуры, а на границе кластера.

Вы можете задаться справедливым вопросом. Почему бы просто напрямую не отправлять запросы на сервер, не используя посредника? Есть несколько причин, по которым такой вариант не видится предпочтительным:

• лучше контроль за интернет трафиком: Прямой прокси может разрешать или запрещать доступ к определённым ресурсам, контенту или сервисам, основываясь на описанных правилах. Это ценно для организаций, которые отслеживают и регулируют деятельность сотрудников или студентов в Интернете, а также для родителей, ограничивающих пребывание своих детей в Интернете.

• экономия пропускной способности, и повышение скорости: с помощью кэширования часто посещаемых ресурсов прокси сервер ускоряет время загрузки страниц, и сокращает сетевой трафик.

• улучшение приватности и безопасности: прокси-сервер может скрыть пользовательский IP адрес и другую идентификационную информацию от конечного сервера, что в свою очередь создаёт сложности для отслеживания пользователя. Он так же может шифровать пользовательские запросы и ответы, предотвращая перехват или взлом. Это большое преимущество для пользователей, которые хотят обезопасить свои персональные данные.

• Обход цензуры: прокси помогает пользователям получать доступ к контенту и сервисам, которые заблокированы или запрещены в их сети (провайдером или правительством). Это достигается путем маршрутизации запросов через другое местоположение или IP-адрес, на которые не распространяются те же ограничения. Это выгодно для пользователей, которые ищут больше онлайн-свободы.

Обратный прокси (Reverse Proxy)

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

Дополнительно обратный прокси может предоставлять возможности кэширования. Кэшируя статический контент, такой как изображения или файлы CSS, обратный прокси может предоставлять эти ресурсы напрямую клиентам, устраняя необходимость пересылать запросы на внутренние веб-серверы. Это существенно сокращает время отклика, и увеличивают общую производительность веб-приложения.

Другая важная фича обратного прокси - SSL Termination. Когда клиент запрашивает безопасное соединение (HTTPS), обратный прокси-сервер может обрабатывать процессы шифрования и дешифрования, освобождая серверные серверы от этой ресурсоёмкой задачи. Это не только улучшает производительность приложений, но еще и упрощает управление сертификатами SSL.

Некоторые примеры обратных прокси:

• Nginx: в особом представлении не нуждается. Это высокопроизводительный open-source веб-сервер, который так же может работать в качестве обратного прокси. Он поддерживает различные протоколы, алгоритмы балансировки нагрузки, механизмы кэширования и настройки безопасности.

• Varnish: Open-source обратный прокси-сервер HTTP с встроенным механизмом кэширования, предназначенный для ускорения веб-приложений.

• Apache Traffic Server: Обратный и кэширующий сервер с открытым исходным кодом, способный обрабатывать миллионы одновременных подключений и различных протоколов.

• Istio: Istio - это сервисная сетка с открытым исходным кодом, которая улучшает взаимодействие микросервисов с помощью таких функций, как обнаружение сервисов, балансировка нагрузки, маршрутизация трафика и многое другое.

Заключение

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

Тут в догонку может прилететь второй вопрос.
Но у нас же полно различных средств автоматизации на любой вкус и под совершенно разные задачи? Может Shell всё таки того? Не нужен?
Ответ аналогичный первому: Shell всё еще жив, и всё еще очень нужен.
Да, может сейчас и не очень нужно создавать огромные портянки сценариев оболочки для автоматизации всего и вся, но для специальных задач для использования с инструментами автоматизации нам всё еще нужен Shell.

Например, если вы используете AWS user data, то весьма велика вероятность, что внутри него вы будете использовать скрипты на Shell. Другой пример, для создания образов AMI с помощью packer вы в конечном итоге будете применять Shell для конфигурации AMI. Также умение писать на баше может пригодится и при работе с системами управления конфигурацией, с контейнерами, и с многими другими системами.

Кроме того, сценарий оболочки пригодится для повторяющихся задач разработки. Например, это может быть развертывание Vagrant VM с необходимым программным обеспечением или настройка самой среды разработки.

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

2. Как начать писать на Shell?

Предварительное условия для начала - иметь опыт работы с Linux(или Unix). Следовательно прежде всего нужно убедиться, что вы комфортно себя чувствуете в командной строке Linux, и умеете работать с командами из пакета coreutils.

Если мир Linux для вас пока чужд, то стоит какое-то время потренироваться в виртуальной среде. Например развернув у себя локально абсолютно любой Linux в VirtualBox. Либо, воспользовавшись предложениями облачных провайдеров. Важно выбрать для начала широкоиспользуемый дистрибутив (ubuntu, fedora), так будет проще найти людей в сети, которым можно задать вопросы, и обсудить всплывающие проблемы. Если интересно копнуть глубже, и разобраться во внутренностях системы, то можно попробовать "продвинутые" дистрибутивы типа Arch или Gentoo (для особо упорных LFS). Но что совершенно точно не нужно, так это брать в руки всякую маргинальщину вроде KaliLinux или AstraLinux (во первых они основаны на более популярном и широко используемом дистрибутиве, а во вторых не во всяком линуксовом сообществе вас встретят с распростёртыми объятиями при упоминании таких поделок).

Если вы считаете, что достаточно хорошо умеете работать с Linux, то тогда сделайте следующее.

Создайте репозиторий на Github, создайте в нём каталог для каждого изучаемого вами аспекта, и коммитьте туда все ваши рабочие скрипты. Не имеет значения, будет репозиторий открытый или закрытый (хотя открытый обязывает более ответственно подходить к наполнению).

Заведите собственную документацию. Вы можете например оставлять в README ссылки на полезные источники. Поверьте - фиксирование информации в репозитории поможет вам сохранить знания, а также может помочь другим.

3. Какие есть бесплатные ресурсы для изучения программирования на Shell?

Вам совершенно точно не нужно платить за какие-либо расширенные курсы по изучению Shell-скриптинга, хотя на рынке есть достаточно предложений самых разных курсов для инженеров DevOps. Курсы (если они качественные) - это не плохо, и если вам комфортно обучаться в таком формате, то пожалуйста. Однако программирование на Shell - это тот навык, который вполне можно освоить самостоятельно.

Ниже представлен список бесплатных ресурсов для начала обучения. Некоторые ресурсы пересекаются по рассматриваемым темам. Поэтому выберете наиболее приемлемые по содержанию именно для вас, и начинайте работать с выбранным материалом от начала и до конца. Труд и самодисциплина, как уже упоминалось выше, здесь имеют самую важную роль.

Ссылки на сайты с интерактивными туториалами, бесплатными курсами, и pdf материалами (так как все ресурсы на английском, то тут у нас всплывает побочный квест - оттачивание навыка чтения технических текстов).

1. Linux Shell Scripting Tutorial [Web]

2. Free interactive shell scripting tutorials [Web]

3. Shell Scripting tutorial [Web]

4. Bash Guide [web]

5. Shell Scripting Free Course [Udemy]

6. Advanced Bash Scripting Guide [PDF]

7. Bash Academy [Web]

8. Bash Notes for Professionals [PDF]

9. Bash Reference manual [PDF]

10. The Linux command line [PDF]

4.Применение навыков Shell-скриптинга на практике.

Предположим вы уже изучили все основные концепции программирование на Shell, возможно написали несколько солидных скриптов в обучающих целях. Следующий справедливый вопрос у вас возможно будет "Ну и где мне теперь это всё применять?"

В первую очередь имеет смысл посмотреть существующие проекты автоматизации в своей компании. Особенно если компания не маленькая, и не решается одна точечная задача, то весьма вероятно, что в проектах найдётся не мало мест, где применяется Shell-скриптинг.

Если в вашей компании нет таких проектов, и вы как раз хотите заняться чем-то подобным, но не знаете с чего начать, то например можете посмотреть Git-репозитории с наиболее популярными образами контейнеров для Docker (например контейнер с Nginx).

Попытайтесь разобраться и понять как работают найденные Shell-скрипты. Попутно понимая работу базовых коцепций, и отмечая для себя нестандартные, но интересные пути решения, которые могут быть использованы в этих скриптах.

Не стоит конечно зацикливаться только на скриптах из контейнеров, вы можете найти скрипты во множестве других репозиториях open-source комьюнити.

5. Некоторые примеры для тренировки

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

1. Найдите 10 самых больших файлов в системе, и перенаправьте вывод в файл.

2. Напишите скрипт для безопасного извлечения накопителей.

3. Напишите скрипт, отправляющий уведомление на почту.

4. Напишите скрипт для мониторинга загрузки CPU, памяти и дисков. Перенаправьте вывод с собранными данными в виде таблицы в файл, и уведомление в stdout если один их них превышает определённый порог.

5. Напишите сценарий для поиска созданных файлов и их размеров. Он должен принимать количество дней в качестве входных данных. Или формат от и до даты в качестве входных данных.

6. Напишите сценарий для автоматизации процесса создания новых учетных записей пользователей на сервере Linux и настройки их разрешений и доступа по SSH.

7. Напишите скрипт для создания списка пользователей, вошедших в систему по дате, и запишите его в выходной файл.

8. Напишите скрипт для рекурсивного копирования файлов на удалённую машину.

9. Напишите скрипт который отображает количество неудачных попыток входа в систему по IP-адресу

10. Создайте скрипт, который анализирует системный журнал, и пересылает в выходной файл выборку событий по конкретной службе, с отметками времени (в человекочитаемом формате).

11. Напишите скрипт, автоматизируйщий процесс архивирования системного журнала в каталог с резервными копиями, с последующей очисткой текущего журнала.

12. Напишите сценарий, проверяющий доступность списка URL, и отправляющий уведомление на почту, если какой-то из них не доступен.

13. Напишите скрипт для автоматизации процесса обновления нескольких серверов.

14. Напишите функцию, которая находит и убивает все зомби процессы в системе (задание со звёздочкой)

Не забывайте использовать в скриптах изученные понятия:

1. Переменные.

2. Подстановка команд, назначение результата переменным.

3. Использование cut, awk, и grep.

4. Перенаправление stdin/stdout/stderr.

5. Обработка условий с помощью if/elif/else.

6. Работу с оператором выбора (switch).

7. Циклы for/do-while)

8. Коды завершения (exit codes)

6.Вопросы по навыкам написания сценариев на собеседовании DevOps инженера.

Вопросы инженерам разнятся от компании к компании.

Например некоторые компании будут просто заинтересованы в ваших базовых знаниях Linux и сценариев оболочки. Другие компании будут рассчитывать на высокий уровень знаний командной строки Linux и сценариев оболочки.

Ниже приведены несколько примеров вопросов на собеседовании инженера DevOps.

1. Можете ли вы объяснить, как сценарии оболочки вписываются в более широкий рабочий процесс DevOps?

2. Зачем нужны сценарии оболочки, если есть другие инструменты автоматизации?

3. В решении каких задач вы предпочтете использовать Shell, а не Python/Golang?

4. Как провести статический анализ скрипта Shell?

5. Как вы можете гарантировать, что сценарий оболочки не содержит ошибок в CI/CD pipeline?

6. Как вы будете обрабатывать ошибки и исключения в своих сценариях?

7. Напишите простой скрипт, который принимает в качестве аргументов имена двух файлов, объединяет их и записывает вывод в третий.

8. Найдите дублирующиеся строки в файле, и замените их другой строкой.

9. Найдите все уникальные IP адреса в логе, и запишите их в отдельный файл

10. Как бы вы отлаживали сценарий оболочки, который работает неправильно?

11. Какая разница между циклами for и while?

7. Заключение

Разумеется этот пост не претендует на исчерпывающее рассмотрение темы (очень уж она большая, чтобы уместиться в один пост), но надеюсь, это краткое руководство по изучению сценариев Shell будет как минимум небесполезным для вас.

Неприятная ссылка на канал сообщества в телеграме

Короче говоря, если вы уже знакомы с какими-то языками программирования, например TypeScript, Python, Go, C#, Java, итд, и категорически не принимаете идею учить еще один новый язык - Pulumi для вас. Если вы используете AWS, технически вы можете использовать AWS CDK тоже, но если вы планируете заниматься оркестрацией гибридной облачной инфраструктуры, Pulumi сильно упростит вам жизнь.

Если вы уже используете Terraform в проде, но вас напрягают ограничения, накладываемые HCL, вы так же можете попытаться использовать Pulumi.

Этот инструмент давно не новый. Ему уже исполнилось почти 16к звездочек на github'e. Хотя по отношению к Terraform - он новый. Впрочем какая разница? Если он гипотетически может помочь решить ваши проблемы, то почему бы и не попробовать его?

SOPS

SOPS - сокращение от Secrets OPerationS. Это опенсорсный текстовый редактор файлов, который автоматически шифрует/дешифрует файлы.

Основные задачи на которых сосредоточено это приложение - редактирование, шифрование, и автоматизация.

Обычно, когда вы хотите зашифровать текстовый файл, вы делаете следущее:

• Открываете любимый текстовый редактор, вносите правки в текст, и сохраняете файл.

• Используете инструмент для шифрования/дешифрования для того, чтобы зашифровать весь файл.

Когда вам нужно прочитать зашифрованный файл:

• Сначала берете специальный инструмент, и расшифровываете файл.

• Открываете расшифрованный файл любимым текстовым редактором.

Недостаток этого процесса очевиден. Вам нужно два инструмента. С одной стороны текстовый редактор, с другой программа для шифрования информации. При этом задача остаётся на самом деле только одна.

И вот SOPS как раз и позволяет объединить два действия в одно.

Если очень кратко, он может быть интегрирован с такими сервисами как HashiCorp Vault, AWS KMS, etc) для расшифровки ваших зашифрованных файлов автоматически, а так же позволяет использовать git репозиторий для хранения ключей, что сильно упрощает рабочую коммуникацию.

Если вдруг заинтересовал инструмент, то в этой статье можно детально с ним ознакомиться.

Trivy

Контейнеризация и 12-факторные приложения (приложение как услуга) стали к настоящему времени настолько популярны, что когда у вас возникает задача что-то собирать и деплоить, вы не думаете ни о чём другом. С тех пор как мы стали зависимы от контейнеров в нашей инфраструктуре, стало важным поддерживать в актуальном состоянии безопасность хранимых образов, поскольку запускаемые из них контейнеры наследуют все характеристики родительских образов, в том числе уязвимости и неправильную конфигурацию.

Trivy - сканер безопасности. Он надёжен, быстро, и легок в использовании. У Trivy есть различные встроенные сканеры, которые призваны искать различные проблемы безопасности. Самый популярный вариант использования - поиск CVE. Второй по популярности - ошибки конфигурации.

Вы можете запускать Trivy как локально, с помощью CLI для сканирования локальных образов перед тем как отправлять их в реестр, или перед тем как деплоить ваше приложение.

Более того. Trivy разработан с возможностью без особого труда интегрироваться в CI пайплайны, что отлично согласуется с методологией DevOps.

Cluster API

Cluster API - это подпроект Kubernetes, ориентированный на предоставление декларативных API и оснастки упрощающей подготовку, обновление и эксплуатацию множества кластеров Kubernetes.

Запущенный Kubernetes Special Interest Group (SIG) Cluster Lifecycle, проект Cluster API использует API и шаблоны в стиле Kubernetes для автоматизации управления жизненным циклом кластера для операторов платформы. Вспомогательная инфраструктура, такая как виртуальные машины, сети, балансировщики нагрузки и VPC, а также конфигурация кластера Kubernetes определяются так же, как разработчики приложений развертывают свои рабочие нагрузки и управляют ими. Это обеспечивает согласованное и воспроизводимое развертывание кластера в самых разных инфраструктурных средах.

Если вас смущает официальное определение, подумайте так: вы можете запустить одну команду kubectl apply для создания кластера K8s, и она работает для AWS, Azure, DigitalOcean, Docker, GCP, OpenStack и других.

Не нужно создавать модули Terraform (или, что еще хуже, пытаться выяснить все параметры чужих модулей) для кластеров K8s, не нужно разбираться, как использовать eksctl для AWS и еще что-то для другого облака; просто применить kubectl для создания кластеров. Звучит впечатляюще, правда? Я знаю. Вот почему он и входит в этот список.

Linkerd

Linkerd - самая легкая и быстрая в мире service mash (по крайней мере, так говорят). Что такое service mash? Service mash — это выделенный уровень инфраструктуры для обеспечения безопасной, быстрой и надежной связи между сервисами.

Простота использования - вот ключевая фишка Linkerd. Вы можете установить его буквально одной командой.

Но давайте поговорим больше.

Настройка быстрая. Даже образы докеров маленькие, поэтому они загружаются быстрее.

Архитектура не сильно отличается. Существует плоскость управления и плоскость данных, где плоскость управления представляет собой набор служб, отвечающих за телеметрию, API, предоставление управляющих данных прокси плоскости данных и т. д., а плоскость данных имеет прокси, которые работают рядом с каждой службой. пример. Ознакомьтесь с официальным документом, если вы хотите узнать больше деталей.

Istio и AWS App Mesh используют прокси-сервер envoy с открытым исходным кодом — высокопроизводительный распределенный прокси-сервер C++, предназначенный для отдельных сервисов и приложений. Это сложный прокси общего назначения. Linkerd, с другой стороны, использует специально разработанный прокси-сервер, написанный на Rust, чтобы он был как можно меньше, легче и безопаснее. Я здесь не для того, чтобы судить, какой язык лучше и безопаснее, C++ или Rust, но как современный язык с особым способом управления памятью (собственность вместо сборки мусора) Rust определенно имеет преимущество.

Для управления несколькими кластерами, в отличие от Istio, Linkerd использует механизм зеркалирования сервисов. Настройка также относительно проста, почти как установка с одним кластером, за исключением того, что вам нужно сделать это дважды плюс плоскость управления с несколькими кластерами.

Подводя итог, Linkerd — это service mash другого типа: сверхлегкая, сверхпростая и сверхмощная. Linkerd добавляет безопасность, наблюдаемость и надежность в Kubernetes без каких-либо сложностей. Это не совсем новый инструмент, но если функции соответствуют вашим потребностям и вам нравится простота, попробуйте.

Github Actions

GitHub Actions — еще один CI.

Почему же тогда именно GitHub Actions?

Ну, во-первых, он находится в техническом радаре CNCF (и находится на стадии «оценки», превращая его в «новый» инструмент), поэтому нам как бы нужно хорошенько его рассмотреть.

Во-вторых, CI много взаимодействует с вашим кодом, и по своей природе GitHub Actions легко взаимодействует с вашими репозиториями GitHub. Больше никаких проблем с интеграцией CI с вашими репозиториями кода.

Еще одно преимущество для стартапов: у GitHub Actions есть некоторая бесплатная квота, поэтому, когда вы только что запустили новый продукт, бесплатной квоты может быть более чем достаточно, что делает его полностью бесплатным. Вам, вероятно, не нужно регистрировать несколько дополнительных самостоятельных исполнителей в течение довольно долгого времени, и вы экономите затраты на запуск некоторых виртуальных машин в каком-либо облаке для вашей собственной инфраструктуры только для части CI.

Tekton

Tekton... Ну... Это еще один CI)))

Ключевые особенности:

• Можно запустить его в кластере K8s

• Определить пайплайны как нативные ресурсы K8s, и просто применять применять их kubectl.

• Теперь у него есть панель инструментов и интерфейс командной строки.

Кроме того, Tekton позволяет создавать, тестировать и развертывать в нескольких средах, таких как виртуальные машины или бессерверные решения. Вы также можете выполнять развертывание в различных облачных провайдерах или гибридных средах, используя конвейеры Tekton.

Стоит ли использовать его? Мое мнение, если:

• Вы должны «владеть» своей системой CI (например, использование бесплатной квоты GitHub Actions по какой-то причине вам не подходит).

• Вы уже используете K8s.

• Вам нравится работать с K8s.

тогда определенно стоит попробовать Tekton.

HashiCorp Harness

Harness. О, это у нас еще один CI. НО на самом деле куда больше чем просто CI.

Оно объединяет несколько вещей в одно:

• CI

• CD/GitOps

• feature flags

• cloud costs

Harness предлагает размещенные виртуальные машины (ВМ) для запуска ваших сборок. С Harness Cloud вы можете без проблем создавать свой код на инфраструктуре, которую предоставляет Harness. Вы можете тратить меньше времени и усилий на обслуживание инфраструктуры и вместо этого сосредоточиться на разработке отличного программного обеспечения.

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

Harness GitOps позволяет выполнять развертывание GitOps в Harness. Вы определяете желаемое состояние службы, которую хотите развернуть, в своем манифесте Git, а затем используете Harness GitOps для синхронизации состояния с вашим работающим кластером Kubernetes.

Harness Feature Flags (FF) — это решение для управления функциями, которое позволяет вам изменять функциональность вашего программного обеспечения без развертывания нового кода. Это позволяет вам скрывать код или поведение без выпуска новых версий программного обеспечения. Флаг функции похож на мощный оператор if.

Короче говоря, если вы хотите, чтобы SaaS CI/CD/FeatureFlags были собраны в одном месте, это то, на что стоит обратить внимание.

Thanos

Здесь для начала следует немного вспомнить о локальном хранилище Prometheus.

Локальное хранилище Prometheus не предназначено для долговременного хранения; внешние решения обеспечивают длительное хранение и устойчивость данных.

Несмотря на то, что мы можем установить длительный период хранения данных, например годы, с помощью storage.tsdb.retention, вопрос остается в масштабе и планировании. С годами зондов с высоким разрешением обработка очень длинных запросов может занять много памяти. Это также зависит от масштаба: например, функция rate() в течение одного года с 15-секундным интервалом очистки требует 2,1 миллиона выборок или около 2,6 МБ данных. И это только по одному показателю.

Если у вас небольшая инфраструктура, нет ничего плохого в том, чтобы скорректировать время хранения до нескольких лет; текущая реализация TSDB отлично справляется с этим. Для более крупных приложений рассмотрите возможность использования более крупной распределенной базы данных TSDB.

И Thanos — это решение, которое решает эту проблему: это высокодоступная установка Prometheus с открытым исходным кодом и возможностями долгосрочного хранения, ориентированная на долгосрочное хранение. Если вы уже столкнулись с проблемами с хранилищем Prometheus, попробуйте Thanos.

HashiCorp Sentinel

Наконец поговорим про Sentinel.

Политика как код — это подход к управлению политиками, при котором политики определяются, обновляются, совместно используются и применяются с помощью кода, и Sentinel — это решение HashiCorp.

Поскольку Sentinel принадлежит HashiCorp, он хорошо интегрируется с другими продуктами HashiCorp. Так что, если вы активно пользуетесь Terraform, Vault, Consul или Nomad и хотите попробовать Policy-as-Code, Sentinel — именно то, что вам нужно.

Чтобы привести несколько конкретных примеров того, что могут сделать политики Sentinel:

• Не позволяйте облачным ресурсам предоставляться без тегов с помощью Terraform.

• Убедитесь, что изменение важных данных Vault может выполняться только авторизованными системными операторами с действительным MFA.

• Разрешить рабочие нагрузки Docker только в Nomad.

• Ключи Consul можно обновить только в рабочее время.

Пример короткого кода:

import “tfplan/v2” as tfplan

aws_instances = filter tfplan.resource_changes as _, rc {
rc.mode is “managed” and
rc.type is “aws_instance” and
rc.change.actions is not “delete”
}

main = rule {
all aws_instances as _, instance {
(instance.change.after.tags else {}) is not empty
}
}

Довольно очевидно, не так ли?