일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Clean Code
- Google Cloud Platform
- vm
- MIG
- CentOS
- 보안 규칙
- github
- cloud armor
- Python
- cicd
- vpc peering
- 우테캠
- IAM
- Terraform Cloud
- Uptime Check
- 자격증
- cloud
- interconnect
- gcp
- docker
- 후기
- devops
- cloud function
- AWS
- Java
- direnv
- terraform
- pub/sub
- kubernetes
- VAGRANT
- Today
- Total
목록전체 글 (96)
EMD Blog
이전 포스팅에서 인스턴스를 만들어 봤으니 이제 MIG를 구성해보자. 관리형 인스턴스 그룹(Manged Instance Group) 제목에 있는 MIG는 Managed Instance Group의 약자로 관리형 인스턴스 그룹을 말한다. GCP에서 인스턴스 그룹은 비관리형 인스턴스 그룹과 관리형 인스턴스 그룹으로 나뉘는데, 비관리형 인스턴스 그룹은 인스턴스를 묶은 것이다. 딱히 무슨 기능이 제공되는 것은 아니고 그냥 논리적으로 묶은 것 뿐이다. 이렇게 묶은 인스턴스 그룹은 로드밸런서를 연결할 수 있게 된다. 그럼 관리형 인스턴스 그룹은 뭐가 다를까? 관리형 인스턴스 그룹은 오토스케일링을 제공해주고 장애 복구 기능을 지원한다. 이 외에도 다양한 zone에 VM을 생성해 가용성을 높히거나 다양한 배포 옵션을 제..
Compute Engine GCP Compute Engine은 GCP에서 제공하는 컴퓨팅 및 호스팅 서비스이다. 사용자들은 이 Compute Engine 서비스를 통해 쉽게 원하는 사양의 VM을 생성할 수 있으며 그에 따른 다양한 서비스들을 제공하고 있다. 아무래도 GCP내에서 말 그대로 컴퓨터를 담당하고 있기 때문에 Cloud를 처음 접한다면 IAM보다 일찍 접하게 되는게 이 Compute Engine 서비스가 될 것이다. 이 서비스를 사용하기에 앞서 먼저 생각해야 할 것이 있다. Cloud를 사용하고자 하는 이유는 공부일 수도 있고, 회사에서 마이그레이션 하려는 이유일 수도 있고, 그 외에도 다양한 이유가 있을 것이지만 중요한 것은 마냥 가격이 저렴해서 사용하는 것은 아니라는 걸 명심하자. 만약에 랜..
전 포스팅에 이어서 마저 세팅을 해보자. 이전 포스팅에서는 개발자 용 계정을 생성해 IAM계정에 추가하고 IAP TCP 터널링을 통해 VM에 접속할 수 있도록 설정해주었다. 이제는 배포를 해야하니 파일을 업로드할 수 있도록 설정해보자. 파일을 업로드를 하기 위해서 가장 먼저 생각나는 것은 FTP(또는 SFTP)다. 하지만 우리는 IAP 터널링을 사용하고 있고 보안상 21,22번 포트를 오픈하는 것은 별로 바람직하지 못할 뿐더러 관리적인 측면에서도 불편할 수 있다. 그렇게 생각하면 파일 업로드를 위한 좋은 방법이 두 가지가 존재한다. - gcloud 명령어 사용 - Cloud Storage 사용 위 방법외에도 그냥 SCP 명령어(gcloud 말고)를 사용하거나 브라우저 업로드를 하는 방법도 있으나 우리는 ..
이전 포스팅에서는 Cloud SDK를 설치 했었다. 이제는 IAM을 간단하게 사용해보기로 하자. 그래도 막무가내로 하는 것 보다는 목표를 정하는 것이 좋으니 다음과 같은 상황이라 생각하고 실습을 해보자. 다른 개발 부서에서 GCP에 어플리케이션을 배포하고 테스트하기 위헤 권한을 부여해달라는 요청을 받았다. 간단한 주문이다. 일단 CI/CD나 네트워크 설정 및 방화벽은 생각하지 않기로 하고 진행해보자. 그럼 다음과 같은 요소들을 생각할 수 있다. 1. 다른 개발부서의 개발자들이 VM에 접속할 수 있어야 함. 2. 개발자들이 파일 업로드(배포)도 할 수 있어야 함. 3. 배포한 어플리케이션이 필요에 따라 다른 리소스에 접근할 수 있어야 함. 위 내용들을 하나식 해결해보도록 하자. 진행은 SDK로 진행할 것인..
IAM Identity and Access Management의 약자로 엑세스 제어를 위한 서비스이다. 대체로 IAM에서 하게 되는 것은 사용자(주 구성원)를 만들고 권한을 부여하는 것이다. 사용자는 가지고 있는 권한에 따라 원하는 리소스에 접근할 수도 있고 접근하지 못할 수도 있다. 역할 역할이란 권한을 여러개 묶어 놓은 것을 말한다. 위에서 사용자에게 권한을 부여한다고 했었는데, 사실 정확하게는 사용자에게 직접적으로 개별 권한을 부여할 수는 없고 역할을 부여해한다. 예를 들어 조직 내 누군가에게 Cloud Storage를 전체적으로 관리할 수 있도록 권한을 주고자 한다면 Cloud Storage 내 Bucket에 대한 생성, 삭제, 목록 보기 등에 대한 권한을 하나씩 부여하는 것이 아닌 생성, 삭제,..
기존에 이미 AWS를 사용하기도 했었고 회사에서 자격증 취득을 지원해주는 것도 있기 때문에 공부겸해서 자격증을 따보기로 했다. 요즘에는 어떤 개발을 하더라도 퍼블릭 클라우드를 완전 배제하는 일은 별로 없기때문에 사람들이 가장 많이 따는 자격증 중 하나가 아닐까 싶다. 공부 기간: 12일 시험일 : 10월 28일 공부방법 친구한테 Udemy가 좋다는 말을 들어서 강의(이름만 강의고 모의시험)를 구매해서 공부했다. 총 6회의 모의시험이 있으며 하루는 문제풀고 하루는 해답보고하면 딱 12일동안 6회차를 전부 볼 수 있다. 나같은 경우는 이미 실무에서 좀 다양하게 AWS를 사용하고 있고 네트워크도 기초는 가지고 있는 상태에서 시작했기때문에 비교적 짧고 쉽게 시험을 치뤘지만 만약에 AWS 실무경험이 없거나 기초가..
CodeDeploy와 ELB를 활용해 Blue/Green 배포 중 헷갈리는 부분이 있었다. 기존에 알고있던 Blue/Green 배포 방식은 아래와 같았다. 부끄러운 일이지만 여태까지는 Blue/Green 배포가 이런 방식으로 진행되는 줄 알았다. 즉, AZ 단위로 하나씩 배포되는 방식인줄 알고 있었던 것이다. 더 부끄러운 것은 위 동작 방식은 동작 방식 그 자체도 Blue/Green 배포 방식이 아니다. 이렇게까지 잘못 이해하고 있었던 이유는 처음부터 배포단위를 착각했었던 이유가 제일 컸다. 그럼 AWS를 사용해 Blue/Green 배포에 대해 자세하게 살펴보자. 만약에 Blue/Green 배포가 무엇인지 모른다면 아래 글을 가볍게 읽고오자. https://www.redhat.com/ko/topics/d..
Jenkins를 설치했다면 파일을 주고 받기위해 RSA 암호화 키를 생성해야 한다. RSA Key를 생성하는 이유는 Jenkins에서 Git Repository에 접근할 때 Http가 아닌 SSH 방식으로 접근할 것이기 때문이다. 그럼 Key를 먼저 생성해보자. 생성하는 위치는 Jenkins가 설치되어 있는 서버 내 아무곳에나 생성하면 된다. $ ssh-keygen -t rsa -f study Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in study. 패스워드의 경우 일단 비워두고 진행하도록 하자. -t 암호화 형식이다. RSA를 사용할 것이므로 rsa로..
회사 프로젝트 중 크롤링 Batch 서버를 구축해야할 일이 생겼다. 새롭게 들어온 팀원이 맡아서 진행하기로 했는데 기왕 하는 거 Docker Image push 까지 자동화 구축 후 진행을 하면 좀 더 편하게 개발을 하지 않을까 싶어 구축 과정을 간략하게 기록하려한다. 사내 서비스 운영은 인력 부족 및 금액 적인 부분 때문에 AWS에 많이 의존하고 있다. 현재 구축하려는 서비스도 MongoDB를 활용하려다가 데이터가 쌓이면 관리하기 힘들어질 것 같아 DynamoDB를 활용하기로 했다. 구축하고자 하는 개발 프로세스는 다음과 같다. 먼저 로컬에서 github repository를 remote하여 개발하다가 이슈 단위의 작업이 종료되면 Github의 Task branch에 Push 후 develop bran..
이슈관리 현재 사내에서는 원격 Git repository로 Github를 채택해서 사용하고 있다. 현재 구성원은 백엔드 개발 2명 프론트개발 1명이 맡아서 하고 있고 각 개발자들은 자신들이 맡은 영역을 개발하고 있으며 겹치는 부분이 있지는 않아 협업으로서의 Git사용을 하고 있지는 않다. 그래서 Git을 코드 관리 측면에서만 계속 사용하고 있었고 간단하게 Branch 관리만 하면서 작업을 진행하고 있었다. 하지만 개발이 진행됨에 따라 출시 이후 버전 관리라던가 개발 및 배포 프로세스를 어떻게 잡을 것인지 주기는 어떻게 할 것인지 등 다양한 문제를 생각하지 않을 수 없게 되었다. 사실 개발을 시작했을 때부터 고민하고 잡고 갔어야했을 문제였지만 사정이 여의치 않다는 핑계를 대면서 미뤄왔었고 이제 간단하게 나..