Kestra: CI/CD'nin ötesindeki işlemleri otomatikleştirin

kapanış bildirimi

Bu makale İngilizce olarak da mevcuttur. Teknik yardımla tercüme edildi ve yayınlanmadan önce editoryal olarak gözden geçirildi.

Bir daha gösterme.

Pazartesi, 9:00 Bir geliştiricinin bir test sunucusuna ihtiyacı var. Bilet sistemini açar, host adını, işletim sistemini ve maliyet merkezini girer ve bekler. Bir gün, bazen üç. Bir noktada VM, iki hafta önceki haliyle yapılandırılmış olarak gelen kutusuna düşüyor çünkü o zamandan beri modele kimse dokunmadı.

Bu sorunu mevcut araçlarla çözme eğilimi anlaşılabilir. Azure DevOps veya GitHub Actions'daki bir işlem hattı hızlı bir şekilde yazılır. Ancak CI/CD araçları başka bir şey için tasarlanmıştır: kod oluşturma, test etme, dağıtma. Bir taahhüdü takip edersiniz, yürütürsünüz ve işiniz biter. Uzun süren iş akışları, yeniden deneme mantığı ve durum yönetimi onların alanı değildir.

Kestra tam olarak bu boşluğu dolduruyor. Araç, 2021'den beri Kestra Technologies tarafından geliştirilmekte ve Şubat 2022'den beri Apache 2.0 lisansı altında açık kaynaklı bir proje olarak halka sunulmaktadır. Ticari işletmenin işlevleri OSS'nin çekirdeğini tamamlar. Kestra kendisini evrensel bir orkestratör olarak görüyor: görev otomasyonu, veri hatları, olay odaklı iş akışları ve giderek artan oranda yapay zeka aracıları ve iş akışları için; YAML'de her şey bildirimseldir, Git'te her şey sürümlendirilmiştir. Bu makale bunun pratikte nasıl göründüğünü göstermek için somut bir örnek kullanıyor: Bir geliştirici bir modül kullanarak bir Hetzner VM talep ediyor, Kestra bunu Terraform kullanarak tam otomatik olarak hazırlıyor. Terraform, Kestra yapılandırması ve Kestra Flows'a ilişkin tüm kodlar yazarın GitHub deposunda bulunabilir.

Düzenleme otomasyonla aynı şey değildir

Kestra'yı ilk duyduğunuzda, kaçınılmaz olarak bunun kabuk komut dosyalarını güzel bir kullanıcı arayüzünde saran başka bir araç olduğunu düşünürsünüz. Bu geçerli değildir. Aradaki fark, konsepttedir: Bir kabuk komut dosyası veya CI/CD işlem hattı sıralıdır: A adımının ardından B, ardından C gelir ve son olarak durum tamamlandı veya başarısız oldu. Araç, arada ne olduğuyla ilgilenmez. Öte yandan Kestra yönetir: Her bir adımın durumunu bilir, harici olayları bekleyebilir, hataları özel olarak ele alabilir, adımları paralel hale getirebilir ve iş akışını saatler veya günler sonra tam olarak kesintiye uğradığı noktada devam ettirebilir.

Bu salt akademik bir ayrım değildir. Uygulamada bu, Kestra'nın klasik işlem hattı araçlarıyla temsil edilemeyen iş akışlarını eşleyebileceği anlamına gelir: harici bir sistem hazır olana kadar bekleyen bir ön hazırlık işi, bir HTTP hatası nedeniyle üç dakika duraklayan ve ardından tekrar deneyen bir veri hattı, yalnızca manuel sürümden sonra devam eden bir dağıtım. Diğer araçların “boru hattı” dediği şey Kestra'daki bir akıştır.

Projenin arkasındaki geliştirme ekibi, Kestra'yı bilinçli olarak geniş bir kullanım yelpazesine göre konumlandırıyor. Odaklanılan nokta:

• Operasyonların otomasyonu: Altyapı sağlayın, kümeler sağlayın, yinelenen operasyonel görevleri otomatikleştirin.
• Veri hattı: Kestra, Apache Airflow ve Prefect ile doğrudan rekabet ediyor
• Olay odaklı iş akışları: Web kancalarına, sıraya alınmış iletilere veya dosya değişikliklerine yanıt veren akışlar.
• Yapay zeka iş akışları: Kestra, yapay zeka aracılarını tıpkı klasik operasyon görevleri gibi yönetir.

Dört temel yapı taşı

Kestra, aracın genel yaklaşımını anlamayı kolaylaştırmak için geliştiricilerin öncelikle içselleştirmesi gereken dört konsepte sahiptir.

A Akış Boru hattı tanımıyla karşılaştırılabilecek, ancak önemli ölçüde daha fazla ifade gücüne sahip olan en üst birimdir. Her akışın bir kimliği, yapılandırma için bir ad alanı ve bir görev listesi vardır. Git'te bir YAML dosyası olarak bulunur ve onun aracılığıyla değiştirilebilir ve dağıtılabilir.

atamalar bunlar bir akışın içindeki bireysel adımlardır. Kestra, yerleşik görev türlerinden oluşan kapsamlı bir kitaplıkla birlikte gelir: HTTP istekleri, dosya işlemleri, kabuk komutları, kapsayıcı yürütme, döngüler, koşullar ve paralelleştirme. Faaliyetler, sonraki faaliyetlerin girdi olarak kullanabileceği çıktılar üretebilir. Bu, akışın bireysel adımları arasında anlaşılır bir veri akışı oluşturur.

Tetikleyiciler Bir akışın ne zaman başlayacağını tanımlayın. Tetikleyici olarak programlar (Cron), web kancaları, diğer akışlar veya kullanıcı arayüzü aracılığıyla manuel yürütme arasında seçim yapabilirsiniz. Manuel tetikleme hafife alınmamalıdır: bildirilen tüm girişler için Kestra kullanıcı arayüzünde otomatik olarak bir giriş formu açar.

Eklentiler Kestra'yı harici entegrasyonlarla genişletin. Resmi eklenti ekosistemi, diğerlerinin yanı sıra Terraform, Kubernetes, AWS, Azure, GCP, Slack, dbt ve Airbyte'ı içerir. Eklentiler, Kestra'nın ayrı bir bağımlılık yönetimi olmadan başlangıçta yüklediği versiyonlu JAR'lardır. pip install.

Aşağıdaki liste minimum akışı göstermektedir:

id: hello-kestra
namespace: demo

inputs:
  - id: message
    type: STRING
    defaults: "Hallo von Kestra"

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "{{ inputs.message }}"

Bu akış temel öğeleri gösterir: ad alanı demo Yapılar, klasörlere benzer şekilde kullanıcı arayüzü üzerinden akar. Giriş message manuel olarak çalıştırıldığında bir metin alanı olarak görünür. Etkinlik, Pebble desen sözdizimini kullanarak girdiye referans verir {{ inputs.message }}. Aynı sözdizimi gizli diziler, önceki görevlerin çıktıları ve yürütme meta verileri için akışın her yerinde çalışır.

Yedek değil, tamamlayıcı

Şu soru ortaya çıkıyor: Zaten Azure DevOps'a sahip değil miyiz? Gerçekten buna ihtiyacımız var mı? Cevap evet ve hayır. Azure DevOps veya GitHub Actions, yapabilecekleri konularda rakipsiz olmaya devam ediyor: kod derlemek, testler çalıştırmak, kapsayıcılar oluşturmak, yapıtları dağıtmak. Bu görevleri değiştirmek isteyen herkes yanlış sorunla karşılaşıyor çünkü Kestra farklı bir yerden başlıyor.

CI/CD, depodan gelen her şey için doğru katman olmaya devam ediyor: oluşturma, test etme, gönderme. Ancak çoğu operasyonel süreç bir taahhüt yerine bir istekle başlar: bir ortam oluşturmanız, bir değişikliği test etmeniz, bir kaynağı yayınlamanız veya harici bir hizmeti entegre etmeniz gerekir. Kestra'nın mevcut CI/CD ortamını tamamladığı nokta tam da burasıdır.

Somut bir örnek: Bir geliştirici bir Kubernetes kümesi sağlamak istiyor. Bu teknik olarak bir Azure DevOps işlem hattında temsil edilebilir terraform apply bir komut dosyası görevi olarak. Eksik olan, onu çevreleyen her şeydir: Geliştiriciler için yapılandırılmış bir giriş formu yoktur ve bulut sağlayıcı yanıt vermezse temiz bir yeniden deneme mantığı yoktur. Kimin, hangi kaynağı, ne zaman istediğini gösteren bir kayıt da yok. En önemlisi, bir işlem hattı Terraform'u ateşle ve unut tarzında ele alır: betiği başlatın, çalıştırın, bir sonuç için umut edin; arada ne olduğu soyuttur. Öte yandan Kestra, her çalışmayı kendi parametreleriyle tamamen kapsar: durum, günlük ve yeniden deneme davranışı, belirli bir çalıştırmaya açıkça atanır ve kullanıcı arayüzünde anlaşılabilir. Bir adım başarısız olursa Kestra nerede, hangi girdilerle ve hangi durumda olduğunu biliyor ve körü körüne baştan başlamak yerine özel olarak tepki verebiliyor.

Airflow ve Prefect ile Karşılaştırma: Görüş açısı çok önemlidir

Kestra'ya hangi alternatiflerin söz konusu olacağı, veri mühendisliği ile platform mühendisliği arasında büyük farklılık gösteren bakış açısına bağlıdır. Veri mühendisliği ortamından gelenlerin aklına genellikle ilk önce Apache Yazılım Vakfı'nın üst düzey bir projesi olan Apache Airflow veya aynı isimdeki şirket tarafından geliştirilen Prefect gelir. Hava akışı, bağımlılıklar, zamanlama ve yinelenen mantık içeren DAG tabanlı veri hatları için belirlenmiş standarttır. Prefect, daha düşük işletme maliyetleri ve daha akıcı bir API sunan daha modern bir alternatiftir. Kestra aynı alanı kaplar ancak daha az Python merkezlidir: akışlar YAML'de tanımlanır, görevlere eklenti denir, Python bilgisi gerekli değildir. Bu, Kestra'yı özellikle karma ekipler için daha erişilebilir hale getirir.

Ancak platform mühendisliğinde tamamen farklı araçlar kullanılır. Yaygın olanlar arasında yerel bir Kubernetes orkestratörü olarak Argo Workflows, operasyonel görevler ve konfigürasyon yönetimi için Ansible Automation Platform ve Kod Olarak Altyapı iş akışları için Terraform Cloud yer alır. Bu araçların tümü gerçek sorunları çözer, ancak her biri kendi paradigmasına sıkı sıkıya bağlıdır. Terraform Cloud, Terraform'u çalıştırır, Argo, Kubernetes iş akışlarını çalıştırır, Ansible Automation Platform, Ansible'ı çalıştırır. Kestra burada kendisini kasıtlı olarak daha evrensel hale getiriyor: Bir akış, bir Terraform kapsayıcısını başlatabilir, ardından bir PowerShell betiğini çalıştırabilir, bir HTTP API'yi çağırabilir ve aracın temeldeki teknolojileri hesaba katmasına gerek kalmadan tek bir YAML akışında sonucu Slack'e geri getirebilir.

Geliştirici açısından bakıldığında Azure DevOps ve GitHub Eylemleri, CI/CD katmanı için ilk tercih olmaya devam ediyor. Airflow veya Prefect veri odaklı ortamlarda çalışmaya devam edebilir. Ancak Kestra, bu enstrümanların hiçbirinin evde olmadığı bir yere uyum sağlıyor: heterojen enstrüman manzaralarını bir arada tutan bir orkestrasyon katmanı olarak, ancak aynı zamanda bireysel enstrümanlar için bir vekil görevi de görebilir.

Yerel olarak test edin, bir kümede çalıştırın

Kestra, Docker Compose kullanılarak yerel olarak başlatılabilir. Docker-compose.yml dosyasının tamamı ekteki GitHub deposunda bulunur. komut docker compose up -d bu kadar yeter, kullanıcı arayüzü aşağıda http://localhost:8080 hemen ulaşılabilir:

Kubernetes'te üretken işlemler için resmi bir Helm şeması vardır. Bileşenler (sunucu, zamanlayıcı, yürütücü ve çalışan) ayrı dağıtımlar olarak çalışır ve bağımsız olarak ölçeklendirilebilir. Çalışanlar, görevlerin fiili yürütülmesinin kontrolünü ele alır ve ölçeklenebilirliğin ana aracıdır: daha fazla paralel yürütme, daha fazla çalışan kopyası anlamına gelir, altyapının geri kalanı sabit kalır. Kestra kaynaklarını (akışlar, ad alanları, sırlar, kullanıcılar ve roller) kod olarak da yönetmek istiyorsanız resmi Terraform sağlayıcısını kullanın: tüm Kestra yapılandırmasını Terraform kaynakları olarak eşler ve mevcut kod olarak altyapı işlem hatlarına sorunsuz bir şekilde entegre edilebilir.