Jenkins-CI-CD

BÖLÜM-1

İÇİNDEKİLER:

1. Jenkins Kurulumu

2. Java Kurulumu

3. Jenkins Servisini Yönetme

4. Nginx Kurulumu ve Yapılandırması (Reverse Proxy)

5. Self-Signed Sertifika Oluşturma (HTTPS için)

6. Nginx Yapılandırmasını HTTPS için Güncelleme

7. Jenkins’e Erişme

8. Ek Bilgiler; Plugin, Folder, Artifact, Workspace

1. Jenkins Kurulumu

apt-cache show jenkins

Bu komut, Jenkins paketi hakkında bilgi verir (versiyon, bağımlılıklar, açıklama vb.). Kuruluma başlamadan önce Jenkins hakkında bilgi edinmek için faydalıdır.

sudo wget -O /usr/share/keyrings/jenkins-keyring.asc https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key

echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/" | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null

Bu adımlar, Jenkins’in resmi paket deposunu sisteminize ekler. Bu sayede, Jenkins’i apt paket yöneticisi ile kurabileceksiniz.

sudo apt-get update

Bu komut, sistemdeki paket listesini günceller. Yeni eklenen Jenkins deposunun da listeye dahil olmasını sağlar.

sudo apt-get install jenkins

Bu komut, Jenkins’i kurar. Kurulum sırasında bağımlılıklar da otomatik olarak kurulacaktır.

2. Java Kurulumu

Jenkins Java ile çalıştığı için, sisteminizde Java’nın kurulu olması gerekir.

sudo apt update

Paket listesini tekrar güncellemek her zaman iyi bir uygulamadır.

3. Jenkins Servisini Yönetme

4. Nginx Kurulumu ve Yapılandırması (Reverse Proxy)

Nginx’i bir reverse proxy olarak kullanmak, Jenkins’e güvenli ve kolay bir şekilde erişmenizi sağlar.

5. Self-Signed Sertifika Oluşturma (HTTPS için)

Bu adım, Jenkins’e HTTPS üzerinden erişmek için gereklidir. Self-signed sertifika, ücretsiz bir seçenektir. Let’s Encrypt gibi bir sertifika otoriteside kullanılabilir.

6. Nginx Yapılandırmasını HTTPS için Güncelleme

7. Jenkins’e Erişme

Tarayıcınızda https://example.com (veya sunucu IP adresiniz) adresine giderek Jenkins’e erişebilirsiniz. Tarayıcınız, self-signed sertifika nedeniyle bir uyarı gösterebilir. Bu uyarıyı kabul ederek devam edebilirsiniz.

8. JENKINS

BÖLÜM-2

İÇİNDEKİLER:

1. Master-Slave Bağlantısı Kurulumu

2. Manuel Build Alma

3. Cron ile Build Alma

4. Trigger ile Build Alma

5. Jenkins User Yönetimi ve Parametrik Job’lar

Master-Slave Bağlantısı Kurulumu

Bu adım, Jenkins’in iş yükünü dağıtmak için ikinci bir sanal makine (Slave) oluşturulmasını ve Master makine ile bağlantısının yapılandırılmasını içerir.

Adımlar:

  1. İkinci Sanal Makine Kurulumu: Yeni bir sanal makine oluşturun (Slave).
  2. Şifresiz SSH Bağlantısı: Master makineden Slave makineye şifresiz SSH bağlantısı kurun.

    • SSH Anahtarı Oluşturma (Master):

        ssh-keygen -t rsa -b 4096 -C "jenkins server ssh keys" -f jenkins_id_rsa

      Bu komut, Master makinede jenkins_id_rsa  ve jenkins_id_rsa.pub dosyalarını oluşturur.

    • Private Key’i Jenkins’e Ekleme: Oluşturulan jenkins_id_rsa dosyasının içeriğini Jenkins’in Credentials bölümüne ekleyin. Bu, Jenkins’in SSH bağlantısını yönetmesini sağlar.
    • Public Key’i Slave’e Ekleme:
      • Slave makinede root kullanıcısına geçin: sudo su - (veya ilgili kullanıcı).
      • .ssh dizini yoksa oluşturun: mkdir -p ~/.ssh
      • authorized_keys dosyası oluşturun veya varsa düzenleyin: nano ~/.ssh/authorized_keys
      • Master makinede oluşturulan jenkins_id_rsa.pub dosyasının içeriğini bu dosyaya yapıştırın.
      • Dosyanın doğru izinlere sahip olduğundan emin olun: chmod 600 ~/.ssh/authorized_keys ve chmod 700 ~/.ssh

    • SSH Bağlantısını Test Etme:

        ssh -i ./jenkins_id_rsa root@<slave_ip>

      Eğer bağlantı sırasında fingerprint doğrulaması yapılıyorsa kabul edin.

  3. SSH Agent Plugin Kurulumu: Jenkins’in Slave makineye erişmesi için SSH Agent Plugin‘ini kurun.

  4. Jenkins Job’u Oluşturma ve Test Etme: Jenkins üzerinden yeni bir Job oluşturun ve Slave makinede çalıştığını doğrulamak için aşağıdaki komutlardan birini çalıştırın:

     ip -a
 ifconfig
 cat /etc/hostname

1. Manuel Build Alma

1.Jenkins Job’unu Oluşturun: 

image

2.SSH Agent’ı Yapılandırın:

3.Build Adımları Ekleyin:

4.Backup Script’i Oluşturma (Slave)

Bu adım, Slave makinesinde çalışacak bir yedekleme script’inin oluşturulmasını içerir.

4.1. /opt/mysql Klasörü Oluşturma:

    sudo mkdir -p /opt/mysql

4.2./opt/backup Klasörü Oluşturma:

    sudo mkdir -p /opt/backups

4.3.Backup Script’i Oluşturma: 

/opt/backup.sh dosyasını oluşturun ve aşağıdaki içeriği ekleyin:

    #!/bin/bash
    
    SOURCE_DIR="/opt/mysql"
    BACKUP_DIR="/opt/backups"
    
    mkdir -p "$BACKUP_DIR"
    
    TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
    BACKUP_FILENAME="backup_$(basename "$SOURCE_DIR")_$TIMESTAMP.tar.gz"
    BACKUP_PATH="$BACKUP_DIR/$BACKUP_FILENAME"
    
    if tar -czf "$BACKUP_PATH" -C "$(dirname "$SOURCE_DIR")" "$(basename "$SOURCE_DIR")"; then
        echo "Backup successful: $BACKUP_PATH"
    else
        echo "Backup failed!"
        exit 1
    fi

4.4.Script’e Çalışma İzni Verme (Slave):

    sudo chmod +x /opt/backup.sh

4.5.Jenkins Job’unu Build Alma: 

Jenkins’teki ilgili Job’u çalıştırın.

image

2. Cron ile Build Alma

Cron ile build alma, Jenkins’teki Job’ların belirli zaman aralıklarında otomatik olarak çalıştırılmasını sağlar.

Adımlar:

  1. Job Yapılandırması: Jenkins’teki ilgili Job’u açın ve yapılandırma sayfasına gidin.
  2. Triggers Bölümü: ”Build Triggers” bölümünü bulun.
  3. Build Periodically: ”Build periodically” seçeneğini işaretleyin.
  4. Zamanlama Ayarı: Cron ifadesini kullanarak zamanlama ayarlarını yapın. Örneğin, her gece 03:00’te çalıştırmak için: 0 3 * * *

Not: Cron ifadelerini Jenkins Job bazlı yönetmek, sunucudaki cron ayarlarını yönetmekten daha kolaydır, özellikle sunucu sayısı arttığında.

3. Trigger ile Build Alma

Bu adım, Gitlab gibi versiyon kontrol sistemlerindeki değişikliklerin otomatik olarak Jenkins build’lerini tetiklemesini sağlar.

Adımlar:

  1. Gitlab Entegrasyonu: Jenkins ve Gitlab arasında entegrasyon sağlamak için gerekli eklentileri kurun ve yapılandırın.
  2. Webhook Oluşturma (Gitlab): Gitlab’ta, ilgili proje için bir webhook oluşturun. Bu webhook, değişiklik olduğunda Jenkins’e bildirim gönderecektir.
    • URL: Jenkins sunucusunun URL’si ve Job’un build URL’si. Örneğin: https://jenkins.example.com/job/your_job/build
    • Secret Token: Gitlab ve Jenkins arasındaki güvenliği sağlamak için bir secret token kullanın.
  3. Jenkins’te Token Oluşturma:
    • Jenkins’te kullanıcı hesabınıza gidin.
    • Configure sayfasına gidin.
    • API Token bölümünde bir token oluşturun.
  4. Gitlab Webhook Ayarları: Gitlab webhook ayarlarında:
    • Secret token alanına oluşturduğunuz token’ı girin.
    • Hangi olayların webhook’u tetikleyeceğini seçin (push, merge request vb.).

Örnek Curl Komutu (Gitlab’tan Jenkins’i Tetikleme):

curl -X POST -L --user your-user-name:apiToken \
https://jenkins.example.com/job/your_job/build

Not: Jenkins lokalde çalışıyorsa ve Gitlab’daki branch’lerden tetiklenmesi isteniyorsa, Gitlab’ın da yerelde olması tercih edilir. Alternatif olarak, Cloudflare Tunnel gibi servisler kullanılabilir.

6. Cloudflare Tunnel ve Benzeri Servisler

Bu servisler, dışarıdaki bir yapının içerideki bir sunucuya ulaşması gerektiğinde kullanılır.

Örnek Servisler:

Jenkins User Yönetimi ve Parametrik Job’lar

Bu notlar, Jenkins’te kullanıcı yönetimi, rol tabanlı yetkilendirme ve parametrik job’lar hakkında bilgi içermektedir.

1. User Yönetimi

Jenkins’te kullanıcı yönetimi, kimlerin Jenkins’e erişebileceğini ve hangi yetkilere sahip olacağını belirlemeyi sağlar.

Yöntemler:

Uygulama Örneği:

Manuel User Oluşturma: 4 adet kullanıcı manuel olarak oluşturuldu.

image

Jenkins Konfigürasyonunu Yedekleme:

Yetkilendirme Testi: Bir Job’a sadece okuma yetkisi verin ve gizli modda giriş yaparak yetkilendirmenin doğru çalıştığını kontrol edin.

2. Rol Tabanlı Yetkilendirme (RBAC) ve Matris Tabanlı Yetkilendirme

Jenkins’te yetkilendirme, kullanıcıların veya grupların belirli eylemleri gerçekleştirmesine izin vermek için farklı yöntemlerle yönetilebilir. İki yaygın yöntem Role-Based (RBAC) ve Matrix-Based Security’dir.

1️⃣ Role-Based Authorization Strategy (RBAC)

Bu yöntemde kullanıcılara roller atanır ve bu roller belirli yetkilerle ilişkilendirilir. Böylece aynı role sahip kullanıcılar, sistem içinde aynı izinlere sahip olur.

Özellikleri:

✅ Kullanıcıları gruplar halinde yöneterek merkezi kontrol sağlar. ✅ Global, Job ve Agent seviyelerinde roller oluşturulabilir. ✅ Büyük organizasyonlar için uygundur, yeni kullanıcılar sadece ilgili role atanarak yetkilendirilebilir.

image image image image

2️⃣ Matrix-Based Security

Bu yöntemde kullanıcılar veya gruplar doğrudan yetkilendirilir, roller kullanılmaz. Kullanıcı bazında hassas ve detaylı izin ayarı yapmak gerektiğinde kullanışlıdır.

Özellikleri:

✅ Kullanıcı ve gruplara doğrudan izinler atanabilir. ✅ RBAC’ye göre daha esnektir, her kullanıcı için farklı yetki seviyeleri belirlenebilir. ✅ Küçük ekiplerde veya detaylı yetkilendirme gereken durumlarda daha uygundur.

image image

3. Parametrik Job’lar

Parametrik Job’lar, kullanıcıların bir build’i başlatırken değerlerini belirleyebileceği parametreler tanımlamanıza olanak tanır. Bu, aynı Job’u farklı konfigürasyonlarla çalıştırmayı kolaylaştırır.

Adımlar:

  1. Job Yapılandırması: İlgili Job’un yapılandırma sayfasına gidin.
  2. This project is parameterized: ”This project is parameterized” seçeneğini işaretleyin.
  3. Parametre Tanımlama:
    • String Parameter: Metin tabanlı değerler için.
    • Boolean Parameter: Doğru/Yanlış değerleri için.
    • Choice Parameter: Önceden tanımlanmış seçenekler arasından seçim yapmak için.
    • File Parameter: Bir dosya yüklemek için.
  4. Parametreleri Kullanma: Build adımlarında parametre değerlerine $PARAMETRE_ADI şeklinde erişebilirsiniz. Örneğin, bir shell script’te parametre değerini kullanmak için:
    echo "Parametre değeri: $MY_PARAMETER"

Örnek Senaryolar:

image image image image image image image image

Kaynaklar:

BÖLÜM-3

İÇİNDEKİLER:

1. Pipeline: Stage View Eklentisi Kurulumu

2. Groovy ile Basit Bir Pipeline Oluşturma

3. Jenkins Credential Yönetimi

4. Generate Declarative Directive Kullanımı

5. Jenkins Agent’ları ile Dağıtık Build Ortamları Oluşturma

6. Java Uygulamaları için Tool Ekleme (Maven Örneği)

1. Pipeline: Stage View Eklentisi Kurulumu

Bu plugin ile pipeline çıktısını aşamalar halinde görebilir ve her aşamanın durumunu kolayca takip edebiliriz.

2. Groovy ile Basit Bir Pipeline Oluşturma

Jenkins arayüzünden Groovy script’i kullanarak basit bir Pipeline oluşturalım.

  1. Jenkins ana sayfasında, “New Item—>Pipeline”
  2. Bir isim verin (örneğin, “groovy-pipeline”).
  3. “OK”a tıklayın.
  4. Pipeline yapılandırma sayfasında, “Pipeline” bölümüne gidin, menüden “Pipeline script’i” seçeneğini seçin.Aşağıdaki Groovy kodunu metin alanına yapıştırın:

pipeline {
    agent any
    stages {
        stage('Merhaba') {
            steps {
                echo 'Merhaba Dünya!'
            }
        }
        stage('Tarih') {
            steps {
                sh 'date'
            }
        }
    }
}
  1. “Save” ile kaydedin.
  2. “Build Now” ile pipeline ı çalıştırın.

image

Jenkins’te pipeline oluşturmanın iki temel yolu vardır:

Jenkins Arayüzünde Doğrudan Kodlama (“Pipeline script”): Bu yöntemde, pipeline betiğini doğrudan Jenkins işinin yapılandırma sayfasındaki metin alanına yazarsınız.

SCM’den Pipeline Betiği Çekme (“Pipeline script from SCM”): Bu yöntemde, pipeline betiğini (genellikle Jenkinsfile adında) bir versiyon kontrol sisteminde saklarsınız. Jenkins, pipeline’ı çalıştırdığında betiği otomatik olarak SCM’den çeker.

image

  1. Jenkins Credential Yönetimi

Jenkins’te hassas bilgileri (şifreler, API anahtarları vb.) güvenli bir şekilde saklamak için credential özelliğini kullanabilirsiniz.

Amaç: Pipeline’larda güvenli bir şekilde hassas bilgileri kullanmak.

Adımlar: Jenkins ana sayfasında, “Manage Jenkins -> Credentials -> System -> Global credentials (unrestricted)” bölümünden add new credential’a tıklayarak yeni credential oluşturun.

image

Burada ;

1- Kind: açılır menüden “Secret text” seçeneğini seçin. Bu, gizli bir metin verisi saklayacağımızı belirtir.

2- Scope: Bu, kimlik bilgilerinin tüm Jenkins projelerinde ve işlerinde kullanılabileceği anlamına gelir. Genellikle en iyi seçenektir. Açıklama: Kimlik bilgilerinin kullanılabilirliğini sınırlamak istiyorsanız, proje veya klasör bazında bir kapsam seçebilirsiniz. Örneğin, yalnızca belirli bir projede kullanılacak bir API anahtarı için, o projeyi seçebilirsiniz.

3- Secret: Buraya, saklamak istediğiniz gerçek gizli metin verisini girin. Bu, gerçekte API anahtarınız, şifreniz veya başka bir hassas bilginiz olacaktır. Bu alana girilen bilgi Jenkins tarafından şifrelenerek saklanacaktır.

4- ID: Bu, credential’ımıza verdiğimiz benzersiz ID’dir. Pipeline kodumuzda bu ID’yi kullanarak credential’a başvuracağız. Açıklama: Anlamlı ve kolayca hatırlanabilir bir ID seçin. Boşluk veya özel karakterler kullanmaktan kaçının.

5- Description: Credential’ımızın ne için kullanıldığını açıklayan bir metindir. Açıklama: Açıklayıcı bir metin girmeniz, gelecekte bu credential’ı kimin veya neyin kullandığını anlamanıza yardımcı olacaktır. Ne tür bir veri sakladığınızı ve nerede kullanıldığını belirtmek faydalı olabilir.

6- “Create” Butonuna Tıklayın

New Item’dan yeni bir pipeline oluşturun:

pipeline {
    agent any

    stages {
        stage('Write Secret to File') {
            steps {
                withCredentials([string(credentialsId: 'Secret_data', variable: 'SECRET_VALUE')]) {
                    script {
                        // Gizli değeri bir dosyaya yaz
                        def secretFilePath = 'secret.txt'
                        writeFile file: secretFilePath, text: "$SECRET_VALUE"

                        // Dosyanın içeriğini konsola yazdır (isteğe bağlı, debug için)
                        //sh "cat ${secretFilePath}"

                        // Dosyanın oluşturulduğunu doğrulamak için bir mesaj yazdır (isteğe bağlı)
                        echo "Secret value has been written to ${secretFilePath}"
                    }
                }
            }
        }
    }
    post {
        always {
            // Dosyayı artifact olarak arşivle
            archiveArtifacts artifacts: 'secret.txt', allowEmptyArchive: true

            // Dosyayı sil (isteğe bağlı, güvenliği artırmak için)
            //deleteDir()
            //echo "Cleanup complete."
        }
    }
}

Save butanuna tıklayarak pipeline kaydedebilirsiniz. Ardından “Buil Now” ile çalıştıralım.

image image

Aşağıdaki ekran görüntüsü, pipeline tarafından oluşturulan secret.txt adlı artifact’e tıklandığında açılan içeriği göstermektedir. Bu dosya, Jenkins tarafından güvenli bir şekilde saklanan Secret_data adlı credential’dan alınan gizli metni içermektedir.

image

  1. Generate Declarative Directive Kullanımı

Jenkins’te “Generate Declarative Directive” veya “Pipeline Syntax” olarak bilinen araç, Declarative Pipeline sözdizimini öğrenmeyi ve kullanmayı kolaylaştırmak için tasarlanmıştır. Bu araç, kullanıcı arayüzü üzerinden belirli adımları yapılandırarak, karşılık gelen Declarative Pipeline kodunu otomatik olarak oluşturmanıza olanak tanır.

image image image

Jenkins Agent’ları ile Dağıtık Build Ortamları Oluşturma

Jenkins agent’ları, Jenkins master sunucusunun iş yükünü dağıtmak ve farklı ortamlarda build işlemleri gerçekleştirmek için kullanılan bağımsız yürütme ortamlarıdır.

1. Agent Kavramı ve Önemi:

Jenkins, build işlemlerini (derleme, test, deployment vb.) gerçekleştirmek için kaynaklara ihtiyaç duyar. Agent’lar, bu kaynakları Jenkins master sunucusundan bağımsız olarak sağlayarak aşağıdaki avantajları sunar:

2. Agent Ekleme ve Yapılandırma:

Agent’lar, Jenkins arayüzünde “Manage Jenkins” -> “Nodes” (veya “Manage Nodes and Clouds”) bölümünden eklenir ve yönetilir.

3. SSH Anahtar Tabanlı Kimlik Doğrulama ile Agent Bağlantısı:

Agent’lar, Jenkins master sunucusu ile SSH protokolü üzerinden güvenli bir şekilde iletişim kurar. SSH anahtar tabanlı kimlik doğrulama, şifre tabanlı kimlik doğrulamaya göre daha güvenli bir yöntemdir.

4. Pipeline’larda Agent Kullanımı:

Pipeline’larda agent direktifi ile belirli agent’ları hedefleyebilirsiniz.

pipeline {
    agent { label 'my-agent' } // "my-agent" etiketine sahip agent'ta çalışır
    stages {
        stage('Build') {
            steps {
                sh 'echo "Build aşaması çalışıyor..."'
            }
        }
    }
}

Agent Bağlantısı;

image

Pipeline’da kullanımı

image image

Eğer pipeline’ın tamamının belirli bir agent üzerinde çalışmasını istemiyorsanız, agent none direktifini kullanabilirsiniz. Bu durumda, her bir stage’in kendi agent direktifini içermesi gerekir.

pipeline {
    agent none
    stages {
        stage('Build') {
            agent { label 'my-agent' }
            steps {
                sh 'echo "Build aşaması çalışıyor..."'
            }
        }
        stage('Test') {
            agent { label 'another-agent' }
            steps {
                sh 'echo "Test aşaması çalışıyor..."'
            }
        }
    }
}

Java Uygulamaları için Tool Ekleme (Maven Örneği):

Java uygulamaları için genellikle Maven gibi build araçlarına ihtiyaç duyulur. Jenkins, bu araçları otomatik olarak yükleyebilir veya önceden yüklenmiş araçları kullanabilir.

image

Jenkins, build işlemi sırasında gerekli olan Maven’i otomatik olarak agent’a yükleyecektir.

BÖLÜM-4 Jenkins ve Tomcat ile Java Web Uygulaması Dağıtımı

İÇİNDEKİLER:

1. Tomcat 11 Kurulumu

2. Tomcat Kullanıcılarını Yapılandırma

3. Uzaktan Erişimi Yapılandırma (Jenkins ve Tomcat Farklı Sunucularda ise)

4. Tomcat’i Başlat

5. Jenkins’te Gerekli Eklentiyi Yükleme: Deploy to container Plugin

6. Global Tool Configuration (Maven Yapılandırması)

7. Jenkins Pipeline Oluşturma ve Yapılandırma

8. Credential ve Pipeline Entegrasyonu (tomcat-deploy Credential)

9. Pipeline’ı Çalıştırın ve Sonuçları İzleyin

10. Alternatif Deployment Yöntemi: “deploy-war-to-tomcat-without-plugin” (Pluginsiz Dağıtım)

11. Jenkins Configuration as Code (JCasc)

12. Seed Jobs ve Job DSL

Jenkins ve Tomcat ile Java Web Uygulaması Dağıtımı

Bu bölümde, bir Java web uygulamasının Jenkins tarafından otomatik olarak Tomcat 11 sunucusuna nasıl dağıtılacağını bakacağız.

Tomcat 11 Kurulumu:

Aşağıdaki adımlar, Tomcat 11’in /opt dizinine kurulmasını göstermektedir:

  1. Dizine Git:

        
 cd /opt

  2. Tomcat 11’i İndir:

        
 wget https://dlcdn.apache.org/tomcat/tomcat-11/v11.0.3/bin/apache-tomcat-11.0.3.tar.gz

  3. Arşivi Çıkar:

        
 tar -xf apache-tomcat-11.0.3.tar.gz

Tomcat Kullanıcılarını Yapılandırma:

Tomcat’in web arayüzüne erişim ve uygulamaların dağıtımı için kullanıcıları yapılandırmanız gerekmektedir.

  1. tomcat-users.xml Dosyasını Düzenle:

nano /opt/apache-tomcat-11.0.3/conf/tomcat-users.xml

  1. Kullanıcıları Ekle:

    Aşağıdaki kod bloğunu tomcat-users.xml dosyasına ekleyin (  etiketi içinde):

        
 <role rolename="manager-gui"/>
 <role rolename="manager-script"/>
 <role rolename="manager-jmx"/>
 <role rolename="manager-status"/>
    
 <user username="admin"
       password="admin"
       roles="manager-gui,manager-script,manager-jmx,manager-status"/>
    
 <user username="deployer"
       password="deployer"
       roles="manager-script"/>
    
 <user username="tomcat"
       password="s3cret"
       roles="manager-gui"/>
    • admin: Tomcat web arayüzüne tam erişim sağlar.
    • deployer: Uygulamaların dağıtımı için kullanılır (Jenkins ile entegrasyon için önerilen kullanıcı).
    • tomcat: Yalnızca Tomcat web arayüzüne erişim sağlar.

    Güvenlik Notu: Üretim ortamında, varsayılan kullanıcı adlarını ve parolalarını değiştirin ve güçlü parolalar kullanın!

    Uzaktan Erişimi Yapılandırma (Jenkins ve Tomcat Farklı Sunucularda ise):

    Eğer Jenkins ve Tomcat farklı sunucularda çalışıyorsa, Jenkins’in Tomcat’e uzaktan erişebilmesi için Tomcat’te ek yapılandırma yapmanız gerekmektedir. Bu yapılandırma, Tomcat’in web arayüzüne ve deployment işlevlerine uzaktan erişime izin vermeyi içerir.

    1. context.xml Dosyalarını Bul:

      Tomcat sunucunuzda, aşağıdaki komutu kullanarak aşağıda belirtilen dosyaları bulun:

      • /opt/apache-tomcat-11.0.3/webapps/manager/META-INF/context.xml
      • /opt/apache-tomcat-11.0.3/webapps/host-manager/META-INF/context.xml
     find / -name context.xml

context.xml Dosyalarını Düzenle:

Her iki context.xml dosyasını da bir metin düzenleyici ile açın ve  etiketi içinde aşağıdaki etiketini bulun


<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|JENKINS_SUNUCUSUNUN_IP_ADRESI"/>
JENKINS_SUNUCUSUNUN_IP_ADRESI: Bu kısmı, Jenkins sunucunuzun gerçek IP adresiyle değiştirin. Bu, yalnızca belirli bir IP adresinden (Jenkins sunucusu) Tomcat’in yönetici arayüzüne erişime izin verecektir. Birden fazla IP adresine izin vermek için, adresleri   karakteriyle ayırabilirsiniz.(test için allow=“.*” yapılandırabilirsiniz fakat bu şekilde Tomcat sunucusunun yönetim arayüzünü (manager ve host-manager uygulamaları) herhangi bir IP adresinden gelen isteklere açmış olursunuz.)

Örnek (Tek IP Adresi):


<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|192.168.1.100"/>

Bu örnek, hem yerel erişime (127.0.0.1 ve ::1) hem de 192.168.1.100 IP adresinden erişime izin verir.

Tomcat’i Başlat:

cd /opt/apache-tomcat-11.0.3/bin/
./startup.sh

Jenkins’te Gerekli Eklentiyi Yükleme: Deploy to container Plugin ( Plugin ile dağıtım yöntemi için gereklidir.)

Global Tool Configuration (Maven Yapılandırması, dokuman3 de burayı yapmıştık. Burada proje içinde kullanılacak mvn versiyonu aynı olmalı)

Jenkins Pipeline Oluşturma ve Yapılandırma:

Jenkins’te, Tomcat’e dağıtımı otomatikleştirecek bir pipeline oluşturun:

  1. Yeni Pipeline İşi Oluşturun:
    • Jenkins ana sayfanızda “New Item” seçeneğine tıklayın.
    • Bir isim verin (örneğin, tomcat-deploy-approve).
    • “Pipeline” türünü seçin ve “OK” butonuna tıklayın.
  2. Pipeline Tanımını Yapılandırın:
    • İş yapılandırma sayfasında, “Pipeline” bölümüne gidin.
    • “Definition” açılır menüsünden “Pipeline script” seçeneğini seçin.
    • pipeline kodunu yazın:
        
 pipeline {
     agent {
         label 'linux'  // Bu pipeline'ın "linux" etiketine sahip bir agent üzerinde çalışacağını belirtir.
     }
     tools {
         maven 'maven 3.8.6' // Bu pipeline'ın "maven 3.8.6" adında bir Maven kurulumu kullanacağını belirtir.
     }
     stages {
         stage('Checkout Code') {
             steps {
                 checkout([$class: 'GitSCM', branches: [[name: '*/main']], extensions: [], userRemoteConfigs: [[url: 'https://gitlab.com/ozguryazilimkiskampi/tomcat-deployment-example.git']]])
             }
         }
         stage('Test') {
             steps {
                 sh 'mvn test'
             }
         }
         stage('Build') {
             steps {
                 sh 'mvn package'
             }
         }
         stage("Deploy on Test") {
             steps {
                 deploy adapters: [
                     tomcat9(credentialsId: 'tomcat-deploy',
                      path: '', url: 'http://192.168.186.145:8080')],
                      contextPath: '', war: '**/*.war'
    
             }
    
         }
     }
 }
    • agent { label ‘linux’ }: Pipeline’ın linux etiketine sahip bir agent üzerinde çalışacağını belirtir. Agent yapılandırması için önceki bölümlere bakın.
    • tools { maven ‘maven 3.8.6’ }: Pipeline’ın maven 3.8.6 adında bir Maven kurulumu kullanacağını belirtir. Global Tool Configuration bölümünde bu kurulumun yapılandırıldığından emin olun.
    • checkout: Git repository’sinden kaynak kodunu çeker.
    • mvn test: Maven ile testleri çalıştırır.
    • mvn package: Maven ile projeyi paketler (WAR dosyası oluşturur).
    • deploy: “Deploy to container Plugin” eklentisini kullanarak WAR dosyasını Tomcat sunucusuna dağıtır.
      • credentialsId: ‘tomcat-deploy’: Tomcat credential’ının ID’sini belirtir (önceki adımlarda oluşturduğunuz).
      • url: ‘http://192.168.186.145:8080’: Tomcat sunucusunun URL’sini belirtir.
      • war: ‘*/.war’: Dağıtılacak WAR dosyasının yolunu belirtir.
  3. “Save” Butonuna Tıklayarak Pipeline’ı Kaydedin.

Credential ve Pipeline Entegrasyonu (tomcat-deploy Credential):

image

Pipeline’ı Çalıştırın ve Sonuçları İzleyin:

Alternatif Deployment Yöntemi: “deploy-war-to-tomcat-without-plugin” (Pluginsiz Dağıtım):

Bazı durumlarda, belirli bir plugin kullanmak yerine, daha esnek bir çözüm tercih edebilirsiniz. Bu örnekte, “Deploy to container Plugin” kullanmadan, doğrudan SSH üzerinden Tomcat sunucusuna dağıtım yapacağız.

Ek Credential Oluşturun (SSH Key ile Kimlik Doğrulama):

Pluginsiz dağıtım için, Tomcat sunucusuna SSH ile bağlanmak için bir credential oluşturmanız gerekmektedir. Bu credential, bir SSH private key içermelidir.

Bu pipeline, üretilen artifact’ı (WAR dosyası) Nexus Repository Manager’a yükleme adımlarını içermektedir. Nexus kullanımı tamamen opsiyoneldir. Eğer Nexus kullanmıyorsanız, pipeline’daki “Publish to Nexus” aşamasını kaldırabilir veya devre dışı bırakabilirsiniz. Nexus Kullanılıyorsa “Nexus Artifact Uploader” plugin’in kurmak gerekir.


pipeline {
    
    agent {
        label 'linux'
    }

    environment {
        TOMCAT_SERVER = '<tomcat_ip>'
        TOMCAT_PATH = '/opt/tomcat/webapps'
        TOMCAT_SERVER_USER = 'root'
        TOMCAT_STARTUP_SCRIPT = '/opt/tomcat/bin/startup.sh'
        TOMCAT_SHUTDOWN_SCRIPT = '/opt/tomcat/bin/shutdown.sh'
        NEXUS_VERSION = "nexus3"
        NEXUS_PROTOCOL = "http"
        NEXUS_URL = "<nexus_ip>:<port>"
        NEXUS_REPOSITORY = "maven-releases"
        NEXUS_CREDENTIAL_ID = "nexus-credentials"
    }
    
    tools {
        maven 'maven 3.8.6'
    }
    
    stages {
        stage('Checkout Code'){
            steps{
                checkout scm
            }
        }
        
        stage('Test'){
            steps{
                sh 'mvn test'
            }
        }
        
        stage('Build'){
            steps{
                sh 'mvn package'
            }
        }
        
        stage('Deploy Onayı') {
            steps {
                input m
                essage: 'Uygulamayı test ortamına deploy etmek istiyor musunuz?',
                      ok: 'Evet, Deploy Et'
            }
        }
        
        stage("Deploy on Test") {
            steps {
                sshagent(['deploy-ssh-key']) {
                    sh '''
                        scp -o StrictHostKeyChecking=no target/*.war ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER}:${TOMCAT_PATH}
                        ssh -o StrictHostKeyChecking=no ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER} "sudo sh ${TOMCAT_SHUTDOWN_SCRIPT}"
                        ssh -o StrictHostKeyChecking=no ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER} "sudo sh ${TOMCAT_STARTUP_SCRIPT}"
                    '''
                }
            }
        }
        
        stage("Publish to Nexus") {
            steps {
                script {
                    pom = readMavenPom file: "pom.xml"
                    filesByGlob = findFiles(glob: "target/*.${pom.packaging}")
                    artifactPath = filesByGlob[0].path
                    artifactExists = fileExists artifactPath

                    if(artifactExists) {
                        echo "*** File: ${artifactPath}, group: ${pom.groupId}, packaging: ${pom.packaging}, version ${pom.version}"
                        
                        nexusArtifactUploader(
                            nexusVersion: NEXUS_VERSION,
                            protocol: NEXUS_PROTOCOL,
                            nexusUrl: NEXUS_URL,
                            groupId: pom.groupId,
                            version: pom.version,
                            repository: NEXUS_REPOSITORY,
                            credentialsId: NEXUS_CREDENTIAL_ID,
                            artifacts: [
                                [artifactId: pom.artifactId,
                                classifier: '',
                                file: artifactPath,
                                type: pom.packaging],
                                [artifactId: pom.artifactId,
                                classifier: '',
                                file: "pom.xml",
                                type: "pom"]
                            ]
                        )
                    } else {
                        error "*** File: ${artifactPath}, could not be found"
                    }
                }
            }
        }
    }
}

Pipeline’ın İşleyişi:

  1. Checkout Code: Kaynak kodunu Git deposundan çeker.
  2. Test: Maven ile testleri çalıştırır.
  3. Build: Maven ile projeyi paketler (WAR dosyası oluşturur).
  4. Deploy Onayı: Kullanıcıdan dağıtım için onay ister.
  5. Deploy on Test:
    • sshagent([‘deploy-ssh-key’]): deploy-ssh-key adlı SSH credential’ını kullanarak SSH bağlantısı kurar. Bu credential, Tomcat sunucusuna bağlanmak için gerekli olan private key’i içerir.
    • scp -o StrictHostKeyChecking=no target/*.war ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER}:${TOMCAT_PATH}: WAR dosyasını Tomcat sunucusuna kopyalar.
      • scp: SSH üzerinden dosya kopyalama komutu.
      • o StrictHostKeyChecking=no: İlk bağlantıda host key’i otomatik olarak kabul eder. (Güvenlik açısından dikkatli olunmalı, gerçek ortamda bu seçenek kaldırılabilir veya dikkatli bir şekilde yönetilmelidir).
      • target/*.war: Kopyalanacak WAR dosyasının konumu.
      • ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER}:${TOMCAT_PATH}: Dosyanın kopyalanacağı hedef sunucu ve dizin.
    • ssh -o StrictHostKeyChecking=no ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER} “sudo sh ${TOMCAT_SHUTDOWN_SCRIPT}”: Tomcat’i durdurur.
    • ssh -o StrictHostKeyChecking=no ${TOMCAT_SERVER_USER}@${TOMCAT_SERVER} “sudo sh ${TOMCAT_STARTUP_SCRIPT}”: Tomcat’i başlatır.
  6. Publish to Nexus: (Opsiyonel) Üretilen artifact’ı (WAR dosyası) Nexus’e yükler. Bu aşama, artifact’ların merkezi bir depoda saklanmasını ve paylaşılmasını sağlar.

Jenkins Configuration as Code (JCasc)

Jenkins Configuration as Code (JCasc), Jenkins ayarlarını kod olarak yönetmenizi sağlayan bir yaklaşımdır. Bu yaklaşım, Jenkins ayarlarını YAML formatında dosyalarda saklamanıza ve versiyon kontrol sisteminde tutmanıza olanak tanır.

JCasc ile Jenkins ortamınızı kolayca yeniden oluşturabilir veya farklı ortamlara dağıtabilirsiniz.Jenkins ayarlarını otomatik olarak uygulayabilir ve yönetebilirsiniz.

Bu özelliği kullanabilmek için Jenkins’te “Configuration as Code” plugin’ini kurun.

image

Seed Jobs ve Job DSL

Seed Jobs ve Job DSL (Domain-Specific Language), Jenkins’te job’ları otomatik olarak oluşturmanızı sağlayan bir yaklaşımdır. Bu yaklaşım, büyük sayıda benzer işi yönetmek ve yapılandırmayı otomatikleştirmek için idealdir.

Ek Notlar: