홈랩에서 Docker Compose 사용: 구성, 프로필 및 모범 사례

인포매텍 디지털 » Recursos » 홈랩에서 Docker Compose 사용: 구성, 프로필 및 모범 사례

컨테이너를 활용해 현대적인 홈랩을 구축하는 것은 많은 IT 전문가들 사이에서 인기 있는 취미가 되었습니다. Docker Compose는 거의 항상 그러한 설정의 핵심에 있습니다.YAML 형식으로 서비스를 정의하고 Git으로 버전을 관리하면 단 하나의 명령으로 전체 환경을 시작할 수 있습니다.

이제 성장하기 시작하면 여러 가지 일이 생깁니다. 화분이 두세 개에서 시작해서 점점 늘어나게 되죠. 수십 개의 서비스, 내부 네트워크, 리버스 프록시, 데이터베이스 및 CI 실행기바로 이때 중요한 질문이 떠오릅니다. 하나의 거대한 Docker Compose 파일로 관리할 것인가, 아니면 여러 개의 작은 파일로 관리할 것인가? 프로필, 네트워크, 백업, 보안을 어떻게 구성하고, 더 나아가 마이그레이션을 쉽게 만들 수 있을까?

실제 환경에서 홈랩을 구축하기 위한 Docker Compose 설정 방법

실제로 홈랩을 오랫동안 사용해 온 사람들은 일반적으로 각각 장단점이 있는 세 가지 Compose 조직 모델 내에서 운영합니다. 머신을 확장하거나 마이그레이션할 때 올바른 접근 방식을 선택하면 많은 어려움을 피할 수 있습니다..

한쪽에는 먼저 시작한 사람이 있습니다. Docker Run은 처음에는 자유로운 형태로 시작되었고, 그 후 Portainer로 옮겨갔으며, 최종적으로 Docker Compose로 발전했습니다.전형적인 사례입니다. Portainer는 뛰어난 가시성, 사용자 친화적인 인터페이스, 템플릿 등을 제공하지만, 결국 파일에 아무것도 없으면 복잡한 매개변수를 편집하거나 구성을 마이그레이션하는 것이 번거로워집니다.

정반대 극단에는 다음과 같은 사람들이 있습니다. 모든 것을 하나의 "메가" docker-compose.yml 파일로 통합했습니다. 리버스 프록시, 미디어, 유틸리티, 모니터링, LLM, 데이터베이스 등 홈랩에 필요한 모든 서비스를 단일 스택에서 실행할 수 있습니다.

그 중간 단계에서 많은 사용자는 혼합 방식을 선택합니다. 컨텍스트별로 그룹화된 여러 개의 작은 docker-compose.yml 파일 (예를 들어 미디어, 인프라, 생산성, 모니터링) 모두 동일한 저장소에 있으며 일반적으로 전역 환경 변수를 공유합니다.

상당히 우아한 해결책은 두 가지 장점을 결합합니다. 다른 파일들을 포함하는 루트 docker-compose 파일 (각각의 앱 또는 서비스 하위 폴더에 저장). 이렇게 하면 홈랩 전체를 한눈에 파악할 수 있으면서도 읽기 어려운 수천 줄짜리 YAML 파일을 일일이 살펴볼 필요가 없습니다.

프로필, 기능별 그룹화 및 대규모 홈랩

홈랩이 거의 완성 단계에 가까워지면 30회, 40회 또는 50회 서비스 (데이터베이스, 캐시, 인덱서와 같은 백업 서비스를 포함하여) 이러한 것들을 체계화하는 것이 매우 중요합니다. 바로 이 지점에서 두 가지 모두가 기능별 그룹화 의 사용과 같은 Docker Compose 프로필.

가장 흔한 패턴은 모든 것을 하나의 Compose "프로젝트"로 묶되, 프로필별로 논리적으로 구분하는 것입니다. 예를 들면 다음과 같습니다.

• 핵심 프로필홈랩 코어는 Traefik을 리버스 프록시로 사용하고, ID 공급자(예: OAuth 또는 Authentik)를 통해 동일 도메인 내의 모든 앱을 HTTPS로 인증합니다.
• 미디어 프로필Plex, Sonarr, Radarr, Ombi, SABnzbd 또는 qBittorrent와 같은 서비스는 멀티미디어 콘텐츠를 선별, 다운로드 및 제공하는 역할을 합니다.
• 유틸리티 프로필컨테이너 및 업데이트를 관리하고 모니터링하기 위한 Portainer, Watchtower(사용하는 경우), Diun, dockcheck 또는 이와 유사한 도구.
• 인프라/모니터링 프로필Traefik, cAdvisor, Prometheus, Grafana, Uptime Kuma, Dozzle 등 모니터링 및 로깅 관련 모든 도구.
• 실험 프로필 또는 LLM: LLM 또는 특이한 앱(ChatGPT Next Web local, LibreOffice Online 등)에 대한 특정 스택으로, 일반적으로 기본적으로 비활성화되어 있습니다.

프로필의 매력은 바로 이것입니다. 인프라의 일부만 실행할 수 있습니다. 필요에 따라 선택할 수 있습니다. 예를 들어, 저전력 미니 PC에서는 코어 및 인프라 프로필만 실행하고, 디스크와 GPU가 더 많은 대형 서버에서는 미디어 프로필만 실행할 수 있습니다.

잘 설계된 저장소에는 일반적으로 다음과 같은 특징이 있습니다. docker-compose.yml 파일의 "master" 설정은 apps/ 또는 services/ 폴더 내의 개별 파일에 대한 include를 가져옵니다.또한 거의 모든 서비스는 단일 파일을 통해 구성됩니다. .env 파일은 전역 변수이고, secrets/ 디렉터리에는 몇 가지 비밀 정보가 있습니다.이는 초기 설정을 크게 간소화합니다.

이러한 패턴을 따르면 홈랩 관리는 기본적으로 다음과 같이 요약됩니다. .env 파일과 비밀 키를 편집하고, 프로필을 활성화 또는 비활성화하고, 각 호스트에서 시작할 서비스를 결정합니다.여러 대의 컴퓨터에 동일한 애플리케이션 세트를 배포하려는 경우에 이상적입니다.

하나의 거대한 docker-compose 파일 vs. 여러 개의 작은 파일

이것은 영원한 논쟁입니다: 모든 것을 포함하는 단일 docker-compose.yml 파일을 사용하나요, 아니면 서비스/스택별로 여러 개의 파일을 사용하나요? 실제 답은 대개 "마이그레이션의 단순성을 우선시하느냐, 아니면 서비스별 명확성을 우선시하느냐에 따라 다릅니다."입니다.

누가 옹호하는가 단일 마스터 파일 일반적으로 다음과 같은 몇 가지 장점을 강조합니다.

• 호스트 마이그레이션은 매우 쉽습니다.저장소를 복제하고, .env 파일과 비밀 키를 복사하고, 볼륨을 마운트한 다음 `docker compose up -d`를 실행하면 됩니다. 디렉토리별로 이동할 필요가 없습니다.
• 진실의 코드로서의 인프라홈랩의 전체 토폴로지(서비스, 네트워크, 볼륨, 종속성)가 한 곳에 있습니다.
• 중앙 집중식 업데이트이미지 버전, 재부팅 정책 또는 로깅을 변경할 때 정확히 어디를 수정해야 하는지 알 수 있습니다.

하지만 분명한 단점도 있습니다. 방대한 YAML 파일은 유지 관리가 더 어렵습니다. 병합 충돌이 증가합니다 특정 문제를 디버깅할 때, 수백 줄에 달하는 방대한 코드를 헤쳐나가야 하는 상황에 놓이게 됩니다. 코드가 너무 방대해지면 약간의 후회를 느끼는 것도 드문 일이 아닙니다.

다른 접근 방식은 다음과 같습니다. 앱 또는 논리적 스택당 하나의 docker-compose.yml 파일이 필요합니다.다음과 같은 구조 내에서:

docker/
├── bookstack/
│   └── docker-compose.yml
├── dashy/
│   └── docker-compose.yml
└── traefik/
    └── docker-compose.yml

이렇게 하면 각 컨테이너는 다음과 같은 이름으로 불립니다. 북스택 앱-1 o 트라에픽-리버스-프록시-1이를 통해 문제를 신속하게 찾아낼 수 있습니다. bookstack-app-1 컨테이너가 충돌하는 경우, 어떤 폴더를 확인해야 하는지 정확히 알 수 있습니다.

시각적으로 훨씬 더 깔끔합니다. 이를 통해 각 서비스를 독립적으로 관리할 수 있습니다. (나머지 부분에 영향을 주지 않고 시작, 중지 또는 업데이트할 수 있습니다.) 또한 Dozzle과 같은 애플리케이션은 로그를 더 잘 정리하기 위해 별도의 스택을 활용합니다.

절충안은 모든 것을 너무 분리하면 Traefik이나 공유 네트워크와 같은 공통 서비스 간의 조정에 더 많은 주의를 기울여야 합니다.외부 네트워크는 반드시 선언해야 하며, 특정 Traefik 레이블을 사용해야 하고, 다른 docker-compose에서 생성한 네트워크의 명명법을 기억해야 합니다.

.env 파일, 오버라이드 및 버전 관리에 대한 모범 사례

가장 과소평가된 비법 중 하나는 .env 파일에 설정을 중앙 집중화합니다.docker-compose.yml 파일에 환경 변수를 잔뜩 넣는 대신, 다음과 같이 정의하면 됩니다.

DB_USERNAME=myuser
DB_PASSWORD=secretpassword

그리고 YAML 파일에서는 다음과 같이 참조됩니다. ${DB_USERNAME} o ${DB_PASSWORD}이렇게 하면 작성 내용을 한눈에 읽을 수 있으므로 다음과 같은 이점을 누릴 수 있습니다. 여러 서비스에서 변수를 공유합니다. 무엇보다 중요한 것은 비밀번호를 별도의 파일에 저장하여 Git에서 제외할 수 있도록 하는 것입니다.

다양한 환경(운영, 테스트, 개발)에서 매우 유용합니다. docker-compose.override.yml을 활용하세요기본 docker-compose.yml 파일을 만들고, 오버라이드 부분에서 포트, 경로, 디버그 플래그 등 변경된 부분만 덮어쓰는 것이 핵심입니다.

예를 들어, 개발 환경에서 오버라이드를 로드할 수 있습니다. 다른 포트를 노출하고, 디버그 모드를 활성화한 다음, 로컬 소스 코드를 마운트합니다.메인 YAML 파일은 건드리지 않고, 실행 환경에 맞게 스택을 조정합니다.

분명히 제대로 된 홈랩을 구축하려면 Git을 사용하여 모든 것을 버전 관리하는 것은 필수입니다.보통 다음과 같은 내용이 있습니다.

homelab-docker/
├── docker-compose.yml
├── .env.example
├── services/
│   ├── media/
│   ├── infra/
│   └── ...
└── scripts/

그 다음에는 저장소를 초기화하고, 인프라 변경 사항을 커밋하고, 문제가 발생하면 해결하면 됩니다. 작성 중인 내용을 이전 버전으로 되돌리는 데 몇 초밖에 걸리지 않습니다.조금 야심찬 홈랩 구축을 고려하는 사람들에게는, 이것은 선택 사항이 아니라, 미쳐버리는 것을 피할 수 있는 유일한 방법입니다.

네트워크, Traefik 및 보안 서비스 노출

거의 모든 중급 수준 홈랩에서 동일한 조합이 나타납니다. Traefik을 리버스 프록시 및 중앙 집중식 ID 공급자(Auth 또는 Authentik)로 사용이를 통해 HTTPS 및 SSO를 사용하여 여러 앱을 서브도메인 아래에 노출할 수 있습니다.

대표적인 패턴은 예를 들어 전용 Docker 네트워크를 설정하는 것입니다. 리버스프록시 또는 이와 유사한 방식으로 Traefik과 외부에서 제공할 모든 웹 서비스가 연결됩니다. 나머지 컨테이너(데이터베이스, 캐시 등)는 격리된 내부 네트워크에 유지됩니다.

Traefik을 사용하고 서비스를 각각 다른 docker-compose 파일로 분리하는 경우 다음이 필요합니다. 공유 외부 네트워크를 정의합니다.뭐 그런 거죠:

services:
  bookstack:
    image: lscr.io/linuxserver/bookstack
    networks:
      - traefik-net
    labels:
      - "traefik.docker.network=traefik_default"

networks:
  traefik-net:
    name: traefik_default
    external: true

여기서 traefik_default 네트워크는 Traefik 스택에 의해 생성되고, 다른 서비스들은 traefik-net이라는 외부 네트워크를 통해 추가됩니다. 태그는 Traefik에게... 트래픽을 라우팅하는 데 어떤 네트워크를 사용해야 할까요?.

단일 스택에 백엔드 서비스(예: 웹 컨테이너 및 데이터베이스)가 포함된 경우 다음과 같은 작업을 수행할 수 있습니다. 공유 기본 네트워크에 연결하고 웹 컨테이너에만 Traefik 네트워크에 대한 액세스 권한을 부여하십시오.데이터베이스에는 Traefik.enable=false라는 레이블이 추가되어 Traefik이 해당 항목을 무시하게 됩니다.

이러한 구성 방식은 두 가지 주요 이점을 제공합니다. 서비스 간 격리 및 통제된 노출Traefik 레이블로 표시하고 프록시 네트워크에 있는 컨테이너만 외부에서 접근할 수 있습니다.

데이터 영속성, 볼륨 및 디스크 구조

영구 데이터가 없는 홈랩은 그다지 유용하지 않습니다. 데이터베이스, 설정 파일, 미디어, 문서 등 모든 것이 Docker Compose가 종료되더라도 유지되어야 합니다. 단행본과 제본된 책들은 당신의 생명 보험입니다..

많은 사람들이 다음과 같은 구조를 이용하여 수납공간을 정리합니다.

/mnt/storage/
├── downloads/
│   ├── movies/
│   └── tv/
├── media/
│   ├── movies/
│   ├── tv/
│   └── music/
└── srv/
    └── 

아이디어는 다운로더(qBittorrent, SABnzbd 등)는 다운로드 폴더만 볼 수 있습니다.Radarr/Sonarr 같은 파일 관리 프로그램은 다운로드 파일과 미디어 파일 모두에 접근하여 하드 링크를 이동/생성할 수 있지만, Plex나 Jellyfin 같은 서버는 미디어 폴더만 볼 수 있습니다.

이렇게 하면 원칙을 적용할 수 있습니다. 최소한의 특권각 컨테이너는 실제로 필요한 데이터에만 접근합니다. 이러한 명확한 분리는 클라우드 또는 외장 드라이브에 백업할 볼륨이나 경로를 결정할 때도 도움이 됩니다.

srv 디렉터리는 일반적으로 애플리케이션 구성(예: /srv/jellyfin/config, /srv/traefik, /srv/paperless 등)을 저장하는 데 사용됩니다. 일반적으로 템플릿, Caddyfile 등은 부분적으로 버전 관리되지만, 중요하거나 리소스 집약적인 파일은 제외됩니다.

어떤 경우에는 사용하는 것이 흥미로울 수 있습니다. 하드 링크 다운로드 과정에서 Radarr나 Sonarr 같은 서비스는 다운로드한 파일을 연결하여 디스크 공간을 중복 사용하지 않고도 시딩을 유지할 수 있습니다. TRaSHGuides 같은 가이드에서 제안하는 디렉토리 구조는 바로 이러한 원리를 기반으로 합니다.

GitHub Actions와 로컬 러너를 사용하여 배포 자동화

더 나은 결과를 원하신다면, 한 단계 더 나아가실 수 있습니다. CI/CD를 사용하여 홈랩 업데이트를 자동화하세요여러 사용자가 Jenkins 및 유사 도구를 GitHub Actions와 자체 호스팅 러너를 사용하는 워크플로로 대체하여 홈랩에서 활용하고 있습니다.

메커니즘은 간단합니다. 홈랩 저장소의 메인 브랜치에 푸시할 때마다, GitHub Actions 워크플로가 시작되어 테스트와 린터를 실행하고, 모든 것이 순조롭게 진행되면 변경 사항을 서버에 배포합니다..

일반적인 워크플로는 다음과 같은 단계를 포함합니다.

• Gitleaks 유형의 비밀 스캐너혹시 실수로 비밀번호나 토큰을 저장소에 업로드했을 경우를 대비한 것입니다.
• 보풀 읽기 쉽고 일관된 형식을 유지하기 위해 YAML 또는 인프라 코드를 사용합니다.
• 홈랩 내 저장소 업데이트대상 서버에서 `git pull`을 실행합니다.
• 컨테이너의 제어된 재구성기존 프로세스를 중지하고 새 프로세스를 시작한 다음 상태를 확인합니다.

장점: 보안 강화(비밀 정보 유출 방지), 코드 품질 향상 한 번의 푸시로 반복 가능한 배포로컬 실행기를 사용하고 있으므로 이미지와 볼륨은 네트워크를 벗어나지 않습니다. GitHub 인터페이스를 사용하여 파이프라인을 시각화하는 것뿐입니다.

Docker Compose가 홈랩 운영을 훨씬 편리하게 만들어주는 이유

많은 사람들이 수년간 의존해 왔습니다. Docker Run 및 Portainer 사고나 마이그레이션으로 인해 접근 방식을 재평가해야 할 때까지는 그렇습니다. 호스트를 잃거나 서비스를 다른 시스템으로 옮겨야 할 때, Portainer에서 개별 명령이나 설정에만 의존하는 것은 함정입니다..

Compose로 전환했을 때 가장 큰 차이점은 다음과 같습니다. 서비스 정의 전체가 텍스트로 변환됩니다.볼륨, 포트, 네트워크, 레이블, 변수… 이 모든 것을 복사, 공유, 버전 관리 및 재사용이 가능한 YAML 파일에 담았습니다.

서비스 편집은 더 이상 "컨테이너를 수동으로 재구축하는 것"이 ​​아니며, 이제는 다음과 같습니다. 파일의 한 줄을 수정하고 저장한 다음 `docker compose up -d` 명령을 실행합니다.원래 명령어를 기억할 필요도 없고, 여러 Portainer 화면을 클릭할 필요도 없습니다.

또한, 여러 대의 서버(미니 PC, NAS, 데스크톱)를 사용하는 경우, 이러한 기능을 활용할 수 있다면 매우 편리합니다. 동일한 compose 파일을 다른 컴퓨터로 복사하고, 네 개의 경로를 조정한 다음, 다른 하드웨어에서 동일한 스택을 실행합니다.실제로 많은 사람들이 데이터 손실이나 혼란스러운 마이그레이션과 관련된 문제를 겪은 후 Compose 덕분에 이후 유사한 상황에서 많은 시간을 절약할 수 있었다고 인정합니다.

추가적인 이점으로, 기존 서비스를 기반으로 새로운 서비스를 만드는 것이 매우 간단해집니다. 예를 들어, Plex 설정을 복제하여 Jellyfin을 마운트합니다. YAML 블록을 복사하는 방식으로 동일한 미디어 경로와 트랜스코딩 장치를 재사용하는 데는 몇 분밖에 걸리지 않습니다.

최적화: 빌드 컨텍스트, 다단계 빌드 및 리소스

홈랩 컨테이너는 대부분 공개 이미지를 사용하지만, 경우에 따라서는 직접 이미지를 컴파일해야 할 수도 있습니다. 이러한 경우에는 주의해야 할 점이 있습니다. 빌드 컨텍스트전체 저장소를 필터링 없이 보내지 말고, 프로젝트 폴더만 (적절한 .dockerignore 파일을 사용하여) 보내면 빌드 속도가 빠르고 가볍습니다.

또 다른 매우 유용한 기법은 다음과 같은 방법을 사용하는 것입니다. 다단계 빌드 Dockerfile에서 첫 번째 단계에서는 종속성을 설치하고 컴파일하고, 두 번째 단계에서는 필요한 아티팩트만 작은 기본 이미지에 복사합니다. 결과적으로 최종 이미지를 얻게 됩니다. 훨씬 작고 안전합니다툴체인이나 추가 라이브러리를 이전하지 않기 때문입니다.

작성 측면에서는 다음과 같은 옵션을 정의할 수 있습니다. CPU 및 RAM 제한 (특히 Swarm 환경이나 Docker가 이러한 매개변수를 준수하는 경우) 리소스를 많이 사용하는 앱이 리소스를 독점하는 것을 방지하기 위해서입니다. 홈랩 환경에서는 잘못 구성된 서비스가 시스템의 나머지 부분을 마비시키는 것을 막는 데 도움이 됩니다.

잊지 마세요 재시작 정책 (재시작: 항상, 중지되지 않을 때, 장애 발생 시): 이러한 설정을 통해 재부팅 또는 일회성 장애 발생 후 중요 서비스(리버스 프록시, VPN, 주요 데이터베이스)가 자동으로 재시작되도록 할 수 있습니다.

마지막으로, 다음과 같은 명령어를 사용하여 정기적인 청소 작업을 예약하는 것이 좋습니다. 도커 이미지 정리, 도커 컨테이너 정리 및 도커 볼륨 정리 이전 빌드의 잔여물, 중지된 컨테이너 또는 사용되지 않는 볼륨을 제거하여 디스크 공간을 확보합니다.

의료 서비스, 기록 및 모니터링

홈랩이 블랙박스가 되지 않도록 하려면 다음 세 가지 핵심 사항에 집중하는 것이 중요합니다. 건강 검진, 통제된 로깅 및 모니터링Docker Compose를 사용하면 서비스별로 (curl -f http://localhost와 같은 명령이나 특정 스크립트를 사용하여) 컨테이너의 상태를 확인하는 상태 점검을 선언할 수 있습니다.

이렇게 하면 다음과 같이 만들 수 있습니다. "정상" 컨테이너만 트래픽을 수신합니다. (예를 들어 Traefik을 통해) 서버가 응답하지 않을 경우 구성된 정책에 따라 재시작되도록 합니다. 이를 통해 최소한의 노력으로 복원력을 크게 향상시킬 수 있습니다.

로그와 관련하여 드라이버 JSON 파일의 제한 사항을 조정하십시오. 최대 크기 및 최대 파일 이렇게 하면 디스크 공간이 수 기가바이트에 달하는 잊혀진 로그 파일로 가득 차는 것을 방지할 수 있습니다. Dozzle과 같은 웹 도구를 사용하면 브라우저에서 모든 컨테이너의 로그를 탐색할 수 있으므로 특정 서비스를 디버깅하는 데 매우 편리합니다.

지표 및 지속적인 모니터링과 관련하여, 일반적인 조합은 다음과 같습니다. cAdvisor + 프로메테우스 + 그라파나cAdvisor는 컨테이너별 CPU, 메모리, 디스크 및 네트워크 사용량 통계를 제공하고, Prometheus는 이를 주기적으로 수집하며, Grafana는 보기 좋은 대시보드에 표시하고 사용량이 급증할 경우 알림을 보냅니다.

잘 구성된 홈랩에는 일반적으로 다음이 포함됩니다. 가용성 확인을 위한 Kuma 가동 시간 (HTTP, ICMP, TCP 등) 프로토콜을 사용하고, Duplicati와 같은 자동 백업 시스템을 통해 중요한 데이터를 다른 디스크나 클라우드에 복사합니다. 이렇게 하면 데이터 손실을 방지하고, 문제가 발생하더라도 중요한 데이터를 잃지 않을 수 있습니다.

홈랩의 보안 및 원격 접속

아무리 직접 만든 장치라 하더라도 안전은 선택 사항이 아닙니다. 많은 사람들이 선택합니다. NAS 또는 NAS의 서비스를 외부 세계에 직접 노출하지 마십시오.VPN을 통한 원격 액세스 제한 (WireGuard는 성능과 간편성 덕분에 매우 인기 있는 옵션입니다).

이 모델에서 라우터는 게이트웨이 역할을 합니다. VPN 서버에 대해 임의의 포트 하나만 열리고, 연결되면, 내부 서비스에 대한 모든 요청은 암호화된 터널을 통해 전달됩니다.Traefik이나 앱 모두 사전 필터 없이는 인터넷에 노출되지 않습니다.

VPN을 직접 관리하고 싶지 않은 사람들은 때때로 다른 방법을 사용합니다. 클라우드플레어 터널 또는 테일스케일 포트를 열지 않고 홈랩에 접속할 수 있습니다. 이러한 방법들은 편리한 대안이지만, 개인정보 보호가 최우선이라면 제3자가 어떤 메타데이터를 수집할지 고려해야 합니다.

또 다른 좋은 습관은 서버 및 NAS 디스크를 암호화합니다.정기적으로 패치를 적용하고 자동 업데이트는 제한하세요(많은 사용자가 Watchtower 대신 수동으로 업데이트를 제어합니다). 업데이트 확인도 하지 않고 홈랩 시스템의 절반을 망가뜨리는 것보다는 약간 뒤처지더라도 업데이트를 제어하는 ​​것이 훨씬 낫습니다.

보시다시피, "엔터프라이즈" 수준에 도달할 필요는 없습니다. 네, 최소한의 안전 및 규율 기준을 마련하는 것이 바람직합니다. 홈랩이 보안에 취약하거나 끊임없이 문제를 일으키는 곳이 되지 않도록 하기 위함입니다.

결론적으로, Docker Compose를 사용하여 제대로 된 홈랩을 구축하는 것은 체계성, 상식, 그리고 실험 정신의 조합입니다. 서비스를 그룹화하고, 네트워크를 잘 정의하고, Git에 문서를 기록하고, 약간의 자동화를 적용하면 단 하나의 명령으로 시작할 수 있고, 다른 머신으로 쉽게 마이그레이션할 수 있으며, 통제 불가능한 정글처럼 되지 않고 조금씩 확장할 수 있는 환경을 만들 수 있습니다.