13장. RHEL bootc 이미지에 대한 소프트 재부팅 수행

이미지 모드에서 실행되는 시스템은 사용자 공간만 재부팅하는 패키지 모드 시스템과 동일한 방식으로 소프트 재부팅을 수행합니다. 차이점은 컨테이너 이미지에서 먼저 이러한 패키지 및 서비스에 대한 업데이트를 빌드해야 한다는 것입니다. 예에서는 패키지 및 서비스 업데이트를 적용하고 다시 시작하는 방법을 보여줍니다.

사용자 공간 패치는 사용자 애플리케이션 및 공유 라이브러리의 보안 취약점과 버그를 해결합니다. 패치를 적용하면 새 코드를 로드하려면 소프트 재부팅 또는 프로세스 재시작이 필요합니다. 예를 들면 다음과 같습니다.

문제: 웹 서버, 데이터베이스, SSH 데몬과 같은 OpenSSL을 사용하는 애플리케이션은 다시 시작하지 않고 노출된 상태로 유지되어 취약한 공유 라이브러리를 계속 사용합니다.

소프트 재부팅 솔루션: dnf 업데이트 openssl 을 수행한 후 소프트 재부팅은 종속 프로세스를 종료합니다. 그런 다음 systemd는 이러한 서비스를 다시 시작하여 새로운 패치된 libssl.so 및 libcrypto.so 라이브러리를 자동으로 로드하여 전체 시스템을 재부팅하지 않고 시스템을 보호합니다.

문제: Glibc는 시스템의 거의 모든 프로그램이 의존하는 기본 사용자 공간 구성 요소입니다. glibc의 취약점은 전체 시스템에 영향을 미칩니다. 하나 또는 두 개의 서비스를 다시 시작하는 것만으로는 충분하지 않습니다. 다른 많은 프로세스가 여전히 취약하기 때문입니다.

소프트 재부팅 솔루션: dnf 업데이트 glibc 이후 소프트 재부팅은 모든 프로세스가 다시 시작되고 새 glibc에 다시 연결할 수 있도록 하는 가장 안정적인 방법입니다. 이로 인해 업데이트가 모든 곳에 적용되도록 보장하면서 전체 시스템 재부팅 시간이 길어집니다.

사용 사례: 보안 또는 성능을 위해 dbus-broker 데몬 업데이트.

문제: Dbus-broker는 중요한 시스템 서비스입니다. 업데이트는 일반적으로 탄력적이지만 프로토콜의 민감도는 브로커 및 관련 서비스를 다시 시작해야 합니다.

소프트 재부팅 솔루션: 소프트 재부팅은 systemd 를 사용하여 dbus-broker 및 모든 종속 서비스 및 애플리케이션을 올바르게 다시 시작하여 완전히 종료되고 다시 시작됩니다.

이미지 기반 시스템에서는 다음 두 가지 방법으로 업데이트를 관리할 수 있습니다.

systemd 소프트 재부팅 메커니즘은 kexec 재부팅과 다릅니다. kexec 및 커널 전환 기능은 사용자 공간만 재시작하므로 systemd 소프트 재부팅에서는 사용할 수 없으며 커널은 변경되지 않습니다. 이를 통해 지속성을 보장하고 하드웨어를 재설정하지 않고도 커널을 변경할 때 발생할 수 있는 잠재적인 복잡성과 불일치를 방지할 수 있습니다. 새 커널 버전이 포함된 업데이트된 OS 이미지에는 기존의 전체 재부팅이 필요합니다.