2020.01.20

쿠버네티스와 도커를 백업하는 방법

W. Curtis Preston | Network World
컨테이너 인프라에도 일종의 백업이 필요하다. 재해가 발생한 후 쿠버네티스와 도커가 스스로 재건되지는 않기 때문이다. 각 컨테이너의 실행 상태를 백업할 필요는 없지만 컨테이너를 실행하고 관리하는 데 사용되는 구성은 백업해야 한다.

백업해야 할 요소를 간단히 요약해 보자.
 

구성과 원하는 상태 정보

  • 이미지를 만드는 데 사용되는 도커파일(Dockerfile)과 이 파일의 모든 버전
  • 도커파일에서 생성되어 각 컨테이너를 실행하는 데 사용되는 이미지
  • 쿠버네티스 etcd 및 기타 : 클러스터 상태에 대한 정보를 저장하는 K8s 데이터베이스
  • 배치 : 각 배치를 설명하는 YAML 파일


컨테이너에 의해 생성 또는 변경되는 영구 데이터

  • 영구 볼륨
  • 데이터베이스
 

도커파일

도커 컨테이너는 이미지에서 실행되며, 이미지는 도커파일에서 작성된다. 적절한 도커 구성이라면 일반적으로 깃허브와 같은 리포지토리를 모든 도커파일의 버전 제어 시스템으로 사용한다. 애드혹 도커파일로 만든 애드혹 이미지를 사용해서 애드혹 컨테이너를 만들어서는 안 된다. 모든 도커파일은 현재 빌드에서 문제 발생 시 과거 버전을 가져올 수 있는 기능을 제공하는 리포지토리에 저장해야 한다.

또한 각 K8s 배치와 연결된 YAML 파일을 저장할 리포지토리도 필요하다. 이와 같은 YAML 파일은 버전 제어 시스템을 활용할 수 있는 텍스트 파일이다.

백업해야 할 대상은 이 리포지토리다. 가장 많이 사용되는 리포지토리 중 하나는 깃허브다. 깃허브는 리포지토리를 백업할 수 있는 여러 가지 방법을 제공한다. 제공된 API를 사용해서 리포지토리의 현재 백업을 다운로드하는 다양한 스크립트가 있고, 깃허브나 기타 사용 중인 리포지토리를 백업하기 위한 별도의 상용 툴도 있다.

이런 권장사항과 달리 도커파일이 더 이상 없는 이미지를 기반으로 컨테이너를 실행 중이라면, docker image history 명령, 또는 dfimage와 같은 툴을 사용해서 현재 이미지에서 도커파일을 만들 수 있다. 만든 도커파일을 리포지토리에 넣고 백업을 시작하기 바란다. 물론 처음부터 이런 상황에 처하지 않는 것이 좋다. 환경을 만드는 데 사용되는 도커파일과 YAML을 항상 저장하고 백업해야 한다.
 

도커 이미지

컨테이너를 실행하는 데 사용되는 현재 이미지도 리포지토리에 저장해야 한다. 물론 쿠버네티스에서 도커 이미지를 실행하는 경우 이미 백업하고 있는 상태이다. 도커 레지스트리와 같은 비공개 리포지토리 또는 도커허브(Dockerhub)와 같은 공개 리포지토리를 사용할 수 있다. 클라우드 서비스 업체도 이미지를 저장하기 위한 비공개 리포지토리를 제공한다. 이 리포지토리의 내용물을 백업해야 한다. 구글에서 “도커허브 백업” 등을 검색하면 생각 이상으로 많은 옵션을 확인할 수 있다.

컨테이너를 실행하는 데 사용되는 현재 이미지가 없다면 docker commit 명령을 사용해서 만든 다음 docker image history 또는 dfimage 툴을 사용해서 이 이미지에서 도커파일을 만들 수 있다.
 

쿠버네티스 etcd

쿠버네티스 etcd 데이터베이스는 매우 중요하며, etcdctl snapshot save db 명령을 사용해서 백업해야 한다. 명령을 실행하면 현재 디렉터리에 snapshot.db 파일이 생성되는데, 이 파일을 외부 스토리지에 백업해야 한다.

상용 백업 소프트웨어를 사용한다면 snapshot.db가 생성될 디렉터리를 백업하기 전에 etcdctl snapshot save 명령을 손쉽게 트리거할 수 있다. 이 방법으로 백업을 상용 백업 환경에 통합할 수 있다. 복구 문서를 참조하기 바란다.
 

영구 볼륨

데이터를 저장하거나 생성하는 데 사용되는 영구 스토리지에 대한 액세스 권한을 컨테이너에 부여하는 방법은 다양하다. 일반적인 도커 볼륨은 도커 구성의 하위 디렉터리에 위치한다. bind 마운트는 bind mount command 명령을 사용해서 컨테이너 내에 마운트되는 도커 호스트의 디렉터리다. 여러가지 이유로 도커 커뮤니티에서는 전통적인 볼륨을 선호하지만 백업 측면에서 전통적인 볼륨과 bind 마운트는 사실상 동일하다. 또한 객체 스토리지 시스템의 객체나 네트워크 파일 시스템(NFS) 디렉터리를 컨테이너 내부의 볼륨으로 마운트할 수도 있다.

영구 볼륨을 백업하는 데 사용하는 방법은 여러 옵션 중에서 어느 옵션을 컨테이너에 사용하는지에 따라 결정된다. 그러나 어느 옵션을 사용하든 데이터가 변경되는 경우 일관적인 백업을 위해 이 변경을 처리해야 한다는 점은 동일하다.

변경 처리 방법 중 하나는 그 볼륨을 사용하는 모든 컨테이너를 종료하는 것이다. 약간 구식이지만 백업 에이전트를 컨테이너에 두는 일반적인 방법을 사용할 수 없는 컨테이너 환경에서 어쩔 수 없이 발생하는 문제 중 하나다. 컨테이너를 종료하면 볼륨을 백업할 수 있다. 일반 도커 볼륨이라면 백업되는 동안 데이터가 변경될 일이 없는 다른 컨테이너에 마운트한 다음 해당 볼륨의 tar 이미지를 bind 마운트된 볼륨에 만들고, 이후 사용 중인 백업 시스템을 사용해서 이 볼륨을 백업하면 된다.

그러나 쿠버네티스에서 이 방법을 실행하기는 매우 어렵다. 이 점이 상태 정보를 파일 시스템이 아닌 데이터베이스에 저장하는 것이 최선인 이유 중 하나다. K8s 인프라를 설계할 때 이 부분을 꼭 고려하길 바란다.

또한 bind 마운트 디렉터리, NFS 마운트 파일 시스템 또는 객체 스토리지 시스템을 영구 스토리지 시스템으로 사용 중인 경우, 이 스토리지 시스템을 백업하는 최선의 방법이 무엇이든 그 방법을 사용하면 된다. 스냅샷을 생성한 다음 복제하는 방법일 수도 있고, 해당 시스템에서 상용 백업 소프트웨어를 실행하는 방법일 수도 있다. 대부분의 경우 이와 같은 방법을 사용하면 일반적인 파일 수준 백업으로 볼륨을 백업하는 방법에 비해 훨씬 더 일관적인 백업이 가능하다.
 

데이터베이스

그 다음 생각할 문제는 컨테이너가 데이터베이스를 사용해서 데이터를 저장하는 경우다. 이 데이터베이스는 무결성을 보장하는 방법으로 백업해야 한다. 데이터베이스에 따라 앞서 설명한 방법을 사용할 수도 있다. 즉, 데이터베이스에 액세스하는 컨테이너를 종료하고 파일이 저장된 디렉터리를 백업하는 방법이다. 그러나 여기서 발생하는 다운타임이 문제가 될 수 있다.

다른 방법은 데이터베이스 엔진 자체에 직접 연결해서 파일로 백업하도록 요청한 다음, 이 파일을 백업하는 방법이다. 데이터베이스가 컨테이너 안에서 실행된다면 컨테이너 외부에 백업을 둘 수 있도록 먼저 bind 마운트를 사용해서 데이터베이스가 백업할 수 있는 볼륨을 연결해야 한다. 이후 데이터베이스에 사용되는 명령(예를 들어 mysqldump)을 실행해서 백업을 생성한다. 생성된 파일을 백업 시스템을 사용해서 백업한다.

어느 컨테이너가 무슨 스토리지 또는 어떤 데이터베이스를 사용하는지 모르는 경우에는 어떻게 해야 할까? docker ps 명령을 사용해서 실행 중인 컨테이너 목록을 출력한 다음 docker inspect 명령을 사용해 각 컨테이너의 구성을 표시한다. 여기서 Mounts라는 섹션을 보면 어느 볼륨이 어디에 마운트되어 있는지 확인할 수 있다. 또한 bind 마운트는 쿠버네티스에 제출하는 YAML 파일에도 지정된다.
 

상용 백업 솔루션

앞서 설명한 데이터 중 일부 또는 모든 데이터를 보호할 수 있는 다양한 상용 백업 솔루션이 있다. 몇 가지를 간단히 요약하면 다음과 같다.
  • 컴볼트(Commvault)의 가상 서버 에이전트는 컨테이너와 컨테이너의 이미지를 백업하기 위한 프록시 역할을 할 수 있다.
  • 코히시티(Cohesity)는 K8s 네임스페이스를 위한 데이터 보호를 제공한다.
  • 헵티오(Heptio, 현재 VM웨어 자회사)는 K8s용으로 설계된 백업인 벨레로(Velero)를 제공한다.
  • 콘티노(Contino), 데이터코어(Datacore), 포트웍스(Portworx)는 K8s와 컨테이너용으로 설계된 스토리지를 제공하며 이 정보의 백업도 지원한다.
K8s와 도커의 구성 방법은 매우 다양해서 한 기사에서 모든 경우를 다루기는 매우 어렵다. 그러나 이 기사를 통해 백업에 대해 생각을 하게 됐거나, 지금까지 백업하지 않았던 것을 백업해야 할 필요성을 느꼈다면 그것 만으로 충분하다. 안전이 최고다! editor@itworld.co.kr


2020.01.20

쿠버네티스와 도커를 백업하는 방법

W. Curtis Preston | Network World
컨테이너 인프라에도 일종의 백업이 필요하다. 재해가 발생한 후 쿠버네티스와 도커가 스스로 재건되지는 않기 때문이다. 각 컨테이너의 실행 상태를 백업할 필요는 없지만 컨테이너를 실행하고 관리하는 데 사용되는 구성은 백업해야 한다.

백업해야 할 요소를 간단히 요약해 보자.
 

구성과 원하는 상태 정보

  • 이미지를 만드는 데 사용되는 도커파일(Dockerfile)과 이 파일의 모든 버전
  • 도커파일에서 생성되어 각 컨테이너를 실행하는 데 사용되는 이미지
  • 쿠버네티스 etcd 및 기타 : 클러스터 상태에 대한 정보를 저장하는 K8s 데이터베이스
  • 배치 : 각 배치를 설명하는 YAML 파일


컨테이너에 의해 생성 또는 변경되는 영구 데이터

  • 영구 볼륨
  • 데이터베이스
 

도커파일

도커 컨테이너는 이미지에서 실행되며, 이미지는 도커파일에서 작성된다. 적절한 도커 구성이라면 일반적으로 깃허브와 같은 리포지토리를 모든 도커파일의 버전 제어 시스템으로 사용한다. 애드혹 도커파일로 만든 애드혹 이미지를 사용해서 애드혹 컨테이너를 만들어서는 안 된다. 모든 도커파일은 현재 빌드에서 문제 발생 시 과거 버전을 가져올 수 있는 기능을 제공하는 리포지토리에 저장해야 한다.

또한 각 K8s 배치와 연결된 YAML 파일을 저장할 리포지토리도 필요하다. 이와 같은 YAML 파일은 버전 제어 시스템을 활용할 수 있는 텍스트 파일이다.

백업해야 할 대상은 이 리포지토리다. 가장 많이 사용되는 리포지토리 중 하나는 깃허브다. 깃허브는 리포지토리를 백업할 수 있는 여러 가지 방법을 제공한다. 제공된 API를 사용해서 리포지토리의 현재 백업을 다운로드하는 다양한 스크립트가 있고, 깃허브나 기타 사용 중인 리포지토리를 백업하기 위한 별도의 상용 툴도 있다.

이런 권장사항과 달리 도커파일이 더 이상 없는 이미지를 기반으로 컨테이너를 실행 중이라면, docker image history 명령, 또는 dfimage와 같은 툴을 사용해서 현재 이미지에서 도커파일을 만들 수 있다. 만든 도커파일을 리포지토리에 넣고 백업을 시작하기 바란다. 물론 처음부터 이런 상황에 처하지 않는 것이 좋다. 환경을 만드는 데 사용되는 도커파일과 YAML을 항상 저장하고 백업해야 한다.
 

도커 이미지

컨테이너를 실행하는 데 사용되는 현재 이미지도 리포지토리에 저장해야 한다. 물론 쿠버네티스에서 도커 이미지를 실행하는 경우 이미 백업하고 있는 상태이다. 도커 레지스트리와 같은 비공개 리포지토리 또는 도커허브(Dockerhub)와 같은 공개 리포지토리를 사용할 수 있다. 클라우드 서비스 업체도 이미지를 저장하기 위한 비공개 리포지토리를 제공한다. 이 리포지토리의 내용물을 백업해야 한다. 구글에서 “도커허브 백업” 등을 검색하면 생각 이상으로 많은 옵션을 확인할 수 있다.

컨테이너를 실행하는 데 사용되는 현재 이미지가 없다면 docker commit 명령을 사용해서 만든 다음 docker image history 또는 dfimage 툴을 사용해서 이 이미지에서 도커파일을 만들 수 있다.
 

쿠버네티스 etcd

쿠버네티스 etcd 데이터베이스는 매우 중요하며, etcdctl snapshot save db 명령을 사용해서 백업해야 한다. 명령을 실행하면 현재 디렉터리에 snapshot.db 파일이 생성되는데, 이 파일을 외부 스토리지에 백업해야 한다.

상용 백업 소프트웨어를 사용한다면 snapshot.db가 생성될 디렉터리를 백업하기 전에 etcdctl snapshot save 명령을 손쉽게 트리거할 수 있다. 이 방법으로 백업을 상용 백업 환경에 통합할 수 있다. 복구 문서를 참조하기 바란다.
 

영구 볼륨

데이터를 저장하거나 생성하는 데 사용되는 영구 스토리지에 대한 액세스 권한을 컨테이너에 부여하는 방법은 다양하다. 일반적인 도커 볼륨은 도커 구성의 하위 디렉터리에 위치한다. bind 마운트는 bind mount command 명령을 사용해서 컨테이너 내에 마운트되는 도커 호스트의 디렉터리다. 여러가지 이유로 도커 커뮤니티에서는 전통적인 볼륨을 선호하지만 백업 측면에서 전통적인 볼륨과 bind 마운트는 사실상 동일하다. 또한 객체 스토리지 시스템의 객체나 네트워크 파일 시스템(NFS) 디렉터리를 컨테이너 내부의 볼륨으로 마운트할 수도 있다.

영구 볼륨을 백업하는 데 사용하는 방법은 여러 옵션 중에서 어느 옵션을 컨테이너에 사용하는지에 따라 결정된다. 그러나 어느 옵션을 사용하든 데이터가 변경되는 경우 일관적인 백업을 위해 이 변경을 처리해야 한다는 점은 동일하다.

변경 처리 방법 중 하나는 그 볼륨을 사용하는 모든 컨테이너를 종료하는 것이다. 약간 구식이지만 백업 에이전트를 컨테이너에 두는 일반적인 방법을 사용할 수 없는 컨테이너 환경에서 어쩔 수 없이 발생하는 문제 중 하나다. 컨테이너를 종료하면 볼륨을 백업할 수 있다. 일반 도커 볼륨이라면 백업되는 동안 데이터가 변경될 일이 없는 다른 컨테이너에 마운트한 다음 해당 볼륨의 tar 이미지를 bind 마운트된 볼륨에 만들고, 이후 사용 중인 백업 시스템을 사용해서 이 볼륨을 백업하면 된다.

그러나 쿠버네티스에서 이 방법을 실행하기는 매우 어렵다. 이 점이 상태 정보를 파일 시스템이 아닌 데이터베이스에 저장하는 것이 최선인 이유 중 하나다. K8s 인프라를 설계할 때 이 부분을 꼭 고려하길 바란다.

또한 bind 마운트 디렉터리, NFS 마운트 파일 시스템 또는 객체 스토리지 시스템을 영구 스토리지 시스템으로 사용 중인 경우, 이 스토리지 시스템을 백업하는 최선의 방법이 무엇이든 그 방법을 사용하면 된다. 스냅샷을 생성한 다음 복제하는 방법일 수도 있고, 해당 시스템에서 상용 백업 소프트웨어를 실행하는 방법일 수도 있다. 대부분의 경우 이와 같은 방법을 사용하면 일반적인 파일 수준 백업으로 볼륨을 백업하는 방법에 비해 훨씬 더 일관적인 백업이 가능하다.
 

데이터베이스

그 다음 생각할 문제는 컨테이너가 데이터베이스를 사용해서 데이터를 저장하는 경우다. 이 데이터베이스는 무결성을 보장하는 방법으로 백업해야 한다. 데이터베이스에 따라 앞서 설명한 방법을 사용할 수도 있다. 즉, 데이터베이스에 액세스하는 컨테이너를 종료하고 파일이 저장된 디렉터리를 백업하는 방법이다. 그러나 여기서 발생하는 다운타임이 문제가 될 수 있다.

다른 방법은 데이터베이스 엔진 자체에 직접 연결해서 파일로 백업하도록 요청한 다음, 이 파일을 백업하는 방법이다. 데이터베이스가 컨테이너 안에서 실행된다면 컨테이너 외부에 백업을 둘 수 있도록 먼저 bind 마운트를 사용해서 데이터베이스가 백업할 수 있는 볼륨을 연결해야 한다. 이후 데이터베이스에 사용되는 명령(예를 들어 mysqldump)을 실행해서 백업을 생성한다. 생성된 파일을 백업 시스템을 사용해서 백업한다.

어느 컨테이너가 무슨 스토리지 또는 어떤 데이터베이스를 사용하는지 모르는 경우에는 어떻게 해야 할까? docker ps 명령을 사용해서 실행 중인 컨테이너 목록을 출력한 다음 docker inspect 명령을 사용해 각 컨테이너의 구성을 표시한다. 여기서 Mounts라는 섹션을 보면 어느 볼륨이 어디에 마운트되어 있는지 확인할 수 있다. 또한 bind 마운트는 쿠버네티스에 제출하는 YAML 파일에도 지정된다.
 

상용 백업 솔루션

앞서 설명한 데이터 중 일부 또는 모든 데이터를 보호할 수 있는 다양한 상용 백업 솔루션이 있다. 몇 가지를 간단히 요약하면 다음과 같다.
  • 컴볼트(Commvault)의 가상 서버 에이전트는 컨테이너와 컨테이너의 이미지를 백업하기 위한 프록시 역할을 할 수 있다.
  • 코히시티(Cohesity)는 K8s 네임스페이스를 위한 데이터 보호를 제공한다.
  • 헵티오(Heptio, 현재 VM웨어 자회사)는 K8s용으로 설계된 백업인 벨레로(Velero)를 제공한다.
  • 콘티노(Contino), 데이터코어(Datacore), 포트웍스(Portworx)는 K8s와 컨테이너용으로 설계된 스토리지를 제공하며 이 정보의 백업도 지원한다.
K8s와 도커의 구성 방법은 매우 다양해서 한 기사에서 모든 경우를 다루기는 매우 어렵다. 그러나 이 기사를 통해 백업에 대해 생각을 하게 됐거나, 지금까지 백업하지 않았던 것을 백업해야 할 필요성을 느꼈다면 그것 만으로 충분하다. 안전이 최고다! editor@itworld.co.kr


X