운영 서버 구축으로 알아보는 서버 기초 설정들

[JJ503]

운영 서버 생성 및 설정

운영 서버를 위한 VPC 및 서브넷 생성

운영 서버 - db 서버 - 개발 서버는 하나의 vpc에 있어야 하므로 peering 설정을 하기 위해선 각각 서로 다른 CIDR를 가지고 이어야 한다.

그렇기에 기본 할당된 172.31.0.0/16 대신 사용할 VPC를 생성해준다.

해당 VPC에 대한 서브넷을 생성한다

인터넷 게이트웨이 설정 후 prod vpc에 연결한다

EC2 생성하기

• 프리티어 인스턴스로 사용

• 스토리지 : 25 GiB
  

• VPC는 위에서 만들어준 VPC와 서브넷을 사용
  

DB 연결을 위한 Peering 연결 요청

• db ec2의 vpc와 prod ec2의 vpc를 VPC Peering을 통해 연결
• 이때, VPC의 CIDR는 달라야 함을 주의하자
• 자세한 내용은 discussion 참고
  

Peering 연결 수락

각 VPC의 라우팅 테이블에 피어링 연결 추가하기

• prod vpc의 라우팅 테이블
  

• db vpc의 라우팅 테이블
  

db ec2의 pem 키를 prod ec2에게 전달

sudo scp -i blooming-prod-ec2.pem blooming-db-ec2.pem [email protected]:/home/ubuntu/

연결 확인

운영 서버 DB 및 user 추가

운영 서버 데이터베이스 추가

create database blooming_prod;

운영 서버의 사용자 추가 및 권한 설정

개발 서버는 테스트용이기에 모든 권한을 준 반면, 운영 서버는 보안을 위해 최소한의 권한만 부여해준다.

• create, alter, delete, insert, select, update

use mysql;
create user 'blooming_prod_username'@'%' identified by 'blooming_password';
grant create, alter, delete, insert, select, update on blooming_prod.* to 'blooming_prod_username'@'%';

서브모듈을 통한 DB 연결

DB 설정을 운영 서버를 위한 yml 파일을 서브모듈에 생성해 추가해 준다. 그 외의 설정은 개발 서버 yml과 동일

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://172.32.6.32:3306/blooming_prod?serverTimezone=Asia/Seoul&characterEncoding=UTF-8&useSSL=false&allowPublicKeyRetrieval=true
    username: blooming_prod_username
    password: blooming_password

access-token-expire-hour만 12시간에서 30분으로 줄임

jwt:
  access-token-expire-hour: 0.5
  refresh-token-expire-hour: 1440

모니터링 툴과 연결하기

다만 아직 운영 서버에는 배포하기 전이라, 배포 후 제대로 동작하는 지 확인이 필요하다

운영 서버에 promatail 설치

Loki 깃허브 릴리즈에서 서버 설정에 맞는 버전을 사용해 다운로드 받는다
운영 서버의 경우 linux-amd64이므로 아래 명령어를 통해 설치한다

mkdir promtail && cd promtail

// promtail 설치
wget https://github.com/grafana/loki/releases/download/v2.8.11/promtail-linux-amd64.zip
sudo apt install unzip
unzip promtail-linux-amd64.zip

// promtail config 설치
wget https://raw.githubusercontent.com/grafana/loki/v2.8.11/clients/cmd/promtail/promtail-local-config.yaml

promtail 설정

server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /home/ubuntu/promtail/positions.yaml

clients:
  - url: http://15.164.164.108:3100/loki/api/v1/push

scrape_configs:
- job_name: blooming-prod-warn
  static_configs:
  - targets:
      - localhost
    labels:
      job: prod-warn-log
      __path__: /home/ubuntu/log/warn/**/*.log

- job_name: blooming-prod-error
  static_configs:
  - targets:
      - localhost
    labels:
      job: prod-error-log
      __path__: /home/ubuntu/log/error/**/*.log

promtail 실행

nohup /home/ubuntu/promtail/promtail-linux-amd64 -config.file=/home/ubuntu/promtail/promtail-local-config.yaml /home/ubuntu/promtail/promtail.log 2>&1 & 

prometheus 설정 및 실행

• prometheus.yml

- job_name: "prometheus"

  # metrics_path defaults to '/metrics'
  # scheme defaults to 'http'.

  static_configs:
    - targets: ["localhost:9090"]

- job_name: "blooming-dev"
  metrics_path: '/management/prometheus'
  scrape_interval: 1s
  static_configs:
    - targets: ["54.180.121.104:8080"]

- job_name: "blooming-prod"
  metrics_path: '/management/prometheus'
  scrape_interval: 1s
  static_configs:
    - targets: ["3.35.48.43:8080"]

• prometheus 실행

nohup ./prometheus --config.file=prometheus.yml > prometheus.log 2>&1 &

Grafana에 운영 서버 로그 추가

• 경로 로그 설정
  

• 에러 로그 설정
  

• prometheus 설정
  

운영 서버 CD 구축

• 개발 서버 CD와 동일하게 작성
• 다만, develop이 아닌 main 브랜치에서 수행되도록 함## 운영 서버 생성 및 설정

[jhsseonn]

운영서버 구축 디스커션 상세히 기록해주셔서 감사합니다. 정말 수고 많으셨습니다!
다만 몇가지 궁금한 점이 있어 질문드립니다.

1. db 서버, 개발 서버, 운영서버가 모두 같은 vpc에 위치해야한다고 하셨는데 아래 운영 서버와 db 서버의 vpc peering을 진행하는 부분에서 의문이 생겼습니다. vpc peering이 두 vpc 간에 통신을 위한 것으로 알고 있는데, 그러면 다른 vpc에 위치하고 있는 것이 아닌가 생각했습니다!
2. 운영서버와 db 서버 간의 통신이 필요하니 둘을 vpc peering을 통해 네트워크를 연결하고, 이 때 운영 서버의 경우 외부 인터넷과 연결 가능해야하니 인터넷 게이트웨이를 연결해준다. 이렇게 이해했는데 맞는지 궁금합니다.

[JJ503]

1. db 서버, 개발 서버, 운영서버가 모두 같은 vpc에 위치해야한다고 하셨는데 아래 운영 서버와 db 서버의 vpc peering을 진행하는 부분에서 의문이 생겼습니다. vpc peering이 두 vpc 간에 통신을 위한 것으로 알고 있는데, 그러면 다른 vpc에 위치하고 있는 것이 아닌가 생각했습니다!

각자 모두 다른 vpc에 위치하고 있는 것이 맞습니다.
정확히 어떤 이야기를 하다 효선님께서 말씀해 주신 이야기가 나온 지는 잘 모르겠지만, 조금 추측해서 답변드리겠습니다.
아마 같은 vpc에 위치해야 한다는 이야기는 저희가 비용이 상관없었을 때의 이야기 같습니다.
원래 같은 vpc 내에 있는 서브넷들은 private, public 상관없이 통신을 허용합니다.
그리고 저희는 db 서버의 경우 보안을 위해 해당 ec2를 private subnet으로 설정했습니다.
그렇기에 private subnet으로 접근하기 위해선 동일한 vpc에 public subnet에 있는 ec2를 생성해 접근할 수 있을 것입니다.
하지만, 현재 저희의 aws는 프리티어로 두 개 이상의 ec2를 생성하면 비용이 발생하기에 어쩔 수 없이 각 ec2 별로 다른 계정을 생성해 만들었습니다.
그렇기에 각 ec2 별로 vpc도 다른 상태입니다.
이러한 상황에서 db 서버인 private subnet에 접근하기 위해 다른 vpc에서의 연결이 가능하게 만들어주는 vpc peering을 채택하게 되었습니다.
(간단하게 설명하긴 했지만, 당시 기술을 채택했을 때의 디스커션입니다.)

그래서 결론적으로는 아마 같은 vpc에서 위치해야 하는데, 불가능하기에 같은 vpc에 있는 것처럼 만들어주는 vpc peering을 채택했다고 볼 수 있습니다!

2. 운영서버와 db 서버 간의 통신이 필요하니 둘을 vpc peering을 통해 네트워크를 연결하고, 이 때 운영 서버의 경우 외부 인터넷과 연결 가능해야하니 인터넷 게이트웨이를 연결해준다. 이렇게 이해했는데 맞는지 궁금합니다.

네 맞습니다.
vpc peering을 위해선 각 vpc의 cidr가 달라야 했기에 dev 서버와 다르게 db 서버와 prod 서버는 새로운 vpc를 생성해주었습니다.
왜냐하면 각 계정 별로 생성된 기본 vpc의 cidr는 모두 동일했기에 서로 연결이 불가능했기 때문입니다.
그래서 db와 prod는 새로 vpc를 생성해 직접 설정을 해줬어야 했는데, peering 연결 외에는 인터넷 연결을 위해 인터넷 게이트웨이에 대한 설정만 고민하면 됩니다.
이때, 아래 사진처럼 private subnet은 인터넷 연결이 되어선 안됩니다.
그래서 private subnet 용도인 db 서버측의 vpc는 인터넷 게이트웨이 연결은 하지 않고 운영 서버는 public subnet이기에 인터넷 연결이 가능하도록 인터넷 게이트웨이 설정을 추가해주었습니다.

그리고 혹시나 헷갈리실까 추가로 말씀드리자면, vpc peering의 경우 한 쪽에서만 설정하는 것이 아닌 양측 모두에서 라우팅 테이블에서 연결을 설정해줘야 합니다.
그래서 도움이 될지는 모르겠지만, 아래 그림과 같이 라우팅 테이블이 설정되어 있는 상태입니다.