Refaktor aplikasi Linux dengan menggunakan Azure App Service, Azure Traffic Manager, dan Azure Database for MySQL

  • Artikel

Artikel ini menunjukkan cara perusahaan fiktif Contoso melakukan refaktor aplikasi berbasis LAMP dua tingkat, memigrasikannya dari lokal ke Azure dengan menggunakan Azure App Service dengan integrasi GitHub dan Azure Database for MySQL.

osTicket, aplikasi divisi layanan yang kami gunakan dalam contoh ini, disediakan sebagai perangkat lunak sumber terbuka. Jika ingin menggunakannya untuk tujuan pengujian Anda sendiri, Anda dapat mengunduhnya dari repositori osTicket di GitHub.

Pendorong bisnis

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

  • Mengejar pertumbuhan bisnis. Contoso tumbuh dan bergerak ke pasar baru. Dibutuhkan agen layanan pelanggan tambahan.
  • Skala. Solusi harus dibangun agar Contoso dapat menambahkan lebih banyak agen layanan pelanggan sebagai skala bisnis.
  • Meningkatkan ketahanan. Sebelumnya, masalah terkait sistem hanya memengaruhi pengguna internal. Dengan model bisnis baru, pengguna eksternal akan terpengaruh, dan Contoso membutuhkan aplikasi yang siap berjalan setiap saat.

Tujuan migrasi

Untuk menentukan metode migrasi terbaik, tim cloud Contoso telah menentukan tujuan mereka untuk migrasi ini:

  • Aplikasi harus menskalakan di luar kapasitas dan performa lokal saat ini. Contoso memindahkan aplikasi untuk memanfaatkan penskalaan sesuai permintaan dari Azure.
  • Contoso ingin memindahkan basis kode aplikasi ke alur pengiriman berkelanjutan. Karena perubahan aplikasi didorong ke GitHub, Contoso ingin menyebarkan perubahan tersebut tanpa tugas untuk staf operasi.
  • Aplikasi harus tangguh, dengan kemampuan untuk menangani pertumbuhan dan failover. Contoso ingin menyebarkan aplikasi di dua wilayah Azure yang berbeda dan mengaturnya untuk melakukan penskalaan secara otomatis.
  • Contoso ingin meminimalkan tugas admin database setelah aplikasi dipindahkan ke cloud.

Desain solusi

Setelah menyematkan tujuan dan persyaratan mereka, Contoso merancang dan meninjau solusi penyebaran, dan mengidentifikasi proses migrasi, termasuk layanan Azure yang akan digunakan untuk migrasi.

Arsitektur saat ini

  • Aplikasi ini dibuat bertingkat di dua mesin virtual (VM) (OSTICKETWEB dan OSTICKETMYSQL).
  • Mesin Virtual terletak di host contosohost1.contoso.com VMware ESXi (versi 6.5).
  • Lingkungan VMware dikelola oleh vCenter Server 6.5 (vcenter.contoso.com), berjalan pada mesin virtual.
  • Contoso memiliki pusat data lokal (contoso-datacenter) dengan pengendali domain lokal (contosodc1).

Diagram arsitektur saat ini.

Arsitektur yang diusulkan

Berikut adalah arsitektur yang diusulkan:

  • Aplikasi tingkat web di OSTICKETWEB akan dimigrasikan dengan membangun aplikasi web Azure App Service di dua wilayah Azure. Tim Contoso akan menerapkan Azure App Service untuk Linux dengan menggunakan kontainer PHP 7.0 Docker.
  • Kode aplikasi akan dipindahkan ke GitHub, dan aplikasi web Azure App Service akan dikonfigurasi untuk pengiriman berkelanjutan dengan GitHub.
  • Azure App Service akan disebarkan di wilayah utama (East US 2) dan wilayah sekunder (Central US).
  • Azure Traffic Manager akan disiapkan di depan dua aplikasi web di kedua wilayah.
  • Traffic Manager akan dikonfigurasi dalam mode prioritas untuk membuat lalu lintas melalui East US 2.
  • Jika server aplikasi Azure East US 2 sedang offline, pengguna dapat mengakses aplikasi yang di-fail over di Central US.
  • Database aplikasi akan dimigrasikan ke layanan Azure Database for MySQL dengan menggunakan Azure Database Migration Service. Database lokal akan dicadangkan secara lokal, dan dipulihkan langsung ke Azure Database for MySQL.
  • Database akan berada di wilayah utama (East US 2) di subnet database (PROD-DB-EUS2) dari jaringan produksi (VNET-PROD-EUS2).
  • Karena mereka memigrasikan beban kerja produksi, sumber daya Azure untuk aplikasi akan berada di grup ContosoRG sumber daya produksi.
  • Sumber daya Traffic Manager akan disebarkan dalam grup ContosoInfraRG sumber daya infrastruktur Contoso.
  • Mesin virtual lokal di pusat data Contoso akan dinonaktifkan setelah migrasi selesai.

Diagram arsitektur skenario.

Proses migrasi

Contoso menyelesaikan proses migrasi sebagai berikut:

  1. Sebagai langkah pertama, admin Contoso menyiapkan infrastruktur Azure, termasuk memprovisikan Azure App Service, menyiapkan Traffic Manager, dan memprovisikan instans Azure Database for MySQL.
  2. Setelah menyiapkan infrastruktur Azure, mereka memigrasikan database dengan menggunakan Azure Database Migration Service.
  3. Setelah database berjalan di Azure, admin mengunggah repositori privat GitHub untuk Azure App Service dengan pengiriman berkelanjutan, dan memuatnya dengan aplikasi osTicket.
  4. Di portal Microsoft Azure, mereka memuat aplikasi dari GitHub ke kontainer Docker dengan menjalankan Azure App Service.
  5. Admin menyesuaikan pengaturan DNS dan mengonfigurasi penskalaan otomatis untuk aplikasi.

Diagram proses migrasi Contoso.

Layanan Azure

Layanan Deskripsi Biaya
Azure App Service Layanan ini menjalankan dan menskalakan aplikasi dengan menggunakan platform Azure sebagai layanan (PaaS) untuk situs web. Harga didasarkan pada ukuran instans dan fitur yang diperlukan. Pelajari selengkapnya.
Azure Traffic Manager Penyeimbang muatan yang menggunakan Sistem Nama Domain (DNS) untuk mengarahkan pengguna ke Azure atau ke situs web dan layanan eksternal. Harga didasarkan pada jumlah kueri DNS yang diterima dan jumlah titik akhir yang dipantau. Pelajari selengkapnya.
Layanan Migrasi Database Azure Azure Database Migration Service memungkinkan migrasi tanpa hambatan dari berbagai sumber database ke platform data Azure dengan waktu henti minimal. Pelajari tentang wilayah yang didukung dan harga Azure Database Migration Service.
Azure Database untuk MySQL Database ini didasarkan pada mesin database MySQL sumber terbuka. Hal ini menyediakan database MySQL komunitas yang dikelola penuh dan siap digunakan oleh perusahaan untuk pengembangan dan penyebaran aplikasi. Harga didasarkan pada persyaratan komputasi, penyimpanan, dan pencadangan. Pelajari selengkapnya.

Prasyarat

Untuk menjalankan skenario ini, Contoso harus memenuhi prasyarat berikut:

Persyaratan Detail
Langganan Azure Contoso membuat langganan sebelumnya dalam seri artikel 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 ada dan bukan merupakan administrator, Anda perlu bekerja dengan admin untuk menetapkan izin Pemilik atau Kontributor bagi Anda.
Infrastruktur Azure Contoso menyiapkan infrastruktur Azure seperti yang dijelaskan dalam Infrastruktur Azure untuk migrasi.

Langkah skenario

Berikut adalah rencana Contoso untuk menyelesaikan migrasi:

  • Langkah 1: Provisikan Azure App Service. Admin Contoso akan memprovisikan aplikasi web di wilayah primer dan sekunder.
  • Langkah 2: Siapkan Traffic Manager. Mereka mengatur Traffic Manager di depan aplikasi web, untuk perutean dan penyeimbangan beban lalu lintas.
  • Langkah 3: Provisikan Azure Database for MySQL. Di Azure, mereka memprovisikan instans Azure Database for MySQL.
  • Langkah 4: Migrasi database. Mereka memigrasikan database dengan menggunakan Azure Database Migration Service.
  • Langkah 5: Siapkan GitHub. Mereka menyiapkan repositori GitHub lokal untuk situs web aplikasi dan kode.
  • Langkah 6: Konfigurasikan aplikasi web. Mereka mengonfigurasi aplikasi web dengan situs web osTicket.

Langkah 1: Provisikan Azure App Service

Admin Contoso memprovisikan dua aplikasi web (satu di setiap wilayah) dengan menggunakan Azure App Service.

  1. Mereka membuat sumber daya aplikasi web (osticket-eus2) di wilayah primer (East US 2) melalui Azure Marketplace.

  2. Mereka menempatkan sumber daya dalam grup sumber daya produksi ContosoRG.

    Cuplikan layar panel Aplikasi Web untuk membuat aplikasi web di Linux.

  3. Mereka membuat paket App Service, APP-SVP-EUS2, di wilayah utama, dan mereka menggunakan ukuran standar.

    Cuplikan layar panel Paket App Service Baru untuk membuat paket App Service.

  4. Mereka memilih OS Linux dengan tumpukan runtime bahasa umum PHP 7.0, yang merupakan kontainer Docker.

    Cuplikan layar panel Aplikasi Web, dengan OS Linux, lokasi US Timur 2, dan PHP 7.0 dipilih.

  5. Mereka membuat aplikasi web kedua, osticket-cus, dan paket Azure App Service untuk US Tengah.

    Cuplikan layar panel Aplikasi Web, dengan OS Linux, lokasi US Tengah, dan PHP 7.0 dipilih.

Butuh bantuan lainnya?

Langkah 2: Siapkan Traffic Manager

Admin Contoso menyiapkan Traffic Manager untuk mengarahkan permintaan web masuk ke aplikasi web yang berjalan di tingkat web osTicket.

  1. Di Marketplace Azure, mereka membuat sumber daya Traffic Manager, osticket.trafficmanager.net. Mereka menggunakan perutean prioritas sehingga US Timur 2 adalah situs primer. Mereka menempatkan sumber daya dalam grup sumber daya infrastruktur yang ada, ContosoInfraRG. Perhatikan bahwa Traffic Manager bersifat global dan tidak terikat pada lokasi tertentu.

    Cuplikan layar panel Buat profil Traffic Manager.

  2. Mereka mengonfigurasi Traffic Manager dengan titik akhir. Mereka menambahkan aplikasi web di US Timur 2 sebagai situs primer, osticket-eus2, dan aplikasi web di US Tengah sebagai situs sekunder, osticket-cus.

    Cuplikan layar panel Tambahkan titik akhir di Traffic Manager.

  3. Setelah mereka menambahkan titik akhir, admin dapat memantaunya.

    Cuplikan layar panel Titik Akhir untuk memantau titik akhir di Traffic Manager.

Butuh bantuan lainnya?

Langkah 3: Provisikan Azure Database for MySQL

Admin Contoso memprovisikan instans database MySQL di wilayah utama, US Timur 2.

  1. Di portal Microsoft Azure, mereka membuat sumber daya Azure Database for MySQL.

    Cuplikan layar tautan Azure Database for MySQL di portal Azure.

  2. Mereka menambahkan nama contosoosticket untuk database Azure. Mereka menambahkan database ke grup sumber daya produksi ContosoRG dan kemudian menentukan informasi masuk.

  3. Database MySQL lokal adalah versi 5.7, sehingga mereka memilih versi ini untuk kompatibilitas. Mereka menggunakan ukuran default, yang sesuai dengan persyaratan database mereka.

    Cuplikan layar panel MySQL Server, dengan versi 5.7 dipilih.

  4. Untuk Opsi Redundansi Cadangan, mereka memilih Geo-Redundant. Opsi ini memungkinkan mereka untuk memulihkan database di wilayah sekunder mereka (US Tengah) jika terjadi pemadaman. Mereka dapat mengonfigurasi opsi ini hanya pada saat mereka memprovisikan database.

    Cuplikan layar panel Opsi Redundansi Cadangan, dengan opsi Geo-Redundant dipilih.

  5. Mereka mengatur keamanan koneksi. Dalam database, mereka memilih Keamanan koneksi dan kemudian menyiapkan aturan firewall guna mengizinkan database mengakses layanan Azure.

  6. Mereka menambahkan alamat IP klien stasiun kerja lokal ke alamat IP awal dan akhir. Hal ini memungkinkan aplikasi web mengakses database MySQL, bersama dengan klien database yang melakukan migrasi.

    Cuplikan layar panel Keamanan koneksi, memperlihatkan akses ke layanan Azure diaktifkan dan alamat IP klien dipilih.

Langkah 4: Migrasikan database

Ada beberapa cara untuk memindahkan database MySQL. Setiap opsi mengharuskan admin Contoso membuat instans Azure Database for MySQL untuk target. Setelah membuat instans, mereka dapat memigrasikan database menggunakan salah satu dari dua jalur:

  • Langkah 4a: Azure Database Migration Service
  • Langkah 4b: Cadangan dan pemulihan MySQL Workbench

Langkah 4a: Migrasikan database melalui Azure Database Migration Service

Admin Contoso memigrasikan database melalui Azure Database Migration Service dengan mengikuti tutorial migrasi langkah demi langkah. Mereka dapat melakukan migrasi online, offline, dan hibrida (pratinjau) dengan menggunakan MySQL 5.6 atau 5.7.

Catatan

MySQL 8.0 didukung di Azure Database for MySQL, tetapi alat Database Migration Service belum mendukung versi ini.

Singkatnya, Contoso melakukan hal berikut:

  • Mereka memastikan bahwa semua prasyarat migrasi terpenuhi:

    • Sumber server database MySQL harus cocok dengan versi yang didukung oleh Azure Database for MySQL. Azure Database for MySQL mendukung MySQL Community Edition, mesin penyimpanan InnoDB, dan migrasi di seluruh sumber dan target dengan versi yang sama.

    • Mereka mengaktifkan pengelogan biner di my.ini (Windows) atau my.cnf (Unix). Kegagalan melakukan hal ini akan menyebabkan kesalahan berikut dalam Wizard Migrasi:

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      Untuk informasi selengkapnya, lihat Opsi dan variabel pengelogan biner dalam dokumentasi MySQL.

    • Pengguna harus memiliki peran ReplicationAdmin.

    • Migrasikan skema database tanpa kunci asing dan pemicu.

  • Mereka membuat Jaringan Privat Maya (VPN) yang tersambung melalui ExpressRoute atau VPN ke jaringan lokal.

  • Mereka membuat instans Azure Database Migration Service dengan SKU Premium yang tersambung ke jaringan virtual.

  • Mereka memastikan bahwa Azure Database Migration Service dapat mengakses database MySQL melalui jaringan virtual. Hal ini juga termasuk memastikan bahwa semua port masuk diizinkan dari Azure ke MySQL di tingkat jaringan virtual, VPN jaringan, dan mesin yang menghosting MySQL.

  • Mereka menjalankan alat Database Migration Service kemudian melakukan hal berikut:

    1. Membuat proyek migrasi yang didasarkan pada SKU Premium.

      Cuplikan layar panel Gambaran Umum MySQL, dengan pesan yang mengatakan bahwa layanan migrasi berhasil dibuat.

      Cuplikan layar panel proyek migrasi Baru MySQL.

    2. Tambahkan sumber (database lokal).

      Cuplikan layar panel Tambahkan Detail sumber wizard Migrasi.

    3. Pilih target.

      Cuplikan layar panel Detail target wizard migrasi.

    4. Pilih database yang akan dimigrasikan.

      Cuplikan layar wizard Migrasi Petakan ke panel database target.

    5. Konfigurasikan pengaturan tingkat lanjut.

      Cuplikan layar panel Pengaturan migrasi wizard Migrasi.

    6. Mulai replikasi dan selesaikan semua kesalahan.

      Cuplikan layar panel detail server.

    7. Lakukan cutover.

      Cuplikan layar panel detail osTicket.

      Cuplikan layar panel Selesaikan cutover.

      Cuplikan layar tabel status aktivitas migrasi.

    8. Pulihkan kunci asing dan pemicu.

    9. Modifikasi aplikasi untuk menggunakan database baru.

      Cuplikan layar tabel Aktivitas Migrasi.

Langkah 4b: Migrasikan database (MySQL Workbench)

  1. Admin Contoso memeriksa prasyarat dan mengunduh MySQL Workbench.

  2. Mereka menginstal MySQL Workbench untuk Windows sesuai dengan instruksi penginstalan. Mesin tempat mereka menginstal MySQL Workbench harus dapat diakses oleh mesin virtual osticketmysql dan Azure melalui internet.

  3. Di MySQL Workbench, mereka membuat sambungan MySQL ke osticketmysql.

    Cuplikan layar panel detail koneksi MySQL Workbench.

  4. Mereka mengekspor database sebagai osticket ke file mandiri lokal.

    Cuplikan layar panel Ekspor Data MySQL Workbench.

  5. Setelah mereka mencadangkan database secara lokal, admin membuat sambungan ke instans Azure Database for MySQL.

    Panel Penyiapan Koneksi Baru MySQL Workbench.

  6. Sekarang, mereka dapat mengimpor (memulihkan) database dalam instans Azure Database for MySQL dari file mandiri. Skema baru, osticket, dibuat untuk instans.

    Cuplikan layar panel Impor Data MySQL Workbench.

  7. Setelah memulihkan data, admin dapat mengkuerinya dengan menggunakan MySQL Workbench. Data ditampilkan di portal Microsoft Azure.

    Cuplikan layar portal Azure, menampilkan data yang dipulihkan.

    Cuplikan layar bilah database MySQL, dengan panah yang menunjuk ke database osTicket.

  8. Admin memperbarui informasi database di aplikasi web. Pada instans MySQL, mereka membuka String Koneksi.

    Cuplikan layar tautan String Koneksi di instans MySQL.

  9. Dalam daftar string koneksi, mereka memilih pengaturan aplikasi web dan kemudian menyalinnya dengan memilih Klik untuk menyalin.

    Cuplikan layar pengaturan aplikasi web di instans MySQL.

  10. Mereka membuka file baru di Notepad, menempelkan untai (karakter) ke dalamnya, dan memperbarui untai (karakter) agar sesuai dengan database osTicket, instans MySQL, dan pengaturan informasi masuk.

    Cuplikan layar string koneksi yang ditempelkan dalam file Notepad.

  11. Mereka dapat memverifikasi nama server dan masuk melalui panel Gambaran Umum untuk instans MySQL di portal Microsoft Azure.

    Cuplikan layar panel grup sumber daya, menampilkan nama server dan nama akun admin server.

Langkah 5: Siapkan GitHub

Admin Contoso membuat repositori GitHub privat baru dan menyiapkan sambungan ke database osTicket di Azure Database for MySQL. Kemudian, mereka memuat aplikasi web ke Azure App Service.

  1. Mereka menelusuri ke repositori GitHub publik perangkat lunak osTicket dan melakukan fork ke akun GitHub Contoso.

    Cuplikan layar halaman repositori GitHub, menyoroti tombol Fork.

  2. Setelah mereka melakukan fork pada repositori, mereka melakukan penelusuran ke folder include dan memilih file ost-config.php.

    Cuplikan layar file PHP di GitHub.

  3. File terbuka di browser, dan mereka mengeditnya.

    Cuplikan layar ikon edit file (pensil) di GitHub.

  4. Dalam editor, admin memperbarui detail database, khususnya untuk DBHOST dan DBUSER.

    Cuplikan layar panel edit file di GitHub.

  5. Mereka menerapkan perubahan.

    Cuplikan layar menyoroti tombol Terapkan perubahan pada panel edit.

  6. Untuk setiap aplikasi web (osticket-eus2 dan osticket-cus), di portal Microsoft Azure, mereka memilih Pengaturan aplikasi di panel sebelah kiri lalu memodifikasi pengaturan.

    Cuplikan layar menyoroti tautan Pengaturan aplikasi di portal Azure.

  7. Mereka memasukkan string koneksi dengan nama osticket, dan menyalin untai (karakter) dari Notepad ke area nilai. Mereka memilih MySQL di daftar dropdown di samping untai (karakter), dan menyimpan pengaturan.

    Cuplikan layar panel String koneksi, menyoroti string koneksi osTicket.

Langkah 6: Konfigurasikan aplikasi web

Sebagai langkah terakhir dalam proses migrasi, admin Contoso mengonfigurasi aplikasi web dengan situs web osTicket.

  1. Di aplikasi web utama, osticket-eus2, mereka membuka Opsi penyebaran dan kemudian mengatur sumber ke GitHub.

    Cuplikan layar panel opsi Penyebaran, dengan GitHub dipilih sebagai sumbernya.

  2. Mereka memilih opsi penyebaran.

    Cuplikan layar detail opsi pada panel opsi Penyebaran.

  3. Setelah mereka mengatur opsi, konfigurasi akan ditampilkan sebagai Tertunda di portal Microsoft Azure.

    Cuplikan layar panel Opsi penyebaran, memperlihatkan status situs yang tertunda.

  4. Setelah konfigurasi diperbarui dan aplikasi web osTicket dimuat dari GitHub ke kontainer Docker yang menjalankan Azure App Service, situs ditampilkan sebagai Aktif.

    Cuplikan layar panel Opsi penyebaran.

  5. Mereka mengulangi langkah-langkah sebelumnya untuk aplikasi web sekunder, osticket-cus.

  6. Setelah situs dikonfigurasi, situs ini dapat diakses melalui profil Traffic Manager. Nama DNS adalah lokasi baru dari aplikasi osTicket. Pelajari selengkapnya.

    Cuplikan layar panel profil Traffic Manager, menampilkan nama DNS.

  7. Contoso ingin menggunakan nama DNS yang mudah diingat. Pada panel Rekaman Sumber Daya Baru, mereka membuat alias, CNAME, dan nama domain yang sepenuhnya memenuhi syarat, osticket.contoso.com, yang menunjuk ke nama Traffic Manager di DNS pada pengendali domain mereka.

    Cuplikan layar panel Rekaman Sumber Daya Baru, menampilkan nama alias dan penunjuk ke Traffic Manager.

  8. Mereka mengonfigurasi aplikasi web osticket-eus2 dan osticket-cus web untuk mengizinkan nama host kustom.

    Cuplikan layar panel Nama host iklan, menyoroti tombol Validasi.

Menyiapkan penskalaan otomatis

Terakhir, admin Contoso menyiapkan penskalaan otomatis untuk aplikasi. Penskalaan otomatis memastikan bahwa, ketika agen menggunakan aplikasi, instans aplikasi meningkat dan menurun sesuai dengan kebutuhan bisnis.

  1. Di App Service APP-SVP-EUS2, mereka membuka Unit Skala.

  2. Mereka mengonfigurasi pengaturan skala otomatis baru dengan satu aturan yang meningkatkan jumlah instans sebesar satu ketika penggunaan CPU untuk instans saat ini berada di atas 70 persen selama 10 menit.

    Cuplikan layar halaman pengaturan skala otomatis untuk wilayah pertama.

  3. Mereka mengonfigurasi pengaturan yang sama di APP-SVP-CUS untuk memastikan bahwa perilaku yang sama berlaku jika aplikasi melakukan fail over ke wilayah sekunder. Satu-satunya perbedaan adalah bahwa mereka mengatur instans default ke 1, karena hal ini hanya berlaku untuk failover.

    Cuplikan layar halaman pengaturan skala otomatis untuk wilayah kedua.

Membersihkan setelah migrasi

Dengan migrasi yang sudah selesai, aplikasi osTicket direfaktor untuk berjalan di aplikasi web Azure App Service dengan pengiriman berkelanjutan menggunakan repositori GitHub privat. Aplikasi ini berjalan di dua wilayah untuk meningkatkan ketahanan. Database osTicket berjalan di Azure Database for MySQL setelah migrasi ke platform PaaS.

Untuk membersihkan setelah migrasi, Contoso melakukan hal berikut:

  • Mereka menghapus mesin virtual VMware dari inventaris vCenter Server.
  • Mereka menghapus mesin virtual lokal dari pekerjaan cadangan lokal.
  • Mereka memperbarui dokumentasi internal untuk menunjukkan lokasi baru dan alamat IP.
  • Mereka mengulas sumber daya apa pun yang berinteraksi dengan mesin virtual lokal, dan memperbarui pengaturan atau dokumentasi yang relevan untuk mencerminkan konfigurasi yang baru.
  • Mereka mengonfigurasi ulang pemantauan untuk menunjuk ke URL osticket.trafficmanager.net, untuk melacak bahwa aplikasi sudah siap dan berjalan.

Tinjau penyebaran

Dengan aplikasi yang sekarang berjalan, Contoso perlu mengoperasikan dan mengamankan infrastruktur baru mereka sepenuhnya.

Keamanan

Tim keamanan Contoso mengulas aplikasi untuk menentukan masalah keamanan apa pun. Mereka mengidentifikasi bahwa komunikasi antara aplikasi osTicket dan instans database MySQL tidak dikonfigurasi untuk SSL. Mereka melakukan semua ini untuk memastikan bahwa lalu lintas database tidak dapat diretas. Pelajari selengkapnya.

Pencadangan

  • Aplikasi web osTicket tidak berisi data status dan dengan demikian tidak memerlukan cadangan.
  • Tim Contoso tidak perlu mengonfigurasi cadangan untuk database. Azure Database for MySQL secara otomatis membuat cadangan server dan menyimpannya. Tim memilih untuk menggunakan geo-redundansi untuk database, sehingga database bersifat tangguh dan siap produksi. Pencadangan dapat digunakan untuk memulihkan server mereka ke satu titik waktu. Pelajari selengkapnya.

Optimalisasi lisensi dan biaya

  • Tidak ada masalah lisensi untuk penyebaran PaaS.
  • Contoso akan menggunakan Azure Cost Management + Billing untuk memastikan bahwa mereka tetap sesuai dengan anggaran yang ditetapkan oleh pimpinan IT mereka.