NAS 또는 홈 서버에서 홈랩용 Docker 사용 방법

Docker는 각 서비스, 포트, 네트워크, 영구 데이터 경로를 배포 전에 정의하여 홈랩을 반복 가능한 애플리케이션 플랫폼으로 사용할 수 있게 합니다.

NAS나 홈 서버에서는 DNS 필터링, 모니터링, 미디어, 파일 동기화, 대시보드 및 기타 셀프 호스팅 앱을 호스트에 직접 모든 종속성을 설치하지 않고 실행할 수 있습니다. 실용적인 목표는 단순히 컨테이너를 한 번 시작하는 것이 아니라, 재부팅을 견디고, 업데이트 중에도 데이터를 유지하며, 의도한 곳에서만 접근 가능하고, 문제가 생겼을 때 복원할 수 있는 스택을 구축하는 것입니다.

홈랩에서 Docker가 하는 일

Docker는 애플리케이션과 런타임 종속성을 이미지로 패키징한 후, 그 이미지를 컨테이너로 시작합니다. 호스트는 여전히 CPU, 메모리, 저장소, 네트워크를 제공하지만, 각 서비스는 수동 설치 단계보다 재현하기 쉬운 정의된 환경을 갖게 됩니다.

다섯 가지 개념이 홈랩에서 사용할 대부분의 Docker 구성을 설명합니다:

컨테이너는 교체 가능한 것으로 간주해야 합니다. 서비스 복구에 필요한 부분은 Compose 파일, 환경 설정, 그리고 영구 데이터입니다.

Docker 설치 전에 필요한 것

먼저 Docker가 어디서 실행될지 결정하세요. NAS 운영 체제는 시각적 앱 관리자를 제공할 수 있고, 일반 Linux 홈 서버는 보통 명령줄에서 Docker 엔진과 Compose 플러그인을 사용합니다. 가상 머신도 기본 하이퍼바이저와 분리된 Docker를 원할 때 사용할 수 있습니다.

• 호스트가 amd64인지 arm64인지 확인하여 호환되는 이미지를 선택하세요.
• DHCP 예약이나 고정 IP를 통해 안정적인 LAN 주소를 확보하세요.
• 컨테이너 구성과 데이터베이스를 위한 영구 위치를 하나 만들고, 대용량 미디어 공유와는 분리하세요.
• 문서화되지 않은 방법을 혼합하지 말고 Compose 프로젝트나 시각적 관리자를 기본 워크플로우로 선택하세요.
• 어떤 서비스가 LAN 전용으로 남을지, 어떤 서비스가 나중에 원격 접근이 필요할지 결정하세요.
• Compose 파일과 영구 데이터를 백업할 두 번째 저장소 위치를 선택하세요.

호스트 자체가 아직 계획 중이라면 자신만의 홈 서버 구축 및 설정 방법 가이드가 Docker 추가 전에 저장소, 네트워크, 운영 체제 기반을 마련하는 데 도움이 될 수 있습니다.

Docker 설치 및 호스트 검증

설치 방법은 운영 체제에 따라 다르지만 검증 순서는 일관되어야 합니다. 일부 NAS 플랫폼은 앱 인터페이스 뒤에 Docker를 번들로 제공합니다. 리눅스 호스트는 보통 Docker 엔진과 Compose 플러그인이 필요하며, 윈도우와 macOS는 영구 NAS 서비스보다는 학습이나 테스트에 더 적합합니다.

초보자 친화적인 Docker 홈랩 설정은 Docker 설치, 첫 컨테이너 실행, 프로젝트 폴더 구성, 반복 가능한 서비스를 Compose로 이동하는 유용한 순서를 보여줍니다. 이 순서를 프레임워크로 사용하고, 자신의 NAS나 리눅스 배포판에 맞는 설치 방법을 따르세요.

Docker 및 Compose 확인

설치 후 호스트에서 터미널을 열고 Docker와 Compose가 모두 응답하는지 확인하세요:

docker --version
docker compose version

명령어 중 하나라도 없으면 여기서 중지하고 설치를 수정한 후 애플리케이션 폴더를 만드세요. 리눅스에서는 Docker 서비스가 자동으로 시작되는지, 관리에 사용하는 계정이 보호되는지도 확인하세요. Docker 데몬에 대한 접근은 사실상 호스트에 대한 관리자 권한입니다.

일회용 검증 컨테이너 실행

임시 컨테이너를 사용하여 데몬이 이미지를 다운로드하고 시작할 수 있는지 확인하세요:

docker run --rm hello-world

성공적인 결과는 명령줄 클라이언트에서 Docker 데몬과 이미지 레지스트리까지의 기본 경로가 정상임을 확인합니다. --rm 옵션은 테스트 컨테이너가 종료된 후 삭제되어 영구 스택의 일부가 되지 않도록 합니다.

기본 관리자 명령어 확인

docker ps
docker ps -a
docker images

docker ps 실행 중인 컨테이너를 보여줍니다, docker ps -a 중지된 컨테이너도 포함하며, docker images 호스트에 저장된 이미지를 보여줍니다. 이 세 가지 뷰만으로도 컨테이너가 중지되었는지, 이미지가 다운로드되지 않았는지, 서비스가 생성되지 않았는지 문제의 원인을 파악하는 데 충분한 경우가 많습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

첫 번째 Docker Compose 스택 배포하기

일회성 docker run 명령어는 테스트에 유용하지만 Compose가 반복, 검토, 백업 및 마이그레이션에 더 쉽습니다. 각 프로젝트는 자체 디렉터리와 compose.yaml 이미지, 포트, 저장소, 재시작 동작 및 네트워크를 기록하는 파일.

프로젝트 디렉터리 생성

다음 예시는 간단한 Nginx 시작 페이지를 만듭니다. 의도적으로 단순하지만 대시보드, 미디어 서버, 모니터링 도구 또는 개인 클라우드에 사용할 워크플로우를 테스트합니다:

mkdir -p ~/docker/start-page/site
cd ~/docker/start-page
printf '<h1>Docker homelab is running</h1>\n' > site/index.html

각 서비스를 별도의 폴더에 보관하면 Compose 파일, 환경 값 및 영구 데이터를 식별하기 쉽습니다. 더 큰 NAS는 다음과 같은 경로를 사용할 수 있습니다. /docker/start-page 홈 디렉터리 대신 전용 공유 폴더를 사용하세요.

Compose 파일 생성

파일 생성 이름 compose.yaml 프로젝트 디렉터리 내에서:

서비스:
  start-page:
    이미지: nginx:alpine
    컨테이너 이름: homelab-start-page
    포트:
      - "8080:80"
    볼륨:
      - ./site:/usr/share/nginx/html:ro
    재시작: unless-stopped
    네트워크:
      - homelab

네트워크:
homelab:
드라이버: bridge

포트 매핑은 포트에서 요청을 보냅니다 8080 NAS에서 포트로 80 컨테이너 내부. 바인드 마운트는 로컬 사이트 Nginx 내에서 읽기 전용 콘텐츠로 사용할 수 있는 디렉터리입니다. 재시작 정책은 의도적으로 중지하지 않는 한 정상 재부팅 후 서비스를 다시 시작합니다.

이 예시는 호스트의 8080 포트를 공개합니다. 테스트 중에는 라우터 포트 포워딩을 비활성화 상태로 유지하세요. 서비스가 Docker 호스트 자체에서만 접근 가능해야 할 때는 loopback에 바인딩하세요. 127.0.0.1:8080:80 대신에.

서비스 시작 및 확인

docker compose up -d
docker compose ps
docker compose 로그 --tail=100

열기 http://NAS-IP:8080 같은 네트워크에 있는 장치에서. 페이지에 “Docker homelab is running.”이 표시되어야 합니다. 그런 다음 호스트를 한 번 재부팅하고 컨테이너가 자동으로 다시 시작되는지 확인하세요.

가장 자주 사용할 명령어는 다음과 같습니다:

추가하지 마세요 -v 까지 docker compose down Compose가 관리하는 볼륨을 의도적으로 제거하려는 경우가 아니면. 컨테이너 제거는 일상적이지만, 영구 데이터를 제거하는 것은 아닙니다.

NAS 운영 체제가 시각적 Docker 앱 관리자를 제공하는 경우에도 동일한 필드가 중요합니다. 인터페이스는 이미지, 호스트 포트, 컨테이너 포트, 마운트된 경로, 환경 변수 및 재시작 동작을 보여줘야 합니다. GUI를 선호하지만 예측 가능한 앱 경로를 원할 때 이 NAS 운영 체제 워크플로우가 유용합니다.

NAS에 Docker 데이터를 안전하게 저장하세요

컨테이너는 일회용이지만 서비스 데이터는 그렇지 않습니다. 업데이트 후 대부분의 홈랩 실패는 컨테이너 레이어 내부에만 저장된 데이터베이스, 계정 파일 또는 애플리케이션 구성에서 발생합니다. 해당 컨테이너를 재생성하면 원래 서비스를 복원하는 대신 깨끗한 설치가 이루어집니다.

바인드 마운트는 알려진 호스트 파일 또는 디렉터리를 컨테이너에 매핑합니다. 볼륨은 Docker가 자체 저장 영역에서 관리합니다. 둘 다 데이터를 보존할 수 있지만 가시성과 백업 작업 흐름에서 차이가 있습니다.

애플리케이션 데이터를 대용량 미디어와 분리

구성, 데이터베이스, 썸네일, 인덱스 및 기타 소형 파일 작업은 전용 docker-data 자주 백업되는 위치. 대용량 영화, 사진, 녹음 및 다운로드는 일반 미디어 공유에 보관할 수 있습니다. 이 분리는 백업 범위를 명확하게 하고 애플리케이션 메타데이터가 대용량 순차 저장 작업과 경쟁하는 것을 방지할 수 있습니다.

실제 애플리케이션을 배포하기 전에 Compose 파일에서 사용된 모든 호스트 경로를 기록하세요. 간단한 레이아웃은 다음과 같을 수 있습니다:

/docker
  /app-name
    compose.yaml
    .env
    /config
    /data

서비스를 재생성하는 항목 백업

Compose 파일과 모든 .env 파일, 인증서, 사용자 지정 구성 및 지속적인 컨테이너 데이터. 이미지는 다시 다운로드할 수 있으므로 일반적으로 백업할 필요가 없습니다. 비밀번호, 토큰 또는 데이터베이스 자격 증명이 포함될 수 있으므로 환경 파일을 신중하게 보호하세요.

3-2-1 백업 규칙은 유용한 계획 모델을 제공하지만, Docker 백업은 스택을 재생성하고 데이터를 복원할 수 있을 때만 완전합니다. 홈랩이 서비스에 의존하기 전에 비중요 복원 테스트를 해보세요.

시각적 NAS 인터페이스를 사용할 때, 인터페이스가 자동으로 보호한다고 가정하지 말고 지속적인 컨테이너 데이터가 어디에 저장되는지 확인하세요.

홈랩에서 Docker 네트워킹 작동 방식

Docker 네트워킹은 두 가지 경로를 제어합니다: 컨테이너 간 통신과 Docker 외부 장치의 접근. 이 경로를 분리하면 불필요한 포트 공개를 줄이고 다중 서비스 스택을 이해하기 쉽게 만듭니다.

포트 매핑은 왼쪽에서 오른쪽으로 읽으세요

에서 8080:80, 포트 8080은 Docker 호스트에 속하고 포트 80은 컨테이너에 속합니다. LAN 내 장치들은 NAS 주소와 호스트 포트에 연결합니다. Docker는 요청을 애플리케이션 내부 포트로 전달합니다.

브라우저, 휴대폰, TV 또는 다른 비-Docker 장치가 직접 접근해야 할 때만 호스트 포트를 공개하세요. 다른 컨테이너만 사용하는 데이터베이스는 보통 포트를 공개할 필요가 없습니다.

관련 서비스에 맞춤 네트워크 사용하기

Compose는 각 스택에 대해 사용자 정의 브리지 네트워크를 생성할 수 있습니다. 해당 네트워크에 있는 컨테이너들은 서비스 이름으로 서로 접근할 수 있어 웹 애플리케이션이 데이터베이스 변하는 컨테이너 IP 주소에 의존하지 않고.

맞춤 Docker 네트워크와 컨테이너 격리에 대한 실습 예시는 컨테이너가 별도의 브리지 네트워크에 배치되거나 둘 이상의 네트워크에 연결될 때 이름 해석과 연결성이 어떻게 변하는지 보여줍니다.

실제로 통신이 필요한 서비스끼리 그룹화하세요. 관련 없는 스택은 별도의 네트워크에 두고, 컨테이너들이 서로 보도록 내부 데이터베이스, 캐시 또는 메시지 큐를 단순히 공개하지 마세요.

LAN 접근과 인터넷 접근을 분리하세요

접근 가능한 서비스 NAS-IP:8080 홈 네트워크에 있는 서비스는 인터넷에서 자동으로 접근할 수 없습니다. 공개 노출은 일반적으로 라우터 포워딩 규칙, 터널, VPN 또는 다른 원격 접근 경로가 필요합니다. 이 추가 단계를 모든 배포의 일부가 아닌 별도의 보안 결정으로 취급하세요.

Docker 서비스를 안전하게 노출하기

원격 접근은 편리한 홈랩이 실제 보안 취약점이 될 수 있는 부분입니다. 더 안전한 기본 설정은 애플리케이션 인터페이스를 LAN 내에서 비공개로 유지하고 원격 사용이 필요할 때만 제어된 접근 계층을 노출하는 것입니다.

개인 원격 접근을 위해 VPN 사용하기

개인 VPN 또는 오버레이 네트워크는 승인된 장치가 각 애플리케이션을 직접 공개하지 않고도 홈 서비스에 접근할 수 있게 해줍니다. 이는 개인 대시보드, 관리자 패널, 파일 접근 및 소수의 신뢰할 수 있는 사람들만 사용하는 서비스에 가장 간단한 경로인 경우가 많습니다. 안전한 원격 접근 방법 가이드는 VPN 기반 접근과 공개 웹 노출 사이의 홈 서버 결정에 대해 더 폭넓게 다룹니다.

리버스 프록시를 공개 진입점으로 사용하기

웹 서비스가 공개되어야 할 경우, 리버스 프록시는 호스트명, 인증서, 라우팅 규칙, 접근 제어를 한 곳에서 관리할 수 있게 해줍니다. 각 애플리케이션에 별도의 라우터 포트를 포워딩하기보다 프록시만 노출하세요. 데이터베이스, 관리자 인터페이스, 내부 서비스 포트는 가능한 한 사설 Docker 네트워크에 유지하세요.

HTTPS 및 신중한 포트 규칙 사용하기

홈 네트워크 외부에서 접근 가능한 로그인이나 세션은 반드시 HTTPS를 사용해야 합니다. 라우터 포워딩 규칙을 주기적으로 검토하고 더 이상 필요 없는 항목은 제거하세요. 인증서 자동화는 도움이 되지만 강력한 인증, 적시 업데이트, 공개 서비스에 대한 신중한 제어를 대체하지는 않습니다.

스택 업데이트, 모니터링, 복원

Docker 홈랩은 유지보수가 반복 가능한 순서를 따를 때 관리가 용이합니다. 모든 서비스를 한꺼번에 무작정 업데이트하지 마세요. 백업부터 시작해 하나의 스택을 업데이트하고 중요한 경로를 확인한 후 다음 애플리케이션으로 넘어가세요.

통제된 업데이트 순서 사용하기

cd ~/docker/start-page
docker compose pull
docker compose up -d
docker compose ps
docker compose 로그 --tail=100

중요한 서비스는 업데이트 전에 작동 중인 이미지 태그를 기록해 두어 롤백 참조로 사용하세요. 재배포 후 로그인, 마운트된 저장소, 데이터베이스 연결, LAN 접근, 리버스 프록시 경로를 테스트하세요. “Up” 상태는 프로세스가 실행 중임을 의미할 뿐 애플리케이션이 정상임을 보장하지 않습니다.

조용히 변하는 신호를 주시하세요

• 오래된 이미지, 쓰기 가능한 레이어, 로그, 버려진 데이터로 인한 시스템 드라이브 사용량
• 컨테이너 재시작 횟수 및 애플리케이션 로그의 반복 오류
• 예상치 못한 라우터 포워딩 또는 더 이상 필요하지 않은 호스트 포트
• 백업의 나이, 백업 크기, 최신 아카이브가 열리는지 여부
• 작은 NAS에 추가 서비스가 늘어날 때 발생하는 메모리 압박

정리 명령어는 삭제할 항목을 검토한 후에만 사용하세요. 사용하지 않는 이미지는 공간을 차지하지만, 과도한 정리는 복구 계획에 필요한 캐시된 레이어나 사용하지 않는 볼륨까지 삭제할 수 있습니다.

복원 연습하기

중요하지 않은 서비스를 선택하여 중지하고, 해당 서비스의 지속 데이터는 따로 옮긴 후 Compose 파일에서 다시 빌드하세요. 그런 다음 데이터를 복원하고 계정, 설정, 애플리케이션 상태가 정상으로 돌아오는지 확인하세요. 성공적인 복원은 백업 작업이 정상 완료되었다는 것보다 더 확실한 증거입니다.

일반적인 Docker 홈랩 문제 및 해결책

홈랩에 적합한 다음 컨테이너 선택

첫 번째 Compose 스택이 재부팅과 소규모 업데이트를 견뎌낸 후, 실제 가정의 필요를 해결하는 서비스를 하나 추가하세요. 각 카테고리는 다른 운영 교훈을 소개합니다:

가정 내 모든 사용자가 하나의 네트워크 서비스를 이용할 때는 DNS 수준 필터가 유용합니다. 저장 워크플로우의 경우, 개인 파일 동기화는 구성과 데이터베이스가 일회용 컨테이너 계층 밖에 있어야 하는 이유를 보여줍니다. Plex 미디어 서버는 미디어 권한, 메타데이터 배치, 그리고 가능한 트랜스코딩 요구 사항을 추가합니다.

여러 중요한 서비스를 한꺼번에 추가하지 마세요. 문서화된 경로, 제한된 노출, 테스트된 백업이 있는 작은 스택이 아무도 신뢰할 수 없게 재구성할 수 있는 복잡한 대시보드보다 더 유용합니다.

자주 묻는 질문(FAQs)

ARM 기반 NAS에서 Docker를 사용할 수 있나요?

대부분 그렇습니다. 이미지는 NAS 아키텍처용 빌드를 제공해야 합니다. 특히 amd64는 지원하지만 arm64는 지원하지 않는 소규모 프로젝트의 경우 배포 전에 이미지가 제공하는 플랫폼을 확인하세요. 아키텍처 불일치는 Compose 파일이 올바르더라도 컨테이너가 시작되지 못하게 할 수 있습니다.

Docker 홈랩에 필요한 RAM은 얼마나 되나요?

보편적인 숫자는 없습니다. DNS 필터, 미디어 서버, 데이터베이스, AI 서비스는 메모리 사용량이 매우 다릅니다. 실행할 서비스를 목록화하고, 작은 스택으로 시작해 며칠간 최대 사용량을 측정하며, 운영체제, 파일시스템 캐시, 업데이트, 일시적 급증을 위한 여유 공간을 확보하세요.

NAS에 GUI가 있으면 Docker Compose가 필요한가요?

아니요. 잘 설계된 GUI는 모든 경로, 포트, 변수, 재시작 설정을 노출할 때 간단한 홈랩을 관리할 수 있습니다. Compose는 버전 관리된 구성, 쉬운 마이그레이션, 반복 가능한 복구, 또는 여러 관련 서비스를 하나의 스택으로 운영할 때 더 가치가 있습니다.

모든 컨테이너가 자체 네트워크를 가져야 하나요?

반드시 그런 것은 아닙니다. 각 개별 컨테이너에 네트워크를 할당하기보다는 애플리케이션 경계에 따라 네트워크를 만드세요. 웹 앱과 데이터베이스는 하나의 사설 네트워크를 공유할 수 있고, 관련 없는 미디어 서버는 다른 네트워크를 사용할 수 있습니다. 비-Docker 장치가 필요로 하는 포트만 공개하세요.

Docker 서비스를 원격으로 안전하게 접근하는 방법은 무엇인가요?

개인용 접근을 위해 집에서 운영하는 개인 VPN은 여러 애플리케이션 포트를 공개할 필요를 줄여줍니다. 공개 서비스는 보통 리버스 프록시, HTTPS, 강력한 인증, 적시 업데이트, 그리고 무엇을 비공개로 유지할지에 대한 신중한 결정이 필요합니다.

Docker 백업이 완전한지 어떻게 알 수 있나요?

Compose 파일에서 컨테이너를 재생성하고 저장된 영구 데이터를 통해 애플리케이션 상태를 복원할 수 있어야 합니다. 이미지나 Compose 파일만 있고 데이터베이스와 구성 디렉터리가 없는 백업은 대부분의 상태 저장 서비스에 충분하지 않습니다.

재현 가능한 홈랩 구축하기

홈랩에서 Docker를 배우는 것은 컨테이너를 모으는 것보다 각 서비스를 반복 가능하게 만드는 데 더 중점을 둡니다. 먼저 Docker를 검증하고, 애플리케이션당 하나의 Compose 프로젝트를 유지하며, 상태는 컨테이너 외부에 저장하고, 필요한 포트만 공개하며, 서비스가 중요해지기 전에 복구를 테스트하세요.

첫 번째 스택이 재부팅, 업데이트, 복구 훈련을 무사히 통과하면 같은 원칙으로 다음 애플리케이션을 추가하세요. 이 순서가 NAS를 단순히 컨테이너가 실행되는 장소에서 이해하고 유지하며 재구성할 수 있는 홈 서버로 바꿉니다.