To jest bardzo szerokie pytanie dotyczące metod i porad dotyczących zmiennych / struktury środowiska. Ale ostatecznie szukam odpowiedzi na bardzo szczegółowe pytanie „Jak przechowywać moje zmienne środowiskowe?”
Po pierwsze kilka wyjaśnień:
- Dla mnie środowisko może mieć od 3 do 10 serwerów i jest sposobem na ograniczenie infrastruktury konkretnego klienta.
- W każdym środowisku znajduje się kilka zmiennych, które są w większości automatycznie generowane na podstawie kilku kluczowych danych wejściowych (nazwa, rozmiar itp.).
Na obecnym etapie przechowujemy wszystkie nasze zmienne środowiskowe w takiej strukturze:
<playbook>.yml # Various playbooks for deployment
roles/windows # Ansible role for Ubuntu
roles/ubuntu # Ansible role for Ubuntu
config/hosts/<name>.yml # Ansible inventory
config/hosts/vars/<name>.json # Environment specific variables
W tej chwili konfiguracja jest inicjowana jako submoduł w powyższym repozytorium git. Ponieważ plik zmiennych zmienia się dość często, spowodowało to problemy ze zmianą danych, raz, dwa lub nawet trzy razy między zatwierdzeniami, przez co zmiany są coraz trudniejsze do śledzenia.
Ponieważ osobiście widzę to w przyszłości, powinniśmy starać się przechowywać wszystkie zmienne naszych klientów w scentralizowany / skalowalny sposób, a następnie połączyć się z nimi za pomocą dynamicznej inwentaryzacji z ansible .
Rozumiem, że istnieje kilka technologii, które wydają się wykonywać część tego, co może być wymagane, takie jak Consul, ale wydają się one działać najlepiej w środowisku obsługującym jedną dużą aplikację, a nie wiele mniejszych, nieco różniących się.
Zasadniczo widzę, że musimy napisać skrypt inwentaryzacyjny, a następnie po prostu wepchnąć wszystkie nasze dane do jakiejś nieprzeznaczonej do tego bazy danych, a następnie kontynuować, jak gdyby nic się nie zmieniło. Widzę to jako sposób na potencjalne ograniczenie dużej ilości danych, które obecnie przechowujemy, i być może przyglądam się różnym sposobom przechowywania danych, a nie tylko skalowaniu tego, co je ponownie obsługuje.
Mam nadzieję, że ktoś ma jakieś doświadczenie we wdrażaniu infrastruktury jako kodu, gdy ma do czynienia z wieloma mniejszymi środowiskami w przeciwieństwie do jednego, dwóch lub trzech dużych.
Jakieś sugestie?
Jeśli twoje środowiska dotyczą jednego klienta, sugerowałbym w twoim konkretnym przypadku utworzenie repozytorium dla każdego klienta . (Ogólnie rzecz biorąc, jest to repozytorium według środowiska.) To repozytorium miałoby standardową strukturę katalogów dla zmiennych środowiskowych, zmiennych ansible i inwentarzy, silnie zaszyfrowanych tajemnic (tokeny dostępu do konta, klucze prywatne itp.). Dostarczyłbyś kod podrzędny do tych repozytoriów. Prawdopodobnie zrobiłbym to w wielu repozytoriach. Jeden dla odpowiedzialnych ról i modułów, jeden dla skryptów konserwacji i wdrażania, jeden dla każdej głównej aplikacji działającej w środowisku.
Teraz możesz opcjonalnie rozwidlić kod lub w inny sposób przypiąć podmoduł do określonego znacznika do wydania , upewniając się, że kod zarządzający środowiskiem klienta nie zmieni się, chyba że zostanie przetestowany i wydany.
Jeśli używasz repozytorium artefaktów , upewnij się, że artefakty są odpowiednio wersjonowane, a wersje te są poprawnie określone w zmiennych środowiskowych.
Automatyzacja jest ważna, ponieważ zmienne środowiskowe nie powinny być aktualizowane przez ludzi, jeśli to możliwe, ale generowane przez skrypty. Upewnij się, że prawie nie ma ręcznych aktualizacji w spisie dla poszczególnych klientów, a programiści aktualizują tylko repozytoria kodów. Jeśli chcą zmienić konfigurację, należy to zrobić w jednym ze skryptów generujących, który jest następnie uruchamiany w celu wygenerowania zmiennych, a różnicę zapisuje się w repozytorium klienta. Opłaca się ustawić ciągłą integrację tego procesu. Bez tego w pewnym momencie będzie zbyt wiele repozytoriów do utrzymania .
źródło