13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Docker

  • [Nas] Synology NAS Docker 활용: 앱 설치 및 관리 완벽 가이드

    [Nas] Synology NAS Docker 활용: 앱 설치 및 관리 완벽 가이드

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 많은 분들이 홈랩(Homelab)에서 필수적으로 활용하고 계시는 Synology NAS의 Docker 활용법에 대해 이야기해보려고 해요.

    솔직히 처음엔 저도 NAS에 Docker를 왜 써야 하나 싶었습니다. 그냥 패키지 센터에서 앱 깔면 되지 않나? 하는 생각이었죠. 그런데 막상 제가 직접 몇 가지 서비스를 올려보고 관리해보니, Docker(도커)만큼 편하고 강력한 도구가 없더라고요. 특히 Synology NAS는 훌륭한 하드웨어와 DSM(DiskStation Manager)이라는 직관적인 운영체제를 제공해서, 여기에 Docker를 얹으면 그 시너지가 정말 대단합니다. 제가 홈랩에서 이것저것 실험하면서 겪었던 삽질 경험과 해결 과정을 솔직하게 공유해볼게요. 이 글을 통해 여러분도 Synology NAS의 잠재력을 100% 끌어내셨으면 좋겠어요! 🎉

    Synology NAS가 홈 네트워크의 여러 Docker 서비스를 구동하는 모습을 시각화한 다이어그램입니다.

    Docker, 컨테이너가 뭐길래 그렇게 좋다고 할까요?

    본격적인 실전 가이드에 앞서, Docker(도커)와 컨테이너(Container) 개념을 잠깐 짚고 넘어가야겠죠? 쉽게 말해, Docker는 애플리케이션을 실행하는 데 필요한 모든 것(코드, 런타임, 시스템 도구, 라이브러리 등)을 컨테이너(Container)라는 독립적인 패키지로 묶어주는 기술입니다. 이 컨테이너는 어떤 환경에서든 동일하게 작동하도록 보장해주죠.

    기존에는 하나의 서버에 여러 앱을 설치하면, 서로 다른 앱 버전이나 라이브러리 충돌 때문에 골치 아픈 경우가 많았어요. 윈도우에서 프로그램 깔다가 “어? 이 버전은 안 맞는데?” 하는 경험 다들 있으실 겁니다. 😅 가상 머신(VM)도 좋은 대안이지만, OS를 통째로 가상화하다 보니 무겁고 자원 소모가 컸거든요.

    근데 Docker 컨테이너는 호스트 OS의 커널을 공유하면서도, 각각의 앱이 마치 독립적인 OS에서 실행되는 것처럼 격리된 환경을 제공합니다. 💡 그래서 가상 머신보다 훨씬 가볍고(Lightweight) 빠르며(Fast), 효율적(Efficient)이더라고요. Synology NAS 같은 한정된 자원의 장비에서 여러 서비스를 안정적으로 운영하고 싶다면, Docker는 거의 필수라고 할 수 있습니다.

    Synology NAS에 Docker 설치하기: 시작이 반이죠!

    Synology NAS에 Docker를 설치하는 건 정말 간단합니다. DSM(DiskStation Manager)의 패키지 센터(Package Center)를 이용하면 되거든요. 제가 처음 Synology NAS를 접했을 때, 이 패키지 센터의 편리함에 정말 놀랐던 기억이 나네요.

    1. DSM에 관리자 계정으로 로그인합니다.
    2. 패키지 센터를 엽니다.
    3. 검색창에 “Docker”를 입력하거나, “유틸리티” 카테고리에서 Docker 패키지를 찾습니다.
    4. 설치 버튼을 클릭합니다.
    5. 설치 과정이 완료되면, 메인 메뉴에 Docker(컨테이너 관리자) 아이콘이 생성된 것을 확인할 수 있습니다.

    참 쉽죠? 이렇게 설치를 마치면, 이제 웹 UI를 통해 Docker 컨테이너를 관리할 준비가 된 겁니다. Synology는 이 Docker 관리 UI를 컨테이너 관리자(Container Manager)라고 부르더라고요. 처음엔 좀 헷갈렸는데, 그냥 Docker GUI라고 생각하시면 편해요.

    Synology DSM의 컨테이너 관리자 화면입니다. 실행 중인 컨테이너들의 상태를 한눈에 볼 수 있습니다.

    실전! Docker 컨테이너 배포 및 관리 노하우

    이제 본격적으로 Docker 컨테이너를 배포하고 관리하는 방법을 알아볼까요? 저는 주로 두 가지 방법으로 컨테이너를 관리하는데요, 하나는 Synology의 컨테이너 관리자(Container Manager) UI를 이용하는 것이고, 다른 하나는 Docker Compose(도커 컴포즈)를 활용하는 방법입니다. 제가 직접 써보니, 간단한 앱은 UI로, 여러 앱을 묶어서 관리할 때는 Compose가 훨씬 편하더라고요.

    1. 컨테이너 관리자 UI로 Synology Docker 앱 설치하기 (Nginx 예시)

    Synology의 컨테이너 관리자는 마치 앱스토어처럼 이미지를 검색하고 컨테이너를 생성할 수 있게 해줍니다. Nginx(엔진엑스) 웹 서버를 예시로 들어볼게요.

    1. 컨테이너 관리자를 실행합니다.
    2. 왼쪽 메뉴에서 레지스트리(Registry)를 클릭합니다.
    3. 검색창에 “nginx”를 입력하고 검색합니다. 공식 Nginx 이미지를 선택하고 다운로드(Download) 버튼을 클릭합니다. 태그(Tag)는 latest를 선택하면 돼요.
    4. 이미지 다운로드가 완료되면, 왼쪽 메뉴의 이미지(Image) 탭으로 이동합니다. 방금 다운로드한 nginx:latest 이미지를 선택하고 실행(Run) 버튼을 클릭합니다.
    5. 컨테이너 생성 마법사가 나타납니다.
      • 일반 설정(General Settings): 컨테이너 이름(예: my-nginx)을 입력하고, 자동으로 다시 시작(Enable auto-restart)을 체크해두는 게 좋습니다.
      • 포트 설정(Port Settings): Nginx는 기본적으로 80번 포트를 사용합니다. 호스트 포트(Local Port)를 비워두면 자동으로 할당되지만, 특정 포트(예: 8080)로 지정해서 사용하고 싶으면 입력하면 돼요. 저는 보통 8080으로 매핑해서 사용합니다.
      • 볼륨 설정(Volume Settings): Nginx 설정 파일이나 웹 페이지 파일을 외부 폴더와 연결(마운트)할 수 있습니다. 예를 들어, Synology NAS의 /docker/nginx/html 폴더를 컨테이너 내부의 /usr/share/nginx/html 경로에 마운트하면, NAS 폴더에 웹 페이지를 넣으면 바로 Nginx를 통해 서비스할 수 있어요. 💡 주의! NAS 폴더에 권한이 없으면 Nginx가 시작되지 않거나 파일을 읽지 못할 수 있으니, 읽기/쓰기(Read/Write) 권한을 꼭 확인해주세요.
    6. 설정 완료 후 적용(Apply) 버튼을 누르면 컨테이너가 생성되고 바로 실행돼요.

    이제 웹 브라우저에서 http://[NAS_IP_주소]:8080으로 접속해보세요. Nginx 기본 페이지가 보인다면 성공입니다! ✅

    2. Docker Compose로 여러 서비스 한 번에 관리하기 (Watchtower 예시)

    하나의 컨테이너는 UI로 관리하기 편하지만, 여러 컨테이너가 서로 연동되거나 복잡한 설정을 해야 할 때는 Docker Compose(도커 컴포즈)가 빛을 발합니다. YAML(야믈) 파일 하나로 여러 컨테이너의 설정과 관계를 정의할 수 있거든요. 저는 주로 Watchtower(왓치타워) 같은 유틸리티 컨테이너를 Docker Compose로 배포해서 사용합니다. Watchtower는 실행 중인 Docker 컨테이너의 새 이미지가 있는지 주기적으로 확인하고 자동으로 업데이트해주는 고마운 녀석이더라고요. 매번 수동으로 업데이트하는 삽질을 줄여줍니다!

    Synology NAS에서 Docker Compose를 사용하려면 SSH로 NAS에 접속해야 합니다. SSH 접속 방법은 제 이전 글에서 다루었으니 참고해주세요! (나중에 링크 추가 예정) ➡️

    1. SSH로 NAS에 로그인합니다.
    2. 컨테이너 설정을 저장할 폴더를 만듭니다. (예: /volume1/docker/watchtower)
    3. 해당 폴더로 이동하여 docker-compose.yml 파일을 생성하고 아래 내용을 입력합니다.
    version: '3.8'
    services:
      watchtower:
        image: containrrr/watchtower
        container_name: watchtower
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock
        environment:
          - TZ=Asia/Seoul # 시간대 설정 (선택 사항)
          - WATCHTOWER_CLEANUP=true # 이전 이미지 삭제
          - WATCHTOWER_SCHEDULE=0 4 * * * # 매일 새벽 4시에 실행 (Cron 표현식)
        restart: unless-stopped
    

    위 YAML 파일은 containrrr/watchtower 이미지를 사용하고, Docker 데몬과 통신하기 위해 /var/run/docker.sock을 마운트합니다. 또한, 매일 새벽 4시에 컨테이너를 업데이트하고 이전 이미지를 정리하도록 설정했어요. 환경 변수(Environment Variables)를 통해 다양한 옵션을 줄 수 있으니, Watchtower 공식 문서를 참고하시면 더 많은 기능을 활용할 수 있습니다.

    1. docker-compose.yml 파일이 있는 디렉토리에서 다음 명령어를 실행하여 컨테이너를 배포합니다.
    sudo docker compose up -d
    

    -d 옵션은 컨테이너를 백그라운드에서 실행하라는 뜻입니다. 명령어를 실행하면 Watchtower 컨테이너가 생성되고 바로 작업을 시작할 거예요. 나중에 컨테이너를 중지하고 싶다면 sudo docker compose down 명령어를 사용하면 됩니다.

    ⚠️ 삽질 경험 & 트러블슈팅: 이것만 알면 고생 끝!

    제가 Docker를 처음 다룰 때 가장 많이 겪었던 문제들은 바로 권한과 포트 충돌이었습니다. 독자분들은 저처럼 삽질하지 마시라고 몇 가지 팁을 드릴게요.

    • 볼륨 마운트(Volume Mount) 권한 문제: 컨테이너가 호스트(NAS)의 특정 폴더에 접근해야 할 때, 해당 폴더에 컨테이너가 접근할 수 있는 권한이 없으면 에러가 발생합니다. 예를 들어, Nginx가 웹 페이지를 읽지 못하거나, Plex가 미디어 파일을 스캔하지 못하는 경우가 대표적이죠.

      해결책: Synology DSM의 제어판 > 공유 폴더에서 해당 폴더의 권한 설정을 확인하고, everyone 그룹 또는 Docker 컨테이너가 사용하는 사용자(대부분 root 또는 특정 UID/GID)에게 읽기/쓰기 권한을 부여해야 합니다. 저는 보통 777 권한을 주기도 하는데, 보안상 좋지 않으니 필요한 최소한의 권한만 부여하는 게 좋아요.
    • 포트 충돌(Port Conflict): 이미 NAS에서 사용 중인 포트(예: DSM 웹 UI의 5000/5001번)를 Docker 컨테이너가 사용하려고 하면 충돌이 발생합니다.

      해결책: 컨테이너 생성 시 호스트 포트(Local Port)를 비어있는 다른 포트(예: 80 -> 8080, 443 -> 8443)로 변경하여 매핑해주면 됩니다. netstat -tulnp 명령어로 현재 사용 중인 포트를 확인할 수 있더라고요.
    • 이미지 다운로드 실패: 인터넷 연결 문제나 Docker Hub(도커 허브) 서버 문제로 이미지를 다운로드하지 못하는 경우가 있습니다.

      해결책: 인터넷 연결 상태를 확인하고, 잠시 기다렸다가 다시 시도하거나, 다른 미러 서버를 사용하는 방법을 찾아볼 수도 있습니다.

    이런 문제들을 겪으면서 “아, 진짜 왜 안 되는 거야!” 하고 답답했던 순간들이 많았는데, 결국은 대부분 설정 문제더라고요. 꼼꼼하게 확인하는 습관이 중요합니다. 💡

    ✅ 결과 확인 및 컨테이너 관리

    컨테이너가 제대로 실행되고 있는지 확인하는 것은 매우 중요합니다. Synology의 컨테이너 관리자 UI나 SSH 터미널에서 쉽게 확인할 수 있어요.

    1. 컨테이너 관리자 UI에서 확인: 왼쪽 메뉴의 컨테이너(Container) 탭을 클릭하면 현재 실행 중인 모든 컨테이너 목록과 상태를 한눈에 볼 수 있습니다. 각 컨테이너를 클릭하면 CPU, 메모리 사용량 등 자세한 정보를 확인할 수 있어요.
    2. SSH 터미널에서 확인: sudo docker ps 명령어를 사용하면 현재 실행 중인 컨테이너 목록을 확인할 수 있습니다. 모든 컨테이너(종료된 컨테이너 포함)를 보려면 sudo docker ps -a를 사용합니다. 특정 컨테이너의 로그를 확인하고 싶다면 sudo docker logs [컨테이너_이름_또는_ID] 명령어를 사용하면 되더라고요.

    이런 식으로 주기적으로 컨테이너 상태를 점검하고, 문제가 발생하면 로그를 확인하여 빠르게 대처하는 것이 중요합니다. 멘토인 제가 늘 강조하는 부분이죠! 😉

    Portainer 웹 UI 대시보드에서 Docker 컨테이너 및 스택 개요를 보여주는 스크린샷입니다.

    마무리하며: Synology NAS와 Docker, 무한한 가능성!

    오늘은 Synology NAS에 Docker를 설치하고 컨테이너를 배포, 관리하는 방법에 대해 자세히 알아봤습니다. 제가 직접 홈랩에서 13년 동안 다양한 장비를 만져보면서 느낀 건, Synology NAS와 Docker의 조합은 정말 강력하다는 겁니다. 여러분의 NAS를 단순한 파일 서버를 넘어, Plex 미디어 서버, Home Assistant 스마트 홈 허브, Nextcloud 개인 클라우드 등 무궁무진한 서비스의 허브로 탈바꿈시킬 수 있어요.

    물론 처음에는 생소하고 어려운 부분도 있을 겁니다. 저도 그랬거든요! 하지만 한 번 익숙해지면 이 편리함에서 헤어나오기 어렵습니다. 삽질은 성장의 어머니라고 하잖아요? 😅 여러분의 삽질을 줄여드리고자 이 글을 썼으니, 부디 도움이 되셨기를 바랍니다.

    다음 글에서는 Synology NAS에서 Reverse Proxy(리버스 프록시)와 Let’s Encrypt(렛츠 인크립트)를 활용하여 Docker 컨테이너에 외부에서 안전하게 접근하는 방법에 대해 다뤄볼 예정입니다. 기대해주세요! 그럼 다음 글에서 또 만나요! 👋

  • [Proxmox] LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    [Proxmox] LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    LXC 컨테이너 심화 활용: Docker 연동 및 성능 최적화 (Proxmox VE 9.1)

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’ 블로그 주인장입니다. 오늘도 홈랩에서 밤샘 삽질 끝에 얻어낸 귀한 경험 하나를 공유해드리려고 해요. 💡

    홈랩을 운영하거나 소규모 서버를 돌리시는 분들이라면 Proxmox VE (Virtual Environment)의 매력에 빠져 계실 텐데요. 특히 LXC (Linux Containers)는 가벼운 오버헤드로 높은 성능을 내주기 때문에 저도 애용하고 있습니다. 여기에 Docker까지 연동하면 어떨까요? 효율은 물론이고 관리 유연성까지 챙길 수 있거든요.

    오늘은 Proxmox VE 9.1 환경에서 LXC 컨테이너 안에 Docker를 설치하고, 실제 서비스를 운영하면서 겪었던 삽질과 함께 성능 최적화 팁까지 아낌없이 풀어보겠습니다. LXC와 Docker 연동에 어려움을 겪으셨다면, 이 글이 든든한 가이드가 될 거예요!

    Proxmox VE 호스트에서 LXC 컨테이너와 Docker가 연동되는 아키텍처 다이어그램

    LXC와 Docker, 그리고 그들의 시너지

    먼저 LXC와 Docker가 뭔지 간단하게 짚고 넘어갈게요. 이미 잘 아시는 분들도 계시겠지만, 핵심만 콕 짚어드리겠습니다.

    • LXC (Linux Containers, 리눅스 컨테이너): 리눅스 커널의 컨테이너 기술을 활용한 OS 수준의 가상화예요. 쉽게 말해, 별도의 커널 없이 호스트의 커널을 공유하면서도 독립적인 운영체제 환경을 만들어주는 거죠. 가상 머신(VM)보다 훨씬 가볍고 빠르고, 부팅 시간도 거의 없어서 자원 소모가 정말 적어요.
    • Docker (도커): 애플리케이션 수준의 컨테이너 기술입니다. 특정 애플리케이션과 그에 필요한 모든 종속성(라이브러리, 설정 파일 등)을 하나의 이미지(Image)로 묶어서 어디서든 동일하게 실행되도록 해줘요. 개발 환경과 운영 환경의 불일치 문제를 한 번에 해결하는 거죠.

    그럼 이 둘을 왜 같이 쓸까요? 직접 써본 결과 이런 장점들이 정말 크더라고요.

    특징 LXC + Docker 연동의 장점 기존 방식 대비
    자원 효율성 LXC는 VM보다 오버헤드가 적어서, 그 위에 Docker를 올리면 VM 내 Docker보다 훨씬 적은 자원으로 많은 서비스를 돌릴 수 있어요. VM 내 Docker: 커널 이중화로 자원 낭비
    베어메탈 Docker: 호스트 OS 오염 우려
    격리성 LXC 컨테이너가 OS 수준의 격리를 제공하고, 그 안에 Docker가 또 한 번 애플리케이션 격리를 제공하니 보안성과 안정성이 정말 높아져요. 베어메탈 Docker: 호스트 OS와 Docker 컨테이너 간 완전한 격리가 어려움
    관리 용이성 Proxmox VE의 강력한 LXC 관리 기능(스냅샷, 마이그레이션 등)과 Docker의 애플리케이션 배포/관리 기능을 동시에 누릴 수 있어요. 각각의 장점을 한 번에!

    Proxmox VE 9.1 버전에서는 LXC 컨테이너 기능이 더욱 안정화되고 사용성이 개선되었기 때문에, Docker 연동할 때 시너지가 정말 커져요.

    Proxmox VE 9.1 환경에서 LXC 컨테이너 생성 및 Docker 연동 실전 가이드

    자, 이제 직접 해볼 시간입니다. 제가 홈랩에서 실제로 진행했던 과정을 그대로 따라하시면 돼요. 😎

    1. LXC 컨테이너 기본 생성

    먼저 Proxmox VE 웹 UI에 접속해서 LXC 컨테이너를 생성합니다. OS 템플릿은 Ubuntu 22.04 LTS (Jammy Jellyfish)를 추천할게요. 가장 안정적이고 Docker 지원도 정말 잘 되거든요.

    1. Proxmox VE 웹 UI (https://<Proxmox_IP>:8006) 에 접속합니다.
    2. Datacenter -> pve -> Local (pve) -> CT Templates -> Templates에서 원하는 Ubuntu 템플릿을 다운로드해요.
    3. pve 노드에서 CT 생성 버튼을 클릭합니다.
    4. 일반 설정: Hostname, Password 등을 설정하세요.
    5. 템플릿 설정: 다운로드한 Ubuntu 22.04 LTS 템플릿을 선택해요.
    6. 디스크 설정: 최소 8GB 이상으로 설정해주세요. Docker 이미지를 많이 올릴 계획이라면 더 크게 잡는 게 좋습니다.
    7. CPU 설정: 코어는 1개 이상, CPU units (CPU 유닛)은 기본값(1024)으로 둬도 되지만, 고성능이 필요하면 더 높게 설정할 수 있어요.
    8. 메모리 설정: 최소 512MB 이상을 권장합니다. Docker 앱에 따라 달라지니 유연하게 설정하세요.
    9. 네트워크 설정: Bridge (브리지) 모드로 설정하여 호스트와 동일한 네트워크 대역을 사용하도록 하세요.
    10. 마지막으로 확인을 눌러 LXC 컨테이너를 생성합니다.

    ⚠️ 중요 포인트: 비특권 컨테이너(Unprivileged Container) 설정!

    Docker를 LXC 컨테이너 안에서 안전하게 사용하려면 비특권 컨테이너로 만드는 게 좋아요. 보안상 훨씬 유리하거든요. 하지만 비특권 컨테이너에서 Docker가 제대로 동작하려면 몇 가지 추가 설정이 필요해요.

    1. 컨테이너 생성 후, Proxmox VE 웹 UI에서 해당 LXC 컨테이너를 선택하세요.
    2. 옵션 탭으로 이동합니다.
    3. Features (기능) 항목을 찾아서 편집을 클릭하세요.
    4. 여기서 Nesting (중첩)과 FUSE (파일 시스템 인 유저스페이스)를 활성화하고 확인을 눌러요.

    이 두 가지 옵션이 Docker의 스토리지 드라이버(특히 overlay2)가 LXC 내부에서 정상적으로 작동하도록 하는 핵심이에요. 제가 이걸 몰라서 며칠 밤낮을 삽질했던 기억이 생생하네요… 😅

    Proxmox VE 웹 UI에서 LXC 컨테이너 생성 시 Nesting 및 FUSE 기능을 활성화하는 화면

    2. Docker 설치 및 설정

    LXC 컨테이너가 준비되었다면, 이제 컨테이너에 접속해서 Docker를 설치해봅시다. Proxmox 웹 UI에서 해당 LXC 컨테이너를 선택하고 콘솔 탭으로 이동하면 바로 접속돼요.

    \n# LXC 컨테이너 내부에서 실행
    
    # 패키지 목록 업데이트 및 필요한 도구 설치
    sudo apt update
    sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release
    
    # Docker 공식 GPG 키 추가
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
    
    # Docker Stable 저장소 추가
    echo \
      "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
      $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    
    # Docker 엔진 설치
    sudo apt update
    sudo apt install -y docker-ce docker-ce-cli containerd.io
    
    # Docker 서비스 시작 및 부팅 시 자동 시작 설정
    sudo systemctl start docker
    sudo systemctl enable docker
    
    # 현재 사용자에게 Docker 그룹 권한 추가 (선택 사항, sudo 없이 docker 명령어 사용 가능)
    sudo usermod -aG docker $USER
    
    # 변경 사항 적용을 위해 재로그인 또는 새 쉘 시작
    # exit 후 다시 접속하거나, su - $USER 명령으로 적용
    
    # Docker 설치 확인
    docker run hello-world
    

    docker run hello-world 명령을 실행했을 때 성공 메시지가 나온다면 🎉 Docker 설치가 완벽하게 된 거예요!

    3. 비특권(Unprivileged) 컨테이너의 Docker 이슈 해결 (추가 팁)

    위에서 Nesting과 FUSE를 활성화했지만, 간혹 비특권 컨테이너에서 Docker를 사용할 때 권한 문제나 스토리지 관련 이슈가 발생할 수 있어요. 특히 subuid, subgid 매핑이 제대로 안 되어있을 때 그렇습니다. 제가 겪었던 문제 중 하나였죠.

    만약 Docker 컨테이너 실행 시 권한 관련 오류가 발생한다면, Proxmox 호스트에서 다음 설정을 확인해보세요.

    1. Proxmox 호스트에 SSH로 접속합니다.
    2. /etc/subuid와 /etc/subgid 파일에 LXC 컨테이너의 UID/GID 범위가 매핑되어 있는지 확인하세요. 보통 LXC 생성 시 자동으로 추가돼요.
    3. 만약 특정 Docker 컨테이너가 호스트의 특정 디렉토리에 접근해야 하는데 권한 문제가 있다면, /etc/pve/lxc/<VMID>.conf 파일에 다음 라인을 추가하세요. (예시: 100은 컨테이너 ID)
      echo 'lxc.apparmor.profile: unconfined'
      echo 'lxc.mount.auto: cgroup:rw'
      

      이 설정은 컨테이너의 보안 프로파일을 완화하고 cgroup 마운트를 허용하여 Docker가 더 자유롭게 동작하도록 해요. 하지만 보안상 약간 취약해질 수 있으니 신중하게 사용하세요.

    4. 또 다른 방법으로는 Docker root directory를 변경하여 /var/lib/docker 대신 /mnt/data/docker처럼 별도의 마운트 경로를 사용하는 거예요. /etc/docker/daemon.json 파일을 생성(또는 편집)하고 다음 내용을 추가하세요.
      {
        "data-root": "/mnt/data/docker",
        "storage-driver": "overlay2"
      }
      

      그 후 Docker 서비스를 재시작해요: sudo systemctl restart docker. 이 방법은 특히 ZFS 같은 파일 시스템을 사용하는 Proxmox 호스트에서 LXC에 더 안정적인 Docker 스토리지 환경을 제공할 때 정말 유용해요.

    성능 최적화를 위한 팁과 트러블슈팅 ⚠️

    LXC 컨테이너에 Docker를 올리면 기본적으로 성능이 좋지만, 몇 가지 설정을 통해 더 극대화할 수 있어요.

    1. 컨테이너 자원 관리 (CPU, RAM)

    • CPU Core (CPU 코어) 할당: Proxmox VE 웹 UI에서 LXC 컨테이너의 CPU 코어를 필요한 만큼 할당하세요. 너무 많이 할당하면 다른 컨테이너나 VM의 자원을 잠식할 수 있으니, 실제 워크로드에 맞춰 조절하는 게 중요해요.
    • CPU Units (CPU 유닛) 조절: 여러 컨테이너가 CPU를 경쟁할 때, 특정 컨테이너에 더 높은 우선순위를 주고 싶다면 CPU units 값을 높게 설정해요. 기본값 1024가 공평한 분배라면, 2048은 두 배의 우선순위를 갖는 식이죠.
    • Memory (메모리) 및 Swap (스왑): Docker 컨테이너가 사용할 메모리를 충분히 할당해주세요. 스왑은 꼭 필요한 경우가 아니라면 비활성화하거나 최소한으로 설정하는 게 성능에 좋아요. 스왑이 너무 많이 발생하면 I/O 병목 현상이 생기거든요.

    2. I/O 성능 개선 (Storage)

    • SSD 사용: Proxmox VE 호스트의 OS 및 LXC 컨테이너 스토리지는 반드시 SSD (Solid State Drive)를 사용하는 게 좋아요. 특히 Docker는 이미지 다운로드, 레이어 관리 등으로 I/O 작업이 빈번하니 SSD의 이점이 극대화돼요. NVMe SSD라면 더할 나위 없겠죠.
    • LVM-Thin or ZFS: Proxmox에서 LXC 컨테이너를 생성할 때 LVM-Thin이나 ZFS 같은 스토리지를 사용하는 게 좋아요. 스냅샷 기능도 유용하고, 성능도 괜찮거든요. 개인적으로는 ZFS를 선호해요.
    • Bind Mount (바인드 마운트) 활용: Docker 컨테이너가 영구 데이터를 저장해야 한다면, LXC 컨테이너 내부의 디렉토리를 호스트의 물리 디스크에 바인드 마운트하는 게 좋아요. 예를 들어, 호스트에 별도의 데이터 디스크를 마운트하고, 이를 LXC 컨테이너에 다시 마운트한 뒤 Docker 볼륨으로 사용하는 방식이죠.
    \n# Proxmox 호스트에서 LXC 컨테이너 설정 파일 편집
    # /etc/pve/lxc/VMID.conf 에 다음 라인 추가
    lxc.mount.entry: /path/on/host /path/on/lxc none bind,create=dir 0 0
    

    3. 네트워크 설정 최적화

    • Bridge (브리지) 모드: LXC 컨테이너의 네트워크는 기본적으로 브리지 모드를 사용하는 게 가장 일반적이고 성능 저하가 적어요. 호스트의 브리지(vmbr0)에 직접 연결돼서 별도의 NAT 변환 없이 호스트와 동일한 네트워크에서 통신하거든요.
    • MacVLAN (맥브이랜): 특정 Docker 컨테이너에 별도의 물리적 MAC 주소를 할당하여 호스트 네트워크와 동등하게 통신하고 싶다면 MacVLAN을 고려할 수 있어요. 하지만 설정이 조금 복잡하고, 네트워크 장비가 이를 지원해야 해요. 저도 이 부분은 아직 삽질 중이지만, 특정 시나리오에서는 정말 유용할 수 있습니다.

    성능 검증 및 결과 확인 ✅

    모든 설정이 끝났다면, 이제 실제로 Docker 컨테이너를 띄워서 성능을 확인해볼 차례예요. docker stats 명령어로 각 Docker 컨테이너의 자원 사용량을 실시간으로 모니터링할 수 있거든요.

    \n# LXC 컨테이너 내부에서 실행
    docker stats
    

    이 명령어를 실행하면 CPU 사용량, 메모리 사용량, 네트워크 I/O, 블록 I/O 등을 한눈에 볼 수 있어요. 이 외에도 htop이나 glances 같은 도구를 LXC 컨테이너에 설치하여 전체적인 자원 사용량을 확인하는 것도 정말 좋습니다.

    제가 직접 여러 Docker 컨테이너(Nginx, MariaDB, Portainer 등)를 LXC에 올려서 테스트해보니, 확실히 VM에 올렸을 때보다 CPU와 메모리 사용량이 눈에 띄게 줄어드는 거더라고요. 특히 아이들(idle) 상태에서는 거의 자원을 사용하지 않아서 매우 만족스러웠어요. 🎉

    Proxmox LXC 내 Docker 컨테이너의 CPU, 메모리, I/O 성능 모니터링 대시보드

    마무리하며: 13년차 엔지니어의 한마디

    오늘은 Proxmox VE 9.1 환경에서 LXC 컨테이너와 Docker를 연동하고 성능을 최적화하는 방법을 심도 있게 다뤄봤어요. 제가 직접 겪었던 Nesting, FUSE 같은 핵심 삽질 포인트를 해결하는 방법을 공유하면서, 독자분들의 시간을 절약해드리고 싶었거든요. 😅

    이 조합은 가벼운 홈랩부터 소규모 프로덕션 환경까지, 자원을 효율적으로 사용하면서도 높은 유연성을 제공하는 정말 강력한 솔루션이에요. Proxmox의 안정적인 가상화 기반 위에 Docker의 강력한 애플리케이션 관리 능력을 더하는 거죠.

    물론 모든 기술이 그렇듯, 완벽한 솔루션은 없어요. 하지만 LXC와 Docker의 장점을 잘 이해하고 활용한다면, 여러분의 서버실도 더욱 스마트하고 효율적으로 운영될 수 있을 거예요. 다음에는 이 LXC + Docker 환경 위에 Docker Compose (도커 컴포즈)를 활용해서 여러 서비스를 한 번에 배포하는 방법을 다뤄볼까 하는데, 기대해주세요!

    궁금한 점이나 추가로 알고 싶은 내용이 있다면 언제든지 댓글로 남겨주세요. 여러분의 서버실 운영에 조금이나마 도움이 되었으면 좋겠고, 다음 글에서 또 만나요! 👋

    Proxmox LXC와 가상 머신(VM)에서 Docker를 실행할 때의 성능 및 자원 활용 비교 인포그래픽

  • [Cloud] Podman vs Docker: Rootless 컨테이너 보안 및 활용 가이드

    [Cloud] Podman vs Docker: Rootless 컨테이너 보안 및 활용 가이드

    Podman vs Docker: Rootless 컨테이너 보안 및 활용 가이드

    인프라 엔지니어의 고민: 더 안전한 컨테이너 운영을 찾아서

    안녕하세요, 13년차 서버실 지킴이입니다. 요즘 인프라 엔지니어라면 컨테이너(Container) 기술을 빼놓고 이야기하기 어렵죠. 저도 처음엔 도커(Docker)가 세상에 나왔을 때, ‘와, 이거 진짜 물건이다!’ 하면서 열광했던 기억이 납니다. 개발 환경부터 운영 환경까지 컨테이너 덕분에 정말 많은 게 편리해졌거든요. 그런데 말입니다, 편리함 뒤에는 늘 그림자가 따르기 마련이더라고요. 특히 보안(Security) 측면에서는 늘 마음 한편이 불안했어요.

    도커 데몬(Docker daemon)이 항상 루트(root) 권한으로 실행된다는 점, 그리고 컨테이너 탈출(Container Escape) 같은 잠재적인 보안 위협들은 저를 계속해서 고민하게 만들었죠. 홈랩(Home Lab)에서 다양한 서비스를 돌리면서 ‘어떻게 하면 좀 더 안전하게 컨테이너를 운영할 수 있을까?’ 하는 고민은 저만의 숙제는 아닐 겁니다. 혹시 여러분도 이런 고민 해보신 적 있으신가요? 이 지점에서 제가 눈여겨보게 된 것이 바로 Podman(팟맨)입니다.

    오늘 글에서는 컨테이너 보안의 새로운 대안으로 떠오른 Podman과 우리가 오랫동안 써왔던 Docker를 비교하고, 특히 Rootless 컨테이너(Rootless Container) 개념을 중심으로 Podman의 장점과 활용법을 자세히 알려드리려고 합니다. 제가 직접 삽질해가며 얻은 경험들을 바탕으로, 여러분의 컨테이너 운영에 도움이 될 만한 실질적인 팁들을 공유해볼게요! 💡

    Podman과 Docker 아키텍처 비교 다이어그램

    Podman과 Docker의 아키텍처 비교. Podman은 데몬 없이 사용자 프로세스로 실행되어 보안 이점을 가집니다.

    Rootless 컨테이너란 무엇인가?

    쉽게 말해, Rootless 컨테이너는 루트(root) 권한 없이, 일반 사용자(non-root user) 권한으로 실행되는 컨테이너를 말합니다. 기존 도커는 도커 데몬(Docker Daemon)이 호스트(Host) 시스템에서 루트 권한으로 실행되고, 이 데몬이 컨테이너를 관리하는 구조였죠. 이게 왜 문제가 되냐면, 만약 컨테이너에 보안 취약점이 있어서 외부 공격자가 컨테이너를 탈출(Escape)하는 데 성공하면, 호스트 시스템의 루트 권한까지 획득할 수 있는 심각한 상황이 발생할 수 있기 때문입니다. ⚠️

    Podman은 태생부터 이런 보안 문제를 염두에 두고 설계되었어요. Podman은 도커와 달리 데몬(Daemon)이 없거든요. 즉, 백그라운드에서 항상 루트 권한으로 돌아가는 프로세스가 없다는 뜻입니다. Podman 명령어를 실행하면, 해당 명령어는 일반 사용자 권한으로 컨테이너를 생성하고 관리하게 됩니다. 처음 이걸 알았을 땐 ‘아, 이거다!’ 싶었거든요. 이렇게 되면 컨테이너를 탈출하더라도 일반 사용자 권한까지만 접근할 수 있으니, 호스트 시스템의 피해를 최소화할 수 있습니다. 보안적인 측면에서 봤을 때 정말 큰 이점이라고 할 수 있어요.

    Podman vs Docker: 핵심 차이점 비교

    Podman과 Docker는 컨테이너를 관리하는 도구라는 공통점이 있지만, 내부적으로는 꽤 많은 차이가 있습니다. 제가 직접 써보면서 느낀 주요 차이점들을 표로 정리해봤어요.

    특징 Podman Docker
    아키텍처 (Architecture) 데몬리스 (Daemonless): 백그라운드 데몬 없음. 사용자 프로세스로 실행. 데몬 기반 (Daemon-based): Docker 데몬이 루트 권한으로 백그라운드 실행.
    루트 권한 (Root Privileges) 기본 Rootless: 일반 사용자 권한으로 컨테이너 실행. 데몬이 루트 권한으로 실행. Rootless 모드는 실험적 또는 부가 기능.
    보안 (Security) 호스트 시스템에 대한 공격 표면(Attack Surface) 감소. 데몬 취약점 발생 시 호스트 시스템 전체 위험.
    이미지 빌드 (Image Build) Buildah(빌다)를 내부적으로 활용 (podman build). Docker Build 엔진 사용 (docker build).
    오케스트레이션 (Orchestration) Kubernetes Pods(쿠버네티스 파드)와 높은 호환성. podman generate kube로 YAML 생성 가능. Docker Swarm(도커 스웜), Docker Compose(도커 컴포즈) 지원.
    명령어 호환성 (CLI Compatibility) 대부분의 docker 명령어와 유사 (podman으로 대체 가능). 표준 Docker CLI.
    Podman vs Docker 핵심 차이점 비교 인포그래픽

    Podman과 Docker의 주요 특징들을 한눈에 비교한 표입니다. 특히 데몬리스 아키텍처와 Rootless 기본 지원이 Podman의 가장 큰 차이점이죠.

    Podman으로 Rootless 컨테이너 실행하기

    그럼 이제 Podman으로 Rootless 컨테이너를 직접 실행해보면서 그 편리함을 느껴볼 시간입니다! 제가 홈랩에서 주로 쓰는 CentOS Stream 9나 Fedora, 또는 Ubuntu 22.04 이상 환경에서는 Podman 설치가 아주 쉬워요.

    1. 팟맨 설치하기

    저는 CentOS Stream 9에서 진행했습니다. 여러분의 OS에 맞게 설치해주세요.

    
    # CentOS/Fedora
    sudo dnf install podman -y
    
    # Ubuntu/Debian
    sudo apt update
    sudo apt install podman -y
    

    설치가 완료되면, podman info 명령어로 잘 설치되었는지 확인해볼 수 있습니다.

    
    podman info
    

    여기서 중요한 건, 루트 권한 없이 실행해도 잘 동작한다는 점이에요! 🎉

    2. Rootless 컨테이너 실행해보기

    가장 기본적인 컨테이너 실행부터 시작해볼까요? Alpine 리눅스 컨테이너를 실행해보겠습니다.

    
    podman run --rm -it alpine sh
    

    컨테이너 내부에서 whoami 명령어를 실행해보면, root로 나올 거예요. ‘어? Rootless라면서 왜 컨테이너 안에서는 root지?’ 하고 저처럼 당황하실 수 있는데, 이건 컨테이너 내부의 루트 사용자가 호스트 시스템의 일반 사용자에 매핑(mapping)되었기 때문입니다. 즉, 컨테이너 안에서는 여전히 강력한 권한을 가지지만, 호스트 시스템에는 아무런 영향을 주지 못하는 ‘가짜 루트’인 셈이죠.

    이제 Nginx 웹 서버를 Rootless로 띄워볼까요?

    
    podman run -d --name my-nginx -p 8080:80 nginx
    

    잘 실행되었는지 확인하고, 웹 브라우저나 curl로 접속해보세요.

    
    podman ps
    curl localhost:8080
    

    정상적으로 Nginx 초기 페이지가 보인다면 성공입니다! ✅

    3. Podman의 파드(Pod) 기능 활용해보기

    Podman은 쿠버네티스(Kubernetes)의 파드(Pod) 개념을 네이티브(Native)하게 지원합니다. 여러 컨테이너가 동일한 네트워크 네임스페이스(Network Namespace)와 저장소(Storage)를 공유해야 할 때 아주 유용하거든요. 제가 이걸 처음 써봤을 때, ‘홈랩에 간이 쿠버네티스를 구축한 느낌인데?’ 하면서 감탄했어요. 🤭

    먼저 파드를 생성합니다.

    
    podman pod create --name my-web-app-pod -p 8080:80
    

    이제 이 파드 안에 Nginx와 다른 컨테이너를 넣어보죠.

    
    podman run -d --pod my-web-app-pod --name webserver nginx
    podman run -d --pod my-web-app-pod --name data-logger alpine sleep 1h
    

    podman pod ps 명령어로 파드와 그 안에 있는 컨테이너들을 확인할 수 있습니다.

    
    podman pod ps
    

    4. 이미지 빌드하기

    Podman은 Dockerfile을 이용한 이미지 빌드도 완벽하게 지원합니다. docker build 대신 podman build를 사용하면 되죠. Dockerfile 예시를 하나 만들어볼게요.

    
    # Dockerfile
    FROM alpine:latest
    RUN apk add --no-cache nginx
    COPY ./index.html /usr/share/nginx/html/index.html
    EXPOSE 80
    CMD ["nginx", "-g", "daemon off;"]
    

    그리고 간단한 index.html 파일도 만들어줍니다.

    
    <!DOCTYPE html>
    <html>
    <head>
        <title>Hello Podman!</title>
    </head>
    <body>
        <h1>Welcome to my Rootless Nginx with Podman!</h1>
    </body>
    </html>
    

    이제 이 두 파일이 있는 디렉토리에서 이미지를 빌드합니다.

    
    podman build -t my-custom-nginx .
    

    빌드된 이미지를 확인하고 실행해보세요.

    
    podman images
    podman run -d --name my-custom-web -p 8080:80 my-custom-nginx
    curl localhost:8080
    
    Podman 이미지 빌드 프로세스 다이어그램

    Podman을 이용한 이미지 빌드 과정입니다. Docker와 거의 동일한 명령어로 편리하게 이미지를 만들 수 있어요.

    Podman 운영 시 주의사항

    제가 Podman을 처음 접하면서 겪었던 몇 가지 ‘삽질’과 그 해결책을 공유합니다. 저처럼 헤매지 마시길 바라요! ㅎㅎ

    1. 낮은 포트(Low Port) 바인딩 문제: Rootless 컨테이너는 기본적으로 1024번 이하의 포트(예: 80, 443)를 직접 바인딩(Binding)할 수 없습니다. 이는 보안상의 이유로 일반 사용자에게 허용되지 않는 권한이거든요. 처음 Nginx를 80번 포트에 바로 연결하려고 했을 때, ‘왜 안 되지?’ 하면서 한참을 헤맸습니다. 😩
      해결책: 가장 쉬운 방법은 -p 8080:80처럼 1024번보다 높은 포트에 바인딩하는 것입니다. 아니면 Nginx나 Apache 같은 리버스 프록시(Reverse Proxy)를 호스트에 설정해서 80번 포트로 들어오는 트래픽을 컨테이너의 8080번 포트로 포워딩(Forwarding)하는 방법도 있어요. (sysctl net.ipv4.ip_unprivileged_port_start=80 같은 설정을 할 수도 있지만, 보안상 권장하지는 않습니다.)

    2. 볼륨 마운트(Volume Mount) 권한 문제: Rootless 컨테이너에서 호스트의 특정 디렉토리를 볼륨으로 마운트할 때 권한 문제가 발생할 수 있어요. 컨테이너 내부의 UID/GID(User ID/Group ID)가 호스트 시스템의 UID/GID와 매핑되는 방식 때문에 생기는 문제인데, /etc/subuid와 /etc/subgid 파일에 정의된 보조 UID/GID 범위가 적절히 설정되어 있지 않으면 문제가 됩니다.
      해결책: 이 파일들을 수동으로 편집하거나, Podman이 자동으로 설정하도록 합니다. 대부분의 경우 Podman 설치 시 자동으로 설정되지만, 가끔 문제가 생기면 이 파일을 확인해보세요. 저도 특정 디렉토리에 로그를 남기려다가 권한 문제로 고생 좀 했어요.

    3. systemd 통합: Podman은 systemd와 아주 잘 통합됩니다. podman generate systemd 명령어를 사용하면 실행 중인 컨테이너나 파드를 systemd 서비스로 등록할 수 있는 유닛(Unit) 파일을 자동으로 생성해줍니다. 이걸 몰랐을 때는 직접 유닛 파일을 만들었는데, 나중에 이 기능을 알고 얼마나 편했는지 몰라요! 🤩

    검증: Rootless 컨테이너로 더 안전한 운영

    Podman으로 Rootless 컨테이너를 운영하면서 제가 가장 크게 느낀 점은 ‘마음의 평화’입니다. 😅 호스트 시스템에 대한 잠재적인 보안 위협이 크게 줄어들기 때문에, 훨씬 안심하고 컨테이너를 돌릴 수 있게 되었거든요. podman ps, podman inspect 같은 명령어로 컨테이너 상태를 확인해보면, 도커와 거의 동일한 방식으로 작동한다는 걸 알 수 있습니다. 단지 실행 주체가 루트가 아닌 일반 사용자라는 것만 다를 뿐이죠.

    특히 ~/.local/share/containers 경로를 확인해보면, 모든 컨테이너 관련 파일들이 일반 사용자 홈 디렉토리 아래에 생성된 것을 볼 수 있어요. 이게 바로 Rootless 컨테이너의 핵심 증거입니다. 👍

    Rootless 컨테이너 보안 이점 다이어그램

    Rootless 컨테이너는 호스트 시스템의 루트 권한으로부터 격리되어 보안을 강화합니다.

    마무리: 언제 Podman을 써야 할까?

    오늘 Podman과 Docker의 차이점, 그리고 Rootless 컨테이너의 중요성에 대해 이야기해봤습니다. Podman은 다음과 같은 상황에서 특히 강력한 대안이 될 수 있다고 생각해요.

    • 보안이 최우선 고려사항일 때: 특히 다중 사용자 환경이나, 호스트 시스템의 보안을 최대한 강화하고 싶을 때 Rootless Podman은 탁월한 선택입니다.
    • 쿠버네티스 환경을 준비 중일 때: Podman은 쿠버네티스 파드 개념을 네이티브하게 지원하고, podman generate kube 같은 명령어로 쉽게 YAML 파일을 생성할 수 있어 쿠버네티스 학습 및 연동에 유리합니다.
    • 경량화된 컨테이너 환경이 필요할 때: 백그라운드 데몬 없이 필요한 시점에만 프로세스가 실행되므로, 리소스 효율성 측면에서도 장점이 있어요.

    물론 Docker도 여전히 막강한 생태계와 성숙한 도구들을 가지고 있습니다. Docker Compose나 Docker Swarm 같은 기능은 아직 Podman보다 더 안정적이고 편리한 측면이 많죠. 따라서 어떤 도구를 선택할지는 여러분의 특정 요구사항과 환경에 따라 달라질 겁니다.

    저의 13년차 경험상, ‘만능 도구’는 없습니다. 하지만 각 도구의 장단점을 정확히 알고 상황에 맞게 사용하는 것이 진정한 엔지니어의 자세라고 생각합니다. Podman은 컨테이너 보안과 효율성을 한 단계 끌어올릴 수 있는 정말 매력적인 도구임은 분명해요. 다음번에는 Podman Compose를 이용한 다중 컨테이너 애플리케이션 배포에 대해 더 깊이 다뤄보도록 하겠습니다. 긴 글 읽어주셔서 감사합니다! 👋

  • [Nas] Docker Compose로 NAS에 앱 배포 및 관리하기: Synology, TrueNAS SCALE 가이드

    [Nas] Docker Compose로 NAS에 앱 배포 및 관리하기: Synology, TrueNAS SCALE 가이드

    13년차 서버실: Docker Compose로 NAS 앱 배포 및 관리 – Synology, TrueNAS SCALE 실전 가이드

    안녕하세요! 13년차 인프라 엔지니어입니다. 오늘은 많은 분들이 궁금해하실 주제를 다뤄볼게요. 바로 Docker Compose를 활용해서 NAS(Network Attached Storage)에 다양한 애플리케이션을 배포하고 관리하는 방법인데요. Synology와 TrueNAS SCALE 환경에서 직접 경험했던 내용을 바탕으로 실전 팁을 공유해드리겠습니다. 혹시 NAS를 파일 저장소로만 쓰고 계신가요? Docker Compose와 함께라면 여러분의 NAS가 훨씬 더 똑똑한 홈랩 서버로 변신합니다! 😉

    NAS 환경에서 Docker Compose를 활용한 애플리케이션 배포 및 관리 아키텍처 개요

    왜 NAS에 Docker Compose를 써야 할까요?

    NAS를 운영하다 보면 언젠가는 ‘파일 저장소 말고 다른 기능도 쓰고 싶은데…’ 하는 생각이 들게 돼요. 개인 블로그를 운영하고 싶거나, 영화·음악 스트리밍 서버를 구축하고 싶을 때 말이죠. 예전 같으면 복잡한 설치 과정과 설정 때문에 망설였겠지만, Docker와 Docker Compose를 알게 된 후로는 정말 달라졌어요.

    Docker는 애플리케이션을 컨테이너라는 격리된 환경에 담아 실행하는 기술입니다. 덕분에 운영체제나 다른 프로그램과의 충돌 걱정 없이 원하는 앱을 쉽게 설치하고 실행할 수 있죠. 다만 여러 개의 컨테이너를 묶어서 관리하려면 일일이 명령어를 입력해야 해서 번거로울 때가 많아요. 이때 등장하는 것이 바로 Docker Compose입니다!

    쉽게 말해, Docker Compose는 YAML이라는 설정 파일을 사용해서 여러 컨테이너로 구성된 애플리케이션을 한 번에 정의하고 실행할 수 있게 해주는 도구예요. 마치 오케스트라의 지휘자처럼 여러 악기(컨테이너)들이 조화롭게 연주(실행)되도록 지휘하는 역할을 하는 거죠.

    Docker Compose를 NAS에서 사용하면 좋은 점은 다음과 같아요:

    • ✅ 간편한 배포: 복잡한 설정 과정을 YAML 파일 하나로 정의하고, 단 한 번의 명령어로 여러 컨테이너를 한 번에 띄울 수 있어요.
    • ✅ 쉬운 관리: 컨테이너의 시작, 중지, 재시작, 삭제 등을 Compose 명령어로 간단하게 관리할 수 있습니다.
    • ✅ 재현성: 동일한 YAML 설정 파일만 있으면 언제 어디서든 똑같은 환경을 구축할 수 있어요. 개발, 테스트, 운영 환경 간의 차이로 인한 문제를 줄여주거든요.
    • ✅ 포트 충돌 방지: 각 컨테이너가 사용할 포트(Port)를 명확하게 지정하여 충돌을 피할 수 있습니다.
    • ✅ 확장성: 필요에 따라 컨테이너 수를 늘리거나 줄이기가 정말 쉬워요.

    Synology와 TrueNAS SCALE, Docker Compose 활용법

    Synology DSM과 TrueNAS SCALE은 각기 다른 방식으로 Docker 환경을 제공하지만, Docker Compose를 활용하는 기본 원리는 동일합니다. 핵심은 docker-compose.yml 파일을 작성하고 실행하는 거죠.

    1. Synology NAS에서 Docker Compose 사용하기

    Synology NAS에서는 ‘Docker’ 패키지를 설치하면 Docker Compose 기능을 사용할 수 있어요. DSM의 ‘패키지 센터’에서 Docker를 검색하여 설치해주세요. 저는 보통 SSH로 NAS에 접속해서 작업하는 것을 선호하지만, DSM의 ‘텍스트 편집기’나 ‘File Station’을 이용해 YAML 파일을 작성하고 관리할 수도 있습니다.

    실행 단계:

    1. SSH 접속: Putty(Windows) 또는 터미널(macOS/Linux)을 이용해 NAS에 SSH로 접속합니다.
    2. 작업 디렉토리 생성: 원하는 위치에 애플리케이션을 위한 디렉토리를 만들어요. 예: mkdir /volume1/docker/my-app && cd /volume1/docker/my-app
    3. docker-compose.yml 파일 작성: 텍스트 편집기(vi, nano 등)를 이용해 docker-compose.yml 파일을 생성하고 내용을 작성합니다.
    4. Docker Compose 실행: docker-compose up -d 명령어를 실행하면 설정된 컨테이너들이 백그라운드(-d)에서 실행돼요.

    예시: Nginx 웹 서버와 Portainer (컨테이너 관리 도구) 배포

    Portainer는 Docker 환경을 웹 UI로 쉽게 관리할 수 있게 해주는 정말 유용한 도구예요. NAS에 Portainer를 설치해두면 컨테이너 관리가 훨씬 편해진답니다.

    
    version: '3.8'
    
    services:
      portainer:
        image: portainer/portainer-ce:latest
        container_name: portainer
        restart: unless-stopped
        security_opt:
          - no-new-privileges:true
        ports:
          - "8000:8000"
          - "9443:9443"
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock
          - portainer_data:/data
        networks:
          - portainer_net
    
      nginx:
        image: nginx:latest
        container_name: my-nginx
        restart: unless-stopped
        ports:
          - "80:80"
          - "443:443"
        volumes:
          - ./nginx.conf:/etc/nginx/nginx.conf:ro
          - ./html:/usr/share/nginx/html:ro
        depends_on:
          - portainer
        networks:
          - portainer_net
    
    volumes:
      portainer_data:
    
    networks:
      portainer_net:
        driver: bridge
    

    이 파일을 /volume1/docker/portainer-nginx/docker-compose.yml에 저장하고, 해당 디렉토리에서 docker-compose up -d를 실행하면 Portainer와 Nginx 웹 서버가 동시에 실행돼요. Portainer는 http://NAS_IP:9443 (SSL), Nginx는 http://NAS_IP로 접속할 수 있습니다.

    Synology DSM에서 Docker 패키지를 설치하는 과정

    2. TrueNAS SCALE에서 Docker Compose 사용하기 (TrueNAS SCALE Apps)

    TrueNAS SCALE은 Kubernetes 기반으로 앱을 관리하는 ‘Apps’ 기능을 제공해요. Docker Compose 파일을 직접 사용하는 방식과는 조금 다르지만, Apps 기능을 통해 원하는 애플리케이션을 쉽게 설치하고 관리할 수 있다는 점은 같습니다. TrueNAS SCALE의 Apps는 Helm chart라는 것을 사용하는데, 많은 경우 Docker Compose 파일과 유사한 구조를 가져요.

    실행 단계:

    1. Apps 메뉴 접근: TrueNAS SCALE 웹 UI에서 ‘Apps’ 메뉴로 이동합니다.
    2. Catalogs 설정: 원하는 애플리케이션을 설치하기 위해 Catalog(앱 스토어 같은 개념)를 추가해야 해요. 커뮤니티에서 제공하는 다양한 Catalog들이 있습니다.
    3. 애플리케이션 설치: Catalog에서 원하는 앱을 선택하고 설치를 진행하면 돼요. 커스텀 앱을 직접 등록하여 Docker Compose 파일처럼 관리할 수도 있습니다.

    주의사항: TrueNAS SCALE의 Apps는 Kubernetes 기반이므로, Docker Compose의 docker-compose.yml 파일을 직접 실행하는 방식과는 다릅니다. 하지만 많은 커뮤니티 앱들이 Docker Compose 구조를 따르고 있어서, YAML 파일의 내용을 이해하고 있다면 앱 설정 시 도움이 돼요. 직접 Docker Compose 파일을 적용하려면 TrueNAS CORE의 ‘iocage’ 플러그인이나 TrueNAS SCALE에서 별도의 VM을 구성해야 할 수도 있습니다. 다만 대부분의 일반 사용자는 Apps 기능으로 충분히 원하는 앱을 설치하고 관리할 수 있어요.

    TrueNAS SCALE의 Apps 메뉴에서 다양한 애플리케이션을 탐색하고 설치하는 과정

    실전 팁 & 트러블슈팅 ⚠️

    13년간 Docker를 다루면서 겪었던 문제와 팁을 공유해 드릴게요. 처음엔 이것 때문에 밤새 고생했던 기억이 있어요. ㅎㅎ

    • 포트 충돌 (Port Conflict): 가장 흔한 문제예요. docker-compose.yml 파일에서 ports 섹션에 이미 사용 중인 호스트 포트를 지정하면 컨테이너가 실행되지 않습니다. Synology NAS의 경우, DSM 자체적으로 사용하는 포트와 충돌하지 않도록 주의해야 해요. 예를 들어 80번 포트는 DSM의 웹 스테이션 등이 사용할 수 있으니, 다른 포트(예: 8080)로 변경하는 것이 훨씬 안전합니다.
    • 볼륨 마운트 경로: 컨테이너 내의 데이터가 호스트 NAS의 특정 경로에 저장되도록 volumes 설정을 잘 해야 합니다. Synology에서는 /volume1/docker/app-name 같은 경로를 주로 사용하고, TrueNAS SCALE에서는 /mnt/poolname/dataset/app-name 같은 경로를 써요. 경로가 잘못되면 데이터가 사라지거나 컨테이너가 제대로 동작하지 않을 수 있으니 주의하세요. 경로 지정 시에는 항상 절대 경로(Absolute Path)를 사용하는 게 정답이에요.
    • 권한 문제 (Permission Issues): 컨테이너가 호스트 파일 시스템에 접근할 때 권한 문제가 발생할 수 있습니다. Docker Compose 파일의 user 옵션을 설정하거나, 호스트 볼륨의 권한을 컨테이너 사용자의 권한에 맞게 조정해야 할 수 있어요.
    • Docker Compose 버전 호환성: version 필드에 명시된 Compose 파일 형식 버전과 실제 사용 중인 Docker Compose 엔진 버전 간의 호환성을 확인하세요. 최신 버전에서는 지원되지 않는 기능이 이전 버전에 있을 수 있습니다.
    • 네트워크 설정: 여러 컨테이너가 서로 통신해야 하는 경우, networks 설정을 올바르게 해야 합니다. 기본적으로는 bridge 네트워크가 사용되지만, 복잡한 구성에서는 custom network을 사용해야 할 때도 있어요.

    💡 팁: 문제가 발생했을 때, docker-compose logs 명령어로 해당 서비스의 로그를 확인하세요. 정말 많은 힌트를 얻을 수 있거든요! 저도 이 명령어로 대부분의 문제를 해결했어요.

    결과 확인 및 관리

    Docker Compose 명령어를 통해 컨테이너를 실행한 후에는 상태를 확인하는 것이 중요합니다.

    • docker-compose ps: 현재 실행 중인 컨테이너 목록과 상태를 보여줘요.
    • docker-compose logs -f : 특정 컨테이너의 실시간 로그를 확인할 수 있습니다. (Ctrl+C로 종료)
    • docker-compose down: 실행 중인 컨테이너들을 중지하고 관련된 네트워크, 볼륨 등을 삭제해요. (데이터 보존 여부는 볼륨 설정에 따라 다름)
    • docker-compose pull: Docker 이미지의 최신 버전을 다운로드합니다.
    • docker-compose up -d --build: 설정 파일을 새로 빌드하고 컨테이너를 실행해요.

    Portainer 대시보드를 통해 Synology 또는 TrueNAS SCALE에서 실행 중인 Docker 컨테이너들을 한눈에 관리하는 모습

    마무리하며

    지금까지 Docker Compose를 활용하여 Synology와 TrueNAS SCALE NAS 환경에서 애플리케이션을 배포하고 관리하는 방법에 대해 알아봤습니다. 처음에는 조금 복잡해 보일 수 있지만, 한 번 익혀두면 NAS의 활용도를 정말 무궁무진하게 높일 수 있는 강력한 도구예요.

    저도 처음엔 간단한 웹 서버 하나 띄우는 것도 버거웠는데, 지금은 여러 컨테이너를 엮어 복잡한 서비스를 구축할 수 있게 됐네요. 여러분도 오늘 알려드린 내용을 바탕으로 차근차근 시도해보신다면, 분명 여러분만의 멋진 홈랩 환경을 구축하실 수 있을 겁니다.

    다음 글에서는 Docker Compose를 활용한 Home Assistant 설치 및 연동에 대한 실전 가이드를 다룰 예정이니 많은 기대 부탁드립니다! 혹시 오늘 내용 중에 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 함께 해결해나가겠습니다. 😉

  • [HomeLabs] 라즈베리파이 5 홈랩 구축: 저전력 미니PC 활용 완전 가이드

    전기세 걱정 없는 홈서버, 라즈베리파이 5로 시작해보세요

    홈랩(Home Lab)을 처음 꾸릴 때 저도 똑같은 고민을 했거든요. “중고 서버 살까? 미니PC 살까?” 근데 막상 중고 타워 서버를 들여놨더니 소음이 장난이 아니더라고요. 한밤중에 서버실(사실 제 방 한 켠이지만) 앞을 지나갈 때마다 데이터센터 온 느낌이랄까요. 그리고 전기 요금 고지서 받아보고 진짜 식겁했습니다.

    그래서 찾게 된 게 라즈베리파이 5(Raspberry Pi 5) 홈랩이에요. 저전력 홈서버로 이만한 게 없더라고요. 처음엔 “이 작은 게 뭘 할 수 있겠어?” 싶었는데, 막상 세팅하고 나니까 놀라웠습니다. 이 글에서는 제가 직접 구축하면서 겪은 삽질과 함께, 라즈베리파이 5 홈랩을 제대로 활용하는 방법을 공유해 드릴게요.

    라즈베리파이 5 기반 홈랩의 전체 구성도 — 단일 보드 컴퓨터 하나로 이렇게 많은 서비스를 돌릴 수 있습니다.

    라즈베리파이 5가 홈랩에 적합한 이유

    라즈베리파이 시리즈는 워낙 유명하지만, 5세대로 넘어오면서 진짜 “쓸만한” 홈서버로 거듭났어요. 이전 세대와 비교하면 체감 성능 차이가 꽤 납니다.

    라즈베리파이 5의 주요 스펙을 간단히 정리하면:

    • CPU: Broadcom BCM2712, Arm Cortex-A76 쿼드코어
    • RAM: 4GB 또는 8GB LPDDR4X (홈랩용이라면 8GB 추천)
    • 스토리지 인터페이스: PCIe 2.0 슬롯 추가 (NVMe SSD 연결 가능)
    • 네트워크: 기가비트 이더넷
    • USB: USB 3.0 포트 2개, USB 2.0 포트 2개

    여기서 제가 특히 주목한 건 PCIe 슬롯이에요. 이전 세대까지는 microSD 카드에 전적으로 의존하거나 USB 방식 외장 SSD를 써야 했거든요. 5세대부터는 공식 HAT(Hardware Attached on Top, 확장 보드)나 서드파티 어댑터를 통해 NVMe SSD를 직접 연결할 수 있어요. 속도 차이가 체감상 확연합니다.

    저전력 홈서버로서의 장점

    • ✅ 소음 없음: 액티브 쿨러를 달아도 일반 PC 대비 훨씬 조용
    • ✅ 저전력: 일반 데스크탑 PC 대비 전력 소모가 현저히 낮음
    • ✅ 공간 효율: 손바닥 크기라 어디든 놓을 수 있음
    • ✅ 활발한 커뮤니티: 문제 생기면 검색하면 다 나옴 (이게 진짜 중요해요)
    • ✅ 합리적인 가격: 진입 장벽이 낮음

    물론 단점도 있어요. x86 아키텍처가 아닌 ARM이라 일부 소프트웨어는 ARM 빌드를 따로 찾아야 하고, 고성능 컴퓨팅 작업에는 한계가 있습니다. 하지만 홈랩 용도, 특히 네트워크 서비스, 모니터링, 미디어 서버, 자동화 같은 작업에는 충분하더라고요.

    준비물 체크리스트

    본격적으로 시작하기 전에 뭐가 필요한지 정리해 드릴게요. 제가 처음에 이것저것 빠뜨려서 두 번 주문했던 기억이 나서 말이에요. ㅎㅎ

    항목 필수 여부 비고
    라즈베리파이 5 (8GB 모델 권장) ✅ 필수 홈랩이라면 8GB로
    공식 전원 어댑터 (27W USB-C PD) ✅ 필수 5세대는 전원 요구사항 달라짐
    microSD 카드 (32GB 이상) 또는 NVMe SSD ✅ 필수 NVMe 강력 추천
    케이스 + 쿨러 권장 발열 관리 필요
    NVMe HAT (M.2 어댑터) 선택 NVMe SSD 쓸 경우 필요
    이더넷 케이블 권장 Wi-Fi보다 유선 안정적

    💡 팁: 라즈베리파이 5는 공식 27W USB-C PD 어댑터를 권장합니다. 전력이 부족하면 부팅 중 경고 메시지가 뜨거나 불안정해질 수 있어요. 저도 처음에 아무 충전기나 꽂았다가 낭패 봤습니다.

    OS 설치 및 초기 설정

    자, 이제 본격적으로 세팅 시작해볼게요. 생각보다 어렵지 않습니다.

    1단계: Raspberry Pi OS 설치

    가장 쉬운 방법은 Raspberry Pi Imager를 사용하는 거예요. 공식 도구라 믿을 수 있고, 설치 전에 SSH 활성화, Wi-Fi 설정, 사용자 계정 설정까지 다 할 수 있거든요.

    1. Raspberry Pi 공식 사이트에서 Raspberry Pi Imager 다운로드
    2. OS 선택: Raspberry Pi OS Lite (64-bit) — 홈서버용이라면 GUI 없는 Lite 버전이 리소스 효율적
    3. 고급 설정(⚙️ 아이콘)에서 SSH 활성화, 사용자명/비밀번호 설정
    4. microSD 또는 NVMe에 Write

    설치 완료 후 첫 부팅, SSH로 접속해서 기본 설정부터 해줍니다.

    # 시스템 업데이트 (항상 첫 번째로 해야 할 일)
    sudo apt update && sudo apt upgrade -y
    
    # 한국 타임존 설정
    sudo timedatectl set-timezone Asia/Seoul
    
    # 호스트명 변경 (나중에 여러 대 운영할 때 헷갈리지 않으려면)
    sudo hostnamectl set-hostname homelab-pi5
    
    # 자동 보안 업데이트 설치
    sudo apt install unattended-upgrades -y
    sudo dpkg-reconfigure --priority=low unattended-upgrades

    2단계: 고정 IP 설정

    홈서버는 IP가 바뀌면 진짜 골치 아파요. 라우터에서 DHCP 예약을 하거나, 직접 고정 IP를 설정해 줍니다. 저는 라우터 DHCP 예약 방식을 선호하는데, 그게 관리하기 편하더라고요.

    직접 설정하고 싶다면 NetworkManager를 씁니다.

    # 현재 연결 이름 확인
    nmcli connection show
    
    # 고정 IP 설정 (예: 192.168.1.100)
    nmcli connection modify "Wired connection 1" \
      ipv4.method manual \
      ipv4.addresses 192.168.1.100/24 \
      ipv4.gateway 192.168.1.1 \
      ipv4.dns "1.1.1.1,8.8.8.8"
    
    # 적용
    nmcli connection up "Wired connection 1"

    3단계: Docker 설치

    홈랩의 핵심은 Docker(도커, 컨테이너 기반 가상화 플랫폼)예요. 여러 서비스를 격리된 환경에서 깔끔하게 관리할 수 있거든요. ARM64 지원이 많이 좋아져서 이제는 대부분의 인기 이미지가 ARM64 빌드를 제공합니다.

    # Docker 공식 설치 스크립트
    curl -fsSL https://get.docker.com -o get-docker.sh
    sudo sh get-docker.sh
    
    # 현재 사용자를 docker 그룹에 추가 (sudo 없이 docker 명령 사용)
    sudo usermod -aG docker $USER
    
    # 변경사항 적용을 위해 재로그인 필요
    newgrp docker
    
    # 설치 확인
    docker --version
    docker run hello-world

    Docker Compose도 함께 설치해 줍니다. 여러 컨테이너를 한 번에 관리할 때 필수예요.

    # Docker Compose V2는 Docker 설치 시 플러그인으로 포함됨
    # 확인
    docker compose version

    Docker 컨테이너로 구성한 홈랩 서비스 스택 — 각 서비스가 독립된 컨테이너로 동작하는 구조입니다.

    핵심 서비스 구축: 실전 Docker Compose 설정

    이제 진짜 재미있는 부분이에요. 어떤 서비스를 돌릴지가 홈랩의 핵심이거든요. 제가 실제로 운영 중인 서비스 스택을 공유해 드릴게요.

    홈랩 필수 서비스 구성

    # ~/homelab/docker-compose.yml
    version: '3.8'
    
    services:
    
      # Portainer: 도커 컨테이너 웹 UI 관리 도구
      portainer:
        image: portainer/portainer-ce:latest
        container_name: portainer
        restart: unless-stopped
        ports:
          - "9000:9000"
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock
          - portainer_data:/data
    
      # Pi-hole: 네트워크 전체 광고 차단 DNS 서버
      pihole:
        image: pihole/pihole:latest
        container_name: pihole
        restart: unless-stopped
        ports:
          - "53:53/tcp"
          - "53:53/udp"
          - "8080:80/tcp"
        environment:
          TZ: 'Asia/Seoul'
          WEBPASSWORD: 'your_secure_password'  # 반드시 변경하세요!
        volumes:
          - pihole_data:/etc/pihole
          - dnsmasq_data:/etc/dnsmasq.d
        cap_add:
          - NET_ADMIN
    
      # Uptime Kuma: 서비스 모니터링 대시보드
      uptime-kuma:
        image: louislam/uptime-kuma:latest
        container_name: uptime-kuma
        restart: unless-stopped
        ports:
          - "3001:3001"
        volumes:
          - uptime_kuma_data:/app/data
    
    volumes:
      portainer_data:
      pihole_data:
      dnsmasq_data:
      uptime_kuma_data:
    # 서비스 시작
    cd ~/homelab
    docker compose up -d
    
    # 실행 상태 확인
    docker compose ps
    
    # 로그 확인
    docker compose logs -f

    🎉 이렇게 하면 세 가지 핵심 서비스가 한 번에 뜹니다. Portainer(포테이너)로 컨테이너를 웹에서 관리하고, Pi-hole(파이홀)로 집 안 모든 기기의 광고를 차단하고, Uptime Kuma(업타임 쿠마)로 서비스 가용성을 모니터링할 수 있어요.

    홈 미디어 서버 추가 (선택)

    미디어 서버도 많이들 구성하시는데, Jellyfin(젤리핀, 오픈소스 미디어 서버)이 ARM64 지원도 잘 되고 무료라서 추천드려요.

    # docker-compose.yml에 추가
      jellyfin:
        image: jellyfin/jellyfin:latest
        container_name: jellyfin
        restart: unless-stopped
        network_mode: host  # DLNA 사용 시 host 모드 권장
        volumes:
          - jellyfin_config:/config
          - jellyfin_cache:/cache
          - /mnt/media:/media:ro  # 미디어 파일 경로
        environment:
          - TZ=Asia/Seoul

    ⚠️ 삽질 경험담: 이것만 주의하세요

    13년 경력이라도 새 장비 세팅할 때는 항상 뭔가 하나씩 걸리더라고요. 제가 겪은 주요 문제들을 공유해 드릴게요.

    문제 1: 발열 관리

    라즈베리파이 5는 이전 세대보다 성능이 오른 만큼 발열도 있어요. 케이스 없이 쓰다가 CPU 쓰로틀링(Throttling, 과열 시 성능 제한)이 걸리는 걸 모니터링으로 발견했습니다.

    # CPU 온도 확인
    vcgencmd measure_temp
    
    # 실시간 모니터링
    watch -n 2 vcgencmd measure_temp
    
    # 쓰로틀링 여부 확인 (0x0이면 정상)
    vcgencmd get_throttled

    액티브 쿨러(팬)를 달거나, 방열판이 포함된 케이스를 사용하는 게 좋아요. 라즈베리파이 공식 액티브 쿨러 제품도 있고, 서드파티 케이스들도 많습니다.

    문제 2: ARM64 이미지 없는 경우

    가끔 원하는 Docker 이미지가 ARM64(aarch64)를 지원 안 하는 경우가 있어요. 이럴 때 확인하는 방법:

    # 이미지 아키텍처 확인
    docker manifest inspect [이미지명] | grep architecture
    
    # 만약 arm64 없으면 대안 이미지 검색 필요
    # 또는 QEMU 에뮬레이션 (성능 저하 있음)
    docker run --platform linux/amd64 [이미지명]

    ⚠️ QEMU 에뮬레이션으로 x86 이미지를 돌리면 성능이 많이 떨어집니다. 가능하면 ARM64 네이티브 이미지를 쓰세요.

    문제 3: microSD 카드 수명 문제

    Docker를 microSD에 올리고 로그를 막 쌓다 보면 카드 수명이 급격히 줄어요. 실제로 저 첫 번째 카드 6개월 만에 날렸습니다. 해결책은 두 가지예요.

    • NVMe SSD로 부팅 드라이브 변경 (가장 좋은 방법)
    • 로그 설정 최적화로 쓰기 횟수 줄이기
    # Docker 로그 크기 제한 설정
    # /etc/docker/daemon.json 생성 또는 수정
    sudo nano /etc/docker/daemon.json
    {
      "log-driver": "json-file",
      "log-opts": {
        "max-size": "10m",
        "max-file": "3"
      }
    }
    # Docker 재시작으로 적용
    sudo systemctl restart docker

    운영 결과 확인: 이렇게 쓰고 있습니다

    세팅 완료 후 실제로 어떻게 돌아가는지 확인해 보는 시간이에요. 드디어 됐다! 싶은 순간이기도 하고요.

    시스템 리소스 모니터링

    # 전체 시스템 상태 한눈에 보기
    htop
    
    # Docker 컨테이너별 리소스 사용량
    docker stats
    
    # 디스크 사용량
    df -h
    
    # 메모리 상세
    free -h

    제 경우 위에 소개한 서비스들을 다 올려도 RAM 사용량이 여유 있더라고요. 8GB 모델이라면 훨씬 더 여유롭게 쓸 수 있어요.

    Uptime Kuma 모니터링 대시보드 — 홈랩의 모든 서비스 상태를 한눈에 확인할 수 있습니다.

    자동 시작 설정

    정전이나 재부팅 후에도 서비스가 자동으로 올라오도록 설정해 줍니다.

    # Docker 서비스 자동 시작
    sudo systemctl enable docker
    
    # docker-compose를 systemd 서비스로 등록
    sudo nano /etc/systemd/system/homelab.service
    [Unit]
    Description=Homelab Docker Compose
    Requires=docker.service
    After=docker.service
    
    [Service]
    Type=oneshot
    RemainAfterExit=yes
    WorkingDirectory=/home/pi/homelab
    ExecStart=/usr/bin/docker compose up -d
    ExecStop=/usr/bin/docker compose down
    TimeoutStartSec=0
    
    [Install]
    WantedBy=multi-user.target
    # 서비스 등록 및 활성화
    sudo systemctl daemon-reload
    sudo systemctl enable homelab.service
    sudo systemctl start homelab.service

    다음 단계로 확장하기

    기본 세팅이 끝났다면 이제 더 재미있는 것들을 추가할 수 있어요. 제가 다음 글에서 다룰 예정인 주제들이기도 합니다.

    추천 확장 서비스 목록

    서비스 용도 ARM64 지원
    Nginx Proxy Manager 리버스 프록시, SSL 인증서 관리 ✅
    Grafana + Prometheus 메트릭 수집 및 시각화 대시보드 ✅
    Home Assistant 스마트홈 자동화 허브 ✅
    Vaultwarden 자체 호스팅 비밀번호 관리자 ✅
    Nextcloud 개인 클라우드 스토리지 ✅
    WireGuard VPN 서버 ✅

    💡 WireGuard(와이어가드, 경량 VPN 프로토콜)를 설정해 두면 외출 중에도 집 홈랩에 안전하게 접속할 수 있어요. 이건 다음 글에서 자세히 다루겠습니다.

    라즈베리파이 5 홈랩에서 활용 가능한 서비스 비교 — 용도에 맞게 골라서 구성해 보세요.

    자주 묻는 질문 (FAQ)

    Q. 라즈베리파이 5 홈랩, 24시간 켜놔도 되나요?

    네, 됩니다. 저도 항상 켜놓고 있어요. 다만 발열 관리(케이스 + 쿨러)와 안정적인 전원 공급이 중요합니다. UPS(무정전 전원 장치)까지 달면 더욱 안정적이에요.

    Q. microSD vs NVMe SSD, 어떤 게 낫나요?

    홈랩 용도라면 NVMe SSD를 강력히 추천드려요. 속도도 빠르고 수명도 훨씬 길거든요. 처음 세팅 비용이 조금 더 들지만, microSD 갈아 엎는 수고를 생각하면 훨씬 이득입니다.

    Q. 라즈베리파이 5 8GB vs 4GB, 뭐가 더 나을까요?

    홈랩 목적이라면 8GB를 권장합니다. Docker 컨테이너 여러 개 올리다 보면 4GB는 빠듯해질 수 있어요. 처음부터 8GB로 가는 게 나중에 후회가 없더라고요.

    마무리: 작게 시작해서 크게 배웁니다

    라즈베리파이 5 홈랩, 생각보다 어렵지 않죠? 처음엔 “이게 진짜 되겠어?” 싶었는데, 막상 세팅하고 나면 진짜 신세계가 열려요.

    제가 13년 동안 인프라 엔지니어로 일하면서 느낀 건, 홈랩이야말로 가장 빠르게 실력이 느는 방법이라는 거예요. 회사 서버는 함부로 건드릴 수 없으니까요. 집에서 마음껏 실험하고, 망가뜨려 보고, 복구해 보는 과정에서 진짜 실력이 쌓입니다.

    오늘 다룬 내용을 정리하면:

    • ✅ 라즈베리파이 5의 하드웨어 특성과 홈랩 적합성 이해
    • ✅ OS 설치 및 기본 시스템 설정
    • ✅ Docker 기반 서비스 스택 구성 (Portainer, Pi-hole, Uptime Kuma)
    • ✅ 발열, ARM64 호환성, 스토리지 수명 등 주요 이슈 해결
    • ✅ 시스템 안정성을 위한 자동 시작 설정

    다음 글에서는 Nginx Proxy Manager와 Let’s Encrypt를 활용한 HTTPS 설정을 다룰 예정이에요. 외부에서 홈랩 서비스에 안전하게 접속하는 방법인데, 이게 또 재미있거든요. 기대해 주세요! 😄

    궁금한 점이나 다른 삽질 경험이 있으시면 댓글로 공유해 주세요. 같이 고민해 봐요!