Vagrant Shell vs puppet vs chef

Question

Vagrant Shell vs puppet vs chef

Mam następującą konfigurację:

wiele różnych projektów, które są oddzielnymi repozytoriami git, ale wszystkie mają w większości tę samą konfigurację serwera
każdy projekt z kolei zależy od wielu innych projektów i używamy menedżera zależności composer, aby je połączyć (język PHP tutaj).

Chcę użyć Vagrant i dołączyć plik Vagrant do każdego repozytorium, aby członkowie mojego zespołu mogli sklonować repozytorium, uruchomić vagrant up i być gotowi do pracy.

Moje pytanie brzmi teraz kieruję się w stronę zaopatrzenia. Muszę zainstalować kilka narzędzi i pakietów, takich jak apache, git, mysql i kilka pakietów php, a następnie pobrać kilka plików (jak niedawny zrzut dB development), ustawić wszystko w /var/www i uruchomić komendę install composer.

Więc jedną z opcji, aby to zrobić, jest użycie Menedżera przy użyciu przepisów takich jak szef kuchni lub pacynka. Alternatywą byłoby napisanie pliku bash i użycie aprowizacji powłoki.

Nie mam dużego doświadczenia z kucharzem / kukiełką, więc oczywiście, łatwiej jest użyć opcji powłoki, ale chcę zrozumieć, czy nie jest to dobra / realna opcja na dłuższą metę.

Dlaczego dla mnie to kiepskie podejście do pacynki / szefa kuchni:

Rozumiem, że będę musiał użyć kilku różnych receptur i prawie zawsze będę używał tych samych receptur dla moich różnych repozytoriów, więc musiałbym uwzględnić je wszystkie we wszystkich repozytoriach. Rozważ posiadanie 20 repo i potrzebujesz 10 przepisów, co oznacza, że będę musiał dodaj 200 receptur jako podmodule git lub podobne (również każdy członek zespołu musi sklonować repozytorium, następnie sklonować 10 repozytoriów receptur i dopiero wtedy uruchomić vagrant dla każdego projektu). W przeciwieństwie do tego, chciałbym po prostu mieć mały repo z moim skryptem powłoki i sklonować go 20 razy.

Prawdopodobnie czegoś mi brakuje, więc proszę o poradę, czy powinienem wybrać chef / puppet i dlaczego ma to sens, nawet jeśli moje repozytoria mają bardzo podobną konfigurację serwera.

37

shell vagrant provisioning chef puppet

Author: mpaepper, 2013-11-09

Source

2 answers

Aktualizacja 2016

Dla tych, którzy znaleźli to za pośrednictwem Google, wydaje się Banda programistów idą w kierunku Ansible dla prostoty. From post:

" Ansible to narzędzie do wdrażania dla osób, które nie lubią narzędzi wdrażania. Jest zbliżony do skryptów, nie zanieczyszcza serwerów agentami lub scentralizowanymi serwerami i ma natychmiastowy sens."

Zaimplementowaliśmy go niedawno w naszej architekturze mikrousług i został Super.

Super simple
zajęło około dnia, aby odebrać
naprawdę nie trzeba myśleć o tym, gdy jesteś ustawiony

Puppet / chef zawsze ma miejsce w moim sercu/ stos , ale Ansible jest po prostu łatwiejsze.

2

Author: the_red_baron,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-11-23 17:47:37

score 25 · Accepted Answer

Poniższy artykuł dotyczy jeszcze jednego narzędzia CM (ansible), ale myślę, że autor doskonale wyjaśnia korzyści płynące z odejścia od skryptów powłoki.

Http://devopsu.com/blog/ansible-vs-shell-scripts/

Cytat 1:

To, co naprawdę mnie zaskoczyło, to odpowiedź niektórych z tych bardziej znanych deweloperów. W zasadzie powiedzieli: "To jest naprawdę fajne, ale prawdopodobnie nie przeczytam tego, ponieważ mój manual-install/shell-script workflow jest na razie w porządku."

Byłem trochę zszokowany, ale kiedy przez kilka minut myślałem o tym, zdałem sobie sprawę, że ich wybór był całkowicie rozsądny i racjonalny, biorąc pod uwagę to, co wiedzą o narzędziach CM.

Cytat 2:

Dla nich korzystanie z narzędzia CM oznaczało tygodnie wysiłku uczenia się złożonych koncepcji, zmagania się ze złożonym procesem instalacji i utrzymywania tego złożonego systemu w czasie. Byli w pewnym stopniu świadomi korzyści, ale koszty korzystania z CM narzędzie wydawało się zbyt wysokie, aby było warte wysiłku.

Korzyści w stosunku do skryptów powłoki są podsumowane na końcu i myślę, że dotyczą one wszystkich narzędzi CM, puppet, chef, salt, ansible...

Która metoda najprawdopodobniej zakończy się kontrolą źródła?
Która metoda może być uruchamiana wielokrotnie bezpiecznie z pewnością?
którą metodę można łatwo uruchomić na wielu serwerach?
jaka metoda faktycznie weryfikuje (testuje) Twój serwer pod kątem poprawność?
jaką metodą można łatwo kierować na niektóre serwery (web, db, etc)?
Która metoda umożliwia łatwe tworzenie szablonów plików konfiguracyjnych?
Która metoda będzie rosła, aby łatwo obsługiwać cały stos?

Mam nadzieję, że to pomoże.