Activiti Bulut Uygulama Hizmeti

Activiti Cloud Application Service

Dağıtılmış mimariler (kapsayıcılar dahil) oluşturduğunuzda, uygulamalar, bir altyapı üzerinde çalıştırdığınız mantıksal olarak ilişkili bir dizi mikro hizmet olur. Bu altyapı, kaynak tahsisini ve güvenliğini kontrol edebilmeniz gereken izole ortamlar kurmanıza izin verecektir. Bu ortamların her birinin içinde, bu mantıksal uygulamalardan oluşan bir sete sahip olmak isteyebileceğinize inanıyoruz, bu da muhtemelen çok sayıda konteyner yerleştireceğiniz anlamına gelir. Bu kapsayıcılardan bazıları Veri Depoları, Mesaj Aracıları, Ağ Geçitleri gibi altyapı hizmetleri olacak ve bazıları çok alana özel olacaktır.

Activiti Bulut Uygulama Hizmetinin ana sorumluluğu, bir ortamda çalışan bir dizi etki alanına özgü uygulamanın bu yüksek seviyeli (Activiti Buluta özgü) görünümünü sağlamaktır. Bazı düzeylerde Uygulamalar ayrıca birbirleri arasında yalıtım sağlar ve genellikle farklı Rol Tabanlı Erişim Denetimi, IDM yapılandırmaları, farklı mesaj aracısı yapılandırmaları, farklı kimlik bilgileri kümesi vb. Gerektirirler.

Bu belgenin amacı, Bulut Yerel ortamlarımızda konuşlandırılan Uygulamalar için bir tür denetleyici / monitör görevi gören Activiti Bulut Uygulama Hizmetinin ilk uygulaması için bir şartname olarak hizmet etmektir. Bu, istemci uygulamaları tarafından her bir Uygulama Hizmetini kullanmak ve onlarla etkileşim kurmak için kullanılabilir.

Not: Kubernetes'i hedeflesek bile, temel hizmetin teknolojiden bağımsız olduğundan emin olmamız gerekir. Bu, herhangi bir topluluk projesinin hizmetinde olduğu gibi, ortak soyutlamalara güvenmek, mevcut olanları yeniden kullanmaya çalışmak veya çabaların tekrarını önlemek için mevcut topluluklarla işbirliği yapmaktır.

Özellikleri

Uygulama Hizmeti uç noktaları, mevcut uygulamaları, uygulama meta verilerini ve uygulama durumunu ortaya çıkarmalıdır. Uygulama Hizmeti bu bilgileri saklamamalı, ancak mümkün olduğunca Hizmet Kaydı, Yapılandırma Hizmeti ve altyapıdaki diğer hizmetlere yetki verilmesine güvenmelidir.

Uygulama Hizmeti, yeni uygulamaların dağıtılmasından / sağlanmasından sorumlu değildir, ancak uygulamaların ne zaman hazır olduğunu ve istekleri almaya hazır olduğunu anlamak için uygulamanın yapısı ve durumu gibi işlemleri ifşa etmelidir. Bu, bu hizmetin en azından ilk sürümü için işlemlerin çoğunun yalnızca OKUYACAĞI anlamına gelir. Bu hizmet, Uygulama Hizmetinin güncel olan ve dağıtımların gerçek durumunu yansıtan verileri sağladığından emin olmak için ortamdaki değişikliklere (yeni hizmet kaydı / kayıt silme) tepki vermelidir, bu Hizmetin izlenmesiyle sağlanabilir Kayıt.

Uygulama Hizmeti ayrıca, her bir uygulamayı ve altyapı hizmetleri yapılandırmalarını ve bağımlılıklarını anlamak için Yapılandırma Hizmeti ile etkileşime girmelidir. Örneğin: Runtime Bundle (temel yapı taşlarımızdan biri) bir İlişkisel Veritabanına ve bir Mesaj Aracısına bağlıysa, hangi altyapı hizmetlerinin gerekli olduğunu anlamak için uygulama hizmetiyle ilgili bir giriş için bir Yapılandırma Hizmetine (veya configMaps) bakabilir. uygulamanın çalışması için. Akıllı olabilir ve bu gereksinimleri dağıtım zamanından önce listeleyebiliriz, böylece bir yönetici bu altyapı hizmetlerinin hazır olduğundan emin olabilir.

Uygulamaların IDM ve güvenlikle ilişkisi vardır, çünkü Keycloak'ı SSO ve IDM sağlayıcımız olarak kullanıyoruz, Uygulamalar farklı bir alan yapılandırmasına sahip olmayı gerektirebilir.

Dikkate alınması ve analiz edilmesi gereken önemli bir özellik, Uygulamalar sürümlemedir. Uygulamaları farklı ortamlardan taşıyabildiğimizden ve bu Uygulamaların her birinin bir yaşam döngüsüne sahip olacağından emin olmak önemlidir. Bu belgenin amacı, bu yönleri tanımlamaktır, hepsini çözmek değil.

Etkileşimler / Akış

Aşağıdaki şema, yukarıda açıklanan özellikleri sağlamak için etkileşime girecek bileşenleri göstermektedir:

Uygulama Hizmetinin 4 temel bileşenle ilişkisi vardır:

• Yapılandırma Hizmeti (K8'lerde Yapılandırma Haritaları ve Spring Bulut'ta Yapılandırma Hizmeti)

• Hizmet Kaydı (K8s dışında Eureka ve K8s Hizmet Kaydı)

• Ağ Geçidi (Spring Cloud Gateway)

• Kimlik Yönetimi / SSO (KeyCloak)

Bu yüksek seviyeli soyutlamaları (bir dizi hizmetten oluşan bir uygulama) sağlamak için, temel olarak Uygulama beklenen yapısını tanımlayan bir Uygulama Dağıtım Tanımlayıcısına ihtiyacımız var. Bu Dağıtım Tanımlayıcısı, uygulamanın nasıl oluşturulduğunu açıklar ve Uygulamanın UP (durum) olması için neyin gerekli olduğunu örtük olarak tanımlar.

Bu nedenle etkileşimin ilk adımı, bu yüksek seviyeli Dağıtım Tanımlayıcısını oluşturmaktır. Bu yüksek seviyeli Dağıtım Tanımlayıcısı, Activiti Bulut Yapı Taşlarını (Çalışma Zamanı Paketleri, Bulut Bağlayıcıları, Sorgu ve Denetim Hizmetleri vb.) Bir Uygulama yapısına eşler.

Bu Dağıtım Tanımlayıcısı, Dağıtım Tanımlayıcılarını bir dizin tarzında depolamak için bir yapıya sahip olan Yapılandırma Sunucusunun içinde yaşayacaktır. Diğer bir deyişle, Dağıtım Tanımlayıcı Dizini, Uygulamalar için mevcut Dağıtım Tanımlayıcılarına referanslar elde etmek için sorgulanabilen kullanılabilir Uygulama Dağıtım Tanımlayıcılarının bir listesine sahip olacaktır.

Bu Dağıtım Tanımlayıcıları, her Uygulamanın durumunu Hizmet Kaydı ile eşleştirmek için kullanılacaktır.

Sağlanan her Hizmetin, bu Dağıtım Tanımlayıcıları ile korelasyona izin verecek iki Meta Veriye sahip olması gerekir:

Activiti Bulut Uygulama Adı

Activiti Bulut Hizmet Türü

Bu iki bilgi parçası, Hizmet Kayıt Defteri içindeki Hizmet Eşgörünümü bilgilerine eklenirse, Uygulama Hizmeti, halihazırda konuşlandırılan hizmetler arasındaki ilişkiyi ilişkilendirebilir, doğrulayabilir ve izleyebilir.

Bir uygulamaya ait olmayan tüm hizmetlerin birlikte gruplanacağına dikkat edin.

Daha sonra Uygulama Hizmeti, konuşlandırılan uygulamaların miktarı ve ilgili durumları hakkındaki soruları yanıtlamak için Hizmet Kayıt Defteri ile etkileşimden sorumlu olacaktır.

Etkileşim dizisi aşağıdaki gibidir:

Uygulama Hizmetinin bir parçası olarak durum depolamanın bulunmadığına dikkat etmek önemlidir; tüm durum, Yapılandırma Hizmetindeki Dağıtım Tanımlayıcılarına ve Hizmet Kayıt Defterinde halihazırda dağıtılan hizmetlere göre oluşturulur.

Veri tipleri

Hizmetin ilk Taslağı olarak aşağıdaki Veri Türleri tanıtılacaktır.

Bu varlıklar ve veri türleri, altta yatan uygulamaya göre bağımsız olmalıdır. Bu Veri Türleri, Activiti Bulut Uygulamaları hakkında düşündüğümüzde dünya görüşümüzü temsil eder ve herhangi bir özel uygulama veya teknoloji yığını varsaymamalıyız.

• ApplicationDeploymentDirectory
  • ApplicationDeploymentEntry[]
• DeploymentDescriptor
  • applicationName
  • applicationVersion
  • serviceDeploymentDescriptors[]
    • Name
    • Version
    • ServiceType
• Application[]
  • Application
    • Name
    • Version
    • ProjectRelease
    • Realm (Security Group / IDM bindings)
    • Status
    • Services
      • URL (path??)
      • Configurations[]
        • Resources[]
      • ServiceType
      • Name (Descriptive name)
      • ArtifactName (artifact – maven / docker image)
      • Version
      • Status
• ServiceType -> Enum:  (Connector, Runtime Bundle, Audit, Query, Domain Service)
• ProjectRelease (Coming from Modeling Service)
• Status (UP, DOWN, PENDING, ERROR)
• Realm (TBD)

Proposed Endpoints

• GET /v1/deployments/directory -> list of applications that we want to deploy (static)
• GET /v1/deployments/{deploymentName} -> get deployment descriptor for a given app
• GET /v1/apps/ -> list of APPs names and link to app
• GET /v1/apps/{appName}/ -> get app info
• GET /v1/apps/{appName}/services
• GET /v1/apps/{appName}/services/{serviceName}/url
• GET /v1/apps/{appName}/services/{serviceName}/config

Evrim, Sürüm Yükseltme ve Veri Taşıma

Uygulamaların Runtime Bundles içermesini düşünüyorsak, bu Paketlerin gelecekteki sürümlere nasıl evrileceğini ve uygulama sürümünün içindeki Runtime Paketleriyle nasıl ilişkili olduğunu tanımlamamız gerekir. Çalışma Zamanı Paketleri, yalnızca İşlem Çalışma Zamanları değil, Çalıştırma Zamanları kümeleri için değişmez kapsayıcılar olarak tasarlandı.

Çok çeşitli senaryoları kapsadığımızdan emin olarak, bunun nasıl çalışacağına dair bazı genel senaryolar tanımlamamız gerekiyor. Geleneksel olarak BPM platformlarında kapsamak istediğiniz bazı farklı senaryolar vardır:

Aynı süreç tanımının farklı sürümleri arasında geçiş: Bu, örneğin: iki süreç sürümü tamamen farklıysa ve uçuş sırasındaki süreçlerin geçişi hiç mümkün değilse ne olur? Ayrıca, her bir örneğin manuel olarak incelenmesi ve taşınması gereken manuel geçiş kavramını da sunar.

Bir süreç tanımının iki farklı versiyonunu paralel olarak çalıştırmak, eski versiyonda daha fazla uçuş sırasında süreç kalmayana kadar, bu genellikle işlerin ters gidemeyeceğinden emin olmak için iyi bir yaklaşımdır, ancak bizi yönlendirme hakkında düşünmeye zorlar yeni işlem örnekleri oluşturmak için kullanılan mantık. * Bunun değişmezlik kavramıyla daha uyumlu bir yaklaşım olduğunu fark etmek ilginçtir *.

Bazen, ne yaparsanız yapın, yalnızca yeni bir Uygulama sürümünü dağıtmak ve veriler dahil eskisini unutmak istersiniz. Bu, geliştirme döngülerinde oldukça yaygındır. Temel olarak, uygulamanın mevcut sürümünü atmak ve veri geçişini gerçekten önemsemeden yeni bir sürümle değiştirmek istersiniz. Hızlı yineleme döngüleri istiyorsanız, bu gerekli olabilir.

Bu kategorilere göre aşağıdaki stratejiler önerilir:

Bakım: Aynı veri deposunu kullanın ve eskileri içeride tutarak işlem tanımlarının yeni sürümlerini ekleyin. Bu, mevcut Runtime Bundle'ın yeni sürümlerini oluştururken bazı uygulamalar gerektirecektir.

Taşıma: Yükseltme yapılırken bir dizi işlemin yürütülmesi gerekecektir, uçak içi işlem çıkarma ve enjeksiyon için uç noktalar sağlanmalıdır. Bu strateji, yürütmeleri bir ortamdan diğerine taşımak istediğimiz, temeldeki veri deposunun aynı olmadığı ve verilerin taşınması gereken durumlar için çok yararlı olacaktır.

Paralel: Uçuş işlemlerinin önceki sürümünü, tanımlandıkları Runtime Paketinde çalıştırmak ve yeni sürümü farklı bir Runtime Bundle örneğinde paralel olarak çalıştırmaya başlamak istiyorsunuz. Bir yönlendirme mekanizmasına ihtiyaç duyulacaktır ve eski sürümün ne zaman kapatılacağını kontrol etmek için bir kullanımdan kaldırma politikası gerekebilir.

Yok Et: Eski tanımı bir kenara atmak ve sadece yenisini çalıştırmak istiyorsunuz. Eski sürüm tarafından oluşturulan verileri umursamıyorsunuz.

Bu stratejilerin Runtime Bundle düzeyinde değil, uygulama düzeyinde tanımlanması gerektiğine dikkat edin, çünkü bu stratejiler Denetim ve Sorgu gibi diğer bileşenleri etkileyecektir. Tutarlılık, Uygulama Düzeyinde muhafaza edilmelidir.

Her strateji, bir DevOps kullanıcısı tarafından otomatikleştirilmesi veya tetiklenmesi gereken farklı bir eylem akışı (işlem hatları) uygulayacaktır. Bu hizmete herhangi bir boru hattına atıfta bulunulmaması gerektiğine, ancak kancaların mevcut olması gerektiğine dikkat edin.

(TBD Stratejileri örnekleri ve uygulama için planlama, öneriler ve yorumlar memnuniyetle karşılanmaktadır)

Diğer konular / Riskler / Açık Sorular

Uygulama Hizmetini, Activiti Cloud'a özgü bazı gereksinimlerimiz olduğu için oluşturuyoruz, ancak Kubernetes, Spring Cloud ve diğer topluluklar (JHipster gibi) bu gereksinimleri farklı açılardan inceliyorlar. Bu hizmetin geliştirilmesinin bir parçası olarak, bu toplulukları izlemeyi ve herhangi bir işlevi kopyalamadığımızdan emin olmak için onlarla işbirliği yapmayı taahhüt ediyoruz, bunun yerine, aynı çekirdek kitaplık setinden hepsinden yararlanmak için işbirliği yapıp önerdiklerini iyileştireceğiz ve altyapı.

Kubernetes Hizmet Kataloğu

Spring Cloud Açık Hizmet Aracısı

Kubernetes Uygulama Türü önerisi

Spring Cloud Deployers SPI (Uygulamalar yalnızca tek bahar önyükleme uygulamalarıdır) -> https://github.com/spring-cloud/spring-cloud-deployer

Hizmet Kaydı ve Yapılandırma Hizmeti arasındaki etkileşim nedeniyle, Spring Cloud saf uygulamaları için Hizmet Kaydı ve Yapılandırma Hizmetini diğer toplulukların yaptığı gibi bir araya getirebiliriz (http://jhipster.tech/). Aynı yaklaşımı izleyerek, fazladan konteynerlerin konuşlandırılmasını önlemek için Uygulama Hizmetini bu ikisiyle bir araya getirebiliriz.

K8'lere baktığımızda bu, Uygulama Hizmeti için K8s Hizmet Kaydı ve Yapılandırma Haritaları ile etkileşime girecek bir kapsayıcıya ihtiyaç duyacağımız anlamına geliyor ve bu hizmeti Ağ Geçidi kapsayıcısı ile paketleyebilir miyiz sorusunu gündeme getiriyor.

ApplicationDeploymentDescriptors ile Kubernetes Deployment Descriptors (YAML dosyaları) ve HELM Charts gibi gerçek dağıtım tanımlayıcıları arasındaki ilişki etrafında bazı araştırmalar yapılmalıdır. Activiti Bulut görünümü ile hizmetleri sağlamak için kullanılan gerçek dağıtım tanımlayıcıları arasında bir iz olması önemlidir. Bu nedenle, Monocular (https://github.com/kubernetes-helm/monocular) ve burada açıklanan hizmetler arasındaki ilişkilere bakmak önemlidir. Ayrıca, bu senaryoları BPM'ye özgü olmayan bir şekilde çözmek için halihazırda tasarlanmış HELM veya benzer teknolojiler olarak sürüm oluşturma ve yayınlamalarla başa çıkmak için benzer uygulamaları takip ettiğimizden emin olmak da önemlidir.

Referanslar

Github Sorunları

Incubator Project

Original Document in Google Docs open for Comments.

https://salaboy.com/2018/04/11/rfc-activiti-cloud-application-service/