Semasa anda bekerja dalam IT, anda mula menyedari bahawa sistem mempunyai watak mereka sendiri. Mereka boleh menjadi fleksibel, senyap, sipi, dan tegas. Mereka boleh menarik atau menolak. Satu cara atau yang lain, anda perlu "berunding" dengan mereka, bergerak antara "perangkap" dan membina rantai interaksi mereka.
Jadi kami mendapat penghormatan untuk membina platform awan, dan untuk ini kami perlu "memujuk" beberapa subsistem untuk bekerjasama dengan kami. Nasib baik, kami mempunyai "bahasa API", tangan langsung dan banyak semangat.
Artikel ini tidak akan tegar secara teknikal, tetapi akan menerangkan masalah yang kami hadapi semasa membina awan. Saya memutuskan untuk menerangkan laluan kami dalam bentuk fantasi teknikal yang ringan tentang cara kami mencari bahasa yang sama dengan sistem dan perkara yang terhasil daripadanya.
Selamat datang ke kucing.
Bermula perjalanan
Beberapa ketika dahulu, pasukan kami telah ditugaskan untuk melancarkan platform awan untuk pelanggan kami. Kami mempunyai sokongan pengurusan, sumber, susunan perkakasan dan kebebasan dalam memilih teknologi untuk melaksanakan bahagian perisian perkhidmatan.
Terdapat juga beberapa keperluan:
- perkhidmatan memerlukan akaun peribadi yang mudah;
- platform mesti disepadukan ke dalam sistem pengebilan sedia ada;
- perisian dan perkakasan: OpenStack + Tungsten Fabric (Open Contrail), yang jurutera kami telah belajar untuk "memasak" dengan cukup baik.
Kami akan memberitahu anda pada lain masa tentang cara pasukan itu dipasang, antara muka akaun peribadi telah dibangunkan dan keputusan reka bentuk dibuat, jika komuniti Habra berminat.
Alat yang kami memutuskan untuk menggunakan:
- Python + Flask + Swagger + SQLAlchemy - set Python standard sepenuhnya;
- Vue.js untuk bahagian hadapan;
- Kami memutuskan untuk melakukan interaksi antara komponen dan perkhidmatan menggunakan Celery melalui AMQP.
Menjangkakan soalan tentang memilih Python, saya akan terangkan. Bahasa ini telah menemui nichenya dalam syarikat kami dan budaya yang kecil, tetapi masih, telah berkembang di sekelilingnya. Oleh itu, ia telah memutuskan untuk mula membina perkhidmatan di atasnya. Lebih-lebih lagi, kelajuan pembangunan dalam masalah sedemikian sering menentukan.
Jadi, mari kita mulakan perkenalan kita.
Bil Senyap - pengebilan
Kami sudah lama mengenali lelaki ini. Dia sentiasa duduk di sebelah saya dan diam mengira sesuatu. Kadangkala dia memajukan permintaan pengguna kepada kami, mengeluarkan invois pelanggan dan mengurus perkhidmatan. Seorang lelaki biasa yang bekerja keras. Benar, terdapat kesukaran. Dia diam, kadang-kadang termenung dan sering memikirkan fikirannya sendiri.
Pengebilan ialah sistem pertama yang kami cuba berkawan. Dan kesukaran pertama yang kami hadapi ialah semasa memproses perkhidmatan.
Sebagai contoh, apabila dibuat atau dipadamkan, tugasan masuk ke dalam baris gilir pengebilan dalaman. Oleh itu, sistem kerja tak segerak dengan perkhidmatan dilaksanakan. Untuk memproses jenis perkhidmatan kami, kami perlu "meletakkan" tugas kami ke dalam baris gilir ini. Dan di sini kami menghadapi masalah: kekurangan dokumentasi.
Berdasarkan penerangan API perisian, masih mungkin untuk menyelesaikan masalah ini, tetapi kami tidak mempunyai masa untuk melakukan kejuruteraan terbalik, jadi kami mengambil logik di luar dan mengatur baris gilir tugas di atas RabbitMQ. Operasi pada perkhidmatan dimulakan oleh pelanggan daripada akaun peribadinya, bertukar menjadi "tugas" Saderi di bahagian belakang dan dilakukan pada bahagian pengebilan dan OpenStack. Saderi menjadikannya agak mudah untuk menguruskan tugas, mengatur ulangan dan memantau status. Anda boleh membaca lebih lanjut mengenai "celeri", contohnya, .
Selain itu, pengebilan tidak menghalang projek yang kehabisan wang. Berkomunikasi dengan pemaju, kami mendapati bahawa apabila mengira statistik (dan kami perlu melaksanakan betul-betul logik jenis ini), terdapat perkaitan kompleks peraturan pemberhentian. Tetapi model ini tidak sesuai dengan realiti kita. Kami juga melaksanakannya melalui tugasan pada Saderi, membawa logik pengurusan perkhidmatan ke bahagian belakang.
Kedua-dua masalah di atas menyebabkan kod menjadi sedikit kembung dan pada masa akan datang kita perlu memfaktorkan semula untuk memindahkan logik untuk bekerja dengan tugasan ke dalam perkhidmatan yang berasingan. Kami juga perlu menyimpan beberapa maklumat tentang pengguna dan perkhidmatan mereka dalam jadual kami untuk menyokong logik ini.
Masalah lain ialah senyap.
Billy senyap menjawab "Ok" kepada beberapa permintaan API. Ini berlaku, sebagai contoh, apabila kami membuat pembayaran pembayaran yang dijanjikan semasa ujian (lebih lanjut mengenainya kemudian). Permintaan telah dilaksanakan dengan betul dan kami tidak melihat sebarang ralat.
Saya terpaksa mengkaji log semasa bekerja dengan sistem melalui UI. Ternyata pengebilan itu sendiri melakukan permintaan yang serupa, menukar skop kepada pengguna tertentu, sebagai contoh, pentadbir, menghantarnya dalam parameter su.
Secara umum, walaupun terdapat jurang dalam dokumentasi dan kelemahan API kecil, semuanya berjalan dengan baik. Log boleh dibaca walaupun di bawah beban berat jika anda memahami bagaimana ia berstruktur dan perkara yang perlu dicari. Struktur pangkalan data adalah hiasan, tetapi agak logik dan dalam beberapa cara malah menarik.
Jadi, untuk meringkaskan, masalah utama yang kami hadapi pada peringkat interaksi adalah berkaitan dengan ciri pelaksanaan sistem tertentu:
- "ciri" tidak berdokumen yang menjejaskan kami dalam satu cara atau yang lain;
- sumber tertutup (pengebilan ditulis dalam C++), akibatnya, adalah mustahil untuk menyelesaikan masalah 1 dalam apa-apa cara selain daripada "percubaan dan ralat".
Nasib baik, produk tersebut mempunyai API yang agak luas dan kami telah menyepadukan subsistem berikut ke dalam akaun peribadi kami:
- modul sokongan teknikal - permintaan daripada akaun peribadi anda "diproksikan" kepada pengebilan secara telus untuk pelanggan perkhidmatan;
- modul kewangan - membolehkan anda mengeluarkan invois kepada pelanggan semasa, membuat hapus kira dan menjana dokumen pembayaran;
- modul kawalan perkhidmatan - untuk ini kami terpaksa melaksanakan pengendali kami sendiri. Kebolehkembangan sistem bermain di tangan kami dan kami "mengajar" Billy jenis perkhidmatan baharu.
Ia agak menyusahkan, tetapi satu cara atau yang lain, saya fikir Billy dan saya akan serasi.
Berjalan melalui ladang tungsten β Fabrik Tungsten
Medan tungsten dihiasi dengan ratusan wayar, menghantar beribu-ribu bit maklumat melaluinya. Maklumat dikumpulkan ke dalam "paket", dihuraikan, membina laluan kompleks, seolah-olah dengan sihir.
Ini adalah domain sistem kedua yang kami terpaksa berkawan - Tungsten Fabric (TF), dahulunya OpenContrail. Tugasnya adalah untuk mengurus peralatan rangkaian, menyediakan abstraksi perisian kepada kami sebagai pengguna. TF - SDN, merangkumi logik kompleks bekerja dengan peralatan rangkaian. Terdapat artikel yang bagus tentang teknologi itu sendiri, sebagai contoh, .
Sistem ini disepadukan dengan OpenStack (dibincangkan di bawah) melalui pemalam Neutron.
Interaksi perkhidmatan OpenStack.
Lelaki dari jabatan operasi memperkenalkan kami kepada sistem ini. Kami menggunakan API sistem untuk mengurus susunan rangkaian perkhidmatan kami. Ia belum menyebabkan kami sebarang masalah atau kesulitan yang serius (saya tidak boleh bercakap untuk mereka dari OE), tetapi terdapat beberapa keanehan dalam interaksi.
Yang pertama kelihatan seperti ini: arahan yang memerlukan mengeluarkan sejumlah besar data ke konsol contoh apabila menyambung melalui SSH hanya "menutup" sambungan, manakala melalui VNC semuanya berfungsi dengan betul.
Bagi mereka yang tidak biasa dengan masalah ini, ia kelihatan agak lucu: ls /root berfungsi dengan betul, manakala, sebagai contoh, bahagian atas "membeku" sepenuhnya. Nasib baik, kami pernah menghadapi masalah yang sama sebelum ini. Ia telah diputuskan dengan menala MTU pada laluan dari nod pengiraan ke penghala. By the way, ini bukan masalah TF.
Masalah seterusnya hampir tiba. Dalam satu saat "indah", keajaiban penghalaan hilang, begitu sahaja. TF telah berhenti mengurus penghalaan pada peralatan.
Kami bekerja dengan Openstack dari peringkat pentadbir dan selepas itu berpindah ke peringkat pengguna yang diperlukan. SDN nampaknya "merampas" skop pengguna yang melakukan tindakan tersebut. Hakikatnya ialah akaun pentadbir yang sama digunakan untuk menyambung TF dan OpenStack. Pada langkah beralih kepada pengguna, "sihir" hilang. Ia telah memutuskan untuk membuat akaun berasingan untuk berfungsi dengan sistem. Ini membolehkan kami bekerja tanpa melanggar fungsi penyepaduan.
Bentuk Hayat Silikon - OpenStack
Makhluk silikon berbentuk pelik tinggal berhampiran ladang tungsten. Paling penting, ia kelihatan seperti kanak-kanak yang terlalu besar yang boleh menghancurkan kami dengan satu hayunan, tetapi tidak ada keagresifan yang jelas datang darinya. Ia tidak menyebabkan ketakutan, tetapi saiznya menimbulkan ketakutan. Begitu juga dengan kerumitan apa yang berlaku di sekeliling.
OpenStack ialah teras platform kami.
OpenStack mempunyai beberapa subsistem, yang pada masa ini kami menggunakan Nova, Glance dan Cinder paling aktif. Setiap daripada mereka mempunyai API sendiri. Nova bertanggungjawab untuk sumber pengiraan dan penciptaan contoh, Cinder bertanggungjawab untuk menguruskan volum dan syot kilatnya, Glance ialah perkhidmatan imej yang menguruskan templat OS dan metamaklumat padanya.
Setiap perkhidmatan dijalankan dalam bekas, dan broker mesej ialah "arnab putih" - RabbitMQ.
Sistem ini memberi kami masalah yang paling tidak dijangka.
Dan masalah pertama tidak lama akan datang apabila kami cuba menyambungkan volum tambahan ke pelayan. API Cinder dengan tegas menolak untuk melaksanakan tugas ini. Lebih tepat lagi, jika anda percaya OpenStack itu sendiri, sambungan diwujudkan, tetapi tiada peranti cakera di dalam pelayan maya.
Kami memutuskan untuk melencong dan meminta tindakan yang sama daripada Nova API. Hasilnya ialah peranti bersambung dengan betul dan boleh diakses dalam pelayan. Nampaknya masalah berlaku apabila storan blok tidak bertindak balas kepada Cinder.
Satu lagi kesukaran menanti kami apabila bekerja dengan cakera. Kelantangan sistem tidak dapat diputuskan sambungan daripada pelayan.
Sekali lagi, OpenStack sendiri "bersumpah" bahawa ia telah memusnahkan sambungan dan kini anda boleh bekerja dengan betul dengan volum secara berasingan. Tetapi API secara mutlak tidak mahu melakukan operasi pada cakera.
Di sini kami memutuskan untuk tidak melawan terutamanya, tetapi untuk mengubah pandangan kami tentang logik perkhidmatan. Jika ada contoh, mesti ada juga jumlah sistem. Oleh itu, pengguna belum boleh mengalih keluar atau melumpuhkan "cakera" sistem tanpa memadamkan "pelayan".
OpenStack ialah set sistem yang agak kompleks dengan logik interaksinya sendiri dan API berhias. Kami dibantu oleh dokumentasi yang agak terperinci dan, sudah tentu, percubaan dan kesilapan (di manakah kami tanpanya).
Larian ujian
Kami menjalankan pelancaran ujian pada Disember tahun lepas. Tugas utama adalah untuk menguji projek kami dalam mod pertempuran dari bahagian teknikal dan dari bahagian UX. Penonton telah dijemput secara terpilih dan ujian telah ditutup. Walau bagaimanapun, kami juga telah meninggalkan pilihan untuk meminta akses kepada ujian di tapak web kami.
Ujian itu sendiri, sudah tentu, bukan tanpa detik-detik lucunya, kerana di sinilah pengembaraan kami baru bermula.
Pertama, kami agak salah menilai minat dalam projek dan terpaksa menambah nod pengiraan dengan cepat semasa ujian. Kes biasa untuk kluster, tetapi terdapat beberapa nuansa di sini juga. Dokumentasi untuk versi TF tertentu menunjukkan versi khusus kernel yang berfungsi dengan vRouter telah diuji. Kami memutuskan untuk melancarkan nod dengan kernel yang lebih terkini. Akibatnya, TF tidak menerima laluan daripada nod. Saya terpaksa menggulung semula isirong dengan segera.
Satu lagi rasa ingin tahu adalah berkaitan dengan fungsi butang "tukar kata laluan" dalam akaun peribadi anda.
Kami memutuskan untuk menggunakan JWT untuk mengatur akses kepada akaun peribadi kami supaya tidak berfungsi dengan sesi. Memandangkan sistem ini pelbagai dan tersebar secara meluas, kami menguruskan token kami sendiri, di mana kami "membungkus" sesi daripada pengebilan dan token daripada OpenStack. Apabila kata laluan ditukar, token, sudah tentu, "menjadi buruk", kerana data pengguna tidak lagi sah dan ia perlu dikeluarkan semula.
Kami terlepas pandang tentang perkara ini, dan tiada sumber yang mencukupi untuk menyelesaikan bahagian ini dengan cepat. Kami terpaksa memotong fungsi sejurus sebelum melancarkan ujian.
Pada masa ini kami log keluar pengguna jika kata laluan telah ditukar.
Walaupun nuansa ini, ujian berjalan lancar. Dalam beberapa minggu, kira-kira 300 orang singgah. Kami dapat melihat produk melalui mata pengguna, mengujinya dalam tindakan dan mengumpul maklum balas berkualiti tinggi.
Perlu diteruskan
Bagi kebanyakan kita, ini adalah projek pertama skala ini. Kami mempelajari beberapa pelajaran berharga tentang cara bekerja sebagai satu pasukan dan membuat keputusan seni bina dan reka bentuk. Bagaimana untuk mengintegrasikan sistem yang kompleks dengan sumber yang sedikit dan melancarkannya ke dalam pengeluaran.
Sudah tentu, ada sesuatu untuk diusahakan dari segi kod dan antara muka penyepaduan sistem. Projek ini agak muda, tetapi kami penuh dengan cita-cita untuk mengembangkannya menjadi perkhidmatan yang boleh dipercayai dan mudah.
Kami telah pun dapat memujuk sistem. Bill dengan patuh mengendalikan pengiraan, pengebilan dan permintaan pengguna dalam almarinya. "Keajaiban" medan tungsten memberikan kita komunikasi yang stabil. Dan hanya OpenStack kadangkala menjadi berubah-ubah, menjerit sesuatu seperti "'WSREP belum lagi menyediakan nod untuk kegunaan aplikasi." Tetapi itu cerita yang sama sekali berbeza...
Kami baru-baru ini melancarkan perkhidmatan.
Anda boleh mengetahui semua butiran di kami .
Pasukan Pembangunan CLO
Pautan berguna
OpenStack
Kain Tungsten
Sumber: www.habr.com