CentOS 8: 서둘러 마이그레이션하는 것보다 연장 지원이 더 나은 이유

이제 더 이상 지원되지 않는데도, 그리고 명백한 위험에도 불구하고 여전히 CentOS 8을 사용하시나요? 어떤 면에서는 이해할 수 있습니다. Red Hat은 CentOS 8의 공식 지원 기간을 10년에서 2년으로 줄이면서 OS의 Lifecycle이 종료된다는 사실을 불과 1년 전에 알렸기 때문에 모두를 놀라게 했습니다.

1년은 긴 시간처럼 느껴지지만 바쁜 시스템 관리자에게는 순식간에 지나가는 시간이며, 시스템 마이그레이션을 테스트하는 데 특별히 긴 시간은 아닙니다. 하지만 최근에 발견된 LUKS 버그로 인해 작업을 진행하게 되었다면, 이 글을 통해 잠시 멈추고 기다리라고 말씀드리고 싶습니다. 서두르고 신중하게 고려하지 않은 마이그레이션은 재앙이 될 수 있습니다.

마이그레이션하기 전에 고려해야 할 사항과 마이그레이션 프로세스를 서두르는 것보다 Lifecycle을 연장하는 것이 더 나은 선택인 이유를 계속 읽어보세요.

CentOS 8 마이그레이션 옵션

CentOS 8에 대한 옵션을 아직 고려하지 않으신 분들을 위해 간단히 다시 한 번 알려드리겠습니다. 이제 CentOS 8은 Lifecycle이 종료되었으므로 향후 패치 및 업데이트가 제공되지 않으므로 직접 패치를 구축하지 않는 한 새로운 익스플로잇에 취약해질 수 있습니다.

CentOS 9로 전환하는 것은 옵션이 아니며, CentOS 9는 존재하지 않으며, 상당수의 CentOS 8 사용자에게는 CentOS Stream도 옵션이 아닙니다. 그러면 CentOS와 바이너리 호환이 되지 않는 Linux 배포판(예: Ubuntu, SUSE)이나 호환되는 배포판(예: RHEL, Oracle Linux, 록키 Linux, Alma Linux) 중 하나를 선택할 수 있습니다.

이전 글에서 설명한 것처럼 바이너리 호환성을 사용하면 전환 시 훨씬 수월하게 작업할 수 있으며, 만족스러운 공급업체를 찾을 수 있다면 바이너리 호환 배포판으로 전환하는 것을 권장합니다.

이론적으로는 쉽게 전환할 수 있습니다. 실제로는...

CentOS 8과 바이너리 호환이 가능한 OS로 전환하는 경우 프로세스는 비교적 간단합니다. 배포판마다 전환하는 방법은 다르지만, 다행히 CentOS 8과 바이너리 호환되는 많은 바이너리 배포판이 간단한 전환 경로를 제공한다는 점은 다행입니다.

일반적으로 스크립트를 실행하는 것만 있으면 됩니다. Oracle 및 RHEL을 포함한 공급업체는 CentOS 8을 실행하는 머신을 해당 배포판으로 전환하는 스크립트를 제공합니다. 마찬가지로 AlmaLinux와 RockyLinux 프로젝트 모두 전환을 위해 실행할 수 있는 간단한 스크립트를 제공합니다. 어쨌든 이론상으로는 전환이 매우 쉬우며 대량의 머신도 약간의 노력으로 전환할 수 있습니다.

하지만 숙련된 기술 전문가라면 누구나 알다시피 악마는 디테일에 있습니다. 예, 스위치가 완벽하게 작동할 가능성이 높습니다. 그러나 작지만 중요한 문제들이 무수히 많이 발생하여 사용자의 발목을 잡을 수 있습니다.

발생할 수 있는 몇 가지 문제

기존 배포판에서 마이그레이션할 때는 항상 위험이 따릅니다. 새 배포판이 바이너리 호환 배포판인 경우에도 마찬가지입니다. 수많은 일이 잘못될 수 있습니다.

실행 중인 애플리케이션의 사소한 결함일 수도 있고, OS의 모든 것이 정확히 일치해야 하는 문제일 수도 있습니다. 또는 더 이상 지원되지 않는 특정 하드웨어 장치를 지원하기 위해 시스템에 배포된 드라이버일 수도 있습니다.

실제로 근본적인 문제는 새 시스템에 제대로 설치할 수 없거나 배포 이름에서 "CentOS 8" 텍스트를 특별히 검색하기 때문에 새 시스템에서 전혀 실행되지 않는 애플리케이션이나 서비스(매우 일반적인 시나리오)와 같이 간단할 수 있습니다.

기술적으로는 사소한 문제이지만 마이그레이션이 실패할 수 있기 때문에 실질적인 위험이 될 수 있습니다. 비즈니스에 중요한 애플리케이션이 특정 배포판과 호환되는지 확인하기 위해 간단한 검사만 수행한 후 정당한 이유 없이 시작을 거부할 수 있습니다.

이 문제를 수정하는 것은 간단한 코드 변경이지만, 애플리케이션 개발자가 코드를 수정할 때까지는 해당 배포가 바이너리 호환이 되더라도 새 배포에서 애플리케이션을 사용할 수 없습니다.

OS 마이그레이션을 준비하는 방법

따라서 마이그레이션을 수행한 후 애플리케이션이 실행되지 않는 상황에 쉽게 처할 수 있습니다. 실사에서는 마이그레이션 전에 테스트를 수행하도록 요구하며, 마이그레이션 전에 테스트를 수행하지 말 것을 제안하는 것은 아닙니다.

진짜 문제는 테스트를 수행할 시간이 있느냐는 것입니다. 시간, 리소스, 예산의 제약으로 인해 테스트를 소홀히 하기 쉽습니다. 고려해야 할 사항이 많습니다.

물론 전체 백업으로 시작됩니다. 이미 백업이 마련되어 있을 가능성이 높지만, 백업이 필요한 경우 백업이 성공적으로 복원될 것이라고 얼마나 확신할 수 있는가라는 다음 질문으로 이어집니다. 이는 테스트했을 수도 있고 테스트하지 않았을 수도 있는 사항이며 마이그레이션 전에 반드시 테스트해야 합니다.

다음으로, 워크로드에 의존하는 모든 애플리케이션을 테스트해야 합니다. 일부 CentOS 사용자의 경우, 특히 애플리케이션이 상호 의존적인 경우 이 과정이 상당히 복잡할 수 있습니다. 마이그레이션 후 재부팅하자마자 오류가 나타나는 것은 아니며, 실제 사용을 통해서만 이러한 오류를 인지할 수 있으며 시간이 지남에 따라 오류가 발생할 수도 있습니다.

즉, 마이그레이션과 관련된 실제 단계는 스크립트를 실행하는 것만큼 간단할 수 있지만 OS 마이그레이션을 빠르게 수행할 수 있는 빠른 방법은 없습니다.

 어쨌든 CentOS 8 시스템은 이미 빌린 시간으로 실행되고 있습니다.

기다리지 말고 위험을 감수하되 서두르지도 마세요.

 한 순간도 더 이상 적극적인 지원 없이 CentOS 8을 실행하고 앉아 있을 수는 없습니다. LUKS 취약점은 심각한 위험이며 마지막으로 등장하는 취약점은 아닐 것입니다. 반면에 마이그레이션을 서두르는 것은 분명히 현명하지 않습니다. 하지만 시간을 벌 수 있는 대안이 있습니다.

조직에서 CentOS 8에서만 지원되는 특정 애플리케이션 또는 하드웨어 디바이스를 사용하는 경우, 가장 좋은 방법은 예를 들어 TuxCare의 ELS(Lifecycle 연장 지원) 서비스를 배포하여 보안 업데이트를 계속 사용할 수 있도록 지원을 연장하는 것입니다.

어떤 면에서는 CentOS 8의 EOL이 이미 백미러에 표시되어 있기 때문에 이 시점에서는 선택의 여지가 없습니다. 공식 지원 없이 CentOS 8을 실행하면 불과 몇 주 안에 준수해야 하는 모든 규정 준수 표준을 위반하게 됩니다. 따라서 현재는 취약점 발표와 패치 배포 사이에 30일이라는 허용 가능한 지연 기간이 있지만, 이는 곧 변경될 것입니다(몇 주 또는 몇 달이 아닌 며칠 내로).

TuxCare의 ELS 서비스를 선택하든, 다른 제공업체의 유사한 서비스를 선택하든, 패치를 구축하기 위해 타사를 고용하든, 무언가를 해야 합니다. TuxCare는 가격이 저렴하고 설정이 간단하며 워크로드에 방해가 되지 않습니다.