İçeriğe geç
Proxus 2.0.0 Proxus 2.0: Proxus tarihinin en büyük sürümü Sürüm notları

1.5.6

ara sürüm 15 Nisan 2026

Sertifika deposu, kolay HTTPS değişikliği ve güvenli sertifika yenileme

Sertifika deposu, entegrasyonlara sertifika atama, daha güvenli varsayılan HTTPS seçimi ve sertifika değişikliğinden sonra otomatik toparlanma.

1.5.6 sürümü, HTTPS ve entegrasyon sertifikalarının yönetimini kolaylaştırıyor.

Yeni özellikler

Sertifika deposu

  • Sertifikalar tek ekranda: HTTPS, OPC UA güven listesi ve entegrasyon sertifikaları artık tek bir ekrandan yönetiliyor.
  • Sertifika hakkında net bilgi: Bir sertifikayı uygulamadan önce son kullanma tarihi, türü, özel anahtarının olup olmadığı, nerede kullanıldığı ve hangi profillerin ona bağlı olduğu görülebiliyor.
  • İlk kurulumda hazır sertifika: Yeni kurulumlar, üretim sertifikası içe aktarılana kadar otomatik oluşturulan kendinden imzalı bir sertifikayla açılabiliyor.

Sertifika deposu ayrıntı ekranı

Entegrasyonlara sertifika atama

  • Daha sade atama: AWS IoT Core, MQTT, Sparkplug B ve OPC UA bağlantıları artık arayüzden seçilen sertifikaları kullanıyor.
  • Daha az elle düzenleme: Çalışma sırasında gereken sertifika dosyalarını Proxus otomatik olarak hazırlıyor.
  • Daha sade profil formları: Yalnızca sistemin kendi içinde kullandığı alanlar artık normal düzenleme ekranlarında görünmüyor.

OPC UA güven yönetimi

  • Güvenilen ve reddedilen sertifikalar: Hangi sertifikaya güvenileceğine artık doğrudan Sertifika deposundan karar verilebiliyor.
  • Sertifikanın nerede kullanıldığı belli: Sertifika ayrıntı sayfası, sertifikanın istemci profillerinde mi yoksa güvenilen sunucu profillerinde mi kullanıldığını gösteriyor.

İyileştirmeler

Daha güvenli Sistem günlükleri ve destek paketi

  • Daha sade günlük ekranı: Sistem günlükleri artık operatörün önce görmesi gerekenleri gösteriyor: güvenli bir özet, önem derecesi, neden, kaynak, tekrar sayısı ve mesaj.
  • Tekrarlayan olaylar gruplanıyor: Aynı olay tekrar ettiğinde liste özdeş satırlarla dolmuyor; olay tek satırda sayısıyla gösteriliyor.
  • Destek paketi: Sistem günlükleri ekranından destek paketi oluşturulabiliyor. Destek ekibi ayrıntılı tanılama kayıtlarını bu paketten inceliyor; ham tanılama bilgileri normal yönetici ekranında açığa çıkmıyor.

Sistem günlükleri ekranı

Veri hedeflerinin çalışma durumu

  • Bağlayıcının gerçek durumu: Veri hedefleri ekranı artık bir bağlayıcının çalıştığını, hazır beklediğini, kısıtlı çalıştığını, durduğunu, hata verdiğini ya da hiç kullanılmadığını gösteriyor.
  • Daha kolay sorun giderme: Son başarılı gönderim, son hata, kullanım sayısı, hedef türü ve güvenli hata özeti sayesinde bir bağlayıcının gerçekten veri gönderip göndermediği anlaşılabiliyor.
  • Cihaz düzeyinde görünürlük: Cihaz ayrıntılarındaki Veri hedefleri sekmesinde artık her hedefin durumu doğrudan görülüyor.

Anomali inceleme ve alarm kuralı önerileri

  • İnceleme ve kural oluşturma ayrıldı: Trendlerdeki bulgular önce inceleniyor; kural oluşturmak istendiğinde aday değerlendirme moduna geçiliyor.
  • Bulgular çalışan kurallara aktarılıyor: Ani sıçrama, hızlı değişim, kayma, sabit kalma ve veri boşluğu seçimleri doğrudan çalışan alarm kurallarına taşınıyor.
  • Varsayılan olarak daha az gürültü: Sabit kalma bulguları artık daha temkinli değerlendiriliyor ve inceleme modunda gruplanıyor.

Varsayılan HTTPS seçimi daha güvenli

  • Etkinleştirmeden önce özel anahtar kontrolü: Özel anahtarı olmayan bir sertifika artık varsayılan HTTPS sertifikası yapılamıyor.
  • Tek bir varsayılan: Proxus aynı anda yalnızca bir varsayılan sertifikayı etkin tutuyor.
  • Daha okunaklı başlıklar: Sertifika sekmelerinde ve ayrıntı başlıklarında artık daha kısa ve okunaklı adlar kullanılıyor.

Sertifika deposu liste ekranı

Cloudflare ile daha uyumlu

  • PEM ve anahtar birlikte içe aktarılıyor: Cloudflare Origin Certificate'lar artık özel anahtarlarıyla birlikte içe aktarılıp platformun HTTPS sertifikası olarak kullanılabiliyor.
  • Full (strict) için güvenli davranış: Özel anahtarı olmayan genel sertifikalar depoya doğru şekilde kaydediliyor, ancak HTTPS sunucu sertifikası olarak kabul edilmiyor.

Sertifika değişikliğinden sonra otomatik toparlanma

  • Arayüz yeniden başlarken toparlanıyor: Arayüzün kullandığı HTTPS sertifikası değiştiğinde Proxus, Data Protection anahtar halkasını otomatik olarak yeniliyor.
  • Edge Gateway da yeniden başlarken toparlanıyor: Aynı koruma artık Edge Gateway ve çalışma ortamı tarafında da geçerli.
  • Eski anahtarlar arşivleniyor: Sertifika yenilenirken eski korumalı anahtar dosyaları açılışı engellemiyor; arşive taşınıyor.

Arayüzde tutarlılık

  • Yerel yazı tipleri: Arayüz kendi içinde gelen yazı tiplerini kullanıyor; kurulumların yazı tiplerini göstermek için internete erişmesi gerekmiyor.
  • Material tarzı durum etiketleri: Cihaz durumu, veri hedefi bağlayıcı durumu, alarm kuralı durumu, alarm durumu ve günlük seviyesi, listelerde ve ayrıntı ekranlarında daha anlaşılır ve tutarlı gösteriliyor.
  • Tutarlı adlandırma: Cihaz ayrıntı sayfalarında dış sistemlere veri gönderilen yollar için artık Veri hedefleri adı kullanılıyor.

Kubernetes HA kurulumu güçlendirildi

Bu sürümle Kubernetes HA kurulum paketi yenilendi. Yüksek erişilebilirlik kurulumu, artık bir düğüm ya da pod arızalandığında da gerçekten kesintisiz çalışıyor.

Yüksek erişilebilirlik için çoğaltılmış mesajlaşma

  • HA'da akışlar varsayılan olarak çoğaltılıyor: Her kalıcı mesaj akışı artık üç mesajlaşma pod'unda üç kopya halinde tutuluyor. Pod'lardan biri arızalansa da yoldaki mesajlar kaybolmuyor.
  • Ortam değişkeniyle ayarlanıyor: Kopya sayısı, UI ve Gateway pod'larındaki bir ortam değişkeniyle belirleniyor. Üretim HA kurulumu üç kopya kullanıyor; tek düğümlü mevcut Docker kurulumu hiçbir değişiklik olmadan tek kopyayla çalışmaya devam ediyor.
  • Kademeli güncellemede kesinti yok: Akışlar üç kopyalı olduğu için mesajlaşma pod'ları yeniden başlatılırken mesaj akışı kesilmiyor.

Pod Disruption Budget tanımları

  • Bakımda koruma: Bir düğüm boşaltıldığında ya da bakıma alındığında aynı anda birden fazla mesajlaşma pod'u veya UI pod'u devre dışı kalmıyor.
  • Çoğunluk korunuyor: Üç pod'lu mesajlaşma kümesi, olağan küme işlemleri sırasında çoğunluğu (quorum) kaybetmiyor.

Prometheus metrik uç noktası

  • Yerleşik mesajlaşma metrikleri: Her mesajlaşma pod'u artık akış, rota, leaf ve gateway istatistiklerini 7777 portunda Prometheus uyumlu bir uç noktadan sunuyor.
  • Toplamaya hazır servis: Ayrı bir headless servis, metrik uç noktasını standart Prometheus etiketleriyle yayımlıyor.

Pod'lar daha iyi yerleştiriliyor

  • Mesajlaşma pod'ları ayrı düğümlerde: Kaynaklar elverdiğinde mesajlaşma pod'ları farklı küme düğümlerine yerleştiriliyor (anti-affinity).
  • UI kopyaları dağıtılıyor: UI kopyaları küme düğümlerine yayılıyor; iki kopya aynı düğümde toplanmıyor.

Kaynak istekleri ve sınırları

  • Öngörülebilir yerleşim: UI, Gateway ve mesajlaşma iş yükleri artık CPU ve bellek istek ve sınırlarını bildiriyor. Böylece zamanlayıcı onları güvenilir şekilde yerleştiriyor ve aynı düğümdeki diğer iş yüklerinin etkisinden koruyor.

Kimlik bilgileri Kubernetes Secret'larında

  • Manifestlerde açık metin yok: Varsayılan mesajlaşma ve veritabanı kimlik bilgileri artık kurulum manifestlerinde açık metin olarak yer almıyor; pod açılırken Kubernetes Secret'larından okunuyor.
  • Kolay değiştirme: Bu değerler, manifestlere dokunmadan yalnızca Secret güncellenerek değiştirilebiliyor.
  • Docker kurulumu değişmedi: Tek düğümlü Docker Compose kurulumu eskisi gibi çalışmaya devam ediyor.

Daha sade küme yönlendirmesi

  • Tek headless servis kaydı: Mesajlaşma kümesi rotaları, pod başına ayrı rota yerine artık tek bir headless DNS kaydı kullanıyor. Pod yeniden başlatılırken günlüklere düşen yinelenen rota satırları ortadan kalktı.

Hata düzeltmeleri

Ortam değişkenleri artık tüm yapılandırma ayarlarını geçersiz kılabiliyor

  • TOML ayarları güvenilir biçimde geçersiz kılınıyor: Bir ortam değişkeni tanımlandığında artık her bölümde karşılık gelen Proxus-config.toml değerinin yerine geçiyor. Mesajlaşma kimlik bilgileri, Edge Gateway kimliği, MQTT sunucusu erişim anahtarı, uç modu ve entegrasyon modu da buna dahil. Bu ayarlar daha önce doğrudan dosyadan okunuyor, bazı kurulumlarda ortam değişkenleri dikkate alınmıyordu.
  • Standart .NET yazımı: Hiyerarşi seviyeleri arasında çift alt çizgi kullanılıyor (örneğin Database__ConnectionString, EdgeGateway__GatewayID, Security__Password__MinLength). TOML anahtarlarının büyük/küçük harf yazımı korunuyor.
  • Boş değer de geçerli sayılıyor: Boş metin olarak tanımlanan bir ortam değişkeni, TOML değerinin yerine boş metin yazıyor. TOML'daki değerin kullanılması isteniyorsa değişken "" yapılmamalı, tamamen kaldırılmalı.
  • Güncel başvuru: Yapılandırma dosyası başvurusu her anahtarın doğru ortam değişkeni adını listeliyor.

Kurulum ve işletim notları

  • Varsayılan HTTPS sertifikası değiştirildiğinde mevcut oturumlar ve çerezler geçersiz olur. Bu beklenen bir durumdur.
  • Yeni bir varsayılan HTTPS sertifikası seçtikten sonra ilgili servisi yeniden başlatın.
  • Cloudflare Full (strict) modunda sertifikayı ve özel anahtarı birlikte içe aktarın.
  • Kubernetes manifestlerini kubectl apply -k <overlay-dir> (kustomize) ile uygulayın. Dosyalar -f ile tek tek uygulanırsa kustomization'da tanımlı namespace dikkate alınmaz ve kaynaklar yanlış namespace'te oluşabilir.
  • Üretime geçmeden önce Kubernetes Secret'larında tutulan varsayılan mesajlaşma ve veritabanı kimlik bilgilerini değiştirin.
  • Mevcut kurulum manifestlerinde eski UPPERCASE_SINGLE_UNDERSCORE kuralıyla yazılmış ortam değişkeni adları varsa gözden geçirin. Bu adlar daha önce de etkisizdi ve hâlâ etkisiz; geçerli olmaları için belgelerdeki Section__Key biçimine göre yeniden adlandırın.

Bir sonraki adım

Güncel sürümü kendi tesis verinizle görün.

Bir veri katmanını değerlendirmenin en kısa yolu, onu kendi ekipmanınızdan veri okurken görmektir. Bir makine ve bir hedef sistem belirleyin; veri yolunu gözünüzün önünde birlikte kuralım.

  1. 01

    Keşif görüşmesi

    Ekipmanlarınızı, protokollerinizi, tesislerinizi ve verinin ulaşması gereken sistemleri konuşuruz.

  2. 02

    Teknik demo

    Genel bir tanıtım yerine, tesisinize benzeyen bir senaryo üzerinde canlı demo yaparız.

  3. 03

    Pilot planı

    Kurulum ve güvenlik sorularını baştan yanıtlar, ilk hat ya da tesis için kapsamı birlikte belirleriz.

  4. 04

    Yaygınlaştırma

    Aynı şablonlarla yeni hatlar ve tesisler devreye girer.