Merefaktor aplikasi lokal ke aplikasi web App Service dan instans terkelola SQL

Artikel ini menunjukkan bagaimana perusahaan fiktif Contoso melakukan refaktor aplikasi Windows .NET dua tingkat yang berjalan di mesin virtual (VM) VMware sebagai bagian dari migrasi ke Azure. Tim Contoso memigrasikan VM {i>front-enddatabase

Aplikasi SmartHotel360 yang digunakan dalam contoh ini disediakan sebagai perangkat lunak sumber terbuka. Jika Anda ingin menggunakannya untuk tujuan pengujian Anda sendiri, Anda dapat mengunduhnya dari GitHub.

Pendorong bisnis

Tim kepemimpinan IT Contoso bekerja sama dengan mitra bisnis untuk memahami apa yang ingin mereka capai dengan migrasi ini:

  • Mengelola pertumbuhan bisnis. Contoso berkembang, dan ada tekanan pada sistem dan infrastruktur lokal perusahaan.
  • Meningkatkan efisiensi. Contoso perlu menghapus prosedur yang tidak perlu dan menyederhanakan proses untuk pengembang dan pengguna. Bisnis membutuhkan TI untuk menjadi cepat dan tidak membuang waktu atau uang, sehingga memberikan kebutuhan pelanggan dengan lebih cepat.
  • Meningkatkan kelincahan. TI Contoso harus lebih responsif terhadap kebutuhan bisnis. Untuk berhasil dalam perekonomian global, perusahaan harus dapat bereaksi lebih cepat daripada perubahan di marketplace. Waktu reaksi tidak boleh menghalangi atau menjadi pemblokir bisnis.
  • Skala. Seiring berkembangnya bisnis, IT Contoso harus menyediakan sistem yang dapat tumbuh dengan kecepatan yang sama.
  • Mengurangi biaya. Contoso ingin meminimalkan biaya pemberian lisensi.

Tujuan migrasi

Untuk membantu menentukan metode migrasi terbaik, tim cloud Contoso membuat tujuan ini:

Domain persyaratan Detail
Aplikasi Aplikasi di Azure akan tetap sama pentingnya seperti saat ini di lokal.

Aplikasi harus memiliki kemampuan performa yang sama dengan yang saat ini ada di VMware.

Tim tidak ingin berinvestasi dalam aplikasi. Untuk saat ini, admin hanya akan memindahkan aplikasi dengan aman ke cloud.

Tim ingin berhenti mendukung Windows Server 2008 R2, yang saat ini dijalankan aplikasi.

Tim juga ingin berpindah dari SQL Server 2008 R2 ke database platform as a service (PaaS) modern, yang akan meminimalkan kebutuhan akan manajemen.

Contoso ingin memanfaatkan investasinya dalam lisensi SQL Server dan Jaminan Perangkat Lunak jika memungkinkan.

Contoso ingin mengurangi titik kegagalan tunggal di tingkat web.

Aplikasi ini terdiri dari aplikasi ASP.NET dan layanan Windows Communication Foundation (WCF) yang berjalan pada satu VM. Contoso ingin menyebarkan komponen-komponen ini di dua aplikasi web menggunakan App Service.
Azure Contoso ingin memindahkan aplikasi ke Azure, tetapi mereka tidak ingin menjalankannya di mesin virtual. Contoso ingin menggunakan layanan Azure PaaS untuk tingkat web dan data.
DevOps Contoso ingin pindah ke model DevOps yang menggunakan Azure DevOps untuk build dan alur rilis.

Desain solusi

Setelah menentukan tujuan dan persyaratan, Contoso merancang dan meninjau solusi penyebaran. Tim juga mengidentifikasi proses migrasi, termasuk layanan Azure yang akan mereka gunakan untuk migrasi.

Aplikasi saat ini

  • Aplikasi lokal SmartHotel360 dijenjangkan di dua VM, WEBVM dan SQLVM.
  • VM terletak di contosohost1.contoso.com host VMware ESXi 6.5.
  • Lingkungan VMware dikelola oleh vCenter Server 6.5 (vcenter.contoso.com), yang berjalan pada VM.
  • Contoso memiliki pusat data lokal (contoso-datacenter) dengan pengendali domain lokal (contosodc1).
  • Mesin virtual lokal di pusat data Contoso akan dinonaktifkan setelah migrasi selesai.

Solusi yang diusulkan

  • Untuk tingkat web aplikasi, Contoso akan menggunakan App Service. Contoso dapat menggunakan layanan PaaS ini untuk menyebarkan aplikasi hanya dengan beberapa perubahan konfigurasi. Contoso akan menggunakan Visual Studio untuk membuat perubahan, dan mereka akan menyebarkan dua aplikasi web, satu untuk situs web dan satu untuk layanan WCF.
  • Untuk memenuhi persyaratan untuk alur DevOps, Contoso akan menggunakan Azure DevOps untuk manajemen kode sumber dengan repositori Git. Mereka akan menggunakan build dan rilis otomatis untuk membangun kode dan menyebarkannya ke App Service.

Pertimbangan {i>database

Selama proses desain solusi, Contoso membandingkan fitur Azure SQL Database dengan SQL Managed Instance. Tim memutuskan untuk menggunakan SQL Managed Instance, berdasarkan pertimbangan berikut:

  • SQL Managed Instance bertujuan untuk menghadirkan kompatibilitas mendekati 100 persen dengan versi SQL Server lokal terbaru. Microsoft merekomendasikan SQL Managed Instance untuk organisasi yang menjalankan komputer virtual SQL Server lokal atau infrastruktur sebagai layanan (IaaS) dan yang ingin memigrasikan aplikasi mereka ke layanan yang dikelola sepenuhnya dengan perubahan desain minimal.
  • Contoso berencana untuk memigrasikan sejumlah besar aplikasi dari lokal ke IaaS VM. Banyak dari VM ini disediakan oleh vendor perangkat lunak independen. Tim Contoso menyadari bahwa menggunakan SQL Managed Instance dapat membantu memastikan kompatibilitas database untuk aplikasi ini. Mereka akan menggunakan SQL Managed Instance alih-alih SQL Database, yang mungkin tidak didukung.
  • Contoso dapat melakukan migrasi lift-and-shift ke SQL Managed Instance dengan menggunakan Azure Database Migration Service yang sepenuhnya otomatis. Contoso juga dapat menggunakan kembali layanan ini untuk migrasi database di masa mendatang.
  • SQL Managed Instance mendukung SQL Server Agent, komponen penting dari aplikasi SmartHotel360. Contoso membutuhkan kompatibilitas ini. Jika tidak, mereka harus mendesain ulang rencana pemeliharaan yang diperlukan oleh aplikasi.
  • Dengan Jaminan Perangkat Lunak, Contoso dapat menukar lisensinya saat ini dengan tarif diskon pada instans terkelola SQL dengan menggunakan Azure Hybrid Benefit untuk SQL Server. Ini memungkinkan Contoso untuk menyimpan sebanyak 30 persen dengan menggunakan SQL Managed Instance.
  • Instans terkelola SQL sepenuhnya terkandung dalam jaringan virtual, sehingga memberikan isolasi dan keamanan yang lebih baik untuk data Contoso. Contoso bisa mendapatkan manfaat dari cloud publik sambil menjaga lingkungan tetap terisolasi dari internet publik.
  • SQL Managed Instance mendukung banyak fitur keamanan, termasuk Always Encrypted, masking data dinamis, Keamanan Tingkat Baris, dan deteksi ancaman.

Ulasan solusi

Tim Contoso mengevaluasi desain yang mereka usulkan dengan menyusun daftar pro dan kontra:

Pertimbangan Detail
Pro Kode aplikasi SmartHotel360 tidak memerlukan perubahan untuk migrasi ke Azure.

Contoso dapat memanfaatkan investasinya dalam Jaminan Perangkat Lunak dengan menggunakan Azure Hybrid Benefit untuk SQL Server dan Windows Server.

Setelah migrasi, Contoso tidak perlu mendukung Windows Server 2008 R2. Untuk informasi selengkapnya, lihat Kebijakan Siklus Hidup Microsoft.

Contoso dapat mengonfigurasi tingkat web aplikasi dengan beberapa instans, sehingga tingkat web tidak lagi satu titik kegagalan.

Database tidak akan lagi tergantung pada penuaan SQL Server 2008 R2.

SQL Managed Instance mendukung persyaratan dan tujuan teknis Contoso.

Instans terkelola SQL akan memberikan kompatibilitas 100 persen dengan penyebaran saat ini sambil menjauh dari SQL Server 2008 R2.

Contoso dapat menggunakan kembali Database Migration Service untuk migrasi mendatang.

Instans terkelola SQL memiliki toleransi kesalahan bawaan yang tidak perlu dikonfigurasi oleh Contoso. Toleransi kesalahan ini memastikan bahwa tingkat data tidak lagi menjadi satu titik failover.
Kontra App Service hanya mendukung satu penyebaran aplikasi untuk setiap aplikasi web. Jadi dua aplikasi web harus disediakan, satu untuk situs web dan satu untuk layanan WCF.

Untuk tingkat data, SQL Managed Instance mungkin bukan solusi terbaik jika Contoso ingin menyesuaikan sistem operasi atau server {i>database

Arsitektur yang diusulkan

Diagram that shows the proposed architecture.

Proses migrasi

  1. Contoso menyediakan instans terkelola Azure SQL lalu memigrasikan database SmartHotel360 ke dalamnya dengan menggunakan Database Migration Service.
  2. Contoso memprovisikan dan mengonfigurasi aplikasi web dan menyebarkan aplikasi SmartHotel360 kepadanya.

Diagram that shows the migration process.

Layanan Azure

Layanan Deskripsi Biaya
Asisten migrasi App Service Alat gratis yang mudah digunakan yang dapat membantu Anda memigrasikan aplikasi web .NET dari lokal ke cloud dengan perubahan kode minimal atau tanpa perubahan kode. Ini adalah alat yang dapat diunduh, gratis.
Layanan Migrasi Database Layanan Azure yang dapat Anda gunakan untuk bermigrasi dari beberapa sumber database ke platform data Azure dengan waktu henti minimal. Lihat Harga Azure Database Migration Service dan wilayah yang didukung.
SQL Managed Instance Layanan database terkelola yang mewakili instans SQL Server yang dikelola sepenuhnya di Azure. Ini menggunakan kode yang sama dengan versi terbaru mesin database SQL Server, dan memiliki fitur terbaru, peningkatan performa, dan patch keamanan. Menggunakan instans terkelola SQL pada Azure dikenakan biaya berdasarkan kapasitas. Pelajari selengkapnya tentang harga SQL Managed Instance.
Azure App Service Layanan yang dapat membantu Anda membuat aplikasi cloud canggih yang menggunakan platform yang dikelola sepenuhnya. Harga didasarkan pada ukuran, lokasi, dan durasi penggunaan. Pelajari lebih lanjut tentang harga Azure App Service.
Alur Azure Layanan yang menyediakan alur integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD) untuk pengembangan aplikasi. Alur dimulai dengan repositori Git untuk mengelola kode aplikasi, sistem build untuk memproduksi paket dan artefak build lainnya, dan sistem manajemen rilis untuk menyebarkan perubahan pada lingkungan pengembangan, pengujian, dan produksi. Pelajari tentang harga Azure Pipelines.

Prasyarat

Untuk menerapkan skenario ini, Contoso harus memenuhi prasyarat berikut:

Persyaratan Detail
Langganan Azure Contoso membuat langganan di artikel sebelumnya dalam seri ini. Jika Anda tidak memiliki langganan Azure, buat akun gratis.

Jika membuat akun gratis, Anda akan menjadi administrator langganan Anda dan dapat melakukan semua tindakan. Jika Anda menggunakan langganan yang sudah ada dan Anda bukan administrator, admin perlu menetapkan izin Pemilik atau Kontributor untuk Anda.
Infrastruktur Azure Contoso menyiapkan infrastruktur Azure seperti yang dijelaskan dalam infrastruktur Azure untuk migrasi.

Langkah-langkah skenario

Berikut cara Contoso menjalankan migrasi:

  • Langkah 1: Menilai dan memigrasikan aplikasi web.. Contoso menggunakan asisten migrasi App Service untuk menjalankan pemeriksaan kompatibilitas pra-migrasi dan memigrasikan aplikasi web ke App Service.
  • Langkah 2: Menyiapkan instans terkelola SQL. Contoso membutuhkan instans terkelola yang sudah ada yang akan menjadi tujuan migrasi {i>database
  • Langkah 3: Migrasi dengan menggunakan Database Migration Service. Contoso memigrasikan database aplikasi dengan menggunakan Database Migration Service.
  • Langkah 4: Menyiapkan Azure DevOps. Contoso membuat proyek Azure DevOps baru, dan mengimpor repositori Git.
  • Langkah 5: Mengonfigurasikan string koneksi. Contoso mengonfigurasi string koneksi sehingga aplikasi web tingkat web, aplikasi web layanan WCF, dan instans SQL dapat berkomunikasi.
  • Langkah 6: Menyiapkan kompilasi dan alur rilis di Azure DevOps. Pada langkah terakhir, Contoso menyiapkan alur build dan rilis di Azure DevOps untuk membuat aplikasi. Tim kemudian menyebarkan alur ke dua aplikasi web terpisah.

Langkah 1: Nilai dan migrasikan aplikasi web

Admin Contoso menilai dan memigrasikan aplikasi web mereka dengan menggunakan asisten migrasi App Service. Mereka menggunakan jalur pembelajaran Migrate ASP.NET Apps ke Azure sebagai panduan selama proses. Admin melakukan tindakan-tindakan ini:

  • Mereka menggunakan alat penilaian migrasi App Service untuk mengevaluasi dependensi apa pun antara aplikasi web mereka dan untuk menentukan apakah ada ketidaksesuaian antara aplikasi web lokal mereka dan apa yang didukung oleh App Service.

  • Mereka mengunduh asisten migrasi App Service dan masuk ke akun Azure mereka.

  • Mereka memilih langganan, grup sumber daya, dan nama domain situs web.

Langkah 2: Menyiapkan instans terkelola SQL

Untuk menyiapkan instans terkelola Azure SQL, Contoso memerlukan subnet yang memenuhi persyaratan berikut:

  • Subnetnya harus khusus. Subnet harus kosong. Subnet tidak boleh berisi layanan cloud lainnya. Subnet tidak boleh menjadi subnet gateway.
  • Setelah membuat instans terkelola, Contoso tidak boleh menambahkan sumber daya ke subnet.
  • Subnet tidak boleh memiliki kelompok keamanan jaringan yang terkait dengannya.
  • Subnet harus memiliki tabel rute yang ditentukan pengguna. Satu-satunya rute yang ditetapkan harus 0.0.0.0/0 next-hop internet.
  • Jika DNS kustom opsional ditentukan untuk jaringan virtual, alamat IP virtual 168.63.129.16 untuk pemecah masalah rekursif di Azure harus ditambahkan ke daftar. Lihat cara mengonfigurasi DNS kustom untuk instans terkelola Azure SQL.
  • Subnet tidak boleh memiliki titik akhir layanan (penyimpanan atau SQL) yang terkait dengannya. Titik akhir layanan harus dinonaktifkan di jaringan virtual.
  • Subnet harus memiliki setidaknya 16 alamat IP. Pelajari cara mengukur subnet instans terkelola.
  • Di lingkungan hibrid Contoso, pengaturan DNS kustom diperlukan. Contoso mengonfigurasi pengaturan DNS untuk menggunakan satu atau beberapa server Azure DNS perusahaan. Pelajari selengkapnya tentang penyesuaian DNS.

Menyiapkan jaringan virtual untuk instans terkelola

Admin Contoso menyiapkan jaringan virtual sebagai berikut:

  1. Mereka membuat jaringan virtual (VNET-SQLMI-EUS2) di wilayah utama (US Timur 2). Mereka membuat jaringan virtual di grup sumber daya ContosoNetworkingRG.

  2. Mereka menetapkan ruang alamat 10.235.0.0/24. Mereka memastikan bahwa rentang tidak tumpang tindih dengan jaringan lain di perusahaan.

  3. Mereka menambahkan dua subnet ke jaringan:

    • SQLMI-DB-EUS2 (10.235.0.0/25).

    • SQLMI-SAW-EUS2 (10.235.0.128/29). Subnet ini digunakan untuk melampirkan direktori ke instans terkelola.

      Screenshot that shows the values for creating the managed instance.

  4. Setelah jaringan virtual dan subnet disebarkan, mereka melakukan {i>peering

    • Peer VNET-SQLMI-EUS2 dengan VNET-HUB-EUS2 (jaringan virtual hub untuk US Timur 2).

    • Peer VNET-SQLMI-EUS2 dengan VNET-PROD-EUS2 (jaringan produksi).

      Screenshot that shows the peered networks.

  5. Mereka mengatur pengaturan DNS kustom. Pengaturan DNS menunjuk pertama ke pengendali domain Azure Contoso. Azure DNS bersifat sekunder. Pengendali domain Contoso Azure terletak sebagai berikut:

    • Mereka terletak di subnet PROD-DC-EUS2 dari jaringan produksi (VNET-PROD-EUS2) di wilayah US Timur 2.

    • alamat CONTOSODC3: 10.245.42.4

    • alamat CONTOSODC4: 10.245.42.5

    • Pemecah masalah Azure DNS: 168.63.129.16

    Screenshot that shows the network DNS servers.

Butuh bantuan lainnya?

Menyiapkan perutean

Instans terkelola ditempatkan di jaringan virtual pribadi. Contoso memerlukan tabel rute untuk memungkinkan jaringan virtual berkomunikasi dengan layanan manajemen Azure. Jika jaringan virtual tidak dapat berkomunikasi dengan layanan yang mengelolanya, jaringan virtual akan menjadi tidak dapat diakses.

Contoso mempertimbangkan faktor-faktor ini:

  • Tabel rute berisi seperangkat aturan (rute) yang menentukan bagaimana paket yang dikirim dari instans terkelola harus dirutekan dalam jaringan virtual.
  • Tabel rute dikaitkan dengan subnet tempat instans terkelola disebarkan. Setiap paket yang meninggalkan subnet ditangani berdasarkan tabel rute terkait.
  • Subnet dapat diasosiasikan dengan hanya satu tabel rute.
  • Tidak ada biaya tambahan untuk membuat tabel rute di Azure.

Untuk menyiapkan perutean, admin Contoso menyelesaikan langkah-langkah berikut:

  1. Mereka membuat tabel rute yang ditentukan pengguna di grup sumber daya ContosoNetworkingRG :

    Screenshot that shows the Create route table dialog.

  2. Untuk mematuhi persyaratan SQL Managed Instance, setelah tabel rute (MIRouteTable) disebarkan, admin menambahkan rute dengan awalan alamat 0.0.0.0/0. Mereka mengatur nilai Jenis hop berikutnya ke Internet:

    Screenshot that shows the Add route dialog.

  3. Mereka mengaitkan tabel rute dengan subnet SQLMI-DB-EUS2 di jaringan VNET-SQLMI-EUS2:

    Screenshot that shows the Associate subnet dialog.

Butuh bantuan lainnya?

Pelajari cara menyiapkan rute untuk instans terkelola.

Membuat instans terkelola

Selanjutnya, admin Contoso menyediakan instans terkelola SQL dengan menyelesaikan langkah-langkah berikut:

  1. Karena instans terkelola melayani aplikasi bisnis, admin menyebarkan instans terkelola di wilayah utama perusahaan (US Timur 2). Mereka menambahkan instans terkelola ke grup sumber daya ContosoRG.

  2. Mereka memilih tingkat harga, ukuran komputasi, dan penyimpanan untuk instans. Pelajari selengkapnya tentang harga SQL Managed Instance.

    Screenshot that shows the SQL Managed Instance dialog.

    Setelah instans terkelola disebarkan, dua sumber daya baru muncul di grup sumber daya ContosoRG:

    • SQL managed instance.

    • Sebuah kluster virtual, jika Contoso memiliki beberapa instans terkelola.

      Screenshot that shows new resources in the ContosoRG resource group.

Butuh bantuan lainnya?

Pelajari cara menyediakan instans terkelola.

Langkah 3: Migrasi dengan menggunakan Database Migration Service

Admin Contoso memigrasikan instans terkelola dengan menggunakan Database Migration Service. Mereka mengikuti instruksi dalam tutorial migrasi langkah demi langkah. Admin Contoso dapat melakukan migrasi online, offline, dan hibrid (pratinjau).

Admin Contoso menyelesaikan langkah-langkah berikut:

  • Mereka membuat instans Database Migration Service dengan SKU Premium yang terhubung ke jaringan virtual.
  • Mereka memastikan bahwa Database Migration Service dapat mengakses instans SQL Server jarak jauh melalui jaringan virtual. Langkah ini melibatkan memastikan bahwa semua port masuk diizinkan dari Azure ke SQL Server di tingkat jaringan virtual, VPN jaringan, dan komputer yang menghosting SQL Server.
  • Mereka mengonfigurasi Database Migration Service:
    • Buat proyek migrasi.
    • Tambahkan sumber (database lokal).
    • Pilih target.
    • Pilih database yang akan dimigrasikan.
    • Konfigurasikan pengaturan tingkat lanjut.
    • Mulai replikasi.
    • Selesaikan kesalahan apa pun.
    • Lakukan cutover.

Langkah 4: Menyiapkan Azure DevOps

Contoso perlu membangun infrastruktur dan alur DevOps untuk aplikasi. Untuk melakukannya, admin Contoso membuat proyek DevOps baru, mengimpor kode, lalu menyiapkan bangun dan alur rilis.

  1. Di akun Contoso Azure DevOps, mereka membuat proyek baru, ContosoSmartHotelRefactor, lalu pilih Git untuk kontrol versi.

    Screenshot that shows the new project dialog.

  2. Mereka mengimpor repositori Git yang saat ini memegang kode aplikasinya. Mereka mengunduhnya dari repositori GitHub publik.

    Screenshot that shows the Import a Git repository dialog.

  3. Mereka menyambungkan Visual Studio ke repositori dan kemudian membuat klon kode ke mesin pengembang dengan menggunakan Team Explorer.

    Screenshot that shows the Connect to a Project dialog.

  4. Mereka membuka file solusi untuk aplikasi. Aplikasi web dan layanan WCF memiliki proyek terpisah dalam {i>file

    Screenshot that shows the web app and WCF service projects in Solution Explorer.

Langkah 5: Mengonfigurasikan {i>string

Admin Contoso memastikan bahwa aplikasi web dan {i>database

  1. Di aplikasi web untuk layanan WCF, SHWCF-EUS2, di bawah pengaturan Pengaturan> Aplikasi, mereka menambahkan string koneksi baru bernama .DefaultConnection

  2. Mereka menarik string koneksi dari database SmartHotel-Registration lalu memperbaruinya dengan kredensial yang benar:

    Screenshot that shows the connection string settings.

  3. Di Visual Studio, admin membuka proyek SmartHotel.Registration.wcf dari file solusi. Dalam proyek, mereka memperbarui bagian connectionStrings file web.config dengan menambahkan string koneksi:

    Screenshot that shows the connectionStrings section of the web.config file in the SmartHotel.Registration.wcf project.

  4. Mereka memperbarui client bagian file web.config untuk SmartHotel.Registration.Web sehingga menunjuk ke lokasi baru layanan WCF. Pointer adalah URL aplikasi web WCF yang menghosting titik akhir layanan.

    Screenshot that shows the client section of the web.config file in the SmartHotel.Registration.wcf project.

  5. Admin menerapkan dan menyinkronkan perubahan kode dengan menggunakan Team Explorer di Visual Studio.

Langkah 6: Menyiapkan alur bangun dan rilis di Azure DevOps

Admin Contoso sekarang mengonfigurasi Azure DevOps untuk melakukan proses bangun dan rilis.

  1. Di Azure DevOps, mereka memilih Bangun dan rilis>Alur baru:

    Screenshot that shows the New pipeline button in Azure DevOps.

  2. Mereka memilih Azure Repos Git dan repositori yang relevan:

    Screenshot that shows the Azure Repos Git button and the selected repository.

  3. Di bawah Pilih templat, mereka memilih templat ASP.NET untuk build mereka:

    Screenshot that shows the Select a template dialog with the ASP.NET template selected.

  4. Mereka menggunakan nama ContosoSmartHotelRefactor-ASP.NET-CI untuk build lalu pilih Simpan &antrean, yang memulai build pertama.

    Screenshot that shows the Save & queue button for the build.

  5. Mereka memilih nomor build sehingga mereka dapat menonton prosesnya. Setelah proses selesai, admin dapat melihat umpan balik proses. Mereka memilih Artefak untuk meninjau hasil build:

    Screenshot that shows the build page and the Artifacts button.

    Jendela penjelajah Artefak terbuka. Hasil build terlihat di folder drop .

    • Dua file .zip adalah paket yang berisi aplikasi.
    • File .zip ini digunakan dalam alur rilis untuk penyebaran ke App Service.

    Screenshot that shows the Artifacts explorer.

  6. Mereka memilih Rilis>Alur baru:

    Screenshot that shows the New pipeline button.

  7. Mereka memilih templat penyebaran untuk App Service:

    Screenshot that shows the Select a template dialog.

  8. Mereka menamai alur rilis ContosoSmartHotel360Refactor dan, dalam kotak Nama tahap, tentukan SHWCF-EUS2 sebagai nama aplikasi web WCF:

    Screenshot that shows the stage name of the WCF web app.

  9. Di bawah tahapan, mereka memilih 1 pekerjaan, 1 tugas untuk mengonfigurasi penyebaran layanan WCF:

    Screenshot that shows the 1 job, 1 task option.

  10. Mereka memverifikasi bahwa langganan dipilih dan diotorisasi, lalu mereka memilih nama layanan aplikasi:

    Screenshot that shows the app service name.

  11. Pada alur, mereka memilih Artefak, pilih Tambahkan artefak, pilih Bangun sebagai jenis sumber, lalu buat dengan menggunakan alur ContosoSmarthotel360Refactor:

    Screenshot that shows the Build button in the Add an artifact dialog.

  12. Untuk mengaktifkan pemicu penyebaran berkelanjutan, admin memilih tombol petir pada artefak:

    Screenshot that shows the lightning bolt button on the artifact.

  13. Mereka mengatur pemicu penyebaran berkelanjutan ke Diaktifkan:

    Screenshot that shows the continuous deployment trigger set to Enabled.

  14. Admin kembali ke pekerjaan tahap 1, 1 tugas dan pilih Sebarkan Azure App Service:

    Screenshot that shows the Deploy Azure App Service option.

  15. Di bawah Pilih file atau folder, mereka memperluas folder drop , pilih file SmartHotel.Registration.Wcf.zip yang dibuat selama build, lalu pilih Simpan:

    Screenshot that shows the Select a file or folder dialog.

  16. Mereka memilih Tahap alur>, lalu pilih Tambahkan untuk menambahkan lingkungan untuk SHWEB-EUS2. Mereka memilih penyebaran Azure App Service lainnya.

    Screenshot that shows the 1 job, 1 task link.

  17. Mereka mengulangi proses untuk menerbitkan file SmartHotel.Registration.Web.zip aplikasi web yang benar, lalu pilih Simpan:

    Screenshot that shows the Select a file or folder dialog for selecting the web file.

    Alur rilis ditampilkan, seperti yang ditunjukkan di sini:

    Screenshot that shows the release pipeline.

  18. Mereka kembali ke Build, pilih Pemicu, lalu pilih Aktifkan integrasi berkelanjutan. Tindakan ini memungkinkan alur sehingga ketika perubahan diterapkan pada kode, build dan rilis lengkap terjadi.

    Screenshot that shows the Enable continuous integration checkbox.

  19. Mereka memilih Simpan & antrean untuk menjalankan alur lengkap. Build baru dipicu, yang pada gilirannya membuat rilis pertama aplikasi ke App Service.

    Screenshot that shows the Save & queue button.

  20. Admin Contoso dapat mengikuti proses alur bangun dan rilis dari Azure DevOps. Setelah build selesai, rilis dimulai:

    Screenshot that shows the build and release progress.

  21. Ketika alur selesai, kedua situs disebarkan dan aplikasi berjalan online:

    Screenshot that shows the running application.

    Aplikasi berhasil dimigrasikan ke Azure.

Bersihkan setelah migrasi

Setelah migrasi, tim Contoso menyelesaikan langkah-langkah pembersihan berikut:

  • Mereka menghapus mesin virtual lokal dari inventaris vCenter Server.
  • Mereka menghapus mesin virtual dari pekerjaan cadangan lokal.
  • Mereka memperbarui dokumentasi internalnya untuk menunjukkan lokasi baru untuk aplikasi SmartHotel360. Dokumentasi menunjukkan bahwa database berjalan di instans terkelola SQL dan ujung depan berjalan di dua aplikasi web.
  • Mereka meninjau semua sumber daya yang berinteraksi dengan mesin virtual yang dinonaktifkan, dan memperbarui segala pengaturan atau dokumentasi yang relevan untuk mencerminkan konfigurasi baru.

Tinjau penyebaran

Setelah sumber daya dimigrasikan ke Azure, Contoso perlu sepenuhnya mengoprasi infrastruktur baru dan memberikan keamanan untuk itu.

Keamanan

Pencadangan

  • Tim Contoso meninjau persyaratan cadangan untuk database di SQL Managed Instance. Untuk informasi selengkapnya, lihat Pencadangan otomatis di Azure SQL Database.
  • Mereka juga belajar tentang mengelola pencadangan dan pemulihan Microsoft Azure SQL Database. Untuk informasi selengkapnya, lihat pencadangan otomatis.
  • Mereka mempertimbangkan untuk menerapkan grup {i>failoverfailoverdatabaseGambaran umum grup failover otomatis.
  • Mereka mempertimbangkan untuk menyebarkan aplikasi web di wilayah utama (US Timur 2) dan wilayah sekunder (AS Tengah) untuk ketahanan. Tim dapat mengonfigurasi Microsoft Azure Traffic Manager untuk memastikan failover selama pemadaman regional.

Lisensi dan pengoptimalan biaya

  • Setelah semua sumber daya disebarkan, Contoso menetapkan tag Azure yang mereka putuskan selama perencanaan infrastruktur.
  • Semua lisensi dibangun ke dalam biaya layanan PaaS yang dikonsumsi Contoso. Biaya ini akan dikurangi dari Perjanjian Enterprise.
  • Contoso akan menggunakan Azure Cost Management dan Billing untuk memastikan bahwa mereka beroperasi dalam anggaran yang ditetapkan oleh kepemimpinan TI mereka.

Kesimpulan

Dalam artikel ini, Contoso merefaktor aplikasi SmartHotel360 di Azure dengan memigrasikan VM front-end aplikasi ke dua aplikasi web App Service. Contoso memigrasikan database aplikasi ke instans terkelola Azure SQL.