NAS에서 Docker 사용하는 방법

NAS를 파일 보관함으로만 쓰다가 “이 프로그램도 NAS에서 계속 돌려 두고 싶다”는 생각이 드는 순간이 있습니다. 개인용 웹페이지, 다운로드 도구, 메모 서비스, 개발 테스트용 서버처럼 NAS가 켜져 있는 동안 계속 동작해야 하는 프로그램입니다. Synology NAS에서 이런 프로그램을 설치하는 대표적인 방법이 Docker 컨테이너이고, DSM에서는 Container Manager라는 화면 도구가 그 역할을 맡습니다.

처음 시도할 때 설치 버튼보다 중요한 것은 세 가지입니다. 프로그램이 데이터를 어디에 저장하는지, 어떤 포트로 접속하는지, 컨테이너나 프로젝트를 지웠을 때 무엇이 함께 사라지는지입니다. 이 세 가지를 모르고 시작하면 실행은 되어도 업데이트나 정리 한 번에 데이터를 잃는 구성이 됩니다. 메뉴 이름은 DSM 버전에 따라 조금 다를 수 있습니다.

방화벽, 외부 접속 방식, 공유 폴더 만들기처럼 NAS 전반의 설정은 Synology NAS 처음 설치하기에서 다뤘으므로 여기서는 컨테이너에 필요한 부분만 짚습니다.

Docker와 컨테이너, 이미지는 무엇이 다른가

Docker는 프로그램을 컨테이너라는 격리된 실행 환경에 담아 실행하는 기술입니다. 프로그램과 그 프로그램이 필요로 하는 구성 요소가 한 묶음으로 들어 있어서, NAS 운영체제에 이것저것을 직접 설치하지 않고도 실행하고, 필요 없어지면 컨테이너만 중지하거나 지울 수 있습니다.

여기서 두 단어를 구분해 두면 이후 화면이 훨씬 읽기 쉽습니다.

• 이미지: 프로그램을 실행하기 위한 준비물입니다. 설치 파일 묶음에 가깝고, 이미지 자체는 실행 중인 상태가 아닙니다.
• 컨테이너: 이미지를 바탕으로 실제 실행한 인스턴스입니다. 같은 이미지로 컨테이너를 여러 개 만들 수 있지만, 사용하는 포트와 데이터 폴더가 겹치지 않아야 합니다.

Container Manager는 이 둘을 DSM 화면에서 관리하게 해 주는 도구입니다. 화면은 개요, 프로젝트, 컨테이너, 이미지, 레지스트리, 네트워크, 로그로 나뉩니다. 개요에서는 서비스 상태와 실행 중인 프로젝트·컨테이너의 자원 사용량을 보고, 레지스트리에서 이미지를 검색해 내려받고, 이미지 화면에서 받아 둔 이미지를 관리하고, 컨테이너와 프로젝트 화면에서 실제 실행을 다룹니다.

Docker가 필요한 경우도 따져 봅니다. 사진 백업이나 파일 공유가 목적이라면 DSM 기본 패키지로 충분할 때가 많습니다. 쓰고 싶은 프로그램이 패키지 센터에 없고 컨테이너 이미지 형태로 제공될 때 Docker가 유용한 선택지가 됩니다.

내 NAS가 Container Manager를 지원하는지 확인합니다

모든 Synology NAS가 같은 패키지를 쓸 수 있는 것은 아닙니다. 지원 여부는 모델에 따라 다르고, Synology의 Container Manager 패키지 페이지에 적용 모델 목록이 있습니다. 목록에는 Plus 계열 모델이 많이 들어 있고 일부 값 모델도 포함되어 있으므로, 같은 시리즈라고 해서 추측하지 말고 본체 모델명을 목록과 대조합니다.

가장 빠른 확인은 DSM의 패키지 센터에서 Container Manager를 검색하는 것입니다. 패키지 센터에 보이면 설치할 수 있습니다. 보이지 않으면 모델명을 적용 모델 목록에서 찾아봅니다.

설치 전에 저장 공간과 메모리도 봅니다. 이미지와 컨테이너가 쓰는 공간은 NAS의 볼륨에서 나가고, 프로그램이 쌓는 데이터베이스·로그·캐시는 계속 늘어납니다. 컨테이너가 메모리를 많이 쓰면 파일 공유 같은 기존 서비스의 반응도 느려질 수 있으므로, 처음에는 가벼운 컨테이너 하나로 시작해서 개요 화면의 자원 사용량을 보며 늘려 갑니다.

또 하나는 프로세서 계열입니다. 이미지는 대상 CPU 아키텍처가 정해져 있고, amd64용 이미지는 ARM 계열 NAS에서 별도 에뮬레이션 없이는 실행되지 않습니다. 여러 아키텍처를 함께 제공하는 이미지는 Docker가 NAS에 맞는 쪽을 골라 줍니다. 이미지를 고를 때 제공처 페이지에 NAS의 아키텍처가 지원 목록에 있는지 확인합니다.

Container Manager 설치하기

지원되는 모델이라면 설치는 간단합니다.

1. 관리자 권한이 있는 계정으로 DSM에 로그인합니다.
2. 패키지 센터를 엽니다.
3. Container Manager를 검색해 설치를 선택합니다.
4. 설치가 끝나면 메인 메뉴에서 Container Manager를 실행합니다.

설치가 끝났으면 문제가 생겼을 때 어디를 볼지 정해 둡니다. 이미지가 받아지지 않으면 레지스트리, 컨테이너가 시작되지 않으면 컨테이너의 상태와 로그, 설정을 바꾸고 싶으면 프로젝트의 YAML 구성입니다.

컨테이너를 만들기 전에 정할 세 가지

설치할 프로그램이 정해졌다면 바로 실행하지 말고 저장 경로, 포트, 접근 범위부터 정합니다.

저장 경로. 프로그램이 만드는 설정 파일, 데이터베이스, 사용자 파일이 어디에 쌓이는지 정합니다. 컨테이너 안에만 두면 컨테이너를 다시 만들 때 사라질 수 있습니다. NAS의 폴더를 컨테이너 안의 경로에 연결(볼륨 연결)해 두면 컨테이너를 지우고 다시 만들어도 데이터는 NAS 폴더에 남습니다. 프로그램마다 안쪽 경로가 다르므로, 다른 사람의 설정을 복사하지 말고 이미지 제공처가 적어 둔 경로를 확인합니다.

포트. 컨테이너에서 실행한 서비스는 NAS의 포트를 통해 접속합니다. NAS 주소가 192.168.0.100이고 8088번 포트로 열었다면 브라우저에서 192.168.0.100:8088을 입력합니다. 컨테이너를 만들 때는 다른 DSM 서비스가 쓰지 않는 포트를 골라야 하고, 겹치면 서비스 오류가 날 수 있습니다. 8088은 예시일 뿐이므로 이미 쓰는 번호면 바꿉니다.

접근 범위. 집 안에서만 쓸지, 밖에서도 쓸지를 정합니다. 처음에는 내부 네트워크에서만 접속하는 것으로 시작합니다. 외부에서 접속하려고 공유기에서 포트를 여는 일은 컨테이너 설치와 별개의 보안 결정이며, 이미지가 제공하는 관리 화면의 인증 수준을 확인하기 전에는 하지 않는 편이 안전합니다.

이미지를 받고 컨테이너 만들기

가장 기본적인 흐름은 레지스트리에서 이미지를 받아 컨테이너를 만드는 것입니다.

1. 레지스트리에서 이미지 이름을 검색합니다. Docker Hub가 기본 레지스트리입니다.
2. 검색 결과에서 이미지를 선택하고 다운로드합니다. 결과를 더블 클릭해도 됩니다. 이름이 비슷한 이미지가 많으므로, 쓰려는 프로그램의 개발 팀이 제공하는 이미지인지 확인합니다.
3. 이미지에서 받은 이미지를 선택하고 실행을 눌러 생성 마법사를 시작합니다.
4. 일반 설정에서 컨테이너 이름을 정하고, 자동 재시작 여부를 고릅니다. 리소스 제한도 이 단계에서 설정할 수 있습니다. 리소스 제한은 컨테이너를 만드는 중에 켜면 끌 수 없으므로, 숫자를 정하기 어려우면 처음에는 켜지 않습니다.
5. 고급 설정에서 포트, 볼륨, 환경 변수를 채웁니다.
6. 요약 화면에서 설정을 확인하고 완료를 누릅니다. 마법사 완료 후 이 컨테이너 실행이 선택되어 있으면 완료와 함께 컨테이너가 시작됩니다.

환경 변수는 프로그램이 시작할 때 읽는 설정값입니다. 어떤 변수는 선택이고 어떤 변수는 필수인데, 필수 변수를 빼면 컨테이너가 곧바로 종료될 수 있습니다. 대부분의 컨테이너는 기본 표준 시간대가 UTC이므로, 로그나 일정에 한국 시간을 쓰려면 환경 변수 TZ에 Asia/Seoul 같은 값을 지정합니다.

완료하면 컨테이너 목록에서 상태를 봅니다. 실행 중이라고 표시되는 것과 프로그램이 정상 동작하는 것은 다릅니다. 브라우저나 클라이언트에서 실제로 접속해 봐야 끝입니다.

Compose 프로젝트로 웹서버 하나 띄워 보기

처음 연습하기에는 데이터베이스나 다운로드 도구보다 구성 요소가 적은 웹서버가 좋습니다. Nginx를 예시로 씁니다. 계정도 데이터베이스도 필요 없어서 컨테이너 실행, 포트 연결, 브라우저 접속이 제대로 되는지만 확인할 수 있습니다. 이 구성은 집 안 네트워크에서 열리는지 보려는 연습이며 인터넷 공개용이 아닙니다.

Container Manager에서 프로젝트 > 생성을 열고 다음을 지정합니다.

• 프로젝트 이름: 구분하기 쉬운 이름, 예를 들어 web-test
• 경로: 이 프로젝트의 작업 디렉토리가 될 폴더. File Station에서 프로젝트 전용 폴더를 하나 만들어 두면 설정 파일을 찾기 쉽습니다.
• 원본: docker-compose.yml을 업로드하거나 편집기로 직접 작성
• 웹 포털: Web Station으로 프로젝트에 접속하는 웹 포털을 켤지 고르는 선택 항목입니다. 이 예제는 켜지 않습니다.

편집기로 작성한다면 다음 내용을 넣습니다.

services:
  web:
    image: nginx:stable-alpine
    container_name: nas-web-test
    ports:
      - "8088:80"
    restart: unless-stopped

image는 실행할 이미지이고 nginx:stable-alpine은 Docker Hub의 공식 Nginx 이미지에 있는 태그입니다. stable-alpine 같은 이름 태그는 시간이 지나면 가리키는 이미지가 바뀔 수 있어서, 오래 운영할 서비스라면 버전 번호까지 적힌 태그로 고정하고 업데이트 시점을 직접 정합니다. container_name은 관리 화면에서 알아보기 위한 이름입니다. ports의 8088:80은 NAS의 8088번 포트를 컨테이너 안의 80번 포트에 연결한다는 뜻으로, 앞쪽이 NAS 쪽 번호이고 뒤쪽이 컨테이너 쪽 번호입니다. 이렇게 번호만 쓰면 NAS의 모든 네트워크 인터페이스에서 8088번이 열립니다. 집 안에서만 쓰려는 연습이라면 "192.168.0.100:8088:80"처럼 NAS의 내부 주소를 앞에 붙여 그 주소로만 열 수 있습니다. 이 주소는 예시이므로 NAS의 실제 내부 주소로 바꾸고, 주소가 바뀌는 환경이라면 공유기에서 NAS 주소를 고정해 둡니다. 외부에서 접근할 수 있는지는 NAS의 IP 주소, 공유기 포트 전달, IPv6, 방화벽, 네트워크 라우팅 설정에 따라 달라집니다. 인터넷 공개를 원하지 않는다면 포트 바인딩과 외부 접근 가능 여부를 함께 확인하고, 포트 전달은 따로 보안을 따져 결정합니다. restart: unless-stopped는 컨테이너가 예기치 않게 멈추거나 Docker가 다시 시작될 때 컨테이너를 다시 켜 주는 정책입니다. 다만 사용자가 직접 중지한 컨테이너는 Docker가 다시 시작되어도 되살아나지 않습니다.

이 예제에는 데이터를 보존할 볼륨 연결이 없습니다. 접속이 되는지 확인하는 용도이므로 이것으로 충분하고, 실제 웹사이트 파일이나 운영 데이터를 담으려면 폴더 연결을 추가해야 합니다.

마법사를 끝낼 때 프로젝트를 바로 시작할지 묻습니다. 시작하면 이미지를 받고 컨테이너가 실행됩니다. 상태가 실행 중으로 바뀌면 같은 네트워크의 컴퓨터에서 http://NAS의 내부 주소:8088로 접속합니다. Nginx 기본 환영 화면이 보이면 이미지 다운로드, 컨테이너 실행, 포트 연결, 브라우저 접속이 모두 정상입니다.

화면이 안 열리면 컨테이너 상태와 8088번 포트가 다른 곳에서 쓰이고 있지 않은지부터 봅니다.

프로젝트와 컨테이너를 직접 만드는 방식의 차이

서비스 하나를 가볍게 시험한다면 이미지에서 컨테이너를 직접 만드는 방식으로 충분합니다. 데이터베이스와 웹 앱처럼 여러 구성 요소가 함께 필요한 프로그램은 프로젝트로 묶어 관리하는 편이 편합니다.

프로젝트는 docker-compose.yml에 구성을 기록하므로 어떤 이미지, 포트, 저장소를 쓰는지 파일 하나로 확인하고 옮기고 검토할 수 있습니다. 프로젝트 화면의 작업에는 빌드, 시작, 중지, 다시 시작, 정리, 삭제가 있습니다. 빌드부터 정리까지는 Docker Compose 명령(up --build --no-start, start, stop, restart, down)에 해당하고, 삭제는 프로젝트 자체를 지우는 작업입니다.

표에서 주의할 것은 마지막 두 줄입니다. Docker 명령줄의 docker compose down은 기본으로 컨테이너와 네트워크만 지우고 볼륨과 이미지는 옵션을 줄 때만 지웁니다. Container Manager의 정리 버튼은 도움말에 그보다 넓은 범위로 적혀 있으므로, 버튼을 누르기 전에는 넓은 쪽을 기준으로 생각합니다. 정리와 삭제는 중지와 달리 컨테이너를 지우고, 정리는 그 프로젝트의 docker-compose.yml로 만들어진 네트워크, 볼륨, 이미지까지 제거합니다. 삭제는 프로젝트의 모든 컨테이너와 데이터를 지웁니다. 데이터를 NAS의 일반 폴더에 연결해 두었는지 Docker 관리 볼륨에 두었는지에 따라 영향이 달라지므로, 이 두 버튼을 누르기 전에 데이터가 어디에 있는지 확인합니다. 정리는 중지와 이름이 비슷해 보이지만 지우는 범위가 다릅니다.

프로젝트 화면에는 컨테이너 목록, 자원 통계, YAML 구성, 설정 탭이 있습니다. YAML 구성에서 파일을 고치고 새 설정으로 배포할 수 있어서, 포트나 환경 변수를 바꿀 때 프로젝트를 새로 만들 필요가 없습니다. 바뀐 서비스의 컨테이너는 새 설정으로 다시 만들어지고, 연결해 둔 폴더의 데이터는 유지됩니다.

Compose 파일이 있다고 데이터가 백업되는 것은 아닙니다. 파일은 실행 구성을 담고, 프로그램이 만든 실제 데이터는 별도 폴더에 있습니다. 파일만 보관하고 데이터 폴더를 백업하지 않으면, NAS가 고장 났을 때 서비스의 빈 껍데기만 다시 만들 수 있습니다.

볼륨을 연결해야 데이터가 남습니다

컨테이너는 실행 환경이고 NAS 폴더는 데이터 보관 장소입니다. 둘을 분리해 두면 프로그램을 업데이트하거나 다시 만들 때 관리가 쉬워집니다.

사진을 정리하는 서비스를 예로 들면, 원본 사진은 기존 공유 폴더에 그대로 두고, 프로그램의 설정과 데이터베이스만 전용 폴더에 저장하는 식입니다. 프로그램이 원본을 읽기만 한다면 원본 폴더를 읽기 전용으로 연결해 필요 이상의 수정이나 삭제를 막을 수 있습니다. 다만 읽기 전용으로 연결해도 프로그램이 정상 동작하는지는 프로그램마다 다릅니다.

볼륨을 연결했는데 프로그램이 폴더를 못 찾는다면 경로가 실제로 있는지, 철자와 대소문자가 맞는지부터 봅니다. 경로는 있는데 쓰기가 안 된다면 NAS 폴더 권한과 컨테이너 안에서 프로그램이 실행되는 사용자 권한이 맞지 않는 경우가 있습니다. 접근 거부를 풀겠다고 모든 사용자에게 쓰기 권한을 주는 방식은 피하고, 프로그램이 읽고 써야 하는 폴더에만 필요한 권한을 줍니다.

포트가 겹치거나 접속이 안 될 때

컨테이너는 실행 중인데 페이지가 안 열리면 포트 연결을 봅니다.

하나의 NAS 주소에서 같은 포트를 두 서비스가 동시에 쓸 수 없습니다. DSM 자체나 다른 패키지가 이미 8088번을 쓰고 있다면 새 컨테이너가 시작되지 않거나 서비스가 오류를 낼 수 있습니다. 포트 번호를 바꿔 다시 배포하고, 브라우저에 입력하는 번호도 같이 바꿉니다.

예제의 8088:80처럼 포트 매핑에는 두 개의 번호가 있습니다. 앞은 NAS 쪽, 뒤는 컨테이너 안쪽입니다. 브라우저에서는 항상 NAS 쪽 번호를 씁니다. 컨테이너 안쪽 번호는 프로그램이 정한 값이므로 함부로 바꾸지 않습니다.

DSM 방화벽을 켜 두었다면 규칙에 따라 접속이 막힐 수 있습니다. 같은 네트워크의 다른 컴퓨터에서 먼저 시험해 보고, 안 되면 방화벽 규칙을 확인합니다. 내부 접속이 되지 않은 채로 공유기 포트 전달부터 추가하는 것은 문제 해결 순서가 아닙니다. 내부 접속이 먼저 되어야 외부 접속을 검토할 수 있습니다.

컨테이너가 시작하자마자 종료될 때

실행 중이 아니거나 계속 다시 시작되는 컨테이너가 있으면 로그를 봅니다. 컨테이너 화면에서 해당 컨테이너의 세부 정보를 열면 로그 탭이 있고, 검색과 HTML·CSV 내보내기가 됩니다. 왼쪽 메뉴의 로그는 이와 달리 Container Manager 자체의 활동 기록이며, 정보·경고·오류로 걸러 볼 수 있습니다. 개별 컨테이너가 왜 멈췄는지는 컨테이너의 로그에서 찾습니다.

로그 탭의 표는 시간, 로그 내용, 스트림으로 나뉩니다. 스트림 열의 stdout은 표준 출력, stderr는 표준 오류 출력입니다. 캡처에서는 서버가 시작되었다는 안내 줄도 stderr로 찍혀 있으므로, stderr라는 표시만으로 오류라고 판단하지 않고 로그 내용을 읽습니다.

원인은 대개 몇 가지로 좁혀집니다.

• 필수 환경 변수 누락. 데이터베이스 이미지는 초기 비밀번호를 요구하는 경우가 많습니다.
• 연결한 폴더가 없거나 권한이 부족함.
• 이미지가 NAS 프로세서 계열을 지원하지 않음.
• 이미 쓰고 있는 포트와 충돌.

로그의 오류 한 줄만 보고 파일을 지우거나 패키지를 재설치하지 않습니다. 의심되는 설정 하나를 고치고 다시 실행하는 순서로 확인하면 어느 변경이 효과를 냈는지 알 수 있습니다. 설정이 맞는데도 Docker Hub 이미지로 컨테이너를 만들 수 없다면 이미지 자체의 문제일 수 있으므로 다른 이미지를 시험해 보는 방법이 있습니다. Docker Hub에는 개발자가 올린 이미지가 많아서 품질이 일정하지 않을 수 있습니다.

CPU와 메모리 사용량 보기

Container Manager의 개요와 컨테이너 세부 화면의 통계에서 CPU, 메모리, 네트워크 사용량을 볼 수 있습니다. 새로 올린 프로그램이 NAS 전체 성능에 영향을 주는지 보는 용도입니다.

잠깐 높아지는 것과 계속 높은 것을 구분합니다. 이미지 다운로드, 데이터베이스 초기화, 미디어 스캔은 일시적으로 작업량이 커집니다. 사용자가 아무것도 하지 않는데 특정 컨테이너가 계속 많이 쓴다면 그 컨테이너의 로그를 보고 무슨 작업을 하는지 확인합니다. 무조건 재시작하는 것보다 원인을 먼저 보는 편이 정확합니다.

컨테이너가 여러 개면 하나씩은 작아도 합치면 부담이 커집니다. 새 프로그램을 올린 직후에는 기존 서비스의 응답 속도와 NAS 사용량이 달라졌는지 살펴봅니다. 리소스 제한은 숫자를 정해 두는 기능인데, 데이터베이스처럼 시작할 때 메모리가 필요한 프로그램에 너무 낮은 값을 주면 아예 실행되지 않을 수 있습니다. 한번 켜면 끌 수 없으므로 프로그램을 하나씩 추가하며 사용량을 본 뒤에 켤지 정합니다.

업데이트는 이미지를 받는 것과 별개의 단계입니다

헷갈리기 쉬운 점은 새 이미지를 내려받는 것과, 실행 중인 컨테이너를 그 새 이미지로 바꾸는 것이 별개라는 사실입니다. 이미지를 새로 받았다고 기존 컨테이너가 저절로 새 버전으로 바뀐다고 가정하면 안 됩니다.

이미지 화면에서는 이미지를 선택하고 태그 열의 작업 > 업데이트(또는 업데이트 사용 가능)로 같은 태그의 새 버전을 받을 수 있습니다. 개요 화면의 이미지 정보에서도 업데이트가 가능하면 같은 작업을 할 수 있습니다. 이렇게 받은 이미지는 컨테이너를 새 이미지로 다시 만들어야 반영됩니다. 프로젝트라면 YAML 구성에서 새 설정으로 배포하고, 이 단계에서 정리를 누르지 않습니다. 정리는 볼륨과 이미지까지 지우는 작업이기 때문입니다.

업데이트 전에 확인할 것이 있습니다.

1. 프로그램 제공처의 릴리스 노트에서 데이터 형식이나 설정 변경이 필요한지 확인합니다. 주 버전이 바뀌는 업데이트는 특히 중요합니다.
2. 영구 데이터 폴더와 프로젝트 설정을 백업합니다. 데이터베이스 마이그레이션이 들어가면 이전 버전으로 되돌리기 어려울 수 있습니다.
3. 새 이미지로 배포한 뒤 컨테이너가 실행 중인지, 웹 화면이 열리는지, 기존 데이터가 보이는지 세 가지를 확인합니다.

자동 업데이트 도구를 쓸 생각이라면 실패했을 때의 복구 계획이 있는지부터 판단합니다. 편하게 새 버전으로 바뀌는 것보다 중요한 것은 설정과 데이터가 유지되는 것입니다.

사용하지 않는 이미지는 이미지 화면의 사용하지 않는 이미지 제거로 정리할 수 있고, 컨테이너에서 쓰는 이미지는 삭제되지 않습니다. 컨테이너가 쓰지 않는 이미지만 지우므로 디스크가 부족할 때 비교적 안전한 정리입니다.

외부 접속은 Docker 설치와 별개의 설계입니다

내부망에서 서비스가 잘 돌면 밖에서도 쓰고 싶어지지만, 컨테이너의 포트를 공유기에서 그대로 인터넷에 여는 것은 신중해야 합니다. 서비스마다 인증 기능의 완성도와 업데이트 주기가 다르고, 관리 화면이 인증 없이 노출되면 외부에서 프로그램을 조작할 수 있기 때문입니다.

개인용이라면 포트를 열지 않고 사설 네트워크로 접속하는 방법을 먼저 검토합니다. 이 방식은 Synology NAS Tailscale로 외부에서 접속하는 방법에서 Mac의 Finder 접속을 예로 정리했습니다. 같은 사설 네트워크에 들어 있는 기기에서는 NAS의 사설 주소와 컨테이너 포트로 접속합니다. 여러 사람이 쓰는 공개 서비스라면 HTTPS, 인증, 접근 통제, 업데이트와 로그 관리까지 따로 설계해야 합니다. 컨테이너로 웹서버를 띄울 수 있다는 사실과 그것을 안전하게 공개할 수 있다는 사실은 다른 문제입니다.

서비스 하나를 쓰기 위해 DSM 관리 화면까지 공개할 필요도 없습니다. 두 화면은 구분해서 다룹니다.

Docker는 백업 수단이 아닙니다

컨테이너를 쓰면 프로그램을 분리하기 쉬워질 뿐, 원본 데이터가 안전해지는 것은 아닙니다. 볼륨이 손상되거나 공유 폴더가 지워지면 연결된 컨테이너 데이터도 같이 영향을 받습니다. 따라서 영구 데이터 폴더는 NAS의 백업 대상에 포함합니다. NAS 데이터를 다른 저장소로 백업하는 방법은 Synology NAS 백업 설정에 정리해 두었습니다.

설정 파일과 데이터가 서로 다른 위치에 있다면 두 위치가 모두 백업 대상인지 점검합니다. 프로그램은 다시 설치하면 되지만, 데이터베이스를 복구하지 못하면 이전 상태로 돌아갈 수 없습니다. 실제 서비스를 올리기 전에 데이터가 어느 폴더에 쌓이고 어떻게 복구하는지 한 번은 확인해 둡니다.

마무리 정리

• 먼저 Docker가 필요한 프로그램인지 판단하고, NAS 모델이 Container Manager 적용 모델 목록에 있는지 확인합니다.
• 첫 컨테이너는 Nginx 같은 가벼운 것으로 시작해서 내부망 접속과 자원 사용량을 확인합니다.
• 장기 운영할 프로그램은 데이터 폴더를 NAS 폴더에 연결하고, 컨테이너가 필요한 권한만 줍니다.
• 프로젝트의 정리는 볼륨과 이미지까지, 삭제는 컨테이너와 데이터까지 지우므로 누르기 전에 데이터 위치와 백업을 확인합니다.
• 업데이트는 이미지를 받은 뒤 컨테이너를 새 이미지로 다시 배포하는 두 단계이고, 외부 공개는 컨테이너 설치와 별도로 설계합니다.