불변 서버 란 무엇입니까?

불변 서버 와 관련하여 다음과 같은 몇 가지 질문이 있습니다 .

• 사후 관리 능력을 잃지 않고 불변 서버 패턴을 구현하는 방법은 무엇입니까?
• 불변 인프라에서 구성 관리 도구의 역할은 무엇입니까?

서버와 관련이 있다는 것이 분명합니다 (그 부분은 내가 얻습니다). 그리고 불변 의 문법을 소화시키면서 " 음소거 할 수 없습니다"와 관련이 있다고 생각합니다 . 그 추측이 가까워지면, 음소거 할 수없는 것이 무엇인지 전혀 알지 못합니다 (사운드 카드 또는 무언가와 관련이 있는지 의심됩니다 ...).

내 질문 :

• 실제로 "불변 서버"란 무엇입니까 (DevOps와 관련하여)?
• 왜 사용됩니까?

불변성은 컴퓨터 과학 분야에서 자주 사용되는 용어로 일반적으로 "생성 후 변경할 수 없음"으로 요약됩니다. 일반적으로 병렬 처리, 동시성 및 스레드 안전성과 관련하여 사용됩니다.

이 주제에 대한 논의는 흥미롭지 만 일반적으로 Stack Overflow의 다른 곳에서 찾을 수 있습니다 . 나는 여기에 뛰어 들고 싶은 충동에 저항하고 있습니다. 핵심 개념은 '만든 후에는 변경할 수 없습니다'입니다.

Amazon에서 웹 서비스를 머신 이미지 (AMI-미리 구축 한 인스턴스로 반복해서 다시 프로비저닝 할 수있는 인스턴스)에 굽어 웹 서비스를 배포한다고 가정 해보십시오. 시작시 레지스트리에서 나오는 자격 증명을 통해 백엔드 데이터베이스에 연결합니다. Splunk와 같은 로깅 도구에 로그를 덤프합니다. 정상적인 일상 작업의 경우이 상자에 넣을 이유가 없습니다. 해당 서비스를 확장해야하는 경우 해당 AMI의 인스턴스를 더 만들고로드 밸런서를 조정하면됩니다. 스핀 다운은 단순히 인스턴스와로드 밸런서를 파괴하는 것입니다.

일상적인 작업의 경우이 상자 를 변경할 이유 가 없습니다 . AMI에서 더 많은 것을 해낼 수 있습니다.

OS 수준 보안 패치를 제공해야 할 경우 어떻게됩니까? 패치를 설치하여 새 AMI를 굽고 실행중인 모든 인스턴스를 재배치하거나 기존 이미지로 ssh하고 패치를 업데이트하기로 결정한 경우입니다. 방금 ssh 할 사람들이 많이 있습니다. '불변의 건축물'의 지지자들은 그런 일이 가능하다는 제안조차 나에게 소리 쳤습니다.

불변 인은 (이런 단어가 있다면) 새로운 ami를 굽는 것을 옹호합니다. 그들은 기계에 ssh해야 할 모든 이유를 제거 할 것을 옹호합니다. 그들은 저장소에서 구성 세부 정보를 가져 와서 해당 컴퓨터를 시작할 때 특정 컴퓨터 구성이 발생해야한다고 주장합니다. 이것은 '애완 동물이 아닌 소'의 궁극적 표현입니다.

변경할 수없는 아키텍처는 머신 이미지를 생성 한 후 변경할 이유가없는 머신 구성에 관한 것입니다 . 변경해야 할 경우 새 인스턴스 이미지를 굽고 이전 인스턴스를 종료하고 새 인스턴스를 불러옵니다.

클라우드 기술은 하드웨어와 소프트웨어 사이의 경계를 전환하여 이전에는 하드웨어 세계의 독점 시민이었던 많은 기술 작업도 소프트웨어 영역의 대상이되었습니다. 공유 컴퓨팅 환경은 컴퓨터 ¹ 만큼 오래 되었지만 클라우드 기술은 편리하고 친숙한 메타포를 제공하여 대중화 할 수 있습니다. 클라우드 사용자는 인스턴스, 완전한 컴퓨터 또는 모방을 예약하지만 오래된 공유 컴퓨팅 환경은 가능한 모든 세트를 갖습니다. 다루기 어려운 제한과“FTP 서버에 프로그램을 업로드해야합니다. 최대 60 분 동안 환경 X (보통 사용하려는 소프트웨어의 10 년 이전 버전)에서 실행됩니다.”이전 또는 실제 사용자에게 친숙하게 들릴 수 있음 컴퓨팅 센터

이러한 변화의 실제 결과는 이제 배포 절차를 소프트웨어 아티팩트 로 나타낼 수 있다는 것 입니다. (배포 절차는 데이터베이스, 웹 서버 또는이 인프라에 속하는 모든 것을 사용하여 네트워크와 함께 인프라를 설정하는 방법을 알려주는 지침입니다.) 이러한 새로운 렌즈와 함께 서버의 수동 유지 관리는 거의 비슷합니다. 생산 코드의 수동 패치 – 아주 드물게 바람직한 경우입니다. 수동 유지 관리는 실제로 프로덕션 환경에서 실행되는 시스템과 이러한 시스템을 설명하는 코드간에 불일치를 발생시킬 수 있으며, 이는 재현 불가능한 동작과 불가능한 버그 분석, 이중 버그 수정 및 기타 재난을 의미합니다.

불변 서버 패턴은 우리가 실행중인 프로그램을 수동으로 유지 보수를하지 않도록해야 할 따르면, 위의 만트라의 클라우드 운영을위한 단지 전치이다. 서버를 수동으로 구성하는 대신 변경 불가능한 서버 패턴 에서이 구성을 자동화하는 것이 좋습니다.

구현 풍미

불변 서버 패턴에 대한 일반적인 아이디어는 분명하지만 많은 구현상의 뉘앙스가 있습니다. 예를 들어, 일부 접근 방식에서는 서버를 전혀 업데이트하지 않고 시스템 적으로 서버를 대체 하는 것이 좋습니다. 업데이트는 배포가 여러 개의 개별 시간에 시작되고 여러 개의 고유 한 업데이트 프로세스를 거친 서버로 구성되어 상황이 불균일 한 서버 집합을 의미하며 서버가 작업을 처리하는 방식에 미묘한 차이를 초래할 수 있기 때문입니다. 두 번째로 많이 사용되는 변형 지점은 서버에 대한 원격 액세스와 관련된 원칙입니다. 일부는 수동 유지 관리가 수행되지 않도록 서버에 대한 원격 관리 액세스를 완전히 비활성화하는 것을 좋아합니다.

연혁

내가 아는 한,“불변 서버”라는 용어는 Kief Morris에 의해 대중화 되었지만 아이디어 자체는 훨씬 오래되었습니다. 1999 년 FreeBSD 교도소는 이미 일회용 컴퓨팅 환경의 구성을 완전히 자동화한다는 아이디어를 대중화했습니다. 이것이 제가이 기술을 설명하기 위해이 이름을 듣기 몇 년 전에“불변 서버”패턴을 구현하기 시작한 방법입니다.

CD-ROM을 기반으로 한 물리적 불변성을 고려한 불변성은 신뢰할 수있는 컴퓨팅 시스템을 제조하기위한 대중적인 수단이기도합니다. 이것은 변경 불가능한 서버 패턴으로 오인되지 않습니다.

변경할 수없는 서버는 업데이트 및 보안 패치 이외의 변경 사항이없는 서버입니다. 서버에서 소프트웨어를 변경하는 대신 원하는 소프트웨어로 새 서버를 스풀링 한 다음 이전 서버를 종료합니다.

이 개념은 테스트, 개발 및 QA 서버가 모두 동일한 지 확인하는 데 도움이되며,이 질문의 범위를 벗어나는 여러 가지 이유로 중요합니다. 변경 불가능한 서버의 또 다른 이점은 응용 프로그램을 이전 서버로 롤백 할 수 있다는 것입니다. 예를 들어 프로덕션 서버 1에서 K를 변경해야하므로 서버 2를 스풀링하고 K를 변경해야합니다. 이제 10 분 후에 K가 즉시 수정하지 않고 내 응용 프로그램에서 문제가 발생하여 몇 시간이 걸릴 수 있음을 알았습니다. 고객에게 다운 타임을 유발할 수 있으므로 트래픽을 서버 1로 다시 리디렉션하고 2의 문제점을 파악합니다.

Immutable Servers에 대한 Martin Fowler의 블리 키 기사에서 가장 좋은 설명을 찾을 수 있습니다 .

하드웨어 나 클라우드의 가상 서버 인 서버는 대개 운영 체제와 응용 프로그램이 실행되고 있습니다.

종종 응용 프로그램 및 운영 체제 구성 요소는 구성이 필요하며 변경 사항을 적용해야합니다. 예를 들어 보안 패치, 새 버전의 응용 프로그램 배포 및 구성 변경.

변경 사항이 서버 상태에 대한 돌연변이 라고 생각 하면 용어 immutable가 더 의미가 있습니다. 이는 그러한 서버에서 돌연변이 가 허용 되지 않음을 의미 합니다.

사람들이 서버의 상태를 변경하는 데 관여하는 경우가 종종 있습니다 (버전의 배포, 구성 변경 또는 보안 경로 등). 결과적으로 서버가 더 이상 예상대로 작동하지 않습니다. 예를 들어, 잘못된 구성 등으로 인해 응용 프로그램이 지금 실행되지 않을 수 있습니다.

이것이 불변의 서버 를 만드는 관행 이 확립 된 이유 입니다. 으로 불변 서버, 이미지 서버의가에 번들 모든 구성, 패치, 응용 프로그램 버전 생성됩니다. 서버 그 이미지가 다양한 환경에서 서버를 만드는 데 사용할 수 있습니다.

이러한 이미지 가 사용되는 첫 번째 환경은 이미지 가 작동하도록 테스트 할 수있는 환경입니다. 이상이 감지되면 해당 이미지 만 프로덕션 환경 으로 승격 하여 서버를 새 버전 (잘 작동하는 것으로 알려진)으로 교체 할 수 있습니다 .

이미지를 만들고 이미지를 홍보하는 프로세스가 자동화되면 사용자의 노력이 거의 들지 않고 서비스에 실패 할 가능성이 매우 낮은 오류 방지 프로세스를 얻게됩니다.

불변 서버는 종종 ssh 서버가없는 경우와 같이 "입력"하는 방법을 포함하지 않습니다. 이 경우 서버의 모든 계측 (메트릭, 로그)이 메트릭 데이터베이스 또는 로그 집계 서비스와 같은 외부 시스템으로 배송되는 경우가 종종 있습니다.

컨테이너 ( Docker 참조 )를 사용하여 이미지를 만든 다음 실행중인 컨테이너에 이미지를 생성하는 프로세스도 있습니다. 이들은 종종 업데이트 된 이미지를 기반으로하는 새로운 컨테이너로 대체되며 결코 변경되지 않습니다. 변경 사항을 도입하여 "무언가를 고치기"위해 컨테이너에 들어가는 사람이 없음을 의미합니다.

변경 가능한 서버 란 무엇입니까?

일반적으로 가변 서버 인프라는 지속적으로 수정 및 업데이트되는 인프라입니다. 쉘을 보호하고 패키지를 업그레이드하고 구성하며 서비스를 설치하고 새 코드를 배포 할 수 있습니다. 이것이 변경 가능하게 만드는 것이므로 변경하거나 수정할 수 있습니다.

불변 인프라는 서버가 배포 된 후에도 수정되지 않는 또 다른 인프라 패러다임입니다. 어떤 방식 으로든 무언가를 업데이트, 수정 또는 수정해야하는 경우, 적절한 변경 사항으로 공통 이미지로 빌드 된 새 서버가 이전 서버를 대체하도록 프로비저닝됩니다. 검증 된 후에는 사용이 시작되고 오래된 것이 폐기됩니다.

왜 사용됩니까? 불변 인프라 스트럭처의 이점은 인프라의 일관성과 안정성, 단순하고 예측 가능한 배포 프로세스로, 서버 충돌로 인한 다운 타임 또는 기타와 같이 가변 인프라 스트럭처의 일반적인 서버 문제를 완화합니다.

그러나 포괄적 인 배포 자동화 및 빠른 서버 프로비저닝을 통해 효율적으로 프로비저닝하는 방법을 알아야합니다.

비트 코인을 채굴한다고 가정하고, 서버가 다운 된 경우 다운 타임을 원치 않으며 가능한 빨리 백업해야하므로 불변 인프라 스트럭처가 솔루션으로 간주됩니다.