[개발일지] 배포 삽질기 | 심볼릭 링크, 리눅스의 Capacities, ufw, netstat

개요

---

새로운 프로젝트 배포 테스트를 하는 과정에서 했던 삽질에 대해 기록한다.

하나의 도메인 내에서 여러 포트를 사용하고, 또 여러 웹서버를 사용하는데 제대로 서버/네트워크를 파악하지 못할 시 시도해볼만한 것들이다.

 

내가 진행한 서버의 개략적인 상황은 다음과 같다.

 

• HTTP/HTTPS 요청
• 80, 8085, 8080 - Tomcat, Apache, java application
  • 이 중에서 8080은 서버(platform) 역할을 한다.
• 8081 - Node.js(React), Nginx

 

 

일단 Ningx 웹서버 위에 React 프로젝트를 올리는 건 따로 포스팅할 예정이다. 여기서는 정말 내가 했던 삽질, 날 것을 다룬다...

까먹지 않으려고 기록하는 용이고 필요하다면 키워드를 통해 다른 사람도 활용할 수 있도록 정리해볼 것이다.

 

 

 

---

포트포워딩 관련 문제가 생겼다면 체크해볼 것

 

• application 레벨에서 port 설정이 잘 되어있는가? 예를 들어, 자바 애플리케이션은 프로퍼티 파일에 server.port=80 이런식으로 설정할 수 있다.
• 방화벽이 잘 세팅되었는가? -> VPC나 ubuntu같은 경우는 ufw로 해결
• 클라우드 환경에 배포한다면, 사용할 포트에 대해 허용해줬는가? -> ufw 등 리눅스 명령어로 방화벽 관리
• Nginx같은 웹서버라면, .conf 등의 세팅 파일 확인 -> 서버의 포트가 잘 설정되었는지 직접 파일을 열어 확인할 수있다.

 

 

---

다양한 Linux - Debian / RedHat

Linux는 UNIX 기반의 다중 작업을 지원하는 네트워크 OS다.

Linux는 오픈소스이기에, 다양한 많은 버전의 리눅스가 있다.

 

대표적인 Linux OOS

회사	대표적인 Linux	관리 패키지
RedHat	CentOS	yum
Debian	Ubuntu	apt / apt-get

 

• 이 둘 간의 차이를 명확하게 이해하지 못해서 약간의 시간 낭비를 했다.
• RedHat 계열의 CentOS는 2021년부로 업그레이드를 하지 않으므로, 사용에 주의하도록 하자. 

 

처음엔 비교적 더 저렴한 CentOS에서 node 프로젝트를 배포하는 작업을 했다.

그런데 GLIBC_2.27’ not found (required by node) 이런 에러가 발생하였다. 이는 해당 OS가 아래 목록의 라이브러리를 지원하지 못하는 케이스다.

 

 

 

해결하는 방법은 다음과 같다.

1. OS를 업그레이드한다.
2. OS를 바꾼다.

1번은 내가 정확하게 이해한 건지도 모르겠고 여러 개발 커뮤니티, 문서 등에서 2번을 추천했기에 과감히 2번으로 선택했다. 많이 귀찮아질 것을 예상했지만... 요구사항이 Node 버전은 18이상이었기에, 이를 맞추려면 불가피한 선택이었다. 나도 이 과정 때문에 알게된건데 CentOS는 더이상 업그레이드가 안되는 구버전의 linux다. 그냥 ubuntu 쓰자.

 

 

 

---

심볼릭 링크(symbolic link)

자바 애플리케이션을 배포하기 위해서 자바를 다운 받는다.

이후, which java 등의 명령어를 통해 자바 위치를 확인할 것이다. 이때 나오는 경로는 심볼릭 링크일 확률이 높다.

 

심볼릭 링크란

말 그대로 symbol. 실제 주소는 따로 있고 참조하는 링크다.

 

왜 심볼릭 링크를 쓰는가?

관리가 편하다, 공간 절약, 편의성 등등 .. 여러가지 이유가 있는데... 솔직히 잘 이해는 가지 않는다ㅠㅠ

이 부분에 대해서 심도있게 학습한 후 정리해야겠다.

 

진짜 링크 확인 방법

readlink -f [symbolic link]

 

애플리케이션 실행 시 심볼릭 링크를 사용해도 문제는 없다.

그러나 이 개념을 알고 있으면 애플리케이션 실행 및 배포에 문제가 생겼을 때 여러모로 활용할 수 있다.

 

---

Ubuntu 서버의 방화벽

GCP에서 방화벽을 관리하지만, ubuntu 자체에서 관리하는 방법도 있다.

 

바로 ufw라는 것인데, Uncomplicated Firewall의 약자로 방화벽 관리 프로그램이다. 명령어를 통해 간단하게 관리가 가능해서 편리하고 유용하다.

 

ufw 대표적인 사용 예제

# ufw 설지
apt-get install ufw

# ufw 활성화
sudo ufw enable

# 방화벽을 허용하는 명령어
ufw allow ${port_number}

# 허용된 방화벽 포트 확인
ufw status verbose

 

주의할 점

클라우드 컴퓨팅 서비스를 이용하고 ufw를 사용하고 싶다면, 일단 enable 한 뒤에 22번 포트부터 열어주자.

바보같이 22번 포트를 열지않고 직렬 콘솔로 해결하였다.

보통 서버에 ssh 키로 접속하여 작업을 하니까.. 명심@

 

 

---

Linux Capacities, well known 1024 이하 포트는 일반 계정으로 사용이 불가능하다.

리눅스 서버들은 루트와 일반 사용자의 권한을 철저히 분리한다. 이를 Capacity라는 시스템 하에 관리를 하는데, 보안상의 문제를 방지하기 위해서다.  CAP_NET_BIND_SERVICE 가 대표적인 예다.

 

setcap 'cap_net_bind_service=+ep' [허용을 원하는 파일명의 주소]

 

이러한 특권은 리눅스에서 다양한 경우의 수를 따져 만든 보안 이슈일 것이다.

따라서 유의해서 사용해야 한다. 

 

이러한 Linux Capacities 관련해서는 따로 깊게 공부를 할 필요가 있다고 느꼈다.

 

---

리눅스/네트워크 정보 관련 다양한 명령어

netstat

network statistic는 네트워크 연결, 라우팅 테이블, 포트 정보 등등 다양한 네트워크 관련 정보를 보여준다.

 

이 명령어는 사용하기 어렵지 않지만, 도커처럼 사용 옵션을 파악하는 것이 중요하다.

 

주요 옵션

옵션	설명
-a	--all과 같다. LISTEN, NOT LISTEN 소켓정보 모두 보여준다.
-n	--numeric과 같다. 10진수의 수치 정보로 결과를 출력한다.
-r	--route와 같다. 설정된 라우팅 정보를 출력한다.
-l	--listening과 같다. listen되고 있는 정보를 출력한다. netstat -anp | grep LISTEN 이런식으로 직접 listen 패턴을 지정할 수도 있다.

 

 

lsof

List Open Files는 현재 열려있는 파일을 보여주는 명령어다. 이때 단순한 디스크 파일이 아니라 소켓, 파이프, 디바이스 등등 다양한 종류의 파일의 정보를 확인한다.

 

# 443 포트에 연결된 프로세스 넘버 확인
# -i 옵션은 대소문자 구별을 하지않는 값이다.
lsof -i :443

# TCP 연결 확인
lsof -i TCP

# 특정 프로세스에 의해 열린 파일
lsof -p ${PID}

# 지정 디렉토리와 하위 파일들 
lsof +D /home/cobinding