사후 관리 능력을 잃지 않고 불변 서버 패턴을 구현하는 방법은 무엇입니까?

변경 불가능한 서버 패턴은 배치의 재현성을 선호하는 배치 원칙입니다. “ 한 번 배포 된 서버는 결코 수정되지 않고 단순히 새로운 업데이트 된 인스턴스로 대체 된 서버 ”라는 사실이 특징 이며이 원칙을 구현하려면 서버 배포 자동화가 필요합니다. 이 자동화에는 수많은 운영상의 이점이 있으며, 가장 중요한 것 중 하나는 인프라에서 장애가 발생한 인스턴스를 빠르고 안정적으로 교체하는 것입니다. 이 자동화는 또한 서버 배포가 버전이 지정된 소프트웨어 아티팩트에 의해 설명되며 반복적 인 개선이 필요함을 의미합니다.

이 분야의 구현에서 널리 사용되는 측면은 서버가 시작되면 서버에 대한 원격 액세스 방법 제거 (SSH 액세스 제거)입니다. 원격 액세스를 제거하면 서버 구성이 배치 자동화에서 준비한 구성과 일치하는 쉬운 방법입니다.

그러나 사후 사후 소프트웨어 오류의 원인을 조사 할 때 구조적 모니터링에 의존하는 것만으로는 충분하지 않으며 기계에 대한 원격 액세스가 필요할 수 있습니다. 서버 모니터링이 모든 실패 원인을 다루지 않거나 서버 장애 자체로 인해 모니터링이 손상 될 수있는 일반적인 실제 상황입니다. 이는 서버의 메모리가 부족하거나 프로세스 한계에 도달 한 경우 일 수 있습니다.

사후 관리 능력을 잃지 않고 불변 서버 패턴을 구현하는 방법은 무엇입니까?

우선, 불변의 서버에서 ssh를 제거한다고해서 아무런 변화가 없다고 보장 할 수는 없으며, 원격 액세스 채널을 제거하여 공격 영역을 줄이는 것을 변경할 필요가 없어야합니다.

사후 분류를 유지하는 한 가지 방법은 로그 중앙 집중화입니다. 그것을 달성하는 무수한 방법, ELK 스택, Splunk, syslog가 있습니다 ...

변경 불가능한 서버에 대한 사후 상태를 유지하는 또 다른 더 조잡한 방법은 종료 프로세스에 스크립트를 작성하는 것입니다 (불변 서버는 종료되고이를 대체하기 위해 새로운 서버가 스핀 업됨). 메모리 덤프 및 원격 시스템에 전송하여 대부분의 로그와 함께 분석합니다.

이 솔루션의 주요 장점은 문제가 발생한 시점에 고장난 시스템 정보 만 다시 가져 와서 정기적으로 얻는 것보다 더 큰 정보를 수집 할 수 있다는 것입니다.

이것을 달성하는 방법에 대해 더 구체적으로 말하기는 어렵습니다. 각 배포판에는 물건을 얻을 수있는 방법이 있으며 일반적인 예는 없습니다.

SSH 액세스 권한이 없다고해서 머신에 액세스 할 수있는 방법이 없다는 의미는 아닙니다. 대부분의 클라우드 운영자에서 다음을 수행 할 수 있습니다.

• 기계의 스냅 샷을 찍습니다. 나중에 분석하기 위해 상자를 파괴하기 전에 간단히 상자의 스냅 샷을 찍을 수 있습니다.
• 콘솔을 통해 머신에 액세스하십시오. 아마도 이것에 대한 루트 암호가 필요할 수도 있지만, 일부 클라우드 공급자는 언제든지 콘솔 액세스를 위해 임의의 루트 암호를 주입 할 수 있습니다.

이는 본질적으로 컴퓨터에 대한 "물리적"액세스이며 다른 유형의 액세스를 제거하더라도 사용할 수 있습니다. 이러한 인터페이스도 제한 할 수 있습니다.

@Tensibai가 말했듯 이이 외에도 더 좋은 방법은 적절한 로깅 및 모니터링을 설정하는 것이므로 사후 관리를 수행해야 할 때마다 충분한 데이터가 있습니다.