푸는 것은 "로컬 환경을 어떻게 맞추는가"

개발을 하다 보면 클러스터의 동작을 노트북에서 다시 만들어야 할 때가 자주 온다. 이미지를 돌려 무엇을 하는지 보고, 배치 설정이 정말 적용되는지 확인하고, 어떤 Kubernetes 판이 올라오기 전에 미리 시험한다. Rancher Desktop 은 그것을 하나의 데스크톱 도구로 모았다. 창 뒤에서 가벼운 가상 기계를 띄우고 그 안에서 컨테이너 엔진과 Kubernetes 를 돌리며, 밖으로는 화면과 명령줄 도구를 함께 준다. 둘 다 같은 것을 본다.

값은 컨테이너가 도는 데 있지 않다. 그것은 다른 도구도 한다. 값은 환경이 "설정하고 되돌릴 수 있는 것"이 되고, "조립한 뒤 계속 돌봐야 하는 것"으로 남지 않는다는 데 있다. 엉뚱한 명령으로 로컬 클러스터를 이상한 상태로 만들어 놓고 오후를 통째로 고치는 데 쓴 사람이라면 그 차이를 안다.

같은 부류보다 고를 것이 많다

보통 정해져 버리는 두 가지를 여기서는 사용자에게 맡긴다. 컨테이너 엔진은 containerd 와 nerdctl 조합이어도 되고, dockerd 와 익숙한 docker 명령줄 조합이어도 된다. Kubernetes 판은 목록에서 고르고 필요할 때 바꿀 수 있다. 특정 소판에 고정된 운영 환경을 재현해야 하는 사람에게 두 번째 항목이 이 도구를 쓸 수 있느냐를 가른다.

화면에서는 이미지와 컨테이너, 볼륨을 관리하고 포트 전달을 설정하며 클러스터가 무엇을 하는지 본다. 로컬에서 빌드한 이미지는 저장소로 밀어 올리지 않아도 클러스터에서 보인다. 태그를 붙이고 올리는 한 바퀴가 일상 개발의 순환에서 통째로 빠진다. 작은 일이지만 무엇인가를 시험해 보는 횟수가 크게 달라진다.

도구 구성과 만든 방식

흔히 쓰는 명령줄 도구의 새 판이 함께 들어온다. docker, nerdctl, kubectl, helm. 편의처럼 보이지만 실은 재현성의 문제다. 도구 판이 클러스터의 기대와 맞아 있으면 코드와 아무 상관 없는 실패가 솟지 않는다.

밑바탕은 통째로 가상 기계 위에 있다. macOS 와 Linux 에서는 Lima, Windows 에서는 Linux 용 하위 체계의 두 번째 판이다. 이 선택이 이점과 비용을 함께 설명한다. 가상 기계는 깨끗한 경계와 버리고 다시 지을 수 있는 환경을 주는 대신, 호스트 쪽의 저장 공간과 메모리를 가져간다. 설정에는 자동 시작, 가상 기계 자원 배분, 모든 것을 처음 상태로 되돌리는 재설정이 있다.

프로젝트는 Apache 허가로 공개되어 어떤 규모의 조직에서도 무료로 쓸 수 있다. 이 점은 개인 노트북보다 회사 안에서 더 실하다.

어느 줄에 타고, 무엇을 피할까

1.x 계열이 현재의 안정된 줄이고 나아가는 속도가 꽤 빠르다. 빠르게 움직이는 생태에 붙어 있는 도구로서는 정상이다. 다음 큰 판의 미리보기도 진행 중이고, 그 구조는 흥미로운 방향으로 바뀐다. 핵심 작업이 가상 기계와 컨테이너 엔진, 클러스터를 맡는 배경 프로그램으로 옮겨 가고, 그 프로그램을 표준 Kubernetes 인터페이스로 부를 수 있게 된다. 손님 체계도 바뀌어 다른 공개 기업용 배포판이 된다.

프로젝트는 그 미리보기를 초기 기술 미리보기로 표시하고 운영 환경에는 맞지 않는다고 밝힌다. 게다가 두 번 읽어야 할 단서를 붙인다. 미리보기 판 사이에서는 올릴 수 없고 되돌려 다시 설치하는 수밖에 없다. 매일 쓰는 용도라면 안정된 줄에 머물고 미리보기는 멀리서 지켜보는 편이 좋다.

이 도구가 하는 일은 "운영과 같은 컨테이너 환경을 손에 둔다"는 문제를 고를 수 있고 다스릴 수 있는 문제로 바꾸는 것이다. 맞바꿈은 분명하다. 저장 공간과 메모리를 조금 내주고, 언제든 되돌릴 수 있고 판을 직접 고르는 로컬 클러스터를 받는다.