Ubuntu 이미지 선택과 배포 전 호환성 확인

주문 전에 전체 소프트웨어 요구 사항 정리하기

애플리케이션이 지원하는 Ubuntu 릴리스, 런타임과 데이터베이스 버전을 기록하세요. 네이티브 확장, 컨테이너, 백업·모니터링 도구의 아키텍처도 포함합니다. 공식 지원과 자체 시험 결과를 구분해야 합니다.

1. 애플리케이션과 확장 모듈이 지원하는 운영체제·런타임·데이터베이스를 나열합니다.
2. 모든 네이티브 구성 요소와 백업 에이전트의 CPU 아키텍처를 확인합니다.
3. 남은 유지보수 기간으로 호환되는 릴리스 후보를 좁힙니다.
4. 원하는 리전에서 제공업체가 해당 이미지와 아키텍처를 제공하는지 확인합니다.
5. 생성 후 아래 명령과 애플리케이션 테스트를 마친 다음 데이터와 트래픽을 옮깁니다.

Ubuntu 24.04 LTS는 출시 당시 기본 Python 3.12, PHP 8.3과 PostgreSQL 16을 도입했습니다. 패치 버전은 업데이트로 바뀝니다. 이전 주요 버전에서 작동하던 소프트웨어가 자동으로 호환되는 것은 아닙니다. 유지보수 기간은 LTS 비교표에서 확인하세요.

실제로 받은 이미지 식별하기

VPS 안에서 다음 읽기 전용 명령으로 배포판, 실행 중인 커널, 패키지 아키텍처와 머신 아키텍처를 확인하고 배포 기록에 남깁니다.

cat /etc/os-release
uname -r
dpkg --print-architecture
uname -m

표를 가로로 움직이면 나머지 열을 볼 수 있습니다.

커널 문자열만으로 Ubuntu 릴리스와 지원 범위를 판정할 수는 없습니다. 클라우드 전용 커널도 있습니다. amd64 전용 바이너리가 arm64에서 기본 실행된다고 가정하지 말고 Arm 빌드나 명시적으로 지원되는 대안을 확인하세요.

초기화가 정상적으로 끝났는지 확인하기

많은 이미지가 cloud-init으로 계정, 키와 네트워크를 준비합니다. 존재 여부를 먼저 확인하세요. 설치되어 있지 않다는 사실만으로 오류는 아니며 제공업체의 초기화 방식을 확인해야 합니다.

if command -v cloud-init >/dev/null 2>&1; then
    cloud-init status --long
else
    printf '%s\n' 'cloud-init이 설치되어 있지 않습니다. 제공업체의 초기화 방식을 확인하세요.'
fi

running이면 초기화가 진행 중입니다. error 또는 degraded 상태는 SSH가 작동해도 조사해야 합니다. cloud-init이 있다면 관련 로그를 확인하세요.

sudo tail -n 50 /var/log/cloud-init.log
sudo tail -n 50 /var/log/cloud-init-output.log

초기화 스크립트의 로그에 민감한 값이 있을 수 있으므로 공유 전에 가리세요. 오류 표시를 없애려고 cloud-init clean을 실행하거나 네트워크 파일을 교체하지 않습니다. 초기화 완료와 애플리케이션·데이터베이스·백업 정상 동작은 별도 확인입니다.

설치 전에 패키지 후보와 저장소 확인하기

메타데이터를 갱신한 뒤 설치하려는 구성 요소의 후보 버전과 제공 저장소를 기록합니다. apt update는 인덱스를 갱신하며 이 애플리케이션 패키지를 설치하지는 않습니다.

sudo apt update
apt-cache policy python3 php postgresql
apt-cache policy python3.12 php8.3 postgresql-16

Installed: (none)은 설치되지 않았다는 뜻이고 Candidate: (none)은 현재 패키지 소스에 후보가 없다는 뜻입니다. 임의의 저장소를 추가하기 전에 이름, 아키텍처와 Ubuntu 저장소 구성 요소를 확인하세요.

php나 postgresql 메타패키지는 기본 구현을 선택하므로 버전이 붙은 패키지도 확인합니다. 이미 설치한 프로그램은 python3 --version, php --version처럼 실제 실행 파일을 검사하세요. 데이터베이스 서버 버전은 클라이언트 도구와 다를 수 있습니다.

호환성 문제를 하나씩 분리하기

가상의 애플리케이션이 Python 3.10만 지원하고 네이티브 확장을 amd64로만 제공한다고 가정해 보겠습니다. 기본 Ubuntu 24.04 arm64 이미지는 기본 Python 3.12와 아키텍처 두 가지 조건에서 맞지 않습니다. 특정 제품의 요구 사항을 주장하는 예시는 아닙니다.

amd64로 바꿔도 Python 기본 버전은 바뀌지 않습니다. 가상 환경은 자신을 만든 인터프리터의 패키지를 분리할 뿐 Python 3.12를 3.10으로 바꾸지 않습니다. 애플리케이션 때문에 Ubuntu 시스템 Python을 교체하지 마세요.

애플리케이션 업그레이드나 별도 유지보수 계획이 있는 런타임·컨테이너를 검토하고 모든 네이티브 구성 요소를 확인합니다. 이전 Ubuntu도 남은 유지보수 기간이 있어 자동 해결책은 아닙니다. 확장 기능, 데이터베이스 작업, 예약 작업과 백업·복원을 실제로 실행해야 하며 설치 성공이나 메인 페이지 요청 하나로 충분하지 않습니다.

컨테이너와 패키지별 유지보수 계획 세우기

컨테이너는 의존성을 분리하지만 호스트 커널, 네트워크와 스토리지에 의존합니다. 선택한 플랫폼의 지원 이미지가 필요하며 에뮬레이션은 성능과 지원 가정을 바꿉니다.

데이터는 문서화한 볼륨이나 외부 저장소에 두고 일회성 컨테이너와 독립적으로 복원을 연습하세요. 재현성을 위해 버전이나 이미지 digest를 고정하되 업데이트 일정도 정합니다. 취약한 이미지를 영구 고정하는 것은 유지보수 대책이 아닙니다.

Ubuntu 릴리스 지원, Main 패키지 표준 보안 유지보수, Pro 확장 범위를 구분하세요. 외부 저장소, 내려받은 바이너리와 컨테이너는 각기 다른 유지보수 주체를 가집니다.

패키지 업데이트와 릴리스 업그레이드 구분하기

패키지 메타데이터 갱신 후 보류된 업데이트와 실패한 서비스를 확인합니다. 다음은 상태 조회이며 배포판 업그레이드를 실행하지 않습니다.

apt list --upgradable
systemctl --failed
if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

업데이트 내용을 검토해 정한 시간에 적용하고 애플리케이션을 다시 확인하세요. 서비스가 재시작될 수 있습니다. 재부팅 표시 파일은 유용하지만 없다고 모든 구성 요소가 최신이라는 뜻은 아닙니다.

릴리스 업그레이드는 복사본이나 새 서버에서 런타임, 저장소, 데이터베이스 업그레이드와 확장을 시험하세요. 최종 데이터 동기화와 되돌리는 경로에 변경 후 발생한 쓰기도 포함해야 합니다. 업그레이드 전 스냅샷에는 이후 주문이 들어 있지 않습니다.

다시 만들 수 있는 배포 기록 남기기

표를 가로로 움직이면 나머지 열을 볼 수 있습니다.

비밀 값은 기록과 분리하고 일반 설정은 버전 관리하세요. 중요한 의존성이 바뀌면 별도로 재구축해 확인합니다. 공개 실습 서버가 필요하면 Oracle 인스턴스 설정, 이미지가 준비됐다면 첫 사이트 배포로 이어집니다.