Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Migrasikan beban kerja kontainer Anda dari Azure Red Hat OpenShift (ARO) ke (ROSA Layanan OpenShift Red Hat di AWS )
Naveen Ramasamy, Srikanth Rangavajhala, dan Gireesh Sreekantan, Amazon Web Services
Ringkasan
Pola ini memberikan step-by-step instruksi untuk memigrasikan beban kerja kontainer dari Azure Red Hat OpenShift (ARO) ke Layanan OpenShift Red Hat di AWS (
Migrasi beban kerja kontainer dari ARO, dari cloud lain, atau dari tempat ke ROSA melibatkan transfer aplikasi, konfigurasi, dan data dari satu platform ke platform lainnya. Pola ini membantu memastikan transisi yang mulus sambil mengoptimalkan AWS Cloud layanan, keamanan, dan efisiensi biaya. Ini mencakup dua metode untuk memigrasikan beban kerja Anda ke kluster ROSA: CI/CD dan Migration Toolkit for Containers (MTC).
Pola ini mencakup kedua metode. Metode yang Anda pilih tergantung pada kompleksitas dan kepastian proses migrasi Anda. Jika Anda memiliki kontrol penuh atas status aplikasi Anda dan dapat menjamin pengaturan yang konsisten melalui pipeline, kami sarankan Anda menggunakan CI/CD metode ini. Namun, jika status aplikasi Anda melibatkan ketidakpastian, perubahan tak terduga, atau ekosistem yang kompleks, sebaiknya gunakan MTC sebagai jalur yang andal dan terkontrol untuk memigrasikan aplikasi dan datanya ke klaster baru. Untuk perbandingan rinci dari dua metode, lihat bagian Informasi tambahan.
Manfaat bermigrasi ke ROSA:
ROSA terintegrasi dengan mulus AWS sebagai layanan asli. Ini mudah diakses melalui Konsol Manajemen AWS dan ditagih melalui satu Akun AWS. Ini menawarkan kompatibilitas penuh dengan yang lain Layanan AWS dan memberikan dukungan kolaboratif dari keduanya AWS dan Red Hat.
ROSA mendukung penyebaran hybrid dan multi-cloud. Ini memungkinkan aplikasi berjalan secara konsisten di pusat data lokal dan beberapa lingkungan cloud.
ROSA mendapat manfaat dari fokus keamanan Red Hat, dan menyediakan fitur seperti kontrol akses berbasis peran (RBAC), pemindaian gambar, dan penilaian kerentanan untuk memastikan lingkungan wadah yang aman.
ROSA dirancang untuk menskalakan aplikasi dengan mudah dan menyediakan opsi ketersediaan tinggi. Ini memungkinkan aplikasi tumbuh sesuai kebutuhan sambil mempertahankan keandalan.
ROSA mengotomatiskan dan menyederhanakan penerapan klaster Kubernetes dibandingkan dengan pengaturan manual dan metode manajemen. Ini mempercepat proses pengembangan dan penyebaran.
ROSA mendapat manfaat dari AWS Cloud layanan, dan menyediakan integrasi tanpa batas dengan AWS penawaran seperti layanan basis data, solusi penyimpanan, dan layanan keamanan.
Prasyarat dan batasan
Prasyarat
Aktif Akun AWS.
Izin yang dikonfigurasi untuk ROSA Layanan AWS yang bergantung pada untuk memberikan fungsionalitas. Untuk informasi lebih lanjut, lihat Prasyarat dalam dokumentasi ROSA.
ROSA diaktifkan pada konsol ROSA
. Untuk instruksi, lihat dokumentasi ROSA. Cluster ROSA diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat Memulai ROSA di dokumentasi ROSA. Untuk memahami berbagai metode untuk menyiapkan cluster ROSA, lihat Panduan AWS Preskriptif panduan strategi implementasi ROSA.
Konektivitas jaringan dibuat dari jaringan lokal ke AWS melalui AWS Direct Connect(lebih disukai) atau AWS Virtual Private Network (Site-to-Site VPN).
Instans Amazon Elastic Compute Cloud (Amazon EC2) atau server virtual lain untuk menginstal alat seperti
aws client, klien OpenShift CLIoc(), klien ROSA, dan biner Git.
Prasyarat tambahan untuk metode ini: CI/CD
Akses ke server Jenkins lokal dengan izin untuk membuat pipeline baru, menambahkan tahapan, menambahkan OpenShift kluster, dan melakukan build.
Akses ke repositori Git tempat kode sumber aplikasi dipertahankan, dengan izin untuk membuat cabang Git baru dan melakukan commit ke cabang baru.
Prasyarat tambahan untuk metode MTC:
Bucket Amazon Simple Storage Service (Amazon S3), yang akan digunakan sebagai repositori replikasi.
Akses administratif ke cluster ARO sumber. Ini diperlukan untuk mengatur koneksi MTC.
Batasan
Beberapa Layanan AWS tidak tersedia di semua Wilayah AWS. Untuk ketersediaan Wilayah, lihat Layanan AWS berdasarkan Wilayah
. Untuk titik akhir tertentu, lihat halaman titik akhir dan kuota Layanan, dan pilih tautan untuk layanan.
Arsitektur
ROSA menyediakan tiga pola penyebaran jaringan: publik, pribadi, dan. AWS PrivateLink PrivateLinkmemungkinkan tim rekayasa keandalan situs Red Hat (SRE) untuk mengelola cluster dengan menggunakan subnet pribadi yang terhubung ke PrivateLink titik akhir cluster dalam VPC yang ada.
Memilih PrivateLink opsi menyediakan konfigurasi paling aman. Untuk alasan itu, kami merekomendasikannya untuk beban kerja yang sensitif atau persyaratan kepatuhan yang ketat. Untuk informasi tentang opsi penyebaran jaringan publik dan pribadi, lihat OpenShift dokumentasi Red Hat
penting
Anda dapat membuat PrivateLink cluster hanya pada waktu instalasi. Anda tidak dapat mengubah cluster untuk digunakan PrivateLink setelah instalasi.
Diagram berikut menggambarkan PrivateLink arsitektur untuk klaster ROSA yang digunakan Direct Connect untuk terhubung ke lingkungan lokal dan ARO.
AWS izin untuk ROSA
Untuk AWS izin ke ROSA, kami sarankan Anda menggunakan AWS Security Token Service (AWS STS) dengan token dinamis yang berumur pendek. Metode ini menggunakan peran dan kebijakan yang telah ditentukan dengan hak istimewa paling sedikit untuk memberikan izin minimal ROSA untuk beroperasi di, dan mendukung instalasi ROSA, bidang kontrol Akun AWS, dan fungsionalitas komputasi.
Pemindahan pipa CI/CD
CI/CD pipeline redeployment is the recommended method for users who have a mature CI/CDpipa. Ketika Anda memilih opsi ini, Anda dapat menggunakan strategi DevOps penyebaran apa pun untuk secara bertahap mengalihkan beban aplikasi Anda ke penerapan di ROSA.
catatan
Pola ini mengasumsikan kasus penggunaan umum di mana Anda memiliki pipeline Git, JFrog Artifactory, dan Jenkins lokal. Pendekatan ini mengharuskan Anda membuat konektivitas jaringan dari jaringan lokal ke AWS jaringan lokal Direct Connect, dan menyiapkan klaster ROSA sebelum mengikuti petunjuk di bagian Epics. Lihat bagian Prasyarat untuk detailnya.
Diagram berikut menunjukkan alur kerja untuk metode ini.
Metode MTC
Anda dapat menggunakan Migration Toolkit for Containers (MTC)
Diagram berikut menunjukkan alur kerja untuk metode ini.
Alat
Layanan AWS
AWS DataSyncadalah layanan transfer dan penemuan data online yang membantu Anda memindahkan file atau data objek ke, dari, dan di antara layanan AWS penyimpanan.
AWS Direct Connectmenghubungkan jaringan internal Anda ke Direct Connect lokasi melalui kabel serat optik Ethernet standar. Dengan koneksi ini, Anda dapat membuat antarmuka virtual langsung ke publik Layanan AWS sambil melewati penyedia layanan internet di jalur jaringan Anda.
AWS PrivateLinkmembantu Anda membuat koneksi pribadi searah dari cloud pribadi virtual Anda (VPCs) ke layanan di luar VPC.
Layanan OpenShift Red Hat di AWS (ROSA) adalah layanan terkelola yang membantu OpenShift pengguna Red Hat untuk membangun, menskalakan, dan mengelola aplikasi kontainer. AWS
AWS Security Token Service (AWS STS) membantu Anda meminta kredensyal hak istimewa terbatas sementara untuk pengguna.
Alat-alat lainnya
Migration Toolkit for Containers (MTC)
menyediakan konsol dan API untuk memigrasi aplikasi kontainer dari ARO ke ROSA.
Praktik terbaik
Untuk ketahanan dan jika Anda memiliki beban kerja kepatuhan keamanan, siapkan klaster ROSA multi-AZ yang menggunakan. PrivateLink Untuk informasi lebih lanjut, lihat dokumentasi ROSA.
catatan
PrivateLink tidak dapat dikonfigurasi setelah instalasi.
Bucket S3 yang Anda gunakan untuk repositori replikasi tidak boleh bersifat publik. Gunakan kebijakan bucket S3 yang sesuai untuk membatasi akses.
Jika Anda memilih metode MTC, gunakan opsi migrasi Tahap untuk mengurangi jendela downtime selama cutover.
Tinjau kuota layanan Anda sebelum dan sesudah Anda menyediakan klaster ROSA. Jika perlu, mintalah peningkatan kuota sesuai dengan kebutuhan Anda. Untuk informasi lebih lanjut, lihat dokumentasi Service Quotas.
Tinjau pedoman keamanan ROSA dan terapkan praktik terbaik keamanan.
Kami menyarankan Anda menghapus administrator cluster default setelah instalasi. Untuk informasi selengkapnya, lihat OpenShift dokumentasi Red Hat
. Gunakan penskalaan otomatis kumpulan mesin untuk mengurangi node pekerja yang tidak digunakan di klaster ROSA untuk mengoptimalkan biaya. Untuk informasi lebih lanjut, lihat Lokakarya ROSA
. Gunakan layanan Red Hat Cost Management untuk OpenShift Container Platform untuk lebih memahami dan melacak biaya cloud dan kontainer. Untuk informasi lebih lanjut, lihat Lokakarya ROSA
. Memantau dan mengaudit layanan dan aplikasi infrastruktur klaster ROSA dengan menggunakan Layanan AWS. Untuk informasi lebih lanjut, lihat Lokakarya ROSA
.
Epik
| Tugas | Deskripsi | Keterampilan yang dibutuhkan |
|---|---|---|
Tambahkan cluster ROSA baru ke Jenkins. |
| Administrator AWS, administrator sistem AWS, AWS DevOps |
Tambahkan |
| Administrator AWS, administrator sistem AWS, AWS DevOps |
Buat cabang Git baru. | Buat cabang baru di repositori Git Anda untuk. | AWS DevOps |
Tag gambar untuk ROSA. | Di tahap build Anda, gunakan tag yang berbeda untuk mengidentifikasi gambar yang dibuat dari pipeline ROSA. | Administrator AWS, administrator sistem AWS, AWS DevOps |
Buat pipa. | Buat pipeline Jenkins baru yang mirip dengan pipeline Anda yang ada. Untuk pipeline ini, gunakan cabang | Administrator AWS, administrator sistem AWS, AWS DevOps |
Tambahkan tahap penerapan ROSA. | Di pipeline baru, tambahkan tahapan untuk diterapkan ke cluster ROSA dan referensi cluster ROSA yang Anda tambahkan ke konfigurasi global Jenkins. | Administrator AWS, AWS DevOps, administrator sistem AWS |
Mulai membangun baru. | Di Jenkins, pilih pipeline Anda dan pilih Build now, atau mulai build baru dengan melakukan perubahan ke | Administrator AWS, AWS DevOps, administrator sistem AWS |
Verifikasi penyebaran. | Gunakan perintah oc atau konsol ROSA | Administrator AWS, AWS DevOps, administrator sistem AWS |
Salin data ke cluster target. | Untuk beban kerja stateful, salin data dari cluster sumber ke cluster target dengan menggunakan AWS DataSync atau utilitas open source seperti rsync, atau Anda dapat menggunakan metode MTC. Lihat informasi yang lebih lengkap dalam dokumentasi AWS DataSync. | Administrator AWS, AWS DevOps, administrator sistem AWS |
Uji aplikasi Anda. |
| Administrator AWS, AWS DevOps, administrator sistem AWS |
Potong. | Jika pengujian Anda berhasil, gunakan kebijakan Amazon Route 53 yang sesuai untuk memindahkan lalu lintas dari aplikasi yang dihosting ARO ke aplikasi yang dihosting Rosa-host. Saat Anda menyelesaikan langkah ini, beban kerja aplikasi Anda akan sepenuhnya beralih ke klaster ROSA. | Administrator AWS, administrator sistem AWS |
| Tugas | Deskripsi | Keterampilan yang dibutuhkan |
|---|---|---|
Instal operator MTC. | Instal operator MTC pada cluster ARO dan ROSA:
| Administrator AWS, AWS DevOps, administrator sistem AWS |
Konfigurasikan lalu lintas jaringan ke repositori replikasi. | Jika Anda menggunakan server proxy, konfigurasikan untuk memungkinkan lalu lintas jaringan antara repositori replikasi dan cluster. Repositori replikasi adalah objek penyimpanan perantara yang digunakan MTC untuk memigrasikan data. Cluster sumber dan target harus memiliki akses jaringan ke repositori replikasi selama migrasi. | Administrator AWS, AWS DevOps, administrator sistem AWS |
Tambahkan cluster sumber ke MTC. | Di konsol web MTC, tambahkan cluster sumber ARO. | Administrator AWS, AWS DevOps, administrator sistem AWS |
Tambahkan Amazon S3 sebagai repositori replikasi Anda. | Di konsol web MTC, tambahkan bucket Amazon S3 (lihat Prasyarat) sebagai repositori replikasi. | Administrator AWS, AWS DevOps, administrator sistem AWS |
Buat rencana migrasi. | Di konsol web MTC, buat rencana migrasi dan tentukan jenis transfer data sebagai Salin. Ini akan menginstruksikan MTC untuk menyalin data dari cluster sumber (ARO) ke bucket S3, dan dari bucket ke cluster target (ROSA). | Administrator AWS, AWS DevOps, administrator sistem AWS |
Jalankan rencana migrasi. | Jalankan paket migrasi dengan menggunakan opsi Stage atau Cutover:
| Administrator AWS, AWS DevOps, administrator sistem AWS |
Pemecahan Masalah
| Isu | Solusi |
|---|---|
Masalah konektivitas | Saat memigrasikan beban kerja kontainer dari ARO ke ROSA, Anda mungkin mengalami masalah konektivitas yang harus diselesaikan untuk memastikan migrasi berhasil. Untuk mengatasi masalah konektivitas ini (tercantum dalam tabel ini) selama migrasi, perencanaan yang cermat, koordinasi dengan jaringan dan tim keamanan Anda, dan pengujian menyeluruh sangat penting. Menerapkan strategi migrasi bertahap dan memverifikasi konektivitas di setiap langkah akan membantu meminimalkan potensi gangguan dan memastikan transisi yang mulus dari ARO ke ROSA. |
Perbedaan konfigurasi jaringan | ARO dan ROSA mungkin memiliki variasi dalam konfigurasi jaringan mereka, seperti pengaturan jaringan virtual (VNet), subnet, dan kebijakan jaringan. Untuk komunikasi yang tepat antar layanan, pastikan pengaturan jaringan sejajar antara kedua platform. |
Grup keamanan dan aturan firewall | ROSA dan ARO mungkin memiliki grup keamanan default dan pengaturan firewall yang berbeda. Pastikan untuk menyesuaikan dan memperbarui aturan ini untuk mengizinkan lalu lintas yang diperlukan untuk menjaga konektivitas antar kontainer dan layanan selama migrasi. |
Alamat IP dan perubahan DNS | Saat Anda memigrasikan beban kerja, alamat IP dan nama DNS mungkin berubah. Konfigurasikan ulang aplikasi yang mengandalkan nama DNS statis IPs atau spesifik. |
Akses layanan eksternal | Jika aplikasi Anda bergantung pada layanan eksternal seperti database atau APIs, Anda mungkin harus memperbarui pengaturan koneksi mereka untuk memastikan mereka dapat berkomunikasi dengan layanan baru dari ROSA. |
Konfigurasi Azure Private Link | Jika Anda menggunakan Azure Private Link atau layanan endpoint pribadi di ARO, Anda perlu menyiapkan fungsionalitas yang setara di ROSA untuk memastikan konektivitas pribadi antar sumber daya. |
Site-to-Site VPN atau Direct Connect pengaturan | Jika ada Site-to-Site VPN atau Direct Connect koneksi antara jaringan lokal dan ARO, Anda perlu membuat koneksi serupa dengan ROSA untuk komunikasi tanpa gangguan dengan sumber daya lokal Anda. |
Pengaturan masuk dan penyeimbang beban | Konfigurasi untuk pengontrol masuk dan penyeimbang beban mungkin berbeda antara ARO dan ROSA. Konfigurasikan ulang pengaturan ini untuk mempertahankan akses eksternal ke layanan Anda. |
Sertifikat dan penanganan TLS | Jika aplikasi Anda menggunakan sertifikat SSL atau TLS, pastikan sertifikat tersebut valid dan dikonfigurasi dengan benar di ROSA. |
Akses registri kontainer | Jika kontainer Anda di-host di registri kontainer eksternal, siapkan autentikasi yang tepat dan izin akses untuk ROSA. |
Pencatatan dan pemantauan | Perbarui konfigurasi pemantauan dan pencatatan untuk mencerminkan infrastruktur baru di ROSA sehingga Anda dapat terus memantau kesehatan dan kinerja kontainer Anda secara efektif. |
Sumber daya terkait
AWSreferensi
Apa itu Layanan OpenShift Red Hat di AWS? (Dokumentasi ROSA)
Memulai dengan ROSA (dokumentasi ROSA)
Layanan OpenShift Red Hat di AWS strategi implementasi (Panduan AWS Preskriptif)
Layanan OpenShift Red Hat di AWS Sekarang GA
(posting AWS blog)
OpenShift Dokumentasi Red Hat
Informasi tambahan
Memilih antara opsi pemindahan MTC dan CI/CD pipa
Migrasi aplikasi dari satu OpenShift cluster ke cluster lainnya membutuhkan pertimbangan yang cermat. Idealnya, Anda menginginkan transisi yang mulus dengan menggunakan CI/CD pipeline untuk menerapkan ulang aplikasi dan menangani migrasi data volume persisten. Namun, dalam praktiknya, aplikasi yang berjalan di cluster rentan terhadap perubahan tak terduga dari waktu ke waktu. Perubahan ini dapat menyebabkan aplikasi secara bertahap menyimpang dari status penerapan aslinya. MTC menawarkan solusi untuk skenario di mana konten yang tepat dari namespace tidak pasti dan migrasi mulus dari semua komponen aplikasi ke cluster baru adalah penting.
Membuat pilihan yang tepat membutuhkan evaluasi skenario spesifik Anda dan menimbang manfaat dari setiap pendekatan. Dengan demikian, Anda dapat memastikan migrasi yang sukses dan mulus yang selaras dengan kebutuhan dan prioritas Anda. Berikut adalah panduan tambahan untuk memilih di antara dua opsi.
Pemindahan pipa CI/CD
Metode CI/CD pipeline adalah pendekatan yang disarankan jika aplikasi Anda dapat digunakan kembali dengan percaya diri menggunakan pipeline. Ini memastikan bahwa migrasi dikontrol, dapat diprediksi, dan selaras dengan praktik penerapan yang ada. Saat Anda memilih metode ini, Anda dapat menggunakan penerapan biru/hijau atau strategi penerapan kenari untuk secara bertahap mengalihkan beban ke penerapan di ROSA. Untuk skenario ini, pola ini mengasumsikan bahwa Jenkins mengatur penerapan aplikasi dari lingkungan lokal.
Keuntungan:
Anda tidak memerlukan akses administratif ke cluster ARO sumber atau perlu menyebarkan operator apa pun di cluster sumber atau tujuan.
Pendekatan ini membantu Anda beralih lalu lintas secara bertahap dengan menggunakan DevOps strategi.
Kekurangan:
Dibutuhkan lebih banyak upaya untuk menguji fungsionalitas aplikasi Anda.
Jika aplikasi Anda berisi data persisten, diperlukan langkah-langkah tambahan untuk menyalin data dengan menggunakan AWS DataSync atau alat lainnya.
Migrasi MTC
Di dunia nyata, menjalankan aplikasi dapat mengalami perubahan tak terduga yang menyebabkan mereka menjauh dari penerapan awal. Pilih opsi MTC ketika Anda tidak yakin tentang status aplikasi Anda saat ini di cluster sumber. Misalnya, jika ekosistem aplikasi Anda mencakup berbagai komponen, konfigurasi, dan volume penyimpanan data, sebaiknya pilih MTC untuk memastikan migrasi lengkap yang mencakup aplikasi dan seluruh lingkungannya.
Keuntungan:
MTC menyediakan pencadangan lengkap dan pemulihan beban kerja.
Ini akan menyalin data persisten dari sumber ke target saat memigrasikan beban kerja.
Itu tidak memerlukan akses ke repositori kode sumber.
Kekurangan:
Anda memerlukan hak administratif untuk menginstal operator MTC pada cluster sumber dan tujuan.
DevOps Tim membutuhkan pelatihan untuk menggunakan alat MTC dan melakukan migrasi.
