ecsimsw

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

요구 사항 : trigger filtering by tag name 회사에서 젠킨스 Trigger를 사용해서 레포지토리에서 발생하는 web hook을 받아 빌드를 자동으로 할 수 있도록 하는 작업을 맡게 되었다. 문제는 한 레포지토리 안에서, branch나 comment가 아닌, tag 이름으로 구분되는 Job이었다. - 한 코드 저장소 안에서 tag로 구분된 여러 JOB이 있었다. - 태그가 생성되는 이벤트를 받아 이 여러 JOB 빌드를 실행시켜야 하는데, JOB에 해당하는 tag가 아닐 경우 빌드를 실행시키지 않는 필터링이 추가되어야 한다. Webhook request 안의 정보를 이용해서 깔끔하게 필터링 할 수 있는 방법을 고민했고, 괜찮은 플러그인을 찾아 소개하게 되었다. 1. Generic We..

개념 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. 정적 요청에 ..

AWS 스토리지 서비스- EBS (Elastic Block Store): 내 컴퓨터에 직접 꽂는 SSD. 속도가 가장 중요할 때 사용. 1:1 연결.- EFS (Elastic File System): 사무실 여러 컴퓨터가 함께 쓰는 네트워크 공유 폴더(NAS). 파일 공유 시 사용. 다수:1 연결.- S3 (Simple Storage Service): 용량 무제한의 웹하드. 백업, 데이터 레이크, 파일 서빙 등 범용적 목적. API/URL 연결.1. S3 (Simple Storage Service)- 개념 : 용량 무제한의 웹하드(Dropbox). 백업, 데이터 레이크, 파일 서빙 등 범용적 목적. API/URL 연결.- 스토리지 타입 및 연결: - 객체(Object) 스토리지. 파일(객체)과 메타데..

AWS 보안 서비스- Secrets Manager: 비밀 정보의 수명 주기 관리 및 자동 교체.- ACM: SSL/TLS 인증서의 발급 및 자동 갱신.- KMS: 데이터 암호화에 사용하는 암호화 키 생성 및 제어.- Parameter Store: 설정값 및 자동 교체가 불필요한 단순 비밀 정보 관리. 서비스 상세 정보Secrets Manager- 핵심 목적: 비밀 정보의 저장, 감사, 자동 교체 등 수명 주기 관리.- 관리 대상: DB 패스워드, API 키, OAuth 토큰.- 핵심 기능: 자동 비밀 교체, 세분화된 접근 제어, 중앙 감사.- 비용 구조: 비밀 개수와 API 호출 수에 따라 과금.- 주요 통합: RDS, DocumentDB 등 데이터베이스 서비스. ACM- 핵심 목적: SSL/TLS 인증..

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

CloudWatch agent 로그 파일 지정과 이벤트 수집Spring application에서 발생하는 로그 파일을 확인하기 위해 매번 인스턴스에 직접 들어가서 파일을 확인하는 작업은 번거롭고, 위험하다. 가급적이면 개발자 개인이 배포 서버 인스턴스를 직접 건드는 작업을 피하고 싶었고, application에서 생성되는 로그 파일을 CloudWatch에 출력하고자 했다. 애플리케이션에서 생성된 파일을 CloudWatch에 출력하는 방법, 그리고 파일로 생성하지 않고 서버의 정보를 CloudWatch에 직접 뿌리는 방법을 공부해왔다. 전자의 경우에는 에러 파일을 그래도 출력하기 위함이었고, 후자의 경우에는 서버의 동작 여부를 확인하기 위함이었다.  해당 프로젝트내에선 사실상 에러 로깅 외의 로그가 없었고..

AWS Cloudwatch Agent AWS Cloudwatch로 인스턴스 상태를 확인, 관리할 수 있다.  CloudWatch에서 기본적으로 제공하는 cpu 사용률, 네트워크 패킷 수 외에도, 다음을 따라 Cloudwatch agent를 이용하면 해당 인스턴스의 메모리와 디스크 사용률까지도 확인할 수 있다.  적용한 Cloudwatch 대시보드는 아래와 같다.    1. IAM role, ec2 cloudwatch API 생성 2. 원하는 ec2 인스턴스에 해당 role 적용 3. 우분투 기준, CloudWatchAgent 다운로드 및 설치 wget https://s3.amazonaws.com/amazoncloudwatch-agent/ubuntu/amd64/latest/amazon-cloudwatch-..