Jak ustrukturyzować kod i konfiguracje związane z DevOps w repozytorium kodów?

Rozwijamy się jako firma, nasze produkty się rozwijają, rosną również nasze działania i wysiłki związane z DevOps - przeszliśmy z Bamboo na bardziej elastycznego i konfigurowalnego Jenkinsa, używając potoków wdrażania i innych wtyczek; przełączyłem się na Ansible i zacząłem używać Dockera tu i tam wewnętrznie.

Wszystkie te rzeczy wymagają pewnego poziomu kodowania lub konfiguracji - skrypty i konfiguracje Ansible, groovy skrypty Jenkinsa, Dockerfiles i konfiguracje YAML.

Do tej pory stworzyliśmy osobne „ops” repozytorium z katalogami Wysoki poziom jenkins, ansible, dockeroraz other(co jest okropne imię, ale teraz wszystko jest „inne” devops automatyki są tam).

Nasze podejście nie wydaje się właściwe i może nie być skalowane, ale jakie są najlepsze praktyki i zalecenia dotyczące przechowywania kodu związanego z DevOps w repozytorium lub repozytoriach kodów?

Obecna organizacja kodu i konfiguracji, którą opisujesz, oparta jest na zastosowanych rozwiązaniach technicznych. Jest to zły projekt, który zwiększy narzut w naszych działaniach konserwacyjnych i doda wiele pułapek na nasz sposób. Zamiast tego organizacja ta powinna opierać się na artefaktach , które wdrażamy.

Powodem tego jest to, że chcemy brać pod uwagę artefakty ( np. Obraz dokera lub pakiet oprogramowania) jako obiekty następujących czasowników:

• budować
• test
• rozmieścić

rozważenie minimalnego zestawu zautomatyzowanych zadań, które chcemy wykonać. Jeśli chcemy coś zmienić w sposobie implementacji czasownika testowego, łatwo jest odwiedzić folder odpowiadający temu artefaktowi w odpowiednim repozytorium, a następnie odkryć elementy automatyzacji specyficzne dla jenkins, które należy zaktualizować. Zamiast tego, jeśli przepisy dotyczące automatyzacji opierają się na rozwiązaniach technicznych, musimy od razu zrozumieć, że Jenkins bierze udział w procedurach testowych i znaleźć tam elementy automatyzacji związane z artefaktami. W złożonych sytuacjach organizacja rozwiązań technicznych bardzo utrudnia aktualizację, ponieważ musimy z góry poznać wszystkie rozwiązania techniczne związane z niektórymi usługami, aby je odpowiednio zaktualizować.

Na przykład repozytorium zawierające kod strony internetowej i mikro-usługę „a” może mieć następujące podkatalogi poświęcone operacjom:

./ops/website
./ops/micro-service-a

z których każdy ma trzy skrypty nazywa build, testi deploy. Teraz, gdy organizacja elementów automatyzacji została w jakiś sposób wyjaśniona, zwróćmy naszą uwagę na konfigurację.

deployCzasownik określa główne warunki i wymagania dotyczące organizacji konfiguracji w przypadku zastosowania go do artefaktu podobnego do usługi. deployCzasownik powinien posiadać następujące parametry:

• wersja artefaktu do wdrożenia,
• cel wdrażania artefaktu, który opisuje konkretne środowisko, w którym uruchomiony zostanie artefakt ( np. klaster i punkty końcowe , z którymi powinien rozmawiać)
• poświadczenia, których powinien używać do łączenia się z innymi punktami końcowymi ( np. bazami danych)
• konfiguracja środowiska wykonawczego (np. jak długo powinny trwać wpisy w pamięci podręcznej itp.)

Z punktu widzenia operacyjnego ten podział parametryzacji jest zgodny z naturalnym stopniem swobody problemu wdrażania - oprócz poświadczeń, które można powiązać z konfiguracją środowiska wykonawczego, ale lepiej jest je rozdzielić, aby uniknąć niedbałego ich rozprzestrzeniania.

Mogę odpowiedzieć na temat okna dokowanego, jedną z najlepszych praktyk korzystania z okna dokowanego jest przechowywanie pliku dokowania i plików tworzenia w tym samym repozytorium projektu, więc gdziekolwiek sklonujesz projekt, możesz zbudować obraz dokera, i dobrze jest przechowuj wiele wersji plików komponujących dokera, na przykład (prod, staging, dev), abyś mógł zbudować obraz i uruchomić kontener z określoną opcją dla każdej env, na przykład dla maszyny deweloperskiej możesz użyć konkretnej sieci i uruchomić więcej kontenerów zależności lub cokolwiek innego.

Kod każdego narzędzia przechodzi do własnego repozytorium. na przykład

1. Szablon Jenkins Groovy w repozytorium Jenkins
2. Odpowiednie podręczniki YAML we własnym repozytorium (z rolami, zadaniami, podkatalogami inwentarza)
3. Szablony Cloudformation / Terrform we własnym repozytorium
4. Pliki Docker we własnym 5 .. I tak dalej

Pomoże to w lepszym skalowaniu pod względem organizacji procesów i utrzymywania różnych gałęzi dla każdego środowiska

Zapewniłoby to bardziej szczegółową kontrolę i odciąłoby wszystkie koszty związane z wersjonowaniem do systemów kontroli wersji. Utwórz także osobne gałęzie dla każdego środowiska i oznacz kod dla każdej wersji produkcyjnej (podobnie jak w przypadku podstawy kodu aplikacji). Pomyśl o infra i przetwarzaj kodowo. (Wszelkie zmiany w procesie muszą zostać skodyfikowane i wysłane do QA, SIT, UAT, a następnie do PROD) podobnie jak w aplikacji.

Na przykład możesz mieć V2.1 Ansible działający w dziale produkcyjnym (gałąź master), ale V2.0 kontenerów dokujących działający w Prod (gałąź master)

Podobnie przechowuj skrypty DB / skrypty bash we własnych repozytoriach, a być może możesz mieć skonfigurowany plik sprawdzania kondycji (JSON / YAML), aby wyświetlał wersje wszystkich narzędzi / części w każdym wdrożonym adresie URL w celu śledzenia i automatyzacji. (Aby haczyki internetowe odczytywały adres URL i automatyzowały wdrożenia)

Dokonanie rozróżnienia między Ops, Dev i DevOps promuje izolację i wymusza postawę „przerzuć ją przez mur”. Aby zwiększyć współpracę między zespołami, należy umieścić wszystko w repozytorium, które jest wymagane do zbudowania i wdrożenia projektu.

To powiedziawszy, odpowiedź na pytanie:

Jak ustrukturyzować kod i konfiguracje związane z DevOps w repozytorium kodów?

jest to, że jeśli wymagana jest konfiguracja do uruchomienia projektu, to należy go umieścić w tym samym katalogu.