Полная инвентаризация вашего следа AWS за 5 минут

Полная инвентаризация вашего следа AWS за 5 минут

14 марта 2022 г.

Поскольку компании продолжают переносить свои рабочие нагрузки с локальных решений на общедоступных поставщиков облачных услуг (CSP), таких как AWS, становится все труднее понять полную картину того, что может работать в облаке организации. Даже простые приложения обычно имеют несколько сред, таких как среда разработки, подготовка и производство. Для более сложных рабочих нагрузок существуют дополнительные среды, микросервисы, очереди, службы уведомлений (например, SNS, SES), хранилища данных и многое другое.


Даже когда все это находится под одной учетной записью AWS, трудно концептуализировать, не говоря уже об управлении растущими облачными ресурсами. Возьмем два, казалось бы, простых вопроса: «Сколько инстансов EC2 у меня сейчас запущено во всех моих аккаунтах AWS?» и «Правильно ли я пометил все экземпляры EC2 своей производственной среды тегом environment: production?». На них очень сложно ответить с помощью консоли AWS или интерфейса командной строки.


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


Выполнение инвентаризации с помощью консоли AWS требует ручного подсчета при смене регионов и учетных записей, чтобы убедиться, что вы ничего не пропустили. К сожалению, использование интерфейса командной строки AWS не намного проще. Для каждого региона и учетной записи, которую вы хотите запросить, вам необходимо выполнить несколько команд, вызывающих правильные API для каждого типа активов (например, aws ec2 description-instances). Затем вы должны вручную агрегировать результаты и дважды проверить, не пропустили ли вы какие-либо данные.


Вместо того, чтобы мучиться со всем этим межрегиональным ручным получением данных между учетными записями, давайте посмотрим, как это будет выглядеть с помощью [CloudGraph] (https://github.com/cloudgraphdev/cli). CloudGraph — это бесплатный GraphQL API с открытым исходным кодом для AWS, который значительно упрощает процесс ответов на вопросы об инвентаризации активов, соблюдении требований и выставлении счетов.


Итак, с чего начать?


Во-первых, вы устанавливаете CloudGraph с помощью одной команды установки npm install:


npm install -g @cloudgraph/cli


Затем вы сканируете все свои учетные записи AWS одновременно, настроив CloudGraph, используя учетные данные, которые вы уже сохранили в локальном файле \~/.aws/credentials (см. README поставщика CloudGraph AWS, если вам нужна дополнительная информация об этом). Вы также можете сканировать учетные записи, используя роли IAM, если хотите. Инициализируйте CloudGraph для наших учетных записей AWS, выполнив следующую команду:


cg init aws


Если у вас есть локальный файл учетных данных AWS, вы должны увидеть список профилей для выбора. В моем случае я выберу профили «по умолчанию» и «главный», чтобы я мог сканировать учетные записи AWS, в которых работают мои среды разработки и производства.



Затем вы можете выбрать регионы, которые CloudGraph должен сканировать. В моем случае это «нас-восток-1», «нас-восток-2» и «нас-запад-1». Если вы не знаете, в каких регионах у вас есть ресурсы, вы всегда можете выбрать их все. CloudGraph автоматически просканирует все поддерживаемые ресурсы. При необходимости это можно изменить, передав флаг -r команде инициализации (см. README CloudGraph для получения дополнительной информации о передаче флаги).



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


cg запуск


И, наконец, выполните следующую команду, чтобы просканировать все настроенные вами учетные записи, регионы и сервисы AWS:


cg scan aws


Не стесняйтесь взять быструю чашку кофе, пока это работает.


После завершения сканирования CloudGraph откроет [инструмент запросов GraphQL] (https://github.com/cloudgraphdev/cli#query-tools), который вы выбрали на шаге cg init. Вы можете использовать этот инструмент запросов, чтобы задать практически любой вопрос о ваших ресурсах AWS.


Давайте ответим на первый вопрос, который я задал в начале этого поста: «Сколько экземпляров EC2 в настоящее время работает во всех моих учетных записях AWS?». На этот вопрос легко ответить с помощью CloudGraph.



Как видите, у меня есть 46 экземпляров EC2, работающих в двух средах, которые я выбрал для сканирования. Обратите внимание, что CloudGraph также предоставляет общее количество всех отсканированных ресурсов в отчете, распечатываемом в конце каждого сканирования.



Возможно, я хочу сделать еще один шаг и просмотреть метаданные об этих экземплярах EC2, такие как их instanceType. Я могу легко выполнить запрос GraphQL к своим инстансам EC2 и запросить только те метаданные, которые мне интересны.



Теперь давайте ответим на второй заданный мной вопрос: «Правильно ли я пометил все экземпляры EC2 своей производственной среды тегом environment: production?». На самом деле я мог бы сделать это несколькими способами.


Во-первых, я мог напрямую запрашивать экземпляры EC2 в Production и видеть их теги, например:


запрос {


queryawsEc2 (фильтр: {accountId: {eq: "632*77"}}) {


я бы


теги {


ключ


стоимость



Этот вывод ясно показывает мне все мои экземпляры EC2 в учетной записи «632…» и их теги.


Второй и более прямой способ задать этот вопрос — использовать queryawsTag и отфильтровать ключ и значение, на которые я хотел бы нацелиться:


запрос {


queryawsTag (фильтр: {ключ: {eq: "среда"} и: {значение: {eq: "производство"}}}) {


ec2Instance (фильтр: {accountId: {eq: "632*77"}}) {


я бы


арн



Теперь я получаю только инстансы EC2 с тегом «environment: production».


Это также будет работать для других тегируемых ресурсов AWS, таких как VPC, пользователи IAM, корзины S3 или кластеры EKS. CloudGraph упрощает инвентаризацию ваших активов, независимо от того, в скольких регионах или учетных записях они находятся. Нет предела тому, что вы можете запрашивать!


Если у вас есть какие-либо вопросы или предложения о том, как мы можем улучшить CloudGraph, пожалуйста, напишите нам в slack или в [проблемы CloudGraph GitHub] (https://github.com/cloudgraphdev/cli/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc).


[Тайлер Дункель] (https://www.linkedin.com/in/tylerdunkel/)


Технический директор [AutoCloud] (https://www.autocloud.dev/)



Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE