Управление облачными службами с помощью CRD Kubernetes
Все три ведущих облачных провайдера (AWS, Azure, GCP) теперь поддерживают механизм подготовки облачных сервисов к работе и управления ими, основанный на специальных ресурсах (custom resource definitions, CRD) Kubernetes. В AWS есть средство AWS Controllers for Kubernetes (ACK) (пока в статусе developer preview). В Azure недавно появился инструмент Azure Service Operator (Microsoft больше не поддерживает Open Service Broker для Azure). В GCP есть Config Connector в виде аддона для GKE. IaC-инструменты (Infrastructure-as-Code, инфраструктура как код) всё ещё широко используются для управления облачными инфраструктурами. Это, например, Terraform, Ansible и Puppet. Но поддержка облачных систем, управляемых средствами Kubernetes, говорит об огромном сдвиге организаций в сторону восприятия Kubernetes в виде центрального узла их облачных инфраструктур. Плюс этого сдвига заключается в том, что теперь разработчики могут использовать одни и те же инструменты, представленные API Kubernetes, для управления Kubernetes-приложениями и другими облачными службами. Это может привести к упрощению рабочих процессов. Но столь тесная связь Kubernetes и остальных облачных задач может кого-то не устроить. Это зависит от особенностей конкретной облачной системы и от того, насколько хорошо те, кто поддерживает эту инфраструктуру, знакомы с Kubernetes.
Pulumi
Если продолжить разговор об IaC-инструментах, то можно сказать, что компания Pulumi недавно сообщила о привлечении инвестиций в размере 37,5 миллионов долларов в рамках финансирования серии B. Благодаря этому Pulumi собирается потеснить Terraform лидирующую в настоящее время платформу для управления облачными инфраструктурами. Создатели Pulumi решили позволить разработчикам писать инфраструктурный код на их любимых языках программирования (вроде Go, Python и JavaScript), а не предлагать им очередной особый язык, основанный на JSON или YAML. Этим Pulumi отличается от традиционных IaC-платформ. Такой подход делает платформу Pulumi, в сравнении с Terraform, более гибкой, это позволяет разработчикам задействовать существующие тестировочные фреймворки для проверки своих инфраструктур. Но, учитывая то, что Pulumi проект достаточно молодой, вокруг него пока сложилось, в сравнении с Terraform, сравнительно небольшое сообщество разработчиков.
Terragrunt и TFSEC
В сфере применения Terraform (в отличие от Pulumi) некоторые недостатки устраняются силами опенсорсного сообщества. Например, существует проект Terragrunt, представляющий собой небольшую оболочку для Terraform, нацеленную на упрощение управления большими Terraform-проектами. Делается это путём организации конфигураций в модули и путём применения к этим модулям системы контроля версий. Terragrunt реализует некоторые лучшие практики, основы которых заложены соучредителем Gruntwork Евгением Брикманом. Но Terragrunt это полностью опенсорсное решение, а компания Gruntwork недавно объявила о коммерческой поддержке, предназначенной для организаций, которые нуждаются в сервисах, лучше подготовленных к реальной работе. Ещё одним опенсорсным дополнением для Terraform-проектов является TFSEC. Этот инструмент использует средства статического анализа кода для поиска потенциальных уязвимостей в инфраструктурном коде. Подобные инструменты со временем будут становиться всё важнее. Так можно говорить, учитывая нужды набирающего популярность движения DevSecOps, ориентированного на безопасность.
Tekton
CI/CD-рынок насыщен качественными инструментами вроде Jenkins и Spinnaker. Появляются на нём и проекты, изначально рассчитанные на облачные инфраструктуры, вроде Argo CD. В этой сфере появился один новый проект Tekton, который нацелен на рабочие нагрузки Kubernetes. Этот проект зародился в виде части проекта Knative, после чего он был передан Continuous Delivery Foundation (CDF). Tekton отличается от схожих разработок тем, что позволяет описывать CI/CD-цепочки с использованием CRD Kubernetes. Это позволяет цепочкам пользоваться стандартными возможностями Kubernetes (например откатами на предыдущие версии проекта) и интегрироваться с существующими инструментами вроде Jenkins X или Argo CD. Это позволяет поддерживать сложные CI/CD-цепочки, охватывающие весь жизненный цикл продукта.
Trivy
Сканирование контейнеров на предмет уязвимостей становится важной частью любых CI/CD-цепочек. Тут, как и в среде обычных CI/CD-решений, есть множество опенсорсных и коммерческих инструментов. Среди них Docker Bench for Security, Clair, Cilium, Anchore Engine, Falco. Trivy это инструмент от Aqua Security, который не только сканирует контейнеры, но и проверяет пакеты, используемые в коде. Если совместить Trivy и kube-bench (разработкой этого проекта тоже занимается Aqua Security), можно упростить интеграцию средств обеспечения безопасности в процесс разработки программных проектов.
ShellCheck
Несмотря на невероятный прогресс в сфере инфраструктурных инструментов shell-скрипты всё ещё используются в самых разных системах для решения простых задач. ShellCheck это статический анализатор кода, который умеет проверять тексты скриптов на наличие в них синтаксических и других распространённых ошибок. Этим инструментом можно пользоваться, войдя на специальный сайт, его можно вызывать из командной строки и включать в состав CI/CD-цепочек. Его можно интегрировать и в текстовый редактор (например в Vim, Sublime, Atom, VS Code).
Pitest и Stryker
Инструменты Pitest (Java) и Stryker (JavaScript, C#, Scala) реализуют механизмы мутационного тестирования кода, написанного на поддерживаемых ими языках. В ходе такого тестирования исследуется качество тестов путём внесения в код изменений (фактически ошибок) и проверки того, как выполняются тесты. Хороший модульный тест, если код изменён, завершится с ошибкой. Мутационное тестирование дополняет обычные тесты и позволяет улучшать покрытие кода тестами за счёт обнаружения непротестированного кода и кода, протестированного плохо.
Litmus
В 2011 году компания Netflix популяризовала идею хаос-инжиниринга, представив Chaos Monkey средство, которое входило в состав набора инструментов Simian Army. В мире Kubernetes имеется множество подобных инструментов. Это, например, опенсорсные chaoskube, kube-monkey и PowerfulSeal, а так же коммерческие вроде Gremlin. Мне хотелось бы выделить проект Litmus, представляющий собой зрелое решение, которым легко пользоваться и которое можно расширять. Litmus это легковесный оператор Kubernetes, состоящий из ChaosEngine, ChaosExperiment и ChaosResult. С помощью Litmus можно проводить эксперименты, тонко настраивая их параметры. Возможности системы гораздо шире обычной остановки случайным образом выбранных подов в заданном пространстве имён. Результаты испытаний выводятся с помощью CRD ChaosResult, система не возлагает на пользователя необходимость оценки последствий испытаний с применением обычных средств.
Итоги
Есть и другие технологии и тренды, за которыми я наблюдаю (например архитектуры безопасности с нулевым доверием, микрофронтенды, service-mesh-инструменты), но у меня нет опыта работы с ними, поэтому о них я не пишу. Полагаю, в 2021 году будет интересно понаблюдать и за этими технологиями.
Какие инструменты и технологии вы добавили бы к тем, о которых рассказал автор этой статьи?
