Linux 서버를 얼마나 자주 업데이트해야합니까?


56

프로덕션 서버 (메일, 웹, 데이터베이스는 모두 하나의 서버에 있음)와 테스트 서버를 모두 관리해야합니다. 둘 다 데비안을 기반으로합니다. 그러나 시스템 관리를 처음 접했을 때 최신 기능을 사용하고 버그를 수정하기 위해 업데이트해야 할 사항을 발견했을 때만 업데이트를 설치했습니다. 지금은 매우 특별한 프로세스이며, 덜 덜하고 싶습니다.

그래서 나는 그들이 무엇을하고 있는지 아는 사람들이 이것을 어떻게 처리하는지 궁금합니다. 서버에서 얼마나 자주 업그레이드를 수행합니까? 테스트와 프로덕션간에 업그레이드 프로세스가 다른가요? 항상 테스트 서버를 먼저 업그레이드합니까? 그리고 모든 소프트웨어의 전체 업데이트를 수행합니까, 아니면 선택한 업데이트 만 설치합니까?

답변:


34

apt-get update -qq를 실행합니다 . apt-get upgrade -duyq 매일. 업데이트를 확인하지만 자동으로 업데이트하지는 않습니다.

그런 다음보고있는 동안 업그레이드를 수동으로 실행하고 잘못 될 수있는 모든 사항을 수정할 수 있습니다.

패치 된 시스템을 유지 관리하는 데 대한 보안 문제 외에도 패치 사이에 시스템을 너무 오래두면 업그레이드하려는 패키지 가 많아 져서 업그레이드하거나 업그레이드하는 것보다 더 많은 것을 두려워합니다. 매주 2 번 정도 요 따라서 업그레이드를 매주 또는 우선 순위가 높은 경우 매일 업그레이드하는 경향이 있습니다. 이것은 어떤 패키지가 시스템을 고장 났는지 아는 추가적인 이점이 있습니다 (예 : 한 번에 한 쌍만 업그레이드하는 경우)

항상 덜 중요한 시스템을 먼저 업그레이드합니다. 시스템을 고칠 수없는 경우를 대비하여 "롤백 계획"도 있습니다. (대부분의 서버가 가상이기 때문에이 롤백 계획은 일반적으로 업그레이드 전에 스냅 샷 을 작성하여 필요한 경우 되돌릴 수 있음)

즉, 지난 4 년 동안 업그레이드가 한두 번만 고장 났으며 고도로 맞춤화 된 시스템에 있다고 생각합니다. 따라서 너무 편집증이 될 필요는 없습니다. :)


4
30 일마다 각 서버를 건 드리려고 열심히 노력합니다. 이 시점에서 80 대 이상의 서버가 있습니다. 기능 그룹 또는 운영 체제별로 배치로 수행합니다.
토마스 덴튼

2
우리는 매일 밤 SLES / OpenSuSE 상자에 해당하는 크론 스크립트를 가지고 있습니다. 패키지가 필요하다는 것을 알게되면 문제 티켓 시스템의 시스템 관리 큐에 티켓을 제출합니다. (이는 큐를 스팸하지 않도록 / tmp의 파일에서 이전에 제출 된 파일을 추적합니다.)
Karl Katzke 2009

4
데비안에는 apticron과 cron-apt의 두 가지 패키지가 있는데, 비슷한 패키지를 제공하고 업데이트가있을 경우 이메일을 보냅니다. IME, apticron은 변경 내역을 이메일로 보내 주므로 변경 사항을 확인할 수 있습니다.
David Pashley 2016


6

데비안의 안정된 릴리스를 실행한다고 가정하면, 대부분의 패치는 보안 또는 버그와 관련이 있으므로 특정 패키지의 버전간에 큰 변화가 없을 것입니다. 데비안 패치 정책에 따르면 패치는 또한 관리자에 의해 안정적인 지점으로 이동하기 전에 일정 시간 동안 테스트 중이어야합니다. 분명히 이것은 패치 할 때 파손을 멈추지 않지만 대부분의 경우 파손을 방지해야합니다.

테스트 서버를 최신 상태로 유지하고 사용자와 서버에 영향을 미치는 버그가있는 패키지는 최신 상태로 유지해야합니다. 패치가 안정적임을 알면 보안 권고가있는 모든 패키지를 업데이트해야합니다.

데비안은 일반적으로 매우 안정적인 OS이며, 파손에 대해 지나치게 염려해야 할 것은 아니지만 업데이트되기 전에 항상 업데이트 될 내용을 읽고 이상한 것으로 보이는 것을 주시하십시오. / etc / dir에서 VCS를 사용하여 'git diff'명령으로 구성 파일 변경 사항을 볼 수 있습니다.


3

나는 무엇을 업데이트 할 것인지보기 위해 드라이 런 (먼저)을한다. 때로는 라이브러리 (이 예제에서는 libfoo라고 함)가 API를 변경하여 직접 작성하거나 설치 한 프로그램을 중단시킵니다. 중요한 라이브러리가 업데이트되면 소스를 가져 와서 업데이트하기 전에 소스를 다시 작성하십시오.

또한 우리가 아파치 등과 같은 일부 공공 서비스의 중간 버전으로 점프하지 않는지 확인합니다. 업데이트가 중요하지 않은 한 1 년 뒤에 머물러 있고 임의의 손상이 발생하지 않습니다.

시스템 관리자 인 경우 Secunia 와 같은 사이트에서 RSS 피드를 가져와야 합니다. 그러면 배포판에서 일부 패치를 적용 할 예정인지 미리 알려야합니다.

맹목적으로 업그레이드 / 업데이트하지 마십시오. 불행히도, 시스템이 프로그래머를 지원하는 경우 배포판 패키지 관리자가 아닌 깨진 부분을 아는 작업이 당신에게 달려 있습니다.


2

내가 일하는 곳에서는 PatchLink라는 소프트웨어를 사용하여 가장 중요한 보안 관련 업데이트를 알려주고 테스트 후 패키지별로 적용하는 매우 광범위한 프로세스가 있습니다. 그래도 수천 대의 서버가 있습니다.

서버가 두 대 뿐인 경우 프로세스가 훨씬 간단해야합니다. "apt-get update / upgrade"를하는 것이 최선의 방법이라고 생각하지는 않습니다.

실행중인 소프트웨어에 대한 패치를 모니터링하고 업그레이드시기에 대한 해당 릴리스의 수정 사항에 따라 결정합니다.

테스트 서버가 있으므로 반드시 업데이트를 적용하기 전에 항상 테스트하십시오.


2

수동 업데이트는 현재 상황을 확인할 수 있다는 점에서 여기에 언급 된대로 가장 좋습니다. 그러나 실용적이지 않을 수있는 매우 많은 서버의 경우. 드라 이런은 표준 관행이며, 사실 대부분의 패키지 관리자가 진행하기 전에 물어볼 것입니다.

약간의 균형 조정 작업이 될 수 있지만 정기적으로 업데이트하는 것이 가장 좋습니다. 빈번한 업데이트는 한 번에 적은 수와 한 번에 잘못되는 수가 적음을 의미합니다. 문제가 발생하면 조사 할 후보자가 적습니다. 패키지는 작은 단계로 업데이트하는 데 약간 더 좋습니다. 일반적으로 프로그래머가 마지막 버전에서 다음 버전으로 갈 때 업데이트 할 때 마지막 버전 이후에주의를 기울 일지 여부는 다양 할 수 있습니다. 대부분 빠르게 진화하는 소프트웨어에 적합합니다.

모든 업데이트가 중단되지는 않습니다. 이것을 조심해야 할 것입니다. 일부는 다운 타임을 초래하는 서비스를 다시 시작합니다.

이상적인 설정에서는 다음이있을 수 있습니다.

  • 겉보기에는 서버를 전환하는 수단 (A / B 또는 틱톡). 즉, 벤치에있는 동안 업데이트 한 다음 현재 트래픽을 새 트래픽으로 간단히 전환하면됩니다. 데이터베이스와 같은 서비스에서는 더 복잡 할 수 있습니다.
  • 업데이트 테스트 기능. 실제로 프로덕션 복제 본인 테스트 서버가 있어야하지만 프로덕션 서비스에 연결하지 않아도됩니다. 업데이트를 먼저 테스트 할 수 있습니다.
  • 좋은 백업 전략, 증분이 이상적입니다. 당신은 몰라요 항상 미안보다 안전하는 것이 좋습니다.
  • 가장 활동적인 시간과 허용 가능한 다운 타임 레벨을 알고 있어야합니다.
  • 업데이트 또는 특정 패키지를 롤백하는 방법을 알고 있어야합니다.
  • 서버간에 업데이트가 일관되고 예측 가능하도록 자체 패키지 미러를 사용하십시오. 이것은 신뢰할 수있는 적절한 무인 시스템을 향한 첫 번째 단계입니다. 즉, 미러를 업데이트하고 하나 이상의 테스트 시스템에서 업데이트를 실행 한 다음 자동으로 내보내도록 할 수 있습니다. 나는 약 800 대의 EPOS 기계를 적절하게 관리하면서 훌륭한 시간을 보냈습니다.
  • 일관된 수준의 일관성을 통해 여기에서 무언가가 작동하면 작동 할 것임을 알 수 있습니다.

이들 중 일부는 소규모 설정의 경우 다양한 정도로 과도 할 수 있지만 명심해야합니다.

일반적으로 업데이트는 일반적으로 서버 배포판에서 비교적 고통스럽지 않습니다. 거의 항상 버그 수정 및 보안 업데이트 만 고수하기 때문입니다. 그러나 사람들이 시스템에 이상한 일을하거나 추가 패키지 소스를 추가하면 문제가 발생할 수 있습니다.

비록 드물기는하지만 때때로 실수를하여 마이너 패키지 버전 사이의 호환성을 손상시킵니다.


1

나는이 프로세스를 자동화하기 위해 cron-apt를 좋아하지만 @dinomite가 업데이트에 관한 또 다른 질문을 지적했듯이 보안 관련 업데이트를 자동화하도록 특별히 구성하는 것은 매우 현명한 아이디어입니다. 그러면 필요한 것을 수동으로 업데이트 할 수 있습니다. 나는 모든 업데이트에 cron-apt를 사용했지만 실제로 그의 대답에 따라 이것을 변경했습니다. 당신이 그것을 좋아한다면, 아마도 이것보다 그의 대답에 투표 해야 할 것입니다 .


1

데비안에서 cron-apt를 설치 하고 구성 파일을 편집하여 변경 사항이 있으면 메일을 보내주십시오. 이 방법으로 시스템 업데이트가있을 경우 알림을 받고 직접 업데이트를 수행합니다.


1

cron-apt와 동일한 행을 따라 무인 업그레이드 패키지 http://packages.debian.org/lenny/unattended-upgrades를 살펴보십시오 .

구성이 매우 쉽고 보안 업데이트를 자동으로 다운로드하여 적용 할 수는 있지만 수동으로 업그레이드 할 수 있도록 다른 업데이트를 남겨 두십시오 (또는 재량에 따라 모든 것을 업그레이드하십시오!).

공식 우분투 서버 안내서에는 무인 업그레이드 패키지 사용에 대한 합리적인 섹션이 있습니다 https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

참고 :주의 / 편집증 수준에 따라 먼저 테스트 서버 그룹에서 롤링 업그레이드를 수행 할 수 있습니다. 문제가 없으면 생산 상자를 업데이트 할 수 있습니다. 개인적으로 보안 업데이트에 아무런 문제가 발생하지 않았습니다. 지금까지 혼란을 겪고 있습니다 (나무를 두 드리십시오) ...

각 보안 업데이트의 결과를 적용한 후에 메일로 발송하는 구성 옵션도 있습니다. 또한 업데이트 중에 표시되는 대화 상자 나 대화 상자 프롬프트가 있으면 sysadmin이 수동으로 조정해야하는 대화 상자 나 대화 상자가 표시됩니다.


1

본인은 다음과 같은 경우를 제외하고는 자동 업데이트를 개인적으로 해제하고 내 환경의 서버에서 패키지 업데이트를 정기적으로 수행하지 않습니다. (b) 특정 이유로 개별 패키지를 업그레이드해야합니다. (c) OS 또는 패키지의 수명이 다되어 더 이상 지원되지 않으므로 계속 지원해야합니다. 내 추론은 무엇이 바뀌고 있는지, 왜 깨지기 어려운 공간을 남겨 두는지를 모르고 업그레이드하는 것입니다. 나는 14 년 동안 이런 일을 해왔으며 잘 작동합니다.


0

언급 된 것 외에도 업데이트를 알리기 위해 일종의 모니터링 도구 (Nagios 또는 보트를 떠 다니는 모든 것)를 사용해야합니다.

얼마나 자주 진행되는지 : 업데이트가 제공되는 즉시!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.