Czym jest Jenkins? Serwer CI/CD, pipeline i jak zacząć

W artykule o CI/CD w praktyce pokazaliśmy pipeline w GitHub Actions i wspomnieliśmy, że to nie jedyne narzędzie. Jenkins jest jednym z najbardziej znanych, więc często pojawia się w ogłoszeniach na stanowiska DevOps (jedną z umiejętności tej roli opisujemy w artykule o DevOpsie). Ten artykuł wyjaśnia, czym jest Jenkins, jak jest zbudowany, jak wygląda pipeline w Jenkinsfile i kiedy warto go wybrać. Uwaga: nie instalowałem Jenkinsa ani nie uruchamiałem pipeline'u (na tej maszynie nie ma Dockera), więc cały opis opieram na oficjalnej dokumentacji z jenkins.io i oznaczam to w tekście.

Czym jest Jenkins?

Według własnego opisu Jenkins to „wiodący serwer automatyzacji typu open source” (the leading open source automation server). Strona określa go jako samodzielny program oparty na Javie, który może działać jako prosty serwer ciągłej integracji albo stać się centrum ciągłego dostarczania dla dowolnego projektu. Konfigurujesz go w interfejsie przeglądarkowym, a funkcje dokładasz wtyczkami, których według strony głównej jest ponad 2300, tworzonych przez społeczność.

Najważniejsza różnica względem GitHub Actions: Jenkins to serwer, który sam instalujesz i utrzymujesz, a nie usługa hostowana przez dostawcę repozytorium. Daje większą swobodę, ale odpowiedzialność za aktualizacje, bezpieczeństwo i kopie zapasowe spada na Ciebie.

Jak jest zbudowany Jenkins? Kontroler, węzły i agenci

Dokumentacja Jenkinsa opisuje architekturę tak:

Dokumentacja odradza uruchamianie zadań na wbudowanym węźle kontrolera ze względów bezpieczeństwa, wydajności i skalowalności, a liczbę executorów na nim można ustawić na 0, żeby tego zakazać. W praktyce oznacza to, że przy poważniejszym użyciu zadania uruchamiasz na osobnych agentach, a kontroler tylko nimi zarządza.

Czym jest pipeline i Jenkinsfile?

Pipeline to, według dokumentacji Jenkinsa, zdefiniowany przez użytkownika model procesu ciągłego dostarczania. Opisujesz go w pliku tekstowym zwanym Jenkinsfile, który możesz zapisać w repozytorium razem z kodem. Dzięki temu pipeline jest wersjonowany i przeglądany jak każdy inny kod (podejście pipeline as code). Dokumentacja wyróżnia dwie składnie:

Na start wybierz składnię deklaratywną. Poniżej szkielet z dokumentacji (komentarze // ... oznaczają kroki, które na stronie są pominięte):

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                // ...
            }
        }
        stage('Test') {
            steps {
                // ...
            }
        }
        stage('Deploy') {
            steps {
                // ...
            }
        }
    }
}

Co znaczą elementy według dokumentacji:

• agent każe Jenkinsowi przydzielić executor (na węźle) i przestrzeń roboczą dla całego pipeline'u.
• stages grupuje etapy, a każdy stage to „pojęciowo odrębny podzbiór zadań” wykonywanych w pipeline.
• steps opisuje kroki uruchamiane w danym etapie.

Szkielet ma te same trzy etapy co pipeline z naszego artykułu o CI/CD: budowanie, testy i wdrożenie. Samych kroków do wpisania w steps (np. uruchomienia testów) nie sprawdzałem, więc ich składnię znajdziesz w dokumentacji Jenkins Pipeline. Nie opisuję tu też sekcji post, bo nie było jej w pobranej dokumentacji.

Jak zainstalować Jenkinsa?

Dokumentacja wymienia kilka sposobów instalacji: Docker, Kubernetes, pakiety dla Linuxa, macOS, Windows oraz plik WAR (a także inne kontenery serwletów i instalacje offline). Najwygodniej na start użyć Dockera. Oficjalny obraz to jenkins/jenkins, a tag LTS wygląda tak: jenkins/jenkins:lts-jdk21. Z fragmentów dokumentacji (port 8080 i wolumen na dane) składa się polecenie typu:

# złożone z fragmentów dokumentacji, nie uruchamiałem (brak Dockera)
docker run --publish 8080:8080 \
  --volume jenkins-data:/var/jenkins_home \
  jenkins/jenkins:lts-jdk21

Dokumentacja podaje, że główne polecenie w jej przewodniku używa własnego obrazu zbudowanego na bazie jenkins/jenkins, więc zajrzyj do aktualnego przewodnika Docker na jenkins.io, zanim uruchomisz to na serwerze. Wolumen jenkins-data utrzymuje dane Jenkinsa poza kontenerem, a to, co w nim leży, trzeba objąć kopią zapasową (zobacz artykuł o kopiach zapasowych na serwerze).

Po pierwszym uruchomieniu kreator przeprowadza Cię przez kilka kroków: odblokowanie Jenkinsa, wybór wtyczek (opcja „Install suggested plugins” to zalecany zestaw dla najczęstszych przypadków) i utworzenie pierwszego administratora. Początkowe hasło administratora znajdziesz w logu konsoli albo w kontenerze poleceniem cat /var/jenkins_home/secrets/initialAdminPassword uruchomionym przez docker exec.

Wymagania. Według dokumentacji minimum to 256 MB RAM i 1 GB dysku (dla Dockera zalecane minimum to 10 GB dysku), a dla małego zespołu zalecane jest 4 GB lub więcej RAM i 50 GB lub więcej dysku. Dokumentacja wspomina o wersji Javy „obsługiwanej przez Jenkinsa” bez podawania numeru, a obraz LTS zawiera już Javę. Jeśli myślisz o własnym serwerze, zobacz artykuł o serwerze VPS, a o podstawach pracy w konsoli Linuxa.

LTS czy weekly? Jenkins ma dwie linie wydań. Według dokumentacji baza LTS jest wybierana co 12 tygodni z linii tygodniowych, a co 4 tygodnie wychodzi nowe wydanie LTS z poprawkami błędów i bezpieczeństwa. Linia weekly szybko dostarcza poprawki i nowe funkcje. Do własnego serwera, na którym coś zależy, zwykle wybiera się LTS.

Do czego służą wtyczki i dlaczego są ryzykiem?

Wtyczki rozszerzają Jenkinsa o integracje z narzędziami do budowania, testów i wdrożeń. Jest ich ponad 2300, a wiele funkcji, które w innych narzędziach są wbudowane, w Jenkinsie dodajesz wtyczkami. To daje elastyczność, ale też zwiększa powierzchnię ataku: Jenkins publikuje ostrzeżenia bezpieczeństwa (security advisories) o podatnościach zarówno w samym Jenkinsie, jak i we wtyczkach. Dlatego instaluj tylko potrzebne wtyczki i regularnie je aktualizuj. Nie wymieniam konkretnych wtyczek, bo ich nie sprawdzałem.

Jak Jenkins obchodzi się z hasłami i kluczami?

Pipeline'y często potrzebują dostępu do repozytoriów, serwerów lub chmury, więc Jenkins ma mechanizm poświadczeń (credentials). Według dokumentacji obsługuje m.in. tekst tajny (np. token API albo token GitHub), login i hasło oraz klucz SSH z kluczem prywatnym (z opcjonalną frazą). Poświadczenia są przechowywane w postaci zaszyfrowanej na kontrolerze, a w pipeline'ach używa się ich wyłącznie przez identyfikator (ID), którego po ustawieniu nie można zmienić. Zasada jest taka sama jak w GitHub Actions: nie wpisuj haseł ani kluczy w Jenkinsfile ani do repozytorium. Składni użycia poświadczeń w Jenkinsfile nie podaję, bo nie było jej w pobranej dokumentacji (strona odsyła do osobnej sekcji). O kluczach SSH i bezpiecznym logowaniu piszemy w artykule o SSH.

Uwaga mentora: Jenkins to serwer, który sam musisz utrzymywać: aktualizować, zabezpieczać i robić z niego kopie. Zanim go postawisz, sprawdź, czy GitHub Actions lub GitLab CI nie zrobią tego samego bez dodatkowego serwera.

Jenkins czy GitHub Actions i GitLab CI?

Informacje o GitHub Actions i GitLab pochodzą z dokumentacji opisanej w artykule o CI/CD, a o samym GitLabie piszemy w tekście czym jest GitLab i kiedy jest lepszy od GitHuba. Poniższa tabela to moje uproszczenie, a nie reguła:

Jak zabezpieczyć i utrzymać Jenkinsa?

Skoro sam utrzymujesz serwer, kilka zasad ma szczególne znaczenie:

• Aktualizuj Jenkinsa i wtyczki. Według jenkins.io administratorzy z podatnymi wersjami są informowani w interfejsie, a ostrzeżenia trafiają też przez e-mail i RSS.
• Nie uruchamiaj zadań na wbudowanym węźle (dokumentacja odradza to ze względów bezpieczeństwa).
• Trzymaj hasła i klucze w poświadczeniach, a nie w kodzie.
• Zabezpiecz sam serwer: W przykładzie z dokumentacji panel Jenkinsa jest publikowany na porcie 8080 (--publish 8080:8080), więc nie zostawiaj go otwartego dla całego internetu bez potrzeby. Rozważ zaporę i ograniczenie dostępu (zobacz artykuł o firewallu na serwerze Linux).
• Rób kopie danych Jenkinsa i sprawdzaj odtwarzanie.

Jakie błędy popełniają początkujący przy Jenkinsie?

Pierwszy wiersz i hasło administratora pochodzą wprost z dokumentacji. Wolumen i zalecenie o wtyczkach to praktyka wynikająca z tej dokumentacji i z jej ostrzeżeń o bezpieczeństwie.

Jak sprawdzić Jenkinsa w praktyce? Ćwiczenie na 30 minut

To moja propozycja ćwiczenia, a nie oficjalny kurs. Zrób je na komputerze lub tymczasowym serwerze, nie na produkcji:

1. Uruchom Jenkinsa w Dockerze poleceniem z sekcji o instalacji (albo według aktualnego przewodnika na jenkins.io) i otwórz panel na porcie 8080.
2. Odczytaj początkowe hasło administratora z pliku secrets/initialAdminPassword w kontenerze i przejdź kreator: odblokowanie, „Install suggested plugins”, pierwszy administrator.
3. Utwórz pierwszy pipeline i wklej szkielet Declarative z dokumentacji, wpisując w steps proste kroki, np. wypisanie komunikatu.
4. Uruchom pipeline i obejrzyj wynik oraz logi każdego etapu.
5. Zepsuj jeden krok celowo, uruchom ponownie i zobacz nieudany wynik, a potem go napraw.
6. Zatrzymaj kontener i uruchom go ponownie z tym samym wolumenem, żeby sprawdzić, czy konfiguracja i historia zostały.
7. Usuń kontener i wolumen, jeśli ćwiczysz tylko do nauki.

Od czego zacząć z Jenkinsem?

1. Najpierw zrozum CI/CD na prostszym narzędziu, np. GitHub Actions (artykuł o CI/CD w praktyce).
2. Uruchom Jenkinsa w Dockerze i przejdź kreator początkowy.
3. Utwórz pierwszy pipeline ze szkieletu Declarative z dokumentacji i dopisz kroki.
4. Dodaj agenta i wyłącz zadania na kontrolerze.
5. Zadbaj o aktualizacje, kopie i dostęp zanim użyjesz go do czegoś ważnego.

Cały proces wdrożenia aplikacji na prawdziwym serwerze ćwiczysz w module wdrożenie produkcyjne w chmurze w kursie AI Engineer.

Podsumowanie

• Jenkins to otwarty serwer automatyzacji, który uruchamia pipeline'y CI/CD, a pipeline opisujesz w Jenkinsfile w repozytorium.
• Architektura: kontroler zarządza, agenci wykonują zadania na węzłach w executorach. Zadań nie uruchamia się na wbudowanym węźle kontrolera.
• Wtyczki (ponad 2300) dają elastyczność, ale zwiększają ryzyko i wymagają aktualizacji.
• Instalacja najłatwiej w Dockerze (obraz jenkins/jenkins, port 8080), a minimalne wymagania to 256 MB RAM i 1 GB dysku (dla małego zespołu 4 GB+ RAM).
• Jenkins vs GitHub Actions: Jenkins utrzymujesz sam, a w GitHub Actions serwerem zajmuje się dostawca.
• Nie instalowałem Jenkinsa i nie uruchamiałem pipeline'u, więc całość opiera się na oficjalnej dokumentacji.