많은 CentOS 서버의 패키지 업데이트 관리를위한 모범 사례

내 일의 일환으로 주 설정에 퍼펫을 사용하여 수십 개의 CentOS 5 서버를 관리합니다. 우리 서버의 약 절반은 다양한 장고 사이트를 호스팅하기 위해 표준화 된 설정을 가지고 있으며 나머지는 응용 프로그램의 엉망입니다.

호스팅 방식을 점차적으로 정리하고 있으며 이제 OS 수준에서 보안 업데이트를 관리하는 방법을 알아 냈습니다. 나는 cron 작업을하는 것에 조심 yum -y update하지만 시간이 걸리는 각 서버를 돌아 다니고 업데이트가있는 모든 패키지를 검토하고 싶지는 않습니다.

따라서 관련된 위험 을 최소화하고 지출해야하는 시간을 최소화 할 수있는 좋은 지름길이나 작업 관행이 있는지 궁금합니다 . 또는 다른 방법으로 말하면 제어권을 부여하면서 많은 작업을 자동화 할 수있는 도구 나 방법이 있습니다.

내가 지금까지 결정한 단계 :

• 모든 타사 리포지토리를 비활성화하고 자체 리포지토리를 설정하여 업데이트가 진행되는 것을 제어 할 수 있습니다.
• 테스트를 수행 할 수있는 프로덕션 서버 (대부분의 경우)를위한 스테이징 서버가 있습니다 (하지만 테스트가 얼마나 많은 테스트입니까?)

또한 내가 살펴본 있습니다 냠 보안 플러그인 하지만 CentOS는 작업을하지 않습니다 .

이기종 애플리케이션 배열을 실행하는 다수의 CentOS 서버에 대한 업데이트를 어떻게 관리합니까?

대부분의 환경에서 일반적으로 킥 스타트 및 설치 후 스크립트는 기본 시스템을 최신 상태로 업데이트하고 그 시점의 업데이트를 제공합니다. 일반적으로 CentOS 미러와 매일 또는 매주 동기화되는 로컬 저장소가 있습니다. 설치 시간 현재 커널 패키지를 고정하고 개별적으로 또는 필요에 따라 패키지를 업데이트하는 경향이 있습니다. 종종 내 서버에는 드라이버가 커널 버전과 밀접하게 연결된 주변 장치가 있으므로 고려해야 할 사항입니다.

CentOS 5는 지속적인 업데이트가 필요하지 않은 시점으로 발전했습니다. 또한 CentOS 5가 중단되고 있음을 명심하십시오. 업데이트 속도는 다소 느려졌으며 업데이트의 특성은 버그 수정에 더 가깝고 주요 기능 변경에 대해서는 적습니다.

따라서이 특정한 경우에 가장 먼저 할 수있는 것은 로컬 미러 / 리포지를 구축하는 것입니다. 기존 구성 관리를 사용하여 타사 저장소에 대한 액세스를 제어하십시오. 중요한 서비스 또는 공개 서비스 (ssh, http, ftp, dovecot 등)를 업데이트하도록 정책을 예약 할 수도 있습니다. 다른 모든 것에는 테스트가 필요하지만 대부분의 환경이 완전히 업데이트 / 패치 된 시스템으로 실행되지 않는다는 느낌이 듭니다.

이를 도울 수있는 많은 도구가 있습니다! 구성 관리에 의해 처리되는 것은 일반적으로 패키지 시스템과 패키지가 어디로 가는지입니다. 이 도구는 일반적으로 yum과 rpms 이상을 다루며 시간을 절약하고 많은 두통을 예방합니다!

내가 가장 친숙한 도구는 꼭두각시인데, 환경에서 거의 모든 구성을 관리하는 데 사용합니다. yum을 구체적으로 관리하기위한 몇 가지 꼭두각시 예제는 다음과 같습니다.

http://people.redhat.com/dlutter/puppet-app.html

현재 사용 가능한 여러 구성 관리 도구가 있으며, 상당히 큰 사용자 그룹이 있습니다.

• Cfengine http://cfengine.com/cfengine3
• 꼭두각시 http://puppetlabs.com/puppet/puppet-difference/
• Chef http://wiki.opscode.com/display/chef/Home (내가 아는 사람들 중 일부는 최근에 이것을 구현하고 좋아했습니다)

환경에서 구현하면 인생에 몇 년이 더 걸릴 것입니다. 잘못 구성된 시스템으로 인한 두통 수를 줄이고 쉽게 업그레이드 / 업데이트 할 수 있습니다. 이러한 도구의 대부분은 일부 감사 수준 기능도 제공 할 수 있으므로 구성 실수로 인한 수리 시간을 크게 줄일 수 있습니다.

테스트에 대한 귀하의 질문과 관련하여 우리는 일부 고객 (일반적으로 베타 고객 또는 소규모 생산 트래픽 하위 집합)으로 연결되는 준비 환경을 사용하고 있습니다. 일반적으로이 클러스터는 프로덕션에 배포하기 전에 최소 2 일 (최대 1 주일 동안 (변경의 중력에 따라)) 새 코드를 실행하도록합니다. 일반적으로 대부분의 오류를 발견하는 데 걸리는 시간을 알아 내면이 설정이 가장 효과적이라는 것을 알았습니다. 많이 사용되는 시스템에서는 시간이 문제가 될 수 있습니다. 대부분의 환경에서 일주일은 스테이징 / QA에서 흔하지 않은 버그조차 발견 할 수있을 정도로 길었습니다.

테스트에서 실제로 중요한 부분 중 하나는 데이터 / 사용 복제입니다. 대부분의 프로덕션 하드웨어에 스테이징 버전이 있다고 언급했습니다. 생산 데이터의 사본도 동일합니까? 당신은 그것에 대해 생산 부하를 재생할 수 있습니까? 트래픽 미러링을 사용하여 프로덕션 클러스터의 일부로 만들 수도 있습니까? 이는 일반적으로 비즈니스가 테스트 / QA에 소비하고자하는 자원의 양 사이에서 직접적인 절충점이됩니다. 테스트가 많을수록 자체 제한 (이유 내)을하지 말고 비즈니스가 어떤 지원을 제공하는지 확인한 다음 (10 % 더 많은 방법을 찾으십시오).