공부기록

Apache WebServer는 mod_proxy라는 모듈에서 forward proxy, reverse proxy 두가지 기능을 제공

NginX는 필요한 기능만 제공하는 고성능 웹서버로 reverse proxy기능만을 제공

Forward Proxy

• 사용자가 다른 사이트로 연결을 하려면 사용자 ↔ 서비스 가 바로 연결되는 것이 아니라 중간에 Forward Proxy를 거쳐서 연결이 된다.
• 캐시 기능이 있어 성능에 좋다.
• 보안이 좋다.
  • 정해진 사이트만 연결하게 설정할 수 있어 보안이 중요한 기업 환경에서 많이 사용된다.
  • 기관에서 사내 네트워크를 관리할 때 사용한다고 생각하면 된다. 인터넷 사용에 제한을 두어서 보안에 유의할 수 있도록 해주는 역할

Reverse Proxy

사용자가 example.com 웹 서비스에 데이터를 요청하면 이 Reverse Proxy가 요청을 받고 내부 서버(WAS)에서 데이터를 받아 다시 전송하게 됩니다.

웹 서버의 앞에 두어서 로드밸런싱 역할을 수행할 수 있다.

장점

• 보안
  • WAS를 최전방에 두게 된다면? WAS가 해킹을 당하면 관련 서버와 DB까지 모두 해킹당하는 심각한 보안 문제가 생긴다. 
  • 웹 서버만 내부 WAS와 연결하도록 설정하면 웹 서버가 해킹을 당해도 2차 방화벽이 있어 보안에 더 강해질 수 있다.
  • SSL 암호화
    • 들어가고 나가는 복호화/암호화를 해주어서 원래 서버가 하는 부담을 줄여준다.
• 속도와 안정성
  • Cache Server를 붙이거나 SSL 하드웨어 가속기를 연동하는 등 아키텍처 측면에서 성능을 향상 시키기 용이
  • CDN을 연동한다면 DDOS 공격을 효과적으로 방어하고 안정적으로 서비스를 제공할 수 있다.
• 신뢰성 증대
  • 사용자가 증대하는 상황에 맞게 Web Server나 WAS를 유연하게 늘릴 수 있다.

참고

https://www.lesstif.com/system-admin/forward-proxy-reverse-proxy-21430345.html

https://losskatsu.github.io/it-infra/reverse-proxy/#3-%EB%A6%AC%EB%B2%84%EC%8A%A4-%ED%94%84%EB%A1%9D%EC%8B%9Creverse-proxy-%EC%84%9C%EB%B2%84%EB%9E%80

프로젝트를 진행하면서 Vue.js 배포를 담당하게 되었다.

기존에는 git에서 클론받아 직접 배포를 진행했었는데 CI/CD를 통해 환경을 구축하고 싶었다.

일단은 백엔드 배포를 통해서 Jeinkins 환경은 구축이 되어있었다.

먼저, CI/CD를 구축하기 위해서는 다음과 같은 절차로 배포한다.

1. Local에서 Test
2. Server에서 Test
3. NginX에서 배포하기 
4. CI/CD 구축하기

꼭꼭 테스트를 진행해보면서 이상이 없는지 확인하고 CI/CD를 구축

1. Local에서 Test하기

이건 개발하면서 계속 확인해 봤을 거라고 생각

2. Server에서 Test

서버에서도 똑같이 테스트해 본다

cd {Vue Project Name}
npm install 
npm run serve

http://{domain or ip}:8080

해당 url로 접속해서 잘 접속되는지 확인한다.

3. NginX를 통해서 Test

NginX는 Reverse-Proxy 서버이자 웹서버

1. NginX 설치

sudo apt install nginx
nginx -v

2. NginX 설정 변경

아까 git clone을 받은 프론트 프로젝트에서 다음과 같은 명령어를 통해 빌드 진행

npm install
npm run build

해당 폴더 내부에 dist라는 폴더가 생성된 것을 확인할 수 있다.

pwd 명령어를 통해 해당 디렉토리의 경로를 확인하고 설정을 진행한다.

sudo vi /etc/nginx/sites-enabled/default

이제 Nginx를 실행시킨다.

# syntax 검사
sudo nginx -t 
sudo service nginx restart

http://{domain or ip}로 접속해서 잘 접속이 되는지 확인한다.

4. CI/CD 구축

먼저 Jenkins가 이미 구축되어 있던 환경이었기 때문에 바로 Jenkins 설정부터 진행

1. Jenkins Plugins에서 nodejs 추가

Vue는 nodejs 환경이기 때문에 플러그인에서 Nodejs를 추가해주어야 한다.

Dashboard > Jenkins 관리 > Tools 에서 Nodejs 버전 선택해서 추가

2. 스크립트 작성

아까 위에서 했던 빌드와 배포를 그대로 Jenkins의 스크립트를 통해서 진행한다고 생각하면 된다.

1) 다음과 같이 Execute NodeJS script를 통해 NodeJS를 사용하겠다고 추가해 준다.

2)  빌드 수행

Execute shell을 하나 추가해서 빌드를 수행시킨다.

cd /var/jenkins_home/workspace/fe_deploy/fe
npm install
npm run build

3)  빌드 수행한 결과(dist 폴더)를 프론트가 있는 서버로 전송

Send files or execute commands over SSH 추가

- 기존 서버에 있는 빌드 파일부터 삭제

빌드 →  배포가 계속해서 일어나기 때문에 파일을 보내기 전에 기존에 보냈던 빌드 파일을 삭제하고 진행

-  파일 전송

dist 폴더는 내부에 js, css 등 다양한 파일과 폴더가 존재한다.

이러한 파일들을 모두 보내기 위해서 **/* 로 설정해 줘야 모두 전송이 된다.

• Source files : 현재 서버에서의 파일 위치
• Remove prefix: 앞에 주절주절 붙어있는 거 지우고 다른 서버로 보내기 위해 지우기
• Remote directory: 보낼 곳의 위치 (나는 /front로 보내기로 /var/www/html은 권한이 없음…)
• exec command: 보내고 나서 보낸 서버에서 수행할 스크립트 → 서버 재실행!!

echo "Sending dist file over SSH 1"
sudo service nginx restart

5. 이제 프론트가 있는 EC2서버에서 빌드 파일을 받은 장소를 NginX 설정에 반영

sudo vi /etc/nginx/sites-enabled/default

6. 이제 GitLab에서 푸시하였을 때 자동으로 Jenkins가 배포할 수 있도록 Webhook을 설정

Jenkins

Jenkins > { Job Name } > Configuration > 빌드유발

다음과 같이 설정

고급에서 Secret token을 생성하여 복사!

Gitlab

발급받은 Secret token을 Gitlab의 Webhook에 설정

URL은 Job이름이랑 맞추면 된다.

7. Test를 통해 CI/CD 구축 확인

Gitlab에서 Push events를 눌렀을 때 Jenkins에서 잡을 실행하고 잘 수행한다면 구축이 완료된 것이다.

1.  배포란

컴파일 -> 빌드 -> 배포의 과정을 통해서 사용자는 해당 소프트웨어를 접근할 수 있다.

• 컴파일 : 작성된 코드를 컴퓨터가 이해할 수 있는 언어로 번역
• 빌드: 컴파일된 코드를 실제 실행하도록 만든다. (결과물이 war, jar과 같은 파일!!)
• 배포: 사용자가 서비스에 접근할 수 있도록 만든다.

2.  왜 CI/CD를 구축할까?

CI/CD

• Continuous Integration/Continuous Delivery
• 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포
• 애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법

실제 서비스에서는 많은 서버들이 동작하고 있다.

만약, CI/CD 환경이 구축되어있지 않다면 여러개의 서버를, 하나의 서버도 여러개로 복제하는 상황에서 관리하기가 매우 힘들다.

그래서, 배포를 자동화해두면 서버 하나하나를 매번 배포하는 것이 아니라 자동으로 배포해서 관리할 수 있다.

보통 배포를 위한 전용 서버를 두는데 배포에 사용되는 스크립트를 작성하고 트리거를 통해 해당 스크립트가 동작 → 배포

: 이러한 일을 하는 서버를 Jenkins를 이용하여 구성하려고 한다.

3.  배포 전용 서버 Jenkins

Jenkins는 JavaRuntime 위에서 동작하는 프로그램 → JavaRuntime 환경이 구축되어야 한다. 

따라서 하나의 클라우드 서버 내에서 Jenkins 서버와 EC2 서버를 사용할 경우 환경 분리를 위해 Docker를 많이 사용한다.

EC2에 Kafka를 설치해보려고 하는데 관리하기 쉽도록 오픈 소스인 provectuslabs/kafka-ui를 사용하려고 한다.

1. Docker-compose로 설치하는 방법
2. Docker 없이 수행하는 방법

두가지로 진행해보려고 한다.

왜냐하면 Docker-compose로 실행을 했더니 외부에서 해당 카프카를 접속하는데 계속 실패를 했다... (개발 환경이었기 때문에 접근이 불가능했지만 배포 후에는 잘 동작한다)

그래서 도커 없이 Kafka를 실행시키는 방식으로 구현했지만 기록으로 남겨둔다.

1. Docker-compose로 설치

mkdir kafka 
cd kafka 
vi docker-compose.yml

version: '3.8'
services:
  zookeeper-1:
    image: confluentinc/cp-zookeeper:5.5.1
    ports:
      - '32181:32181'
    environment:
      ZOOKEEPER_CLIENT_PORT: 32181
      ZOOKEEPER_TICK_TIME: 2000

  kafka-1:
    image: confluentinc/cp-kafka:5.5.1
    ports:
      - '9092:9092'
    depends_on:
      - zookeeper-1
    environment:
      KAFKA_BROKER_ID: 1
      KAFKA_ZOOKEEPER_CONNECT: zookeeper-1:32181
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka-1:29092,EXTERNAL://localhost:9092
      KAFKA_DEFAULT_REPLICATION_FACTOR: 1
      KAFKA_NUM_PARTITIONS: 1

  kafka-ui:
      image: provectuslabs/kafka-ui
      container_name: kafka-ui
      ports:
        - "8989:8080"
      restart: always
      environment:
        - KAFKA_CLUSTERS_0_NAME=local
        - KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=kafka-1:29092
        - KAFKA_CLUSTERS_0_ZOOKEEPER=zookeeper-1:22181

sudo docker-compose up -d

 배포환경에서는 같은 네트워크를 잡아주고 해당 도커 네임(http://kafka1-1:9092)으로 레코드를 보내면 잘 전송이 되지만 개발 환경에서 해당 브로커로 데이터를 보내는데 실패했다. 일단, 개발환경이기 때문에 Docker없이 데이터를 전송하기로 결정하고 아래의 환경으로 개발했다.

2. Docker 없이 수행

sudo apt-get install wget

# kafka download
wget https://archive.apache.org/dist/kafka/3.2.1/kafka_2.13-3.2.1.tgz

tar -xzf kafka_2.13-3.2.1.tgz
cd kafka_2.13-3.2.1/

vi config/server.properties

config/server.properties 설정

1. 외부 IP 알아내기

curl ifconfig.me

2. 해당 IP로 config/server.properties 설정

#listeners=PLAINTEXT://:9092

# Listener name, hostname and port the broker will advertise to clients.
# If not set, it uses the value for "listeners".
advertised.listeners=PLAINTEXT://{외부 IP}:9092  

# Maps listener names to security protocols, the default is for them to be the same. See the config documentation for more details
#listener.security.protocol.map=PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL

3. Kafka 실행

# zookeeper 먼저 실행
./bin/zookeeper-server-start.sh -daemon ./config/zookeeper.properties

# kafka server 실행
./bin/kafka-server-start.sh -daemon ./config/server.properties

Kafka 설치 끝!!

이제 Kafka를 관리하기 위한 UI를 설치해보려고 한다.

kafka-UI 설치

docker run -p 8989:8080 \\
-e KAFKA_CLUSTERS_0_NAME=local \\
-e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS={카프카가 동작하는 외부 IP}:9092 \\
-e KAFKA_CLUSTERS_0_ZOOKEEPER={주키퍼가 동작하는 외부 IP}:2183 \\
-d provectuslabs/kafka-ui:latest

Kafka UI로 접근

http://{ip or domain}:8989/

UI 수행되는지 확인 

혹시 접근이 안된다면 아래에 있는 방화벽 설정 확인!!

이렇게 토픽을 생성하거나 파티션을 관리하는 등 편리한 ui를 제공해준다.

이제 외부에서 해당 카프카로 데이터를 전송해보도록 하겠습니다.

방화벽 설정

일단 방화벽부터 설정해서 외부에서 해당 포트로 접근하도록 허가해줍니다.

sudo ufw enable

// kafka
sudo ufw allow 9092

// kafka ui (혹시 Kafka UI 접속이 안된다면 다음처럼 설정)
sudo ufw allow 8989

이제 EC2가 아닌 local 컴퓨터(내 컴퓨터)에서 카프카 프로듀서로 데이터를 전송해보도록 하겠습니다.

내 컴퓨터의 터미널에서

카프카 다운로드

wget https://www.apache.org/dyn/closer.cgi?path=/kafka/3.2.1/kafka_2.13-3.2.1.tgz
tar -xzf kafka_2.13-3.2.1.tgz

카프카 프로듀서(내 컴퓨터) -> 카프카 브로커(EC2)

cd kafka_2.13-3.2.1.tgz

// 토픽 리스트를 확인
bin/kafka-topics.sh --bootstrap-server {Kafka가 있는 EC2 외부 IP}:9092 --list

// 토픽에 데이터 전송하기
bin/kafka-console-producer.sh --bootstrap-server {Kafka가 있는 EC2 외부 IP}:9092 --topic {TOPIC NAME}

이제 UI를 통해서 데이터가 잘 받아져왔는지 확인할 수 있다!!!

참고

https://yooloo.tistory.com/98

https://velog.io/@jwpark06/AWS-EC2에-Kafka-설치하기#2-topic-생성