Memahami perbedaan platform untuk beban kerja alur kerja berbasis peristiwa (EDW)
Sebelum Anda mereplikasi beban kerja EDW di Azure, pastikan Anda memiliki pemahaman yang kuat tentang perbedaan operasional antara platform AWS dan Azure.
Artikel ini membahas beberapa konsep utama untuk beban kerja ini dan menyediakan tautan ke sumber daya untuk informasi selengkapnya.
Beban kerja AWS EDW menggunakan peran AWS Identity and Access Management (IAM) yang diasumsikan oleh layanan EKS. Peran ini ditetapkan ke pod EKS untuk mengizinkan akses ke sumber daya AWS, seperti antrean atau database, tanpa perlu menyimpan kredensial.
Azure menerapkan kontrol akses berbasis peran (RBAC) secara berbeda dari AWS. Di Azure, penetapan peran dikaitkan dengan prinsip keamanan (pengguna, grup, identitas terkelola, atau perwakilan layanan), dan prinsip keamanan tersebut dikaitkan dengan sumber daya.
Beban kerja AWS EDW menggunakan komunikasi layanan untuk terhubung dengan antrean dan database. AWS EKS menggunakan AssumeRole
, fitur IAM, untuk memperoleh kredensial keamanan sementara untuk mengakses pengguna, aplikasi, atau layanan AWS. Implementasi ini memungkinkan layanan untuk mengasumsikan peran IAM yang memberikan akses tertentu, memberikan izin yang aman dan terbatas antar layanan.
Untuk akses database Amazon Simple Queue Service (SQS) dan Amazon DynamoDB menggunakan komunikasi layanan, alur kerja AWS menggunakan AssumeRole
dengan EKS, yang merupakan implementasi dari proyeksi volume token akun layanan Kubernetes. Dalam beban kerja EKS EDW, konfigurasi memungkinkan akun layanan Kubernetes untuk mengasumsikan peran AWS Identity and Access Management (IAM). Pod yang dikonfigurasi untuk menggunakan akun layanan kemudian dapat mengakses layanan AWS apa pun yang izinnya diakses peran tersebut. Dalam beban kerja EDW, dua kebijakan IAM didefinisikan untuk memberikan izin untuk mengakses Amazon DynamoDB dan Amazon SQS.
Dengan AKS, Anda dapat menggunakan Identitas Terkelola Microsoft Entra dengan ID Beban Kerja Microsoft Entra.
Identitas terkelola yang ditetapkan pengguna dibuat dan diberikan akses ke Tabel Azure Storage dengan menetapkan peran Kontributor Data Tabel Penyimpanan. Identitas terkelola juga diberikan akses ke Antrean Azure Storage dengan menetapkan peran Kontributor Data Antrean Penyimpanan. Penetapan peran ini dicakup ke sumber daya tertentu, memungkinkan identitas terkelola membaca pesan dalam Antrean Azure Storage tertentu dan menulisnya ke Tabel Azure Storage tertentu. Identitas terkelola kemudian dipetakan ke identitas beban kerja Kube yang akan dikaitkan dengan identitas pod tempat kontainer aplikasi disebarkan. Untuk informasi selengkapnya, lihat Menggunakan ID Beban Kerja Microsoft Entra dengan AKS.
Di sisi klien, Python Azure SDK mendukung cara transparan untuk memanfaatkan konteks identitas beban kerja, yang menghilangkan kebutuhan pengembang untuk melakukan autentikasi eksplisit. Kode yang berjalan di namespace/pod pada AKS dengan identitas beban kerja yang ditetapkan dapat mengautentikasi ke layanan eksternal menggunakan identitas terkelola yang dipetakan.
Sumber daya berikut dapat membantu Anda mempelajari selengkapnya tentang perbedaan antara AWS dan Azure untuk teknologi yang digunakan dalam beban kerja EDW:
Topik | Sumber daya AWS ke Azure |
---|---|
Layanan | Perbandingan layanan AWS dengan Azure |
Identitas | Memetakan konsep AWS IAM ke konsep serupa di Azure |
Akun | Akun dan langganan Azure AWS |
Manajemen sumber daya | Kontainer sumber daya |
Olahpesan | Amazon SQS ke Azure Queue Storage |
Kubernetes | AKS untuk profesional Amazon EKS |
Microsoft mempertahankan artikel ini. Kontributor berikut awalnya menulisnya:
- Ken Kilty | TPM Utama
- Russell de Pina | TPM Utama
- Jenny Hayes | Pengembang Konten Senior
- Carol Smith | Pengembang Konten Senior
- Erin Schaffer | Pengembang Konten 2
Umpan balik Azure Kubernetes Service
Azure Kubernetes Service adalah proyek sumber terbuka. Pilih tautan untuk memberikan umpan balik: