- PVSM.RU - https://www.pvsm.ru -
Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о технологиях и инструментах из сфер DevOps и SRE, на которые, как он полагает, стоит обратить внимание в 2021 году.
Все три ведущих облачных провайдера (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.
Если продолжить разговор об IaC-инструментах, то можно сказать, что компания Pulumi [6] недавно сообщила о привлечении инвестиций [7] в размере 37,5 миллионов долларов в рамках финансирования серии «B». Благодаря этому Pulumi собирается потеснить Terraform — лидирующую в настоящее время платформу для управления облачными инфраструктурами. Создатели Pulumi решили позволить разработчикам писать инфраструктурный код на их любимых языках программирования (вроде Go, Python и JavaScript), а не предлагать им очередной особый язык, основанный на JSON или YAML. Этим Pulumi отличается от традиционных IaC-платформ. Такой подход делает платформу Pulumi, в сравнении с Terraform, более гибкой, это позволяет разработчикам задействовать существующие тестировочные фреймворки для проверки своих инфраструктур. Но, учитывая то, что Pulumi — проект достаточно молодой, вокруг него пока сложилось, в сравнении с Terraform, сравнительно небольшое сообщество разработчиков.
В сфере применения Terraform (в отличие от Pulumi) некоторые недостатки устраняются силами опенсорсного сообщества. Например, существует проект Terragrunt [8], представляющий собой небольшую оболочку для Terraform, нацеленную на упрощение управления большими Terraform-проектами. Делается это путём организации конфигураций в модули и путём применения к этим модулям системы контроля версий. Terragrunt реализует некоторые «лучшие практики», основы которых заложены соучредителем Gruntwork [9] Евгением Брикманом. Но Terragrunt — это полностью опенсорсное решение, а компания Gruntwork недавно объявила о коммерческой поддержке [10], предназначенной для организаций, которые нуждаются в сервисах, лучше подготовленных к реальной работе. Ещё одним опенсорсным дополнением для Terraform-проектов является TFSEC [11]. Этот инструмент использует средства статического анализа кода для поиска потенциальных уязвимостей в инфраструктурном коде. Подобные инструменты со временем будут становиться всё важнее. Так можно говорить, учитывая нужды набирающего популярность движения DevSecOps, ориентированного на безопасность.
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-цепочки, охватывающие весь жизненный цикл продукта.
Сканирование контейнеров на предмет уязвимостей становится важной частью любых 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), можно упростить интеграцию средств обеспечения безопасности в процесс разработки программных проектов.
Несмотря на невероятный прогресс в сфере инфраструктурных инструментов shell-скрипты всё ещё используются в самых разных системах для решения простых задач. ShellCheck [20] — это статический анализатор кода, который умеет проверять тексты скриптов на наличие в них синтаксических и других распространённых ошибок. Этим инструментом можно пользоваться, войдя на специальный сайт, его можно вызывать из командной строки и включать в состав CI/CD-цепочек. Его можно интегрировать и в текстовый редактор (например — в Vim, Sublime, Atom, VS Code).
Инструменты Pitest [21] (Java) и Stryker [22] (JavaScript, C#, Scala) реализуют механизмы мутационного тестирования кода, написанного на поддерживаемых ими языках. В ходе такого тестирования исследуется качество тестов путём внесения в код изменений (фактически — ошибок) и проверки того, как выполняются тесты. Хороший модульный тест, если код изменён, завершится с ошибкой. Мутационное тестирование дополняет обычные тесты и позволяет улучшать покрытие кода тестами за счёт обнаружения непротестированного кода и кода, протестированного плохо.
В 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
Нажмите здесь для печати.