Bagikan melalui


Penyebaran DevOps untuk Azure Logic Apps penyewa tunggal

Berlaku pada: Azure Logic Apps (Standar)

Dengan tren aplikasi cloud terdistribusi dan asli, organisasi berurusan dengan lebih banyak komponen terdistribusi di lebih banyak lingkungan. Untuk mempertahankan kontrol dan konsistensi, Anda dapat mengotomatisasi lingkungan dan menerapkan lebih banyak komponen dengan lebih cepat dan lebih percaya diri dengan menggunakan alat dan proses DevOps.

Artikel ini menyediakan pengantar dan gambaran umum tentang pengalaman integrasi berkelanjutan dan penerapan berkelanjutan (CI/CD) saat ini untuk Azure Logic Apps penyewa tunggal.

Penyewa tunggal versus multi-penyewa

Di Azure Logic Apps multi-penyewa, penerapan sumber daya didasarkan pada templat Azure Resource Manager (templat ARM), yang menggabungkan dan menangani provisi sumber daya untuk aplikasi logika dan infrastruktur. Di Azure Logic Apps penyewa tunggal, penyebaran menjadi lebih mudah karena Anda dapat memisahkan provisi sumber daya antara aplikasi dan infrastruktur.

Saat Anda membuat aplikasi logika menggunakan jenis sumber daya Logic App (Standar) , alur kerja Anda didukung oleh runtime Azure Logic Apps penyewa tunggal yang didesain ulang. Runtime ini menggunakan ekstensibilitas Model ekstensibilitas Azure Functions dan dihosting sebagai ekstensi pada runtime Azure Functions. Desain ini memberikan portabilitas, fleksibilitas, dan performa lebih untuk aplikasi logika Anda ditambah kemampuan dan manfaat lain yang diwarisi dari platform Azure Functions dan ekosistem Azure App Service.

Misalnya, Anda dapat mengemas runtime dan alur kerja dalam kontainer yang didesain ulang bersama-sama sebagai bagian dari aplikasi logika. Anda dapat menggunakan langkah atau tugas umum yang membangun, merakit, dan membuat zip sumber daya aplikasi logika ke dalam artefak yang siap disebar. Untuk menyebarkan aplikasi, salin artefak ke lingkungan host lalu mulai aplikasi untuk menjalankan alur kerja. Atau, integrasikan artefak ke dalam alur penyebaran menggunakan alat dan proses yang telah Anda ketahui dan gunakan. Misalnya, jika skenario Anda memerlukan kontainer, Anda dapat menyimpan aplikasi logika dalam kontainer dan mengintegrasikannya ke dalam alur yang ada.

Untuk menyiapkan dan menyebarkan sumber daya infrastruktur, seperti jaringan virtual dan konektivitas, Anda dapat terus menggunakan templat ARM dan secara terpisah memprovisi sumber daya tersebut bersama dengan proses dan alur lain yang digunakan untuk tujuan tersebut.

Dengan menggunakan opsi bangun dan sebar standar, Anda dapat fokus pada pengembangan aplikasi secara terpisah dari penyebaran infrastruktur. Akibatnya, Anda mendapatkan model proyek yang lebih umum di mana Anda dapat menerapkan banyak opsi penyebaran serupa atau sama yang digunakan untuk aplikasi umum. Anda juga mendapatkan manfaat dari pengalaman yang lebih konsisten untuk membangun alur penyebaran di sekitar proyek aplikasi Anda dan untuk menjalankan pengujian dan validasi yang diperlukan sebelum menerbitkan ke produksi. Apa pun tumpukan teknologi yang digunakan, Anda dapat menyebarkan aplikasi logika menggunakan alat pilihan Anda sendiri.

Kemampuan penyebaran DevOps

Azure Logic Apps penyewa tunggal mewarisi banyak kemampuan dan manfaat dari platform Azure Functions dan ekosistem Azure App Service. Pembaruan ini mencakup model penyebaran baru dan lebih banyak cara untuk menggunakan DevOps untuk alur kerja aplikasi logika Anda.

Fitur pengembangan dan pengujian

Saat Anda menggunakan Visual Studio Code dengan ekstensi Azure Logic Apps (Standar), Anda dapat mengembangkan, menyusun, dan menjalankan alur kerja aplikasi logika berbasis penyewa tunggal secara lokal di lingkungan pengembangan Anda tanpa harus menyebarkan Azure. Jika skenario Anda memerlukan kontainer, Anda dapat membuat dan menyebarkan melalui Logic Apps dengan dukungan Azure Arc.

Kemampuan ini merupakan peningkatan besar dan memberikan manfaat substansial dibandingkan dengan model multi-penyewa, yang mengharuskan Anda untuk berkembang pada sumber daya yang ada dan yang berjalan di Azure.

Masalah terpisah

Model penyewa tunggal memberi kemampuan untuk memisahkan masalah antara aplikasi dan infrastruktur yang mendasarinya. Misalnya, Anda dapat mengembangkan, membangun, membuat zip, dan menyebarkan aplikasi secara terpisah sebagai artefak yang tidak dapat diubah ke lingkungan yang berbeda. Alur kerja aplikasi logika biasanya memiliki "kode aplikasi" yang lebih sering perbarui daripada infrastruktur yang mendasarinya. Dengan memisahkan lapisan ini, Anda dapat lebih fokus membangun alur kerja aplikasi logika dan meringankan upaya menyebarkan sumber daya yang diperlukan di berbagai lingkungan.

Diagram konseptual memperlihatkan alur penerapan terpisah untuk aplikasi dan infrastruktur.

Struktur sumber daya aplikasi logika

Dalam model Azure Logic Apps multi-penyewa, struktur sumber daya aplikasi logika Konsumsi hanya dapat menyertakan satu alur kerja. Karena hubungan satu-ke-satu ini, aplikasi logika dan alur kerja sering dianggap dan direferensikan sama. Namun, dalam model Azure Logic Apps penyewa tunggal, struktur sumber daya aplikasi logika Standar dapat menyertakan beberapa alur kerja. Hubungan satu-ke-banyak ini berarti bahwa dalam aplikasi logika yang sama, alur kerja dapat berbagi dan menggunakan kembali sumber daya lain. Alur kerja dalam aplikasi logika dan penyewa yang sama juga menawarkan peningkatan performa karena penyewaan bersama ini dan kedekatan satu sama lain. Struktur sumber daya ini terlihat dan berfungsi mirip dengan Azure Functions di mana aplikasi fungsi dapat melakukan host pada banyak fungsi.

Untuk mendapatkan informasi selengkapnya dan cara terbaik mengatur alur kerja, performa, dan penskalaan di aplikasi logika Anda, tinjau panduan untuk Azure Functions serupa yang umumnya dapat diterapkan ke Azure Logic Apps penyewa tunggal.

Struktur proyek aplikasi logika

Dalam Visual Studio Code, proyek aplikasi logika Anda memiliki salah satu dari jenis berikut:

  • Berbasis bundel ekstensi (Node.js), yang merupakan jenis default
  • Berbasis paket NuGet (.NET), yang dapat Anda konversi dari jenis default

Berdasarkan jenis ini, proyek Anda menyertakan folder dan file yang sedikit berbeda. Proyek berbasis NuGet menyertakan folder .bin yang berisi paket dan pustaka lainnya. Proyek berbasis bundel tidak menyertakan folder .bin dan file lainnya. Beberapa skenario memerlukan proyek berbasis NuGet untuk menjalankan aplikasi Anda, misalnya, saat Anda ingin mengembangkan dan menjalankan operasi bawaan kustom. Untuk informasi selengkapnya tentang mengonversi proyek Anda untuk menggunakan NuGet, tinjau Mengaktifkan penulisan konektor bawaan.

Untuk proyek berbasis bundel default, proyek Anda memiliki folder dan struktur file yang mirip dengan contoh berikut:

MyBundleBasedLogicAppProjectName
| .vscode
| Artifacts
  || Maps 
     ||| MapName1
     ||| ...
  || Schemas
     ||| SchemaName1
     ||| ...
| WorkflowName1
  || workflow.json
  || ...
| WorkflowName2
  || workflow.json
  || ...
| workflow-designtime
| .funcignore
| connections.json
| host.json
| local.settings.json

Di tingkat akar proyek, Anda dapat menemukan file dan folder berikut dengan item lain:

Nama Folder atau file Deskripsi
.vscode Folder Berisi pengaturan terkait Visual Studio Code, seperti file extensions.json, launch.json, settings.json, dan tasks.json files.
Artefak Folder Berisi artefak akun integrasi yang Anda tentukan dan gunakan dalam alur kerja yang mendukung skenario business-to-business (B2B). Misalnya, struktur contoh mencakup memetakan dan skema untuk transformasi XML dan operasi validasi.
<WorkflowName> Folder Untuk setiap alur kerja, folder <WorkflowName> menyertakan file workflow.json, yang berisi definisi JSON yang mendasari alur kerja tersebut.
alur kerja-designtime Folder Berisi file pengaturan terkait lingkungan pengembangan.
.funcignore File Berisi informasi yang terkait dengan Alat Inti Azure Functions yang Anda pasang.
connections.json File Berisi metadata, titik akhir, dan kunci untuk sambungan terkelola dan fungsi Azure yang digunakan alur kerja Anda.

Penting: Untuk menggunakan sambungan dan fungsi yang berbeda untuk setiap lingkungan, pastikan Anda membuat parameter file connections.json ini dan memperbarui titik akhir.
host.json File Berisi pengaturan dan nilai konfigurasi khusus runtime, misalnya, batas default untuk platform Azure Logic Apps penyewa tunggal, aplikasi logika, alur kerja, pemicu, dan tindakan. Pada tingkat akar proyek aplikasi logika Anda, file metadata host.json berisi pengaturan konfigurasi dan nilai default yang semua alur kerja dalam aplikasi logika yang sama digunakan saat berjalan, baik secara lokal maupun di Azure.

Catatan: Saat membuat aplikasi logika, Visual Studio Code akan membuat file host.snapshot.*.json cadangan di kontainer penyimpanan Anda. Jika Anda menghapus aplikasi logika Anda, file cadangan ini tidak dihapus. Jika Anda membuat aplikasi logika lain dengan nama yang sama, file rekam jepret lain dibuat. Anda hanya dapat memiliki hingga 10 rekam jepret untuk aplikasi logika yang sama. Jika Anda melebihi batas ini, Anda akan mendapatkan kesalahan berikut:

Microsoft.Azure.WebJobs.Script.WebHost: Repository has more than 10 non-decryptable secrets backups (host))

Untuk mengatasi kesalahan ini, hapus file rekam jepret tambahan dari kontainer penyimpanan Anda.
local.settings.json File Berisi pengaturan aplikasi, string sambungan, dan pengaturan lain yang digunakan alur kerja Anda saat berjalan secara lokal. Dengan kata lain, pengaturan dan nilai ini hanya berlaku saat Anda menjalankan proyek di lingkungan pengembangan lokal. Selama penyebaran ke Azure, file dan pengaturan diabaikan dan tidak disertakan dengan penyebaran Anda.

File ini menyimpan pengaturan dan nilai sebagai variabel lingkungan lokal yang digunakan oleh alat pengembangan lokal Anda sebagai nilai appSettings. Anda dapat memanggil dan merujuk variabel lingkungan ini pada runtime dan waktu penyebaran dengan menggunakan pengaturan aplikasi dan parameter.

Penting: File local.settings.json dapat berisi rahasia, jadi pastikan Anda juga mengecualikan file ini dari kontrol sumber proyek.

Penyebaran kontainer

Azure Logic Apps penyewa tunggal mendukung penyebaran ke kontainer, yang berarti bahwa Anda dapat menyimpan alur kerja aplikasi logika dalam kontainer dan menjalankannya di mana saja kontainer dapat berjalan. Jika Anda menyimpan aplikasi dalam kontainer, penyebaran bekerja hampir sama dengan kontainer lain yang Anda terapkan dan kelola.

Misalnya yang mencakup Azure DevOps, tinjauan CI/CD untuk Kontainer.

Pengaturan dan parameter aplikasi

Di Azure Logic Apps multi-penyewa, pola dasar ARM menghadapi tantangan saat Anda harus mempertahankan variabel lingkungan untuk aplikasi logika di berbagai lingkungan dev, pengujian, dan produksi. Semua yang ada dalam templat ARM ditentukan saat penyebaran. Jika Anda hanya perlu mengubah satu variabel, Anda harus menyebarkan ulang semuanya.

Di Azure Logic Apps penyewa tunggal, Anda dapat memanggil dan mereferensikan variabel lingkungan di runtime dengan menggunakan pengaturan dan parameter aplikasi, sehingga Anda tidak perlu sering-sering menyebarkan ulang.

Konektor yang dikelola dan operasi bawaan

Ekosistem Azure Logic Apps menyediakan ratusan konektor yang dikelola Microsoft dan operasi bawaan sebagai bagian dari kumpulan yang terus berkembang yang dapat Anda gunakan dalam Azure Logic Apps penyewa tunggal. Cara Microsoft mempertahankan konektor dan operasi bawaan ini sebagian besar tetap sama di Azure Logic Apps penyewa tunggal.

Peningkatan yang paling signifikan adalah bahwa layanan penyewa tunggal membuat konektor terkelola yang lebih populer juga tersedia sebagai operasi bawaan. Misalnya, Anda dapat menggunakan operasi bawaan untuk Azure Service Bus, Azure Event Hubs, SQL, dan lainnya. Sementara itu, versi konektor terkelola masih tersedia dan terus bekerja.

Koneksi yang Anda buat menggunakan operasi bawaan disebut koneksi bawaan, atau koneksi penyedia layanan. Operasi bawaan dan koneksinya berjalan secara lokal dalam proses yang sama dengan yang menjalankan alur kerja Anda. Keduanya dihosting pada runtime Logic Apps yang didesain ulang. Sebaliknya, koneksi terkelola, atau koneksi API, dibuat dan dijalankan secara terpisah sebagai sumber daya Azure, yang Anda sebarkan menggunakan templat ARM. Akibatnya, operasi bawaan dan koneksinya memberikan performa yang lebih baik karena kedekatannya dengan alur kerja Anda. Desain ini juga berfungsi dengan baik dengan alur penyebaran karena koneksi penyedia layanan dikemas ke dalam artefak bangunan yang sama.

Di Visual Studio Code, saat Anda menggunakan perancang untuk mengembangkan atau membuat perubahan pada alur kerja, mesin Logic Apps secara otomatis menghasilkan metadata koneksi yang diperlukan dalam file fileconnections.js. Bagian berikut ini menjelaskan tiga jenis koneksi yang bisa Anda buat di alur kerja. Setiap jenis koneksi memiliki struktur JSON yang berbeda, yang penting untuk dipahami karena titik akhir berubah ketika Anda berpindah antar lingkungan.

Koneksi penyedia layanan

Saat Anda menggunakan operasi bawaan untuk layanan seperti Azure Service Bus atau Azure Event Hubs di Azure Logic Apps penyewa tunggal, Anda membuat koneksi penyedia layanan yang berjalan dalam proses yang sama dengan alur kerja. Infrastruktur koneksi ini di-host dan dikelola sebagai bagian dari aplikasi logika, dan pengaturan aplikasi menyimpan string koneksi untuk operasi bawaan berbasis penyedia layanan apa pun yang digunakan alur kerja.

Dalam proyek aplikasi logika Anda, setiap alur kerja memilik file workflow.jspada yang berisi penentuan JSON yang mendasari alur kerja. Definisi alur kerja ini kemudian mereferensikan string koneksi yang diperlukan dalam file connections.jsproyek.

Contoh berikut menunjukkan bagaimana koneksi penyedia layanan untuk operasi Azure Service Bus bawaan muncul di file connections.js Anda:

"serviceProviderConnections": {
   "{service-bus-connection-name}": {
      "parameterValues": {
         "connectionString": "@appsetting('servicebus_connectionString')"
      },
      "serviceProvider": {
         "id": "/serviceProviders/serviceBus"
      },
      "displayName": "{service-bus-connection-name}"
   },
   <...>
}

Sambungan terkelola

Saat pertama kali menggunakan konektor terkelola dalam alur kerja, Anda akan diminta untuk membuat koneksi API terkelola untuk layanan target atau sistem dan mengautentikasi identitas Anda. Konektor ini dikelola oleh ekosistem konektor bersama di Azure. Koneksi API ada dan berjalan sebagai sumber daya terpisah di Azure.

Di Visual Studio Code, saat Anda terus membuat dan mengembangkan alur kerja menggunakan perancang, mesin Logic Apps secara otomatis membuat sumber daya yang diperlukan di Azure untuk konektor terkelola di alur kerja Anda. Mesin secara otomatis menambahkan sumber daya koneksi ini ke grup sumber daya Azure yang Anda rancang untuk memuat aplikasi logika.

Contoh berikut menunjukkan cara koneksi API untuk konektor Azure Service Bus terkelola muncul di file connections.json:

"managedApiConnections": {
   "{service-bus-connection-name}": { 
      "api": {
         "id": "/subscriptions/{subscription-ID}/providers/Microsoft.Web/locations/{region}/managedApis/servicebus"
      },
      "connection": { 
         "id": "/subscriptions/{subscription-ID}/resourcegroups/{resource-group-name}/providers/Microsoft.Web/connections/servicebus"
      }, 
      "connectionRuntimeUrl": "{connection-runtime-URL}",
      "authentication": { 
         "type": "Raw",
         "scheme": "Key",
         "parameter": "@appsetting('servicebus_1-connectionKey')"
      },
   },
   <...>
}

Koneksi Azure Functions

Untuk memanggil fungsi yang dibuat dan dihosting di Azure Functions, Anda menggunakan operasi Azure Functions bawaan. Metadata koneksi untuk panggilan Azure Functions berbeda dari koneksi bawaan lainnya. Metadata ini disimpan dalam file connection.json proyek aplikasi logika Anda, tetapi terlihat berbeda:

"functionConnections": {
   "{function-operation-name}": {
      "function": { 
         "id": "/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Web/sites/{function-app-name}/functions/{function-name}"
      },
      "triggerUrl": "{function-url}",
      "authentication": {
        "type": "QueryString",
         "name": "Code",
         "value": "@appsetting('azureFunctionOperation_functionAppKey')"
      }, 
      "displayName": "{functions-connection-display-name}"
   },
   <...>
}

Autentikasi

Dalam Azure Logic Apps penyewa tunggal, model hosting untuk alur kerja aplikasi logika adalah penyewa tunggal di mana beban kerja Anda mendapat manfaat dari isolasi yang lebih banyak daripada di dalam model multi-penyewa. Selain itu, runtime Azure Logic Apps penyewa tunggal bersifat portabel, yang berarti Anda dapat menjalankan alur kerja Anda di lingkungan lain, misalnya, secara lokal di Visual Studio Code. Namun, desain ini memerlukan cara bagi aplikasi logika untuk mengautentikasi identitasnya sehingga mereka dapat mengakses ekosistem konektor terkelola di Azure. Aplikasi Anda juga memerlukan izin yang benar untuk menjalankan operasi saat menggunakan koneksi terkelola.

Secara default, setiap aplikasi logika berbasis penyewa tunggal memiliki identitas terkelola yang ditetapkan sistem yang diaktifkan secara otomatis. Identitas ini berbeda dari info masuk autentikasi atau string koneksi yang Anda gunakan untuk membuat koneksi. Pada runtime, aplikasi logika Anda menggunakan identitas ini untuk mengautentikasi koneksinya melalui kebijakan akses Azure. Jika Anda menonaktifkan identitas ini, koneksi tidak akan berfungsi saat runtime.

Bagian berikut ini memberikan informasi selengkapnya tentang jenis autentikasi yang bisa Anda gunakan untuk mengautentikasi koneksi terkelola, berdasarkan tempat aplikasi logika berjalan. Untuk setiap koneksi terkelola, file connection.json proyek aplikasi logika Anda memiliki objek authentication yang menentukan jenis autentikasi yang dapat digunakan aplikasi logika Anda untuk mengautentikasi koneksi terkelola tersebut.

Identitas terkelola

Untuk aplikasi logika yang dihosting dan dijalankan di Azure, identitas terkelola adalah jenis autentikasi default dan yang direkomendasikan untuk digunakan untuk mengautentikasi koneksi terkelola yang dihosting dan dijalankan di Azure. Dalam file connection.json proyek aplikasi logika Anda, koneksi terkelola memiliki objek authentication yang menentukan ManagedServiceIdentity sebagai jenis autentikasi:

"authentication": {
   "type": "ManagedServiceIdentity"
}

Mentah

Untuk aplikasi logika yang berjalan di lingkungan pengembangan lokal yang menggunakan Visual Studio Code, kunci autentikasi mentah digunakan untuk mengautentikasi koneksi terkelola yang dihosting dan dijalankan di Azure. Kunci ini dirancang hanya untuk penggunaan pengembangan, bukan untuk produksi, dan memiliki waktu kedaluwarsa 7 hari. Dalam file connection.json proyek aplikasi logika, koneksi terkelola memiliki objek authentication yang menentukan informasi autentikasi:

"authentication": {
   "type": "Raw", 
   "scheme": "Key", 
   "parameter": "@appsetting('connectionKey')"
 }

Langkah berikutnya