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

도입 배경 시작하기 앞서 기존의 배포 방식을 먼저 설명하려고 한다. 적용한 프로젝트의 배포 방식은 아래 그림처럼, 젠킨스가 프로젝트를 빌드, 전달하고 실행 스크립트에 의해 인스턴스 내부에서 실행하고 있다.   그렇게 빌드된 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-..

배경 이번 프로젝트의 경우에는 jdk8이 문제가 없던 상황에서 잘 쓰다가 jdk11이 필요한 상황이었다. 예를 들면 rabbitMQ나 sonarqube를 사용하는데 11 이상이 필요한 것을 확인했다. dev 서버, prod 서버, 프론트 서버, 딥러닝 학습 서버,,, 이번 프로젝트 안에서 기존에 젠킨스 설정을 잡아둔게 너무 많아 새로 젠킨스를 설치할 수는 없었고, 결국 버전을 바꾸기로 했다. 그 과정이 명확하게 설명이 된 블로그가 없길래 한번 정리해본다. default version : 8 도커를 이용해서 젠킨스 설치 시 기본으로 설치되는 jdk 버전은 8이다. 젠킨스 서버 내부에서 jdk 를 설치하고, 버전을 지정할 수 있는데 무료는 젠킨스9 까지이다. 그런데 젠킨스에서 설치 지원을 안한다는거지 젠킨스..

젠킨스 삽질 과정에서 배운 것들 Jenkins를 설정하면서 다음을 배웠다. 1. 리눅스 가상 메모리 설정 (스왑 파일 생성) aws 프리티어 인스턴스가 지나치게 느려 메모리 문제임을 확인하고 가상 메모리를 설정하였다. 코틀린 빌드 시간이 말도 안되게 느렸고, 가상 메모리로 해당 문제를 해결할 수 있었다. (결국 용량 문제로 Medium으로 갈아탔다.. ) 스왑 파일을 사용하여 Amazon EC2 인스턴스의 스왑 공간으로 메모리 할당 1. dd 명령을 사용하여 루트 파일 시스템에 스왑 파일을 생성합니다. 명령에서 bs는 블록 크기이고 count는 블록 수입니다. 스왑 파일의 크기는 dd 명령의 블록 크기 옵션에 블록 수 옵션을 곱 aws.amazon.com 2. 리눅스 포트포워딩 (iptables) 젠킨스..