우리는 흥미로운 논쟁에 빠지고 있으며 두 개의 수용소에 빠지고 있습니다. 아이디어 나 문제가있는 특정 문제에 관심이 있습니다. 실제로, 결정을 내리거나 설명하지 않은 것을 지적하는 데 도움이 될 수있는 모든 것. 나는 이것이 "의견이없는"규칙에 가깝다는 것을 알고 있지만 여전히 수용 가능한 질문이기를 바란다. 길이도 미안하지만, 약간의 뉘앙스가 있습니다.
1) 한쪽 (광산-나는 편견이 없다)은 불변의 서버 모델이 클라우드 시스템에 매우 흥미 롭다는 것을 안다. 이를 위해 인프라의 모든 구성 요소를 Docker로 이동하는 프로토 타입을 제작했습니다. 우리의 사용자 정의 응용 프로그램은 Jenkins를 통해 로컬 Docker Registry에 배포되는 Docker 이미지에 직접 빌드됩니다. 그런 다음 빈 서버에 연결할 수있는 대규모 Ansible 역할과 플레이 북을 만들고 Docker를 설치 한 다음 Docker에 모든 컨테이너를 필요에 따라 설치하도록 지시합니다. 몇 분 후 전체 앱과 모든 지원 인프라가 유선, 작동, 로깅, 모니터링, 데이터베이스 생성 / 인식 등입니다. 완성 된 머신은 자체적으로 포함 된 QA 또는 개발 환경으로 신청. 이 확장 계획은 신뢰할 수있는 기본 AMI (아마도 이미지가 거의 없음)에서 새로운 AWS 서버를 구축하기 위해 새로운 Playbook을 만들고, 구성 관리 및 릴리스를 처리하기 위해 프로덕션 애플리케이션을 지속적으로 배포하고 일반적으로 서버를 다시 편집하지 않는 것입니다. 그냥 새로 만드십시오. 합리적인 모델이라면 실제로 작업 한 것을 얻는 것에 대해 걱정하지 않습니다.
2) 다른 캠프는 Puppet을 사용하여 구성 관리를 처리하고, 빌드 프로세스에서 생성 된 타르볼 인 사용자 지정 응용 프로그램을 배포 할 수 있으며, Foreman은 프로세스의 전체 트리거 및 관리를 처리하고, Katello는 약간의 기본 작업을 수행합니다. 이미지 관리. 릴리스에는 필요에 따라 Puppet 구성을 변경하고 일정량의 Foreman 조정으로 업데이트 된 구성 요소를 배포 할 수 있습니다. 새로운 서버가 필요한 경우 서버를 합리적으로 신속하게 구축 할 수 있지만 표준 프로세스의 일부로 서버를 일회용으로 만들지 않아야합니다. 수명이 길지만 피닉스 서버 모델에 더 가깝습니다.
그래서 내 질문은 실제로 이것으로 귀착됩니다. 위에서 설명한 것처럼 도구가있는 불변의 서버 모델이 실제로 보이는 것처럼 현실적입니까? 우리의 스테이징 프로세스가 문자 그대로 애플리케이션의 전체 복제본을 라이브로 구축하고 QA가 망치게 한 다음 데이터베이스 스토리지와 일부 DNS 설정을 뒤집어 라이브로 만들 수 있다는 아이디어를 좋아합니다.
아니면 불변의 서버 모델이 실제로 실패합니까? 우리는 AWS와 클라우드 환경에 대한 풍부한 경험을 보유하고 있으므로 실제로는 걱정할 필요가 없습니다.보다 합리적으로 정교한 앱을 안정적으로 배포하는 방법에 대한 문제입니다. 우리가 자주 출시 할 때 특히 관심의 대상입니다.
실제로 EC2 서버를 생성하는 것을 제외하고 필요한 대부분의 작업을 Ansible에서 수행했습니다. 이 모델에 꼭 꼭 꼭두각시 / 포먼 / 카텔로가 필요한 이유를 이해하는 데 어려움을 겪고 있습니다. Docker는 실제로 말할 수있는 모든 도구에서 사용자 정의 배포 스크립트보다 훨씬 깨끗하고 간단합니다. Ansible은 현장에서 구성해야하는 것에 대해 걱정하지 않고 새로운 구성으로 간단히 다시 빌드 할 때 Puppet보다 사용하기가 훨씬 간단 해 보입니다. 저는 KISS 교장의 팬입니다. 특히 머피의 법칙이 만연하는 자동화 분야입니다. 기계가 적을수록 IMO가 더 좋습니다.
접근 방식에 대한 생각이나 의견이나 제안은 크게 감사하겠습니다!