Refaktor aplikasi Linux dengan menggunakan Azure App Service, Azure Traffic Manager, dan Azure Database for MySQL
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
danOSTICKETMYSQL
). - 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
).
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 diCentral 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.
Proses migrasi
Contoso menyelesaikan proses migrasi sebagai berikut:
- Sebagai langkah pertama, admin Contoso menyiapkan infrastruktur Azure, termasuk memprovisikan Azure App Service, menyiapkan Traffic Manager, dan memprovisikan instans Azure Database for MySQL.
- Setelah menyiapkan infrastruktur Azure, mereka memigrasikan database dengan menggunakan Azure Database Migration Service.
- Setelah database berjalan di Azure, admin mengunggah repositori privat GitHub untuk Azure App Service dengan pengiriman berkelanjutan, dan memuatnya dengan aplikasi osTicket.
- Di portal Microsoft Azure, mereka memuat aplikasi dari GitHub ke kontainer Docker dengan menjalankan Azure App Service.
- Admin menyesuaikan pengaturan DNS dan mengonfigurasi penskalaan otomatis untuk aplikasi.
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.
Mereka membuat sumber daya aplikasi web (
osticket-eus2
) di wilayah primer (East US 2
) melalui Azure Marketplace.Mereka menempatkan sumber daya dalam grup sumber daya produksi
ContosoRG
.Mereka membuat paket App Service,
APP-SVP-EUS2
, di wilayah utama, dan mereka menggunakan ukuran standar.Mereka memilih OS Linux dengan tumpukan runtime bahasa umum PHP 7.0, yang merupakan kontainer Docker.
Mereka membuat aplikasi web kedua,
osticket-cus
, dan paket Azure App Service untuk US Tengah.
Butuh bantuan lainnya?
- Pelajari tentang Aplikasi web Azure App Service.
- Pelajari tentang Azure App Service di Linux.
Langkah 2: Siapkan Traffic Manager
Admin Contoso menyiapkan Traffic Manager untuk mengarahkan permintaan web masuk ke aplikasi web yang berjalan di tingkat web osTicket.
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.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
.Setelah mereka menambahkan titik akhir, admin dapat memantaunya.
Butuh bantuan lainnya?
- Pelajari tentang Traffic Manager.
- Pelajari tentang perutean lalu lintas ke titik akhir prioritas.
Langkah 3: Provisikan Azure Database for MySQL
Admin Contoso memprovisikan instans database MySQL di wilayah utama, US Timur 2.
Di portal Microsoft Azure, mereka membuat sumber daya Azure Database for MySQL.
Mereka menambahkan nama
contosoosticket
untuk database Azure. Mereka menambahkan database ke grup sumber daya produksiContosoRG
dan kemudian menentukan informasi masuk.Database MySQL lokal adalah versi 5.7, sehingga mereka memilih versi ini untuk kompatibilitas. Mereka menggunakan ukuran default, yang sesuai dengan persyaratan database mereka.
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.
Mereka mengatur keamanan koneksi. Dalam database, mereka memilih Keamanan koneksi dan kemudian menyiapkan aturan firewall guna mengizinkan database mengakses layanan Azure.
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.
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) ataumy.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:
Membuat proyek migrasi yang didasarkan pada SKU Premium.
Tambahkan sumber (database lokal).
Pilih target.
Pilih database yang akan dimigrasikan.
Konfigurasikan pengaturan tingkat lanjut.
Mulai replikasi dan selesaikan semua kesalahan.
Lakukan cutover.
Pulihkan kunci asing dan pemicu.
Modifikasi aplikasi untuk menggunakan database baru.
Langkah 4b: Migrasikan database (MySQL Workbench)
Admin Contoso memeriksa prasyarat dan mengunduh MySQL Workbench.
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.Di MySQL Workbench, mereka membuat sambungan MySQL ke
osticketmysql
.Mereka mengekspor database sebagai
osticket
ke file mandiri lokal.Setelah mereka mencadangkan database secara lokal, admin membuat sambungan ke instans Azure Database for MySQL.
Sekarang, mereka dapat mengimpor (memulihkan) database dalam instans Azure Database for MySQL dari file mandiri. Skema baru,
osticket
, dibuat untuk instans.Setelah memulihkan data, admin dapat mengkuerinya dengan menggunakan MySQL Workbench. Data ditampilkan di portal Microsoft Azure.
Admin memperbarui informasi database di aplikasi web. Pada instans MySQL, mereka membuka String Koneksi.
Dalam daftar string koneksi, mereka memilih pengaturan aplikasi web dan kemudian menyalinnya dengan memilih Klik untuk menyalin.
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.
Mereka dapat memverifikasi nama server dan masuk melalui panel Gambaran Umum untuk instans MySQL di portal Microsoft Azure.
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.
Mereka menelusuri ke repositori GitHub publik perangkat lunak osTicket dan melakukan fork ke akun GitHub Contoso.
Setelah mereka melakukan fork pada repositori, mereka melakukan penelusuran ke folder
include
dan memilih fileost-config.php
.File terbuka di browser, dan mereka mengeditnya.
Dalam editor, admin memperbarui detail database, khususnya untuk
DBHOST
danDBUSER
.Mereka menerapkan perubahan.
Untuk setiap aplikasi web (
osticket-eus2
danosticket-cus
), di portal Microsoft Azure, mereka memilih Pengaturan aplikasi di panel sebelah kiri lalu memodifikasi pengaturan.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.
Langkah 6: Konfigurasikan aplikasi web
Sebagai langkah terakhir dalam proses migrasi, admin Contoso mengonfigurasi aplikasi web dengan situs web osTicket.
Di aplikasi web utama,
osticket-eus2
, mereka membuka Opsi penyebaran dan kemudian mengatur sumber ke GitHub.Mereka memilih opsi penyebaran.
Setelah mereka mengatur opsi, konfigurasi akan ditampilkan sebagai Tertunda di portal Microsoft Azure.
Setelah konfigurasi diperbarui dan aplikasi web osTicket dimuat dari GitHub ke kontainer Docker yang menjalankan Azure App Service, situs ditampilkan sebagai Aktif.
Mereka mengulangi langkah-langkah sebelumnya untuk aplikasi web sekunder,
osticket-cus
.Setelah situs dikonfigurasi, situs ini dapat diakses melalui profil Traffic Manager. Nama DNS adalah lokasi baru dari aplikasi osTicket. Pelajari selengkapnya.
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.Mereka mengonfigurasi aplikasi web
osticket-eus2
danosticket-cus
web untuk mengizinkan nama host kustom.
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.
Di App Service
APP-SVP-EUS2
, mereka membuka Unit Skala.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.
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.
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.