Activiti 7 ürününü dağıtırken ve kullanırken karşılaşacağınız kavramların (terimlerin) ve teknolojilerin bir listesi bulunmaktadır.

Giriş

Activiti 7, bir bulut ortamında çalışmak üzere bina edilmiş, Alfresco'nun war'ında test edilmiş Activiti iş akışı motorunun bir evrimidir. Cloud Native uygulama konseptlerine göre oluşturulmuştur ve nasıl tasarlandığı açısından önceki Activiti sürümlerinden biraz farklıdır. Ayrıca, ayrı bir makalede inceleyeceğimiz yeni bir Activiti Modeler'a da sahi .

Activiti 7 motorunun özü hala önceki sürümlerle aynıdır. Ancak, çok daha dar bir şekilde tek bir işi yapmaya ve bunu şaşırtıcı derecede iyi yapmaya odaklanmış ve bu da BPMN iş süreçlerini yürütmek için yapılmıştır. Activiti çalışma zamanında yerleşik yardımcı işlevler, motor tarafından üretilen ve Motorun veritabanında depolanan Sorgu ve Denetim verileri için API çalışma zamanı talebine hizmet vermeyi içerir, motordan çıkarıldı ve her biri çalışan Spring Boot 2 mikro hizmetleri olarak çalışacak şekilde yapıldı kendi yüksek ölçeklenebilir kapları.

Activiti motorunun çekirdek kitaplıkları da sürüm 7 için yeniden tasarlandı, bunlara başka bir makalede göz atacağız.

Bu makale, Activiti 7 uygulamalarınızı Docker konteynerleri ve Kubernetes kullanarak bir bulut ortamında nasıl kolayca dağıtabileceğinizi ve çalıştırabileceğinizi anlatıyor. Activiti 7 ile birlikte kullanılan birçok yeni teknoloji ve kavram var, bu yüzden ilk önce buna bir göz atacağız.

Activiti 7 Derin Dalış Makale Serisi

Bu makale, Activiti 7'yi ayrıntılı olarak ele alan makaleler dizisinin bir parçasıdır, bunlar sırayla okunmalıdır:

• Bir İş Sürecini Dağıtma ve Çalıştırma

• Bir İş Süreci Tasarlamak için Modelleyiciyi Kullanma

• Özel Bir İş Süreci Oluşturma, Dağıtma ve Çalıştırma

• Çekirdek Kitaplıklarını Kullanma

Ön koşullar

Docker kurulu olmalı. Kubernetes paketli olarak gelen daha yeni bir Docker sürümüne ihtiyacınız var.

Kavramlar ve Teknolojiler

Aşağıda, Activiti 7 ürününü dağıtırken ve kullanırken karşılaşacağınız kavramların (terimlerin) ve teknolojilerin bir listesi bulunmaktadır.

Sanal Makine Monitörü (Hiper Yönetici)

Yerel ana makinenizde diğer işletim sistemi örneklerini çalıştırmak için bir Hiper Yönetici kullanılır. Tipik olarak, makinenizde Mac'te Windows gibi farklı bir işletim sistemi çalıştırmak için kullanılır. Ana makinenizde başka bir işletim sistemi çalıştırdığınızda, buna konuk işletim sistemi denir ve sanal makine (VM) olarak adlandırılan bir işletim sisteminde çalışır.

Image

Bir görüntü, bir konteyneri başlatmak için kullanılabilen bir dizi yazılım katmanıdır. Bir uygulamayı çalıştırmak için gereken her şeyi içeren hafif, bağımsız, yürütülebilir bir yazılım paketidir: kod, çalışma zamanı, sistem araçları, sistem kitaplıkları ve ayarlar. Bu, örneğin Java + Apache Tomcat olabilir. Docker Hub adı verilen herkese açık depoda her türlü Docker Görüntüsünü bulabilirsiniz. Ayrıca Alfresco'nun kullandığı Quay adında olduğu gibi özel görüntü depoları da vardır (ticari kurumsal görüntüler gibi şeyler için).

Bir image salt okunurdur ve değişmez.

Konteyner

Bir görüntünün bir örneğine kap adı verilir. Açıklandığı gibi bir dizi katman olan bir görüntünüz var. Bu görüntüyü başlatırsanız, bu görüntünün çalışan bir konteynerine sahip olursunuz. Aynı görüntünün birçok çalışan kabına sahip olabilirsiniz. Bir konteyner çalışırken, siz konteyneri çalıştırırken şeylerin depolandığı bir okuma-yazma katmanı oluşturulur. Kap kaldırılırsa, okuma-yazma katmanındaki her şey de kaldırılır. Bazı verilerin kalıcı olmasını istiyorsanız, Birim adı verilen şeyi kullanmanız gerekir.

Docker

Docker, en popüler konteyner platformlarından biridir. Docker, görüntüleri temel alan kapsayıcılarda uygulamaları dağıtmak ve çalıştırmak için işlevsellik sağlar.

Docker Oluşturma

Activiti 7 gibi çözümünüzü oluşturan çok sayıda konteynırınız olduğunda ve her bir konteyneri birlikte güzel bir şekilde çalışacak şekilde yapılandırmanız gerektiğinde, bunun için bir araca ihtiyacınız vardır.

Docker Compose, çok kapsayıcılı Docker uygulamalarını tanımlamak ve çalıştırmak için böyle bir araçtır. Compose ile, uygulamanızın hizmetlerini yapılandırmak için bir YAML dosyası kullanırsınız. Ardından tek bir komutla tüm hizmetleri yapılandırmanızdan oluşturup başlatırsınız.

Dockerfile

Dockerfile, yeni bir Docker görüntüsü oluşturmak için yürütülecek ardışık bir dizi talimat, yön ve komut içeren bir komut dosyasıdır. Yürütülen her komut görüntüdeki yeni bir katmana çevrilerek son ürünü oluşturur. Her şeyi elle ve tekrar tekrar yapma sürecini değiştirirler. Bir Dockerfile'ın çalıştırılması bittiğinde, yeni bir imaj oluşturmuş olursunuz ve bu imajı yeni bir Docker konteyneri başlatmak için kullanırsınız.

Kapsayıcılar ve Sanal Makineler Arasındaki Fark

Kapsayıcı kullanmakla VM kullanmak arasındaki farkı anlamak önemlidir. İşte bunu gösteren bir resim:

Temel fark, bir kapsayıcı çalıştırırken tamamen yeni bir işletim sistemi örneğini başlatmamanızdır. Bu da kapları çok daha hafif ve daha hızlı başlatır. Bir konteyner aynı zamanda tüm işletim sistemini taşıması gerekmediği için sabit diskinizde çok daha az yer kaplıyor.

Temel fark, bir kapsayıcı çalıştırırken tamamen yeni bir işletim sistemi örneğini başlatmamanızdır. Bu da kapları çok daha hafif ve daha hızlı başlatır. Bir konteyner aynı zamanda tüm işletim sistemini taşıması gerekmediği için sabit diskinizde çok daha az yer kaplıyor.

Cluster (Küme)

Bir küme, küme içinde çalışan iş yüklerini ve süreçleri desteklemek için kaynakların bir arada kümelendiği sunuculardan (bir veya daha fazla kapsayıcıya sahip düğümler) oluşan paylaşılan bir bilgi işlem ortamı oluştur:

Kubernetes

Docker, konteynerleri tek bir ana bilgisayarda çalıştırmak için harikadır ve bu amaç için gerekli tüm işlevselliği sağlar. Ancak günümüzün dağıtılmış hizmetler ortamında gerçek zorluk, sunucular ve karmaşık altyapılar genelinde kaynakları ve iş yüklerini yönetmektir.

Bugün bunun için en çok kullanılan ve desteklenen araç, orijinal olarak Google tarafından oluşturulan ve ardından açık kaynak haline getirilen Kubernetes'tir (Yunanca "dümenci" veya "pilot" anlamına gelen bir kelime). Kelimeden de anlaşılacağı gibi Kubernetes, birçok yararlı özelliği kullanarak kapsayıcıları (containers) birçok düğümde (nodes) düzenlemek için zahmetli bir görevi üstlenir. Kubernetes, bir kümedeki uygulama kapsayıcılarını çalıştırmak (operate application containers in a cluster), ölçeklendirmek ve çalıştırmak için kullanılabilen açık kaynaklı bir platformdur.

Kubernetes birkaç mimari bileşenden oluşur:

Kubernetes Worker Node - bir veya daha fazla kapsayıcı çalıştıran bir küme düğümü.

Kube Proxy - düğümde konuşlandırılan hizmetlere harici erişimi kolaylaştırır, diğer düğümlere yönlendirebilir.

Kubelet - kubelet, birincil düğüm aracısıdır. Düğüm için istenen durumun korunmasını sağlar. Bu, düğümde çalışacak şekilde planlanan kapsayıcıların çalıştığından emin olur.

Pods (Bölmeler) - bu, Kubernetes Nesne Modelinde (sonraki bölüme bakın) dağıtılabilen en küçük birimdir. Kümede çalışan bir süreci temsil eder. Bir bölme bir uygulama kabını kapsüller ve Docker en çok kullanılan kapsayıcı çalışma zamanıdır.

Labels (Etiketler) - kapsüller dahil Kubernetes nesnelerine eklenen meta veriler.

Kubernetes Master Node

API Sunucusu - kümenin paylaşılan durumuna ön uç. Tüm bileşenlerin kullandığı bir ReST API sağlar.

Replication Controllers (Çoğaltma denetleyicileri) - kümenin durumunu düzenler. Yapılandırılabilir sayıda kapsülün çalıştığından emin olmak için bir kapsül şablonundan yeni kapsül "eşlemeleri" oluşturur.

Scheduler (Zamanlayıcı) - atanmış düğüm atanmamış yeni oluşturulan bölmeleri izleyerek iş yükünü yönetir ve üzerinde çalışacakları bir düğüm seçer.

Kubectl - Kubernetes kümesini komut satırından kontrol etmek ve yönetmek için kubectl adlı bir araç kullanacağız. Kubernetes Ana Sunucusundaki API Sunucusuyla konuşur ve bu da ayrı Kubernetes düğümleriyle iletişim kurar.

Hizmetler, etiket güdümlü seçiciler kullanarak istekleri kümedeki mantıksal bir kapsül arka uç kümesine yönlendirmek için düşük ek yük sağlayan bir yol sunar.

Kubernetes'e benzeyen Docker Swarm'ı da duymuş olabilirsiniz.

Kubernetes Nesneleri

Kubernetes ile çalışırken farklı türden şeyler oluşturulacak, dağıtılacak, yönetilecek ve yok edilecek. Bunlara genellikle kaynaklar olarak da adlandırılan nesneler diyebiliriz. Kubernetes Nesne Modelinde bilinmesi iyi olan birkaç farklı nesne türü vardır. Aşağıdaki resim, karşılaşmanız muhtemel olan bu nesnelerden bazılarını göstermektedir:

Bu nesnelerin bazıları zaten tanıdık geliyor, gerisini açıklayan bir liste:

Container - uygulamamız bir Docker container ile konuşlandırılmıştır.

Volume - uygulamamız, fiziksel depolamaya işaret eden bir birim aracılığıyla kalıcı verileri depolayabilir.

Pod (Kapsül) - bir veya daha fazla kap içerir ve kısa ömürlüdür. Sürekli yükseleceği garanti edilmez. Bölme başına bir kabın olması yaygındır. Bir bölmenin benzersiz bir IP adresi vardır, bu nedenle Docker kapsayıcılarında yaptığınız gibi tipik bağlantı noktası çakışması sorununa sahip olmazsınız.

ReplicaSet - bir dizi çoğaltılmış bölmeyi yönetir. Her zaman doğru sayıda kopya çalıştığından emin olmak.

Dağıtım - bölmeler, çoğaltma yönetimi, ölçeklendirme, sıralı güncellemeler, geri alma, temizleme vb. Sağlayan dağıtımlar kullanılarak planlanır. Bölmelerle Çoğaltma Kümelerini kontrol ettikleri için bunlara denetleyici nesneleri denir.

Hizmet - bir mikro hizmet sağlayan bir dizi kapsülü tanımlar. Kümedeki geçici (kısa ömürlü) kapsüller için kararlı bir sanal uç nokta sağlar. Bir hizmet IP adresi kalıcıdır ve değişmez. Bir hizmete kendi adı (dns) üzerinden de ulaşabilirsiniz. Bir dizi farklı hizmet türü vardır: Kubernetes kümesi içinde iletişim için kullanılan Küme IP'si (varsayılan), bir hizmeti harici olarak bir düğüme sunmak için kullanılabilen NodePort ve son olarak hizmeti Bulut tabanlı bir şekilde sunacak olan LoadBalancer örneğin AWS'den yük dengeleyici.

Ingress - bir veya daha fazla hizmet için genel erişim noktası. Kubernetes Kümesi dışında açığa çıkarılması gereken birden fazla hizmet uç noktanız olduğunda, tüm bu hizmetler için LoadBalancer türü hizmeti kullanmak pahalı olabilir (her biri için bir bulut yük dengeleyici oluşturulacaktır) ve birleştirilmiş erişimi yönetin. Ingress, HTTP trafiği için yerleşik Kubernetes yük dengeleme çerçevesidir. Bir Giriş ile, harici trafiğin yönlendirilmesini ve tüm yapılandırmasını Kubernetes YAML'nizde kontrol edersiniz.

ConfigMap - kapsüller / kapsayıcılar için ad ve değer çifti özellik yapılandırması.

Secret - gizli olması gereken kapsüller / kapsayıcılar için ad ve değer çifti özellik yapılandırması (yani düz metinde gösterilmemelidir). Bu, genellikle parolalar ve belirteçler gibi yapılandırmadır.

Namespace - bir ad alanındaki tüm nesne adları, başka bir ad alanındaki nesne adlarıyla çakışamaz. Ad alanlarının kullanımı tam izolasyon sağlar ve çok kiracılı gereksinimleri veya paralel olarak çalışan birden çok ekibi ele almak için idealdir.

Kubernetes YAML

Activiti gibi bir uygulamanın istenen durumunu açıklamak için bir Kubernetes kümesinde oluşturulan nesneler, YAML adı verilen bir formatta tanımlanır.

Helm

Bu nedenle, çalışır durumda bir Kubernetes kümemiz var ve artık konteyner dağıtımları için hazır. Bunu verimli bir şekilde nasıl hallederiz? Veritabanı katmanı, uygulama katmanı, web katmanı, arama katmanı vb. Şeyler için çok sayıda konteynırımız olabilir. Ayrıca ölçeklenebilirlik ve yük devretme için farklı konfigürasyonlara sahip olmaları gerekir. Kulağa oldukça karmaşık geliyor ve dağıtımın ihtiyaç duyacağı tüm nesneleri / kaynakları (yani bölmeler, hizmetler, dağıtımlar, yapılandırma haritaları, secrets vb.) Tanımlamak için çok sayıda Kubernetes YAML gerektirecek.

Bununla birlikte, Helm adlı bir araç biçiminde yardım var. Kubernetes kümeleri için bir paket yöneticisidir. Bununla birlikte, tüm Kubernetes YAML'lerimizi bir araya getirebilir ve bir sürüm olarak doğru sırayla dağıtılmasını sağlayabiliriz. Helm Paketi tanımı Helm Chart olarak adlandırılır. Her chart, aşağıdakileri listeleyen veya tanımlayan bir dosya koleksiyonudur:

• Şablon biçiminde dağıtılması gereken Kubernetes YAML dosyaları.

• Farklı Kubernetes nesnelerinin / kaynaklarının yapılandırması. Böylece, UAT, STAGING ve PRODUCTION gibi farklı ortamlara dağıtımı kolaylaştırmak için YAML dosyalarınızın farklı özellikleri için değerleri özelleştirebilirsiniz.

• Diğer Helm haritalarına bağımlılıklar.

Diğer önemli Helm kavramları:

Release - Kubernetes'e yüklenen bir grafik örneği.

Helm Repo - yayınlanan çizelgelerin deposu. Kubernetes.io'da halka açık bir repo var bu kuruluşların kendi depoları olabilir. Örneğin Alfresco'nun kendi chart repo'su var.

Şablon - Go şablonlama diliyle yazılmış bir Kubernetes yapılandırma dosyası (Sprig işlevlerinin eklenmesiyle)

Helm Charts, JAR'ların örneğin Maven Central'da depolandığı gibi, bir Helm deposunda saklanır. Yani Helm aslında hem bir İstemci biti hem de bir Sunucu bitinden oluşur. Helm'in sunucu biti Tiller olarak adlandırılır ve Kubernetes kümesinde çalışır. Helm mimarisi şuna benzer:

Helm yalnızca bir paket yöneticisi değil, aynı zamanda şunları yapabilen bir dağıtım yöneticisidir:

• Tekrarlanabilir dağıtımlar yapın

• Bağımlılıkları yönetin: yeniden kullanın ve paylaşın

• Birden çok yapılandırmayı yönetin

• Uygulama dağıtımlarını güncelleyin, geri alın ve test edin (sürümler olarak anılır)

Activiti 7 çözümü Helm ile paketlenmiştir ve Activiti, Activiti 7 bileşenleriyle ilgili Grafikler içeren bir Helm deposu sağlar.

Minikube

Minikube, Kubernetes'i yerel olarak çalıştırmayı kolaylaştıran bir araçtır. Minikube, dizüstü bilgisayarınızdaki bir sanal makinenin içinde tek düğümlü bir Kubernetes kümesi çalıştırır. Öncelikle Kubernetes'i denemek veya bir geliştirme ortamı olarak kullanmak isteyen kullanıcılar içindir.

Kubernetes ile birlikte gelen en yeni Docker for Desktop ortamını kullanacağız, bu yüzden Minikube'u kurmaya gerek yok.

Bulutta Yerel Uygulamalar

Activiti 7'nin nasıl tasarlandığını, oluşturulduğunu ve çalıştırıldığını anlamak için Cloud Native uygulamaları hakkında biraz bilgi sahibi olmak yararlıdır. Bir örnekle açıklamaya çalışalım. Yaklaşık 10 yıl önce Netflix, müşterilerin sadece bir düğmeyi tıklayıp çevrimiçi bir film izleyebilecekleri bir gelecek düşünüyordu. Artık DVD olmayacaktı. İnsanlara DVD göndermek sadece küresel ölçekte ölçeklenmiyor, istediğiniz şeyi istediğiniz yerde izleyemezsiniz, sadece posta yoluyla gönderebileceğiniz çok fazla DVD vardır, DVD'ler zarar görebilir vb. Netflix'in de sınırlı yolları vardır. yeni filmleri müşterilere verimli bir şekilde önermek.

Bu yeni çevrimiçi yayın hizmetini uygulamak için Netflix'in yeni bir çevrimiçi hizmet türü oluşturması gerekir.

Web ölçeği - hem hizmetler hem de bilgi işlem gücü olmak üzere her şey dağıtılır. Sistem, hata izolasyonu ve dağıtılmış kurtarma ile kendi kendini onarır. API güdümlü otomasyon olacaktır. Aynı anda çalışan birden çok uygulama.

Küresel - film hizmetinin, nerede olursanız olun, anında küresel ölçekte erişilebilir olması gerekir.

Yüksek erişilebilirlik - bir filmi görmek için bir düğmeyi tıkladığınızda sadece çalışır, aksi takdirde müşteriler hizmeti benimsemez

Tüketiciye dönük - çevrimiçi hizmet, müşterilerle evlerinde doğrudan yüz yüze olmalıydı.

Netflix'in gerçekten istediği şey, hız ve geniş ölçekte erişimdi. Film sitesinin her zaman açık olması, her zaman erişilebilir olması ve neredeyse hiç kesinti olmaması gerekiyordu. Tüketici olarak teknik sorunlar nedeniyle film izleyemeyeceğinizi kabul etmezsiniz. Ayrıca, tüketici ihtiyaçlarına göre yeni özellikler eklemek için çalışırken ürünlerini sürekli olarak değiştirmek zorunda kalacaklarını da biliyorlardı. Temelde daha iyi ve daha iyi, daha hızlı ve daha hızlı olmaları gerekirdi. Ve bu, Cloud Native uygulamalarının anahtarıdır.

Öyleyse, her zaman çevrimiçi görünen ve sürekli olarak yeni özellikler ekleyip sunabilen bir uygulama sunmanızı sağlayan Cloud Native nedir? Aşağıda, Bulut Yerel uygulamalarının bazı özellikleri verilmiştir:

Modülerlik - uygulamalar artık tüm işlevselliğin tek bir büyük uygulamada toplandığı tek parça olamaz. Her uygulama işlevinin, mikro hizmet olarak adlandırılan bağımsız bir hizmet olarak sunulması gerekir. Netflix söz konusu olduğunda, monolitik bir DVD kiralama uygulaması üreten 100 mühendisin geleneksel bir geliştirme modelinden, birlikte çalışan yüzlerce mikro hizmetin uçtan uca geliştirilmesinden sorumlu birçok küçük ekibin bulunduğu bir mikro hizmet mimarisine geçişi göreceklerdir. her gün milyonlarca Netflix müşterisine dijital eğlence akışı gerçekleştirin.

Gözlemlenebilirlik - tüm bu mikro hizmetlerle sorunları tespit etmek için onları sürekli izlemek ve ardından hizmetlerin yeni örneklerini anında başlatmak önemlidir, böylece tüm uygulama her zaman çalışıyormuş gibi görünür.

Dağıtılabilirlik - uygulamayı bir dizi mikro hizmet olarak sunmak, bu küçük hizmetleri hızlı ve sürekli bir şekilde dağıtmanıza olanak tanır. Ayrıca, uygulamanın farklı bölümlerinde bağımsız olarak yükseltme yapabileceğiniz ve bakım yapabileceğiniz anlamına gelir. Hizmetler ayrıca Docker kapsayıcıları olarak dağıtılır, bu da işletim sisteminin soyutlandığı anlamına gelir.

Test edilebilirlik - sürekli teslimat yapılırken, tüm testlerin otomatik olması önemlidir, böylece yeni özellikleri olabildiğince çabuk sunabiliriz.

Tek kullanımlık - bir uygulamadaki özellik veya işlevden kurtulmak çok kolay olmalıdır. Tüm temel işlevler bağımsız olarak mikro hizmetler olarak sunuluyorsa bu kolaydır.

Değiştirilebilirlik - uygulamayı oluşturan özellikleri ne kadar kolay değiştirebiliriz. Özelliklerin atılması ve yenileriyle değiştirilmesi kolaysa, uygulama müşterilerin yeni gereksinimlerine göre çok esnek olabilir.