Konfigurasikan perkhidmatan mongodb

Pengenalan

Bekas sedang merevolusikan keseluruhan kitaran hayat perisian: daripada eksperimen teknikal terawal dan bukti konsep, melalui pembangunan, ujian, penggunaan dan sokongan.

Pengenalan

Ingin mencuba MongoDB pada komputer riba anda? Hanya laksanakan arahan dan anda akan mempunyai kotak pasir yang ringan dan serba lengkap. Anda boleh memadamkan semua kesan apa yang telah anda lakukan apabila anda selesai.

Ingin menggunakan salinan tindanan aplikasi yang sama dalam berbilang persekitaran? Bina imej kontena anda sendiri dan biarkan pembangunan, ujian, operasi dan pasukan sokongan anda menggunakan klon persekitaran yang sama.

Bekas sedang merevolusikan keseluruhan kitaran hayat perisian: daripada eksperimen teknikal terawal dan bukti konsep, melalui pembangunan, ujian, penggunaan dan sokongan.

Alat orkestrasi digunakan untuk mengurus cara membuat, menaik taraf berbilang bekas dan menjadikannya sangat tersedia. Orkestrasi juga mengawal cara bekas disambungkan untuk membina aplikasi kompleks daripada berbilang bekas perkhidmatan mikro.

Ciri yang kaya, alatan ringkas dan API yang berkuasa menjadikan bekas dan keupayaan orkestrasi pilihan pertama untuk pasukan DevOps untuk disepadukan ke dalam aliran kerja penyepaduan berterusan (CI) dan penghantaran berterusan (CD).

Artikel ini meneroka cabaran tambahan yang dihadapi semasa menjalankan dan mengatur MongoDB dalam bekas dan menerangkan cara untuk mengatasinya.

Nota tentang MongoDB

Terdapat beberapa pertimbangan tambahan untuk menjalankan MongoDB dengan bekas dan orkestrasi:

Nod pangkalan data MongoDB adalah stateful. Jika bekas gagal dan dijadualkan semula, data hilang (boleh dipulihkan daripada nod lain dalam set replika, tetapi ini memerlukan masa), yang tidak diingini. Untuk menyelesaikan masalah ini, anda boleh menggunakan ciri seperti pengabstrakan volum dalam Kubernetes untuk memetakan direktori data MongoDB sementara dalam bekas ke lokasi yang berterusan supaya data itu bertahan dalam kegagalan kontena dan proses penjadualan semula.
Nod pangkalan data MongoDB dalam set replika mesti boleh berkomunikasi antara satu sama lain - termasuk selepas penjadualan semula. Semua nod dalam set replika mesti mengetahui alamat semua rakan sebaya mereka, tetapi apabila bekas dijadualkan semula, ia mungkin dimulakan semula dengan alamat IP yang berbeza. Contohnya, semua bekas dalam Kubernetes Pod berkongsi alamat IP dan apabila pod disusun semula, alamat IP berubah. Dengan Kubernetes, ini dikendalikan dengan mengaitkan perkhidmatan Kubernetes dengan setiap nod MongoDB, yang menyediakan "nama hos" menggunakan perkhidmatan DNS Kubernetes untuk memastikan perkhidmatan tidak berubah merentas orkestrasi semula.
Setelah setiap nod MongoDB individu berjalan (masing-masing dalam bekasnya sendiri), set replika mesti dimulakan dan setiap nod ditambahkan padanya. Ini mungkin memerlukan beberapa pemprosesan tambahan di luar alat orkestrasi. Khususnya, anda mesti menggunakan nod MongoDB dalam set replika sasaran untuk melaksanakan perintah rs.initiate dan rs.add.
Jika rangka kerja orkestrasi menyediakan penyusunan semula kontena secara automatik (seperti Kubernetes), maka ini akan meningkatkan daya tahan MongoDB kerana ahli set replika yang gagal boleh dicipta semula secara automatik, dengan itu memulihkan tahap redundansi penuh tanpa campur tangan manusia.
Perlu diingat bahawa walaupun rangka kerja orkestra mungkin memantau status bekas, ia tidak mungkin memantau aplikasi yang berjalan di dalam bekas atau menyandarkan datanya. Ini bermakna adalah penting untuk menggunakan penyelesaian pemantauan dan sandaran yang berkuasa seperti Pengurus Awan MongoDB yang disertakan dalam MongoDB Enterprise Advanced dan MongoDB Professional. Pertimbangkan untuk mencipta imej anda sendiri yang mengandungi versi MongoDB pilihan anda dan Ejen Automasi MongoDB.

Melaksanakan set replika MongoDB menggunakan Docker dan Kubernetes

Seperti yang dinyatakan dalam bahagian sebelumnya, pangkalan data teragih (seperti MongoDB) memerlukan sedikit perhatian apabila digunakan menggunakan rangka kerja orkestrasi (seperti Kubernetes). Bahagian ini akan menerangkan secara terperinci bagaimana untuk mencapainya.

Kami bermula dengan mencipta keseluruhan set replika MongoDB dalam gugusan Kubernetes tunggal (biasanya dalam pusat data, yang jelas tidak memberikan geo-redundansi). Dalam amalan, jarang sekali perlu menukar untuk dijalankan merentasi berbilang kelompok, dan langkah ini diterangkan kemudian.

Setiap ahli set replika akan dijalankan sebagai podnya sendiri dan menyediakan perkhidmatan dengan alamat IP dan port yang terdedah. Alamat IP "tetap" ini penting kerana kedua-dua aplikasi luaran dan ahli set replika lain boleh bergantung padanya untuk kekal tidak berubah sekiranya penjadualan semula pod.

Imej di bawah menggambarkan salah satu pod dan pengawal dan perkhidmatan replikasi yang berkaitan.

Rajah 1: ahli set replika MongoDB dikonfigurasikan sebagai Kubernetes Pods dan didedahkan sebagai perkhidmatan
Rajah 1: ahli set replika MongoDB dikonfigurasikan sebagai Kubernetes Pods dan didedahkan sebagai perkhidmatan
Pengenalan langkah demi langkah kepada sumber yang diterangkan dalam konfigurasi ini:

Bermula dari inti, terdapat bekas yang dipanggil mongo-node1. mongo-node1 mengandungi imej bernama mongo, iaitu imej bekas MongoDB yang tersedia secara umum yang dihoskan pada Docker Hub. Bekas itu mendedahkan port 27107 dalam kelompok.
Ciri volum data Kubernetes digunakan untuk memetakan direktori /data/db dalam penyambung kepada storan berterusan bernama mongo-persistent-storage1, yang seterusnya dipetakan ke cakera bernama mongodb-disk1 yang dicipta dalam Google Cloud . Di sinilah MongoDB menyimpan datanya supaya ia berterusan selepas bekas itu diatur semula.
Bekas itu disimpan dalam pod dengan label bernama mongo-node dan contoh (sewenang-wenangnya) bernama rod .
Konfigurasikan pengawal replikasi mongo-node1 untuk memastikan bahawa satu contoh pod mongo-node1 sentiasa berjalan.
Perkhidmatan pengimbangan beban bernama mongo-svc-a membuka alamat IP dan port 27017 ke dunia luar, yang dipetakan ke nombor port yang sama bagi bekas. Perkhidmatan ini menggunakan pemilih untuk memadankan label pod untuk menentukan pod yang betul. Alamat IP luaran dan port akan digunakan untuk komunikasi antara aplikasi dan ahli set replika. Setiap bekas juga mempunyai alamat IP tempatan, tetapi apabila bekas itu dialihkan atau dimulakan semula, alamat IP ini berubah dan oleh itu tidak digunakan untuk set replika.
Rajah seterusnya menunjukkan konfigurasi ahli kedua set replika.

Rajah 2: Ahli set replika MongoDB kedua dikonfigurasikan sebagai Pod Kubernetes
Rajah 2: Ahli set replika MongoDB kedua dikonfigurasikan sebagai Pod Kubernetes
90% konfigurasi adalah sama, cuma perubahan ini:

Nama cakera dan volum mestilah unik, jadi mongodb-disk2 dan mongo-persistent-storage2 digunakan
Pod diberikan label contoh: jane dan nama: mongo-node2 supaya perkhidmatan baharu boleh dibezakan daripada Pod rod yang ditunjukkan dalam Rajah 1 menggunakan pemilih.
Pengawal salinan dinamakan mongo-rc2
Perkhidmatan ini dinamakan mongo-svc-b dan diberikan alamat IP luaran yang unik (dalam kes ini, Kubernetes memberikan 104.1.4.5)
Konfigurasi ahli replika ketiga mengikut corak yang sama, dan imej di bawah menunjukkan set replika lengkap:

Rajah 3: Ahli set replika penuh dikonfigurasikan sebagai perkhidmatan Kubernetes
Rajah 3: Ahli set replika penuh dikonfigurasikan sebagai perkhidmatan Kubernetes
Ambil perhatian bahawa walaupun semasa menjalankan konfigurasi yang ditunjukkan dalam Rajah 3 pada kelompok Kubernetes tiga atau lebih nod, Kubernetes boleh (dan selalunya) mengatur dua atau lebih ahli set replika MongoDB pada hos yang sama. Ini kerana Kubernetes menganggap ketiga-tiga pod sebagai milik tiga perkhidmatan berasingan.

Untuk menambah lebihan dalam zon, perkhidmatan tanpa kepala tambahan boleh dibuat. Perkhidmatan baharu ini tidak menyediakan sebarang fungsi kepada dunia luar (ia tidak akan mempunyai alamat IP pun), tetapi ia membenarkan Kubernetes memberitahu tiga pod MongoDB untuk membentuk perkhidmatan, jadi Kubernetes akan cuba mengaturnya pada nod yang berbeza.

Rajah 4: Perkhidmatan tanpa kepala yang mengelakkan ahli set replika MongoDB yang sama
Rajah 4: Perkhidmatan tanpa kepala yang mengelakkan ahli set replika MongoDB yang sama
Fail dan arahan konfigurasi sebenar yang diperlukan untuk mengkonfigurasi dan melancarkan set replika MongoDB boleh didapati dalam kertas putih Mendayakan Perkhidmatan Mikro: Menjelaskan Bekas dan Orkestrasi. Khususnya, beberapa langkah khas yang diterangkan dalam artikel ini diperlukan untuk menggabungkan tiga kejadian MongoDB ke dalam set replika yang berfungsi dan mantap.

Berbilang set replika MongoDB Zon Ketersediaan

Set replika yang dibuat di atas adalah berisiko kerana semuanya berjalan dalam kelompok GCE yang sama dan oleh itu dalam zon ketersediaan yang sama. Jika acara utama mengambil Zon Ketersediaan di luar talian, set replika MongoDB tidak akan tersedia. Jika lebihan geografi diperlukan, tiga pod harus dijalankan dalam tiga Zon Ketersediaan atau wilayah yang berbeza.

Mengejutkan, sangat sedikit perubahan diperlukan untuk mencipta set replika yang serupa dipecah antara tiga wilayah (memerlukan tiga kelompok). Setiap kluster memerlukan fail YAML Kubernetes sendiri yang mentakrifkan pod, pengawal replikasi dan perkhidmatan untuk hanya satu ahli set replika tersebut. Maka adalah mudah untuk mencipta kluster, storan berterusan dan nod MongoDB untuk setiap rantau.

Rajah 5: Set replika berjalan pada berbilang zon ketersediaan
Rajah 5: Set replika berjalan pada berbilang zon ketersediaan
Langkah seterusnya
Untuk mengetahui lebih lanjut tentang bekas dan orkestra—teknologi yang terlibat dan faedah perniagaan yang mereka tawarkan—baca kertas putih Mendayakan Perkhidmatan Mikro: Kontena dan Orkestra Dijelaskan. Dokumen ini menyediakan arahan lengkap untuk mendapatkan set replika yang diterangkan dalam artikel ini dan menjalankannya pada Docker dan Kubernetes dalam Google Container Engine.

Mengenai pengarang:

Andrew ialah Pengurus Besar Pemasaran Produk di MongoDB. Dia menyertai MongoDB pada musim panas lalu dari Oracle, di mana dia menghabiskan lebih daripada enam tahun dalam pengurusan produk yang memfokuskan pada ketersediaan tinggi. Dia boleh dihubungi di @andrewmorgan atau dengan mengulas di blognya (clusterdb.com).

Atas ialah kandungan terperinci Konfigurasikan perkhidmatan mongodb. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!