Docker는 컨테이너 기반의 리눅스 가상화 도구입니다… 라고 업계 용어로 표현하면 선뜻 다가가기가 힘들죠. 우리는 그저 나스를 구축하고자 할 뿐이니까, 쉽게 다시 정의해 봅시다.

Docker는 서버 환경에 관계없이 같은 방법으로 서비스를 설치할 수 있게 하는 플랫폼입니다.

음, 아직도 어렵지만, 우리의 목적에 맞는 표현은 된 것 같아요.


Docker?

Docker 로고
Docker 공식 홈페이지

앞의 정의를 다시 가져옵시다. Docker는 컨테이너 기반의 리눅스 가상화 도구입니다. VMWareVirtualBox 같은 가상 머신과는 다른 개념이지만, 가상화라는 점에서는 비슷한 도구라고 볼 수 있겠네요.

근데 도커와 같은 가상화가 왜 나스와 같은 개인용 홈서버 구축에 획기적인 도구가 되었을까요? 그건 일단 도커만 설치가 잘 되었다면, 컨테이너 (가상화 공간) 내부는 완벽하게 제작자 의도대로 돌아가는 공간이 되어있기 때문입니다. 따라서 환경별 차이로 발생하는 설치 문제에 일일이 대응할 필요가 없어지므로, 제작자와 사용자 모두에게 편리한 설치 환경을 제공할 수 있습니다.

OMV4에 Docker 설치하기

OMV4는 Docker CE의 플러그인을 제공하고 있어요. 시스템 > OMV-Extras 페이지의 저장소 탭에서 이를 활성화해줍니다.

Docker CE 저장소 활성화

그리고 이제 시스템 > 플러그인 페이지에 들어가면 아래와 같이 Docker 패키지가 추가되어 있어요. 설치합니다.

Docker CE 패키지 설치

설치하고 나면 서비스 > Docker 메뉴가 추가된 것이 보입니다. 메뉴에 접속하기 전에 Docker 시스템에서 사용하는 데이터를 넣어 둘 공간을 만들어야 하는데요, 이를 위해 공유 폴더 하나를 생성합니다.

Docker 시스템 폴더 생성

사실, 이 폴더를 만들지 않고 OMV 내부의 운영체제 공간에 이를 생성하게 할 수도 있어요. 그리고 이 폴더는 우리가 직접 들어가 볼 이유도, 권한도 없으므로 그편도 나쁘지 않습니다. 다만 이 공간의 용량이 설치하는 도커 서비스에 따라 굉장히 유동적일 수 있으므로, 운영체제 공간의 용량이 부족하다고 생각한다면 넉넉한 곳에 공유 폴더를 생성하여 잡아주도록 합시다.

이제 서비스 > Docker 페이지에서 도커 서비스를 활성화합니다.

Docker 서비스 활성화

쨘! 그럼 이제 아래와 같이 도커가 활성화되어 준비 중인 것을 볼 수 있습니다.

Docker 관리 페이지

이제 도커를 사용할 준비가 끝났네요. 이제 컨테이너를 설치해 봅시다.

Docker 컨테이너 설치

도커를 사용하여 배포되는 많은 서비스는 Docker Hub라는 이미지 공개 저장소에서 공유되고 있어요. 도커로 배포되는 서비스에 특별한 설명이 없으면, 당연히 이곳에서 받을 수 있다고 생각해도 될 정도입니다.

누구나 도커 이미지를 배포할 수 있는 곳이기 때문에, 잘 관리되어 원활하게 동작하는 이미지를 찾는 것이 쉬운 설치의 지름길입니다.

잘 만들어진 이미지는 보통,

  • 서비스 개발사 공식 이미지 (Official Image 태그가 붙어 있고, 이미지 이름이 ‘아이디/이미지명’ 구조가 아닌, 그냥 ‘이미지명’ 으로 되어 있습니다)
  • 다운로드 횟수가 많은 이미지
  • 매뉴얼이 잘 써진 이미지

정도가 되겠습니다. 사실 가장 좋은 건 남들이 깔아봤다는 이미지

자, 이제 하나 골라서 설치해 봅시다.

Docker 실행 명령 이해하기

docker run 공식 문서

도커 이미지는 보통 이미지의 실행 명령어와 같이 공유됩니다. 이 명령어가 어떤 의미인지를 이해하고, 각자의 상황에 맞게 바꿔주는 것이 가장 중요합니다.

일반적으로 docker run으로 시작되는 이 실행 명령어의 각 요소가 어떤 의미인지 알아봅시다. 예시로는 Github Pages의 사이트 빌더 Jekyll을 가져왔어요.

docker run -d \
  --name=jekyll \
  -e LANG=ko_KR.UTF-8 \
  -e LANGUAGE=ko_KR \
  -e TZ=Asia/Seoul \
  -e LC_ALL=ko_KR.UTF-8 \
  -p 3000:4000 \
  -v /path/to/jekyll/sources:/srv/jekyll \
  --restart unless-stopped \
  jekyll/jekyll:3.8.5 \
  jekyll serve

\ (역슬래시, 환경에 따라 으로 보일 수도 있습니다) 는 터미널에서 명령이 끝나지 않았음을 의미합니다. 즉, 저 명령은 ‘'를 제거하고 한 줄로 쓴 것과 같아요. 근데 그건 너무 길잖아요. 그래서 보통 저렇게 나누어 씁니다.

docker run

docker run은 컨테이너 만들어 실행한다는 의미입니다.

-d

-d는 이 컨테이너를 백그라운드로 실행한다는 의미에요. 이 옵션이 생략된다면 명령 실행 시 로그가 화면에 출력되며, 터미널 종료 시 컨테이너도 종료하게 됩니다.

여기까지는 OMV 도커 플러그인에서 신경 쓸 필요가 없는 부분입니다. 플러그인에서는 docker run -d까지를 당연히 사용하는 것으로 간주하거든요. 하지만 이다음부터는 상황에 따라 바꿔줘야 할 일이 아주 많아집니다.

–name=CONTAINTER_NAME

이 부분은 컨테이너 각각을 인식하는 이름을 지어주는 부분입니다. 같은 이미지에 대한 컨테이너를 여러 개 만들 수도 있으므로, 이를 구분해 주기 위해 사용합니다.

이 부분을 생략하면 임의의 이름으로 컨테이너가 생성되게 됩니다.

[NOTE]
도커가 임의로 컨테이너 이름을 붙이는 규칙은 형용사_과학자 이름 구조입니다. 컨테이너 이름을 보고 어떤 사람을 의미하는 것인지 추측해 보세요. 전 mad_einstein 나옴

-e KEY=VALUE

-e는 환경 변수를 지정하는 옵션입니다. 컨테이너 실행 시 상황에 따라 설정값을 바꿔줘야 하는 경우가 있는데, 그 값을 컨테이너 내부에 전달해 주는 옵션이에요.

예시처럼 -e LANG=ko_KR.UTF-8 이라고 적혀있다면, 컨테이너 내부의 인코딩을 한국어 UTF-8로 하겠다는 의미에요.

사용 가능한 옵션이 무슨 의미인지, 무슨 값을 사용할 수 있는지는 이미지마다 달라요. 해당 도커 이미지의 매뉴얼을 확인하세요.

-p LOCAL_PORT:CONTAINER_PORT

-p는 이 컨테이너에서 사용하는 포트를 컨테이너 바깥 (= 우리가 접속할 수 있는 곳) 과 연결해 줄 수 있는 포트 매핑 옵션입니다. 어렵게 생각할 것 없이, 컨테이너를 공유기로 가정하고, 그 안팎으로 포드포워딩을 해준다고 생각하면 됩니다.

따라서 -p 3000:4000은 컨테이너 내부에서 사용하는 4000번 포트를 컨테이너 밖에서는 3000번으로 생각하고 접근한다는 의미입니다.

: 왼쪽의 로컬 포트는 나스에서 현재 사용 중인 포트와 겹치면 안 되므로, 이미 사용 중인 서비스의 포트를 고려하여 겹치지 않는 번호를 할당합니다. 일반적으로 HTTP 공식 포트인 80, HTTPS443이 잘 겹치고, 이 포트에서 파생된 8080, 8000 등도 자주 겹치는 편이에요.

-v /local/path:/container/path

-v는 볼륨 바인딩이라고 하여, 컨테이너 내부의 특정 경로를 나스의 특정 경로와 이어 주는 역할을 합니다. 일종의 공유 폴더와 같은 셈이죠. 또한, 폴더뿐만 아니라 파일도 연결할 수 있습니다.

이에 따라서 예시의 -v /path/to/jekyll/sources:/srv/jekyll 부분을 해석하면, 컨테이너 내부에 /srv/jekyll이라는 폴더가 있는데, 이를 나스의 /path/to/jekyll/sources 폴더와 연결한다는 뜻입니다. 물론 /path/to/jekyll/sources라는 폴더가 있을 리 없으니, 그 부분을 이 목적에 사용될 폴더의 경로로 바꿔줘야겠죠.

주의할 것은, 반드시 /으로 시작되는 절대 경로로 적어야 한다는 점입니다. 목적 폴더에 접속한 뒤 pwd 명령을 실행하여 절대 경로를 확인할 수 있습니다.

–restart restart_policy

도커는 가상 머신과는 다르게, 컨테이너에서 실행하는 내용이 끝나면 컨테이너를 멈추게 됩니다. --restart는 이때 컨테이너를 어떻게 재시작할지 정책에 대한 설정입니다. 네 종류가 있어요.

  • no: 재시작하지 않습니다.
  • always: 항상 재시작합니다.
  • unless-stopped: 종료되지 않는 한 항상 재시작합니다.
  • on-failure: 컨테이너가 오류로 꺼졌을 때만 재시작합니다.

2번과 3번이 차이가 없어 보일 수 있는데, 두 옵션의 차이는 컨테이너가 중단된 후 도커 (또는 나스째로) 가 재부팅되었을 때 차이가 있습니다. always는 무조건 다시 켜지지만, unless-stopped는 도커가 중단된 후 나스가 재부팅되었을 때는 다시 켜지지 않아요.

user/image[:tag]

jekyll/jekyll:3.8.5로 표현된 마지막 부분은 이 이미지의 정보입니다.

tag는 생략 가능한 옵션으로, 생략하면 latest 태그를 찾아 실행시키게 됩니다. 버전이나 실행 환경의 차이에 따라 이미지를 나누어둔 경우가 있으므로, latest를 사용해도 되는지, 자신에게 맞는 태그가 있는지 확인할 필요가 있어요.

COMMAND

마지막 줄의 jekyll serve는 컨테이너 실행 후 실행될 명령입니다. 이미지에 실행 옵션이 있는 경우에 볼 수 있습니다. 이 경우에는 이미지가 buildupdate도 지원하기 때문에 실행 명령 선택을 COMMAND로 제공한 것입니다. 이미지의 매뉴얼에서 자세한 사용법을 확인할 수 있습니다. 하지만 많은 이미지가 이 옵션 없이 사용하게 해 두었을 거예요.

OMV4에서 도커 컨테이너 실행하기 - Nextcloud 설치

물론 우리는 저 내용을 터미널에 입력할 필요는 없습니다. 서비스 > Docker 페이지에서 같은 작업을 수행할 수 있거든요.

실행 명령 확인

그 시범으로 Nextcloud라는 설치형 클라우드를 가져왔습니다. 그리고 Docker Hub - Nextcloud의 매뉴얼과 인터넷의 수많은 팁을 통해 아래와 같은 docker run 명령으로 서비스를 설치할 수 있다고 알게 되었습니다. 고 칩시다.

docker run -d \
  --name=omv4_nextcloud
  --restart always \
  -p 6080:80 \
  -v nextcloud:/var/www/html \
  nextcloud

이 명령어 내용대로 컨테이너를 만들어 볼 겁니다.

Docker 플러그인에서 설정

우선, 뭔가 폴더를 연결해줘야 하는 듯싶으니, 공유 폴더에서 nextcloud라는 폴더를 하나 만들어 둡니다.

그리고 서비스 > Docker 페이지에서 복제본 당겨오기 버튼을 눌러 이미지를 가져오고요.

Nextcloud 이미지 가져오기

꼬리표 부분을 생략하면 latest 태그의 이미지를 가져오게 됩니다. 혹시 다른 tag를 가져오려면 꼬리표 에 태그를 입력해 주세요.

그리고 사용할 nextcloud 이미지를 클릭하고 복제본 실행 버튼을 눌러 아래 그림과 같이 설정합니다.

Nextcloud 컨테이너 실행

각 부분이 무엇을 의미하는지는, 위 챕터를 열심히 읽었으면 쉽게 이해할 수 있을 거예요.

이 경우에는 환경 변수가 엄청나게 많이 나오는데요, 이것은 이미지에서 기본값으로 설정해 둔 모든 환경 변수가 다 표시되는 것으로 직접 설정한 것이 아닙니다. 만약 필요하다면 여기에 환경 변수를 새롭게 추가하거나 기존 변수를 수정할 수도 있습니다.

컨테이너 실행 확인

일반적으로 80 포트가 서비스 접속 포트이고, 우리는 이것을 6080으로 설정했으니, http://나스주소:6080으로 접속해 봅시다.

Nextcloud 최초 접속 화면

잘 뜨네요. 이제 이 페이지에서 남은 설정을 완료하고 서비스를 사용하면 됩니다.

[NOTE]
지금 글의 방법으로 설치한 넥스트클라우드는 별도의 DB를 설치하지 않아 SQLite로만 설정하여 사용할 수 있습니다. 그림에서 경고하듯 성능이 좋은 편은 아니니 실제로 사용하시려면 DB를 같이 설치하여 사용하는 것이 좋습니다.


그리고 남은 이야기

이것으로 OMV4 자작 NAS 구축는 끝입니다. 나머지는 기존의 글을 응용하여 직접 플러그인이나 도커 컨테이너를 설치하여 기능을 확장할 수 있을 거예요.

openmediavault는 시놀로지에 비해서는 편의성도, 기능도 완벽하지 못한 나스 솔루션이지만, 커뮤니티에서 개발하여 배포하는 무료 솔루션 중에서는 가장 직관적이고 다루기 쉬운 것으로 생각됩니다. OMV5에서 플러그인 다수를 포기하고 대부분을 외부의 도커 서비스로 대체한 것은 별로 마음에 들지 않긴 하지만… 커뮤니티 개발의 한계라고 이해는 되고요.

그나마 다행인 점은, 데비안을 기반으로 하여 돌아가기 때문에 데비안/우분투 팁을 참고하여 문제를 해결하기 좋다는 점이 아닐까요.

이 글들을 통해 성공적인 자작 나스 구축이 되셨으면 좋겠습니다. 감사합니다.

댓글남기기