cloudgraphdev/cliAWS, Azure, GCP, K8s 및 tencent를 위한 범용 GraphQL API 및 CSPM 도구
CloudGraph는 AWS, Azure, GCP, K8s를 위한 무료 오픈소스 유니버설 GraphQL API 및 클라우드 보안 구성 관리(CSPM) 도구입니다. CloudGraph를 사용하면 다음과 같은 기능을 얻을 수 있습니다:
Cloud Graph를 사용하면 5분 안에 클라우드를 알 수 있습니다. AutoCloud 팀이 사랑을 담아 만들고 유지 관리합니다 ❤️ AutoCloud ❤️
🌐 웹사이트
💻 문서
💰 CloudGraph 제공업체 구축에 대한 보상 받기
** 사용이 보증을 의미하지는 않습니다
AWS, Azure, GPC는 점점 더 상호 연결된 세상을 위한 시스템을 구축할 수 있도록 엔지니어 같은 우리를 위한 솔루션을 훌륭하게 구축해 왔습니다. 지난 15년 동안 EC2, S3, RDS, Lambda와 같은 제품들은 컴퓨팅, 스토리지, 데이터베이스에 대한 우리의 생각을 근본적으로 바꾸어 놓았습니다.
지난 5년 정도 동안 Kubernetes 및 Serverless의 확산으로 클라우드 서비스는 물리적 서버 랙 위에서 점점 더 추상화되었습니다. 최종 사용자에게 클라우드의 모든 것은 단지 API일 뿐이므로 애플리케이션 구축에 사용하기 위해 Lambda 함수나 EKS가 내부적으로 어떻게 작동하는지 반드시 알 필요는 없습니다. 약간의 문서, API 또는 콘솔 액세스, 튜토리얼만 있으면 누구든지 필요한 거의 모든 것을 만들 수 있습니다.
이러한 추상화는 CSP 서비스 제공의 전반적인 편의성과 범위에서 엄청난 개선을 가져왔습니다. 한때 새 서버, 데이터베이스 또는 파일 시스템을 프로비저닝하는 것이 고통스럽고 시간이 많이 걸리며 오류가 발생하기 쉬운 과정이었지만, 이제는 버튼 클릭 한 번이나 IAC 배포만으로 몇 초 만에 수행할 수 있습니다. 모든 것이 단지 API 추상화이기 때문에 CSP가 새로운 "제품"을 도입할 준비가 되면 새 API를 노출하기만 하면 됩니다. 물론 약간 단순화한 것입니다 :)
CSP에 익숙한 사람이라면 서비스 API가 거의 항상 수십 개, 경우에 따라 수백 개의 개별 API 메서드를 포함하는 모듈식 네임스페이스로 분할된다는 것을 알고 있습니다. 예를 들어 AWS EC2 서비스에는 500개가 넘는 API 메서드가 있으며, 때때로 새로운 메서드가 추가됩니다. CSP에서 상당한 규모의 시스템을 구축하는 모든 회사는 아마도 매우 다양한 서비스를 사용하고 있을 것입니다.
데이터센터 아키텍처의 걸작이지만, 수백 가지 서비스와 구성 옵션의 선택은 이러한 서비스를 올바르게 사용하는 방법에 대한 지식의 부담을 우리 엔지니어에게 고스란히 안겨주었습니다. 그 결과, 우리는 모든 서비스 제공이나 새로운 변경 사항을 지속적으로 업데이트하고 배워야 하는 상황에 처하게 됩니다. 이는 상당한 시간과 정신적 에너지를 필요로 합니다. 개발자로서 AWS CLI를 사용하여 예를 들어 AWS ECS 클러스터, 그 서비스, 작업 정의, 작업, 컨테이너 정의 등을 설명하기 위해 5개의 다른 API 호출을 해야 하는 것은 어렵고 시간이 많이 걸리며 좌절스러울 수 있습니다. 우리는 종종 문서에서 길을 잃고 "이 VPC에서 정확히 무엇이 실행되고 있나요?"와 같은 질문에 대한 답을 얻기 위해 수많은 API를 사용해야 합니다.
이는 AWS, Azure, GCP가 숙련된 클라우드 아키텍트에게조차 빠르게 압도적으로 느껴질 수 있음을 의미합니다. CSP는 우리 비즈니스를 구동하는 실제 서비스를 구축하는 데는 환상적이지만, 수백 가지 서비스를 합리적인 방식으로 쿼리하는 일상적인 UX를 단순화하는 데는 많은 진전이 없었습니다.
AWS의 Cloud Control API와 같은 새로운 솔루션은 다양한 유형의 AWS 리소스를 쿼리하기 위한 표준화된 인터페이스를 만들려고 시도했습니다. 불행히도 Cloud Control API의 사용은 심각하게 제한되어 있으며, 사용자는 여전히 데이터를 올바르게 쿼리하는 방법을 알아야 합니다. 즉, 문서를 읽고 서비스가 어떻게 작동하고 서로 관련되어 있는지 이해하는 데 더 많은 시간을 소비해야 합니다.
CSP API의 모듈성은 훌륭한 논리적 구성 시스템이며 타당하지만, 인지적 부담과 학습 곡선 측면에서 최종 사용자에게 부담이 됩니다. 끊임없이 변화하는 수백 가지 서비스가 어떻게 작동하고 연결되어 있는지 기억해야 하는 것은 카페인 중독과 탐정 놀이에 시간 낭비로 이어집니다.
DevOps/클라우드 엔지니어로서 AWS, Azure, GCP 등에서 데이터를 더 간단하게 가져올 수 있는 방법이 있다면 좋지 않을까요? 계정에 관계없이 모든 서비스에 대한 모든 데이터를 쉽게 쿼리할 수 있는, 문서나 스택 오버플로에서 몇 시간을 소비하지 않아도 되는 방법이 있다면요?
이러한 이유로 우리는 모든 클라우드를 위한 GraphQL API인 CloudGraph를 구축했습니다. CloudGraph는 클라우드 데이터를 추출하고, 정규화하고, 처리하고, 보강하여 여러 제공업체에 걸쳐 깊은 통찰력에 쉽게 액세스할 수 있도록 합니다. 자세한 내용은 블로그 게시물 The GraphQL API for everything을 확인하세요.
CloudGraph는 실행하기 위해 읽기 전용 권한이 필요하며, 따라서 실제 클라우드 인프라를 절대 변경할 수 없습니다. 또한 사용자의 클라우드 환경 정보가 CloudGraph, AutoCloud 또는 다른 제3자에게 전송되거나 공유되지 않습니다.
내부적으로 CloudGraph는 클라우드 제공업체에 연결하여 모든 구성 데이터를 수집하고, 처리한 후, 이 데이터의 복사본을 Dgraph에 저장합니다. 그런 다음 http://localhost:8997에서 엔드포인트를 노출하여 저장된 데이터에 대해 GraphQL 쿼리를 작성할 수 있습니다. 이러한 쿼리를 통해 AWS SDK/CLI 등으로 할 수 있는 모든 것을 수행할 수 있을 뿐만 아니라 훨씬 더 강력한 쿼리도 실행할 수 있습니다. CloudGraph는 GraphQL Playground 및 Altair를 포함한 사전 패키지된 GraphQL 쿼리 도구와 함께 제공되지만, 자신만의 도구를 자유롭게 사용할 수도 있습니다. 또한 엔티티 간의 관계를 이해할 수 있도록 Voyager라는 스키마 시각화 도구도 포함되어 있습니다.
CloudGraph는 현재 AWS, Azure, GCP, K8s, Tencent를 지원합니다 (곧 몇 가지 더 추가 예정). CloudGraph는 데이터를 수집하기 위해 읽기 권한이 필요합니다. 쉽게 하기 위해 AutoCloud을 구동할 때 CloudGraph를 실행하는 데 내부적으로 사용하는 것과 동일한 권한을 사용할 수 있습니다. 각 제공업체에 대한 인증 가이드 및 자격 증명 생성 방법은 다음과 같습니다 (AutoCloud 관련 구성은 생략해도 됩니다):
시스템 요구 사항
CloudGraph CLI를 설치하는 방법은 2가지가 있습니다.
다음 명령어로 Homebrew를 사용하여 CloudGraph를 설치할 수 있습니다:
brew install cloudgraphdev/tap/cg
