이해코딩

GPT 선생님께서 제시해준 단계는 아래와 같다.

1. 목적 정의

  먼저 홈 서버를 사용하려는 목적을 명확히 해야 합니다.

• 파일 공유 및 저장 (NAS)
• 웹 서버 호스팅 (개인 블로그, 포트폴리오)
• 미디어 서버 (예: Plex, Jellyfin)
• 개발 및 테스트 환경
• 홈 자동화 시스템 (예: Home Assistant)

2. 하드웨어 선택

  서버 하드웨어는 용도와 예산에 따라 달라집니다.

• 저가형 옵션: 라즈베리 파이, 미니 PC
• 고성능 옵션: 기존 PC 재활용, 서버 전용 장비 (예: HP MicroServer)
• 고려사항: CPU 성능, RAM 크기, 저장 공간, 전력 소모

3. 운영체제 선택

  서버 용도에 따라 적합한 OS를 선택하세요.

• NAS: TrueNAS, OpenMediaVault
• 일반 서버: Ubuntu Server, CentOS, Debian
• 멀티미디어: LibreELEC, Plex
• 가상화 및 컨테이너: Proxmox VE, Docker

4. 네트워크 구성

  홈 서버는 네트워크 환경이 중요합니다.

• 고정 IP 주소: 로컬 네트워크에서 서버를 안정적으로 접근
• 포트 포워딩: 외부에서 접근하려면 라우터 설정 필요
• 도메인 이름: 고유한 URL 사용 (예: DDNS 서비스 활용)

5. 소프트웨어 설치

  서버의 용도에 따라 적합한 소프트웨어를 설치합니다.

• 웹 서버: Apache, Nginx
• DB 서버: MySQL, PostgreSQL
• 컨테이너 관리: Docker, Kubernetes
• 기타 앱: Nextcloud, Jellyfin, GitLab

6. 보안 강화

  홈 서버는 보안이 특히 중요합니다.

• SSH 설정: 비밀번호 대신 키 인증 사용
• 방화벽 설정: UFW, iptables
• 자동 업데이트: 소프트웨어 최신 유지
• 백업 계획: 정기적으로 데이터 백업

7. 모니터링 및 유지보수

• 서버 상태 모니터링 도구 사용 (예: Netdata, Grafana)
• 필요 시 하드웨어 업그레이드

나의 계획

1. 목적 정의

DB를 사용하는 웹 서버 호스팅

2. 하드웨어 선택

가정용 저사양 노트북. 자세한  사양은 아래와 같다.

(나중에 집에 도착하면 추가하겠습니다)

3. 운영체제 선택

Linux Ubuntu OS를 사용, 작업 공간은 Docker로 구축

4. 네트워크 구성

가정용 라우터를 포트 포워딩 하여 서버로 사용. 도메인은 아직 계획에 없음.

5. 소프트웨어 설치

Nginx(리버스 프록시를 위한 서버), Spring boot(실제 웹 서버), MySQL(DB), Jenkins(미정)

6. 보안 강화

우선 서버 구축 성공 후에 고려

7. 모니터링 및 유지보수

Netdata로 모니터링, 서버 컴퓨터는 교체될 수도 있음.

최종 정리

  서버 구축

1. 서버에 사용할 기기 선정
2. 노트북 포맷 후 Linux Ubuntu OS 설치
3. Linux OS 커널 기반 Docker 설치
4. Docker에서 Nginx 이미지, Spring boot 이미지, MySQL 이미지를 통해 각각 컨테이너 생성 후 실행
5. Spring boot 서버와 MySQL 서버 연동
6. Nginx 서버와 Spring boot 서버 연동
7. 서버와 연결된 통신 장비^[각주:1] 포트 포워딩

  서버 업데이트

1. Docker에서 서로 연동된 Nginx 서버, Spring boot 서버, MySQL 서버 실행
2. 서버 파일에 변경해야 할 사항 발생 시 (ex, spring boot 코드 변경 또는 실행 파일 추가)
3. 외부 작업용 컴퓨터에서 spring boot 프로젝트 컴파일 및 빌드하여 jar 파일 생성
4. 생성된 jar 파일을 서버로 전송
5. 서버 파일 Update
6. 변경된 서버 재실행

마무리

조사 중에 서버 업데이트 단계의 jar 파일 생성 => 서버로 전송 => 서버 파일 Update => 서버 재실행을 간편화 해주는 Jenkins라는 서비스가 있다는 걸 알았다. 상당히 유용한 서비스인 것 같아 다음번에 별도로 다뤄볼 것이다.

 서버를 공부하려면 절대 빼놓을 수 없는 개념인 포트 포워딩에 대한 내용을 정리해봤다. 정말 중요한 개념이니 부정확하거나 모호한 내용이 있다면 계속 수정해서 100% 익힐 것이다.

포트 포워딩이 필요한 이유

  기존에 스프링 부트나 MySQL을 통해 실행하던 서버는 모두 내부 네트워크에서 사설 IP 주소^[각주:1]를 사용하므로 외부에서 접근할 수 없다. 외부에서 접근하려면, 공인 IP 주소를 통해 특정 포트로 들어오는 요청을 내부 네트워크의 특정 장치^[각주:2]의 특정 애플리케이션으로 전달해야 한다. 이를 위해 필요한 작업이 포트 포워딩이다. 포트 포워딩은 외부의 공인 IP 주소와 포트 번호로 들어오는 트래픽을 내부 네트워크의 특정 장치나 서비스가 사용하는 사설 IP 주소와 포트로 전달하는 방식이다.

내부 네트워크와 외부 네트워크의 차이

 어릴 때 하마치를 통해 친구들과 LAN으로 마인크래프트를 즐긴 경험이 있는가? LAN은 근거리 통신망이란 뜻으로 이것도 내부 네트워크의 한 종류다. 내부 네트워크는 같은 통신장비[footnote]ex) 공유기, 라우터[footnote]를 통해 이어진 내부 통신망으로 원래는 외부 인터넷과 연결할 수 없다. 하지만 하마치는 VPN과 중계 서버를 통해 사용자들이 가상의 사설 네트워크를 사용하는 것처럼 이어준다. 그래서 가상의 사설 IP 주소를 입력해서 친구의 사설 서버에 접속할 수 있었던 것이다. 이처럼 인터넷과 격리되어 그룹 내에서 사설 IP 주소를 통해 내부에서만 통신하는 네트워크를 내부 네트워크라고 부른다. 외부 네트워크는 이와 반대로 공인 IP를 통해 외부와 통신이 가능한 네트워크다.

NAT에 대해

 NAT(Network Address Translation)는 하나의 공인 IP 주소를 사용하여 여러 개의 사설 IP 주소로 트래픽을 전달할 수 있게 해주는 기술이다. 인터넷에 접속하는 각 장치가 공인 IP를 필요로 하지 않고, 통신 장비의 공인 IP 하나로 모든 사설 네트워크 장치의 통신을 중계한다. 그러므로 외부에서 특정 사설 IP로 트래픽을 보내려면 어느 사설 IP로 전달할지 알아야 하므로 이때 포트 포워딩이 필요하다.

 이해를 돕기 위해 NAT 기술과 포트 포워딩을 사용하는 상황을 예로 들어보자. 서버 컴퓨터 A의 사설 IP는 '123.456.7.890', 서버 컴퓨터가 연결된 라우터의 공인 IP는 '111.111.1.111'이며 수많은 서버 컴퓨터가 이 라우터에 연결되어 있다고 가정해보겠다. 그럼 외부에서 '111.111.1.111'로 어떤 요청을 보낸다면, 이게 무슨 서버로 보낸 요청인지 라우터는 알 방법이 없다. 그러므로 "1234 포트로 요청이 오면, 서버 컴퓨터 A의 4321 포트로 전송한다."라는 약속을 미리 정해둔 다음, '111.111.1.111:1234'로 어떤 요청이 왔을 때 미리 약속한 서버 컴퓨터 A의 4321 포트에 요청을 보내는 것이다. 이때 마찬가지로 요청을 받은 서버 컴퓨터 A도 미리 "4321 포트로 요청이 오면, MySQL 애플리케이션으로 전송한다."와 같은 약속을 정해놓고 약속대로 전송한다. 

 참고로 이때, 서버 컴퓨터 A가 "4321 포트로 요청이 오면 특정 애플리케이션으로 전송한다."와 같이 특정 애플리케이션이 요청을 처리하도록 한 것은 포트 포워딩이 아니라 포트 바인딩(Binding)이라는 별개의 표현을 사용한다.

 결과적으로, 외부에서 온 요청을 서버에서 처리하는 순서는 아래와 같다고 볼 수 있다.

외부에서 공인 IP 주소와 포트를 통한 요청 전송 => 미리 약속한 사설 IP 주소와 포트에 요청 전달 => 미리 약속한 애플리케이션에 요청 전달 => 애플리케이션에서 요청 처리 => 요청을 전송한 출발지로 처리 결과를 전송

포트 포워딩을 더 잘 이해하기 위해 필요한 개념인 방화벽, 포트 구분, DMZ, DNS 등은 다음번에 다루도록 하자.

Docker에 대해 본격적으로 공부하기 전, 이론적 배경지식을 단단히 하기 위해 조사해보았다.

Docker의 개념

Docker는 애플리케이션을 컨테이너(Container)라는 가볍고 이식 가능한 환경에 패키징, 배포, 실행할 수 있는 오픈 소스 플랫폼이다. 컨테이너는 운영 체제(OS)의 가상화를 이용해 애플리케이션이 어디에서나 동일하게 실행될 수 있도록 환경을 격리한다.

Docker의 네 가지의 구성 요소

• 컨테이너(Container)
• 이미지(Image)
• 도커 엔진(Docker Engine)
• Docker Hub

컨테이너(Container)

   이미지를 통해 만들어진 독립된 작업 환경.

컨테이너는 커널까진 OS와 공유한다. 가상 머신과 달리 OS를 완전히 새로 돌리는 것이 아니므로 상대적으로 가볍고 빠르다. 그래서 동일 커널을 사용하는 환경이라면 어떤 컴퓨터에서도 동작한다고 기대할 수 있다. 

이미지(Image)

   컨테이너에 필요한 정보를 저장하는 읽기 전용 템플릿.

컨테이너를 생성, 실행하기 위한 모든 필요한 정보^[각주:1]가 담겨 있다. 컨테이너는 이 이미지를 통하여 생성된다. 컨테이너는 이미지의 복사본이라고 볼 수 있는 셈이다. 

도커 엔진(Docker Engine)

   Docker 컨테이너를 실행하고 관리하는 데 필요한 모든 작업을 처리하는 실행 환경. 

   Docker Daemon

   Docker의 중앙 처리 장치.

사실상 도커 엔진 그 자체라고 볼 수 있다. Docker 이미지를 만들고, 컨테이너를 생성하고, 실행하며, 관리한다. 또한 레지스트리와 소통하며 업로드하고 다운로드하는 등 외부와 소통할 수 있다.

   Docker API

   Docker Daemon과 소통을 주고 받기 위한 API

Docker Daemon은 외부뿐만 아니라 로컬 환경의 Docker CLI와 소통할 때도 이걸 사용한다. 아마 확장성과 독립성을 확보하기 위함인 것 같다. 명령을 전달 받을 때, 전달할 때 둘 다 동일하게 Docker API를 사용한다.

   Docker CLI

   단순히 사용자가 Docker Daemon에 명령을 전달하는 명령창이다.

도커 허브(Docker Hub)

   Docker의 Github

Github이 소스 코드와 파일을 저장했다면, Docker Hub은 Docker 이미지를 저장한다.