자동화 된 Linux 업데이트에 대한 모범 사례 업데이트하려는 패키지를 사용 합니다. 문제

RHEL / RHEL 기반 서버의 자동 업데이트를 수행하는 방법을 찾고 있습니다.

초기 아이디어 : Puppet을 사용하여 기본 리포지토리를 비활성화하고 자체 리포지토리를 가리 킵니다. 그런 다음 ensure => latest자동 업데이트하려는 패키지를 사용 합니다.

문제 : 업데이트 (duh) 후 일부 서비스가 다시 시작되는 것을보고 있습니다.

질문 : 서비스 자동 재시작을 완화하기위한 Linux 업데이트 및 전략을보다 효과적으로 자동화하는 방법에 대한 조언이 있습니까? Puppet을 포함하는 솔루션을 선호하지만 다른 서비스를 사용해야하는 경우에는 거래 중단이 아닙니다.

편집하다

가능한 해결책 : @ voretaq7 및 @ewwhite가 제안한 많은 것을 구현하는 솔루션을 제출했습니다. 이것이 내가 가고있는 경로 인 것 같습니다. 다른 제안 사항이 있으면 의견을 말하거나 답변을 제출하십시오.

답변

일반적인 업데이트 전략은 다음과 같습니다. 로컬 리포지토리 (개발 환경에서 테스트 한 것으로 가정)가 있고 해당 리포지토리 (잘 알려진 것으로 가정)에 따라 모든 것을 업데이트합니다.

서비스 재시작은 불가피합니다. 기본 코드가 변경된 경우 해당 변경 사항을 적용하려면 서비스를 다시 시작해야합니다. 그렇게하지 않으면 결과가 더 나빠질 수 있습니다 (공유 라이브러리와 동기화되지 않은 코드를 실행하면 응용 프로그램이 중단 될 수 있음).
내 환경에서는 분기 별 패치 창을 분기마다 “모든 것을 다시 부팅하십시오!”라고 생각합니다. 창문도. 이러한 정책의 장점은 당신이 있다는 것입니다 알고 서버가 다시 시작 후 다시 올 것이다, 당신은 알고 제대로 작동합니다 (당신이 정기적으로 테스트하기 때문에).

가장 좋은 조언은 소프트웨어 릴리스를 예약하고 (꼭두각시로 “수동으로”트리거해야 함) 계획된 유지 관리 / 다운 타임을 사용자에게 알려주는 것입니다.
대안으로 (또는 이것의 일부로) 몇 개의 시스템이나 서비스를 다시 시작하고 최종 사용자에게 서비스를 제공 할 수 있도록 환경에서 중복성을 구성 할 수 있습니다. 이렇게하면 중단이 완전히 제거되지는 않지만 최소화 할 수 있습니다.

추가 된 중복성은 하드웨어 장애가 발생할 경우 오랫동안 보호 할 수없는 보호 기능을 제공합니다.

답변

패키지 업데이트 후 서비스를 다시 시작하는 데 문제가 있습니까? 배포하기 전에 소규모로 테스트하여 문제가 있는지 확인하십시오. 최근에 DenyHosts 의 rpmforge 패키지에 못생긴 문제가 있었습니다 . 실제로 yum 업데이트에서 수정본 사이의 구성 및 작업 디렉토리의 위치를 ​​변경했습니다. 그것은 완전히 원하지 않는 행동입니다. 일반적으로 RHEL의 동일한 개정판에는 너무 많은 문제가 없지만 효과를 면밀히 테스트하고 관찰하지 않으면 확신 할 수 없습니다.

다른 옵션은 서비스를 선택적으로 업데이트하는 것입니다. 예를 들어 항상 최신 패키지가 필요합니까? 업데이트 실행 이유를 이해하는 것으로 되돌아갑니다. 진짜 목표는 무엇입니까?

자체 리포지토리를 실행하면 릴리스 또는 롤아웃을 준비하고 일정을 관리 할 수 ​​있다는 장점이 있습니다. RHEL 5.6이 필요하고 5.7 미만인 하드웨어 주변 장치 또는 소프트웨어 공급 업체가있는 경우 어떻게합니까? 그것은 당신 자신의 패키지를 관리 할 때의 이점 중 하나입니다.

답변

@ 베밍 멜빈

단순화를 통해 ssh for loop 도구를 사용하여 꼭두각시를 시작 / 중지 할 필요가 없습니다.

우선 ENC에서 값이 제공되는 “noop”이라는 변수를 포함하도록 매니페스트를 변경해야합니다.

그래서 당신은 수업에서 이와 같은 것을 가질 것입니다 :

noop => $noop_status

noop_statusENC의 어디에 설정되어 있습니까 ? 값을 noop_status로 설정하면 true매니페스트는 noop 모드에서만 실행됩니다.

호스트가 100 대 또는 1000 대인 경우 대시 보드 또는 Foreman과 같은 ENC를 사용하여 “호스트 그룹”또는 “도메인”수준에서 상속하여 많은 호스트의 매개 변수를 대량으로 변경할 수 있습니다. 그런 다음 소수의 테스트 호스트에 대해 값을 “false”로 설정하여 Hostgroup 값을 재정의 할 수 있습니다.

이를 통해 모든 변경 사항이 선택된 호스트에만 적용됩니다.

중앙 위치에서 하나의 매개 변수를 변경하면 ssh for loop 도구를 사용하여 퍼펫을 켜거나 끌 필요없이 여러 호스트에 영향을 줄 수 있습니다. 안전 / 관리를 위해 호스트를 여러 그룹으로 나눌 수 있습니다.

또한 매니페스트에서 패키지 버전 번호를 하드 코딩하는 대신 ENC에 넣을 수 있습니다. 위와 마찬가지로 변경 사항을 선택적으로 적용하고 롤아웃을 관리 할 수 ​​있습니다.

더 세분성과 복잡성을 원한다면 클래스마다 매개 변수 등을 가질 수도 있습니다 noop_status_apacheClass.

include다른 클래스의 클래스 인 경우 관리하기가 어려울 수 있습니다 .

답변

@ voretaq7의 답변을 기반으로 한 가능한 솔루션 :

  1. puppet매니페스트 에 포함 된 패키지의 하드 코드 버전 번호는 자체 리포지토리에서 패키지를 유지 관리합니다.

  2. 새 버전의 패키지가 필요한 경우 (예 : 보안 강화, 고객이 요구하는 기능 등) 패키지를 리포지토리에 다운로드합니다.

  3. 테스트 서버에서 업데이트 된 패키지를 테스트하십시오.

  4. 업데이트가 테스트되면 func또는 비슷한 것을 사용 하여 영향을받는 노드 pssh에서 puppet에이전트 를 종료하십시오 .

  5. puppet새 버전의 패키지가 영향을받는 노드에 설치되도록 매니페스트를 업데이트하십시오 .

  6. 마지막으로, 실행 puppet agent --onetime && reboot사용하여 서버에 func또는pssh

이 솔루션의 결함이나 단순화 될 수있는 것이 있으면 의견을 말하고 알려주십시오.

답변