회사에서는 aws를 통해 서비스를 배포 운영하고 있는데, 실제 서비스들은 외부에서 접근이 불가능한 private subnet에 위치해있다. 그리고 외부에서 이 서비스를 접근하기 위해서 반드시 거쳐가야 하는 일종의 게이트웨이 역할을 하는 서버가 있는데 바로 베스천 서버이다. 베스천 서버는 public subnet에 위치하며, 여러 보안적인 이슈를 담당한다. 특정 IP만 특정 subnet에 접근가능하도록 강제를 하거나, 서버 접근 이력 정보를 남기는 등 보안적으로 많은 이점이 있다. 베스천 서버를 통해 실제 서버로 접속을 하려면 ssh 터널링을 통해 로컬 호스트에 포트를 띄우고 해당 포트로 접근을 해야했다. ssh -fnNT -L ::22 @ -i 위와 같이 타겟 서버에 맞게 입력을 해보면 아래와 같이 성공..
AWS ECR에 도커 이미지를 등록하면 {ID}. dkr.ecr.us-east-2.amazonaws.com/{리파지토리명} 형태로 도커 이미지가 등록된다. {ID}. dkr.ecr.us-east-2.amazonaws.com/{리파지토리명}:{tag} 형태로 ECR에서는 도커 이미지를 관리하는데, EC2에서 이미지를 받아서 컨테이너를 돌렸을 때, 도커 컨테이너 리스트를 확인하면 다음 사진과 같이 뜨게 된다. docker ps 돌아가는 컨테이너가 한 두개면 몰라도 20~30개가 넘어가는 경우 어떤 컨테이너가 어떤 이미지의 어느 태그 기반으로 돌아가고 있는지 확인하기가 어렵다. 그래서 다음과 같이 간단하게 쉘 스크립트를 짰다. #!/bin/bash docker ps | awk '{split($2,image,"..
2019/11/06 - [Server/Devops] - [ELK] AWS Elastic Load Balancer Log 분석하고 대시보드 만들기 [1] [ELK] AWS Elastic Load Balancer Log 분석하고 대시보드 만들기[1] AWS에서 서비스를 운영하고 있는 사람이라면, 또는 AWS Route53에 도메인을 등록하고 Https로 서비스를 하고 있는 사이트를 연동했다면 AWS Elastic Load Balancer를 사용하고 있을 것이고, 보통 다음과 같은 구조.. johnmarc.tistory.com 이전 포스팅에서는 AWS의 ELB(Elastic Load Balancer)에 대해 간략하게 알아보고, ELB의 로그 기능을 활성화하여 AWS S3 서비스에 파일로 저장하는 과정까지 설명..
AWS에서 서비스를 운영하고 있는 사람이라면, 또는 AWS Route53에 도메인을 등록하고 Https로 서비스를 하고 있는 사이트를 연동했다면 AWS Elastic Load Balancer를 사용하고 있을 것이고, 보통 다음과 같은 구조로 아키텍처를 구상했을 것이다. 위 구조를 보면 사용자는 Route53에 등록된 도메인으로 서비스에 접근하고(예: https://웨부베벱.com ) Route53에서는 해당 도메인과 연결된 Load Balancer로 요청을 보낸다. Load Balancer에서는 다음과 같이 등록된 리스너 리스트를 보고 요청에 맞는 리스너로 요청을 보내게 된다(참고: 리스너 등록 시 EC2 인스턴스의 Elastic IP를 같이 등록하기 때문에 요청을 전달할 인스턴스를 구분할 수 있다). ..
최근 NestJS 기반으로 서버 개발을 하고 있다. S3에 사용자 프로필을 업로드해야 하는 요구사항이 있어 다음과 같이 코드를 작성하여 사용하고 있다. NestJS의 Multer 라이브러리와 Multer-S3를 활용한다. 검색을 해보면 대부분 Controller 단에서 Multer-S3 라이브러리를 불러와 업로드를 하는데, 서비스단에서 비즈니스 로직을 수행하는게 맞다고 생각하여 업로드 서비스로 구분하여 구현하였다. [config.module.ts] import { Global, Module } from '@nestjs/common'; import { ConfigService } from '../service/config.service'; // Make Configuration Module To Globa..
