저는 Centos 프로덕션 웹 서버를 실행하고 있습니다. 업데이트 실행에 대한 모범 사례가 무엇인지 궁금합니다. 이를 자동화하려면 yum-cron 또는 yum-updatesd를 사용해야 합니까? 아니면 업데이트로 인해 사이트가 망가질 위험이 있으므로 테스트 서버에서 하고 매주 수동으로 업데이트를 실행하는 것이 더 나은가요?
대부분의 서버는 공식 저장소만 사용하지만 일부 서버에는 사용할 수 없는 PHP 모듈용 원자 저장소가 있습니다. 이 상황에서 가장 좋은 것은 무엇입니까? PHP 모듈에만 Atomic을 사용하도록 yum을 설정할 수 있나요? 나는 모든 것이 Atomic의 최첨단 기능으로 업데이트되는 것을 원하지 않습니다. 오히려 Centos(또는 실제로 Red Hat)가 내 서버를 안정적이고 안전하게 유지하는 것을 신뢰하고 싶습니다.
답변1
두 가지 접근 방식에는 장단점이 있으며, 어떤 접근 방식이 자신에게 가장 적합한지 알아보려면 시스템 아키텍처를 자세히 살펴봐야 합니다. 어느 쪽으로 가든지 이해해야 해왜어떤 방법을 선택했고, 그 단점을 보완하기 위해 어떤 단점이 있었는지.
고려해야 할 사항은 다음과 같습니다.
보안 업데이트는언제나어떤 식으로든 빨리 적용하세요. 어떤 이유로든 서버가 보안 업데이트를 즉시 적용하지 않는 경우 시스템 관리자 습관을 수정하십시오.
Distro 업데이트는 일반적으로 양호하며, 특히 공식 소스의 업데이트는 더욱 그렇습니다. 적용하는 것이 불편하다면 필요에 가장 적합한 배포판을 사용하고 있지 않은 것일 수 있습니다. 귀하의 접근 방식과 일치하는 분포를 사용해야 합니다. 즉, 업데이트가 귀하에게 가장 큰 이익이 된다고 믿을 수 있습니다. 너무 빨리 움직이거나 소프트웨어 변경으로 인해 작업이 중단된다면 아마도 다른 배포판을 사용해야 할 것입니다.
업데이트로 인해 콘텐츠가 손상될 수 있습니다. 더 이상 사용되지 않는 기능을 사용하거나 제대로 작성하지 않은 경우 최신 소프트웨어로 마이그레이션하면 코드가 손상될 수 있습니다. 업데이트된 제품을 프로덕션 시스템에서 실행하기 전에 테스트할 수 있는 시스템 아키텍처를 고려해야 합니다.
자동 업데이트 기능을 사용하는 경우 알려진 작업 구성으로 롤백할 수 있는 방법이 항상 있어야 합니다. 일부 업데이트로 인해 프로덕션 시스템의 제품이 중단되는 경우 전체 시스템 스냅샷이 생명의 은인이 될 수 있습니다.
이것은 완전한 목록이 아니며, 단지 여러분이 생각해볼 수 있는 몇 가지 사항일 뿐입니다. 궁극적으로 이는 다른 사람이 귀하를 대신하여 내릴 수 있는 결정이 아닙니다. 귀하는 관리자입니다. 귀하의 시스템을 알아보세요. 배포판을 알아보세요.
답변2
케일럽의 말에 100% 동의합니다. 제가 작성한 추가 CentOS 관련 태그:
이 배포판은 RedHat 및 해당 패치를 기반으로 합니다. 패치 테스트는 매우 잘 이루어졌습니다. 우리는 지난 4년 동안 50개가 넘는 서버에서 CentOS 5를 사용해 왔으며 한 번도 잘못된 패치를 받은 적이 없습니다.
그러나 배포 콘텐츠만 실행하는 서버에는 매일 모든 패치를 자동으로 적용하지만 테스트 시스템이 며칠 동안 해당 구성에서 실행될 때까지 프로덕션 서버를 시작하지 않습니다(glibc 또는 커널 업데이트 후).
다른 리포지토리의 경우 이를 스테이징 디렉터리에 미러링합니다. 해당 패치는 테스트 서버에 먼저 적용됩니다. 아무 문제가 없는 것으로 판명되면 준비 디렉터리를 활성화하고 이를 프로덕션 저장소에 복사합니다.
자동 패치의 부작용은 패치된 구성 요소가 자주 다시 시작된다는 것입니다. 따라서 시작 후 구성 요소를 잘못 구성하면 다시 시작이 실패합니다.