13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] CentOS EOL

  • [Linux] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

    [Linux] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

    목차

    [리눅스] YUM에서 DNF로: CentOS 7에서 Rocky Linux 9로 마이그레이션

    CentOS 7에서 Rocky Linux 9로 넘어가야 하는 시점이 오면 제일 먼저 부딪히는 게 YUM DNF 마이그레이션이더라고요. 운영 서버를 오래 굴려보신 분들은 아시겠지만, 패키지 관리자(package manager) 하나 바뀌는 문제가 생각보다 큽니다. 단순히 명령어만 바뀌는 게 아니라 저장소(repository), 의존성(dependency), 자동화 스크립트, 보안 업데이트 흐름까지 전부 영향받거든요. 특히 CentOS EOL 이후에는 더 미루기 어려워졌습니다. 저도 홈랩이랑 사내 테스트 장비에서 리눅스 OS 이전을 여러 번 해봤는데, 처음엔 “yum만 dnf로 바꾸면 끝 아닌가?” 싶었다가 삽질 좀 했습니다. 이번 글에서는 Rocky Linux 9 기준으로 YUM에서 DNF로 옮길 때 무엇을 확인해야 하는지, 어떤 식으로 이전하면 덜 위험한지 경험 기준으로 정리해보겠습니다.

    CentOS 7에서 Rocky Linux 9로 YUM DNF 마이그레이션 개요 이미지

    CentOS 7 환경에서 Rocky Linux 9 환경으로 넘어가며 패키지 관리 흐름이 바뀌는 모습을 보여주는 개요 이미지입니다.

    1. 왜 지금 YUM DNF 마이그레이션을 봐야 할까요?

    여기서 중요한 포인트가 있습니다. CentOS 7은 이미 수명 주기 종료(EOL, End of Life) 상태라서, 운영 환경에 그대로 두면 보안 패치와 유지보수 측면에서 부담이 커져요. 실제로 서버를 오래 운영하다 보면 “지금 잘 돌아가는데 굳이?”라는 생각이 드는데요, 이런 시기에 더 무서운 건 조용히 쌓이는 기술 부채(technical debt)입니다.

    패키지 관리자 관점에서 보면 CentOS 7은 익숙한 YUM(Yellowdog Updater Modified, RPM 계열 패키지 관리 도구) 중심이었고, Rocky Linux 9는 DNF(Dandified YUM, 개선된 차세대 패키지 관리자)가 기본입니다. 이름만 보면 YUM의 후속 버전처럼 보이지만, 실제로 써보니까 의존성 해결 방식, 메타데이터 처리, 플러그인 사용감이 꽤 달라졌더라고요.

    • CentOS 7은 오래된 운영 환경에 익숙한 자동화가 많이 붙어 있어요.
    • Rocky Linux 9는 보안과 최신 패키지 생태계 측면에서 훨씬 유리합니다.
    • YUM DNF 마이그레이션은 명령어 치환이 아니라 운영 습관 전체를 점검하는 작업에 가깝습니다.

    2. YUM과 DNF, 쉽게 말해 뭐가 다른가요?

    쉽게 말해, YUM이 오래된 익숙한 작업 방식이라면 DNF는 그걸 좀 더 현대적으로 다듬은 도구예요. 저도 처음엔 헷갈렸는데, 실제로 써보니까 차이는 몇 가지로 정리되더라고요.

    항목 CentOS 7 / YUM Rocky Linux 9 / DNF
    기본 패키지 관리자 yum dnf
    의존성 처리 기본적이며 오래된 방식 더 개선된 의존성 해결
    메타데이터 처리 익숙하지만 구형 환경 중심 성능과 관리 편의성이 개선됨
    자동화 스크립트 영향 yum 명령 하드코딩 사례 많음 dnf 기준으로 스크립트 점검 필요
    운영 포인트 레거시 유지보수 현행 표준 운영에 가까움

    Rocky Linux 9에서 yum 명령이 아예 완전히 사라진 건 아닐 수 있어요. 다만 운영 기준으로는 DNF를 표준으로 보고 스크립트와 문서를 정리하는 게 맞습니다. 저는 이 부분을 대충 넘겼다가 자동 배포 스크립트 일부가 애매하게 남아서, 나중에 어떤 서버는 yum, 어떤 서버는 dnf를 쓰는 어정쩡한 상태가 됐더라고요. 이런 건 초기에 정리하는 게 진짜 중요합니다.

    3. 마이그레이션 전략: 인플레이스 업그레이드보다 새 환경 이전이 안전합니다

    여기서 많이 물어보시는 게 “CentOS 7을 Rocky Linux 9로 바로 올리면 되나요?”인데요, 제 경험상 신규 Rocky Linux 9 서버를 만들고 워크로드를 이전하는 방식이 훨씬 안전했어요. 특히 메이저 버전을 두 단계 가까이 건너뛰는 식의 접근은 패키지 충돌, 라이브러리 차이, 서비스 설정 변경 때문에 예상보다 위험하거든요.

    1. 현재 CentOS 7 서버에서 설치 패키지와 저장소 구성을 수집합니다.
    2. 애플리케이션, 데이터, 설정 파일을 분리해서 백업합니다.
    3. 새 Rocky Linux 9 서버를 준비합니다.
    4. DNF 기준으로 필요한 패키지를 다시 설치합니다.
    5. 서비스 설정을 이관하고 동작을 검증합니다.
    6. 컷오버(cutover, 운영 전환) 후 구 서버를 단계적으로 종료합니다.

    이 방식이 귀찮아 보여도, 장애 대응이 훨씬 쉬워요. 실패했을 때 원복(rollback)도 명확하고요.

    4. 실전 구현: CentOS 7에서 현재 상태 정리하기

    제가 직접 해보니 마이그레이션의 절반은 “현재 상태를 얼마나 정확히 기록하느냐”에서 갈려요. 특히 오래된 서버는 누가 왜 추가했는지 모르는 패키지와 서드파티 저장소(third-party repository)가 꼭 있거든요.

    4-1. 설치된 패키지 목록 백업

    rpm -qa | sort > /root/centos7-rpm-list.txt
yum repolist all > /root/centos7-repolist.txt
yum history list > /root/centos7-yum-history.txt

    이 세 파일만 있어도 나중에 정말 도움이 돼요. 특히 rpm -qa 결과는 “어떤 기능 때문에 이 패키지가 필요했는지”를 추적하는 출발점이 됩니다.

    4-2. 서비스 목록과 활성화 상태 확인

    systemctl list-unit-files --type=service > /root/centos7-services.txt
systemctl list-units --type=service --state=running > /root/centos7-running-services.txt

    운영 서버는 패키지보다 서비스가 더 중요해요. 패키지는 다시 깔면 되지만, 어떤 서비스가 자동 시작되었는지를 놓치면 전환 후에 “설치는 됐는데 왜 안 뜨지?” 상황이 바로 생기거든요.

    4-3. 설정 파일과 애플리케이션 데이터 백업

    tar czf /root/etc-backup.tar.gz /etc
mkdir -p /root/migration-notes
cp -a /var/www /root/migration-notes/ 2>/dev/null
cp -a /opt /root/migration-notes/ 2>/dev/null

    물론 실제 운영에서는 애플리케이션별 데이터 경로를 더 정확히 잡아야 합니다. 웹 서버라면 /var/www, 자체 배포 앱이면 /opt, DB면 별도 덤프가 필수죠.

    CentOS 7 서버에서 YUM DNF 마이그레이션 사전 점검을 수행하는 이미지

    이전 작업 전에 현재 서버의 패키지와 서비스 상태를 정리하는 과정을 보여주는 이미지입니다.

    5. 실전 구현: Rocky Linux 9에서 DNF 기반으로 재구성하기

    이제 새 서버 쪽입니다. Rocky Linux 9에 들어오면 운영 습관을 DNF 중심으로 재정리하는 게 핵심이에요.

    5-1. 시스템 갱신과 기본 도구 설치

    sudo dnf update -y
sudo dnf install -y dnf-plugins-core vim tar rsync

    dnf-plugins-core는 실무에서 꽤 자주 써요. 저장소 관리나 쿼리 작업할 때 진짜 편하더라고요.

    5-2. 자주 쓰는 YUM 명령을 DNF로 치환

    기존 YUM 명령 Rocky Linux 9 DNF 명령 설명
    yum install httpd dnf install httpd 패키지 설치
    yum remove httpd dnf remove httpd 패키지 제거
    yum update dnf update 패키지 갱신
    yum search nginx dnf search nginx 패키지 검색
    yum info podman dnf info podman 패키지 정보 확인
    yum repolist dnf repolist 저장소 목록 확인

    처음엔 별 차이 없어 보이죠. 근데 운영 자동화에서 이 차이가 커요. Ansible(앤서블, 자동화 도구) 플레이북이나 셸 스크립트 안에 yum이 하드코딩되어 있으면, 이참에 dnf 기준으로 정리하는 게 좋아요.

    5-3. 패키지 그룹과 저장소 확인

    sudo dnf repolist
sudo dnf group list
sudo dnf module list

    여기서 module(모듈, 버전 스트림 관리 기능) 개념이 처음엔 좀 낯설 수 있어요. 예전처럼 무조건 패키지 이름만 보고 설치하다가 원하는 버전이 안 맞는 경우가 생기거든요. 특히 언어 런타임이나 DB 클라이언트 계열은 모듈/저장소 정책을 한 번 더 확인하는 습관이 필요합니다.

    5-4. 예시: 웹 서버 재구성

    sudo dnf install -y httpd
sudo systemctl enable --now httpd
sudo systemctl status httpd

    여기서 중요한 포인트! 패키지 설치만 끝내고 만족하면 안 돼요. 서비스 활성화, 방화벽, SELinux(Security-Enhanced Linux, 보안 정책 프레임워크)까지 같이 봐야 실제 서비스가 떠요.

    sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo restorecon -Rv /var/www/html

    CentOS 7에서 대충 넘어가던 권한/보안 이슈가 Rocky Linux 9에선 더 또렷하게 드러나는 경우가 많았어요. 저도 처음엔 “분명 httpd는 떴는데 왜 페이지가 안 보이지?” 하다가 SELinux 컨텍스트(context) 때문에 한참 봤었네요.

    Rocky Linux 9에서 DNF 기반 패키지 관리와 서비스 설정을 보여주는 이미지

    Rocky Linux 9에서 DNF, systemd, firewall-cmd, SELinux를 함께 점검하는 흐름을 보여주는 이미지입니다.

    6. ⚠️ 실제로 많이 걸리는 문제와 해결법

    이 섹션은 제가 특히 강조하고 싶은 부분이에요. YUM DNF 마이그레이션 자체보다, 주변 요소에서 더 많이 막히거든요.

    6-1. 서드파티 저장소가 그대로 안 붙는 문제

    CentOS 7 시절에 붙여둔 외부 저장소가 Rocky Linux 9에서는 바로 호환되지 않는 경우가 있어요. 배포판 버전, GPG 키, 패키지 경로가 달라졌기 때문입니다.

    • 기존 .repo 파일을 그대로 복사하지 마세요.
    • Rocky Linux 9 지원 여부를 먼저 확인하세요.
    • 지원이 불분명하면 OS 기본 저장소 우선으로 재설계하는 게 안전해요.

    6-2. 패키지 이름이 달라졌거나 사라진 문제

    레거시 패키지는 이름이 바뀌거나 더 이상 기본 저장소에 없을 수 있어요. 이럴 때는 억지로 같은 이름만 찾기보다, 기능 단위로 대체 패키지를 찾는 쪽이 낫습니다.

    sudo dnf search <keyword>
sudo dnf provides '*/binary-name'

    예전엔 패키지 이름을 외워서 설치했다면, 이제는 파일 제공자(provides) 검색을 더 자주 써요. 이거 진짜 편하더라고요.

    6-3. 오래된 스크립트가 yum 전제인 문제

    배치 스크립트나 운영 문서에 이런 코드가 많이 남아 있어요.

    yum install -y rsync
if yum repolist | grep -q epel; then
  echo "repo exists"
fi

    이런 부분은 명시적으로 DNF 기준으로 바꾸는 게 좋아요.

    dnf install -y rsync
if dnf repolist | grep -q epel; then
  echo "repo exists"
fi

    호환 래퍼(wrapper)가 있더라도 운영 표준은 하나로 맞추세요. 혼용하면 나중에 문서, 인수인계, 자동화에서 꼭 꼬여요.

    6-4. SELinux와 방화벽 이슈

    사실 패키지 설치는 됐는데 서비스가 안 되는 경우, 원인은 DNF가 아니라 보안 정책인 경우가 많아요. 특히 다음 항목을 꼭 같이 봐야 합니다.

    • getenforce로 SELinux 상태 확인
    • journalctl -xeu 서비스명으로 서비스 로그 확인
    • firewall-cmd --list-all로 방화벽 규칙 확인
    • 웹/앱 데이터 경로의 컨텍스트와 권한 확인

    7. 검증: 마이그레이션 결과를 어떻게 확인할까요?

    저는 전환 작업이 끝나면 “설치됐다”가 아니라 “운영 관점에서 정상인가”를 봐요. 검증 체크리스트를 짧게라도 만드는 게 좋습니다.

    1. 필수 패키지가 DNF 기준으로 모두 설치되었는지 확인
    2. 주요 서비스가 부팅 후 자동 시작되는지 확인
    3. 애플리케이션 로그에 의존성 오류가 없는지 확인
    4. 방화벽과 SELinux 정책이 서비스 요구사항과 맞는지 확인
    5. 모니터링과 백업 작업이 새 서버에서 정상 동작하는지 확인
    dnf repolist
rpm -qa | sort
systemctl --failed
ss -tulpn
journalctl -p err -b

    이 다섯 줄만 잘 봐도 초반 점검은 꽤 돼요. 저는 여기에 애플리케이션 헬스체크(health check)까지 붙여서 최종 확인하는 편이에요. 드디어 됐다! 싶은 순간이 여기서 오죠.

    Rocky Linux 9 이전 후 YUM DNF 마이그레이션 검증 결과 이미지

    이전 후 서비스 상태와 로그를 검증하는 운영 점검 결과를 보여주는 이미지입니다.

    8. 정리와 FAQ: CentOS EOL 이후 운영 습관도 같이 바꿔야 합니다

    이번 YUM DNF 마이그레이션에서 핵심은 간단해요. CentOS 7의 레거시 운영 습관을 Rocky Linux 9 환경에 그대로 들고 오지 말자는 거예요. 패키지 관리자만 바뀌는 게 아니라 저장소 운영, 보안 정책, 자동화 기준까지 함께 정리해야 실제로 편해져요. 저도 처음엔 명령어 몇 개만 바꾸면 되는 줄 알았는데, 결국 문서와 스크립트까지 손봐야 마음이 편하더라고요.

    다음 글에서는 Rocky Linux 9로 넘어온 뒤 EPEL(Extra Packages for Enterprise Linux)이나 컨테이너 도구를 어떻게 정리하면 좋은지 다뤄볼 예정입니다. 이전 글에서 다룬 시스템 백업 전략과 함께 보시면 흐름이 더 잘 잡히실 겁니다.

    자주 묻는 질문

    • Q. CentOS 7에서 Rocky Linux 9로 바로 인플레이스 업그레이드해도 되나요?
      제가 직접 해본 기준으로는 권장하지 않아요. 새 서버를 만들고 데이터와 설정을 옮기는 방식이 훨씬 안전했습니다.
    • Q. Rocky Linux 9에서도 yum 명령을 써도 되나요?
      일부 환경에서는 동작할 수 있어도 운영 표준은 DNF로 맞추는 게 좋아요. 문서와 자동화도 함께 정리하세요.
    • Q. 가장 많이 놓치는 건 뭔가요?
      서드파티 저장소, SELinux, 자동 시작 서비스, 그리고 배포 스크립트 안의 yum 하드코딩입니다.
    YUM DNF 마이그레이션 핵심 체크포인트 요약 이미지

    CentOS 7에서 Rocky Linux 9로 옮길 때 꼭 확인할 체크포인트를 요약한 이미지입니다.

    마무리 체크리스트

    • CentOS EOL 대응이 필요한 서버인지 확인
    • 기존 YUM 기반 패키지와 저장소 목록 백업
    • Rocky Linux 9 신규 서버 준비
    • DNF 기준으로 패키지 재설치 및 저장소 정리
    • 서비스, 방화벽, SELinux, 로그까지 검증
    • 자동화 스크립트와 운영 문서를 DNF 기준으로 통일

    혹시 지금 CentOS 7 서버를 붙잡고 계신다면, 오늘은 최소한 패키지 목록이랑 서비스 목록부터 백업해보세요. 그 한 걸음이 나중에 진짜 큰 차이를 만들어요.

  • [Linux] CentOS 7에서 AlmaLinux 9로: 성공적인 서버 마이그레이션 전략과 실제 경험

    [Linux] CentOS 7에서 AlmaLinux 9로: 성공적인 서버 마이그레이션 전략과 실제 경험

    목차

    [Linux] CentOS 7에서 AlmaLinux 9로: 성공적인 서버 마이그레이션 전략과 실제 경험

    CentOS 7 AlmaLinux 9 마이그레이션 이야기가 요즘 정말 많이 나옵니다. 이유는 단순합니다. CentOS 7 EOL(End of Life, 기술지원 종료)이 이미 현실이 됐기 때문이거든요. 기존에 잘 돌아가던 서버라도 보안 업데이트가 끊기면 운영 입장에서는 그냥 두기 어렵습니다. 저도 홈랩과 업무 환경에서 비슷한 상황을 여러 번 겪었는데, 처음엔 “OS만 바꾸면 끝 아닌가?” 싶었다가 생각보다 체크할 게 많아서 삽질 좀 했습니다 ㅎㅎ

    특히 이번 글은 CentOS 7에서 AlmaLinux 9로 바로 점프하는 상황을 기준으로 정리했습니다. 결론부터 말씀드리면, 저는 이런 경우 인플레이스 업그레이드(in-place upgrade, 현재 서버를 그대로 올리는 방식)보다 병행 구축 후 이전(side-by-side migration, 새 서버를 만들고 데이터와 서비스를 옮기는 방식)을 훨씬 더 추천합니다. 실제로 써보니까 이 방식이 훨씬 덜 위험하더라고요.

    CentOS 7 AlmaLinux 9 마이그레이션 전체 아키텍처 다이어그램

    기존 CentOS 7 서버, 신규 AlmaLinux 9 서버, 데이터 동기화, 검증, DNS 또는 로드밸런서 전환 흐름을 한눈에 보여주는 개요 이미지입니다.

    1. 왜 CentOS 7 AlmaLinux 9 마이그레이션이 중요한가

    쉽게 말해 운영체제는 서버의 바닥입니다. 애플리케이션이 아무리 멀쩡해도 바닥이 낡으면 문제가 생깁니다. CentOS EOL 이후에는 보안 패치, 버그 수정, 생태계 호환성 측면에서 점점 불리해집니다. 지금 당장은 돌아가도, 어느 날 패키지 설치 하나 때문에 막히는 경우가 생겨요. 저도 예전에 오래된 저장소(repository, 패키지 보관소) 의존성 때문에 야간 작업에서 발목 잡힌 적이 있었습니다.

    AlmaLinux는 RHEL(Red Hat Enterprise Linux, 레드햇 엔터프라이즈 리눅스) 계열과의 호환성을 바탕으로 운영하기 좋은 선택지입니다. 실무 관점에서는 “얼마나 화려한가”보다 얼마나 예측 가능하게 굴러가느냐가 중요하잖아요. 그런 면에서 AlmaLinux 전환은 꽤 현실적인 선택입니다.

    • 보안 측면: 지원 종료 OS를 계속 쓰는 리스크를 줄일 수 있습니다.
    • 운영 측면: 최신 패키지와 관리 체계를 받아들이기 쉬워집니다.
    • 표준화 측면: 앞으로의 리눅스 서버 이전 작업도 훨씬 수월해집니다.

    2. 개념부터 정리: 업그레이드와 마이그레이션은 다릅니다

    여기서 중요한 포인트가 하나 있습니다. 많은 분들이 업그레이드와 마이그레이션을 비슷하게 보시는데, 실제 운영에서는 완전히 다르게 접근해야 합니다.

    구분 의미 장점 주의점
    인플레이스 업그레이드 기존 서버 OS를 바로 올림 서버 수가 적고 빠르게 시도 가능 실패 시 롤백이 까다롭고 서비스 영향이 큼
    사이드 바이 사이드 마이그레이션 신규 서버를 만들고 서비스/데이터를 이전 검증과 롤백이 쉽고 운영 안정성이 높음 초기 준비 작업이 더 필요함

    제가 직접 해보니 CentOS 7에서 AlmaLinux 9로는 새 서버를 만들고 옮기는 전략이 가장 안정적이었습니다. 이유는 간단합니다. 메이저 버전 차이가 크면 패키지 체계, 기본 설정, 런타임(runtime, 실행 환경), 보안 정책이 한꺼번에 바뀌거든요. 특히 다음 항목은 꼭 체크해야 합니다.

    • yum에서 dnf: 명령 습관은 비슷하지만 운영 방식이 미묘하게 달라집니다.
    • Python 2에서 Python 3: 운영 스크립트가 있다면 거의 필수 점검입니다.
    • 방화벽 정책: firewalld, nftables 계열 변화에 따라 기존 iptables 습관이 그대로 안 먹히는 경우가 있습니다.
    • OpenSSL/OpenSSH/PHP/MariaDB 같은 런타임 차이: 애플리케이션 호환성 검증이 필요합니다.

    3. 제가 실제로 잡았던 AlmaLinux 9 마이그레이션 전략

    처음엔 저도 “야간 점검 시간에 한 번에 올리면 되지 않을까?” 생각했었습니다. 근데 서비스가 조금이라도 복잡하면 그 접근이 위험하더라고요. 그래서 최종적으로는 아래 순서로 갔습니다.

    1. 기존 CentOS 7 서버의 서비스 목록과 의존성 파악
    2. 신규 AlmaLinux 9 서버 구축
    3. 패키지, 계정, 서비스 설정 재현
    4. 데이터 사전 동기화
    5. 테스트 도메인 또는 hosts 기반 검증
    6. 짧은 점검 시간에 최종 동기화 후 전환
    7. 문제 없으면 기존 서버는 일정 기간 읽기 전용 또는 대기 상태로 유지

    이 방식의 장점은 명확합니다. 언제든 이전 상태로 돌아갈 수 있다는 거예요. 드디어 됐다 싶어도 사람 일은 모르거든요. 실제 운영은 “성공”보다 “실패했을 때 얼마나 빨리 회복하느냐”가 더 중요합니다.

    4. 실전 구현: CentOS 7 AlmaLinux 9 마이그레이션 준비

    4-1. 기존 서버 인벤토리 정리

    먼저 해야 할 일은 감으로 움직이지 않는 겁니다. 서비스 포트, 패키지, 크론(cron, 주기 실행 작업), 사용자 계정, 마운트 정보를 뽑아두세요. 저는 아래처럼 기본 자료부터 수집했습니다.

    hostnamectl
cat /etc/centos-release
ip addr
ss -tulpn
rpm -qa | sort > /root/pkglist-centos7.txt
systemctl list-unit-files --type=service > /root/services-centos7.txt
crontab -l
ls -al /etc/cron.d/
getent passwd > /root/passwd.snapshot
getent group > /root/group.snapshot
df -h
mount

    이 단계에서 중요한 건 “무엇이 설치돼 있는가”보다 실제로 무엇이 쓰이고 있는가입니다. 설치만 돼 있고 안 쓰는 패키지는 꽤 많습니다. 이걸 정리해두면 AlmaLinux 전환 후 서버가 훨씬 깔끔해집니다.

    4-2. 신규 AlmaLinux 9 서버 기본 세팅

    새 서버는 기존 서버를 그대로 복제하려 하지 말고, 필요한 것만 다시 만든다는 느낌으로 가는 게 좋습니다. 저도 처음엔 예전 설정을 몽땅 복붙했다가 SELinux(Security-Enhanced Linux, 보안 강제 정책)와 서비스 경로 차이 때문에 다시 정리했었네요.

    dnf update -y
hostnamectl set-hostname new-app01.example.local
timedatectl set-timezone Asia/Seoul
dnf install -y rsync vim tar curl wget firewalld policycoreutils-python-utils
systemctl enable --now firewalld
systemctl enable --now sshd

    계정과 SSH 키도 이 시점에 맞춰둡니다.

    useradd -m deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chown -R deploy:deploy /home/deploy/.ssh
    CentOS 7 AlmaLinux 9 마이그레이션을 위한 AlmaLinux 9 신규 서버 구성 이미지

    AlmaLinux 9 신규 서버에서 기본 패키지 설치, firewalld 활성화, 호스트명 설정이 끝난 초기 구성 단계를 보여주는 이미지입니다.

    4-3. 애플리케이션 설정과 데이터 이전

    데이터 이전은 보통 rsync(알싱크, 파일 동기화 도구)를 많이 씁니다. 증분 복사(incremental copy, 바뀐 부분만 다시 전송)가 가능해서 정말 편하더라고요. 서비스 종류에 따라 디렉터리만 옮길지, DB를 별도로 덤프(dump, 내보내기)할지는 달라집니다.

    rsync -avzH --numeric-ids /etc/nginx/ root@new-app01:/etc/nginx/
rsync -avzH --numeric-ids /var/www/ root@new-app01:/var/www/
rsync -avzH --numeric-ids /data/ root@new-app01:/data/

    DB는 파일 복사보다 논리 백업(logical backup, SQL 기반 백업) 쪽이 더 안전한 경우가 많습니다.

    mysqldump --all-databases --single-transaction --routines --triggers > all.sql
scp all.sql root@new-app01:/root/
mysql < /root/all.sql

    웹 서비스라면 설정 파일을 옮긴 뒤 문법 검사를 먼저 합니다.

    nginx -t
apachectl configtest
systemctl daemon-reload
systemctl enable --now nginx

    여기서 제가 많이 하는 방식은 운영 DNS를 바로 바꾸지 않고 hosts 파일이나 임시 도메인으로 먼저 붙어보는 것입니다. 이 단계에서 80% 문제를 잡아요.

    5. ⚠️ 실제로 자주 막히는 문제와 해결법

    이 섹션은 진짜 중요합니다. 문서만 보면 다 쉬워 보이는데, 실전에서는 작은 차이 때문에 시간이 녹습니다.

    5-1. SELinux 때문에 서비스는 뜨는데 동작이 이상한 경우

    처음엔 이게 뭔가 싶었는데, 프로세스는 살아 있는데 파일 접근이 막혀서 웹이 비정상 동작하는 경우가 있더라고요. 저는 로그부터 확인했습니다.

    getenforce
ausearch -m avc -ts recent
journalctl -xe

    무작정 비활성화하기보다 컨텍스트(context, 보안 레이블)를 먼저 맞춰보는 게 훨씬 낫더라고요.

    restorecon -Rv /var/www
semanage fcontext -a -t httpd_sys_content_t "/data/web(/.*)?" 
restorecon -Rv /data/web

    5-2. 예전 스크립트가 Python 2 기준인 경우

    CentOS 7 시절에 만든 운영 스크립트가 꽤 오래 살아남는 경우가 많죠. 근데 AlmaLinux 9로 오면서 Python 3 기준으로 정리해야 할 때가 많습니다. 저도 백업 스크립트 하나가 print 문법 때문에 바로 죽어서 순간 멈칫했습니다.

    • 쉘 스크립트로 대체 가능한지 먼저 검토
    • Python 스크립트라면 shebang과 모듈 의존성 점검
    • 가상환경(virtual environment, 독립 실행 환경) 필요 여부 확인

    5-3. 방화벽 규칙이 예전과 다르게 느껴지는 경우

    서비스는 정상인데 외부에서 접속이 안 되는 상황, 생각보다 흔합니다. 이럴 때는 애플리케이션만 보지 말고 포트 리슨(listen, 대기 상태) 여부, firewalld 규칙, 보안 그룹 또는 상위 네트워크 정책까지 같이 봐야 합니다.

    ss -tulpn
firewall-cmd --get-active-zones
firewall-cmd --list-all
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

    5-4. 패키지 이름은 비슷한데 설정 경로가 미묘하게 다른 경우

    이거 꽤 귀찮습니다. 특히 예전 블로그 글만 보고 따라 하면 안 맞는 경우가 있어요. 그래서 저는 항상 패키지 설치 후 기본 설정 파일 위치와 systemd(unit, 서비스 정의) 이름부터 확인합니다.

    rpm -qc nginx
systemctl status nginx
systemctl cat nginx
    CentOS 7 AlmaLinux 9 마이그레이션 트러블슈팅과 SELinux 점검 이미지

    마이그레이션 중 흔히 만나는 SELinux, 방화벽, 파일 동기화 문제를 점검하는 실제 운영자 시점의 트러블슈팅 이미지입니다.

    6. 검증: 전환 전에 꼭 확인한 체크리스트

    제가 실제로 써보니까 AlmaLinux 마이그레이션 성공 여부는 전환 직전보다 전환 전에 얼마나 검증했는가에서 갈리더라고요. 아래 체크리스트는 꼭 추천드립니다.

    1. 서비스 프로세스가 정상 기동하는가
    2. 기존 포트와 동일하게 리슨 중인가
    3. 웹, API, 배치, DB 연결이 모두 정상인가
    4. 로그 경로와 로그 로테이션(log rotation, 로그 순환)이 정상인가
    5. 백업 스크립트와 크론 작업이 정상 동작하는가
    6. 모니터링 대상과 알림 규칙이 새 서버에 반영됐는가
    7. TLS/인증서, 권한, SELinux, 방화벽 정책이 검증됐는가

    저는 간단한 검증 스크립트도 만들어서 썼습니다.

    #!/bin/bash
set -e
curl -I http://127.0.0.1
systemctl is-active nginx
systemctl is-active mariadb
ss -tulpn | grep -E ":80|:443|:3306"
test -f /var/log/messages

    그리고 전환 직전에는 한 번 더 최종 동기화를 했습니다.

    systemctl stop nginx
rsync -avzH --delete /var/www/ root@new-app01:/var/www/
rsync -avzH --delete /etc/nginx/ root@new-app01:/etc/nginx/

    이후 DNS를 바꾸거나, 로드밸런서(load balancer, 트래픽 분산 장비) 백엔드를 교체하는 식으로 컷오버(cutover, 실제 전환)를 진행했습니다.

    CentOS 7 AlmaLinux 9 마이그레이션 완료 후 검증 대시보드 이미지

    마이그레이션 완료 후 시스템 서비스 상태, 포트 오픈 현황, 웹 응답, 기본 모니터링 지표가 정상임을 보여주는 검증 이미지입니다.

    7. 결과: AlmaLinux 전환 후 체감했던 변화

    결과적으로는 꽤 만족스러웠습니다. 물론 마이그레이션 자체가 즐거운 작업은 아니죠. 근데 막상 끝나고 나면 얻는 게 분명합니다.

    • 지원 종료에 대한 불안감이 줄어듭니다.
    • 새로운 패키지와 운영 표준으로 정리하기 쉬워집니다.
    • 불필요한 설정과 레거시(legacy, 오래된 자산)를 털어낼 기회가 됩니다.
    • 향후 자동화(Ansible 같은 구성관리 포함) 기반 정리가 쉬워집니다.

    특히 CentOS 7 AlmaLinux 9 마이그레이션은 단순히 OS 이름만 바꾸는 일이 아니라, 운영 환경을 한 번 건강하게 정리하는 계기였습니다. 저도 처음엔 귀찮아서 미루고 싶었는데, 정리하고 나니 다음 서버도 훨씬 자신 있게 이전하게 되더라고요.

    8. 정리와 FAQ: 리눅스 서버 이전 전에 꼭 기억할 것

    CentOS 7 AlmaLinux 9 마이그레이션에서 제가 가장 강조하고 싶은 건 딱 세 가지입니다. 첫째, 무리해서 한 번에 올리지 말 것. 둘째, 새 서버를 만들고 검증한 뒤 전환할 것. 셋째, 롤백 경로를 미리 확보할 것. 이 세 가지만 지켜도 실패 확률이 크게 줄어듭니다.

    혹시 이런 경험 있으신가요? 설정은 맞는 것 같은데 전환 후에만 이상하게 꼬이는 상황이요. 대부분은 서비스 자체보다 권한, 경로, 방화벽, 이름 해석 같은 주변 요소에서 터집니다. 그래서 저는 항상 체크리스트와 검증 스크립트를 같이 둡니다. 이거 진짜 편하더라고요.

    자주 묻는 질문

    • Q. 인플레이스 업그레이드보다 신규 구축이 왜 더 낫나요?
      A. 메이저 버전 차이가 큰 경우 변수도 많아집니다. 신규 구축은 검증과 롤백이 쉬워서 운영 리스크가 낮습니다.
    • Q. 모든 설정 파일을 그대로 복사하면 되나요?
      A. 권장하지 않습니다. 필요한 설정만 검토해서 옮기는 편이 안전합니다.
    • Q. AlmaLinux 전환 전에 가장 먼저 볼 것은 뭔가요?
      A. 서비스 의존성, 런타임 버전, 백업/복구 절차입니다.

    다음 글에서는 AlmaLinux 전환 이후 체크해야 할 보안 하드닝(hardening, 보안 강화) 항목이나 Ansible 기반 자동화 이전 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 백업 검증 루틴과 함께 보시면 더 도움이 될 겁니다.

    CentOS 7 AlmaLinux 9 마이그레이션 요약 인포그래픽

    CentOS 7과 AlmaLinux 9의 운영 차이, 추천 마이그레이션 방식, 전환 전후 체크포인트를 요약한 인포그래픽 이미지입니다.