22-07-26 GCP 첫걸음

jakemraz's glacier·2022년 8월 29일
0

Dev Log

목록 보기
1/5

GCP를 써야할 상황이 와서 GCP를 살펴보고 싶은데, 아무런 레퍼런스가 없다. 블로그 글도 없고, 유튜브 검색해도 뭐가 없고.. 결국 의지 할 수 있는건 공식 Document 뿐. 그래도 AWS는 지식이 좀 있으니 GCP도 금방 익히겠지.. 하면서 공식 Document를 살펴봤다.
AWS 101 공부하던 시절 떠올리며.. 시작.

전역 / 리전 / 영역

  • Networks가 Global 이라니..
  • 영역은 AWS로 치면 AZ 말하는듯
  • 멀티 리전 리소스
    • Cloud Storage, DMS 등은 정해진 리전 외에 멀티 리전 위치에 존재함. 덕분에 정해진 리전에 장애가 나더라도 서비스를 유지 할 수 있음.

프로젝트, 조직, 폴더

  • 프로젝트
    • 빌드할 항목을 정리하는 개체
    • 모든 GC 리소스는 하나의 프로젝트에 속해야 함
    • 설정 / 권한 / 애플리케이션을 설명하는 메타데이터로 구성됨
      • 프로젝트 이름(Example Project), 프로젝트 ID(example-id), 프로젝트 번호(123456789012)
      • 프로젝트 ID는 GC 전체에서 고유함
    • 단일 프로젝트 내의 리소스는 리전 및 영역 규칙에 따라 내부 네트워크를 통해 통신하는 등 쉽게 협력 가능
    • 다른 프로젝트와 통신하려면 공유 VPC, VPC 네트워크 피어링을 통해야함
    • 각 프로젝트는 하나의 결제 계정과 연결됨. 여러 프로젝트의 사용 비용이 동일한 결제 계정에서 결제 될 수 있음
    • 프로젝트는 네임스페이스 역할을 함. 즉, 각 프로젝트 내의 모든 리소스는 고유한 이름을 가져야함.
      • 다른 프로젝트에 있는 경우 리소스 이름이 같을 수 있음. 다만 일부 리소스의 경우 전역에서 공유함.
    • 일반적으로 환경마다 애플리케이션당 하나의 프로젝트가 있는 것이 좋다. FOO 앱과 BAR앱이 있다면 FOO-dev FOO-prod BAR-dev BAR-prod 처럼 앱 X 환경 별로 구성하는 것이 좋다.
      • 모든 개발자에게 개발 프로젝트에 대한 액세스 권한을 부여하되 CI/CD 파이프라인에 대한 프로덕션 액세스 권한을 제한 할 수 있다.

결제

https://cloud.google.com/billing/docs/how-to?hl=ko

Cloud Billing 이라는 용어를 쓰는 듯

  • Payments Profile : Google 수준의 리소스. 해당 프로필에 연결된 결제 수단을 통해 GC 뿐만 아니라 AdWords 등의 비용 결제 가능. 이거 쓰면 우리 회사 Google 제품 결제 창구를 일원화 할 수 있을려나? 항상 결제 담당자를 누구로 하느냐에 대한 문제가..ㅠㅠ
  • Billing Account : GC 비용 지불을 위해 Payments Profile과 연결되는 계정. 프로젝트는 Billing Account와 연결돼야 한다.
  • Label : AWS의 TAG 같은 기능인듯

뭔가 Payments Profile (결제 프로필) 기능은 좀 더 심오 한 것 같다.

이걸 쓰면 뭔가 중앙 finance 부서에서 구글 비즈니스 서비스들의 결제를 한곳에서 관리 할 수 있을 것 같은데.. 어떻게 해야 잘 쓸 수 있는지 잘 모르겠다.

역할

  • IAM
    • 어떠한 리소스에 대해 누구(사용자)에게 어떠한 액세스 권한(역할)이 있는지 제어
    • 조직 / 폴더 / 프로젝트 / 서비스 수준 리소스에서 IAM 정책 설정 가능
    • 도메인 최고 관리자
      • 최고 관리자 == 도메인 관리자
    • 조직
      • 조직 리소스에 적용된 IAM 액세스 제어 정책은 조직의 모든 리소스에 대한 계층 구조 전체에 적용됨
    • 리소스의 유효 정책은 해당 리소스에 설정된 정책과 상위 리소스에서 상속된 정책의 합집합임. 이 상속은 하위 수준으로 전이됨. 리소스는 프로젝트에서 정책을 상속하고, 프로젝트는 조직에서 정책을 상속함. 따라서 조직 수준 정책은 리소스 수준에도 적용됨.
      역할은 항상 상속되며 리소스 계층 구조의 상위 수준에서 부여된 하위 수준 리소스에 대한 권한을 명시적으로 삭제할 수 없습니다. 위 예시의 'Test project'에서 Bob의 프로젝트 편집자 역할을 삭제하더라도 Bob은 이 역할을 여전히 'Department Y' 폴더에서 상속받으므로 'Test project'에 대한 이 역할의 권한을 여전히 갖게 됩니다. IAM 정책 계층 구조는 Google Cloud 리소스 계층 구조와 동일한 경로를 따릅니다. 리소스 계층 구조를 변경하면 정책 계층 구조도 변경됩니다. 예를 들어 프로젝트를 조직으로 이동하면 프로젝트의 IAM 정책이 해당 조직의 IAM 정책을 상속하도록 업데이트됩니다. 마찬가지로 프로젝트를 폴더 간에 이동하면 상속된 권한이 변경됩니다. 원래의 상위 요소에서 프로젝트에 상속된 권한은 프로젝트가 새로운 폴더로 이동할 때 상실됩니다. 대상 폴더에서 설정된 권한은 이동될 때도 프로젝트에 상속됩니다.

리소스 계층 구조

https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ko

레퍼런스

Google Cloud 개요

https://cloud.google.com/docs/overview?hl=ko

결제 온보딩 체크리스트

https://cloud.google.com/billing/docs/onboarding-checklist?hl=ko

리소스 계층 구조

https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy?hl=ko

profile
SOFTWARE DEVOPS ENGINEER

0개의 댓글