발단
16년도에 구매해서 이래저래 잘 사용하던 서버가 슬슬 맛이 가기 시작했다. 몇달 전부터 백업 실패 메시지가 나오기 시작하더니 VMware에서 스냅샷 생성도 실패한다. 디스크 문제인가 싶어서 다른 디스크로 옮기려고 VM 복제를 해봤지만 그것도 실패했다. OS에서는 재부팅 할 때 마다 파티션 복구를 해야했다. 다른 VM들은 괜찮은데 이 블로그와 몇 가지 개인적인 개발용으로 쓰는 VM에서 문제가 생기기 시작했다.
NAS로 서비스들을 옮길까 했으나 점찍어둔 작고 귀여운 신상 서버(HP Microserver Gen10+)도 있고 해서 기존 서버는 실험용으로 사용하기로 하고 새 서버를 구매해 서비스를 모두 옮겼다.
서비스 이전에 관하여
IT서비스들을 이전하는 것은 리스크도 꽤 높고 해야할 일도 많은 작업이다. 지난 1년간 회사에서 U2L(UNIX to Linux) 을 한다고 꽤 고생해본 경험이 있어서 그 고단함을 이미 알고 있다. 일단 안정적인 이전을 위해서는 서비스를 중단해야 하므로 작업 시간 부터 제약이 생긴다. U2L이라는 이름 자체는 OS의 변화를 의미하지만 실제로는 H/W부터 가상화 소프트웨어, OS, 스토리지 등이 다 바뀐다고 봐야 한다. 애플리케이션(서비스)과 데이터를 통째로 들어다가 새로운 서버로 옮기는 작업인 것이다.
인프라는 한 번 구축하면 큰 변화 없이 몇 년을 사용하는 것이 보통이고 그 시간 동안 인프라에 관한 정보가 소실되기 쉬운 것 같다. 인프라 작업이라는 것들이 일회적 성격을 띄기 때문인 것 같다. 기록을 유지하지 않으면 나중에 어떤 식으로 인프라가 구성되어 있는지 알기 어렵다. 집으로 치자면 수도물이 잘 나오고 있는데 배관이 어떻게 되어 있는지, 밸브들이 어디 위치하고 있는지 알 수 없기 마련인 것과 같다. 집을 애플리케이션이라고 한다면 생활공간의 모든 것을 뜯어다가 새로운 집에 똑같이 배치하고 연결하고 기존대로 돌아가길 바라는 것이 U2L인 것이다
망가져가는 것들..
기존에 쓰던 서버는 16년도인가 구매한 HP Microserver Gen8이다. 처음엔 헤놀로지로 NAS를 만들기 위해 구매했다. 하지만 가상화 기술-특히 VMware를 접하고 배울 수 있던게 이 서버의 가장 의미라고 생각된다. 서버 가상화는 기업 IT 인프라에 거의 필수적인 요소라 이를 연습하기 위한 환경으로 적합한 서버였다고 생각된다. 가끔 뭐 한다고 서버 내리는 시간들 빼고는 항상 켜져있었다. 꽤 오랜 시간 잘 버텨왔다. 하지만 슬슬 망가지기 시작했다..
VM 이전하기
VMware에서는 기본적으로 물리 서버간 VM 이동을 위한 소프트웨어를 제공하고 있다. 복제가 가능한 경우라면 시간이 좀 걸릴 뿐 이 툴로도 충분히 VM을 옮길 수 있다. vCenter Converter 라는 툴이며 Online 상태에서도 이전도 가능한 것으로 보인다. 사용 중인 것 중에 가벼운 VM은 이걸로 이동을 해보았다. 30GB 정도 하는 VM을 Offline 상태로 이전하는데 20분이 채 안 걸렸다. 꽤 만족할만한 수준이다. vCenter Converter Standalone은 무료이므로 ESXi를 사용하고 있다면 좋은 선택이라고 생각한다. 혹시나 해서 문제가 생기고 있는 VM도 이걸로 이전해 보았는데 역시나 실패했다. 어렵지만 가상화의 내부로 들어가서 손으로 직접 옮겨야 하는 상황이 되었다.
도커 이전하기
주된 서비스들은 대부분 도커로 실행 중이었던 것이 그나마? 문제를 좀 쉽게 만들어 주었다. 컨테이너 하나씩 옮길 수 있으니까.
도커는 크게 이미지와 컨테이너로 구분할 수 있는데 이미지는 레지스트리를 이용해 복제하기 쉽다. 하지만 컨테이너를 이전 하는 것은 쉽지 않은 일이다. 아무래도 컨테이너는 실행 중인 프로세스 같은 거니까 그런 것 아닐까 싶다. export/import 도 해보았지만 볼륨은 복제되지 않는 것 같고 export된 컨테이너는 설정 정보가 소실된다는 문제가 있다. 볼륨은 쉽게 복제할 수 있어서 괜찮은데 설정 정보는 그렇지 않다. Dockerfile이 있으면 그걸 사용해서 다시 빌드하면 되므로 export/import가 가능하지만 그렇지 않으면 설정을 inspect로 확인해 다시 복원해야 하는데.. 쉽지 않은 길이다.
그래서 선택한 마이그레이션 전략은 기존 이미지와 같은 버전의 이미지를 사용(latest 말고 버전 지정 tag)하고, 볼륨으로 외부화된 파일은 복사하여 이전, 나머지 중요한 파일만 컨테이너에서 꺼내서 수동으로 복사하는 것이다.
도커 매뉴얼에 설명되어 있는 볼륨에 대한 개념도이다. 볼륨이라는 용어가 약간 혼용되어 사용된다. 도커에서 파일시스템 외부화를 위해 호스트의 파일시스템을 이용하는 것을 볼륨 이라고 하고 그 방식은 bind mount와 volume 이 있다. 음… volume 방식으로 volume을 할 수 있다니..이해하는데 문제는 없지만 용어 정리가 필요해 보인다.
두 방식 모두 호스트의 파일 시스템을 사용하는 것은 동일하다. 컨테이너를 지우더라도(docker rm) 볼륨의 파일들은 삭제되지 않는다. 같은 이미지와 설정으로 다시 컨테이너를 실행하면 기존 서비스를 그대로 복원시킬 수 있다. 두 방식의 차이는 볼륨의 경우에는 도커가 매니지를 하고 바인드 마운트는 완전 외부화된 것으로 볼 수 있다. 사용자로서 느끼기에 가장 큰 차이는 volume은 docker volume 명령어들로 제어가 되는데 bind mount는 그렇지 않은 것인 것 같다.
중요한 명령어들
- docker inspect : 컨테이너나 이미지의 구성 정보를 확인할 수 있다. volume, port, network, env 등등. volume 은 보통 사용자 데이터에 해당하므로 이를 식별하기 위해 필요하다.
- docker exec : 컨테이너에서 명령을 실행할 수 있다. 보통 bash로 들어가서 중요한 파일들을 압축해놓는 작업을 했다.
- docker cp : 컨테이너와 파일을 주고 받을 수 있다. 위에서 압축한 파일들을 호스트로 복사하는 작업을 했다.
소회
- 가상화도 그렇고 컨테이너(도커)도 그렇고.. 덕분에 서비스 이전도 전보다 훨씬 편해진 것 같다. 예전 리눅스 서버라면 이런저런 작업했던 파일들이 여기저기 널려있게 되고 이것저것 패키지 설치한 것도 그렇고 애플리케이션이 돌아가기 위한 환경을 복제하는게 상당히 고단한 작업이었는데..
- 백업은 항상 중요하다. 뭐가 언제 망가질지 모른다. 중요한 것이라면 하나 이상의 백업이 필수이다.
- 확실히 하나의 큰 덩어리 보다는 작게 여러 개 구성하는게 복잡하긴 해도 안정적이다.