Li Qingwang - Insinyur Pengembangan Perangkat Lunak, Cisco
perkenalan
Halo semuanya, nama saya Li Qingwang, seorang insinyur pengembangan perangkat lunak dari Cisco. Tim kami telah menggunakan Apache DolphinScheduler untuk membangun platform penjadwalan big data kami sendiri selama hampir tiga tahun. Dari versi awal 2.0.3 hingga saat ini, kami telah berkembang bersama komunitas. Ide teknis yang dibagikan kepada Anda hari ini merupakan pengembangan sekunder berdasarkan versi 3.1.1, menambahkan beberapa fitur baru yang tidak disertakan dalam versi komunitas.
Hari ini, saya akan berbagi bagaimana kami menggunakan Apache DolphinScheduler untuk membangun platform data besar dan mengirimkan serta menerapkan tugas kami ke AWS. Beberapa tantangan yang dihadapi selama proses dan solusi kami.
Desain dan penyesuaian arsitektur
Awalnya, semua layanan kami diterapkan di Kubernetes (K8), termasuk API, Alert, dan komponen seperti Zookeeper (ZK), Master, dan Worker.
Tugas pemrosesan data besar
Kami telah melakukan pengembangan sekunder pada tugas-tugas seperti Spark, ETL dan Flink:
tugas ETL: Tim kami telah mengembangkan alat seret dan lepas sederhana yang dapat digunakan pengguna untuk membuat tugas ETL dengan cepat.
Dukungan percikan : Versi awal hanya mendukung Spark yang berjalan di Yarn, dan kami membuatnya mendukung berjalan di K8 melalui pengembangan sekunder. Versi terbaru komunitas saat ini mendukung Spark di K8s.
*Flink pengembangan sekunder: Demikian pula, kami telah menambahkan tugas streaming Flink Pada K8, serta dukungan untuk tugas SQL dan tugas Python Pada K8.
Mendukung Pekerjaan di AWS
Seiring dengan berkembangnya bisnis dan diperlukannya kebijakan data, kami menghadapi tantangan karena harus menjalankan tugas data di berbagai wilayah. Hal ini mengharuskan kita untuk membangun arsitektur yang dapat mendukung banyak cluster. Di bawah ini adalah penjelasan rinci tentang solusi dan proses implementasi kami.
Arsitektur kami saat ini terdiri dari titik akhir kontrol terpusat, satu layanan Apache DolphinScheduler, yang mengelola banyak cluster. Cluster ini didistribusikan di berbagai wilayah geografis, seperti UE dan Amerika Serikat, untuk mematuhi kebijakan data lokal dan persyaratan isolasi.
Penyesuaian arsitektur
Untuk memenuhi permintaan ini, kami telah melakukan penyesuaian berikut:
Jaga agar layanan Apache DolphinScheduler dikelola secara terpusat: Layanan DolphinScheduler kami masih diterapkan di Cisco Webex DC yang dibuat sendiri, dengan menjaga sentralisasi dan konsistensi manajemen.
Mendukung klaster AWS EKS : Pada saat yang sama, kami memperluas kemampuan arsitektur kami untuk mendukung beberapa klaster AWS EKS. Dengan cara ini, persyaratan bisnis baru untuk tugas-tugas yang berjalan di klaster EKS dapat dipenuhi tanpa memengaruhi operasi dan isolasi data klaster Webex DC lainnya.
Melalui desain ini, kami dapat secara fleksibel merespons berbagai kebutuhan bisnis dan tantangan teknis sekaligus memastikan isolasi data dan kepatuhan terhadap kebijakan.
Selanjutnya, kami akan memperkenalkan cara menangani implementasi teknis dan ketergantungan sumber daya Apache DolphinScheduler saat menjalankan tugas di Cisco Webex DC.
Ketergantungan dan penyimpanan sumber daya
Karena semua tugas kita dijalankan di Kubernetes (K8), penting bagi kita untuk:
gambar buruh pelabuhan
lokasi penyimpanan: Sebelumnya, semua image Docker kami disimpan di repositori Docker di Cisco.
Manajemen gambar: Gambar-gambar ini menyediakan lingkungan operasi dan ketergantungan yang diperlukan untuk berbagai layanan dan tugas yang kami jalankan.
File sumber daya dan dependensi
Paket jar dan file konfigurasi, dll.: Kami menggunakan Amazon S3 Bucket sebagai pusat penyimpanan sumber daya untuk menyimpan paket Jar pengguna dan kemungkinan file konfigurasi dependen.
Manajemen sumber daya keamanan: Termasuk kata sandi basis data, informasi enkripsi Kafka dan kunci yang bergantung pada pengguna, dll. Informasi sensitif ini disimpan dalam layanan Cisco Vault.
Akses aman dan manajemen hak
Untuk kebutuhan mengakses S3 Bucket, kita perlu mengonfigurasi dan mengelola kredensial AWS:
Konfigurasi akun IAM
Manajemen kredensial: Kami menggunakan akun IAM untuk mengelola akses ke sumber daya AWS, termasuk Access Keys dan Secret Keys.
Integrasi K8: Informasi kredensial ini disimpan dalam Rahasia Kubernetes dan direferensikan oleh Api-Service untuk mengakses Bucket S3 dengan aman.
Kontrol izin dan isolasi sumber daya: Melalui akun IAM, kami dapat menerapkan kontrol izin yang menyeluruh untuk memastikan keamanan data dan kepatuhan bisnis.
Masalah habis masa berlakunya dan tindakan penanggulangan untuk kunci akses akun IAM
Dalam proses menggunakan akun IAM untuk mengelola sumber daya AWS, kami menghadapi masalah kedaluwarsa access key. Berikut selengkapnya tentang cara kami mengatasi tantangan ini.
Akses masalah kedaluwarsa kunci
periode kunci: Kunci AWS akun IAM biasanya diatur agar kedaluwarsa secara otomatis setiap 90 hari, yang bertujuan untuk meningkatkan keamanan sistem.
dampak misi: Setelah kunci kedaluwarsa, semua tugas yang mengandalkan kunci ini untuk mengakses sumber daya AWS tidak akan dapat dijalankan, sehingga mengharuskan kami memperbarui kunci secara tepat waktu untuk menjaga kelangsungan bisnis.
Menanggapi situasi ini, kami mengatur restart rutin untuk tugas tersebut dan mengatur pemantauan yang sesuai. Jika ada masalah dengan akun AWS sebelum waktu kedaluwarsa, maka kami perlu memberi tahu pengembang terkait untuk melakukan beberapa pemrosesan.
Mendukung AWS EKS
Seiring perluasan bisnis kami ke AWS EKS, kami perlu melakukan serangkaian penyesuaian terhadap arsitektur dan langkah keamanan yang ada.
Misalnya, seperti image Docker yang disebutkan tadi, sebelumnya kita meletakkannya di repo Docker milik Cisco, jadi sekarang kita perlu meletakkan image Docker di ECR.
Dukungan beberapa S3 Bucket
Karena sifat klaster AWS yang terdesentralisasi dan persyaratan isolasi data dari berbagai bisnis, kami perlu mendukung beberapa Bucket S3 untuk memenuhi kebutuhan penyimpanan data dari klaster yang berbeda:
Korespondensi antara cluster dan bucket: Setiap cluster akan mengakses S3 Bucket yang sesuai untuk memastikan lokalitas dan kepatuhan data.
Ubah strategi: Kami perlu menyesuaikan kebijakan akses penyimpanan kami untuk mendukung pembacaan dan penulisan data dari beberapa Bucket S3. Pihak bisnis yang berbeda perlu mengakses bucket S3 mereka yang sesuai.
Perubahan pada alat manajemen kata sandi
Untuk meningkatkan keamanan, kami bermigrasi dari layanan Vault buatan Cisco ke Secrets Manager (ASM) AWS:
Penggunaan ASM: ASM memberikan solusi yang lebih terintegrasi untuk mengelola kata sandi dan kunci untuk sumber daya AWS.
Kami telah mengadopsi metode penggunaan IAM Role dan Service Account untuk meningkatkan keamanan Pod:
Buat Peran dan Kebijakan IAM: Pertama, buat IAM Role dan ikat kebijakan yang diperlukan ke dalamnya untuk memastikan bahwa hanya izin yang diperlukan yang diberikan.
Ikat Akun Layanan K8s: Kemudian buat Akun Layanan Kubernetes dan kaitkan dengan IAM Role.
Integrasi izin pod: Saat menjalankan sebuah Pod, dengan mengaitkannya ke Akun Layanan, Pod dapat memperoleh kredensial AWS yang diperlukan secara langsung melalui IAM Role, sehingga dapat mengakses sumber daya AWS yang diperlukan.
Penyesuaian ini tidak hanya meningkatkan skalabilitas dan fleksibilitas sistem kami, namun juga memperkuat arsitektur keamanan secara keseluruhan untuk memastikan bahwa operasi di lingkungan AWS efisien dan aman. Pada saat yang sama, ini juga menghindari masalah sebelumnya yaitu kedaluwarsa kunci secara otomatis dan kebutuhan untuk memulai ulang.
Mengoptimalkan manajemen sumber daya dan proses penyimpanan
Untuk menyederhanakan proses penerapan, kami berencana untuk memasukkan image Docker langsung ke ECR alih-alih melalui transit sekunder:
mendorong secara langsung: Memodifikasi proses pengemasan saat ini sehingga image Docker dikirim langsung ke ECR setelah dibuat, sehingga mengurangi penundaan waktu dan potensi titik kesalahan.
Ubah implementasi
Penyesuaian tingkat kode: Kami telah memodifikasi kode DolphinScheduler agar dapat mendukung beberapa Klien S3 dan menambahkan manajemen cache untuk beberapa S3Client.
Penyesuaian UI manajemen sumber daya: Memungkinkan pengguna memilih nama AWS Bucket yang berbeda untuk operasi melalui antarmuka.
akses sumber daya: Layanan Apache DolphinScheduler yang dimodifikasi kini dapat mengakses beberapa Bucket S3, memungkinkan pengelolaan data yang fleksibel antar klaster AWS yang berbeda.
Manajemen dan isolasi izin sumber daya AWS
Integrasikan AWS Secrets Manager (ASM)
Kami telah memperluas Apache DolphinScheduler untuk mendukung AWS Secrets Manager, yang memungkinkan pengguna memilih rahasia di berbagai jenis klaster:
Integrasi fungsional ASM
Peningkatan antarmuka pengguna: Di antarmuka pengguna DolphinScheduler, fungsi tampilan dan pemilihan berbagai jenis rahasia ditambahkan.
Manajemen kunci otomatis: Memetakan jalur file yang menyimpan rahasia yang dipilih pengguna ke variabel lingkungan Pod sebenarnya selama runtime, sehingga memastikan penggunaan kunci yang aman.
Konfigurasi sumber daya dinamis dan layanan inisialisasi (Init Container)
Untuk mengelola dan menginisialisasi sumber daya AWS dengan lebih fleksibel, kami menerapkan layanan yang disebut Init Container:
Tarikan sumber daya: Init Container akan secara otomatis menarik sumber daya S3 yang dikonfigurasi oleh pengguna dan menempatkannya di direktori yang ditentukan sebelum Pod dijalankan.
Manajemen kunci dan konfigurasi: Berdasarkan konfigurasinya, Init Container akan memeriksa dan menarik informasi kata sandi di ASM, lalu menyimpannya dalam sebuah file dan memetakannya melalui variabel lingkungan untuk digunakan oleh Pod.
Penerapan Terraform dalam pembuatan dan pengelolaan sumber daya
Kami telah mengotomatiskan proses konfigurasi dan pengelolaan sumber daya AWS melalui Terraform, menyederhanakan alokasi sumber daya dan pengaturan izin:
Konfigurasi sumber daya otomatis: Gunakan Terraform untuk membuat sumber daya AWS yang diperlukan seperti S3 Bucket dan ECR Repo.
Kebijakan IAM dan manajemen peran: Secara otomatis membuat kebijakan dan peran IAM untuk memastikan setiap unit bisnis memiliki akses sesuai permintaan ke sumber daya yang dibutuhkannya.
Isolasi izin dan keamanan
Kami menggunakan strategi isolasi izin yang canggih untuk memastikan bahwa unit bisnis yang berbeda beroperasi di namespace yang independen, menghindari konflik akses sumber daya dan risiko keamanan:
Detail implementasi
Pembuatan dan pengikatan Akun Layanan: Membuat Akun Layanan independen untuk setiap unit bisnis dan mengikatnya ke IAM role.
Isolasi ruang nama: Setiap operasi Akun Layanan mengakses sumber daya AWS yang sesuai melalui IAM role dalam namespace yang ditentukan.
Peningkatan dalam dukungan cluster dan kontrol izin
Ekstensi tipe cluster
Kami menambahkan bidang baru cluster type, untuk mendukung berbagai jenis klaster K8S, yang tidak hanya mencakup klaster Webex DC standar dan klaster AWS EKS, namun juga mendukung klaster tertentu dengan persyaratan keamanan yang lebih tinggi:
Manajemen tipe cluster
Bidang tipe cluster:oleh Diperkenalkancluster typebidang, kami dapat dengan mudah mengelola dan memperluas dukungan untuk cluster K8S yang berbeda.
Kustomisasi tingkat kode: Untuk kebutuhan unik klaster tertentu, kita dapat membuat modifikasi tingkat kode untuk memastikan bahwa persyaratan keamanan dan konfigurasi terpenuhi saat menjalankan pekerjaan pada klaster ini.
Sistem kontrol izin yang ditingkatkan (sistem Auth)
Kami mengembangkan sistem Auth secara khusus untuk kontrol izin yang terperinci, termasuk manajemen izin antar proyek, sumber daya, dan namespace:
Fungsi manajemen hak
Izin proyek dan sumber daya: Pengguna dapat mengontrol izin melalui dimensi proyek. Setelah mereka memiliki izin proyek, mereka memiliki akses ke semua sumber daya dalam proyek tersebut.
kontrol izin namespace: Memastikan bahwa tim tertentu hanya dapat menjalankan tugas proyeknya di namespace yang ditentukan, sehingga memastikan berjalannya isolasi sumber daya.
Misalnya, tim A hanya dapat menjalankan pekerjaan proyek tertentu di namespace A-nya. Pengguna B, misalnya, tidak dapat menjalankan pekerjaan di namespace pengguna A.
Manajemen sumber daya AWS dan aplikasi izin
Kami menggunakan sistem Auth dan alat lainnya untuk mengelola izin dan kontrol akses sumber daya AWS, menjadikan alokasi sumber daya lebih fleksibel dan aman:
Dukungan beberapa Akun AWS: Dalam sistem Auth, Anda dapat mengelola beberapa akun AWS dan mengikat sumber daya AWS yang berbeda seperti S3 Bucket, ECR, ASM, dll.
Pemetaan sumber daya dan aplikasi izin: Pengguna dapat memetakan sumber daya AWS yang ada dan mengajukan izin dalam sistem, sehingga mereka dapat dengan mudah memilih sumber daya yang perlu mereka akses saat menjalankan pekerjaan.
Manajemen Akun Layanan dan pengikatan izin
Untuk mengelola akun layanan dan izinnya dengan lebih baik, kami telah menerapkan fungsi berikut:
Pengikatan dan pengelolaan Akun Layanan
Satu-satunya perbedaan antara Akun Layanan: Mengikat Akun Layanan melalui cluster, namespace, dan nama proyek tertentu untuk memastikan keunikannya.
Antarmuka pengikatan izin: Pengguna dapat mengikat Akun Layanan ke sumber daya AWS tertentu, seperti S3, ASM, atau ECR, pada antarmuka untuk mencapai kontrol izin yang tepat.
Sederhanakan operasi dan sinkronisasi sumber daya
Saya baru saja mengatakan banyak hal, tetapi pengoperasian sebenarnya relatif sederhana bagi pengguna. Seluruh proses aplikasi sebenarnya adalah tugas satu kali. Untuk lebih meningkatkan pengalaman pengguna Apache DolphinScheduler di lingkungan AWS, kami telah mengambil serangkaian langkah-langkah untuk Menyederhanakan prosedur operasi dan meningkatkan kemampuan sinkronisasi sumber daya.
Izinkan saya meringkasnya untuk Anda:
Antarmuka pengguna yang disederhanakan
Di DolphinScheduler, pengguna dapat dengan mudah mengonfigurasi klaster dan namespace tertentu tempat pekerjaan mereka dijalankan:
Pemilihan cluster dan namespace
Seleksi klaster: Saat mengirimkan pekerjaan, pengguna dapat memilih cluster yang mereka inginkan untuk menjalankan pekerjaan tersebut.
konfigurasi ruang nama: Bergantung pada klaster yang dipilih, pengguna juga perlu menentukan namespace tempat pekerjaan dijalankan.
Akun Layanan dan pemilihan sumber daya
Tampilan Akun Layanan: Halaman ini akan secara otomatis menampilkan Akun Layanan yang sesuai berdasarkan proyek, cluster, dan namespace yang dipilih.
Konfigurasi akses sumber daya: Pengguna dapat memilih S3 Bucket, alamat ECR, dan kunci ASM yang terkait dengan akun layanan melalui daftar drop-down.
pandangan masa depan
Mengenai desain saat ini, masih ada beberapa area yang dapat dioptimalkan dan ditingkatkan untuk meningkatkan pengajuan pengguna dan memfasilitasi pengoperasian dan pemeliharaan:
Pengoptimalan dorongan gambar: Pertimbangkan untuk melewatkan proses pengemasan transit Cisco dan mengirimkan paket langsung ke ECR, terutama untuk modifikasi gambar khusus EKS.
Fungsi sinkronisasi satu klik: Kami berencana untuk mengembangkan fungsi sinkronisasi satu klik yang memungkinkan pengguna mengunggah paket sumber daya ke S3 Bucket dan mencentang kotak untuk menyinkronkannya secara otomatis ke S3 Bucket lain untuk mengurangi pekerjaan unggahan berulang.
Secara otomatis memetakan ke sistem Auth: Setelah sumber daya Aws dibuat melalui Terraform, sistem akan secara otomatis memetakan sumber daya ini ke sistem manajemen izin untuk menghindari pengguna memasukkan sumber daya secara manual.
Optimalisasi kontrol izin: Melalui pengelolaan sumber daya dan izin otomatis, pengoperasian pengguna menjadi lebih sederhana, sehingga mengurangi kerumitan penyiapan dan pengelolaan.
Dengan peningkatan ini, kami berharap dapat membantu pengguna menerapkan dan mengelola pekerjaan mereka secara lebih efisien menggunakan Apache DolphinScheduler, baik di Webex DC atau EKS, sekaligus meningkatkan efisiensi dan keamanan pengelolaan sumber daya.
