Bloğa geri dön

Ubuntu 22.04 Üzerinde Kendi Barındırdığınız Çalıştırıcılar (Self-Hosted Runners) ile GitHub Sürekli Entegrasyon İş Hatları Nasıl Kurulur.

Ubuntu 22.04 Üzerinde Kendi Barındırdığınız Çalıştırıcılar (Self-Hosted Runners) ile GitHub Sürekli Entegrasyon İş Hatları Nasıl Kurulur.

Giriş

Yazılım Mühendisliği hızlı tempolu ve rekabetçi bir alandır. Ürünlerinizi kullanıcılara daha hızlı sunmak, rakiplerinize karşı size avantaj sağlayacaktır. İyi tarafı ise, şirketlerin eşit şartlarda rekabet etmesine yardımcı olmak için sektörün en iyi uygulamalarının mevcut olmasıdır.

Sürekli Entegrasyon ve Sürekli Geliştirme (CICD), şirketlere bu rekabetçi alanda avantaj sağlamak için sektörün en iyi uygulamalarından yararlanan bir strateji örneğidir.

Bir sürüm kontrol aracı olan Git ile web tabanlı bir depo olan GitHub, yazılım geliştiricilerinin, mühendislerinin ve mimarlarının CI/CD uygulamasını sağlar. Sürekli Geliştirme (CD), derlemeleri, testleri ve dağıtımları otomatikleştirme uygulamasıdır. Sürekli Entegrasyon (CI) ise birçok kişinin aynı proje üzerinde iş birliği yapmasına ve birleştirme çakışmaları endişesi duymadan kodun çalıştığını kontrol etmesine olanak tanır.

GitHub Actions, derlemeleri, testleri ve dağıtımı otomatikleştiren adımlar yazmamıza olanak tanır.

Bu eğitimde, GitHub Actions ile Sürekli Entegrasyonun nasıl kurulacağını öğreneceksiniz. Kodumuzu barındırmak için bir Git deposu kurarak başlayacağız. Ardından, kodumuzdaki değişiklikleri izlemek, testleri çalıştırmak için bir CI çalıştırıcısı başlatmak, uygulamamızı derlemek ve Nginx çalıştıran Ubuntu 22.04 sunucusuna dağıtmak için bir GitHub CI süreci yapılandıracağız.

Gereksinimler

Bu eğitimi takip etmek için aşağıdakilere ihtiyacınız olacak:

Şimdi ihtiyacımız olan her şeye sahip olduğumuza göre, başlayalım.

Adım 1. Proje Deposunu Klonlama.

Bu eğitimi şu temele dayandıracağız: Reactjs, Kullanıcı arayüzleri oluşturmak için bildirimsel bir Javascript kütüphanesi. Sıfırdan yeni bir proje kurmak istiyorsanız, şu kaynağı kullanabilirsiniz: React Uygulaması Kurma kaynağı. Kısa kesmek adına, bu React.js deposunun GitHub'da halihazırda kurduğumuz bir klonunu kullanacağız.

Klonladığımız uygulama, react-router 6 ve React Testing Library ile yapılmış, bize DOM'a erişmek için yöntemler sunan bir test içeren basit bir react uygulamasıdır.

Depoyu klonlamak için yeşil butona tıklayın ve URL'yi kopyalayın.

Çalışma alanınızda terminali açın ve uygulamayı klonlamak için aşağıdaki komutu çalıştırın:

Depoyu klonladıktan sonra, proje dizinine gidin:

Uygulamayı derlemek ve çalıştırmak için docker-compose up komutunu çalıştırın:

İşlem tamamlandığında, şu adresi ziyaret edin: http://localhost:3000

Şuna benzer bir şey görmelisiniz:

Adım 2. Node.js.yml Dosyasını Anlamak.

Bu adımda, ne olup bittiğini anlamamıza yardımcı olması için GitHub Yaml dosyasındaki yönergeleri tanımlayacağız. Depoda, şu dizin bulunmaktadır: .github/workflows dizini, bir node.js.yml dosyası içerir; bu dosya, GitHub'daki kod deponuza değişiklikleri gönderdikten sonra GitHub çalıştırıcılarının izleyeceği iş akışı adımlarına sahiptir. YAML söz dizimi, GitHub Actions için iş akışları yazmak amacıyla kullanılır. YAML dosyaları şu uzantıyla biter: yaml veya yml.

Şu dosyayı açın: node.js.yml dosyası, şu şekilde görünmelidir:

Bu öğreticiyi yazarken, Node.js 16'nın 16. sürümünü kullanıyorduk. Şimdi, GitHub Actions’ın iş akışını anlayalım:

  • name

name: cicd-tut

İş akışınızın adı, bu ad deponuzun Actions sekmesinde gösterilecektir.

  • on

on olayları tanımlamak için kullanılır. Olaylar bir iş akışını otomatik olarak tetikleyebilir veya daha sonrası için planlanabilir. Olaylar tek veya birden fazla olabilir, ayrıca iş akışı yürütmelerini belirli dallara, etiketlere veya dosyalara göre de belirtebilirsiniz. Bu bir filtre gibi çalışır.

YAML dosyamızda otomatik birden fazla olay tanımlıyoruz, bunlar şunlardır:

  • Bir push olayı, kod bir depoya gönderildiğinde (commit) tetiklenir

  • Bir pull_request olayı, main dalı üzerinde bir çekme isteği (pull request) oluşturulduğunda tetiklenir.

İş akışının yürütülmesini yalnızca o dalla sınırlandırmak için bir dal adı belirtiyoruz: main. Ayrıca dal adının önüne ! işareti koyarak yoksayılacak dalları da belirtebiliriz.

  • jobs

Bir iş akışı esasen bir veya birkaç işten oluşur. Bu işler ilkinden sonuncusuna doğru sırayla çalışır.

Her iş, tarafından belirtilen bir çalıştırıcı (runner) ortamında çalışır.runs-on. İşleri, ile belirtilen GitHub çalıştırıcılarında veya ubuntu-latest ile belirtilen bir self-hosted çalıştırıcıda çalıştırmayı seçebilirsiniz: self-hosted. Seçiminiz, ihtiyacınız olan iş sayısına bağlı olacaktır. Kendi barındırdığınız (self-hosted) çalıştırıcılarla, kaynaklar üzerinde daha fazla esnekliğe ve kontrole sahip olursunuz.

Bir sonraki adımımızda, işlerimizi önce GitHub çalıştırıcılarında çalıştıracağız, ardından kendi sunucumuzda bir GitHub self-hosted (kendi barındırdığımız) çalıştırıcı kuracağız.

  • strategy

Strateji (strategy), değişkenlerin kombinasyonlarına dayalı olarak otomatik olarak birden fazla iş çalışması oluşturmak için tek bir iş tanımında değişkenler kullanmamıza olanak tanır.

YAML dosyamızda node-version için bir değişkenimiz var, ancak node sürüm 18 için şu şekilde başka bir değişken eklersek: node-version: [16.x, 18.x], o zaman matris (matrix) stratejisi, react uygulamamız için hem 16 hem de 18 node sürümleri için 2 iş çalışması oluşturacaktır.

  • steps

Adımlar (steps), bir işi oluşturan görevler dizisidir. Adımlar komutları çalıştırabilir, görevleri kurabilir, genel deponuzdaki eylemleri veya bir docker kayıt defterinde yayınlanan eylemleri çalıştırabilir.

Bir adımın bir adı vardır. İsteğe bağlı olsa da, Github'da görüntülenecek adımınızın adını kolayca tanımlamak için bunu kullanabilirsiniz.

Bir adımda, işinizde çalıştırılacak bir eylem seçebilirsiniz, eylemler yeniden kullanılabilir. Bir eylem tanımlanırken eylemin sürümleri belirtilir; bu, eylem sahibi bir güncelleme yayınladığında iş akışınızın bozulmasını önlediği için önemlidir.

Yukarıdaki kod parçacığında, checkout@v3 belirtilen bir sürüme sahip bir eylem örneğidir 3. Bu eylem, iş akışınızın erişebilmesi için deponuzu kontrol eder (checkout).

Yukarıdaki actions/setup-node@v3 gibi bazı eylemler, with anahtar kelimesi kullanılarak belirtilen girdilere sahiptir; setup node eylemleri node sürüm 16'yı ve npm'in önbelleğe alınmasını gerektirir.

  • run

Bu eylem, işletim sisteminin kabuğunu (shell) kullanarak komut satırı programlarını çalıştırır.

Yukarıdaki YAML dosyasında üç komutumuz var, hepsi de çalıştırıcı (runner) ortamında aynı kabuğu kullanarak çalışacaktır.

  • İlk komut olan npm i react uygulamamızın ihtiyaç duyduğu tüm bağımlılıkları yükler.

  • İkinci komut olan npm test, yazdığımız testi çalıştırır. Test, learn react metninin Ana sayfada oluşturulmasını bekler.

  • Son olarak, npm run build komutu, uygulamamızın üretim sürümünü içeren bir build dizini oluşturur. Daha sonra bu build dizinini Nginx sunucu bloğumuzda kullanacağız..

Adım 3. GitHub Çalıştırıcıları (Runners) ile GitHub CI'yı Test Etme.

Bu adımda, GitHub çalıştırıcıları ile Sürekli Entegrasyon (CI) sürecini test edeceğiz. node.js.yml dosyasını açarak başlayın. Eylemlerin üzerinde çalışacağı çalıştırıcı türünü ubuntu-latest olarak değiştirin. Bunun amacı, kendi barındırdığımız (self-hosted) çalıştırıcılarımızı kurmadan önce GitHub iş akışının GitHub çalıştırıcılarında mükemmel şekilde çalışıp çalışmadığını test etmektir.

Kendi GitHub hesabınızda yeni bir depo oluşturun. Devam etmeden önce çalışma alanı dizininize geri dönün ve .git dizinini silin, göremiyorsanız gizli dosyalarınızı kontrol edin. Dizini silmek için terminalinizde aşağıdaki komutu kullanabilirsiniz:

Şimdi tüm proje dosyalarınızı git add ile ekleyebilir, commit edebilir ve deponuza push edebilirsiniz. Takılırsanız, proje klasörünüzü yukarıda oluşturduğunuz GitHub deposuna bağlama konusundaki bu kılavuzu kullanın.

İşiniz bittiğinde, deponuzdaki Code sekmesine tıklayın; toplam commit sayısının yanında küçük turuncu bir nokta göreceksiniz. Buna tıkladığınızda, iş akışınızın sıraya alındığını gösteren aşağıdaki gibi bir modal göreceksiniz:

Şimdi modal üzerindeki Details bağlantısına tıklayın veya Actions sekmesine gidin, node.js.yml iş akışının her bir adımının GitHub çalıştırıcıları tarafından çalıştırıldığını göreceksiniz:

Başarılı olursa, Actions sekmesine tıklayın, şu şekilde görünmelidir:

İşte bu kadar, Code sekmemizdeki küçük turuncu nokta artık yeşil bir onay işareti olmalıdır. GitHub çalıştırıcısı uygulamamızı başarıyla derledi.

Şimdi bir adım daha ileri gidelim ve derleme ortamını kendi Ubuntu Sunucu Altyapımızda.

Adım 4. GitHub iş akışını kendi barındırdığımız (self-hosted) bir çalıştırıcıyı kullanacak şekilde ayarlama.

Kendi barındırdığımız çalıştırıcıyı sunucumuza kurmadan önce, çalışma alanımıza geri dönelim ve GitHub kendi barındırdığımız çalıştırıcılarda çalışması için node.js.yml  iş akışı dosyasını düzenleyelim.

Bu aşamada, değişiklikleri commit ettiğinizde, kendi barındırdığınız bir çalıştırıcı tanımlanmadığı için iş sıraya alınacaktır.

Deponuzda, Settings sekmesine tıklayın, sol kenar çubuğunda Actions seçeneğine ve ardından Runners:

Şu seçeneğe tıklayın: New self-hosted runner, ve işletim sistemi olarak Linux seçin.

Çalıştırıcıyı nasıl indireceğinizi ve sunucunuza nasıl kuracağınızı gösteren talimatları göreceksiniz.

Adım 5. Sunucumuza bir Github kendi barındırdığımız (self-hosted) çalıştırıcısının kurulması ve yapılandırılması.

Bu adımda, kendi barındırdığınız (self-hosted) bir GitHub runner kuracağız. Kendi barındırdığınız runner, GitHub web sitesindeki GitHub Actions işlerinin dağıtımını ve yürütülmesini yönetebilen bir sistemdir. Kendi barındırdığınız runner'ın GitHub tarafından barındırılan runner'a göre bir avantajı esnekliktir. İstediğiniz uygulama ihtiyaçlarını karşılamak üzere özelleştirilebilen işletim sistemi, donanım ve diğer araçlar üzerinde daha fazla kontrol sunar.

Kendi barındırdığınız runner'lar aşağıdaki gibi çeşitli seviyelerde eklenebilir:

  • Depo (Repository) düzeyinde runner'lar, bunlar tek bir depoya özeldir.

  • Organizasyon düzeyinde runner'lar, bunlar bir organizasyondaki birden fazla depo için işleri işleyebilir.

  • Birden fazla organizasyona atanabilen Kurumsal (Enterprise) düzeyde runner'lar.

Devam etmek için ssh üzerinden sunucunuza giriş yapın:

Şu komutla ana dizininize geçin:

Ardından, şu isimde bir dizin oluşturun: action-runners ve içine gidin:

Ardından, runner paketinin en son sürümünü indirin:

Ardından indirilen paketi şu komutla çıkarın:

Deponuza geri dönün, sol paneldeki Settings sekmesinde, sol yan panelde Actions, ardından Runners, tıpkı Step 4.

Kendi barındırdığınız runner'ınızı GitHub deponuza bağlayan bir belirteç (token) içeren listelenmiş bir komut göreceksiniz. GitHub runner kodunu çıkardığınız dizinin içindeyken, runner'ınızı bağlamak için listelenen komutu kullanın, örneğin:

Başarılı bir şekilde kimlik doğrulaması yapmalıdır:

Varsayılan (Default) runner grubu için enter tuşuna basın.

Ardından runner'ınız için bir isim girin, örneğin, my-runner, ve enter tuşuna basın.

Ek etiketler eklemeyi atlamak için Enter tuşuna basın, aşağıdaki ekran görüntüsündeki başarı mesajını görmelisiniz:

Çalışma dizininizin adını girin, örneğin, react-cicd, şu metinle başarılı olmalıdır: settings saved.

Son olarak, ./run.sh komutunu çalıştırın, bu Connected to Github:

metnini göstermelidir. Ancak bu arka planda çalışmaz, terminalimizde ctrl+c tuşlarına basarsak runner durdurulacaktır; runner'ın bir servis olarak çalışmaya devam etmesi ve bizim de onunla etkileşime devam edebilmemiz için bunu .svc.sh servisi ile değiştirmemiz gerekir.

Runner'ı ctrl+c ile durdurun. .svc.sh servisini şu komutu çalıştırarak yükleyebilirsiniz:

Yüklendikten sonra, şu komutla servisi başlatın:

Bu işlem başarılı olmalı ve şunu göstermelidir: active (running).

To confirm that the svc.sh servisinin çalışır durumda olduğunu doğrulamak için şu komutu çalıştırın:

Bu noktada, kendi barındırdığınız bir runner'ı beklemek üzere sıraya alınmış olabilecek tüm iş akışları başarıyla çalışmalıdır. Ayrıca bir dosyayı düzenleyip test edebilirsiniz. Örneğin, Hakkında.tsx dosyasını değiştirin, değişiklikleri commit edip push edin; kendi barındırdığınız runner işi başarıyla tamamlayacaktır.

Adım 6. Nginx sunucu bloğunun (server block) kurulması

Bu adımda, react uygulamamızın derleme (build) sürümünü görüntülemek için Nginx'te bir sunucu bloğu kuracağız. Yardımcı bulabileceğiniz Nginx sunucu bloklarını kurma üzerine bir eğitimimiz bulunmaktadır.

Aşağıda, bu eğitimde kullanılan bir sunucu bloğu örneği verilmiştir:

Nginx sunucu bloğu yapılandırma dosyasını /etc/nginx/sites-available dizini içinde oluşturacaksınız.

Sitenizin sunucu bloğu yapılandırması için nano düzenleyici ile şu komutu kullanarak bir dosya açın:

Yukarıda paylaşılan sunucu bloğunu kopyalayın, kendi dizin yollarınıza göre düzenleyin ve açılan dosyaya yapıştırın. Düzenlemeyi bitirdiğinizde, ctrl+x tuşlarına, ardından y ve enter tuşlarına basarak kaydedip çıkın.

Kaydettikten sonra, react-cicd sunucu bloğu yapılandırması için /etc/nginx/sites-available dizininden /etc/nginx/sites-enabled dizinine şu komutu çalıştırarak bir sembolik bağlantı (symlink) oluşturun:

Değişikliklerin geçerli olması için Nginx'i yeniden başlatmanız gerekir. Ancak, Nginx servisini yeniden başlatmadan önce, şu komutu çalıştırarak Nginx yapılandırmalarının geçerli olup olmadığını test edin:

Yapılandırma doğruysa test başarılı olmalıdır.

Sunucu bloğundaki server_name yönergesinin “ react.test ” değerini fark ettiniz mi? Bu değeri yerel makinenizdeki hosts dosyasına ekleyeceksiniz. Bu, uygulamayı tarayıcınızda açmanızı sağlayacaktır. Bu adım yalnızca yerel geliştirme ortamlarında kullanılan sanal alan adları için gereklidir. Sunucunuzun genel (public) IP'sine bağlı kayıtlı bir alan adınız varsa, alan adına tarayıcınızdan zaten erişilebiliyor olmalıdır.

Yerel makinenizde, hosts dosyasını şu komutla açın:

hosts dosyasının içine sunucunuzun IP adresini ekleyin, örneğin 127.0.0.1, ardından sanal alan adınız gelecek şekilde.

Aşağıda bir örnek gösterilmiştir. Ardından dosyayı kapatıp kaydedin:

Sunucunuza geri dönüp /var/www dizini içinde, şu komutu çalıştırarak react-cicd adında yeni bir dizin oluşturun:

Bu aşamada, node.js.yml dosyasındaki son komutun yorum satırı işaretini kaldıracağız.

Bu komut, react uygulamamızın derleme (build) klasörünü, önceki adımda 5.

actions-runner dizini içinde belirttiğimiz çalışma klasöründen kopyalar ve public klasörünü /var/www/react-cicd dizinine yerleştirir.

Sunucu bloğu artık uygulamamıza erişebilir ve bunu bir tarayıcıda görüntüleyebilir.

Son olarak, şu komutla Nginx servisini yeniden başlatın:

Şimdi, Hakkında.tsx dosyasında bir değişiklik yapabilir, ardından değişikliklerinizi kaydedip (commit) deponuza (repository) gönderebilirsiniz (push). Başarılı bir derlemeden sonra, react uygulamanızın derlenmiş sürümünü http://react.test adresinde veya belirttiğiniz alan adında göreceksiniz. href öğesini Home.tsx dosyasında düzenlemekten kaçının, çünkü bu durum önceden yazılmış testin başarısız olmasına neden olabilir. Deponuzdaki Actions sekmesi de tamamlanan iş derlemesini göstermelidir.

Sonuç

Github Actions ile sürekli entegrasyon; iyi bir geliştirici deneyimi sunması, sürekli test süreçlerine yardımcı olması, büyük ekiplerde daha kolay iş birliği sağlaması, geliştirme süresini kısaltması, yeni özelliklerin hızlıca yayınlanması, gerçek zamanlı geri bildirim ve rakiplerinize karşı size avantaj sağlayan müşteri memnuniyeti gibi birçok avantajla birlikte gelir. Bu bilgiyi daha da geliştirmek için şunları da öğrenmek isteyebilirsiniz: Ubuntu üzerinde GitLab Sürekli Entegrasyon (CI) Pipelines Kurulumu. ve bir Kendi Kendine Yönetilen GitLab Örneği kullanarak Docker İmajlarınızı barındırmayı ve özel derlemeler çalıştırmayı.

Keyifli Çalışmalar!

author

Preslav Dobrev

Yazar · CloudSigma

Preslav Dobrev, CloudSigma'da Kreatif Tasarımcı olarak görev yapmakta olup geleneksel ve yenilikçi pazarlama kanallarını kullanarak tutarlı bir kurumsal kimlik oluşturmaya odaklanmaktadır. Sanatsal vizyonu stratejik pazarlamayla harmanlayarak etkili marka anlatıları oluşturma konusunda oldukça yeteneklidir.

Yorumlar

Henüz yorum yapılmamış. İlk siz olun.