ecsimsw

EKS 모니터링하기 / Cloudwatch 세팅부터 Metric slack 알람까지 1. EKS의 Metric 정보를 fluentbit와 cloudwatch agent를 이용하여 Cloudwatch로 모니터링한다. 2. Cloudwatch의 알람을 Slack으로 전송한다. docs : https://catalog.us-east-1.prod.workshops.aws/workshops/9c0aa9ab-90a9-44a6-abe1-8dff360ae428/ko-KR/90-monitoring/100-build-insight CWagent 설치와 Fluentbit 를 Daemonset 으로 선언 cwagent-fluent-bit-quickstar.yaml 다운 받는다. wget https://raw.githubuse..

NO_PUBKEY B53DC80D13EDEF05 Google cloud에서 반환하는 gpg key 포맷이 'OpenPGP ASCII armor'로 변경되면서 기존 kubernetes docs에서 소개하는 Installing kubeadm 방식을 사용하는 경우 gpg key이 올바르지 않는 문제가 발생한다. 혹시 Kubeadmin, Kubelet, Kubectl 을 설치하는 과정에서 apt repository를 등록하고 apt update로 package 업데이트 시 아래와 같은 key 에러(NO_PUBKEY B53DC80D13EDEF05)를 만났다면 이전 방식으로 설치를 진행하진 않았는지 점검한다. Err:2 https://packages.cloud.google.com/apt kubernetes-xeni..

Dynamic secret 정적인 Secret은 위험하다. 사용자가 모두 같은 키 공유하기 때문에 하나의 키만 탈취당해도 모든 권한을 갖는다. 마찬가지로 하나의 키를 공유하여 여러 서비스가 사용하고 있기에 퇴사자가 생기거나 탈취 상황에서 키를 만료시키기 쉽지 않다. 극단적인 예로 하나의 AWS 키를 모든 개발자와 CI/CD agent가 사용하다가 퇴사자가 나쁜 마음을 먹고 키를 사용한다고 가정해 보자. 키를 revoke -> renew 하는 사이 시간 동안 모든 개발 작업, CI/CD 동작들이 멈출 것이다. Dynamic secret은 미리 정의한 사용자 허가 범위에 따라 임시 키를 만들어 사용자에게 반환한다. 그 임시 키는 사용자마다 공통되지 않고, 만료 기간이 정의되어 있어 기간 외엔 사용할 수 없는..

Vault 시작하기 Vault의 가장 기본적인 기능들을 소개한다. 0. Vault dev server 실행 1. Secret Engine의 개념과 Secret 생성 2. Seal / Unseal 3. Auth engine / Auth method 4. Policy로 접근 가능 리소스, 액션 제한 5. Entity, 여러 인증 방식을 사용자로 묶어 관리 6. Group, 여러 Entity를 집합으로 관리 0. 간단한 Dev server 실행 Dev server 설치가 간단해서 로컬에서 먼저 테스트해 보기 좋다. 실 서버는 정책이나 설정, Audit을 저장할 저장소가 필요하지만 개발 서버는 인 메모리로 실행되어 Vault 외 준비할 것들이 없다. 1. vault 설치 brew tap hashicorp/tap..

AWS 자원 생성 시에 태깅을 강제하자 AWS의 비용을 계산하고 유휴 자원을 관리하려고 한다. 문제는 어디에 사용되었는지 모르는 레거시 자원들과 여러 팀이 얽힌 프로젝트, 퇴사자들로 이 자원이 현재 사용되고 있는지, 바로 삭제해 버려도 되는지 자원의 출처와 사용처를 알기 어려웠다. 이런 배경 아래, 자원 생성하는 과정에서 태깅을 강제하는 정책을 고민했고 이를 IAM Policy로 풀었던 경험과 필요 개념, 간단한 팁을 공유하고자 한다. 0. 요구 사항 0. 기존 Policy 정책/사용자 그룹은 가능한 건드리지 않도록 한다. 1. 사용자는 정책으로 지정한 자원을 생성하는 경우 태그를 붙여야만 한다. 2. 단순히 태그의 Key 값만 일치하면 생성을 허용할 수 있는 조건이 있을 수 있다. 3. 태그의 Key에..

How to add new hosted VPC 회사 내부에서 사용하는 내부 서비스 도메인이 public하게 열려있었다. 이를 외부에 노출되지 않도록 하고 싶었다. 개발/테스트/배포 환경 등 서비스 환경에 따라 다른 AWS 계정과 리전, 인프라가 분리되어 있었고, 모든 각 계정/리전마다 사용할 DNS를 등록하는 것이 아닌 전면의 한 계정에서 공통된 도메인을 갖고, 노출된 VPC만 따로 등록하는 식으로 관리 포인트를 줄일 수 있었다. Route53의 private dns를 사용해서 지정된 VPC 안에서만 접근할 수 있는 내부용 DNS를 만들 수 있었다. How to configure Route53에서 Dns를 생성할 때 private hosted zone 를 선택할 수 있다. 이때 같은 도메인 이름으로 pu..

개념 1. 리버스 프록시 / Web server와 Web Application Server의 분리 서버 아키텍처에서 WAS(web application server)와 web server를 분리하는 방식이 보편적으로 사용되고 있다. 위 구조처럼 사용자 요청을 처리하는 로직을 갖는 서버 애플리케이션 전면에서 web server를 둬, 사용자 요청이 해당 web server를 거쳐 WAS에 전달되고, 반대로 WAS에서 처리가 완료된 결과가 WAS를 거쳐 다시 사용자에게 응답하는 구조이다. 이렇게 WAS 전면에 요청을 선 처리할 수 있는 web server를 두는 형태, 또는 그 web server를 리버스 프록시(reverse proxy)라고 한다. 이런 구조가 갖는 이점은 다음과 같다. 1. 정적 요청에 ..

도입 배경 시작하기 앞서 기존의 배포 방식을 먼저 설명하려고 한다. 적용한 프로젝트의 배포 방식은 아래 그림처럼, 젠킨스가 프로젝트를 빌드, 전달하고 실행 스크립트에 의해 인스턴스 내부에서 실행하고 있다.   그렇게 빌드된 jar 파일을 실행하는 과정은 단순히 실행 중인 Application 프로세스를 종료하고, 새로 빌드된 Application을 띄우는 것이었는데, 이런 기존 방식에 두 가지 문제가 있었다. 기존 방식의 실행 스크립트 확인하기더보기#!/bin/bashecho "> now ing app pid find!"CURRENT_PID=$(pgrep -f back-end) # PID 구별 key로 back-end가 들어갔다. 본인 환경에 맞게 수정한다.echo "$CURRENT_PID"if [ ..