Najlepsza strategia kontrolowania wersji książek kucharskich

Szukam pomysłów na zarządzanie wersjami książek kucharskich. Wiem, że przypinasz określone wersje do środowiska, ale nie jestem pewien, jak sobie z tym poradzić.

Używamy bibliotekarza-szefa kuchni, który instaluje książki społeczności osób trzecich w folderze książek kucharskich. Nigdy nie dotykamy tych książek i od czasu do czasu aktualizujemy do nowszych wersji.

Posiadamy również nasze niestandardowe książki kucharskie dla konkretnych witryn, z których uwzględniamy te dotyczące społeczności ( include_recipe).

Teoretycznie moglibyśmy określić określone wersje książek społecznościowych, od których zależą nasze książki niestandardowe, a następnie ustawić nasze wersje książek kucharskich w konfiguracji środowiska, ale problem polega na tym, że te książki społecznościowe mogą polegać na niektórych innych książkach bez określonych wersji. I ta głęboko zagnieżdżona zależność może trwać dalej.

Więc nie ma gwarancji, że kiedy załadujesz książkę kucharską na serwer szefa kuchni, nie spowoduje to uszkodzenia prod, ponieważ zależne książki kucharskie również mogą się zmienić.

Jedyne rozwiązanie, jakie obecnie widzę, to określenie każdej wersji książki kucharskiej, której używamy w konfiguracji środowiska, w tym społeczności i niestandardowych. Ale potem muszę przejrzeć każdą książkę kucharską i wymyślić te wersje.

Od czasu do czasu dokonujemy również aktualizacji bibliotekarza-szefa kuchni. Wyobrażam sobie, że może być trudno wyśledzić zmienione wersje i nie zapomnieć o aktualizacji wersji w środowisku, gdy nadejdzie czas.

Podziel się swoim doświadczeniem i najlepszymi praktykami. Jestem pewien, że będzie bardzo przydatny dla innych ludzi.

Niedługo potem zacząłem używać Chef na poważnie, że wpadłem na te same problemy. Dopiero poczułem rozsądek, kiedy zacząłem robić cztery rzeczy operacyjnie. Pamiętaj, że niektórzy członkowie społeczności szefów kuchni mogą nie uznać ich za „najlepsze praktyki”. Niemniej jednak w ten sposób przyniosłem zdrowy świat, powtarzalność i porządek w moim świecie.

1. Twórz własne przepisy. Przestałem całkowicie używać książek kucharskich społeczności i po prostu stworzyłem własne przepisy, zgodnie ze specyfikacjami. W ten sposób zarządzam własnymi zależnościami i kontroluję je. Wielu sprzeciwiłoby się temu, ale szczerze mówiąc - gdybym najpierw przeczytał niektóre przepisy na Opscode i przepisy społeczności, prawdopodobnie nie wybrałbym Chef na początek. Utrzymuję moje przepisy proste i zgodne z moim sposobem pracy. W moim repozytorium mam dokładnie zero wspólnotowych książek kucharskich.
2. Bądź zdyscyplinowany w zakresie aktualizacji. Jeśli aktualizuję przepis, upewniam się, że działa on wszędzie i przechodzę przez dodatkowy problem związany z wdrażaniem go wszędzie, nawet jeśli zakłóca on mój przepływ pracy i powoduje tarcie. Na dłuższą metę jest to klucz do zdrowia psychicznego szefa kuchni. W skrajnych przypadkach, jeśli potrzebuję wersji dla niektórych hostów, takich jak środowisko testowe vs. produkcyjne, koduję je w książce kucharskiej. Ale moja filozofia jest taka, że ​​najnowsza wersja każdej książki kucharskiej powinna być bezpiecznie stosowana wszędzie tam, gdzie jest potrzebna.
3. Użyj Chef Solo do wszystkiego. Co kilka miesięcy w jakiś sposób mam w głowie, że powinienem spróbować ponownie użyć Chef Server. Wydanie społecznościowe się poprawia, ale cały paradygmat nigdy nie pasuje do mojego świata. I za każdym razem, gdy próbuję, dotykam twarzy i kopię się. Paradygmat Chef Server jest odpowiedni dla świata z długowiecznymi serwerami, które wymagają częstych zmian w systemie. Wprowadzam zmiany systemowe tak rzadko, że ciągłe sprawdzanie przez moje serwery aktualizacji na serwerze szefa kuchni jest po prostu głupie. I mam o wiele lepsze narzędzia, aby zapewnić zdrowie moim gospodarzom. Moja praca dotyczy świata maszyn wirtualnych jednorazowego użytku, gdzie mogą przetrwać tylko jedną lub dwie zmiany konfiguracji. Teraz używam wyłącznie Chef Solo i pcham zmiany do moich gospodarzy, jednocześnie przekazując te same książki kucharskie wszystkim potrzebującym.
4. Unikaj kompilowania oprogramowania podczas uruchomień szefa kuchni. Najbardziej ekstremalnym (tj. Głupim) przypadkiem było dla mnie skompilowanie ruby-1.9.3 ze źródła za każdym razem, gdy ładowałem nowe pudełko. Ale tworzenie niestandardowych pakietów często może być uciążliwe. Gdy odkryłem doskonałe narzędzie do tworzenia fpm , stało się trywialne pakowanie własnych rpms, debs i klejnotów i uczyniło moje życie znacznie bardziej wydajnym i łatwym.

Mam nadzieję, że to komuś pomoże!

- AKTUALIZACJA -

Prawie trzy lata później zasady te pozostały mi pomocne. Ale dodam jeszcze jedną radę i to z tych samych powodów, dla których wolałem szefa kuchni solo niż szefa kuchni.

5. UŻYJ ANSIBLE INSTEAD

Istnieją 2 problemy:

1. zarządzać wersjami książek kucharskich w różnych obiektach środowiska
2. zarządzaj wersją receptury w węźle lista_ run.

Artykuł Podstawy wersji książek kucharskichjest najlepszym źródłem informacji o wersjach książek kucharskich. Zgodnie z numerem 1 masz rację, ponieważ zarządzanie różnymi wersjami książek kucharskich w celu obsługi różnych zestawów konfiguracji jest trudne, szczególnie w połączeniu z zależnościami książek kucharskich, w których większość książek kucharskich ze strony książki kucharskiej nie wykonuje tego zadania dobrze. Konfiguracja może się zepsuć. a jeśli nie zarządzałeś wersjami, testując zachowanie dowolnego komponentu w czasie wykonywania, po prostu się psuje. Dlatego złym pomysłem jest przesyłanie książki kucharskiej bez podawania numeru wersji w obiekcie środowiska. Więc zarządzaj wersjami książek kucharskich w obiekcie środowiska i dokładnie testuj promując wersję każdej nowej książki kucharskiej. Zwykle zarządzam obiektem środowiska w SCM i nie przesyłałem go na serwer szefa kuchni za pomocą zautomatyzowanego zadania, dopóki zmieniona książka kucharska nie będzie dobrze współpracować z resztą innych istniejących składników.

Według # 2 jest to trudny temat, ponieważ w tym przypadku rzeczywista zależność od receptury działa na każdym węźle. Krótko mówiąc, w przypadku węzłów krytycznych lepiej kontrolować zależność receptur, określając wersję receptury na liście uruchamiania węzłów / ról. Prawie tego nie robię, ponieważ zapewnia dobrą kontrolę piasku i kosztuje więcej na testowanie / promocję. Jednak w przypadku krytycznej roli / węzła nie jest to zły pomysł, ale zapewnia ubezpieczenie od zmian konfiguracji.