Wchodzimy w interesujący spór i dzielimy się na dwa obozy. Interesują mnie jakieś szczególne problemy z pomysłem lub problemami, które mogą nam brakować. Naprawdę wszystko, co może nam pomóc w podjęciu decyzji lub wskazaniu rzeczy, których nie bierzemy pod uwagę. Wiem, że omija to nieco zasadę „bez opinii”, ale mam nadzieję, że nadal jest to zadowalające pytanie. Przepraszam również za długość, jest trochę niuansów.
1) Jedna strona (moja - nie jestem bez uprzedzeń) uważa niezmienny model serwera za bardzo interesujący dla systemów chmurowych. W tym celu zaprojektowaliśmy prototypy, przenosząc wszystkie elementy naszej infrastruktury do Docker. Nasze niestandardowe aplikacje budowane są za pośrednictwem Jenkins bezpośrednio w obrazach Docker, które są wdrażane w lokalnym rejestrze Docker. Następnie stworzyliśmy duży zestaw ról Ansible i podręcznik, który jest w stanie dotrzeć do pustego serwera, zainstalować Docker, a następnie nakazać Dockerowi zainstalowanie wszystkich kontenerów w razie potrzeby. Po kilku minutach cała aplikacja i cała obsługiwana przez nią infrastruktura jest podłączona i działa - rejestrowanie, monitorowanie, tworzenie baz danych / populacja itp. Gotowa maszyna jest samodzielnym środowiskiem kontroli jakości lub dewelopera z dokładną kopią podanie. Nasz plan zwiększenia tej skali polegałby na tworzeniu nowych Playbooków do budowania nowych serwerów AWS z bazowego zaufanego AMI (prawdopodobnie bardzo gorzej obraz), przeprowadzania ciągłych wdrożeń aplikacji produkcyjnej do obsługi zarządzania konfiguracjami i wydaniami i ogólnie nigdy więcej nie edytuj serwerów - po prostu zrób je od nowa. Nie martwię się o uzyskanie tego, co opisałem, w praktyce - tylko jeśli jest to rozsądny model.
2) Drugi obóz chce używać Puppet do zarządzania konfiguracją, Ansible do wdrażania naszych niestandardowych aplikacji, które są tarballami generowanymi z naszego procesu kompilacji, Foreman do obsługi wyzwalania i zarządzania całym procesem, a Katello do wykonania pewnej ilości bazy zarządzanie obrazami. Wydania obejmowałyby zmianę konfiguracji Puppet według potrzeb i Ansible wdrażanie zaktualizowanych komponentów przy pewnej koordynacji koordynatora. Serwery byłyby budowane dość szybko, gdybyśmy potrzebowali nowych, ale naszym celem nie jest uczynienie ich jednorazowymi w ramach standardowego procesu. Jest to jednak bliższe modelowi serwera Phoenix, ale ma długą żywotność.
Moje pytanie naprawdę sprowadza się do tego: czy niezmienny model serwera z narzędziami, które opisałem powyżej, jest tak realistyczny, jak się wydaje? Podoba mi się pomysł, że naszym procesem tworzenia aplikacji może być dosłownie budowanie całego klonu aplikacji w czasie rzeczywistym, pozwalanie na kontrolę jakości przez QA, a następnie po prostu przerzucanie pamięci bazy danych i niektórych ustawień DNS, aby ją uruchomić.
A może niezmienny model serwera zawodzi w praktyce? Mamy duże doświadczenie zarówno w środowisku AWS, jak i w chmurze, więc to nie jest tak naprawdę problem - bardziej kwestia tego, jak uzyskać odpowiednio zaawansowaną aplikację niezawodnie wdrażaną w przyszłości. Jest to szczególnie interesujące, ponieważ publikujemy dość często.
Ansible robi większość rzeczy, z wyjątkiem tworzenia serwerów EC2 dla nas i to nie jest trudne. Mam problem ze zrozumieniem, dlaczego w ogóle POTRZEBUJESZ Puppet / Foreman / Katello w tym modelu. Docker jest znacznie czystszy i prostszy niż niestandardowe skrypty wdrażania w naprawdę dowolnym narzędziu, jakie znam. Ansible wydaje się o wiele prostszy w użyciu niż Puppet, kiedy przestajesz martwić się koniecznością konfigurowania ich na miejscu i po prostu budować je ponownie w nowej konfiguracji. Jestem fanem zasady KISS - szczególnie w automatyce, w której panuje prawo Murphy'ego. Im mniej maszyn, tym lepsza IMO.
Wszelkie uwagi / komentarze lub sugestie dotyczące tego podejścia będą mile widziane!