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 front-end aplikasi ke aplikasi web Azure App Service. Artikel ini juga menunjukkan cara Contoso memigrasikan database aplikasi ke instans terkelola Azure SQL.

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:

• Mengatasi 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 IT untuk menjadi cepat dan tidak membuang waktu atau uang, sehingga memberikan persyaratan pelanggan secara lebih cepat.
• Meningkatkan ketangkasan. TI Contoso harus lebih responsif terhadap kebutuhan bisnis. Untuk berhasil dalam perekonomian global, perusahaan harus dapat bereaksi lebih cepat daripada perubahan di pasar. Waktu reaksi tidak boleh menghalangi atau menjadi pemblokir bisnis.
• Menskalakan. 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 satu titik kegagalan 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 alur build dan 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 smartHotel360 lokal 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 database

Selama proses desain solusi, Contoso membandingkan fitur Azure SQL Database dengan fitur 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 SQL Server lokal atau di VM 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 Row-Level, dan deteksi ancaman.

Tinjauan solusi

Tim Contoso mengevaluasi desain yang diusulkan 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 di masa 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 database, atau jika mereka ingin menjalankan aplikasi pihak ketiga bersama dengan SQL Server. Menjalankan SQL Server pada mesin virtual infrastruktur sebagai layanan (IAAS) dapat memberikan fleksibilitas ini.

Arsitektur yang diusulkan

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.

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 sedikit 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.
Instans Terkelola SQL	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. Untuk mempelajari 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.
Azure Pipelines	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 adalah administrator langganan dan dapat melakukan semua tindakan. Jika Anda menggunakan langganan yang sudah ada dan bukan administrator, admin harus menetapkan izin Pemilik atau Kontributor kepada Anda.
Infrastruktur Azure	Contoso menyiapkan infrastruktur Azure seperti yang dijelaskan dalam infrastruktur Azure untuk migrasi.

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 database SQL Server lokal.
• Langkah 3: Migrasikan 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 alur rilis dan build 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: Menilai dan memigrasikan 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 ini:

• Subnet harus didedikasikan. 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 internet next-hop.
• 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.

Siapkan 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.

     

4. Setelah jaringan virtual dan subnet disebarkan, keduanya melakukan peer jaringan sebagai berikut:

   • 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).

     

5. Mereka mengatur pengaturan DNS kustom. Pengaturan DNS menunjuk pertama ke pengendali domain Azure Contoso. Azure DNS bersifat sekunder. Berikut letak kontroler domain Contoso Azure:

   • 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

   

Butuh bantuan lainnya?

• Baca Ringkasan SQL Managed Instance.
• Pelajari cara membuat jaringan virtual untuk SQL managed instance.
• Pelajari cara menyiapkan peering.
• Pelajari cara memperbarui pengaturan DNS Azure Active Directory.

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 :

   

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

   

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

   

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.

   

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

   • Instans terkelola SQL.

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

     

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 akhir.

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.

   

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

   

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

   

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

   

Langkah 5: Mengonfigurasikan string koneksi

Admin Contoso memastikan bahwa aplikasi web dan database dapat berkomunikasi satu sama lain. Untuk melakukannya, mereka mengonfigurasi string koneksi dalam kode dan di aplikasi web.

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:

   

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:

   

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.

   

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:

   

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

   

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

   

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

   

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:

   

   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.

   

6. Mereka memilih Rilis>Alur baru:

   

7. Mereka memilih templat penyebaran untuk App Service:

   

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

   

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

   

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

    

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

    

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

    

13. Mereka mengatur pemicu penyebaran berkelanjutan ke Diaktifkan:

    

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

    

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

    

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

    

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

    

    Alur rilis ditampilkan, seperti yang ditunjukkan di sini:

    

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

    

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

    

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

    

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

    

    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 bahwa front end 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

• Contoso menyediakan keamanan untuk database SmartHotel-Registration baru. Untuk informasi selengkapnya, lihat Azure SQL Database dan keamanan SQL Managed Instance.
• Secara khusus, Contoso memperbarui aplikasi web untuk menggunakan SSL dengan sertifikat.

Pencadangan

• Tim Contoso meninjau persyaratan pencadangan 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 failover untuk menyediakan failover regional untuk database. Untuk informasi selengkapnya, lihat Gambaran 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.

Pengoptimalan lisensi dan 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 and Billing untuk memastikan bahwa mereka beroperasi dalam anggaran yang ditetapkan oleh kepemimpinan IT 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.