공부기록

TCP/IP 프로토콜 스택

최근 네트워크는 TCP/IP와 이더넷으로 이루어져 있다.

TCP (트랜스포트 계층)/ IP(네트워크 계층)이지만 함께 동작하고 있어서 프로토콜 스택이라고 부른다.

OSI 7계층

• 애플리케이션 계층 (상위 계층) : 애플리케이션 계층, 프레젠테이션 계층, 세션 계층 (5~7계층)
• 데이터 플로 계층 (하위 계층) : 트랜스포트 계층, 네트워크 계층, 데이터 링크 계층, 피지컬 계층 (1~4계층)
  • 데이터를 상대방에게 잘 전달하는 것을 목표

OSI 7계층

1. 1계층 (피지컬 계층)

전기 신호를 그대로 잘 전달하는 것이 목적

주소에 대한 개념이 없어 전송한 포트를 제외하고 모든 포트에 같은 전기 신호를 전송 

- 허브, 리피터, 케이블, 커넥터, 트랜시버, 탭

2. 2계층 (데이터 링크 계층)

주소 정보를 정의, 정확한 주소로 통신되도록 하는 것을 목표

내가 보낸 것이 맞는지, 처리해야 하는지를 검사 후 처리

데이터에 대한 에러 탐지, 수정

플로 컨트롤 : 받는 사람이 현재 데이터를 받을 수 있는 상태인지를 확인

- 네트워크 인터페이스 카드 (NIC) : 고유 MAC 주소를 갖고 있어, 나에게 보낸 데이터인지를 확인 후 메모리에 적재

- 스위치: 단말이 어떤 MAC 주소이고 연결된 포트는 어느 것인지를 알고 있어 포워딩 하는 역할

3. 3계층 (네트워크 계층)

논리적인 주소(IP 주소) 정의 -> 사용자 변경 가능

1.2.3.4 이면 1.2는 네트워크 주소, 3.4는 호스트 주소

- 라우터 : IP 주소로 최적의 경로를 찾아 패킷을 전송

4. 4계층 (트랜스포트 계층)

정상적으로 데이터를 잘 보냈는지 확인

패킷의 경우 데이터를 분할하고 패킷에 넣어 전송하기 때문에 유실 또는 순서가 변경될 수 있기 때문

• 시퀀스 번호 : 패킷에 보내는 순서 명시
• ACK 번호: 받는 순서

- 로드밸런서: 부하를 분산

- 방화벽: 보안 정책 수립

5. 5계층 (세션 계층)

응용 프로세스의 연결 성립을 도움, 실제 세션을 관리

에러로 중단된 통신에 대한 복구와 재전송 수행

6. 6계층 (프레젠테이션 계층)

표현 방식이 다른 애플리케이션이나 시스템 간의 통신을 위해 구문 형식을 변환

암호화, 압축 등이 이루어진다.

7. 7계층 (애플리케이션 계층)

애플리케이션 프로세스 정의, 서비스 수행

대표 프로토콜: FTP, SMTP, HTTP, TELNET

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를 많이 사용한다.