Pracuję z wieloma projektami, więc rozwiązanie cjc nie będzie dla mnie działać. Występuje również problem konfiguracji wspólnej z niestandardową (adresy itp. Są wspólne dla firmy, jest też trochę magii w konfiguracjach). Schemat, na którym ostatecznie się zdecydowałem, jest trochę włamaniem, ale jest wygodny w użyciu.
Zamiast globalnego ~/.chefużywam podkatalogu „.chef” w repozytorium szefów kuchni, który nie jest przechowywany w git (jest dodawany do .gitignore). Mam również plik config/knife.rb, który jest zapisany w Git i zawiera udostępnioną konfigurację. Zaczyna się od tego fragmentu:
root_dir = File.join(File.dirname(__FILE__), '..')
%w(knife-secrets.rb knife-local.rb).each do |conf_name|
conf = File.join(root_dir, ".chef", conf_name)
Kernel::load(conf) if File.exists? conf
end
To ładuje pliki .chef/knife-local.rbzawierające konfigurację niestandardową (w podstawowej wersji jest to po prostu OPSCODE_USER='username'stała, która jest później używana, ale może zawierać dowolną konfigurację noża) i .chef/knife-secrets.rbktóra zawiera wspólne sekrety (klucze AWS itp.).
Poniżej znajduje się regularna konfiguracja noża, która wykorzystuje stałe zdefiniowane w tych plikach, np .:
client_key "#{root_dir}/.chef/#{OPSCODE_USER}.pem"
W ten sposób osiągam standaryzację konfiguracji noża w całej firmie, co z kolei oznacza, że każdy fragment kodu lub wywołanie noża udostępnione na wiki będzie działać dla wszystkich. W samym nożu jest dość zamieszania i magii - różne konfiguracje tylko pogorszyłyby sytuację. Ponadto każdy zyskuje dzięki małym magicznym fragmentom, takim jak ten, który umożliwia knife sshkorzystanie z logowania skonfigurowanego przez użytkownika~/.ssh/config
Jest także kwestia wspólnych tajemnic: klucz sprawdzania poprawności serwera szefa kuchni, przechowywane w nim klucze AWS knife-secrets.rb, prywatny klucz SSH EC2, klucze zaszyfrowanej torby danych i tak dalej. Zdecydowanie nie chcemy, aby były one przechowywane w repozytorium - a właściwie gdziekolwiek, gdzie nie są bezpiecznie szyfrowane. Rozpowszechniamy więc te pliki jako .tar.gzplik, który jest szyfrowany GPG wszystkim w firmie i udostępniany przez Dropbox.
Konfiguracja tego wszystkiego staje się skomplikowana i chcę, aby ludzie w zespole faktycznie z niej korzystali, więc jest ostatni element: rake initzadanie, które tworzy .chefkatalog, dowiązania config/knife.rbtam, odszyfrowuje i rozpakowuje chef-secrets.tgzplik, upewnia się, że prywatny klucz użytkownika Opscode Platforma jest tam i .chef/knife-local.rbjest poprawnie skonfigurowany, symbolizuje wtyczki noży i ustawia odpowiednie uprawnienia do katalogu i plików w nim zawartych. To zadanie jest skonfigurowane tak, aby można było bezpiecznie uruchamiać je wielokrotnie w już zainicjowanym repozytorium (np. W celu aktualizacji sekretów lub wtyczek noża).
Istnieje również zadanie pomocnika, które przepakowuje wszystkie sekrety, szyfruje tarball wszystkim i kopiuje je do Dropbox, aby ułatwić dodawanie nowych pracowników lub zmianę tajemnic.
Odnośnie wielu środowisk: szef kuchni ma funkcję zwaną środowiskami . Jeszcze go nie użyłem, ale powinien zrobić to, czego potrzebujesz. Możesz także ściśle oddzielić środowisko produkcyjne (aby uniknąć deweloperów posiadających klucze, które w jakikolwiek sposób odnoszą się do środowiska produkcyjnego) poprzez posiadanie dwóch oddzielnych organizacji Hosted Chef lub serwerów Chef. Ten fragment knife.rb pokazuje, jak skonfigurować nóż w inny sposób w oparciu o aktualnie sprawdzoną gałąź - możesz go użyć do ustawienia środowiska, a także adresu URL serwera szefa kuchni. Dostępna jest również wtyczka noża zwana nożem-przepływem , zapewniająca pełniejszy przepływ pracy obejmujący dwie organizacje.
.cheffolder do używania zmiennych środowiskowych lub czegoś takiego?