Czy narzędzia do zarządzania konfiguracją są odpowiednie do użycia jako narzędzia do wdrażania?

Z tyłu mojej odpowiedzi na pytanie: W jaki sposób DevOps może pomóc w ulepszeniu procedur Escrow Software? Tensibai miał pytanie:

Co wymagałoby Capistrano na lalce lub szefie kuchni?

Moja odpowiedź polegała na opublikowaniu linku do artykułu Noah Gibbs „Czy potrzebujemy zarówno Capistrano, jak i szefa kuchni?” . Osobiście nadal popieram pogląd Noego, że najbardziej właściwe jest:

• użyj specjalistycznego narzędzia do wdrażania, takiego jak Capistrano, do wdrożeń.
• użyj specjalistycznego narzędzia do zarządzania konfiguracją, takiego jak Chef, do zarządzania konfiguracją.

Podstawowe podejście każdego typu narzędzia do wykonania zadania jest bardzo różne:

• Narzędzia do zarządzania konfiguracją - służą do tworzenia i utrzymywania pożądanego stanu systemu, są z natury idempotentne. Przykłady narzędzi do zarządzania konfiguracją to Chef , Puppet , Ansible , PowerShell DSC , Salt Stack .

• Narzędzia wdrażania - polegają na dostarczaniu wersji oprogramowania do środowiska hostingowego, zapewniają funkcjonalność umożliwiającą utrzymanie wielu wersji oprogramowania na wielu komputerach i zarządzanie, która wersja jest „aktualna”, z natury są bezwzględnie konieczne. Przykłady narzędzi do wdrażania to Capistrano , Octopus Deploy , Deployer i Command.io .

Wierzę, że Narzędzia do zarządzania konfiguracją mogą wykonywać zadania związane z wdrażaniem, aw przypadku infrastruktury niezmiennej są one najbardziej odpowiednim narzędziem do tego zadania, ponieważ wersje oprogramowania docelowego nie muszą być utrzymywane.

Pytanie: Czy narzędzia do zarządzania konfiguracją, takie jak Chef, Ansible i Puppet, są tak dojrzałe, że są w stanie spełnić zarówno idempotentne, jak i imperatywne modele?

W takim kontekście typowa rada powinna mieć natychmiastowe zastosowanie: użyj odpowiedniego narzędzia do pracy.

Ale wtedy nie można również zignorować w dzisiejszych czasach prawie zjadliwej tendencji narzędzi programowych do rozszerzania funkcjonalności na mniej lub bardziej powiązane pola i faktycznie stają się zestawami narzędzi z różnych powodów: fajne funkcje, poszerzenie bazy klientów, gromadzenie większych przychodów itp.

Na przykład wiele narzędzi do zarządzania plikami obejmuje funkcje przeglądania obrazów, a wiele narzędzi do przetwarzania obrazów obejmuje funkcje zarządzania plikami. Możesz przenosić pliki i przeglądać obrazy za pomocą jednego z narzędzi, często równie dobrze.

Z tego powodu całkiem możliwe jest, aby całe części procesu tworzenia oprogramowania były pokrywane / nakładane na wiele narzędzi (zestawów), nawet jeśli ich główna cecha / możliwości są różne.

Tak naprawdę sprowadza się to do dokładnej funkcjonalności, którą chcesz osiągnąć w danym procesie i tego, jak dobrze jedno narzędzie działa w twoim kontekście . Uwzględniono subiektywność / preferencje / wygodę.

Czyniąc to pytanie przede wszystkim opartym na opiniach;)

Narzędzia do zarządzania konfiguracją służą do wprowadzenia znanego stanu systemu. Narzędzia wdrażania wdrażają nowe pliki programu i dane programu w systemie. Na koniec oba typy narzędzi wykonują kombinację:

• Określ bieżący stan systemu.
• Prześlij pliki do systemu.
• Dodaj lub zmień trwałe dane (np. Pliki konfiguracyjne, dane bazy danych, ustawienia rejestru)
• Uruchom lub uruchom ponownie programy.

Narzędzia do zarządzania konfiguracją mają deklaratywne języki, które określają stan systemu. Narzędzia wdrażania mają imperatywne języki, które każą systemowi robić różne rzeczy. Osoba DevOps musi zrobić jedno i drugie.

Używając narzędzia do wdrażania Capistrano, niezdarnie jest używać jego języka, aby powiedzieć systemowi, aby upewnić się, że serwer WWW jest aktywny. Musisz wydać polecenie, aby zrestartować serwer WWW, a drugie, aby sprawdzić, czy serwer WWW działa. To kludge, aby wprowadzić serwer WWW do znanego stanu.

Za pomocą narzędzia do zarządzania konfiguracją Ansible ponowne uruchomienie serwera WWW jest niezdarne. Język pozwala powiedzieć serwerowi internetowemu, że ma być „uruchomiony”, ale jeśli chcesz go zrestartować, musisz ustawić jego stan na „restart”. Ale nie ma łatwego sposobu sprawdzenia, czy serwer WWW został ponownie uruchomiony. To jest kludge w Ansible, aby umożliwić jednorazowe operacje.

Niektórzy ludzie wolą wykonywać oba rodzaje zadań za pomocą jednego narzędzia i pracować nad szorstkimi krawędziami. Inni ludzie wolą mieć dwa narzędzia do robienia prawie tego samego, ale bez szorstkich krawędzi. Aby odpowiedzieć na pytanie, „odpowiedniość” jest kwestią gustu. Ta odpowiedź wyjaśnia dlaczego.

TL; DR : Wystarczy użyć Ansbile, jest to zarówno narzędzie do konfiguracji, jak i wdrażania :)

Istnieje kilka rodzajów wdrażania:

• Oparte na aplikacji (pliki, archiwa)

• Oparte na kontenerach (obejmuje maszyny wirtualne, środowisko, LXC, dok)

• Oparte na funkcjach (Mikro usługi / Lambdas / Funkcje)

Zakładam, że w tym przypadku mówimy tylko o aktualizacjach aplikacji na serwerach.

W przypadku wdrożenia musisz mieć dwie rzeczy:

1. Prawidłowe pliki lub pakiety należy przenieść na serwer.
2. Konfiguracja i stany usługi muszą ulec zmianie.

Teraz dla (1) możesz używać wielu strategii:

• Repozytoria artefaktów / synchronizacja
• Repozytoria pakietów / Kierownicy paczek
• System kontroli wersji / Aktualizacja + Kompilacja (opcjonalnie)
• Protokoły przesyłania plików (scp, rsync, ftp)
• Narzędzia do wdrażania

Do (2) możesz użyć:

• Narzędzia do zarządzania konfiguracją
• Narzędzia do wdrażania

Tak więc chociaż Narzędzia wdrażania są sposobem na wdrożenie wszystkich w jednym, nie zawsze są najlepszą strategią. Czasami chcesz użyć kombinacji tych sposobów wdrażania. Najprawdopodobniej już używasz już menedżerów pakietów, przynajmniej na swoich serwerach. I tak najprawdopodobniej uruchomisz narzędzia konfiguracyjne. Problem z niektórymi narzędziami konfiguracyjnymi polegał na właściwej organizacji wielu serwerów, ale teraz nawet Chef i Puppet mogą to zrobić całkiem dobrze. Ansible zawsze był w tym dobry.

Z własnego doświadczenia korzystałem ze wszystkich kombinacji, ale obecnie używamy Capistrano do wdrażania i Ansible sync do zarządzania konfiguracją oraz VCS i repozytoria pakietów do przesyłania plików, ale są problemy z Capistrano i planujemy odejść od niego do ujednolicić na Ansible zarówno w zakresie wdrażania, konserwacji i zarządzania konfiguracją.

Wdrożenie aplikacji jest trudne do ustalenia, ponieważ ma wiele podproblemów. Systemy zarządzania konfiguracjami doskonale nadają się do modelowania zadań, które są zbieżne i działają z „jaki jest pożądany stan systemu”. W kontekście wdrażania aplikacji jest to idealne rozwiązanie do wdrażania bitów na komputerze, zarządzania plikami konfiguracyjnymi i konfigurowania usług systemowych. To, co jest wyjątkowo złe, to rzeczy, które są z natury proceduralne, w szczególności migracje baz danych i restartowanie usługi. Zwykle staram się umieścić zbieżną logikę w Chef i pozwolić zewnętrznemu narzędziu proceduralnemu (zwykle w moim przypadku Fabric) obsłużyć kilka pozostałych bitów, a także sekwencjonować rzeczywiste zbieżności.

Zasadniczo powinieneś użyć obu tych elementów, w których są najlepsze.

W przypadku oprogramowania i wdrażania kodu na istniejącym serwerze lub w kontenerze Docker odpowiedź jest stosunkowo prosta - Nie, nie potrzebujesz obu, ale możesz chcieć obu, jeśli inne narzędzie lub narzędzie wnosi wartość dodaną i jest odpowiednim narzędziem do zadania , jednak sprawy stają się bardziej skomplikowane podczas wdrażania serwerów i systemów operacyjnych.

Jedną wartością dodaną mentalności DevOps jest traktowanie infrastruktury jako kodu i częste wdrażanie lub niszczenie maszyn wirtualnych, a nawet goły metal w wysoce elastycznym środowisku. Twój system zarządzania konfiguracją nie może łatwo uruchomić z sieci i uruchomić twojego serwera dla ciebie i nie może zarządzać repozytoriami, pakietami i aktualizacjami / łatkami dla ciebie podczas i po wdrożeniach lub w niektórych przypadkach, licencjonowaniu i uprawnieniach.

W przypadku Amazon Web Services jest to raczej dogodnie obsługiwane przez interfejsy API, ale dla tych z nas, którzy muszą zarządzać własnymi centrami danych, nie jest to opcja. Z tego powodu projekt Foreman (i Red Hat, który zmienia tę markę ) uznał za konieczne połączenie Katello , Candlepin i menedżera konfiguracji, takiego jak Ansible, Foreman lub Puppet, podczas wdrażania scenariusza Katello .

Tak więc, chociaż możesz uciec od używania narzędzi do zarządzania konfiguracją do wdrażania kodu oprogramowania po stronie deweloperów, po stronie operacyjnej, istnieje kilka przypadków, w których odpowiedź brzmi: „nie, narzędzia do zarządzania konfiguracją nie są odpowiednie do użycia jako narzędzia do rozmieszczania „Takie postępowanie wymagałoby poważnego ponownego wynalezienia koła i jest niepraktyczne. Zamiast tego należy użyć narzędzi do zarządzania konfiguracją, aby zainicjować wdrożenia w innym narzędziu.