- PVSM.RU - https://www.pvsm.ru -

Технологии и инструменты, на которые стоит обратить внимание в 2021 году

Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о технологиях и инструментах из сфер DevOps и SRE, на которые, как он полагает, стоит обратить внимание в 2021 году.

Технологии и инструменты, на которые стоит обратить внимание в 2021 году - 1 [1]

Управление облачными службами с помощью CRD Kubernetes 

Все три ведущих облачных провайдера (AWS, Azure, GCP) теперь поддерживают механизм подготовки облачных сервисов к работе и управления ими, основанный на специальных ресурсах (custom resource definitions, CRD) Kubernetes. В AWS есть средство AWS Controllers for Kubernetes [2] (ACK) (пока — в статусе developer preview). В Azure недавно появился инструмент Azure Service Operator [3] (Microsoft больше не поддерживает Open Service Broker для Azure [4]). В GCP есть Config Connector [5] — в виде аддона для GKE. IaC-инструменты (Infrastructure-as-Code, инфраструктура как код) всё ещё широко используются для управления облачными инфраструктурами. Это, например, Terraform, Ansible и Puppet. Но поддержка облачных систем, управляемых средствами Kubernetes, говорит об огромном сдвиге организаций в сторону восприятия Kubernetes в виде центрального узла их облачных инфраструктур. Плюс этого сдвига заключается в том, что теперь разработчики могут использовать одни и те же инструменты, представленные API Kubernetes, для управления Kubernetes-приложениями и другими облачными службами. Это может привести к упрощению рабочих процессов. Но столь тесная связь Kubernetes и остальных облачных задач может кого-то не устроить. Это зависит от особенностей конкретной облачной системы и от того, насколько хорошо те, кто поддерживает эту инфраструктуру, знакомы с Kubernetes.

Pulumi

Если продолжить разговор об IaC-инструментах, то можно сказать, что компания Pulumi [6] недавно сообщила о привлечении инвестиций [7] в размере 37,5 миллионов долларов в рамках финансирования серии «B». Благодаря этому Pulumi собирается потеснить Terraform — лидирующую в настоящее время платформу для управления облачными инфраструктурами. Создатели Pulumi решили позволить разработчикам писать инфраструктурный код на их любимых языках программирования (вроде Go, Python и JavaScript), а не предлагать им очередной особый язык, основанный на JSON или YAML. Этим Pulumi отличается от традиционных IaC-платформ. Такой подход делает платформу Pulumi, в сравнении с Terraform, более гибкой, это позволяет разработчикам задействовать существующие тестировочные фреймворки для проверки своих инфраструктур. Но, учитывая то, что Pulumi — проект достаточно молодой, вокруг него пока сложилось, в сравнении с Terraform, сравнительно небольшое сообщество разработчиков.

Terragrunt и TFSEC

В сфере применения Terraform (в отличие от Pulumi) некоторые недостатки устраняются силами опенсорсного сообщества. Например, существует проект Terragrunt [8], представляющий собой небольшую оболочку для Terraform, нацеленную на упрощение управления большими Terraform-проектами. Делается это путём организации конфигураций в модули и путём применения к этим модулям системы контроля версий. Terragrunt реализует некоторые «лучшие практики», основы которых заложены соучредителем Gruntwork [9] Евгением Брикманом. Но Terragrunt — это полностью опенсорсное решение, а компания Gruntwork недавно объявила о коммерческой поддержке [10], предназначенной для организаций, которые нуждаются в сервисах, лучше подготовленных к реальной работе. Ещё одним опенсорсным дополнением для Terraform-проектов является TFSEC [11]. Этот инструмент использует средства статического анализа кода для поиска потенциальных уязвимостей в инфраструктурном коде. Подобные инструменты со временем будут становиться всё важнее. Так можно говорить, учитывая нужды набирающего популярность движения DevSecOps, ориентированного на безопасность.

Tekton

CI/CD-рынок насыщен качественными инструментами вроде Jenkins и Spinnaker. Появляются на нём и проекты, изначально рассчитанные на облачные инфраструктуры, вроде Argo CD. В этой сфере появился один новый проект — Tekton [12], который нацелен на рабочие нагрузки 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 [13], Clair [14], Cilium [15], Anchore Engine [16], Falco [17]. Trivy [18] — это инструмент от Aqua Security, который не только сканирует контейнеры, но и проверяет пакеты, используемые в коде. Если совместить Trivy и kube-bench [19] (разработкой этого проекта тоже занимается Aqua Security), можно упростить интеграцию средств обеспечения безопасности в процесс разработки программных проектов.

ShellCheck

Несмотря на невероятный прогресс в сфере инфраструктурных инструментов shell-скрипты всё ещё используются в самых разных системах для решения простых задач. ShellCheck [20] — это статический анализатор кода, который умеет проверять тексты скриптов на наличие в них синтаксических и других распространённых ошибок. Этим инструментом можно пользоваться, войдя на специальный сайт, его можно вызывать из командной строки и включать в состав CI/CD-цепочек. Его можно интегрировать и в текстовый редактор (например — в Vim, Sublime, Atom, VS Code).

Pitest и Stryker

Инструменты Pitest [21] (Java) и Stryker [22] (JavaScript, C#, Scala) реализуют механизмы мутационного тестирования кода, написанного на поддерживаемых ими языках. В ходе такого тестирования исследуется качество тестов путём внесения в код изменений (фактически — ошибок) и проверки того, как выполняются тесты. Хороший модульный тест, если код изменён, завершится с ошибкой. Мутационное тестирование дополняет обычные тесты и позволяет улучшать покрытие кода тестами за счёт обнаружения непротестированного кода и кода, протестированного плохо.

Litmus

В 2011 году компания Netflix популяризовала идею «хаос-инжиниринга», представив Chaos Monkey — средство, которое входило в состав набора инструментов Simian Army. В мире Kubernetes имеется множество подобных инструментов. Это, например, опенсорсные chaoskube [23], kube-monkey [24] и PowerfulSeal [25], а так же коммерческие — вроде Gremlin [26]. Мне хотелось бы выделить проект Litmus [27], представляющий собой зрелое решение, которым легко пользоваться и которое можно расширять. Litmus — это легковесный оператор Kubernetes, состоящий из ChaosEngine, ChaosExperiment и ChaosResult. С помощью Litmus можно проводить эксперименты, тонко настраивая их параметры. Возможности системы гораздо шире обычной остановки случайным образом выбранных подов в заданном пространстве имён. Результаты испытаний выводятся с помощью CRD ChaosResult, система не возлагает на пользователя необходимость оценки последствий испытаний с применением обычных средств.

Итоги

Есть и другие технологии и тренды, за которыми я наблюдаю (например — архитектуры безопасности с нулевым доверием, микрофронтенды, service-mesh-инструменты), но у меня нет опыта работы с ними, поэтому о них я не пишу. Полагаю, в 2021 году будет интересно понаблюдать и за этими технологиями.

Какие инструменты и технологии вы добавили бы к тем, о которых рассказал автор этой статьи?

Автор: ru_vds

Источник [28]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/razrabotka/359645

Ссылки в тексте:

[1] Image: https://habr.com/ru/company/ruvds/blog/530946/

[2] AWS Controllers for Kubernetes: https://github.com/aws/aws-controllers-k8s

[3] Azure Service Operator: https://github.com/Azure/azure-service-operator

[4] Open Service Broker для Azure: https://github.com/Azure/open-service-broker-azure

[5] Config Connector: https://cloud.google.com/config-connector/docs/overview

[6] Pulumi: https://www.pulumi.com

[7] инвестиций: https://www.pulumi.com/blog/series-b/

[8] Terragrunt: https://terragrunt.gruntwork.io/

[9] Gruntwork: https://gruntwork.io/

[10] коммерческой поддержке: https://terragrunt.gruntwork.io/commercial-support/

[11] TFSEC: https://github.com/tfsec/tfsec

[12] Tekton: https://tekton.dev/

[13] Docker Bench for Security: https://github.com/docker/docker-bench-security

[14] Clair: https://github.com/quay/clair

[15] Cilium: https://github.com/cilium/cilium

[16] Anchore Engine: https://github.com/anchore/anchore-engine

[17] Falco: https://github.com/falcosecurity/falco

[18] Trivy: https://github.com/aquasecurity/trivy

[19] kube-bench: https://github.com/aquasecurity/kube-bench

[20] ShellCheck: https://github.com/koalaman/shellcheck

[21] Pitest: http://pitest.org/

[22] Stryker: https://stryker-mutator.io/

[23] chaoskube: https://github.com/linki/chaoskube

[24] kube-monkey: https://github.com/asobti/kube-monkey

[25] PowerfulSeal: https://github.com/powerfulseal/powerfulseal

[26] Gremlin: https://www.gremlin.com/kubernetes/

[27] Litmus: https://github.com/litmuschaos/litmus

[28] Источник: https://habr.com/ru/post/530946/?utm_source=habrahabr&utm_medium=rss&utm_campaign=530946