chake - Online w chmurze

PROGRAM:

IMIĘ

chake - konfiguracja bezserwerowa z szefem kuchni

WPROWADZENIE

chake to narzędzie, które pomaga zarządzać wieloma hostami bez konieczności zatrudniania szefa kuchni
serwer. Konfiguracja jest zarządzana w lokalnym katalogu, który prawdopodobnie powinien znajdować się pod
kontrola wersji z odrzutowiec(1) albo coś innego. Konfiguracja jest zwykle wdrażana przez rsync
przez SSH i stosowane przez wywołanie szef kuchni solo(1) przez SSH na każdym hoście.

TWORZENIE THE MAGAZYN

$ chake inicj
[utwórz] nodes.yaml
[mkdir] nodes.d/
[utwórz] config.rb
[ mkdir] konfiguracja/role
[ mkdir] książki kucharskie/podstawy/przepisy/
[utwórz] książki kucharskie/podstawy/przepisy/default.rb
[utwórz] Rakefile

Krótki opis utworzonych plików:

· nodes.yaml: gdzie podasz listę hostów, którymi będziesz zarządzać i jakie przepisy
zastosować do każdego z nich.

· nodes.d: katalog z wieloma plikami w tym samym formacie co nodes.yaml. Wszystkie pliki
pasujące do niego *.yaml zostanie dodane do listy węzłów.

· config.rb: zawiera konfigurację chef-solo. Możesz to modyfikować, ale zwykle ty
nie będzie musiał.

· config/roles: katalog to miejsce, w którym możesz umieścić swoje definicje ról.

· książki kucharskie: katalog, w którym będziesz przechowywać swoje książki kucharskie. Przykładowa książka kucharska pt
„Basics” jest tworzony, ale możesz go usunąć i dodać rzeczywiste książki kucharskie.

· Rakefile: Zawiera tylko wymaganą linię „chake”. Możesz go rozszerzyć o inne zadania
specyficzne dla Twojej infrastruktury.

Po utworzeniu repozytorium możesz wywołać chake lub rake, ponieważ są one całkowicie
odpowiednik.

ZARZĄDZAJĄCY WĘZŁY

Tuż po utworzeniu repozytorium zawartość pliku nodes.yaml jest następująca:

host1.mojafirma.com:
lista_uruchamiania:
- przepis [podstawy]

Możesz wyświetlić listę hostów z węzłami prowizji:

$ rake węzłów
host1.mojafirma.com ssh

Aby dodać więcej węzłów, po prostu dołącz do nodes.yaml:

host1.mojafirma.com:
lista_uruchamiania:
- przepis [podstawy]
host2.mojafirma.com:
lista_uruchamiania:
- przepisy [podstawy]

Chake wie teraz o twoim nowym węźle:

$ rake węzłów
host1.mojafirma.com ssh
host2.mojafirma.com ssh

PRZYGOTOWANIA WĘZŁY DO BE MANAGED

Węzły mają bardzo niewiele początkowych wymagań, którymi można zarządzać za pomocą chake:

· Węzeł musi być dostępny przez SSH.

· Użytkownik, z którym łączysz się z węzłem, musi być albo rootem, albo mieć pozwolenie na uruchamianie sudo (w
który przypadek sudo musi być zainstalowany).

A noty on password monity: za każdym razem, gdy chake wywołuje ssh w węźle, może być wymagane
wpisz swoje hasło; za każdym razem, gdy chake wywołuje sudo w węźle, może być konieczne wpisanie
w twoim haśle. W przypadku zarządzania jednym lub dwoma węzłami jest to prawdopodobnie w porządku, ale w przypadku większych
liczby węzłów jest to niepraktyczne. Aby uniknąć monitów o podanie hasła, możesz:

· Skonfiguruj uwierzytelnianie oparte na kluczach SSH. Jest to bezpieczniejsze niż używanie haseł.
Gdy już to robisz, prawdopodobnie chcesz również wyłączyć uwierzytelnianie hasłem
całkowicie i zezwalać tylko na uwierzytelnianie oparte na kluczach

· Skonfiguruj bezhasłowy dostęp sudo dla użytkownika, którego używasz do łączenia się z twoimi węzłami.

SPRAWDŹ ŁĄCZNOŚĆ ROLNICZE INICJAŁ HOST USTAWIAĆ

Aby sprawdzić, czy hosty są poprawnie skonfigurowane, możesz użyć zadania sprawdzania:

$ prowizji sprawdzić

Spowoduje to uruchomienie polecenia sudo true na każdym hoście. Jeśli to przejdzie bez Twojej konieczności
hasła, jesteś tego pewien

· masz dostęp SSH do każdego hosta; I

· użytkownik, z którym się łączysz, ma poprawnie skonfigurowane sudo bez hasła.

$ prowizji sprawdzić

STOSOWANIE KSIĄŻKI KUCHARSKIE

Aby zastosować konfigurację do wszystkich węzłów, uruchom

$ rake zbieżne

Aby zastosować konfigurację do pojedynczego węzła, uruchom

$ rake zbieżna: $NODE

Aby zastosować pojedynczą recepturę na wszystkich węzłach, uruchom

Obowiązuje prowizja w wysokości $[mój przepis]

Aby zastosować pojedynczą recepturę na określonym węźle, uruchom

$ rake dotyczy: $NODE[mój przepis]

Jeśli nie podasz przepisu w wierszu poleceń, zostaniesz o to poproszony.

Aby uruchomić polecenie powłoki na wszystkich węzłach, uruchom

$ rake run [polecenie]

Jeśli polecenie, które chcesz uruchomić, zawiera spacje lub inne znaki specjalne, zrób to
powłoki, musisz je zacytować.

Aby uruchomić polecenie powłoki w określonym węźle, uruchom

$ rake run: $NODE [komenda]

Jeśli nie poinformujesz o poleceniu w wierszu poleceń, zostaniesz o to poproszony.

Aby sprawdzić istniejące zadania, uruchom

$ prowizji -T

PISANIE KSIĄŻKI KUCHARSKIE

Ponieważ Chake jest właściwie opakowaniem Chef Solo, powinieneś przeczytać [dokumentację szefa kuchni](
).
W szczególności spójrz na [Dokumentację szefa kuchni](
szef_solo.html>).

THE Węzeł URUCHOMIENIE PROCES

Kiedy Chake działa na węźle po raz pierwszy, musi go uruchomić. Bootstrapowanie
proces obejmuje wykonanie następujących czynności:

· instalacja chefa i rsync

· wyłączenie demona klienta szefa kuchni

· konfigurowanie nazwy hosta

Węzeł adresy URL

Klucze w mieszaniu, które są reprezentowane w pliku nodes.yaml, to adres URL węzła. Wszystkie komponenty
adres URL, ale nazwa hosta są opcjonalne, więc po prostu wymienienie nazw hostów jest najprostszą formą
określając swoje węzły. Oto wszystkie składniki adresów URL węzłów:

[backend://][nazwa_użytkownika@]nazwa_hosta[:port][/ścieżka]

· backend: backend używany do łączenia się z hostem. ssh lub lokalnie (domyślnie: ssh)

· nazwa użytkownika: nazwa użytkownika, z którym należy się połączyć (domyślnie: nazwa użytkownika na lokalnej stacji roboczej)

· nazwa hosta: nazwa hosta, z którym należy się połączyć (domyślnie: Żaden)

· port: numer portu do połączenia (domyślnie: 22)

· /ścieżka: miejsce przechowywania książek kucharskich w węźle (domyślnie: /var/tmp/chef.$NAZWA UŻYTKOWNIKA)

DODATKOWY ROZWIĄZANIA

# HACZYKI

Możesz zdefiniować zadania rake, które zostaną wykonane przed ładowaniem węzłów, przed
przesyłanie treści zarządzania konfiguracją do węzłów i przed konwergencją. Aby to zrobić,
wystarczy ulepszyć odpowiednie zadania:

· bootstrap_common: wykonywany przed załadowaniem węzłów (nawet jeśli węzły już zostały
ładowany)

· upload_common: wykonywane przed przesłaniem treści do węzła

· converge_common: wykonywane przed konwergencją (tzn. prowadzeniem szefa kuchni)

Przykład:

zadanie :bootstrap_common wykonaj
sh './scripts/pre-bootstrap-checks'
zakończenia

# ZASZYFROWANE AKTA

Dowolne pasujące zakończenia plików .gpg a .asc zostanie odszyfrowany za pomocą GnuPG przed wysłaniem do
węzeł. Możesz ich używać do przechowywania haseł i innych poufnych informacji (klucze SSL,
etc) w repozytorium wraz z resztą konfiguracji.

# REPOZYTORIUM-LOKALNE SSH KONFIGURACJA

Jeśli potrzebujesz specjalnych parametrów konfiguracyjnych SSH, możesz utworzyć plik o nazwie .ssh_config
(lub jakakolwiek nazwa pliku, którą masz w zmiennej środowiskowej $CHAKE_SSH_CONFIG, patrz poniżej
aby uzyskać szczegółowe informacje) w katalogu głównym twojego repozytorium, a chake użyje go podczas wywoływania ssh.

# LOGOWANIE IN DO A HOST

Aby łatwo zalogować się do jednego ze swoich hostów, po prostu uruchom rake login:$HOSTNAME. to będzie
automatycznie używaj konfiguracji SSH lokalnego repozytorium, jak powyżej, więc nie musisz
cały czas wpisuj -F .ssh_config.

# BIEGANIE WSZYSTKO SSH MODŁY Z TROCHĘ PREFIKSÓW COMMAND

Czasami będziesz również chciał lub musiał poprzedzić swoje wywołania SSH jakimś prefiksem
polecenie, aby np. tunelować je przez jakiś centralny węzeł wyjściowy. Możesz to zrobić przez
ustawienie $CHAKE_SSH_PREFIX w swoim środowisku. Przykład:

CHAKE_SSH_PREFIX=zbieżność prowizji tsocks

Powyższe spowoduje, że wszystkie wywołania SSH do wszystkich hostów będą nazywane jako tsocks ssh [...]

# ZBIEŻNY LOCAL HOST

Jeśli chcesz zarządzać lokalną stacją roboczą za pomocą chake, możesz zadeklarować lokalny węzeł, np
to w nodes.yaml:

lokalny://thunderbolt:
lista_uruchamiania:
- rola [stanowisko]

Aby zastosować konfigurację do lokalnego hosta, możesz użyć konwencjonalnej prowizji
converse:thunderbolt lub lokalny specjalny cel rake.

Podczas łączenia wszystkich węzłów, chake pominie węzły, które są zadeklarowane z local://
backend i którego nazwa hosta nie jest zgodna z nazwą hosta w deklaracji. Na przykład:

lokalny://pulpit:
lista_uruchamiania:
- rola [stanowisko]
lokalny://laptop:
lista_uruchamiania:
- rola [stanowisko]

Gdy uruchomisz rake converge na komputerze stacjonarnym, laptop zostanie pominięty i odwrotnie.

ŚRODOWISKO ZMIENNE

· $CHAKE_SSH_CONFIG: Lokalny plik konfiguracyjny SSH. Domyślnie .ssh_config.

· $CHAKE_SSH_PREFIX: Polecenie poprzedzające wywołania SSH (i rsync przez SSH).

· $CHAKE_RSYNC_OPTIONS: dodatkowe opcje do przekazania do rsync. Przydatne np. do wykluczenia dużych
pliki przed przesłaniem na każdy serwer.

· $CHAKE_NODES: Plik zawierający listę serwerów do zarządzania. Domyślnie: nodes.yaml.

· $CHAKE_NODES_D: Katalog zawierający serwery z plikami definicji węzłów, którymi należy zarządzać.
Domyślnie: nodes.d.

· $CHAKE_TMPDIR: Katalog używany do przechowywania tymczasowych plików pamięci podręcznej. Domyślnie: tmp/chake.

· $CHAKE_CHEF_CONFIG: plik konfiguracyjny szefa kuchni, względem katalogu głównego repozytorium.
Domyślnie: config.rb.

Korzystaj z chake online za pomocą usług onworks.net