내가 어떤 서버에서든 무슨 일이 있어도 먼저 설치하는 6가지 Docker 컨테이너/패키지
제가 처음 Docker를 설정했을 때, 먼저 Portainer를 설치했는데, 그 깔끔한 웹 인터페이스 때문에 제가 이미 프로덕션-ready 서버를 가진 줄 알았습니다. 그러나 그 이후 깨진 컨테이너를 고치기 위해 정신없이 구글링을 하면서 현실로 돌아오게 되었습니다. 저는 기초 없이 지붕부터 지었던 셈입니다.
다행히도, 여러 해 동안 서버를 프로비저닝한 경험 덕분에 나의 접근 방식을 다듬을 수 있었습니다. 이제는 여섯 개의 컨테이너를 무엇보다 먼저 새 설치에 올려놓습니다. 이들은 자동 업데이트, 리버스 프록시, 모니터링, 로깅, 비밀번호 관리, GUI를 다룹니다. 이들은 Docker를 시작하는 누구에게나 내가 가장 추천하는 것입니다. 이러한 순서로 설치하면 SSL 인증서 문제, 손상된 데이터베이스, 눈에 보이지 않는 로그 파일 문제를 피할 수 있습니다.
감시탑
내가 처음으로 자동화하는 것은 유지보수이다
컨테이너가 커질수록 관리하기 어려워지고 보안 패치가 뒤처질 때 이를 놓치기 쉽습니다. 이것은 여러분의 설정에 대한 가장 큰 위험 중 하나입니다. Watchtower가 영구적인 해결책입니다.
Watchtower는 실행 중인 컨테이너를 모니터링하고, 업데이트된 이미지를 확인하며, 새 버전이 사용 가능해지면 정확한 구성으로 다시 시작하는 등 원래 수동으로 수행해야 하는 프로세스를 자동화합니다. 다른 컨테이너보다 먼저 Watchtower를 설정하는 것이 중요하며, 이를 통해 이후에 배포된 모든 컨테이너를 모니터링할 수 있습니다. 이 도구는 지속적인 유지 관리 부담을 제거합니다.
제가 사용할 때는 데이터베이스가 건드려지지 않도록 컨테이너의 compose 파일에 이 라벨을 추가합니다.
labels:
- "com.centurylinklabs.watchtower.enable=false"이 라벨은 Watchtower가 데이터베이스 재시작을 건너뛰도록 합니다. 특히 쓰기 중간에 데이터베이스를 재시작하면 데이터베이스 손상과 영구적인 데이터 손실이 발생할 수 있습니다.
캐디
필요하기 전에 HTTPS 해결하기
인증서는 집 밖에서 서비스를 이용해야 할 경우 매우 중요합니다. 하지만 인증서를 수동으로 설정하는 것은 스트레스를 유발하며, 갱신 타이머뿐만 아니라 도메인을 지정하는 데 필요한 DNS 및 서버 구성도 필요합니다.
Caddy는 전체 인증서 프로세스를 자동화하기 위한 매우 간단한 솔루션입니다. Certbot, 크론 작업 또는 수동 갱신 없이 HTTPS를 자동으로 처리합니다. 또한 내가 아무것도 찾아볼 필요가 없는 간단한 구성 구문을 가지고 있습니다. 새로운 서비스에 대한 작동 항목은 일반적으로 두 줄을 넘지 않습니다.
Caddy보다 더 강력한 리버스 프록시가 있지만, 이러한 옵션은 일반적으로 더 많은 설정 시간이 필요합니다. 추가적인 복잡성 없이 라벨 기반 라우팅 기능을 포함하려면 caddy-docker-proxy 플러그인을 사용할 수도 있습니다.
일부 사용 사례에서는 Caddy보다 Traefik을 선호하지만, 현실적으로 대부분의 가정 환경이나 개인 서버에는 과도한 경우가 많습니다.
이 컨테이너가 두 번째로 오는 이유는 단순히 그 시점부터 설정에 추가된 다른 모든 컨테이너에 대해 깨끗하고 안전한 접근을 보장하기 때문입니다.
넷데이터
"정상"이 무엇인지 규정하기
제가 홈랩을 시작했을 때, 모니터링 도구를 설치하기 전에 문제가 생기길 기다렸습니다. 돌이켜보면, 건강한 설정이 어떤 모습인지 모른다면 무엇이 잘못되었는지 인식하는 것은 거의 불가능하다는 것을 압니다.
이것이 제가 Netdata를 설정한 세 번째 컨테이너인 이유입니다. Netdata는 CPU와 메모리 사용량, 디스크 활동, 네트워크 처리량 및 컨테이너별 지표를 표시하여 제 설정을 조기에 파악할 수 있게 해줍니다. 가장 좋은 점은 이 도구를 사용하기 전에 구성 파일에 몇 시간을 소비할 필요가 없다는 것입니다.
Netdata는 기준선을 제공합니다. 예를 들어, 정상적인 메모리 사용량이 무엇인지 알고 있었기 때문에 새로운 서비스를 설정에 추가하고 메모리 사용량이 급증하는 것을 보았을 때, 즉시 문제가 무엇인지, 무엇이 이를 유발했는지, 그리고 추가된 오버헤드가 무엇인지 알 수 있었습니다.
두즐
증상을 설명하는 동반 도구
Netdata로는 문제가 언제 발생했는지 알 수 있고, 이유를 이해하기 위해 Dozzle를 사용하므로 Netdata 다음에 설치합니다.
Dozzle 없이 나는 문제를 추적하기 위해 docker logs 명령어를 실행했지만, 터미널 출력이 뒤죽박죽인 화면만 반환되었습니다. 또한 동시에 여러 컨테이너에서 로그를 스트리밍할 때도 화면이 혼란스러웠습니다.
Dozzle은 이러한 혼란을 로그를 보는 간단한 브라우저 기반 인터페이스로 대체했습니다. 반복적으로 명령어를 실행하여 로그를 보는 대신, 이제 컨테이너별로 검색하고 필터링하며 새로운 로그 항목을 실시간으로 관찰합니다.
저는 재시작 모드에 갇힌 컨테이너를 만난 적이 있습니다. Netdata를 사용하면 컨테이너가 사라졌다가 다시 시작되는 것을 볼 수 있습니다. Dozzle은 왜 그런 일이 발생하는지 보여주어 명확성을 제공합니다.
볼트워든
자격 증명이 존재하기 전에 금고 설정하기
이 시점까지는 서버가 관리 가능한 것처럼 느껴지지만, 곧 그렇게 유지되지 않을 것입니다. 당신은 애플리케이션, 웹 도구 및 서비스에 로그인하게 될 것입니다. 하나의 데이터베이스 비밀번호에서 관리자 비밀번호까지, 목록은 점점 늘어나고, 금세 20개의 비밀번호, API 키, 서비스 토큰, 자격 증명을 관리하게 됩니다. 이들이 메모 앱, 브라우저 비밀번호 관리자, 텍스트 파일에 흩어져 있을 때는 혼란스럽습니다.
그래서 Vaultwarden은 모든 서버에 설치됩니다. 이는 Bitwarden의 경량 구현체이기 때문입니다. 모든 자격 증명을 한 곳에 모아줍니다. 새로운 서비스를 호스팅할 때, 이제 먼저 Vaultwarden을 열고 자격 증명을 생성 및 저장한 다음 배포를 완료합니다.
Vaultwarden은 처음에 설정해야 할 컨테이너 중 하나여야 합니다. 다섯 개의 비밀번호를 정리하는 것이 쉰 개를 재구성하는 것보다 쉽기 때문입니다.
포테이너 CE
GUI는 이제 마지막에 나옵니다
과거에 나는 Portainer를 설정하는 것으로 시작했습니다. 그래픽 사용자 인터페이스가 있으면 직관적으로 느껴지며, 특히 명령줄 사용에 익숙하지 않은 경우에 그렇습니다. 그러나 그것은 관리 계층일 뿐, 인프라 자체는 아닙니다.
비록 Compose 스택을 배포하기 위한 깔끔한 UI를 제공하고 볼륨을 검사하며 컨테이너를 관리할 수 있도록 해주지만, 서버 신뢰성을 보장하는 기본 서비스인 업데이트, HTTPS, 모니터링, 로깅 및 자격 증명 저장소를 제공하지는 않습니다.
지금 도입함으로써 Watchtower가 이를 업데이트하고; Caddy가 내가 안전하게 접근할 수 있도록 보장하며; Netdata로 그 리소스 사용량을 추적하고; Dozzle로 로그를 캡처하며; Vaultwarden에 자격 증명을 저장합니다. 이들은 Portainer가 제공하지 않지만 의존하는 필수 서비스입니다. 그것이 단지 케이크 위의 장식일 뿐이라는 것을 이해하게 되자, 필수품이 아니라 편리함의 층이 되었습니다.
기초, 올바른 방법
서버는 쉽게 매우 복잡한 작업이 될 수 있습니다. 목표는 가능한 한 오랫동안 최대한 단순하게 유지하는 것이어야 합니다. 다른 도구들이 이러한 역할을 수행할 수 있지만, 이 세트는 설정을 단순하고 관리하기 쉽게 유지합니다. 이것들은 기반이며, 다른 모든 서비스는 그 위에 구축됩니다.