Model niezmiennego serwera z Dockerem / Ansible vs. Ansible, Puppet i Foreman w AWS?

9

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!

Doktor John Wick
źródło
Moje uprzedzenia są zgodne z twoimi. Korzystam ze wszystkich głównych systemów zarządzania konfiguracją od miesięcy, jeśli nie lat, nie wyobrażam sobie używania marionetki do nowego projektu w dzisiejszych czasach. Szef kuchni jest bardziej dojrzałym wyborem, jeśli chcesz trzymać się systemów opartych na rubinie. Ansible wydaje się być najlepszą rasą w dzisiejszych czasach, ale sól jest również dobrym wyborem.
pisklęta
Marionetka i ansible? Będziesz miał zły czas.
dmourati
Docker otwiera możliwość korzystania z kubernetes, co oznacza automatyczne skalowanie, samoleczenie itp. Pole kontenera dojrzewa teraz i jest bardzo dobrą opcją, jeśli aplikacja może pasować do paradygmatu
mikrousług

Odpowiedzi:

1

W naszej firmie z powodzeniem wdrożyliśmy Puppet na starszej infrastrukturze klienta. Używamy również kontenerów Docker do prowadzenia dedykowanej usługi (która w rzeczywistości jest starą aplikacją przyciętą i skręconą w celu dopasowania do kontenerów).
Nie byłem zadowolony z kontenerów, kiedy pierwszy raz zacząłem z nimi pracować (tak ... aplikacja 30kb staje się ciężkim obrazem o wielkości 200 MB), ale kiedy musiałem odtworzyć całe środowisko po małej katastrofie, zmieniłem zdanie. Myślę, że Docker został wymyślony właśnie w tym celu: szybkie i często wdrażane bez obaw o konfigurację serwera. Jeśli odpowiednio zaprojektujesz kontenery, możesz łatwo przełączać się między dostawcami chmury, laptopami dla programistów i centrami danych kolokacji. Ponieważ wszystko, czego potrzebujesz, to waniliowe pudełko Linux z demonem Docker.

  • W scenariuszu 1) masz wszystko w jednym miejscu (mam na myśli jedno, ponieważ dzięki Dockerowi będziesz mieć kod ORAZ konfigurację w tym samym repozytorium) łatwe do zarządzania, czytania i wdrażania.
  • W scenariuszu 2) musisz przechowywać części konfiguracyjne dla 3 różnych (!) Narzędzi w jednym repozytorium, a kod aplikacji w drugim, co komplikuje sprawę

Używałem również Puppet w moim poprzednim projekcie i moje dotychczasowe doświadczenie polega na tym, że niezmienny serwer jest osiągalny raczej dzięki Dockerowi niż Puppet lub Chef. Uważam, że narzędzia do zarządzania konfiguracją są bardziej przydatne dla dostawców usług w chmurze niż dla zespołu programistów.

alxndr
źródło
0

Oto moje 2 centy euro.

Dwie proponowane opcje są prawidłowymi opcjami do osiągnięcia (pewnego rodzaju) niezmienności.
Myślę, że powinieneś wybrać ten, z którym czujesz się bardziej komfortowo.
Jednak z tego, co piszesz, wydaje się, że nie ma jeszcze konsensusu.
Być może potrzebna jest trzecia opcja? ;)

Ponieważ jednak niezmienność nie jest celem, ale środkiem do zapewnienia innych właściwości (brak odchyleń konfiguracji, lepsza stabilność, ...).
Wyraźnie określiłbym swoje cele, podałem miary, aby je zweryfikować i wykonałem testy przy użyciu 2 opcji. Miałbyś wtedy kilka liczb, aby wybrać ten, który najlepiej pasuje do Twojej firmy.

Powodzenia!

sebbrochet
źródło