프로덕션 우분투 박스 업데이트 할 것과하지 말아야 할 것

나는 종종 프로덕션 웹 / db / 도구 상자에 로그인하고 일반적인 메시지를 봅니다.

30 개의 패키지를 업데이트 할 수 있습니다. 16 개의 업데이트는 보안 업데이트입니다.

제 질문은 프로덕션 우분투 박스의 업데이트를 어떻게 처리합니까? 이 업데이트를 자동화합니까? 가동 중지 시간을 설정 했습니까? 문제는 업데이트가 기존 구성 파일 등과 같은 문제를 겪을시기를 알 수 없다는 것입니다.

이 문제의 다른 부분은 패치를 유지하는 것이 '좋은 일'이지만 패치는 거의 매일 릴리스됩니다. 매일 새로운 보안 패치를 사용할 수있게되면 예약 된 정전이 몇 회나 발생해야합니까?

업데이트 관리 방법에 대한 답변 스레드가 매우 유용하다고 생각합니다.

Ubuntu와 Windows, RHEL, CentOS, SuSE, debian 등을 패치하는 데 특별한 것은 없습니다.

패치 절차를 설계 할 때 필요한 기본 상태는 문제가 있다고 가정하는 것 입니다 .

패치 설정을 설계 할 때 사용하는 몇 가지 기본 지침은 다음과 같습니다.

• 항상 로컬 시스템을 사용하여 패치가 설치된 네트워크 내부로 중앙 집중화하십시오

여기에는 WSUS 또는 <your_os_here>내부 패치 관리 시스템의 미러를 사용하는 것이 포함될 수 있습니다 . 중앙에서 쿼리하고 개별 시스템에 설치된 패치의 상태를 알려주는 것이 좋습니다.

• 가능하면 기계에 설치를 사전 준비하십시오.

가능하면 패치가 나오면 중앙 서버가 개별 시스템에 패치를 복사하도록합니다. 이것은 실제로 시간을 절약 해주기 때문에 다운로드 및 설치를 기다릴 필요가 없으며 패치 기간 동안 설치를 시작하면됩니다.

• 패치를 설치하기 위해 중단 창을 가져 와서 다시 부팅해야 할 수도 있으며 문제가 발생할 수 있습니다. 해당 시스템의 스테이크 홀더가 패치가 배포되고 있음을 알고 있는지 확인하십시오. "이것은"전화가 작동하지 않습니다 준비하십시오.

패치가 문제를 일으킨다는 나의 기본 이론에 따라 중요한 문제를 해결하기에 충분한 시간 동안 패치를 적용 할 수있는 중단 기간이 있는지 확인하고 패치를 롤백하십시오. 패치 후에는 사람들이 시험을 보도록 할 필요가 없습니다. 개인적으로 나는 모니터링 시스템에 크게 의존하여 모든 것이 우리가 도망 갈 수있는 최소한의 수준에서 작동하고 있음을 알려줍니다. 그러나 사람들이 일을하면서 조금씩 잔소리가 들리지 않도록 준비해야합니다. 당신은 항상 전화를받을 준비가되어있는 누군가가 있어야한다. 상자를 패치하는 오전 3 시까 지 일했던 사람이 아닌 것이 바람직하다.

• 최대한 자동화

IT의 다른 모든 것과 마찬가지로 스크립트, 스크립트 및 스크립트를 더 작성하십시오. 패키지 다운로드, 설치 시작, 미러를 스크립팅하십시오. 기본적으로 패치 창을 문제가 생길 경우를 대비하여 사람이 필요한 아기 좌석 과제로 바꾸고 싶습니다.

• 매월 여러 개의 창이 있습니다

어떤 이유로 든 "지정된 밤"에 패치 할 수없는 경우 일부 서버를 패치하지 않을 수 있습니다. 밤 1시에 할 수없는 경우 밤 2시에 무료로 제공해야합니다. 또한 서버 수를 패치 된 상태로 유지할 수 있습니다.

가장 중요한 것은 패치를 따라 잡는 것입니다! 당신이하지 않으면 당신이 따라 잡히는 지점으로 돌아 가기 위해 매우 큰 10 + 시간 패치 창을 수행해야한다는 것을 알 수 있습니다. 문제가 발생할 수있는 더 많은 포인트를 소개하고 어떤 패치로 인해 문제가 더 심각해 졌는지 찾아냅니다.

이 문제의 다른 부분은 패치를 유지하는 것이 '좋은 일'이지만 패치는 거의 매일 릴리스됩니다. 매일 새로운 보안 패치를 사용할 수있게되면 예약 된 정전이 몇 회나 발생해야합니까?

한 달에 한 번 또는 두 달에 한 번씩 서버를 패치하는 것은 매우 달성 가능하고 수용 가능한 목표입니다. 그것보다 더, 그리고 당신은 지속적으로 서버를 패치 할 것이고 훨씬 적은 수의 서버 당 수백 개의 패치를 적용 해야하는 상황에 처하기 시작합니다.

한 달에 몇 개의 창문이 필요한가? 환경에 따라 다릅니다. 서버가 몇 대입니까? 당신의 서버에 필요한 가동 시간은 얼마입니까?

9x5의 소규모 환경은 한 달에 하나의 패치 창으로 벗어날 수 있습니다. 대형 24x7 상점에는 2 개가 필요할 수 있습니다. 매우 큰 24x7x365는 매주 다른 서버 세트를 패치하기 위해 매주 롤링 창이 필요할 수 있습니다.

귀하와 귀하의 환경에 적합한 주파수를 찾으십시오.

명심해야 할 한 가지는 100 % 최신 정보를 얻는 것이 불가능한 목표 라는 것입니다. 보안 부서에서 달리 알리지 마십시오. 최선을 다하고 너무 멀리 떨어지지 마십시오.

해야 할 일:

1. 백업 받기
2. 복원 가능한 백업인지 확인하십시오 (이 두 가지가 일반적인 사항 임)
3. 업그레이드하는 동안 프로덕션 박스에서 트래픽을 보내십시오.
4. KVM, 시리얼 콘솔, 로컬 액세스 또는 원격 장치가 모두 잘못 될 경우 대역 외 액세스 방법을 사용하십시오.
5. 더 많은 서버에 업데이트를 배포하기 전에 한 서버에서 테스트 한 다음 모든 것이 작동하는지 확인하십시오.
6. 여러 서버에서 버전 번호를 동일하게 유지하려면 꼭두각시를 사용하십시오. (이를 사용하여 업그레이드를 강제 할 수도 있습니다)
7. 테스트 서버에서 구성 파일의 버전을 새로운 (업데이트 설치) 버전과 비교하여 심각한 문제가 없는지 확인하십시오. 현재 설치된 버전과 다른 새 버전을 설치하기 전에 묻는 dpkg를 기억합니다.

피해야 할 사항 :

1. 정오에 업데이트, 월요일 오전 09:00, 금요일 오후 5시! (@ 3influence 감사합니다!)
2. 매우 큰 데이터베이스 서버에서 MySQL 업그레이드 (다시 시작하는 데 시간이 오래 걸림)
3. 한 번에 모든 서버 수행 (특히 커널)
4. 연결이 끊어 질 수 있으므로 / etc / networks를 변경할 수있는 작업 수행
5. 모든 것을 확인하지 않고 위의 작업을 수행 할 수있는 자동 업데이트는 정상입니다.

또 다른 가치 : Windows에 익숙하다면 대부분의 Linux 업데이트에 다운 타임이나 재부팅이 필요 하지 않다는 사실에 놀랄 것입니다 . 커널 업데이트와 같은 일부가 있습니다. 그러나 재부팅 또는 가동 중지 시간이 필요한 업데이트는 일반적으로 플래그가 지정되며 별도의 일정으로 처리 할 수 ​​있습니다.

우분투 머신은 모두 LTS 릴리스를 실행하고 있습니다.

우리는 모든 업데이트를 자동으로 설치합니다. "모범 사례"는 아니지만 비교적 작은 규모이며 모든 서비스에 대한 테스트 / 개발 / 제작 환경이 없습니다. LTS 업데이트는 일반적으로 상당히 잘 테스트되고 최소 침습적입니다.

새로운 릴리스로 업그레이드하는 것은 분명히 조금 더 복잡합니다.

우분투 LTS 시스템에 대한 다음과 같은 방식으로 업데이트를 처리합니다.

1. 소프트웨어의 모든 중요 경로를 확인하는 수용 테스트 스위트를 보유
2. 매일 오전 4시에 무인 보안 업그레이드를 설치하고 즉시 수락 테스트를 실행하십시오. 문제가 발생하면 엔지니어가 호출되어 오전 9시 전에 문제를 해결하거나 롤백 할 시간이 충분합니다. 이것은 5 년 만에 두 번 밖에 발생하지 않았습니다. LTS는 잘 테스트되고 안정적입니다.
3. 우리는 모든 패키지를 최신 버전으로 유지하는 블루 / 그린 배포를 통해 매주 전체 인프라 (디지털 오션)를 자동으로 재배치합니다. 새 배포가 승인 테스트에 실패하면 엔지니어가 문제를 디버깅 할 수있을 때까지 배포가 보류됩니다.

다음 단계는 메모리 내 세션 정보를 제거하여 고객에게 영향을주지 않고 매일 또는 하루에 여러 번 인프라를 간단히 재배치하고 단계 (2)를 제거 할 수 있도록하는 것입니다.

이 접근 방식은 유지 관리가 적으며 유지 관리 기간을 완전히 피합니다.

내가 권장하는 한 가지는 패키지 롤백을 처리하는 것입니다. 방법에 대한 제안은 Debian과의 트랜잭션 및 롤백을 참조하십시오. 때로는 업그레이드가 필요한 경우 빠른 수정이 필요할 수 있습니다.