나는 종종 프로덕션 웹/db/도구 상자에 로그인할 때 다음과 같은 일반적인 메시지를 봅니다.
30개의 패키지를 업데이트할 수 있습니다. 16개 업데이트는 보안 업데이트입니다.
제 질문은 여러분 모두가 프로덕션 Ubuntu 상자의 업데이트를 어떻게 처리합니까?입니다. 이러한 업데이트를 자동화합니까? 가동 중지 시간을 설정합니까? 문제는 업데이트로 인해 기존 구성 파일 등이 언제 중단될지 알 수 없다는 것입니다.
이 문제의 또 다른 부분은 패치를 유지하는 것이 '좋은 일'이지만 패치는 거의 매일 릴리스된다는 것입니다. 매일 새로운 보안 패치가 제공된다면 몇 번의 예약된 중단을 거쳐야 합니까?
업데이트를 관리하는 방법에 대한 답변이 매우 유용할 것이라고 생각합니다.
답변1
Ubuntu와 Windows, RHEL, CentOS, SuSE, debian 등을 패치하는 데 특별한 것은 없습니다.
패치 절차를 설계할 때 갖춰야 할 기본적인 마음 상태는 무엇인가를 가정하는 것입니다.~ 할 것이다부서지다.
패치 설정을 디자인할 때 제가 사용하는 기본 지침은 다음과 같습니다.
- 항상 로컬 시스템을 사용하여 패치가 설치된 네트워크를 내부적으로 중앙 집중화합니다.
<your_os_here>여기에는 WSUS를 사용하거나 내부 패치 관리 시스템에 대한 미러링이 포함될 수 있습니다 . 개별 컴퓨터에 설치된 패치의 상태를 중앙에서 쿼리하고 알려줄 수 있는 것이 선호됩니다.
- 가능한 경우 기계에 설치를 사전 단계로 진행합니다.
가능하다면 패치가 나오면 중앙 서버가 패치를 개별 시스템에 복사하도록 합니다. 이는 실제로 시간을 절약해 주기 때문에 다운로드 및 설치를 기다릴 필요가 없으며 패치 기간 동안 설치를 시작하기만 하면 됩니다.
- 패치를 설치하기 위한 중단 기간이 발생하면 재부팅해야 할 수도 있으며 문제가 발생할 수도 있습니다. 해당 시스템의 이해관계자가 패치가 배포되고 있음을 알고 있는지 확인하십시오. "이것"은 작동하지 않는다는 호출에 대비하세요.
패치로 인해 문제가 발생한다는 나의 기본 이론을 유지하면서 중요한 문제를 해결할 수 있을 만큼 오랫동안 패치를 적용하고 패치를 롤백할 수 있는 중단 기간을 확보해야 합니다. 패치 후에 테스트를 하도록 사람들을 앉힐 필요는 없습니다. 개인적으로 저는 모니터링 시스템에 크게 의존하여 모든 것이 우리가 피할 수 있는 최소한의 수준에서 작동하고 있음을 알려줍니다. 그러나 사람들이 일을 시작하면서 발생하는 작은 잔소리 문제에 대해서도 대비하세요. 항상 전화를 받을 준비가 되어 있는 사람이 있어야 합니다. 새벽 3시까지 일어나서 상자를 고치는 사람은 바람직하지 않습니다.
- 최대한 자동화하다
IT의 다른 모든 것과 마찬가지로 스크립트, 스크립트, 스크립트를 더 많이 작성합니다. 패키지 다운로드, 설치 시작, 미러 스크립트를 작성합니다. 기본적으로 패치 창을 문제가 발생할 경우를 대비해 사람이 필요한 아기 돌보기 작업으로 바꾸고 싶습니다.
- 매월 여러 개의 창구 보유
이는 어떤 이유로든 "지정된 밤"에 패치를 적용할 수 없는 경우 일부 서버를 패치하지 않을 수 있는 기능을 제공합니다. 1박에 할 수 없다면 2박에 무료가 되도록 요구하세요. 또한 동시에 패치되는 서버 수를 정상으로 유지할 수도 있습니다.
가장 중요한 것은패치를 따라가세요!그렇지 않으면 따라잡힌 지점으로 돌아가기 위해 매우 큰 10시간 이상의 패치 기간을 수행해야 하는 자신을 발견하게 될 것입니다. 문제가 발생할 수 있는 지점이 훨씬 더 많이 도입되고, 어떤 패치가 원인이고 문제인지 찾는 것이 훨씬 더 어려워졌습니다.
이 문제의 또 다른 부분은 패치를 유지하는 것이 '좋은 일'이지만 패치는 거의 매일 릴리스된다는 것입니다. 매일 새로운 보안 패치가 제공된다면 몇 번의 예약된 중단을 거쳐야 합니까?
한 달에 한 번 또는 격월에 한 번 서버를 패치하는 것은 - IMHO - 매우 달성 가능하고 수용 가능한 목표입니다. 그 이상으로, 지속적으로 서버에 패치를 적용하게 될 것이며, 서버당 수백 개의 패치를 적용해야 하는 상황에 빠지기 시작하는 경우는 훨씬 적습니다.
한 달에 몇 개의 창문이 필요한가요? 이는 환경에 따라 다릅니다. 서버가 몇 대나 있나요? 귀하의 서버에 필요한 가동 시간은 얼마나 됩니까?
9x5 규모의 소규모 환경에서는 한 달에 한 번의 패치 기간만 있어도 문제가 해결될 수 있습니다. 대형 24x7 매장에는 두 개가 필요할 수 있습니다. 매우 큰 규모의 24x7x365에는 매주 다른 서버 세트를 패치하기 위해 매주 롤링 창이 필요할 수 있습니다.
귀하와 귀하의 환경에 적합한 주파수를 찾으십시오.
한 가지 명심해야 할 점은 100% 최신 상태라는 것입니다.불가능한목표 달성 - 보안 부서에서 달리 지시하지 않도록 하세요. 최선을 다하고 너무 뒤쳐지지 마십시오.
답변2
해야 할 일:
- 백업하기
- 복원 가능한 백업인지 확인하세요. (이 두 가지는 일반적인 사항이지만)
- 업그레이드하는 동안 프로덕션 상자에서 트래픽을 멀리 보내십시오.
- 모든 것이 잘못될 경우를 대비해 KVM, 직렬 콘솔, 로컬 액세스 또는 원격 액세스 방법을 사용하여 대역 외 액세스 방법을 사용해 보십시오.
- 하나의 서버에서 테스트한 후 모든 것이 제대로 작동하는지 확인한 후 더 많은 서버에 업데이트를 배포하세요.
- 여러 서버에서 버전 번호가 동일한지 확인하려면 가능하면 꼭두각시를 사용하세요. (강제 업그레이드에도 사용할 수 있습니다)
- 테스트 서버에서 구성 파일의 버전을 새로운(업데이트가 설치된) 버전과 비교하고 심각한 문제가 발생하지 않는지 확인하십시오. 현재 설치된 버전과 다른 새 버전을 설치하기 전에 dpkg가 묻는 것을 기억하는 것 같습니다.
피해야 할 것:
- 업데이트는 정오, 월요일 오전 9시, 금요일 오후 5시에 진행됩니다! (@3influence 감사합니다!)
- 매우 큰 데이터베이스 서버에서 MySQL을 업그레이드하는 경우(다시 시작하는 데 시간이 오래 걸릴 수 있음)
- 모든 서버를 한 번에 수행(특히 커널)
- /etc/networks를 변경할 수 있는 모든 작업 수행(연결이 끊어질 수 있으므로)
- 모든 것이 정상인지 확인하기 위해 사용자가 직접 방문하지 않고도 위의 작업을 수행할 수 있는 자동 업데이트입니다.
답변3
또 하나 언급할 가치가 있는 점은 Windows에 익숙하다면 대부분의 Linux 업데이트가 Windows에 익숙하다는 사실에 놀랄 것입니다.~ 아니다가동 중지 시간 또는 재부팅이 필요합니다. 커널 업데이트와 같은 일부 작업이 수행됩니다. 그러나 재부팅이나 다운타임이 필요한 업데이트는 일반적으로 그렇게 플래그가 지정되며 별도의 일정에 따라 처리될 수 있습니다.
답변4
우분투 LTS 시스템에 대한 업데이트는 다음과 같은 방식으로 처리됩니다.
- 소프트웨어의 모든 중요한 경로를 확인하는 일련의 승인 테스트를 유지합니다.
- 매일 새벽 4시에 보안 업그레이드를 무인으로 설치하고 즉시 승인 테스트를 진행합니다. 문제가 발생하면 엔지니어가 호출되어 오전 9시 이전에 문제를 해결하거나 롤백할 수 있는 충분한 시간을 갖습니다. 이는 지금까지 5년 동안 단 두 번만 발생했습니다. LTS는 잘 테스트되었으며 안정적입니다.
- 우리는 모든 패키지를 최신 버전으로 유지하는 블루/그린 배포를 통해 매주 (digitalocean에서) 전체 인프라를 자동으로 재배포합니다. 새 배포가 승인 테스트에 실패하면 엔지니어가 문제를 디버그할 수 있을 때까지 배포가 보류됩니다.
다음 논리적 단계는 인메모리 세션 정보를 제거하여 고객에게 영향을 주지 않고 매일 또는 하루에 여러 번 인프라를 간단히 재배포하고 단계(2)를 제거하는 것입니다.
이 접근 방식은 유지 관리가 적고 유지 관리 기간을 완전히 방지합니다.