Nesnelerin İnterneti (IoT) her geçen gün daha kolay hale geldi. İşlemeyi uç cihaza taşıma işlemi, düşük gecikmeli bağlantı ve bant genişliğinin korunması gibi ihtiyaçları karşılamak için önemli bir model olarak görev gösterir. Bu durum özellikle hareketlilik içeren ve genellikle aralıklı ve düşük bant genişliğine sahip bağlantı ile ortaya çıkan senaryolarda doğrudur. Yazılım kapsayıcısı görüntülerini dağıtarak genellikle uç cihazlar hazırlarsınız, dağıtım işlemleri kesintileri mobil senaryolarda hatalara neden olabilir. Sonuç olarak, sınırlı, aralıklı veya düşük bant genişliğine sahip durumlar için güvenilir ve dayanıklı bir dağıtım özelliğine ihtiyacınız olabilir.
Bu çözüm, docker kapsayıcılarının müşterinin IoT uç platformundan uydu gibi aralıklı düşük bant genişliğine sahip internet bağlantılarında heterojen uzak IoT cihazlarına dağıtımını etkinleştirdi. CSE ekibi bunu her cihaza dağıtımın boyutunu en aza indirerek ve bu dağıtımların güvenilir bir şekilde izlenmesini sağlayarak gerçekleştirdi.
Olası kullanım örnekleri
Bu çözüm, yazılım kapsayıcılarının çözümün bir parçası olarak kullandığı ve bağlantının aralıklı olarak düşük bant genişliğine sahip olduğu tüm senaryolar için uygundur. Örnekler şunlardır:
Mobil senaryolar
Havadan otomobil güncelleştirmeleri
Petrol ve doğalgaz ve madencilik
Retail
Güçlü bir bağlantının garanti edilemez olduğu her yerde
Mimari
Yüksek bant genişliğine sahip senaryolarda Azure IoT Edge, docker hub'ı veya Azure Container Registry (ACR)gibi özel bir Docker kayıt defterinden görüntüleri doğrudan çeker. Bu, yerel makineden "docker pull image_name " <> komutunu çalıştırmayla aynı işlevselliktir.
Ancak, uydu internet bağlantısı gibi aralıklı olabilecek ağ erişimiyle çalışmaya zorlanan Docker çekme yöntemi güvenilmez hale gelir. Özellikle, Docker görüntüyü çekme sırasında internet bağlantısı düşerse ilerleme durumu önbelleğe alınmaz. Bu nedenle İnternet bağlantısı devam edinca Docker'ın görüntüyü en baştan çekmesi gerekir.
Aşağıdaki bölümlerde, aralıklı bağlantının neden olduğu sınırları telafi eden alternatif bir dağıtım mekanizması açıklanmaktadır.
Aşağıdaki diyagramda bu çözümün üst düzey mimarisi gösterilmiştir.
Tasarım gereksinimleri
Müşterinin aralıklı olarak düşük bant genişliğine sahip bulut bağlantısını destekleyen bir çözüme ihtiyacı vardı. Bu çözüm, dağıtılan uygulamaların yerel olarak çalışmaya devam gereksinimlerini karşılar ve yerel personelin bulut gidiş dönüş gecikmesi olmadan ve çevrimdışıyken işlevselliği kullanmasına olanak tanımıştı. Buluta bağlandıktan sonra çözüm, ürünler arasında tutarlı bir şekilde tanımlanan iş kurallarına göre veri gönderme önceliklerini belirlemek için bulut bağlantısını verimli bir şekilde kullanmak için gereklidir.
CSE ekibi, görüntü dosyalarının ikili düzeltme eki uygulama için aşağıdaki ayrıntılı gereksinimleri belirledi:
Görüntü dosyaları düşük bant genişliğine (1Mbit/sn) ve aralıklı bağlantı uydu bağlantısına aktarılmış olması gerekir.
Aktarılan verilerin mümkün olduğunca en aza indirilmesi gerekir.
Müşteri, dosyaları cihazlara aktarmak için üçüncü taraf bir uygulamayı kullanmaya devam etmek tercih eder.
Bir cihazdaki iş yükleri, Docker IoT Edge bir cihazda çalıştıracak.
Görüntü boyutu onlarca MB ile birkaç GB arasında olacaktır (Windows görüntülerin boyutu yaklaşık 5,5 GB'tır).
IoT Edge modülleri .NET Core 2.2'de yazacak.
Bileşenler
Azure
Üçüncü taraf
Açık kaynak
Örnek kullanım örneği
Büyük bir lojistik şirketi, aralıklı olarak düşük bant genişliğine sahip bulut bağlantısı olan coğrafi alanlar aracılığıyla bile dünya genelindeki ürün sevkiyatlarının takibini geliştirmek istedi. Ürün sevkiyatları, gönderilen ürünlerin türüne bağlı olarak sigorta, güvenlik veya izleme amacıyla çeşitli IoT cihazları yükledi. Bu cihazların GPS izleyicileri, sıcaklık algılayıcıları ve diğer ilgili veri noktalarını yakalamak için kullanılan araçlar gibi özellikleri bir cihazdan diğerine değişiklik gösterir; ve ürünler çeşitli taşıma yöntemleri (örneğin, yer, hava ve deniz) ve çok çeşitli uzak bölgelere gönderebilirsiniz.
Çözüm, sınırlı bağlantı ortamlarında sağlama işleminin güvenilirliğini ve güvenilirliğini önemli ölçüde artırmıştır. Aşağıdaki tartışmada seçenekler değerlendirme süreci, CSE ekibinin bu müşteri için geliştirdiği çözümün ayrıntıları ve bu çözümün yararlı olabileceği diğer senaryolar açıklanmıştır.
Müşteri senaryosu
Müşteri yakın zamanda geliştirilen IoT Edge platformu üzerinden cihazlarını güncelleştirme sorunlarıyla karşılandı. CSE, aşağıdaki önemli sorun noktalarını ele almak için müşteriyle birlikte bir ekip yaptı:
Cihazlara güncelleştirilmiş yazılım dağıtırken yüksek bant genişliği tüketimi.
Cihazlar arasında standartlaştırılmış otomatik dağıtım yoktur ve hangi cihazların hangi güncelleştirmelere sahip olduğunu bilmek için bir yol yoktur.
Teknoloji seçiminde sınırlı esneklik.
Çözüm değerlendirmesi
CSE tarafından değerlendirilen dört olası çözümden birden fazlası uygulanabilir ve kullanılabilir durumdadır. CSE, ideal çözüm olarak tam bir Docker görüntüsü veri aktarımı belirledi.
Değerlendirme ölçütleri
CSE aşağıdakilere dikkat etti:
Çözümün gereksinimleri karşılama becerisi
- Evet, Hayır
IoT cihaz karmaşıklığı (cihazlarda ne kadar mantık uygulanması gerekiyor)
- Düşük, Orta, Yüksek
Azure karmaşıklığı (Azure'da uygulanması gereken mantık boyutu)
- Düşük, Orta, Yüksek
Bir görüntüyü aktarmak için bant genişliği verimliliği (aktarılan verilerin toplam görüntü boyutuna oranı):
Cihazda görüntü yok.
Cihazda aynı temel görüntüye sahip bir görüntü vardır.
Cihazda uygulamanın önceki bir sürümünü temsil eden görüntü.
Temel görüntünün önceki bir sürümünü temel alan uygulamanın görüntüsü cihazdadır.
Bant genişliği verimliliği değerlendirmeleri için, CSE aşağıdaki kümeleri temsil eden görüntüleri kullandı.
| Senaryo | Açıklama |
|---|---|
| Yeni Görüntü Aktarma – Temel Katman Zaten Cihazda | Cihazda temel görüntüyü paylaşan başka bir görüntü varken yeni bir görüntüyü aktarma. Bu, yeni bir uygulamayı ilk kez dağıtmayı temsil ederken aynı işletim sistemi ve çerçevede başka bir uygulama var. |
| Uygulama Katmanına Güncelleştirme | Yalnızca mevcut bir uygulamanın görüntüsünün kodunu değiştirme. Bu, bir kullanıcı yeni bir özellik işlerken tipik bir değişikliği temsil eder. |
| Temel Görüntüye Güncelleştirme | Uygulamanın yerleşik olduğu temel görüntünün sürümünü değiştirme. |
Dört seçeneğin kısa açıklaması ve bunların arasındaki takaslar aşağıdaki gibidir.
Çözüm için dikkate alınacak değerlendirme seçenekleri
Docker katmanlarını aktarma
Görüntü, kapsayıcı çalışırken yapılan değişiklikler için ek yazılabilir bir katmanla salt okunur olan çeşitli dosya sistemi farklılıklarının BirLeştirilebilir Dosya Sistemi bağlamasıdır. Bu çeşitli dosya sistemleri temelde yalnızca klasörlerve dosyalar olan katmanlar olarak bilinir. Katmanlar, kapsayıcının kök dosya sisteminin tabanını oluşturmak için yığılmış. Katmanlar salt okunur olduğu için, çeşitli görüntüler ortak katmana sahipse aynı katmanı paylaşabilir.
Bu çözümde görüntüler arasındaki katmanlar yeniden kullanılır, bu nedenle yalnızca yeni katmanları cihaza aktarmanız gerekir. Bu en yaygın olarak aynı temel katmanı (genellikle Ubuntu veya Alpine gibi işletim sistemi) veya mevcut görüntülerin güncelleştirilmiş sürümlerinin yer alan görüntülerde paylaştırır.
Bu yöntemin karşıtları şunlardır:
Orchestrator'da hangi cihazların korunması gerektiğinin hangi katmanlarda mevcut olduğu hakkında bilgi.
Temel katman değişiklikleri, sonraki tüm katmanların karmaları değişmeye neden olur.
Karşılaştırmak için tutarlı katman karmalarının olması gerekir.
Docker Save ve Docker Load bağımlılığı ortaya çıkarabilir.
Değiştirilen Docker istemcisi
Bu çözüm, Internet bağlantısı kesintiye uğradığında katman indirmeyi devam ettirir böylece Docker istemcisinin değiştirilmesine veya sarmalanmasına odaklanılır. Varsayılan olarak, internet bağlantısı kesilmediğinde yaklaşık 30 dakika içinde geri yüklenirse bir Docker çekme işlemi bir indirmeyi sürdürür. Aksi halde, istemci kapanır ve tüm indirme ilerlemeleri kaybolur.
Bu, uygun bir çözümdür ve aşağıdakiler de dahil olmak üzere karmaşıklıklar içeriyordu:
Cihazdaki tüm görüntülerin, bant genişliği verimliliğini en üst düzeye çıkarmak için görüntüleri çekmesini sağlamak için gereken tüm görüntüler.
Açık kaynaklı Docker projesinin, bu değiştirilmiş işlevselliği desteklemesi için değiştirilmesi gerekir ve teklif açık kaynaklı bakım yapanlar tarafından reddedilirse projeye bir risk sunma.
Veriler, müşterinin sık kullanılan hızlı dosya aktarım çözümü yerine HTTP üzerinden aktarılır ve bu da özel yeniden deneme mantığının geliştirilmesini gerektirir.
Bir temel görüntü değiştirildiğinde yeniden aktarılan tüm katmanların yeniden yapılması gerekir.
Kenarda
Bu yaklaşım, görüntü derleme ortamını her cihaza taşımalıdır. Bu senaryoda, aşağıdaki veriler cihaza gönderilir:
Oluşturulmakta olan uygulamanın kaynak kodu
kodun bir bağımlılığı olan tüm NuGet paketlerinin bir kopyası
.NET Core derleme ortamı ve çalışma zamanı için Docker temel görüntüleri
Son görüntünün nasıl görüneceğine ilişkin meta veriler
Sonra cihazdaki bir yapı Aracısı görüntüyü oluşturur ve cihazı Docker Manager 'a kaydeder.
Bu çözümün reddedilme nedeni:
Büyük Docker görüntülerini cihaza taşımanın bir yolu olması gerekir. .NET uygulamasını derlemek için resimler, bunları çalıştırdıklardan daha büyüktür.
Bu yöntem yalnızca ekibin kaynak kodu elinde bulunduğu .NET Core uygulamaları için çalışır ve üçüncü taraf görüntüler kullanılıyorsa hiçbir avantaj gerçekleştirilmeyecektir.
NuGet paketlerini cihaza taşımak ve izlemek için gereken bir durum oluşturur.
Bir görüntü cihazda oluşturulamazsa, ekip derleme ortamında ve oluşturulmuş görüntüde, potansiyel olarak sınırlı bir internet bağlantısı üzerinden geçiş yapmak için çok sayıda telemetri olan oluşturulan görüntüde uzaktan hata ayıklaması yapmak zorunda olur.
Tam görüntü Delta aktarımı
Bu yaklaşım, Docker görüntüsünü tek bir ikili dosya olarak değerlendirir. Bu, görüntüyü bir. tar dosyası olarak dışa aktarmak için Docker Save komutu kullanılarak elde edilir. İki Docker görüntüsünü dışarı aktararak, uygulandığında bir görüntüyü diğerine dönüştüren ikili Delta değerini hesaplayabiliriz.
Bu çözümde, cihazlarımızda var olan Docker görüntülerini izliyoruz ve var olan bir görüntüyü dağıtılmakta olan yeni görüntüye dönüştürmek için ikili değişimleri oluşturacağız. Bu şekilde, yalnızca düşük bant genişliğine sahip internet bağlantısı üzerinde Delta aktaracağız.
Değerlendirme sonucu
Aşağıdaki tabloda, ilk bölümden değerlendirme ölçütlerine göre ölçülen yukarıdaki çözümlerin her biri gösterilmektedir.
| Çözüm | Gereksinimler karşılansın mı? | Cihaz karmaşıklığı | Azure karmaşıklığı | Aktarım | İlk görüntü | Cihazda taban var | Uygulama katmanına Güncelleştir | Temel katmana Güncelleştir |
|---|---|---|---|---|---|---|---|---|
| Docker katmanlarını aktarma | Yes | Düşük | Orta | FileCatalyst | %100 | % 10,5 | % 22,4 | %100 |
| Değiştirilen Docker Istemcisi | Yes | Orta | Düşük | HTTP | %100 | % 10,5 | % 22,4 | %100 |
| Kenarda | No | Yüksek | Orta | FileCatalyst | Yok | Yok | Yok | Yok |
| Tam görüntü Delta aktarımı | Yes | Düşük | Yüksek | FileCatalyst | %100 | % 3,2 | %0,01 | % 16,1 |
Yukarıdaki ayrıntılara bağlı olarak, CSE tam görüntü Delta aktarma yöntemini seçti. Bu çözüm, ikili düzeltme eklerini derlemek için bazı özel mantık gerektirdi, ancak cihazlara ne kadar veri gönderildiğini gösteren en verimli seçenektir.
Dikkat edilmesi gerekenler
Çözüm ayrıntıları
Geliştiriciler, kaynak kodu deposundaki modülleriyle ilgili kaynak kodla etkileşime geçebilir. Deponun temel yapısı, her modül için kodu içeren klasörlerden oluşur ve aşağıdaki gibi:
\- repository root
- modulea
- modulea.csproj
- module.json
- Program.cs
- Dockerfile
\- moduleb
- moduleb.csproj
- module.json
- Program.cs
- Dockerfile
Kaynak kodu depolarının sayısı tercih edilir; Bununla birlikte, önerilen iki desen ve bu müşteriyle hangi CSE 'nin kullanıldığı aşağıda yer verildi:
Tüm iş akışları genelinde geliştirilen tüm modüller için bir depo.
Her bir iş akışı için bir kaynak kod deposu.
Kaynak Depo derleme işlem hatları
her modül için bir Azure DevOps derleme işlem hattı vardır. Bu işlem hatları sorumludur:
Kaynak kodun güvenlik taraması.
Docker görüntüsünü oluşturmak için temel görüntünün güvenlik taraması.
Modül için birim testleri çalıştırılıyor.
Kaynak bir Docker görüntüsüne derleniyor. Resim etiketi, görüntünün her zaman bunu yapan kaynak koda geri bağlanabilmesi için BUILD_BUILDID içerir.
Görüntü bir Azure Container Registry örneğine gönderiliyor.
Delta dosyası oluşturuluyor.
Görüntü için bir imza dosyası oluşturma ve bir Azure depolama hesabına kaydetme.
Tüm işlem hattı örnekleri tek bir YAML işlem hattı tanımınıtemel alabilir. Modül, her bir işlem hattına eklenen filtreler ile ortam değişkenleri kullanılarak kullanılabilir. böylece, yalnızca belirli bir klasöre değişiklik yapıldığında tetiklenirler. Bu, yalnızca biri güncelleştirildiğinde tüm modüllerin bir kez daha güncelleştirilir.
Aşağıda gösterildiği gibi, modülleri oluşturmak ve kaydetmek için Azure DevOps Derleme İşlem Hattı kullanan genel bir Docker derlemesi kullanılır.
Azure Container Registry
Azure Container Registry (ACR), her modülün Docker görüntülerini depolamak için kullanılır. ACR için iki olası yapılandırma vardır:
Tüm görüntüleri depolar tek bir ACR örneği
İki ACR örneği sistemi: biri geliştirme, test ve hata ayıklama görüntülerini depolar; diğeri yalnızca ek testle doğrulanan ve üretime hazır olarak işaretlenmiş görüntüler içerir.
Bildirim deposu
Bildirim deposu, tüm iş akışlarının dağıtım bildirimlerini içerir. Şablonlar, temsil edilen iş akışına göre klasörlere girer ve aşağıda gösterilmiştir. Bu etkileşimde, iki iş akışı paylaşılan altyapı ve (yazılım) kapsayıcı uygulamasıdır.
\- repository root
- Workstream1
- deployment.template.json
- Workstream2
- deployment.template.json
Bildirim deposu görüntüsünden cihaza işlem hattı
Bu işlem hattı, görüntüleri bir bildirim dosyası tarafından tanımlandığı şekilde çeşitli hedeflenen cihazlara dağıtmakla sorumludur. Dağıtımı başlatmak için işlem hattını el ile tetiklemeniz gerekir.
Bu işlem hatları için tanım, bu dağıtım çalışması bir kapsayıcıda çalıştır olduğunu belirtir. Azure DevOps kapsayıcıların içinde derleme işlem hatlarını çalıştırmayı ve kapsayıcıyı temel alan görüntünün değişken girişini destekler. Bu şekilde tek bir değişken, tüm işlem hatlarının temel alınan görüntüsünü kontrol altına akar.
Bu görüntü, hangi düzeltme eklerinin derlemesi gerektiğini belirlemek, bu yamaları oluşturmak ve bunları dosya aktarım aracının Azure tarafına dağıtmak için gereken kodu içerir.
Çalıştırmak için görüntü dağıtım aracının aşağıdaki bilgilere ihtiyacı vardır:
Dağıtılacak görüntüler (depoda bildirim tarafından sağlanır)
Dağıtlanacak cihazlar (işlem hattını tetikleyen kullanıcı tarafından sağlanır)
Hedeflenen cihazlarda (Azure'daki bir SQL tarafından sağlanan) görüntüler
İşlem hattının çıktıları:
Cihazlara dağıtılmaları için dosya aktarım aracının Azure tarafına gönderilen düzeltme eki paketleri.
Bu SQL cihazların her bir cihazı aktarmaya başladığı veritabanı işaretlemesi.
Yeni bir SQL kümeyi temsil eden bir veritabanı girişi. Bu, dağıtımı kimin sipariş verdiğini ve dağıtımda bir sorun olursa iletişim kurmak için bir e-posta adresini içerir.
Bu işlem aşağıdaki adımları içerir:
Dağıtım bildirimine göre hangi görüntülerin gerekli olduğunu belirleme.
Hedeflenen SQL hangi görüntülerin zaten olduğunu görmek için sorgu oluşturun. Hepsi varsa işlem hattı başarıyla sonlandırılır.
Hangi düzeltme eki paketleri oluşturulacaklarını belirleme.
Başlangıç görüntüsünü belirleyen algoritma en küçük düzeltme eki paketi oluşturacak.
Girişler: Dağıtılan yeni görüntüyü içeren .tar dosyası ve cihazlardaki mevcut görüntüler için imza dosyaları.
Çıkış: Oluşturulecek en küçük düzeltme ekini belirlemek için mevcut görüntülerin sıralaması.
Bu dereceli listeden, her cihaz için hangi düzeltme eklerini derlemek için bir belirleme yapabilirsiniz. Benzer düzeltme ekleri bir kez ve ardından ihtiyaç olan tüm cihazlara kopyalanır.
Önceki adımda belirlenen gerekli düzeltme eki paketleri oluşturun.
Düzeltme eklerini dağıtım için dosya aktarım aracı depolama hesabına dağıtabilirsiniz.
Yeni SQL hedeflenen cihazların her biri için "geçişte" olarak işaretlemek için yeni görüntüleri güncelleştirin.
Görüntüyü dağıtan kişiye SQL e-postası ile birlikte dağıtım kümesi bilgilerini de ekleyin.
Bildirim deposu bildiriminden cihaza işlem hattı
Bu işlem hattı, güncelleştirilen cihaz için yeni dağıtım bildirimini uygun IoT hub'a gönderir. Bu el ile tetiklenen bir işlem hattıdır. İşlem hattı:
Dağıtım için hangi görüntülerin gerektiğini belirler.
Gerekli SQL hedeflenen cihazlarda olduğundan emin olmak için sorgular kullanılır.
- Yoksa, işlem hattı burada "başarısız" durumuyla sonlandırılır.
Yeni dağıtım bildirimini uygun IoT hub'ına iletir.
Dağıtımın IoT Hub dağıtım örneği, işlem hattı oluşturulduğunda yapılandırılmış bir ortam değişkenidir.
Hızlı dosya aktarım çözümü
Bu müşteri, kullanmaya devam etmek için tercih ettiği FileCatalyst adlı hızlı bir dosya aktarımı çözümünü zaten kullanıyor. "Nihai tutarlı" dosya aktarım aracı olarak da bilinen bu çözüm, Azure ile IoT cihazları arasında bağlantı sağlar. Nihai tutarlı kavramı, A'dan B'ye aktarımın haftalarca devam etmek ancak dosya bilgileri kaybı olmadan tamamlanması anlamına gelir. CSE, bağlantının Azure tarafında bir Azure Depolama Hesabı ve görüntüleri almak için her bir cihaz üzerinde müşterinin mevcut dosya aktarımı sanal makinesini (VM) kullandı. Cihaza yama paketleri geldiğinde, mevcut işlemler tarafından Bir Linux VM'ye aktarılır. Buradan dosya, dosyanın çalıştır olduğu Linux VM'IoT Hub.
Görüntü yeniden yapılandırma modülü
Görüntü Yeniden IoT Edge modülü, cihazlara alınan düzeltme eklerini uygulamakla sorumludur. Şu şekilde çalışır:
Kapsayıcıya bağlı bir klasörde düzeltme eki paketi alma.
Yapılandırma dosyasını okumak için içeriğinin sıkıştırmayı açın.
Yerel kapsayıcı kayıt defterinden temel görüntüyü çekme (karma ile).
Temel görüntüyü .tar dosyası olarak kaydetme.
Temel görüntüye düzeltme eki uygulama.
Yeni görüntüyü içeren yeni .tar dosyasını Docker'a yükleme.
Yeni görüntüyü yerel görüntüye Container Registry. Yapılandırma dosyasında kolay bir ad ve etiket bulunur.
IoT Hub'a başarı iletisi IoT Hub.
İşlem herhangi bir noktada başarısız olursa, dağıtımı sipariş eden kullanıcıya bildirile IoT Hub için bu modül IoT Hub ileti göndermekten sorumludur. Akış akışını izleyen Azure IoT Hub bu görüntüleri işler ve hazır olduktan sonra bulutta eyleme geçmektedir.
Yerel kapsayıcı kayıt defteri
Her cihaz kendi yerel kapsayıcı kayıt defterini barındırır. Bu çözümde CSE, Docker tarafından dağıtılan açık kaynak kayıt defterini kullandı. Bu işlem, mevcut dosya aktarım VM'si olarak da kullanılan konak VM'de çalışır.
Azure IoT Hub
IoT Hub diğer birçok dağıtım işlemi tarafından kullanılır. IoT hub'ı görüntü yeniden yapılandırma modüllerinden durum iletilerini alır. Ayrıca, çeşitli farklı cihazlar için dağıtım bildirimlerini ayarlar ve bu bildirimleri daha sonra akış akışının geri DevOps kullanılır.
Azure İşlevleri
IoT hub'dan gelen ileti akışını izlemek için bir Azure işlevi kullanılır. Bu, her cihazda Görüntü Yeniden Yapılandırma modülleri tarafından gönderilen iletiler üzerinde harekete sorumludur.
Başarılı bir ileti olması durumunda:
İşlev, cihazdaki görüntünün SQL "geçişte" olan "başarılı" girişlerinin durumunu günceller.
Dağıtım kümesine gelen son görüntü bu ise:
İşlev, dağıtımın başarılı olduğunu kullanıcıya (SQL sunucusunda yapılandırılan e-posta bildirimlerini kullanarak) bilgi verir.
İşlev ayrıca yeni görüntüleri kullanmaya başlamak için bildirimden cihaza işlem hattını tetikler.
Hata iletisi durumunda:
Cihaz SQL görüntüsü için "geçişte" olan giriş "başarısız" olarak güncelleştirilir.
Kullanıcıya görüntünün aktarılamama durumu (SQL sunucusunda yapılandırılan e-posta bildirimleri kullanılarak) bildirilecek.
SQL veritabanları
Bir SQL veritabanı, dağıtım işlemleri sırasında ve sonrasında hedef cihazlarda ve Azure tabanlı dağıtım hizmetlerde neler olduğunu izlemekle sorumludur.
Hem NuGet veritabanı tarafından kullanılan veritabanıyla etkileşim kurmak için özel bir Azure İşlevleri paketi Azure Pipelines.
Şu anda depolanan veriler:
Hangi görüntüler hangi cihazdadır?
Hangi görüntüler hangi cihaza geliyor?
Hangi görüntülerin dağıtılacağı bir kümeye ait ve bu dağıtımı kimin sipariş verdiğini.
Bu, aşağıdakileri gösteren bir Pano için veri kaynağı olarak kullanılabilir:
Dağıtım durumu.
Belirli bir cihazdaki görüntüler.
Görüntüsü olan cihazlar.
Başarılı ve başarısız aktarımlardaki zaman serisi verileri.
Kullanıcıya dayalı dağıtım sorguları.
Bu müşteri katılımı sırasında birincil hedef, sistemin gelecekte gerekli olacak verileri oluşturulmasını sağlamaktır. Çözüm, daha sonra, IoT Edge cihazları çalıştırmanın istatistiklerini almak için IoT Hub sorgulamasına olanak sağlar ve bu da bildirim-cihaz işlem hattının başarısına ilişkin görünürlük sağlar.
Uygulama Özeti
Bu çözümün uygulanması, IoT cihazlarındaki güncelleştirmeler tarafından tüketilen bant genişliğini önemli ölçüde düşürür. Aktarım verimliliğinde farklılıkların bir dökümü aşağıda gösterilmiştir.
Sonraki adımlar
Bu çözümü oluşturmak için kullanılan süreçler ve teknolojiler hakkında daha fazla ayrıntı için bkz.: