Wszystko zaczęło się, gdy kierownik jednego z naszych zespołów programistycznych poprosił nas o przetestowanie ich nowej aplikacji, która została skonteneryzowana dzień wcześniej. Opublikowałem to. Po około 20 minutach otrzymano prośbę o aktualizację aplikacji, ponieważ została tam dodana bardzo potrzebna rzecz. odnowiłem. Po kolejnych kilku godzinach... cóż, można się domyślić, co zaczęło się dalej dziać...
Muszę przyznać, że jestem dość leniwy (czy nie przyznałem się do tego wcześniej? Nie?), a biorąc pod uwagę fakt, że liderzy zespołów mają dostęp do Jenkinsa, w którym wszyscy mamy CI/CD, pomyślałem: pozwólmy mu wdrożyć się jako tyle, ile chce! Przypomniał mi się dowcip: daj człowiekowi rybę, a będzie jadł przez jeden dzień; zadzwoń do osoby Fed, a będzie ona karmiona przez całe życie. I poszedł płatać figle w pracy, który byłby w stanie wdrożyć do Kubera kontener zawierający aplikację dowolnej pomyślnie zbudowanej wersji i przenieść do niego dowolne wartości ENV (mój dziadek, filolog, w przeszłości nauczyciel języka angielskiego, teraz po przeczytaniu tego zdania kręcił palcem na skroni i patrzył na mnie bardzo wyraziście).
W tej notatce opowiem Ci, jak się nauczyłem:
- Dynamicznie aktualizuj zadania w Jenkins z samego zadania lub z innych zadań;
- Połącz się z konsolą chmurową (Cloud Shell) z węzła z zainstalowanym agentem Jenkins;
- Wdróż zadanie w Google Kubernetes Engine.
Prawdę mówiąc, jestem oczywiście nieco nieszczery. Zakłada się, że przynajmniej część infrastruktury znajduje się w chmurze Google, a co za tym idzie, jesteś jej użytkownikiem i oczywiście posiadasz konto GCP. Ale nie o tym jest ta notatka.
To moja kolejna ściągawka. Chcę napisać taką notatkę tylko w jednym przypadku: napotkałem problem, początkowo nie wiedziałem, jak go rozwiązać, rozwiązanie nie było gotowe w Google, więc googlowałem w częściach i ostatecznie rozwiązałem problem. Żeby w przyszłości, gdy zapomnę jak to zrobiłem, nie musiałem wszystkiego ponownie wyszukiwać w Google kawałek po kawałku i składać w całość, sam piszę takie ściągawki.
Zrzeczenie się: 1. Notatka pisana „dla siebie”, dla roli najlepsze praktyki nie dotyczy. Miło mi przeczytać w komentarzach opcję „lepiej byłoby to zrobić w ten sposób”.
2. Jeśli zastosowaną część nuty uważa się za sól, to podobnie jak wszystkie moje poprzednie notatki, ta jest słabym roztworem soli.
Dynamiczne aktualizowanie ustawień zadań w Jenkins
Domyślam się Twojego pytania: co ma z tym wspólnego dynamiczna aktualizacja ofert pracy? Wprowadź ręcznie wartość parametru string i gotowe!
Odpowiadam: jestem bardzo leniwy, nie lubię, gdy narzekają: Misza, wdrożenie się zawiesza, wszystko zniknęło! Zaczynasz szukać i pojawia się literówka w wartości jakiegoś parametru uruchamiania zadania. Dlatego wolę robić wszystko tak efektywnie, jak to możliwe. Jeśli można uniemożliwić użytkownikowi bezpośrednie wprowadzanie danych, podając zamiast tego listę wartości do wyboru, to organizuję selekcję.
Plan jest taki: tworzymy w Jenkinsie zadanie, w którym przed uruchomieniem moglibyśmy wybrać wersję z listy, określić wartości parametrów przekazywanych do kontenera poprzez ENV, następnie zbiera kontener i wypycha go do rejestru kontenerów. Następnie stamtąd kontener jest uruchamiany w kostce as obciążenie pracą z parametrami określonymi w zadaniu.
Nie będziemy rozważać procesu tworzenia i zakładania pracy w Jenkins, to nie na temat. Zakładamy, że zadanie jest gotowe. Aby zaimplementować zaktualizowaną listę z wersjami, potrzebujemy dwóch rzeczy: istniejącej listy źródłowej z a priori prawidłowymi numerami wersji i zmiennej takiej jak Parametr wyboru w zadaniu. W naszym przykładzie niech zmienna zostanie nazwana WERSJA_BUDOWY, nie będziemy się nad tym szczegółowo rozwodzić. Przyjrzyjmy się jednak bliżej liście źródeł.
Nie ma zbyt wielu opcji. Od razu przyszły mi na myśl dwie rzeczy:
- Użyj interfejsu API dostępu zdalnego, który Jenkins oferuje swoim użytkownikom;
- Zapytaj o zawartość folderu zdalnego repozytorium (w naszym przypadku jest to JFrog Artifactory, co nie jest ważne).
Jenkins API dostępu zdalnego
Zgodnie z ugruntowaną, doskonałą tradycją wolałbym uniknąć długich wyjaśnień.
Pozwolę sobie jedynie na swobodne przetłumaczenie fragmentu pierwszego akapitu :
Jenkins zapewnia interfejs API umożliwiający zdalny dostęp do jego funkcjonalności w trybie odczytu maszynowego. <…> Zdalny dostęp oferowany jest w stylu REST. Oznacza to, że nie ma jednego punktu wejścia do wszystkich funkcji, ale zamiast tego jest adres URL taki jak „.../api/", Gdzie "..." oznacza obiekt, do którego stosowane są możliwości API.
Innymi słowy, jeśli zadanie wdrożenia, o którym aktualnie mówimy, jest dostępne pod adresem http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, wówczas gwizdki API do tego zadania są dostępne pod adresem http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Następnie mamy wybór, w jakiej formie otrzymać wynik. Skupmy się na XML-u, gdyż API w tym przypadku pozwala jedynie na filtrowanie.
Spróbujmy uzyskać listę wszystkich uruchomień zadań. Interesuje nas tylko nazwa zestawu (wyświetlana nazwa) i jego wynik (dalsze):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Czy to działa?
Teraz przefiltrujmy tylko te przebiegi, które zakończyły się wynikiem POWODZENIE. Użyjmy argumentu &wykluczać i jako parametr przekażemy mu ścieżkę do wartości nierównej POWODZENIE. Tak tak. Podwójne przeczenie jest stwierdzeniem. Wykluczamy wszystko, co nas nie interesuje:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Zrzut ekranu przedstawiający listę udanych
No cóż, dla zabawy sprawdźmy, czy filtr nas nie oszukał (filtry nigdy nie kłamią!) i wyświetlmy listę „nieudanych”:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Zrzut ekranu przedstawiający listę nieudanych
Lista wersji z folderu na serwerze zdalnym
Istnieje drugi sposób uzyskania listy wersji. Podoba mi się to nawet bardziej niż dostęp do API Jenkinsa. Ano dlatego, że jeśli aplikacja została zbudowana pomyślnie, to znaczy, że została spakowana i umieszczona w repozytorium w odpowiednim folderze. Podobnie repozytorium jest domyślnym miejscem przechowywania działających wersji aplikacji. Tak jak. Cóż, zapytajmy go, jakie wersje są w magazynie. Zwijamy, grepujemy i awk zdalny folder. Jeśli kogoś interesuje oneliner, to jest on pod spoilerem.
Polecenie w jednej linii
Proszę zwrócić uwagę na dwie rzeczy: w nagłówku podaję szczegóły połączenia i nie potrzebuję wszystkich wersji z folderu, a wybieram tylko te, które powstały w ciągu miesiąca. Edytuj polecenie, aby dopasować je do swoich realiów i potrzeb:
curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )Konfigurowanie zadań i pliku konfiguracyjnego zadań w Jenkins
Ustaliliśmy źródło listy wersji. Włączmy teraz powstałą listę do zadania. Dla mnie oczywistym rozwiązaniem było dodanie kroku w zadaniu budowania aplikacji. Krok, który zostałby wykonany, gdyby wynikiem był „sukces”.
Otwórz ustawienia zadania montażu i przewiń na sam dół. Kliknij przyciski: Dodaj krok kompilacji -> Krok warunkowy (pojedynczy). W ustawieniach kroku wybierz warunek Aktualny stan kompilacji, ustaw wartość POWODZENIE, akcja, która ma zostać wykonana, jeśli się powiedzie Uruchom polecenie powłoki.
A teraz zabawna część. Jenkins przechowuje konfiguracje zadań w plikach. W formacie XML. Po drodze http://путь-до-задания/config.xml W związku z tym możesz pobrać plik konfiguracyjny, w razie potrzeby dokonać jego edycji i umieścić go tam, gdzie go otrzymałeś.
Pamiętaj, że ustaliliśmy powyżej, że utworzymy parametr dla listy wersji WERSJA_BUDOWY?
Pobierzmy plik konfiguracyjny i zajrzyjmy do jego wnętrza. Tylko po to, aby upewnić się, że parametr jest na miejscu i żądanego typu.
Zrzut ekranu pod spoilerem.
Twój fragment config.xml powinien wyglądać tak samo. Tyle że brakuje jeszcze zawartości elementu Choose
Jesteś pewny? To wszystko, napiszmy skrypt, który zostanie wykonany, jeśli kompilacja się powiedzie.
Skrypt otrzyma listę wersji, pobierze plik konfiguracyjny, zapisze w nim listę wersji w potrzebnym nam miejscu, a następnie umieści ją z powrotem. Tak. Zgadza się. Napisz listę wersji w formacie XML w miejscu, gdzie już znajduje się lista wersji (będzie w przyszłości, po pierwszym uruchomieniu skryptu). Wiem, że na świecie wciąż są zagorzali fani wyrażeń regularnych. Nie należę do nich. Proszę zainstalować do komputera, na którym konfiguracja będzie edytowana. Wydaje mi się, że nie jest to zbyt duża cena za uniknięcie edycji XML za pomocą sed.
Pod spoilerem przedstawiam kod wykonujący w całości powyższą sekwencję.
Zapisz listę wersji z folderu na serwerze zdalnym do pliku config
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlJeśli wolisz opcję pobrania wersji od Jenkinsa i jesteś tak samo leniwy jak ja, to pod spoilerem znajduje się ten sam kod, ale lista od Jenkinsa:
Zapisz listę wersji z Jenkinsa do pliku config
Pamiętaj tylko o tym: nazwa mojego zestawu składa się z numeru kolejnego i numeru wersji oddzielonych dwukropkiem. Odpowiednio, awk odcina niepotrzebną część. Dla siebie zmień tę linię, aby dopasować ją do swoich potrzeb.
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml
############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlTeoretycznie, jeśli przetestowałeś kod napisany na podstawie powyższych przykładów, to w zadaniu wdrożeniowym powinieneś już mieć rozwijaną listę z wersjami. To tak jak na zrzucie ekranu pod spoilerem.
Poprawnie wypełniona lista wersji
Jeśli wszystko zadziałało, skopiuj i wklej skrypt do Uruchom polecenie powłoki i zapisz zmiany.
Łączenie z powłoką Cloud
Posiadamy kolektory w kontenerach. Używamy Ansible jako naszego narzędzia do dostarczania aplikacji i menedżera konfiguracji. W związku z tym, jeśli chodzi o budowanie kontenerów, przychodzą mi na myśl trzy opcje: zainstaluj Docker w Dockerze, zainstaluj Docker na maszynie z uruchomionym Ansible lub zbuduj kontenery w konsoli w chmurze. Zgodziliśmy się milczeć na temat wtyczek dla Jenkinsa w tym artykule. Pamiętać?
Zdecydowałem: cóż, skoro kontenery „od razu po wyjęciu z pudełka” można zbierać w konsoli chmurowej, to po co zawracać sobie głowę? Utrzymuj czystość, prawda? Chcę zebrać kontenery Jenkinsa w konsoli chmurowej, a następnie uruchomić je stamtąd w kostce. Co więcej, Google posiada w swojej infrastrukturze bardzo bogate kanały, co korzystnie wpłynie na szybkość wdrożenia.
Aby połączyć się z konsolą chmurową, potrzebujesz dwóch rzeczy: gcloud i prawa dostępu do Google Cloud API dla instancji maszyny wirtualnej, z którą zostanie nawiązane to samo połączenie.
Dla tych, którzy planują łączyć się wcale nie z chmury Google
Google dopuszcza możliwość wyłączenia interaktywnej autoryzacji w swoich usługach. Umożliwi to połączenie się z konsolą nawet z ekspresu do kawy, jeśli działa na nim *nix i ma samą konsolę.
Jeśli zajdzie potrzeba bliższego omówienia tej kwestii w ramach tej noty, proszę pisać w komentarzach. Jeśli zdobędziemy wystarczającą liczbę głosów, napiszę aktualizację na ten temat.
Najłatwiejszym sposobem przyznania praw jest interfejs internetowy.
- Zatrzymaj instancję maszyny wirtualnej, z której później połączysz się z konsolą chmurową.
- Otwórz Szczegóły instancji i kliknij zmianę.
- Na samym dole strony wybierz zakres dostępu do instancji Pełny dostęp do wszystkich interfejsów Cloud API.
Zrzut ekranu
- Zapisz zmiany i uruchom instancję.
Po zakończeniu ładowania maszyny wirtualnej połącz się z nią przez SSH i upewnij się, że połączenie nastąpi bez błędu. Użyj polecenia:
gcloud alpha cloud-shell ssh Pomyślne połączenie wygląda mniej więcej tak
Wdróż w GKE
Ponieważ na wszystkie możliwe sposoby staramy się całkowicie przejść na IaC (Infrastruktura jako kod), nasze pliki dokerów są przechowywane w Git. To jest z jednej strony. A wdrożenie w kubernetes jest opisane przez plik yaml, który jest używany tylko przez to zadanie, które samo w sobie jest również jak kod. To jest z drugiej strony. Ogólnie mam na myśli plan jest taki:
- Przyjmujemy wartości zmiennych WERSJA_BUDOWY i opcjonalnie wartości zmiennych, które będą przekazywane ENV.
- Pobierz plik dockerfile z Git.
- Wygeneruj yaml do wdrożenia.
- Przesyłamy oba te pliki przez scp do konsoli w chmurze.
- Budujemy tam kontener i wrzucamy go do rejestru kontenerów
- Stosujemy plik wdrażania obciążenia do modułu Cuber.
Bądźmy bardziej konkretni. Kiedyś zaczęliśmy rozmawiać ENV, to załóżmy, że musimy przekazać wartości dwóch parametrów: PARAM1 и PARAM2. Dodajemy ich zadanie do wdrożenia, wpisujemy - Parametr ciągu.
Zrzut ekranu
Wygenerujemy yaml za pomocą prostego przekierowania przegapić do pliku. Zakłada się oczywiście, że masz plik dockerfile PARAM1 и PARAM2jaka będzie nazwa obciążenia niesamowita aplikacja, a w nim znajduje się zmontowany kontener z zastosowaniem określonej wersji Rejestr kontenerów po drodze gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONGdzie $BUILD_VERSION został właśnie wybrany z listy rozwijanej.
Lista drużyn
touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo " name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo " replicas: 1" >> deploy.yaml
echo " selector:" >> deploy.yaml
echo " matchLabels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " template:" >> deploy.yaml
echo " metadata:" >> deploy.yaml
echo " labels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " spec:" >> deploy.yaml
echo " containers:" >> deploy.yaml
echo " - name: awesomeapp" >> deploy.yaml
echo " image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo " env:" >> deploy.yaml
echo " - name: PARAM1" >> deploy.yaml
echo " value: $PARAM1" >> deploy.yaml
echo " - name: PARAM2" >> deploy.yaml
echo " value: $PARAM2" >> deploy.yamlAgent Jenkins po podłączeniu za pomocą gcloud alfa chmura-shell ssh tryb interaktywny nie jest dostępny, dlatego wysyłamy polecenia do konsoli chmurowej za pomocą parametru --Komenda.
Czyścimy folder domowy w konsoli chmurowej ze starego pliku dockerfile:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Umieść świeżo pobrany plik docker w folderze domowym konsoli chmurowej za pomocą scp:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Zbieramy, tagujemy i wypychamy kontener do rejestru kontenerów:
gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
To samo robimy z plikiem wdrożenia. Należy pamiętać, że poniższe polecenia używają fikcyjnych nazw klastra, w którym następuje wdrożenie (klaster awsm) i nazwę projektu (niesamowity projekt), w którym znajduje się klaster.
gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project &&
kubectl apply -f deploy.yaml"Uruchamiamy zadanie, otwieramy wyjście konsoli i mamy nadzieję na pomyślny montaż kontenera.
Zrzut ekranu
A potem pomyślne rozmieszczenie zmontowanego kontenera
Zrzut ekranu
Celowo zignorowałem to ustawienie Ingres. Z jednego prostego powodu: po skonfigurowaniu obciążenie pracą o podanej nazwie, będzie działać bez względu na to, ile wdrożeń o tej nazwie wykonasz. Cóż, ogólnie rzecz biorąc, jest to trochę poza zakresem historii.
Zamiast wniosków
Wszystkie powyższe kroki prawdopodobnie nie mogły zostać wykonane, ale po prostu zainstalowano wtyczkę dla Jenkinsa, ich muuulion. Ale z jakiegoś powodu nie lubię wtyczek. Cóż, dokładniej, uciekam się do nich tylko z desperacji.
A ja po prostu lubię podjąć jakiś nowy dla mnie temat. Powyższy tekst jest także sposobem na podzielenie się wnioskami, które poczyniłem rozwiązując opisany na samym początku problem. Podziel się z tymi, którzy tak jak on wcale nie są strasznym wilkiem w devopsach. Jeśli moje odkrycia choć komuś pomogą, będę szczęśliwy.
Źródło: www.habr.com