Ubuntu 템플릿과 네트워크 설정에서 만난 DHCP 중복 주소와 로그인 실패

Terraform으로 VM이 생성된 뒤에도 서버가 기대한 상태로 준비되는지는 별도 문제였다. 관리 서버에서는 고정 주소를 넣었는데 DHCP 주소가 함께 남았고, 템플릿을 복제한 VM에서는 호스트명과 계정 설정을 다시 확인해야 했다. 같은 Ubuntu라도 어떤 노드의 어느 설정을 보고 있는지부터 정리할 필요가 있었다.

빈 Netplan 화면은 파일이 없다는 뜻이었다

관리 서버의 네트워크 설정을 확인하려고 익숙한 Netplan 파일명을 열었다. 편집기에는 내용이 없었고 New File 표시가 나왔다. 기존 설정이 지워진 상황으로 보기 전에 실제 파일 목록과 적용된 구성을 확인했다. 그 이름의 파일이 없는 상태였다.

ls -la /etc/netplan/
sudo netplan get
ip -br addr
nmcli device status

이때 접속한 대상은 관리 서버였다. NFS 서버의 전용 브리지 설정을 보는 작업이 아니었다. 여러 노드를 오가며 작업할수록 파일 경로만큼 현재 호스트의 역할을 확인하는 일이 중요했다.

관리 서버를 NetworkManager로 전환하는 과정에서는 기존 설정을 확인하고 백업한 뒤, 실제 존재하는 YAML과 연결 프로필을 다뤘다. 적용 직후 주소를 보니 같은 인터페이스에 고정 주소와 DHCP 주소가 함께 붙어 있었다. 라우팅 테이블에도 같은 대역에 대해 서로 다른 source 주소의 경로가 남았다.

Netplan이 해석한 설정에는 수동 주소와 함께 dhcp4: true가 있었다. 고정 IP를 입력한 사실만으로 DHCP가 꺼진 것은 아니었다. NetworkManager 연결 프로필의 IPv4 방식을 Manual로 맞추고 주소, gateway와 DNS를 확인하는 흐름으로 수정했다.

이 작업 뒤에는 다음 단계로 진행했다. 프로필에 입력한 값만 보는 것으로는 부족했다. 적용된 설정과 커널에 실제로 올라온 주소를 함께 봐야 네트워크 상태를 설명할 수 있었다.

첫 Clone의 cloud-init은 fallback으로 끝났다

Ubuntu 템플릿을 단순 복제한 첫 VM에서는 기본 호스트명이 유지됐고 주소도 DHCP로 받았다. SSH 서비스는 active였다. cloud-init의 결과를 확인하니 한 줄의 상태만으로 설명되지 않았다.

status: done
extended_status: degraded done
detail: DataSourceNone
recoverable_errors:
  - Used fallback datasource

cloud-init 실행은 끝났지만 기대한 데이터소스로 설정을 받은 상태는 아니었다. 호스트명과 주소, datasource를 묶어 봐야 이 VM이 어떻게 준비됐는지 설명할 수 있었다. 단순 Clone 성공과 게스트 초기 설정 성공을 분리해서 보게 된 지점이었다.

다음 테스트 VM에는 VMware customization으로 호스트명과 정적 네트워크를 지정했다. 이미 생성한 테스트 VM의 선언에 바로 덧붙이기보다 별도 VM으로 진행했다. 이 설정은 네트워크와 게스트 이름을 다루는 부분이었고, 사용자 계정과 SSH 키는 템플릿 설정과 따로 준비해야 했다.

템플릿 준비 과정에서 disable_vmware_customization: false를 둘 위치도 정정했다. 처음의 별도 설정 파일 안내에서 원본 cloud.cfg 최상위를 확인하는 방식으로 바뀌었다. 그 뒤 cloud-init 상태를 정리하고 템플릿 원본을 종료한 다음 새 VM을 준비하는 순서였다. 이미 운영 중인 관리 서버와 Kubernetes 노드의 초기화 상태를 반복해서 지우는 작업으로 확장하지 않았다.

비밀번호를 바꿔도 새 VM 로그인이 실패했다

계정 문제는 네트워크가 준비된 뒤에도 남았다. 한 번은 비밀번호를 잊어 Recovery Mode로 들어가 변경했다. 이후 템플릿 암호를 바꿨는데도 새 VM 로그인이 실패했다. 템플릿에서 바꾼 값과 부팅 때 다시 적용되는 계정 정책을 함께 살펴볼 필요가 있었다.

당시에는 cloud-init의 기본 사용자 잠금 설정을 유력하게 의심했다. 기본 사용자 설정의 lock_passwd 값을 확인하고 암호를 다시 설정한 뒤 템플릿을 정리했다. 데이터가 없는 테스트 VM만 교체한 후에는 로그인이 가능해졌다.

수정 전 계정 잠금 상태까지 직접 확정한 것은 아니었다. 템플릿의 계정 설정을 점검하고 수정·재생성한 뒤 성공했다는 것이 확인한 결과다. 변경 후 성공과 단일 원인 확정은 다른 수준의 판단이었다.

템플릿 완료 기준을 게스트에서 다시 확인했다

이후에는 템플릿이 존재한다는 사실보다 복제한 VM이 어떤 상태로 올라오는지에 관심을 두게 됐다. 호스트명, 주소와 경로, cloud-init datasource, SSH 서비스와 실제 로그인까지 각각 확인할 대상이 있었다. 게스트 설정을 담당하는 계층이 다르면 같은 증상처럼 보여도 수정 위치가 달랐다.

NetworkManager를 사용한 관리 서버의 경험을 모든 Kubernetes 노드에 그대로 적용하지도 않았다. 템플릿에 NetworkManager가 없는 경우가 있었고, 뒤의 자동화에서는 해당 서비스가 활성화됐을 때만 관련 작업을 수행하도록 범위를 잡았다. 서버 역할과 현재 관리 주체를 먼저 확인한 뒤 변경하는 방식으로 정리했다.

VM을 지웠다가 다시 만들 수 있는 실습 환경은 템플릿을 점검하는 데 도움이 됐다. 그렇다고 재생성을 일반적인 복구 수단으로 삼을 수는 없었다. 데이터가 없는 테스트 VM에서 확인한 절차라는 경계를 지키고, 다음에는 로그인과 게스트 설정 결과도 같은 시점의 기록으로 남기려 한다.