API test paketiniz, yalnızca güvenebileceğiniz bir programa göre çalışıyorsa işe yarar. Elle tetiklediğiniz bir koleksiyon, tıklamayı hatırladığınızda hataları yakalar. Kontrol ettiğiniz bir makinede gece yapılan bir çalışma, kullanıcılarınızdan önce sabah 2'de onları yakalar. İşte Apidog çalıştırıcısının (runner) görevi budur: kendi sunucunuza Docker ile kurulan, kendi kendine dağıtılan bir hizmettir. Apidog'da oluşturduğunuz zamanlanmış test senaryolarını yürütür ve raporları projenize geri gönderir.
Apidog'da testleri zamanlamanın üç yolunu, otomatik API testlerini zamanlama rehberimizde ele aldık. Bu gönderi, bulut yürütmeyi, çalıştırıcıyı ve CLI'ı genel bir düzeyde karşılaştırır. Bu gönderi ise çalıştırıcı yoluna derinlemesine bir bakıştır: ne zaman ihtiyacınız olduğu, nasıl dağıtılacağı, zamanlanmış bir görevin ona nasıl yönlendirileceği ve alternatiflerle nasıl karşılaştırıldığı.
Kendi kendine barındırılan bir test çalıştırıcısına ne zaman ihtiyacınız olur?
Bulut yürütme kullanışlıdır, ancak üç durum ekipleri kendi kendine barındırılan bir test çalıştırıcısına yönlendirir.
API'leriniz özel bir ağda yaşıyor. https://orders.staging.internal:8443 adresindeki bir hazırlık ortamı, genel internetten çözümlenemez. Hiçbir bulut hizmeti ona ulaşamaz. VPC'nizin veya ofis ağınızın içine dağıtılan bir çalıştırıcı ulaşabilir, çünkü istekleri bulunduğu yerden yapar. Bu, intranetinizde kendi kendine barındırılan bir mock sunucusu çalıştırmanın arkasındaki aynı mantıktır: iş yükü, ağ erişiminin olduğu yerde bulunmalıdır.
Uyumluluk, trafiği şirket içinde tutar. Güvenlik ekibiniz, gerçekçi müşteri verileri içeren test yüklerinin altyapınızdan ayrılmasını yasaklıyorsa, bulut yürütme söz konusu olamaz. Çalıştırıcı ile istekler sunucunuzdan kaynaklanır ve API'lerinize doğrudan ulaşır. Yalnızca test raporları Apidog'a geri gider.
Herhangi bir dizüstü bilgisayardan bağımsız, kararlı programlar istiyorsunuz. Masaüstü uygulamasında zamanlanan testler, uygulama kapandığında durur. CI'ya entegre testler, biri kod gönderdiğinde çalışır. İkisi de size "ne olursa olsun, sonsuza dek her 6 saatte bir" ifadesini vermez. Her zaman açık bir sunucudaki bir çalıştırıcı tam olarak bunu yapar.
Bunlardan hiçbiri geçerli değilse, muhtemelen bir çalıştırıcıya ihtiyacınız yoktur. Uygulamadaki manuel çalıştırmalar veya CI'daki CLI size yeterli olacaktır.
Apidog çalıştırıcısı nedir?
Kendi kendine barındırılan çalıştırıcı, bağımsız bir sunucuya dağıttığınız bir otomasyon hizmetidir. Ekibinize bağlandığında şunları yapabilir:
- Apidog test senaryolarınızdan oluşturulan zamanlanmış otomatik test görevlerini çalıştırır
- Tekrarlayan bir programa göre API belgelerini içe aktarır
- Kendi kendine barındırılan mock yanıtlarını sunar
İki kapsamda gelir. Ekip düzeyinde genel bir çalıştırıcı bir ekibe aittir. Kuruluş düzeyinde bir çalıştırıcı, kuruluşunuzun ekiplerindeki tüm projeler arasında paylaşılabilir. Dağıtım her ikisi için de aynı şekilde çalışır.
Temel zihinsel model: çalıştırıcı bir çalışandır, projenizin bir kopyası değildir. Test senaryolarınız, ortamlarınız ve iddialarınız Apidog'da kalır. Çalıştırıcı görevleri alır, ulaşabildiği herhangi bir ağa karşı yürütür ve sonuçları yükler. Ekip üyeleri ne olduğunu görmek için asla SSH ile bağlanmaz; uygulama içindeki çalıştırma geçmişini açarlar.
Ön koşullar
Dağıtımdan önce bunları kontrol edin. Bunlar doğrudan çalıştırıcı dağıtım ortamı belgelerinden alınmıştır.
Donanım. Minimum 2 CPU çekirdeği ve 4 GB RAM; eşzamanlı görevler çalıştıracaksanız veya daha büyük bir ekibiniz varsa 4+ çekirdek ve 8 GB önerilir. Günlükler ve test eserleri için en az 30 GB disk alanı, rahat olmak için 50 GB ayırın.
Docker. Ana bilgisayarın Docker sürüm 20.10.0 veya üzeri olması gerekir, 20.10.13 önerilir. Sunucu yeniyse, önce dağıtımınız için resmi Docker Engine kurulum rehberini izleyin.
Ağ. Çalıştırıcı, HTTPS üzerinden 443 portundan Apidog sunucusuyla konuşur ve gerçek zamanlı görev gönderimi için bir WebSocket (WSS) bağlantısını açık tutar. Ayrıca rapor yüklemeleri için kullanılan AWS alanlarına giden erişime ve elbette testlerinizin hedeflediği her API'ye ağ erişimine ihtiyacı vardır. Buradaki yönü unutmayın: çalıştırıcı dışarıya bağlantı kurar. Apidog'un ona ulaşması için gelen portları açmanıza gerek yoktur, bu da operasyon ekibinizle güvenlik duvarı görüşmelerini kısa tutar.
İzinler ve plan. Bir çalıştırıcı dağıtmak bir ekip kaynak eylemidir, bu nedenle uygun ekip rolüne ihtiyacınız olacaktır. Kaç zamanlanmış görev çalıştırması alacağınız abonelik katmanınıza bağlıdır; plan başına güncel limitler için Apidog fiyatlandırma sayfasını kontrol edin.
Adım 1: Apidog'dan dağıtım komutunu alın
Apidog, içinde bir kimlik doğrulama belirteci (auth token) bulunan Docker dağıtım komutunu sizin için oluşturur. Bu gönderi dahil, bir blog gönderisinden kopyalamayın; belirteç, kapsayıcıyı ekibinize bağlayan şeydir.
- Apidog'u açın ve Apidog Ana sayfasına gidin. Henüz bir hesabınız yoksa, takip etmek için Apidog'u ücretsiz indirin.
- Çalıştırıcının ait olması gereken ekibi seçin.
- Sağ tarafta Kaynaklar'a tıklayın.
- Genel Çalıştırıcıyı Dağıt'a tıklayın.
Bir açılır pencere, tam dağıtım komutunu gösterir. Hemen kopyalayın: hassas bir belirteç içerir ve yalnızca bir kez gösterilir. Onu bir CI sırrı gibi ele alın, ekip wikiniz için bir kod parçacığı gibi değil.
Kopyalamadan önce, iletişim kutusu komutu özelleştirmenize olanak tanır:
- Sunucu İşletim Sistemi: Linux, macOS veya Windows.
- İmaj varyantı: Genel, Node.js 18, Java 21, Python 3 ve PHP 8 ile birlikte gelir, bu nedenle bu dillerdeki ön/son işlemci betikleri ek kurulum olmadan çalışır. Slim yalnızca Node.js 18'i içerir ve daha hızlı çekilir. Özel, testler dahili CA sertifikalarına veya alışılmadık kitaplıklara bağlı olduğunda kendi Dockerfile'ınızı sağlamanıza olanak tanır.
- Açık port: çalıştırıcıyı kendi kendine barındırılan mock'lar için de kullanacaksanız,
-pile bir tane eşleştirin (örneğin-p 80:4524). - Bağlı veri dizini: test senaryolarınız veri odaklı çalıştırmalar için CSV veri kümeleri gibi yerel veri dosyalarını okuyorsa, bir
-vbirim bağlaması ekleyin.
Genel çalıştırıcı belgeleri her seçeneği ayrıntılı olarak ele alır.
Adım 2: Kapsayıcıyı çalıştırın ve bağlandığını onaylayın
Hedef sunucuya SSH ile bağlanın, komutu yapıştırın ve Docker'ın imajı çekmesine ve kapsayıcıyı başlatmasına izin verin. İlk gün dikkate alınması gereken iki operasyonel not:
TZ'yi bir ortam değişkeni olarak geçirin (örneğinTZ=Asia/Singapore), böylece "her gün 02:00" sizin 02:00'niz anlamına gelir, kapsayıcı varsayılanı değil.- Çalıştırıcı sürümü 2.2.5'ten itibaren, imaj kök olmayan bir
runnerkullanıcısı (UID/GID 10001) içerir. PlatformunuzrunAsNonRoot'u uyguluyorsa, güvenlik bağlamını buna göre ayarlayın ve birim izinlerini önceden yapılandırın, çünkü giriş noktası kök olmayan modda dizinlerin sahipliğini değiştiremez.
Apidog'a geri döndüğünüzde, WebSocket el sıkışması tamamlandığında çalıştırıcı ekibinizin Kaynakları altında görünür ve ekip üyeleri görev oluştururken onu seçebilir. Bir dakika içinde görünmezse, docker logs ile kapsayıcı günlüklerini kontrol edin ve ana bilgisayarın 443 portundan Apidog sunucusuna ulaşabildiğinden emin olun; engellenmiş bir WSS bağlantısı, kısıtlı kurumsal ağlarda genellikle suçludur.
Bir ekipte birden fazla çalıştırıcı dağıtabilirsiniz. Ekipler genellikle birini hazırlık VPC'si içinde, diğerini üretim okuma erişimiyle tutar ve ardından göreve göre seçim yapar.
Adım 3: Çalıştırıcıyı hedefleyen zamanlanmış bir görev oluşturun
Çalıştırıcı çevrimiçi olduğunda, zamanlama bir formdur, bir betik değil.
- Projenizde, Testler modülünü açın ve Zamanlanmış Görevler'e tıklayın. Görevler bir klasör yapısında yaşar, bu nedenle liste büyüdükçe onları hizmete veya ortama göre gruplayın.
- Bir görev oluşturun ve altı ay sonra bir ekip arkadaşınızın anlayacağı bir isim verin: "Sipariş hizmeti duman testi, hazırlık, her 6 saatte bir" ifadesi "test1"i yener.
- Bir veya daha fazla test senaryosu seçin. Senaryo başına ortamı, test verilerini, yineleme sayısını, istekler arasındaki gecikmeyi ve istek/yanıt gövdelerini kaydedip kaydetmeyeceğinizi ayarlayabilirsiniz.
- Ortamı ve değişken kapsamını ayarlayın. Değişkenleri görevin içindeki tüm senaryolara uygulamak önerilen orta yoldur; klasör çapında kapsam güçlüdür ancak kolayca yanlış anlaşılabilir.
- Çalışma Döngüsünü ayarlayın: her Pazar akşam 11'de, her 6 saatte bir, bir şeyin bozulduğunu ne kadar çabuk bilmeniz gerektiğine uygun olanı.
- Üzerinde Çalışan altında, kendi kendine barındırılan çalıştırıcınızı adına göre seçin.
- Bildirimleri yapılandırın. Her çalıştırmadan sonra veya yalnızca başarısızlık durumunda uyarı verebilirsiniz. Yalnızca başarısızlık mantıklı varsayılandır; yeşil tiklerle dolu bir kanal herkesi onu görmezden gelmeye alıştırır.
Kaydedin. Bu noktadan itibaren, Apidog uygulaması açık olsun ya da olmasın, program sunucunuzda yürütülür.
Adım 4: Apidog'daki çalıştırma raporlarını okuyun
Her çalıştırmadan sonra çalıştırıcı, sonuçları otomatik olarak Apidog sunucusuna yükler. Her yürütmeyi görmek için uygulamada Zamanlanmış Görevler → Çalıştırma Geçmişi'ni açın: geçme/kalma durumu, senaryo başına sonuçlar, iddia başarısızlıkları ve zamanlama.
Bu, çalıştırıcının ev yapımı bir cron-artı-betik kurulumuna göre sessiz avantajıdır. Yürütme altyapınızda gerçekleşir, ancak raporlama testlerin tanımlandığı aynı paylaşılan çalışma alanına düşer. Salı günkü 02:00 çalıştırması başarısız olduğunda, araştıran QA mühendisi, bir sunucuda günlük dosyalarını taramadan, hangi adımda hangi iddianın başarısız olduğunu bağlam içinde görür.
Başarısızlık bildirimlerini çalıştırma geçmişiyle eşleştirin ve bir izleme döngünüz olur: uyarı tetiklenir, raporu açın, başarısız olan adımı uygulamada aynı ortama karşı manuel olarak yeniden oluşturun, düzeltin ve bir sonraki başarılı çalıştırmayı bekleyin.
Çalıştırıcı (Runner) vs CLI vs bulut: bir yürütme yolu seçmek
Apidog, uygulamada manuel tıklamanın ötesinde testleri yürütmenin üç yolunu sunar ve bunlar farklı sorunları çözer. Apidog CLI GitHub Actions rehberimizde CI yolunun tam bir adım adım açıklamasını yazdık ve aşağıdaki karşılaştırma her birinin nerede uyduğunu gösteriyor.
| Kendi kendine barındırılan çalıştırıcı | CI'da Apidog CLI | Bulut yürütme | |
|---|---|---|---|
| Tetikleyici | Zaman tabanlı program | Kod gönderme, PR veya işlem hattı programı | Uygulamadan çalıştır |
| Üzerinde çalışır | Sunucunuz (Docker) | CI çalışanlarınız | Apidog'un altyapısı |
| Intranet API'lerine ulaşır | Evet | Evet, eğer CI çalıştırıcıları ağ içindeyse | Hayır |
| Veriler şirket içinde kalır | Evet, sadece raporlar ayrılır | Evet | Hayır |
| Kurulum çabası | Ekip başına bir Docker dağıtımı | İşlem hattı başına YAML | Yok |
| Raporlar | Apidog'da çalıştırma geçmişi | CLI/HTML/JSON çıktısı, yüklenebilir | Apidog'da |
| En iyisi | Özel API'lerde yinelenen sağlık kontrolleri için | Test sonuçlarına göre dağıtımları engellemek için | Genel API'lerde hızlı çalıştırmalar için |
Yollar rekabet etmek yerine birleşir. Yaygın bir kurulum: CLI, işlem hattındaki her dağıtımı denetlerken, çalıştırıcı hazırlık ortamına karşı saatlik bir duman testi paketi ve gece tam bir regresyon testi yürütür, kod değişikliklerinden ziyade altyapı kaymasından ve süresi dolmuş kimlik bilgilerinden kaynaklanan hataları yakalar.
Zamanlama konusunda bir uyarı: zamanlanmış görevler belgelerine göre, zamanlanmış görevler kendi kendine barındırılan bir çalıştırıcıda çalışacak şekilde tasarlanmıştır ve Apidog Cloud kullanılabilirliği yayınlandıkça seçilebilir olacaktır. Bugün zamanlanmış yürütmeye ihtiyacınız varsa ve planınız için bulut kullanılabilirliğini bekleyemiyorsanız, çalıştırıcı güvenilir yoldur.
Sıkça Sorulan Sorular
CI'da Apidog CLI kullanıyorsam çalıştırıcıya ihtiyacım var mı?
Farklı soruları yanıtlarlar. CI size "bu değişiklik API'yi bozdu mu?" diye gönderim anında söyler. Çalıştırıcı size "API şu anda sağlıklı mı?" diye sabit bir döngüde söyler, süresi dolmuş belirteçlerden, ölü bağımlılıklardan veya herhangi bir taahhüde bağlı olmayan altyapı kaymasından kaynaklanan hataları yakalar. Birçok ekip her ikisini de çalıştırır; desenin CI tarafından zamanlanmış yarısı için gece API test kurulum rehberimize bakın.
Çalıştırıcı intranet API'lerine ulaşabilir mi?
Evet, ve var olmasının ana nedeni budur. Çalıştırıcı, dağıtıldığı makineden istekler yapar. VPC'nizin veya ofis ağınızın içine yerleştirin ve hiçbir bulut hizmetinin çözümleyemeyeceği *.internal ana bilgisayarlarını test edebilir. Görevleri almak ve raporları yüklemek için yalnızca Apidog sunucusuna giden HTTPS ve WebSocket erişimine ihtiyacı vardır.
Minimum sunucu özellikleri nelerdir?
İki CPU çekirdeği, 4 GB RAM, 30 GB disk alanı ve Docker 20.10.0 veya üzeri. Eşzamanlı zamanlanmış görevler çalıştıran ekipler için 4+ çekirdek ve 8 GB'a geçin. Küçük bir VM veya ofis rafındaki yedek bir kutu da işe yarar; kısıtlayıcı faktör güç değil, çalışma süresidir.
Kendi kendine barındırılan bir çalıştırıcıda zamanlanmış görevler için hangi plana ihtiyacım var?
Zamanlanmış görev çalıştırma kotaları abonelik katmanına göre değişir, bu nedenle yüksek frekanslı bir program planlamadan önce Apidog fiyatlandırma sayfasındaki güncel limitleri kontrol edin. Araçlar arasında yürütme seçeneklerini değerlendiriyorsanız, Apidog CLI ve Postman CLI karşılaştırmamız her platformun test çalıştırıcı tarafının neleri içerdiğine bakar.