Skip to main content
Köprü modunda sandbox platformunuz intranetinizde kalır ve dışarıdan erişilemez. Platformun yanındaki bir makinede ei-worker daemon’unu çalıştırırsınız; bu süreç yalnızca dışa doğru HTTPS çağrıları yapar, sandbox işleri için Empiric Intelligence’a uzun yoklama uygular, her işlemi yerel platformunuzda yürütür ve sonuçları geri gönderir.
Hiçbir zaman gelen bağlantı açılmaz ve Empiric Intelligence platformunuzun kimlik bilgilerini asla tutmaz: worker bu bilgileri kendi ortam değişkenlerinden okur.

Gereksinimler

  • Python 3.11+.
  • Empiric Intelligence bulut API’sine giden HTTPS erişimi.
  • Yerel sandbox platformuna ağ erişimi.
  • Worker’ın sonuç günlüğü için kalıcı disk (aşağıdaki “Sonuç günlüğü ve kurtarma” bölümüne bakın).

Kurulum

empiric-intelligence-worker paketi PyPI üzerinde yayımlanmıştır; runtime id ve worker anahtarı bilgilerinizi Empiric Intelligence temsilciniz ayrıca iletir. Sistem servisi olarak çalıştıracaksanız sabitlenmiş wheel paketini root tarafından yönetilen bir sanal ortama kurun:
Sürümü sabitleyin; böylece yükseltmeler bilinçli bir operatör eylemi olarak kalır: worker operatör tarafından sabitlenir ve kendiliğinden hiçbir zaman güncellenmez. pipx veya uv tool, etkileşimli bir kullanıcı için uygundur; ancak bunların çalıştırılabilir dosyaları genellikle o kullanıcının ev dizininde bulunur ve aşağıdaki sıkılaştırılmış systemd biriminin bu dizine erişimi bilinçli olarak kapatılmıştır. Sürümler, Empiric Intelligence CI üzerinden PyPI Trusted Publishing ile yayımlanır ve kaynak doğrulaması için Sigstore PEP 740 attestation kayıtları taşır. Paket, kısıtlı kullanım lisansıyla kaynak koda erişilebilir (source-available) biçimde dağıtılır (bkz. LICENSE): Empiric Intelligence’a bağlanmak için çalıştırabilirsiniz, ancak yeniden dağıtamaz veya değiştiremezsiniz.

Yapılandırma

Worker tarafından okunan Empiric Intelligence ayarları: e2b SDK’sının kendisi tarafından okunan sandbox platformu ayarları (worker bunlara bilinçli olarak dokunmaz; tek bir worker’ı hem gerçek E2B bulutunda hem de bir CubeSandbox platformunda çalışabilir kılan da budur):

Worker anahtarı hakkında

lkw01_... biçimindeki anahtar, Empiric Intelligence tarafından tek bir runtime için üretilir ve yalnızca bir kez gösterilir; anahtarı Empiric Intelligence temsilcinizden alırsınız. Yalnızca bu runtime’ın iş kuyruğu için kimlik doğrular (bir runtime’a ait anahtar başka bir runtime’ın kuyruğunu asla yoklayamaz). Anahtarı, sahibi root olan ve izinleri 600 olarak ayarlanmış bir dosyada saklayın. Anahtar değişimi yeniden üretim demektir: yeni bir anahtar alır ve ortam değişkeni dosyasında eskisiyle değiştirirsiniz.

systemd ile çalıştırma

Bu birimi /etc/systemd/system/ei-worker.service olarak kaydedin:
Ardından ortam değişkeni dosyasını oluşturup daemon’u başlatın:
Bu birim, sonuç günlüğü için kalıcı bir durum dizini kullanır ve daemon’u otomatik olarak yeniden başlatır; tek istisna, sürümün reddedildiği durumdur (aşağıya bakın). SIGTERM alındığında worker düzenli biçimde kapanır: yeni iş üstlenmeyi bırakır, devam eden işlemleri tamamlar ve çıkmadan önce hâlâ üzerinde olan işleri bildirir.

Ön kontroller: doctor

Daemon’u etkinleştirmeden önce ve her platform yükseltmesinden sonra yeniden çalıştırın:
Her kontrol OK, WARN veya FAIL yazdırır (herhangi bir FAIL durumunda sıfırdan farklı çıkış kodu döner):
  1. Bulut erişilebilirliği, anahtarın geçerliliği ve anahtar ile runtime arasındaki bağ.
  2. Sunucuya göre saat sapması (30 saniyenin üzerinde uyarı, 300 saniyenin üzerinde hata).
  3. Yerel sandbox platformunun erişilebilirliği.
  4. Duraklatma yeteneği (--probe kullanılmadıkça yalnızca hatırlatma).
  5. Anlık görüntü yeteneği (CubeSandbox >= v0.5.1; --probe kullanılmadıkça yalnızca hatırlatma).
  6. Boş disk alanı.
--probe ek olarak gerçek sandbox kontrollerini çalıştırır: platformunuzda gerçek bir sandbox oluşturur, duraklatılan bir sandbox’ın diskinin korunduğunu ve doğru şekilde sürdürüldüğünü doğrular, ardından anlık görüntü turunu yürütür (sandbox’ın anlık görüntüsünü alır, bu anlık görüntüden bir türev sandbox başlatır, diskin aktarıldığını doğrular) ve oluşturduğu her şeyi siler. Bunlar, duraklatma ve anlık görüntü desteğinin işlevsel eşikleridir; anlık görüntü kontrolü, Empiric Intelligence bulut denetiminin bu worker üzerinden yürüttüğü turun aynısıdır, dolayısıyla doctor ile bulut hiçbir zaman farklı sonuç veremez. Devreye alırken bir kez, ardından her platform yükseltmesinden sonra çalıştırın. Bunun CubeSandbox üzerinde neden önemli olduğunu öğrenmek için bkz. Uyumluluk.

Sürüm sabitleme ve HTTP 426

Bulut, dağıtım genelinde geçerli bir genel worker sürüm alt sınırı uygular (anlık görüntü ve kimlik doğrulama uyumluluğu için; şu anda 0.5.0 veya runtime üzerinde yapılandırılmış daha yüksek bir sabitleme). Bu sınırın altındaki bir worker HTTP 426 ile geri çevrilir ve sıfırdan farklı bir durum koduyla çıkar; systemd bu durumda daemon’u bilinçli olarak yeniden başlatmaz (kalıcı bir sorunda çökme ve yeniden başlatma döngüsüne girilmez). Sabitlenmiş paketi yükseltin (sudo /opt/ei-worker/bin/pip install --upgrade empiric-intelligence-worker==0.7.0) ve daemon’u yeniden başlatın (sudo systemctl restart ei-worker). Worker 0.7.0, sandbox network_policy yeteneğini ekler (izin listeleri ve ağ erişimi kapalı türev sandbox’lar dahil). Dağıtım sürecinde, genel ağa çıkışa izin veren işler uyumlu eski bir worker üzerinde sürebilir; ancak çıkışı kısıtlanmış bir çalıştırma, işi üstlenen worker’ı denetler ve bu yetenek yoksa başlamayı reddeder.

Sonuç günlüğü ve kurtarma

Her işlemin sonucu, bildirilmeden önce yerel bir SQLite günlüğüne yazılır. Bu, sonuçları çökmeye dayanıklı kılar:
  • Daemon veya makine yeniden başlarsa, yeniden teslim edilen bir işlem iki kez yürütülmek yerine günlükteki sonucu yeniden oynatır.
  • Bir işlem farklı bir makineye yeniden teslim edilirse (örneğin ikinci bir worker makinesine yük devretmesinden sonra) ve o makinede günlüğe yazılmış bir sonuç yoksa, worker bir komutu tekrarlamak veya kopya bir sandbox oluşturmak yerine yürütmeyi belirsiz (indeterminate) olarak bildirir.
Sonuç günlüğünü kalıcı depolama üzerinde tutun (EI_WORKER_STATE_DB yolu). Worker’ı bir container içinde çalıştırıyorsanız günlük dizinini birim (volume) olarak bağlayın; container ile birlikte kaybolan bir günlük, aynı makinede sorunsuz tamamlanacak kurtarmayı belirsiz sonuçlara dönüştürür.

İnce ayar

  • EI_WORKER_CONCURRENCY: platformunuzda kapasite payı varsa ve görevler kuyruğa biriktiyse bu değeri yükseltin; her yuva aynı anda tek bir sandbox’ın işlemlerini yürütür.
  • EI_WORKER_IDLE_TIMEOUT_S: boşta duran bir üstlenmenin yuvası bırakılmadan önce ne kadar tutulacağı. Varsayılan değer (330 saniye), bulutun işlem başına süre bütçesinin üzerinde kalacak şekilde seçilmiştir; yalnızca yuva kıtlığı sorun oluşturuyorsa düşürün.