Perkhidmatan anak yatim: kelemahan seni bina perkhidmatan (mikro).

Pengarah Operasi portal Banki.ru Andrey Nikolsky bercakap pada persidangan tahun lepas DevOpsDays Moscow tentang perkhidmatan anak yatim: bagaimana untuk mengenal pasti anak yatim dalam infrastruktur, mengapa perkhidmatan anak yatim tidak baik, apa yang perlu dilakukan dengan mereka, dan apa yang perlu dilakukan jika tiada apa yang membantu.

Di bawah potongan adalah versi teks laporan.

Hello rakan sekerja! Nama saya Andrey, saya mengetuai operasi di Banki.ru.

Kami mempunyai perkhidmatan yang besar, ini adalah perkhidmatan monolitik, terdapat perkhidmatan dalam erti kata yang lebih klasik, dan ada yang sangat kecil. Dalam istilah pekerja-petani saya, saya mengatakan bahawa jika perkhidmatan itu mudah dan kecil, maka ia adalah mikro, dan jika ia tidak begitu mudah dan kecil, maka ia hanya perkhidmatan.

Kebaikan perkhidmatan

Saya akan segera membincangkan kelebihan perkhidmatan.

Yang pertama ialah penskalaan. Anda boleh melakukan sesuatu dengan cepat pada perkhidmatan dan memulakan pengeluaran. Anda telah menerima trafik, anda telah mengklonkan perkhidmatan tersebut. Anda mempunyai lebih banyak trafik, anda telah mengklonkannya dan hidup dengannya. Ini adalah bonus yang baik, dan, pada dasarnya, apabila kami mula, ia dianggap sebagai perkara yang paling penting bagi kami, mengapa kami melakukan semua ini.

Kedua, pembangunan terpencil, apabila anda mempunyai beberapa pasukan pembangunan, beberapa pembangun berbeza dalam setiap pasukan, dan setiap pasukan membangunkan perkhidmatannya sendiri.

Dengan pasukan ada nuansa. Pemaju adalah berbeza. Dan terdapat, sebagai contoh, orang emping salji. Saya pertama kali melihat ini dengan Maxim Dorofeev. Kadang-kadang orang emping salji berada di beberapa pasukan dan bukan pada yang lain. Ini menjadikan perkhidmatan berbeza yang digunakan di seluruh syarikat agak tidak sekata.

Lihat gambar: ini adalah pemaju yang baik, dia mempunyai tangan yang besar, dia boleh melakukan banyak perkara. Masalah utama ialah dari mana datangnya tangan ini.

Perkhidmatan memungkinkan untuk menggunakan bahasa pengaturcaraan yang berbeza yang lebih sesuai untuk tugas yang berbeza. Sesetengah perkhidmatan ada dalam Go, ada dalam Erlang, ada dalam Ruby, ada dalam PHP, ada dalam Python. Secara umum, anda boleh berkembang dengan sangat meluas. Terdapat nuansa di sini juga.

Seni bina berorientasikan perkhidmatan terutamanya mengenai devops. Iaitu, jika anda tidak mempunyai automasi, tiada proses penggunaan, jika anda mengkonfigurasinya secara manual, konfigurasi anda boleh berubah dari contoh perkhidmatan ke contoh, dan anda perlu pergi ke sana untuk melakukan sesuatu, maka anda berada di neraka.

Sebagai contoh, anda mempunyai 20 perkhidmatan dan anda perlu menggunakan tangan, anda mempunyai 20 konsol, dan pada masa yang sama anda menekan "masuk" seperti ninja. Ia tidak begitu baik.

Jika anda mempunyai perkhidmatan selepas ujian (jika ada ujian, sudah tentu), dan anda masih perlu menyelesaikannya dengan fail supaya ia berfungsi dalam pengeluaran, saya juga mempunyai berita buruk untuk anda.

Jika anda bergantung pada perkhidmatan Amazon tertentu dan bekerja di Rusia, maka dua bulan lalu anda juga mempunyai "Semua di sekeliling terbakar, saya baik-baik saja, semuanya sejuk."

Kami menggunakan Ansible untuk mengautomasikan penggunaan, Boneka untuk penumpuan, Buluh untuk mengautomasikan penggunaan dan Confluence untuk menerangkan semuanya.

Saya tidak akan membincangkan perkara ini secara terperinci, kerana laporan itu lebih kepada amalan interaksi, dan bukan mengenai pelaksanaan teknikal.

Sebagai contoh, kami menghadapi masalah di mana Puppet pada pelayan berfungsi dengan Ruby 2, tetapi beberapa aplikasi ditulis untuk Ruby 1.8, dan ia tidak berfungsi bersama-sama. Ada yang tidak kena di sana. Dan apabila anda perlu menjalankan beberapa versi Ruby pada satu mesin, anda biasanya mula menghadapi masalah.

Sebagai contoh, kami memberi setiap pemaju satu platform di mana terdapat kira-kira semua yang kami ada, semua perkhidmatan yang boleh dibangunkan, supaya dia mempunyai persekitaran terpencil, dia boleh memecahkannya dan membinanya mengikut kehendaknya.

Ia berlaku bahawa anda memerlukan beberapa pakej yang disusun khas dengan sokongan untuk sesuatu di sana. Ia agak sukar. Saya mendengar laporan di mana imej Docker seberat 45 GB. Di Linux, sudah tentu, ia lebih mudah, semuanya lebih kecil di sana, tetapi masih, tidak akan ada ruang yang mencukupi.

Nah, terdapat kebergantungan yang bercanggah, apabila satu bahagian projek bergantung pada perpustakaan satu versi, satu bahagian projek bergantung pada versi lain, dan perpustakaan tidak dipasang bersama sama sekali.

Kami mempunyai tapak dan perkhidmatan dalam PHP 5.6, kami malu dengannya, tetapi apa yang boleh kami lakukan? Ini adalah satu laman web kami. Terdapat tapak dan perkhidmatan pada PHP 7, lebih banyak daripada mereka, kami tidak malu dengan mereka. Dan setiap pemaju mempunyai pangkalan sendiri di mana dia gembira melihat.

Jika anda menulis dalam sebuah syarikat dalam satu bahasa, maka tiga mesin maya bagi setiap pembangun berbunyi biasa. Jika anda mempunyai bahasa pengaturcaraan yang berbeza, maka keadaan menjadi lebih teruk.

Anda mempunyai tapak dan perkhidmatan mengenai ini, pada ini, kemudian tapak lain untuk Go, satu tapak untuk Ruby dan beberapa Redis lain di sebelah. Akibatnya, semua ini bertukar menjadi medan besar untuk sokongan, dan sepanjang masa sebahagian daripadanya boleh pecah.

Oleh itu, kami menggantikan faedah bahasa pengaturcaraan dengan penggunaan rangka kerja yang berbeza, memandangkan rangka kerja PHP agak berbeza, mereka mempunyai keupayaan yang berbeza, komuniti yang berbeza dan sokongan yang berbeza. Dan anda boleh menulis perkhidmatan supaya anda sudah mempunyai sesuatu yang sedia untuknya.

Setiap perkhidmatan mempunyai pasukan sendiri

Kelebihan utama kami, yang telah meningkat selama beberapa tahun, ialah setiap perkhidmatan mempunyai pasukannya sendiri. Ini mudah untuk projek besar, anda boleh menjimatkan masa pada dokumentasi, pengurus mengetahui projek mereka dengan baik.

Anda boleh menyerahkan tugasan daripada sokongan dengan mudah. Sebagai contoh, perkhidmatan insurans rosak. Dan segera pasukan yang berurusan dengan insurans pergi untuk membetulkannya.

Ciri baharu sedang dibuat dengan cepat, kerana apabila anda mempunyai satu perkhidmatan atom, anda boleh dengan cepat memasukkan sesuatu ke dalamnya.

Dan apabila anda memecahkan perkhidmatan anda, dan ini tidak dapat dielakkan berlaku, anda tidak menjejaskan perkhidmatan orang lain, dan pembangun daripada pasukan lain tidak akan datang kepada anda dengan sedikit pun dan berkata: "Ay-ay, jangan lakukan itu."

Seperti biasa, terdapat nuansa. Kami mempunyai pasukan yang stabil, pengurus dipaku kepada pasukan. Terdapat dokumen yang jelas, pengurus memantau dengan teliti segala-galanya. Setiap pasukan dengan pengurus mempunyai beberapa perkhidmatan, dan terdapat titik kecekapan tertentu.

Jika pasukan terapung (kami juga kadang-kadang menggunakan ini), terdapat kaedah yang baik dipanggil "peta bintang".

Anda mempunyai senarai perkhidmatan dan orang. Asterisk bermaksud orang itu pakar dalam perkhidmatan ini, buku bermakna orang itu sedang mengkaji perkhidmatan ini. Tugas orang itu ialah menukar buku kecil untuk asterisk. Dan jika tiada apa yang ditulis di hadapan perkhidmatan, maka masalah bermula, yang akan saya bicarakan lebih lanjut.

Bagaimanakah perkhidmatan anak yatim muncul?

Masalah pertama, cara pertama untuk mendapatkan perkhidmatan anak yatim dalam infrastruktur anda ialah memecat orang. Adakah sesiapa pernah mempunyai perniagaan memenuhi tarikh akhir sebelum tugasan dinilai? Kadang-kadang ia berlaku bahawa tarikh akhir adalah ketat dan tidak ada masa yang cukup untuk dokumentasi. "Kami perlu menyerahkan perkhidmatan kepada pengeluaran, kemudian kami akan menambahnya."

Jika pasukan itu kecil, ia berlaku bahawa terdapat satu pemaju yang menulis segala-galanya, selebihnya berada di sayap. "Saya menulis seni bina asas, mari tambah antara muka." Kemudian pada satu ketika pengurus, sebagai contoh, pergi. Dan dalam tempoh ini, apabila pengurus telah pergi dan yang baru belum dilantik, pemaju sendiri memutuskan ke mana perkhidmatan itu akan pergi dan apa yang berlaku di sana. Dan seperti yang kita tahu (mari kita kembali beberapa slaid), dalam beberapa pasukan terdapat orang-orang kepingan salji, kadang-kadang ketua pasukan kepingan salji. Kemudian dia berhenti, dan kami mendapat perkhidmatan anak yatim.

Pada masa yang sama, tugas dari sokongan dan dari perniagaan tidak hilang; Sekiranya terdapat sebarang ralat seni bina semasa pembangunan perkhidmatan, ia juga akan menjadi tertunggak. Perkhidmatan ini perlahan-lahan merosot.

Bagaimana untuk mengenal pasti anak yatim?

Senarai ini menerangkan keadaan dengan baik. Siapa yang belajar apa-apa tentang infrastruktur mereka?

Mengenai penyelesaian yang didokumenkan: terdapat perkhidmatan dan, secara amnya, ia berfungsi, ia mempunyai manual dua halaman tentang cara mengendalikannya, tetapi tiada siapa yang tahu cara ia berfungsi di dalamnya.

Atau, sebagai contoh, terdapat beberapa jenis pemendek pautan. Sebagai contoh, pada masa ini kami mempunyai tiga pemendek pautan yang digunakan untuk tujuan yang berbeza dalam perkhidmatan yang berbeza. Ini hanyalah akibatnya.

Sekarang saya akan menjadi kapten yang jelas. Apa yang patut dibuat? Pertama, kita perlu memindahkan perkhidmatan kepada pengurus lain, pasukan lain. Jika ketua pasukan anda masih belum berhenti, maka dalam pasukan lain ini, apabila anda memahami bahawa perkhidmatan itu seperti anak yatim, anda perlu memasukkan seseorang yang memahami sekurang-kurangnya sesuatu mengenainya.

Perkara utama: anda mesti mempunyai prosedur pemindahan yang ditulis dalam darah. Dalam kes kami, saya biasanya memantau ini, kerana saya memerlukan semuanya untuk berfungsi. Pengurus memerlukannya untuk dihantar dengan cepat, dan apa yang berlaku kemudiannya tidak lagi begitu penting kepada mereka.

Cara seterusnya untuk menjadikan anak yatim ialah "Kami akan melakukannya secara penyumberan luar, ia akan menjadi lebih pantas, dan kemudian kami akan menyerahkannya kepada pasukan." Sudah jelas bahawa setiap orang mempunyai beberapa rancangan dalam pasukan, satu giliran. Selalunya pelanggan perniagaan berfikir bahawa penyumber luar akan melakukan perkara yang sama seperti jabatan teknikal yang dimiliki oleh syarikat. Walaupun motivator mereka berbeza. Terdapat penyelesaian teknologi pelik dan penyelesaian algoritma pelik dalam penyumberan luar.

Sebagai contoh, kami mempunyai perkhidmatan yang mempunyai Sphinx di pelbagai tempat yang tidak dijangka. Saya akan memberitahu anda kemudian apa yang saya perlu lakukan.

Penyumber luar mempunyai rangka kerja yang ditulis sendiri. Ini hanyalah PHP kosong dengan salin-tampal daripada projek sebelumnya, di mana anda boleh menemui pelbagai perkara. Skrip penyebaran adalah kelemahan besar apabila anda perlu menggunakan beberapa skrip Bash yang kompleks untuk menukar beberapa baris dalam beberapa fail, dan skrip penggunaan ini dipanggil oleh beberapa skrip ketiga. Akibatnya, anda menukar sistem penempatan, pilih sesuatu yang lain, lompat, tetapi perkhidmatan anda tidak berfungsi. Kerana di sana adalah perlu untuk meletakkan 8 lagi pautan antara folder yang berbeza. Atau ia berlaku bahawa seribu rekod berfungsi, tetapi seratus ribu tidak lagi berfungsi.

Saya akan terus menjadi kapten. Menerima perkhidmatan penyumberan luar adalah prosedur wajib. Adakah sesiapa pernah menerima perkhidmatan penyumberan luar dan tidak diterima di mana-mana? Ini tidak begitu popular, sudah tentu, sebagai perkhidmatan anak yatim, tetapi masih.

Perkhidmatan perlu disemak, perkhidmatan perlu disemak, kata laluan perlu ditukar. Kami mempunyai kes apabila mereka memberi kami perkhidmatan, terdapat panel pentadbir "jika log masuk == 'admin' && kata laluan == 'admin'...", ia ditulis betul-betul dalam kod. Kami duduk dan berfikir, dan orang menulis ini pada tahun 2018?

Menguji kapasiti penyimpanan juga merupakan perkara yang perlu. Anda perlu melihat apa yang akan berlaku pada seratus ribu rekod, walaupun sebelum anda meletakkan perkhidmatan ini dalam pengeluaran di suatu tempat.

Tidak perlu malu menghantar perkhidmatan untuk penambahbaikan. Apabila anda berkata: "Kami tidak akan menerima perkhidmatan ini, kami mempunyai 20 tugas, lakukannya, maka kami akan terima," ini adalah perkara biasa. Hati nurani anda tidak boleh disakiti oleh fakta bahawa anda menubuhkan pengurus atau perniagaan itu membazirkan wang. Perniagaan kemudiannya akan membelanjakan lebih banyak.

Kami mempunyai kes apabila kami memutuskan untuk menyumber luar projek perintis.

Ia dihantar tepat pada masanya, dan ini adalah satu-satunya kriteria kualiti. Itulah sebabnya kami membuat satu lagi projek perintis, yang sebenarnya bukan juruterbang lagi. Perkhidmatan ini telah diterima, dan melalui cara pentadbiran mereka berkata, inilah kod anda, inilah pasukan, inilah pengurus anda. Perkhidmatan tersebut sebenarnya sudah mula mengaut keuntungan. Pada masa yang sama, sebenarnya, mereka masih yatim piatu, tiada siapa yang memahami cara mereka bekerja, dan pengurus melakukan yang terbaik untuk menolak tugas mereka.

Terdapat satu lagi konsep hebat - pembangunan gerila. Apabila sesetengah jabatan, biasanya jabatan pemasaran, ingin menguji hipotesis dan memerintahkan keseluruhan perkhidmatan daripada sumber luar. Lalu lintas mula mencurah-curah ke dalamnya, mereka menutup dokumen, menandatangani dokumen dengan kontraktor, mula beroperasi dan berkata: "Kawan-kawan, kami mempunyai perkhidmatan di sini, ia sudah mempunyai lalu lintas, ia membawa kepada kami wang, mari kita terima." Kami seperti, "Oppa, macam mana boleh jadi."

Dan satu lagi cara untuk mendapatkan perkhidmatan anak yatim: apabila sesetengah pasukan tiba-tiba menjadi terlebih beban, pihak pengurusan berkata: "Mari kita pindahkan perkhidmatan pasukan ini kepada pasukan lain, ia mempunyai beban yang lebih kecil." Dan kemudian kami akan memindahkannya kepada pasukan ketiga dan menukar pengurus. Dan akhirnya kami mempunyai anak yatim lagi.

Apa masalah anak yatim?

Siapa yang tidak tahu, ini adalah kapal perang Wasa yang dibesarkan di Sweden, terkenal dengan fakta bahawa ia tenggelam 5 minit selepas dilancarkan. Dan Raja Sweden, dengan cara itu, tidak menghukum sesiapa pun untuk ini. Ia dibina oleh dua generasi jurutera yang tidak tahu bagaimana untuk membina kapal tersebut. Kesan semula jadi.

Kapal itu boleh tenggelam, dengan cara itu, jauh lebih buruk, sebagai contoh, apabila raja sudah menaikinya di suatu tempat dalam ribut. Oleh itu, dia lemas serta-merta, menurut Agile adalah baik untuk gagal awal.

Jika kita gagal awal, selalunya tiada masalah. Sebagai contoh, semasa penerimaan ia dihantar untuk semakan. Tetapi jika kita gagal dalam pengeluaran, apabila wang dilaburkan, maka mungkin ada masalah. Akibat, seperti yang dipanggil dalam perniagaan.

Mengapa perkhidmatan anak yatim berbahaya:

• Perkhidmatan mungkin rosak secara tiba-tiba.
• Servis mengambil masa yang lama untuk dibaiki atau tidak dibaiki langsung.
• Masalah keselamatan.
• Masalah dengan penambahbaikan dan kemas kini.
• Jika perkhidmatan penting rosak, reputasi syarikat akan terjejas.

Apa yang perlu dilakukan dengan perkhidmatan anak yatim?

Saya akan ulangi apa yang perlu dilakukan lagi. Pertama, mesti ada dokumentasi. 7 tahun di Banki.ru mengajar saya bahawa penguji tidak sepatutnya mengambil kata-kata pembangun, dan operasi tidak sepatutnya mengambil perkataan semua orang. Kita perlu menyemak.

Kedua, adalah perlu untuk menulis gambar rajah interaksi, kerana ia berlaku bahawa perkhidmatan yang tidak diterima dengan baik mengandungi kebergantungan yang tidak dikatakan oleh sesiapa. Sebagai contoh, pembangun memasang perkhidmatan pada kunci mereka ke beberapa Yandex.Maps atau Dadata. Anda telah kehabisan had percuma, semuanya rosak, dan anda tidak tahu apa yang berlaku sama sekali. Semua rake tersebut mesti diterangkan: perkhidmatan menggunakan Dadata, SMS, sesuatu yang lain.

Ketiga, bekerja dengan hutang teknikal. Apabila anda melakukan beberapa jenis tongkat atau menerima perkhidmatan dan mengatakan bahawa sesuatu perlu dilakukan, anda perlu memastikan bahawa ia telah selesai. Kerana itu mungkin ternyata lubang kecil itu tidak begitu kecil, dan anda akan jatuh melaluinya.

Dengan tugas seni bina, kami mempunyai cerita tentang Sphinx. Salah satu perkhidmatan menggunakan Sphinx untuk memasukkan senarai. Hanya senarai penomboran, tetapi ia diindeks semula setiap malam. Ia dipasang daripada dua indeks: satu indeks yang besar diindeks setiap malam, dan terdapat juga indeks kecil yang disikat kepadanya. Setiap hari, dengan kebarangkalian 50% sama ada pengeboman atau tidak, indeks itu ranap semasa pengiraan, dan berita kami berhenti mengemas kini di halaman utama. Pada mulanya ia mengambil masa 5 minit untuk indeks diindeks semula, kemudian indeks meningkat, dan pada satu ketika ia mula mengambil masa 40 minit untuk mengindeks semula. Apabila kami memotong perkara ini, kami menarik nafas lega, kerana jelas bahawa sedikit masa lagi akan berlalu dan indeks kami akan diindeks semula sepenuh masa. Ini akan menjadi kegagalan untuk portal kami, tiada berita selama lapan jam - itu sahaja, perniagaan telah berhenti.

Rancang untuk bekerja dengan perkhidmatan anak yatim

Sebenarnya, ini sangat sukar dilakukan, kerana devops adalah mengenai komunikasi. Anda ingin menjalin hubungan baik dengan rakan sekerja anda, dan apabila anda mengecam rakan sekerja dan pengurus anda dengan peraturan, mereka mungkin mempunyai perasaan bercanggah terhadap orang yang melakukan perkara ini.

Sebagai tambahan kepada semua perkara ini, terdapat satu lagi perkara penting: orang tertentu mesti bertanggungjawab untuk setiap perkhidmatan tertentu, untuk setiap bahagian khusus prosedur penempatan. Apabila tiada orang dan anda perlu menarik beberapa orang lain untuk mengkaji keseluruhan perkara ini, ia menjadi sukar.

Jika semua ini tidak membantu, dan perkhidmatan anak yatim anda masih anak yatim, tiada siapa yang mahu mengambilnya, dokumentasi tidak ditulis, pasukan yang dipanggil ke perkhidmatan ini enggan melakukan apa-apa, ada cara mudah - untuk membuat semula segalanya.

Iaitu, anda mengambil semula keperluan untuk perkhidmatan itu dan menulis perkhidmatan baharu, lebih baik, pada platform yang lebih baik, tanpa penyelesaian teknologi yang pelik. Dan anda berhijrah kepadanya dalam peperangan.

Kami menghadapi situasi apabila kami mengambil perkhidmatan pada Yii 1 dan menyedari bahawa kami tidak dapat membangunkannya lagi, kerana kami kehabisan pembangun yang boleh menulis dengan baik pada Yii 1. Semua pembangun menulis dengan baik pada Symfony XNUMX. Apa nak buat? Kami memperuntukkan masa, memperuntukkan pasukan, memperuntukkan pengurus, menulis semula projek dan lancar menukar trafik kepadanya.

Selepas ini, perkhidmatan lama boleh dipadamkan. Ini adalah prosedur kegemaran saya, apabila anda perlu mengambil dan membersihkan beberapa perkhidmatan daripada sistem pengurusan konfigurasi dan kemudian menyemak dan melihat bahawa semua kereta dalam pengeluaran telah dilumpuhkan, supaya pemaju tidak mempunyai sebarang kesan yang tersisa. Repositori kekal dalam Git.

Ini sahaja yang saya ingin bincangkan, saya bersedia untuk membincangkan, topiknya adalah holivar, ramai yang telah berenang di dalamnya.

Slaid mengatakan bahawa anda menyatukan bahasa. Contohnya ialah mengubah saiz gambar. Adakah benar-benar perlu untuk mengehadkannya kepada satu bahasa? Kerana saiz semula imej dalam PHP, sebenarnya boleh dilakukan di Golang.

Malah, ia adalah pilihan, seperti semua amalan. Mungkin, dalam beberapa kes, ia juga tidak diingini. Tetapi anda perlu faham bahawa jika anda mempunyai jabatan teknikal dalam syarikat yang terdiri daripada 50 orang, 45 daripada mereka adalah pakar PHP, 3 lagi adalah devops yang mengetahui Python, Ansible, Puppet dan sesuatu seperti itu, dan hanya seorang daripada mereka yang menulis dalam beberapa jenis bahasa beberapa perkhidmatan mengubah saiz imej Go, kemudian apabila ia keluar, kepakaran itu menyertainya. Dan pada masa yang sama, anda perlu mencari pembangun khusus pasaran yang mengetahui bahasa ini, terutamanya jika ia jarang berlaku. Maksudnya, dari sudut organisasi, ini bermasalah. Dari sudut pandangan devops, anda bukan sahaja perlu mengklon beberapa set buku permainan siap sedia yang anda gunakan untuk menggunakan perkhidmatan, tetapi anda perlu menulisnya sekali lagi.

Kami sedang membina perkhidmatan pada Node.js, dan ini hanya akan menjadi platform berdekatan untuk setiap pembangun dengan bahasa yang berasingan. Tetapi kami duduk dan berfikir bahawa permainan itu bernilai lilin. Iaitu, ini adalah soalan untuk anda duduk dan fikirkan.

Bagaimanakah anda memantau perkhidmatan anda? Bagaimanakah anda mengumpul dan memantau log?

Kami mengumpul log dalam Elasticsearch dan meletakkannya di Kibana, dan bergantung pada sama ada ia adalah persekitaran pengeluaran atau ujian, pengumpul berbeza digunakan di sana. Di suatu tempat Lumberjack, di tempat lain sesuatu yang lain, saya tidak ingat. Dan masih terdapat beberapa tempat dalam perkhidmatan tertentu di mana kami memasang Telegraf dan merakam di tempat lain secara berasingan.

Bagaimana untuk hidup dengan Puppet dan Ansible dalam persekitaran yang sama?

Malah, kita kini mempunyai dua persekitaran, satu ialah Puppet, satu lagi adalah Ansible. Kami sedang berusaha untuk menghibridkan mereka. Ansible ialah rangka kerja yang baik untuk persediaan awal, Boneka ialah rangka kerja buruk untuk persediaan awal kerana ia memerlukan kerja langsung pada platform dan Boneka memastikan penumpuan konfigurasi. Ini bermakna bahawa platform mengekalkan dirinya dalam keadaan terkini, dan agar mesin yang tidak dapat dipastikan sentiasa dikemas kini, anda perlu menjalankan buku permainan padanya sepanjang masa dengan beberapa kekerapan. Itu bezanya.

Bagaimanakah anda mengekalkan keserasian? Adakah anda mempunyai konfigurasi dalam kedua-dua Ansible dan Puppet?

Ini adalah kesakitan besar kami, kami mengekalkan keserasian dengan tangan kami dan memikirkan bagaimana untuk meneruskan dari semua ini di suatu tempat sekarang. Ternyata Puppet melancarkan pakej dan mengekalkan beberapa pautan di sana, dan Ansible, sebagai contoh, melancarkan kod dan melaraskan konfigurasi aplikasi terkini di sana.

Pembentangan adalah mengenai versi Ruby yang berbeza. penyelesaian apa?

Kami menghadapi perkara ini di satu tempat, dan kami perlu menyimpannya di kepala kami sepanjang masa. Kami hanya mematikan bahagian yang berjalan pada Ruby yang tidak serasi dengan aplikasi dan memisahkannya.

Persidangan tahun ini DevOpsDays Moscow akan berlangsung pada 7 Disember di Technopolis. Kami menerima permohonan untuk laporan sehingga 11 November. Tulis kami jika anda ingin bercakap.

Pendaftaran peserta dibuka, sertai kami!

Sumber: www.habr.com