EMD Blog

Vagrant의 box를 centos7로 설정했을 경우 kernel version으로 인해 yum 사용 시 /mnt mount error가 발생할 수 있음. 왜냐하면 기본적으로 vagrant의 centos7은 repository에서 제거된 이전 버전의 kernel이 포함되어 있기 때문임. 이를 해결하기 위해 vbguest를 다운그레이드 하거나 vagrant-vbguest에서 제공하는 allow_kernel_upgrade option을 사용하면 됨. # 다운그레이드 방식 $ vagrant plugin uninstall vagrant-vbguest $ vagrant plugin install vagrant-vbguest --plugin-version 0.21 # option 사용 방식 $ vi Vagrant..

Vagrant의 공유 폴더 기능을 사용할 때 box로 centos를 지정하면 실시간 동기화가 되지 않는 이슈 발생. 즉, 계속 reload를 통해 파일을 동기화 시켜주어야함. 하지만 Ubuntu에서는 정상적으로 작동함. https://stackoverflow.com/questions/29731003/synced-folder-in-vagrant-is-not-syncing-in-realtime stackoverflow에 같은 issue를 겪고 질문을 남긴 사람이 있음. 레드햇 계열의 리눅스에서는 전부 동작하지 않는 것으로 보임. 현재 Hashicorp에 문의 중 → 그냥 문서안내만 받음 기존에 rsync__auto 옵션이 기본적으로 true로 설정되어 있다고 하는데 기본 값을 사용하든 명시적으로 지정을 해주..

GCP → IAM 및 관리자 → 서비스 계정으로 이동 서비스 계정 만들기 서비스 계정 이름 및 설명 입력 이 서비스 계정에 프로젝트에 대한 액세스 권한 부여에서 역할 선택 클릭 후 현재 사용 중 → 편집자 선택 완료를 클릭해 계정 설정 완료 서비스 계정 목록에서 방금 생성한 서비스 계정의 이메일 클릭 상단 탭에서 '키' 탭으로 이동 키 추가 → 새 키 만들기 → json 선택 키가 자동으로 다운로드 되며 terraform에서는 아래와 같이 사용하면 됨 main.tf terraform { required_providers { google = { source = "hashicorp/google" version = "3.5.0" } } } provider "google" { credentials = file(..

Shared VPC가 구성되어있는 프로젝트(host)의 compute.subnetworks.get 권한이 필요하다고 하면 Shared VPC를 사용하고자 하는 프로젝트(service)에서 사용중인 서비스 계정에 compute.subnetworks.get 권한을 부여한 후 host 프로젝트의 iam에 해당 서비스 계정을 추가해주면 됨. 또한 위와 같이 서비스 계정을 여러 프로젝트에 등록해두면 등록된 프로젝트들을 하나의 서비스 계정으로 인증/접근할 수 있어 편리함. 하지만 꼭 필요한 프로젝트에만 등록하고 최소 권한만 부여해서 사용할 것.

GCP CLI 설치와 설정이 끝난 후 gcloud를 실행시키면 아래와 같은 에러가 발생하는 상황이 생길 수 있음. Unable to connect to the server: error executing access token command "/usr/lib64/google-cloud-sdk/bin/gcloud config config-helper --format=json": err=exit status 1 output= stderr=Traceback (most recent call last): File "/usr/lib64/google-cloud-sdk/lib/gcloud.py", line 104, in main() File "/usr/lib64/google-cloud-sdk/lib/gcloud.py",..

장애 확인 장애가 발생한 지 모르는 것이 가장 큰 문제 잘못된 장애 인지 순서 고객 문의가 급증한다 → 개발팀에 연락 고객 불만이 쌓임 → 고객이 줄어듬 → 회사의 매출이 줄어든다 → 내가 짤린다? 사장님이 써보다가 안된다. → 개발팀에 연락 안정적인 장애 인지 고객이 인지하기 전에 버그를 수정 → 조용히 배포 → 없었던 일로 만듬 (점수함 패치) 장애 인지 방법 모니터링 → 현재 상황을 인지해야 함. 무엇을 모니터링 해야 하는지? → 서비스에 영향을 주는 모든 것 만약에 에러메세지는 발생하지 않는데 매출이 발생하지 않으면 ? → 장애같지 않아도 장애일 수 있음. 장애에 대한 정의가 필요함 → 도메인 특성도 고려할 것. (장애 같지만 장애가 아닌 경우도 있음) 모니터링 요소의 예 현재 정상 서버의 수 현..

오브젝트 개요에서 간단하게 언급했는데 쿠버네티스는 클러스터에서 파드나 서비스 등(오브젝트의 종류는 아주 다양함)을 구성할 때 이 오브젝트라는 것을 사용한다고 했다. 그리고 클러스터는 오브젝트에 기술되어 있는대로 클러스터의 상태를 유지하려 하기 때문에 이 오브젝트는 쿠버네티스 클러스터의 상태를 나타낸다고 할 수도 있다. 이 오브젝트는 그냥 무언가를 생성한다기 보다는 어떠한 의도를 담았다고 보는게 좋다. 예를 들면 아래와 같다. 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지) 그 애플리케이션이 이용할 수 있는 리소스 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책 위 내용은 문서에 있는 내용인데 대충 파드 오브젝트..

쿠버네티스 쿠버네티스는 컨테이너 기반의 서비스를 관리하기 위한 오픈소스 플랫폼이다. 컨테이터를 사용하면 다음과 같은 장점을 가져갈 수 있다. VM 보다 훨씬 가볍기 때문에 기민하게 애플리케이션을 배포할 수 있다. 주기적으로 이미지를 빌드하고 빠르게 롤백 가능하다. (CI/CD) 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 생성하기 때문에 개발과 운영의 관심사가 분리된다. OS 수준의 정보와 메트릭, Health Check 등을 확인 할 수 있다. (가시성) 모든 환경에서 동일하게 구동된다. (일관성) 다양한 OS, On-Premise, Public Cloud에서 구동된다. (이식성) OS에서 애플리케이션을 실행 하는 수준으로 추상화 수준이 높아진다. 마이크로서비스 배포 가능 리소스를 격리하고 애플리..

GCP Interconnect 부분에서 개선이 필요해 내용 정리해봄. 개요 온프레미스 네트워크와 VPC 네트워크 간 물리적인 연결(중간에 Partner사를 낄 수도 있다). 내부 IP로 온프레미스와 GCP 네트워크 간 통신이 가능해짐. 일반적인 GCP 리소스 뿐만 아니라 외부 IP가 없는 비공개 GCP 리소스(예를 들어 Cloud SQL)에도 접근이 가능하다. 두 네트워크 간 통신이 필요하다면 VPN을 생각 할 수 있지만 대규모 트래픽을 고려하고 있다면 Interconnect를 선택하는 것이 좋다. VPN은 암호화 후 공개 인터넷을 거쳐 트래픽이 전달되기 때문에 아무래도 느릴 수 밖에 없다. Interconnect 연결 GCP Interconnect 연결 방식은 두 가지가 존재한다. Dedicated I..

내용 정리 할 것까지는 아닌거 같아서 링크만 남겨둠 GCP 감사로그 데이터 액세스 감사로그 구성 감사구성 리소스 Terraform GCP 감사로그 모듈