우리는 흥미로운 논쟁을 벌이고 있으며 두 진영으로 나뉘고 있습니다. 나는 우리가 놓쳤을 수도 있는 아이디어나 문제와 관련된 특정 문제에 관심이 있습니다. 실제로, 우리가 결정을 내리는 데 도움이 되거나 우리가 고려하지 않은 사항을 지적할 수 있는 모든 것입니다. 나는 이것이 "의견 없음" 규칙을 약간 우회한다는 것을 알고 있지만 여전히 수용 가능한 질문이기를 바랍니다. 길이도 아쉽지만 약간의 뉘앙스가 있습니다.
1) 한 쪽(나의 편견이 없지는 않습니다)은 불변 서버 모델이 클라우드 시스템에 매우 흥미롭다고 생각합니다. 이를 위해 우리는 인프라의 모든 구성 요소를 Docker로 이동하는 프로토타입을 만들었습니다. 우리의 맞춤형 애플리케이션은 Jenkins를 통해 로컬 Docker 레지스트리에 배포되는 Docker 이미지에 직접 구축됩니다. 그런 다음 빈 서버에 접근하여 Docker를 설치한 다음 Docker에게 필요에 따라 모든 컨테이너를 설치하도록 지시할 수 있는 대규모 Ansible 역할 세트와 플레이북을 만들었습니다. 몇 분 후에 전체 앱과 모든 지원 인프라가 연결되어 작동합니다(로깅, 모니터링, 데이터베이스 생성/채우기 등). 완성된 머신은 정확한 복사본이 있는 독립형 QA 또는 개발 환경입니다. 애플리케이션. 이를 확장하려는 우리의 계획은 신뢰할 수 있는 기본 AMI(아마도 매우 베어 이미지)에서 새로운 AWS 서버를 구축하기 위한 새로운 플레이북을 만들고, 구성 관리 및 릴리스를 처리하기 위해 프로덕션 애플리케이션의 롤링 배포를 수행하며 일반적으로 서버를 다시 편집하지 않는 것입니다. 그냥 새로 만드세요. 나는 내가 설명한 것이 실제로 작동하는 것에 대해 걱정하지 않습니다. 단지 그것이 합리적인 모델이라면 말이죠.
2) 다른 진영에서는 Puppet을 사용하여 구성 관리를 처리하고, Ansible을 사용하여 빌드 프로세스에서 생성된 타르볼인 사용자 정의 애플리케이션을 배포하고, Foreman을 사용하여 프로세스 전체의 트리거링 및 관리를 처리하고, Katello를 사용하여 일정량의 기본 작업을 수행하기를 원합니다. 이미지 관리. 릴리스에는 Puppet이 필요에 따라 구성을 변경하고 Ansible이 일정량의 Foreman 조정을 통해 업데이트된 구성 요소를 배포하는 것이 포함됩니다. 새로운 서버가 필요할 경우 서버를 합리적으로 신속하게 구축할 수 있지만 표준 프로세스의 일부로 서버를 일회용으로 만드는 것은 아닙니다. 수명이 길지만 Phoenix 서버 모델에 더 가깝습니다.
그래서 내 질문은 다음과 같습니다. 위에서 설명한 도구를 사용하는 불변 서버 모델이 실제로 보이는 것처럼 현실적입니까? 저는 우리의 스테이징 프로세스가 말 그대로 라이브로 애플리케이션의 전체 복제본을 구축하고, QA가 이를 망치게 한 다음, 데이터베이스 스토리지와 일부 DNS 설정을 뒤집어 라이브로 만들 수 있다는 아이디어를 좋아합니다.
아니면 불변 서버 모델이 실제로 실패합니까? 우리는 AWS와 클라우드 환경 모두에 대해 많은 경험을 갖고 있으므로 실제로는 문제가 되지 않습니다. 앞으로 합리적으로 정교한 앱을 안정적으로 배포하는 방법에 대한 문제가 더 중요합니다. 우리가 꽤 자주 출시하기 때문에 이는 특히 흥미롭습니다.
실제로 EC2 서버를 생성하는 것 외에는 필요한 대부분의 작업을 Ansible이 수행하고 있으며 이는 어렵지 않습니다. 이 모델에서 실제로 Puppet/Foreman/Katello가 필요한 이유를 이해하는 데 어려움을 겪고 있습니다. Docker는 제가 알 수 있는 모든 도구의 사용자 정의 배포 스크립트보다 훨씬 더 깔끔하고 간단합니다. Ansible을 현장에서 구성해야 하는 것에 대한 걱정을 멈추고 새 구성으로 다시 빌드하면 Puppet보다 사용하기가 훨씬 간단해 보입니다. 저는 KISS 원칙의 팬입니다. 특히 머피의 법칙이 만연하는 자동화 분야에서는 더욱 그렇습니다. 기계가 적을수록 IMO가 더 좋습니다.
접근 방식에 대한 어떤 생각/의견 또는 제안이라도 대단히 감사하겠습니다!
답변1
우리 회사에서는 고객의 레거시 인프라에 Puppet을 성공적으로 구현했습니다. 우리는 또한 Docker 컨테이너를 사용하여 전용 서비스를 실행하고 있습니다(실제로는 컨테이너에 맞게 잘리고 뒤틀린 오래된 애플리케이션입니다).
처음 컨테이너 작업을 시작했을 때는 컨테이너가 마음에 들지 않았지만(예... 30kb 앱이 200MB의 무거운 이미지가 됩니다) 작은 재해가 발생한 후 전체 환경을 다시 만들어야 했을 때 마음이 바뀌었습니다. 저는 Docker가 바로 서버 구성에 대한 걱정 없이 빠르고 자주 배포하기 위해 발명되었다고 생각합니다. 컨테이너를 올바르게 설계하면 클라우드 공급자, 개발자 노트북 및 코로케이션 데이터 센터 간에 쉽게 전환할 수 있습니다. 왜냐하면 Docker 데몬이 포함된 바닐라 Linux 상자만 있으면 되기 때문입니다.
- 시나리오 1)에서는 모든 것이 한 곳에 있습니다(Docker를 사용하면 동일한 저장소에 코드와 구성이 있기 때문에 하나를 의미합니다). 관리, 읽기 및 배포가 쉽습니다.
- 시나리오 2)에서는 3가지 다른(!) 도구에 대한 구성 부분을 한 저장소에 저장하고 애플리케이션 코드를 다른 저장소에 저장해야 하므로 상황이 더욱 복잡해집니다.
나는 또한 이전 프로젝트에서 Puppet을 사용하고 있었고 지금까지 내 경험에 따르면 불변 서버는 Puppet이나 Chef보다는 Docker를 사용하여 달성할 수 있다는 것입니다. 저는 구성 관리 도구가 개발 팀보다는 클라우드 제공자에게 더 유용하다고 생각합니다.
답변2
여기 내 2유로센트가 있습니다.
귀하가 제안한 두 가지 옵션은 (일종의) 불변성을 달성하기 위한 유효한 옵션입니다.
좀 더 편한 쪽을 선택하시면 될 것 같아요.
그러나 당신이 쓴 내용에 따르면 아직 합의가 이루어지지 않은 것 같습니다.
그렇다면 아마도 세 번째 옵션이 필요할 것입니다. ;)
그러나 이러한 불변성은 목표가 아니라 다른 속성(구성 드리프트 없음, 안정성 향상 등)을 보장하기 위한 수단입니다.
나는 내 목표를 명확하게 설명하고 이를 검증하기 위해 몇 가지 측정항목을 설정하고 두 가지 옵션을 사용하여 몇 가지 테스트를 수행했습니다. 그러면 귀하의 비즈니스에 가장 적합한 수치를 선택할 수 있습니다.
행운을 빌어요!