Zarządzanie zmiennymi środowiskowymi/sekretami w Jenkins

Przesiadam się powoli z GitlabCI na Jenkins i mam problem z zarządzaniem sekretami/zmiennymi środowiskowymi itp. Chyba zbyt bardzo przyzwyczaiłem się do GitlabCI i szukam pewnych zastępników.

Co ważne w Gitlabie używam głównie Pipelinów - piszę to bo zauważyłem, że wiele pluginów wspiera tylko niektóre typy projektów - np. znalazłem ciekawy plugin do wstrzykiwania zmiennych środowiskowych, ale działa on tylko w projketach "free style".

Po kolei opiszę problemy i jak je rozwiązywałem w GitalbCI:

Pliki .env

W projekcie często potrzebuje pliku .env. Plik taki przechowywałem sobie jako zmienną CI (gitlab pozwala przechowywać plik tekstowy jako zmienną) i w trakcie builda kontenera kopiowałem sobie ten plik .env do kontenera. Jak poprawnie przechowywać plik .env w Jenkins? Czy takie pliki powinienem przechowywać w sekcji "credentials" i jakoś pobierać je w pipelinie czy ogarnia się to jakoś inaczje?

Zmienne środowiskowe
W projektach mamy sporo zmiennych środowiskowych, które nie są sekretami. Np. nazwa domeny pod jaką zdeployować dany projekt, ścieżka na serwerze itp. W jaki sposób takie zmienne przechowuje się w Jenkins? Na razie przechowuje je w skrypcie w sekcji environment, ale to oznacza, że każda zmiana takiej zmiennej wymaga commitu do repozytorium. Plugin environment injector zdaje się, że załatwiłby ten problem, ale nie działa z Pipelinami.

Zmienne środowiskowe zależne od środowiska

W Gitlabie można sobie zdefiniować zmienne środowiskowe i uzależnić je od "środowiska" - np. mogę sobie zdefiniować, że nazwa brancha to będzie moje środowisko, a w panelu zdefiniować, że zmienna X dla środowiska master będzie 1 a dla środowiska develop 2.
Czy da się to jakość ogarnąć takie "warunkowe" zmienne? Znów na tą chwilę ogarniam to jako funkcję w skrypcie pipelina, która zwraca odpowiednią wartość, ale ma to takie same wady jak w punkcie poprzednim.

Ogólnie sam Jenkins mi się podoba i ma wiele plusów, ale w kwestii zarządzania envami mam wrażenie, że coś mi umyka.

Dawno nie miałem do czynienia z Jenkinsem, ale chyba każde narzędzie do CI ma możliwość odpalenia skryptu, próbowałeś ustawić zmienne w ten sposób?

Możesz spróbować użyć pluginów Folders oraz Credential bindings i ustawić zmienne per folder.
Zródło.

Z czystej ciekawości co Cię skłoniło do przejścia z Gitlaba na Jenkinsa?

@tomasz3dk: dzięki za link - rzucę na to dzisiaj okiem.

Co do przejścia z Gitlab na Jenkins to dłuższa historia. Zacznijmy od tego, że devopsowe tematy to dla mnie raczej dodatek, więc wielu rzeczy nie wiem. Teraz prowadzę projekt w małej firmie produktowej, która nie ma dedykowanego devopsa (mały projekt na kilka osób, brak działu IT). Nasz projekt jest dosyć rozbudowany pod względem infrastruktury - mamy 1 główne repo z którego budowane są różne wersje projektu, na różnych serwerach. Dodatkowo przeszliśmy na trunk based development i do manualnych testów potrzebujemy mieć możliwość stawiania krótko żyjących środowisk na feature branche i późniejszego ich usuwania. Dodatkowo dochodzą dodatkowe zadania typu zrzut bazy danych z mastera danego środowiska, stripowanie śmieci typu logi, anonimizacja i wrzucenie do bucketa S3 takiego dumpa aby można sobie było pobrać i na tym developować. Ogólnie sporo takich różnych zadań odpalanych automatycznie, manualnie lub z CRON. Część zadań chciałbym aby była dzielona na userów - czyli na przykład developer nie może zrobić deployu mastera, ale może na przykład zrobić zrzut bazy developerskiej jak mu jest potrzebny.

Mam wrażenie, że dla Gitlaba to za wiele (albo nie potrafię tego skutecznie ogarnąć). Jankins wydawał mi się tutaj dobrym wyjściem, ale Jenkinsa znałem do tej pory tylko jako użytkownik. Pierwsze wrażenie jest takie, że wiele rzeczy mogę bardziej poukładać pod siebie, ale jest też sporo takich drobiazgów, które wychodzą jak wspomniane zarządzanie ENV - typu jak przechować plik .env dla danego pipelina. Teraz to robię wrzucając envy na serwer i w zmiennej środowiskowej mam ścieżkę do tego pliku, ale mam wrażenie, że to nie jest ok. Mógłby to przechowywać w credentialach, ale strasznie mnie denerwuje brak możliwości podejrzenia takiego credentiala, przez co o wiele trudniej się potem wszystko debuguje.

Ehh ogólnie ciągle mam wrażenie, że coś mi umyka w temacie organizacji. CI Gitlaba było kilka rzędów prostsze do ogarnięcia.

@piotrpo: tak jak piszesz korzystam z skryptów trzmanych w repo - coś w tym stylu jak poniżej. Trochę mi się jednak nie podoba idea trzymania zmiennych środowiskowych w samym skrypcie. Teraz jeszcze widzę, że jest opcja przygotowania środowiska i tam chyba można jakieś zmienne zdefiniować (będę to dzisiaj testował). To by trochę rozwiązało problem.

pipeline {
    agent {
        label '!windows'
    }

    environment {
        PROJECT_ID = "${params.PROJECT_ID}" // odczyt z parametru dynamicznego
        USER = 'deployer' // stała wartość zdefiniowana w skrypcie
        SERVER_IP = getServerIP("${params.PROJECT_ID}") // "dynamiczna zmienna zależna od PROJECT_ID"
        GITHUB_TOKEN = credentials('GITHUB_TOKEN') // odczyt z systemu credentiali jenkinsa
    }

    stages {
        stage('Build') {
            steps {
                echo "${SERVER_IP}"
            }
        }
    }
}

def getServerIP(projectId) {
    def s1 = ['project_1', 'project_2']
    def s2 = ['project_3']
    if (s1.contains(${projectId})) {
        return "1.1.1.1"
    } else if (s2.contains(${projectId})) {
        return "2.2.2.2"
    } else {
        throw new Exception("Unknown environment ${projectId}")
    }
}

Czyli tworzę zmienne środowiskowe na różne sposoby. Ale w ten sposób trochę skrypty mam zależne od "magic numbers" w skrypcie. Trochę chyba nie jst t

Na poziomie Jenkinsa (tutaj znowu nie pamiętam) masz możliwość definiowania sobie zmiennych dla pipeliny. W najgorszym razie możesz je przekazać do skryptu jako parametry uruchomieniowe.