Dalam laporan itu, saya ingat evolusi Python di perusahaan: dari layanan pertama yang dikemas dalam paket deb dan diluncurkan dengan bare metal, hingga repositori mono yang sulit dengan sistem build dan cloud sendiri. Lebih banyak dalam cerita adalah Django, Flask, Tornado, Docker, PyCharm, IPv6 dan hal-hal lain yang telah kita temui selama bertahun-tahun.
- Biarkan saya ceritakan tentang diri saya. Saya datang ke Yandex pada 2008. Pada awalnya saya melakukan layanan konten, khususnya Yandex.Afisha. Saya menulis di sana dengan Python, kami menulis ulang layanan dari Perl dan teknologi menyenangkan lainnya.
Kemudian saya beralih ke layanan internal. Departemen layanan internal secara bertahap berubah menjadi pengelolaan antarmuka pencarian dan layanan untuk organisasi. Sudah lama, dari pengembang sederhana, saya telah berkembang menjadi kepala pengembangan python unit kami, sekitar 30 orang.
Poin penting: perusahaan itu sangat besar, dan saya tidak bisa berbicara untuk semua Yandex. Tentu saja, saya berkomunikasi dengan rekan kerja dari departemen lain, saya tahu bagaimana mereka hidup. Tetapi pada dasarnya saya hanya dapat berbicara tentang departemen kami, tentang produk kami. Pembicaraan saya akan fokus pada ini. Kadang-kadang saya akan memberi tahu Anda bahwa di tempat lain di Yandex mereka melakukan ini. Tetapi tidak akan sering.
Python digunakan di banyak tempat di perusahaan: teknologi apa pun, tumpukan teknologi apa pun, bahasa apa pun. Segala sesuatu yang terlintas dalam pikiran di suatu perusahaan adalah dalam bentuk percobaan, atau sesuatu yang lain. Dan dalam layanan Yandex Yandex pasti akan ada Python dalam satu atau komponen lain.
Segala sesuatu yang akan saya ceritakan adalah interpretasi saya tentang berbagai peristiwa. Saya tidak berpura-pura seratus persen objektif. Semua ini juga melewati tangan saya, itu berwarna secara emosional. Semua pengalaman saya sangat pribadi.
Bagaimana laporan akan disusun? Untuk membuatnya lebih mudah bagi Anda untuk memahami informasi, dan bagi saya untuk memberi tahu, saya memutuskan untuk memecah seluruh evolusi dari tahun 2007 menjadi sekitar momen saat ini menjadi beberapa era. Laporan akan disusun secara ketat oleh era-era ini. Era ini berarti semacam perubahan radikal dalam infrastruktur atau pendekatan pembangunan. Jika infrastruktur besi kami berubah dan pada saat yang sama kami mengubah cara kami mengembangkan layanan, alat apa yang kami gunakan, ini adalah era. Jelas saya harus menyesuaikan sedikit. Jelas bahwa semuanya tidak terjadi secara serempak, dan ada celah di antara perubahan-perubahan ini, tetapi saya mencoba menyesuaikan semuanya di bawah satu garis waktu, hanya untuk membuatnya lebih ringkas.
Zaman apa yang kita miliki? Di sini juga, semuanya adalah hak cipta, semua nama adalah milikku. Era pertama disebut "perangkat keras", inilah yang kami mulai dengan ketika saya datang ke perusahaan. Karena itu, semuanya telah berubah sedikit. Era menjadi "iron + venv". Selanjutnya saya akan mengungkapkan apa yang tersembunyi di balik nama-nama ini. Pertama, saya ingin memberi Anda panduan tentang apa yang akan saya katakan.
Era berikutnya adalah "wadah", semuanya lebih atau kurang jelas di sini. Era di mana kita bergerak saat ini adalah "perakitan biner", saya juga akan memberi tahu Anda tentang hal itu.
Bagaimana masing-masing era akan terstruktur? Ini juga penting, karena saya ingin membuat narasi ritmis, sehingga setiap bagian terstruktur dengan ketat dan lebih mudah dipahami. Era ini digambarkan oleh infrastruktur, kerangka kerja yang kita gunakan, bagaimana kita bekerja dengan ketergantungan, lingkungan pengembangan seperti apa yang kita miliki, dan pro dan kontra dari pendekatan ini atau itu.
(Jeda teknis.) Saya memberi tahu Anda pengantar, saya memberi tahu Anda bagaimana laporan akan disusun, mari kita beralih ke cerita itu sendiri.
Usia 1: zat besi
Layanan pertama yang saya mulai lakukan ketika saya bergabung dengan perusahaan disebut "Where Everybody Goes". Itu adalah satelit Afisha, layanan Django besar pertama.
Grisha Bakunovbobukdapat mengetahui mengapa ia pernah memutuskan untuk mentransfer Django ke Yandex - secara umum, itu terjadi. Kami mulai melakukan layanan di Django.
Saya datang, dan mereka mengatakan kepada saya: mari kita lakukan "Ke mana semua orang pergi." Kemudian sudah ada semacam pangkalan. Saya terhubung, dan kami pikir itu semacam eksperimen - apakah akan berhasil atau tidak. Eksperimen itu ternyata berhasil. Semua orang sepakat bahwa dimungkinkan untuk membuat layanan web di Yandex dengan Python dan Django. Baik! Infrastruktur kami siap untuk ini, orang-orang siap, dunia juga siap. Ayo, mari kita lanjutkan pendistribusian Python dan Django lebih lanjut ke seluruh perusahaan. Kami mulai melakukannya. Tulis ulang Yandex.Afisha, Weather. Kemudian - program TV. Kemudian semuanya berjalan seperti kabut, mereka mulai menulis ulang semuanya.
Pada saat itu, infrastruktur Yandex tampak seperti seluruh backend sebagian besar ditulis dalam plus. Jelas, langkah menuju Python mempercepat pembangunan di banyak tempat, yang diterima dengan baik oleh perusahaan dan manajemennya. Sekarang mari kita bicara tentang infrastruktur - di mana layanan ini bekerja, apa yang mereka lakukan dan semua itu.
Ini adalah mesin besi, maka nama zaman ini. Apa itu mobil besi? Mereka hanya server di pusat data. Ada banyak server, mereka semua digabung menjadi sekelompok, katakanlah, 15 mesin. Lalu 30, lalu 50, 100. Dan semua ini di Debian atau Ubuntu. Pada saat itu, kami telah bermigrasi dari Debian ke Ubuntu. Kami meluncurkan semua aplikasi melalui proses init standar. Semuanya standar, seperti yang dilakukan pada saat itu. Agar aplikasi kami dapat berkomunikasi di server web, kami menggunakan protokol FastCGI dan pustaka flup. Jika Anda telah bekerja dengan Python sejak lama, Anda mungkin pernah mendengarnya. Tapi sekarang, saya yakin Anda tidak menggunakannya, karena sudah usang secara moral dan merupakan hal yang sangat aneh, itu bekerja sangat lambat.
Pada saat itu, jelas, tidak ada Python ketiga, kami menulis dalam Python 2.3. Kemudian mereka bermigrasi ke 2.4. Masa liar. Saya bahkan tidak ingin memikirkan mereka, karena bahasa, komunitas, dan ekosistem tampak sangat berbeda, walaupun juga keren, dan banyak yang tertarik dengan hal ini. Secara pribadi, itu membenamkan saya dalam dunia Python - bahwa meskipun ada kekhasan dan keanehan, sudah jelas bahwa Python adalah teknologi yang menjanjikan, Anda dapat menginvestasikan waktu Anda di sana.
Poin penting: maka kita belum menggunakan nginx, tidak menggunakan Apache lagi, tetapi menggunakan server web yang disebut Lighttpd. Jika Anda telah melakukan layanan web untuk waktu yang lama, Anda mungkin pernah mendengarnya juga. Pada satu titik dia sangat populer.
Dari kerangka kerja, kami benar-benar menggunakan Django. Kami mulai membuat layanan besar di Django. Di suatu tempat di perusahaan itu ada CherryPy, di suatu tempat - Web.py. Anda mungkin pernah mendengar tentang kerangka kerja ini juga. Sekarang mereka tidak berada di peran pertama, mereka telah lama disingkirkan oleh kerangka kerja yang lebih muda dan berani. Kemudian mereka memiliki ceruk mereka sendiri, tetapi akhirnya mereka mati cepat atau lambat, kami berhenti melakukan sesuatu pada mereka. Mereka mulai melakukan semuanya di Django.
Pada titik ini, Python menjadi begitu luas di perusahaan sehingga keluar dari departemen kami: layanan web di Python dan Django mulai dibuat di mana-mana di perusahaan.
Mari beralih ke bekerja dengan dependensi. Dan kemudian ada sesuatu yang Anda, kemungkinan besar, juga temui jika Anda datang untuk bekerja di sebuah perusahaan besar: perusahaan sudah memiliki infrastruktur yang mapan, Anda perlu menyesuaikannya. Yandex memiliki infrastruktur deb, repositori internal paket deb. Diyakini bahwa pengembang Yandex tahu cara menyusun paket deb ini. Kami dipaksa untuk mengintegrasikan ke dalam aliran ini, mengumpulkan proyek-proyek kami dalam bentuk paket deb penuh, dan kemudian, sebagai paket deb, kami meletakkan semua ini di server yang saya bicarakan, dan kemudian meletakkannya di cluster sebagai paket deb juga.
Akibatnya, semua dependensi dan perpustakaan, Django yang sama, kami juga harus mengemas paket deb. Untuk melakukan ini, kami membuat infrastruktur sendiri, mengangkat repositori internal, dan belajar bagaimana melakukannya. Ini bukan kegiatan yang sangat orisinal: jika Anda mencoba membuat RPM atau paket deb, maka Anda mengetahuinya. RPM sedikit lebih sederhana, deb lebih kompleks. Tapi semua sama - itu tidak akan berhasil hanya datang dari jalan dan klik untuk mulai melakukannya. Anda perlu menggali sedikit.
Kami telah membangun paket deb selama bertahun-tahun setelah itu. Dan bagi saya tampaknya tidak semua orang yang melakukan ini untuk pekerjaan perlu memahami apa yang terjadi di bawah tenda. Mereka hanya mengambil dari satu sama lain, menyalin kosong, templat, tetapi tidak menggali secara mendalam. Tetapi mereka yang menggali apa yang sedang terjadi di dalamnya menjadi sangat berguna dan sangat menuntut kolega: jika sesuatu tidak akan terjadi tiba-tiba, semua orang mendatangi mereka untuk meminta nasihat dan meminta nuansa dan bantuan dalam debugging. Itu adalah waktu yang lucu, karena saya tertarik untuk mencari tahu apa yang ada di dalamnya. Dengan demikian mendapatkan popularitas murah dengan kolega.
Selain ekosistem dependensi, ada juga yang bekerja dengan kode bersama. Sudah di awal ada pertumbuhan eksplosif dalam jumlah proyek, dan itu diperlukan untuk bekerja dengan kode umum, membuat perpustakaan umum, dan sebagainya. Kami mulai melakukan semacam ini open source internal. Mereka membuat fungsi umum otorisasi, bekerja dengan log, dengan hal-hal umum lainnya, API internal, repositori internal. Kami melakukan semua ini dalam bentuk perpustakaan, memasukkannya ke dalam repositori internal. Pada awalnya, ini adalah repositori SVN, kemudian GitHub internal.
Dan pada akhirnya mereka mengemas semua dependensi ini, semua perpustakaan ini juga dalam deb, dimuat ke dalam satu repositori. Dari sini, lingkungan paket seperti itu terbentuk. Jika Anda memulai proyek baru, Anda bisa meletakkan beberapa perpustakaan di sana, mendapatkan basis fungsionalitas, dan segera meluncurkan proyek di infrastruktur Yandex. Itu sangat nyaman.
Seperti apa rupa server kami? Secara klasik. Ada kecanduan sistemik, ada kecanduan hewan peliharaan. Beberapa hal mengikuti dari ini. Pertama-tama, semua aplikasi yang berjalan di server yang sama dan, karenanya, pada cluster yang sama, harus memiliki dependensi yang sama. Karena jika Anda menginstal sistem paket, itu selalu satu versi, tidak mungkin ada beberapa, Anda harus menyinkronkan.
Ketika ada beberapa proyek, Anda masih bisa melakukannya. Ketika ada banyak, semuanya menjadi sangat rumit. Mereka dibuat oleh tim yang berbeda, sulit bagi mereka untuk setuju. Setiap tim ingin meningkatkan versi awal ke beberapa perpustakaan atau ingin meningkatkan kerangka kerja. Dan semua orang harus mengikuti ini. Seiring waktu, ini menciptakan banyak masalah. Ini mendorong kami untuk meninggalkan skema seperti itu, untuk pindah ke era berikutnya. Tapi saya akan membicarakannya nanti.
Mari kita bicara tentang lingkungan pengembangan. Tetapi ada pemahaman yang diperluas tentang lingkungan pembangunan. Ini adalah bagaimana Anda mulai bekerja, bagaimana Anda menulis kode, bagaimana Anda men-debug-nya, bagaimana Anda bekerja dengannya, di mana Anda mengujinya, bagaimana Anda menjalankannya, di mana Anda menjalankan tes dan semua itu.
Ketika saya bergabung dengan perusahaan, kami semua bekerja di server dev jarak jauh. Artinya, Anda memiliki semacam desktop, di Windows atau Linux, itu tidak masalah. Anda pergi ke server jauh dengan Debian yang benar dan repositori paket yang benar. Dan Anda jalankan, jalankan vim, Emacs, tulis kode, debug.
Ini tidak terlalu nyaman, tetapi kemudian kami tidak benar-benar tahu kehidupan lain. Mereka yang beruntung, yang memiliki desktop atau laptop dengan Linux, dapat mencoba melakukan ini secara lokal. Tetapi tidak ada instruksi khusus, tidak ada. Waktu yang sedikit liar. Orang-orang istimewa yang pada waktu itu hidup di Windows dan Mac dan ingin mengembangkan secara lokal, mengangkat mesin virtual, di dalamnya Linux. Mereka menulis kode di dalam mesin virtual ini dan meluncurkannya. Lebih tepatnya, mereka menulis kode pada sistem host, menjalankan kode di dalam mesin virtual dan entah bagaimana meneruskan sistem file di sana sehingga semuanya tersinkronisasi. Semuanya bekerja dengan sangat buruk, tapi entah bagaimana itu bertahan.
Apa pro dan kontra dari era ini, pendekatan pembangunan ini? Bahkan - minus solid:
- Seperti yang saya katakan, cluster bersama penuh sesak.
- Semua proyek pada cluster harus memiliki dependensi yang sama.
- . , , Django . , . 15-20 . . , , — . X, . , . - , - , . . , , . .
- Yandex bergantung pada infrastruktur Debian. Kami mendukungnya, mengumpulkan paket-paket, mendukung repositori internal. Dan ini, tentu saja, juga tidak terlalu bagus, tidak terlalu nyaman, tidak terlalu fleksibel. Anda bergantung pada hal-hal aneh yang tidak dilakukan untuk perusahaan. Debian sebagai solusi open source, sebagai distribusi Linux, tetap dibuat untuk tugas-tugas lain.
Mari kita bicara sedikit tentang Django. Mengapa kami mulai menggunakannya? Saya hanya berpikir sebelum laporan, sambil duduk di kursi, bahwa ternyata 11 tahun yang lalu saya berbicara di sebuah konferensi di Kiev dengan topik yang sama "Mengapa saya harus menggunakan Django?" Lalu aku menyukainya sendiri. Saya adalah seorang pengembang yang dikagumi yang membaca dokumentasi, membuat proyek pertama saya, dan tampaknya baginya bahwa segalanya, sekarang alat ini bersifat universal untuk segalanya dan Anda bisa, saya tidak tahu, bahkan palu paku di atasnya.
Tapi itu butuh waktu lama. Saya masih suka Django, masih digunakan cukup banyak di departemen kami dan di perusahaan pada umumnya. Misalnya, sebelum musim gugur 2018, Alice memiliki Django di backend. Sekarang dia tidak lagi di sana, tetapi untuk memulai dengan cepat, rekan-rekannya memilihnya. Karena beberapa keunggulannya masih berlaku - ekosistem yang besar, masih ada banyak spesialis. Ada semua baterai yang diperlukan.
Dan ada fleksibilitas yang cukup. Ketika Anda baru mulai bekerja dengan Django, tampaknya bagi Anda bahwa itu sangat membatasi Anda, mengikat Anda di tangan, membutuhkan aliran kerja tertentu dengannya. Tetapi jika Anda menggali sedikit lebih dalam, banyak hal dapat dimatikan, diubah, dikonfigurasi. Dan jika Anda menggunakan ini dengan terampil, Anda bisa mendapatkan semua barang yang terkait dengan kerangka kerja Python paling populer. Anda dapat melewati semua kontra. Ada juga banyak dari mereka, tetapi mereka dapat dihentikan dengan satu atau lain cara.
Usia 2: zat besi + venv
Kami telah selesai berbicara tentang era ini. Tahun 2011 telah berakhir, kami telah pindah ke era berikutnya, "Iron + venv". Anda sudah tahu tentang perangkat keras, sekarang Anda harus tahu apa yang terjadi, dari mana nama venv berasal. Penyimpangan liris: venv tidak muncul karena "virtualka" muncul. Mengapa mengutip? Karena kami mulai mencoba segala macam hal seperti wadah seperti OpenVZ atau LXC. Kemudian mereka berkembang sangat buruk, tidak seperti sekarang. Mereka tidak terbang sangat baik bersama kami. Kami masih hidup dalam kelompok umum, kami masih harus ada bersama-sama dengan proyek lain bahu-membahu di mesin yang sama. Kami sedang mencari solusi.
Sebagai contoh, kami beralih dari init ke sistem baru, dan sedikit kemudian kami mendapatkan fleksibilitas dalam meluncurkan aplikasi kami. Kami meninggalkan FastCGI dan mulai menggunakan antarmuka WSGI untuk berkomunikasi dengan server web, atau HTTP. Pada titik ini, kami sudah menggunakan kurang lebih Python modern, ekosistem sudah berkembang sangat baik. Kami beralih ke nginx sebagai server web, secara umum semuanya baik-baik saja.
Kami juga mulai mengadaptasi kerangka kerja baru untuk diri kami sendiri. Misalnya, mereka mulai menggunakan Tornado. Tentu saja, pada saat itu Flask sudah muncul, setelah 2012 Flask sudah sangat modis, populer dan Django mengancam akan membuang alas kerangka populer di Python. Dan, tentu saja, mereka mulai menggunakan Seledri. Karena ketika proyek bertambah, jumlahnya bertambah, mereka menjadi lebih sarat, menyelesaikan lebih banyak tugas, memproses lebih banyak data, maka Anda memerlukan kerangka kerja untuk pelaksanaan tugas offline pada cluster komputasi besar. Tentu saja, kami mulai menggunakan Seledri untuk ini. Tetapi lebih lanjut tentang itu nanti.
Apa yang telah berubah secara dramatis adalah cara kerjanya dengan dependensi. Kami mulai mengumpulkan lingkungan virtual. Sekitar waktu itu, komunitas python sampai pada titik bahwa adalah mungkin untuk tidak menempatkan pustaka python dalam sistem, tetapi untuk membuat lingkungan virtual, letakkan semua dependensi python yang Anda butuhkan di sana, dan lingkungan ini akan sepenuhnya independen. Mungkin ada banyak lingkungan virtual pada mesin. Ini adalah isolasi, kecanduan yang sangat nyaman. Anda masih menggunakannya. Dan kami juga menyesuaikan semuanya. Pada akhirnya, apa yang kita lakukan? Kami menciptakan lingkungan virtual dan meletakkan semua dependensi python di sana, mengemasnya ke dalam paket deb dan sudah menggulungnya ke server.
Akibatnya, semua proyek berhenti mengganggu satu sama lain, tergantung pada ketergantungan python umum dalam sistem, mereka dapat dengan mudah memilih versi kerangka kerja atau pustaka yang akan digunakan. Sangat nyaman. Perubahan juga terjadi pada kode bersama. Karena kami sebagian meninggalkan infrastruktur Debian dan, khususnya, berhenti menginstal dependensi python dengan paket deb, kami membutuhkan sesuatu di mana kami dapat membongkar semua kode umum dan perpustakaan umum kami dan dari tempat kami dapat meletakkannya.
Tautan dari slide
Pada saat itu, sudah ada beberapa implementasi PyPI, yaitu repositori paket pet, implementasi yang ditulis, khususnya, di Django. Dan kami memilih salah satunya. Ini disebut Localshop, inilah referensi. Repositori ini masih hidup, sudah ada sekitar seribu paket internal di dalamnya. Yaitu, dari sekitar 2011-2012, sebuah perusahaan ukuran Yandex menghasilkan sekitar seribu perpustakaan yang berbeda, utilitas yang ditulis dengan Python, yang diyakini dapat digunakan kembali dalam proyek lain. Anda dapat memperkirakan skalanya.
Semua perpustakaan diterbitkan di repositori internal ini. Dan kemudian dari sana mereka dipasang di Python, atau ada infrastruktur otomatis khusus yang mengubahnya menjadi Debian. Ini semua lebih atau kurang otomatis, nyaman. Kami berhenti menghabiskan begitu banyak sumber daya untuk memelihara infrastruktur Debian. Semuanya kurang lebih bekerja dengan sendirinya.
Dan ini adalah langkah kualitatif. Berikut adalah diagram dengan apa yang saya bicarakan.
Artinya, kecanduan python akhirnya tidak lagi sama untuk semua orang. Sistem yang masih ada, tetapi tidak banyak. Misalnya, driver untuk database, parser XML diperlukan binari sistem. Secara umum, pada saat itu kami tidak dapat menghilangkan dependensi ini.
Lingkungan pengembangan juga telah berubah. Sejak awal, lingkungan virtual menjadi tersedia dan bekerja di mana-mana pada saat itu, kami dapat membangun proyek kami secara umum pada platform lokal apa pun. Kehidupan yang sangat disederhanakan ini. Tidak perlu lagi berurusan dengan Debian, tidak ada mesin virtual yang perlu dibuat. Anda bisa mengambil OS apa saja, katakan virtual venv, lalu pip instal sesuatu. Dan itu berhasil.
Apa kelebihan skema ini? Karena kita telah hidup cukup lama - mungkin sedikit lebih dari tiga tahun - dengan konfigurasi parameter ini, menjadi lebih mudah untuk hidup dengan cluster-hostel. Ini sangat nyaman. Artinya, kami berhenti bergantung pada pembaruan global beberapa Django ini di seluruh perusahaan. Kita bisa lebih tepat memilih versi yang sesuai dengan kita, lebih sering memperbarui dependensi kritis jika mereka memperbaiki kerentanan atau hal lain. Dan ada cara yang sangat benar, kami menyukainya dan menyelamatkan kami dari segalanya.
Tapi ada juga kerugiannya. Ketergantungan sistem masih umum. Kadang-kadang itu dipecat, kadang-kadang menghalangi. Sekali lagi, saya akan sedikit melampaui lingkup departemen kami dan memberi tahu Anda tentang perusahaan. Karena perusahaannya besar, tidak semua orang mengikuti era ini bersama kami. Pada saat itu, perusahaan masih terus menggunakan paket deb untuk bekerja dengan dependensi dependensi. Biarkan saya memberi tahu Anda secara lebih rinci mengapa kami mulai menggunakan ini atau kerangka kerja itu. Khususnya, Tornado.
Kami membutuhkan kerangka kerja yang tidak sinkron, kami sekarang memiliki tugas untuk itu. Python ketiga dan asyncio-nya belum ada, atau mereka dalam keadaan awal, belum terlalu dapat diandalkan untuk menggunakannya. Oleh karena itu, kami mencoba memilih kerangka asinkron mana yang harus kami gunakan. Ada beberapa opsi: Gevent dan Twisted. Kemungkinan besar, ada lebih banyak, tetapi kami memilih di antara mereka. Twisted sudah digunakan di perusahaan - misalnya, backend Yandex.Taxi ditulis dalam Twisted. Tapi kami melihat mereka dan memutuskan bahwa Twisted tidak terlihat pythonic, bahkan PEP-8 tidak sesuai. Dan Gevent - ada di dalam semacam hack dengan tumpukan hewan peliharaan. Mari kita gunakan Tornado.
Kami tidak menyesalinya. Kami masih menggunakan Tornado di beberapa layanan - pada layanan yang belum kami tulis ulang dengan Python ketiga. Kerangka kerja ini telah membuktikan selama bertahun-tahun bahwa ia kompak, dapat diandalkan, dan dapat diandalkan.
Dan tentu saja, Seledri. Saya sudah sebagian bercerita tentang ini. Kami membutuhkan kerangka kerja untuk pelaksanaan tugas-tugas yang ditangguhkan. Kami mengerti.
Sangat nyaman bahwa Selery memiliki dukungan untuk berbagai broker. Kami secara aktif menggunakan b ini untuk berbagai tugas, mencoba menemukan satu atau broker lain yang benar. Di suatu tempat itu adalah Mongo, di suatu tempat SQS, di suatu tempat Redis. Tetapi kami berusaha memilih sesuai kebutuhan, dan kami berhasil.
Terlepas dari kenyataan bahwa ada banyak keluhan tentang Seledri, bagaimana ini ditulis di dalamnya, bagaimana men-debug-nya, jenis logging apa yang ada, itu lebih berfungsi. Seledri masih aktif digunakan di hampir setiap proyek di departemen kami, dan sejauh yang saya tahu, di luar proyek kami. Seledri harus dimiliki. Jika Anda membutuhkan eksekusi tugas yang ditangguhkan, maka semua orang mengambil Seledri. Atau pada awalnya mereka tidak mengambilnya, mereka mencoba mengambil sesuatu yang lain, tetapi kemudian mereka masih datang ke Seledri.
Kami pergi ke era berikutnya. Kami sudah mendekati saat ini, lebih modern. Di sini nama zaman berbicara untuk dirinya sendiri.
Usia 3: wadah
Kami mendapat cloud yang kompatibel dengan buruh pelabuhan. Di dalam, bukan runtime docker, tetapi pengembangan internal. Tetapi pada saat yang sama, Anda dapat menggunakan gambar buruh pelabuhan di sana. Itu banyak membantu kami karena kami dapat menggunakan seluruh ekosistem buruh pelabuhan untuk pengembangan dan pengujian. Kita dapat menggunakan segala macam barang, dan kemudian, hanya setelah menerima gambar yang diuji, unggah ke awan ini. Itu dimulai di sana dan bekerja sebagaimana mestinya.
Pada saat itu, kami sudah independen dari OS yang ada di dalam wadah. Anda bisa memilih. Kami, tentu saja, tidak menggunakan setan biasa, tetapi, misalnya, seorang pengawas. Selanjutnya, semua orang beralih ke uWSGI - ternyata uWSGI tidak hanya tahu cara menjalankan aplikasi web Anda dan menyediakan antarmuka untuk server web di dalamnya. Ini juga hanya hal umum yang bagus untuk memulai proses.
Namun, ada sedikit konfigurasi yang aneh, tetapi, secara umum, itu nyaman. Kami menyingkirkan kelebihan entitas dan mulai melakukan segalanya melalui uWSGI. Kami juga menggunakannya untuk berkomunikasi dengan server web. Keunikan cloud kami adalah sedemikian rupa sehingga kami tidak dapat menggunakan protokol uWSGI untuk berkomunikasi dengan penyeimbang, yang secara global terwakili di cloud, sebagai komponen. Tapi ini tidak menakutkan. Di dalam uWSGI, server HTTP diimplementasikan dengan cukup baik, ia bekerja dengan cepat dan andal.
Bagaimana dengan kerangka kerja? Kerangka kerja Falcon muncul, dan kami menulis ulang Alice yang sama dengan Django pada Falcon, karena ada sejumlah apis - perlu bagi mereka untuk bekerja dengan cepat, tetapi pada saat yang sama mereka tidak terlalu rumit.
Django di beberapa titik menjadi sedikit berlebihan, dan untuk meningkatkan kecepatan dan menghilangkan ketergantungan yang begitu besar, sebuah perpustakaan besar, kami memutuskan untuk menulis ulang ke Falcon.
Dan tentu saja asyncio. Kami mulai menulis layanan baru dengan Python ketiga, dan yang lama - untuk menulis ulang ke Python ketiga. Hanya di departemen kami sekarang ada sekitar 30 layanan yang ditulis dengan Python. Ini adalah 30 produk lengkap, dengan backend, frontend, dan infrastruktur mereka sendiri. Pemroses data menyediakan layanan bagi konsumen internal dan eksternal.
Tetapi perusahaan, seperti yang Anda tahu, memiliki ribuan layanan Python, dan mereka berbeda. Mereka berada pada kerangka kerja yang berbeda, Python berbeda, lebih tua dan lebih baru. Sekarang perusahaan menggunakan hampir semua kerangka kerja modern yang Anda tahu. Django, Labu, Falcon, sesuatu yang lain, asinkron - Tornado, Twisted, asyncio. Semuanya digunakan dan bermanfaat.
Mari kita kembali ke struktur zaman - bagaimana kita mulai bekerja dengan ketergantungan.
Semuanya sederhana di sini. Sekarang kita tidak bisa menggunakan lingkungan virtual. Kami tidak membutuhkan paket deb. Kami hanya pada saat membangun menempatkan gambar dengan semua yang kita butuhkan pip. Ini sepenuhnya terisolasi. Kami tidak mengganggu siapa pun. Dan sangat nyaman. Ketergantungan sistem apa pun, Anda dapat memilih gambar dasar apa saja dari Debian, Ubuntu, apa pun. Kami suka. Kebebasan penuh.
Tetapi pada kenyataannya, kebebasan penuh, seperti yang Anda tahu, memiliki sisi kedua. Ketika Anda memiliki perusahaan besar, dan terlebih lagi ketika Anda ingin mempromosikan metode dan metode pengembangan umum, metode pengujian, dan pendekatan dokumentasi - pada saat ini Anda dihadapkan dengan kenyataan bahwa kebun binatang ini, di satu sisi, membantu di suatu tempat. Di sisi lain, sebaliknya, itu menjadi rumit. Tidak dapat dengan mudah, misalnya, mengimplementasikan semacam perpustakaan di semua layanan, karena layanannya berbeda. Mereka memiliki versi Python, Django, atau kerangka kerja yang berbeda. Ini menyulitkan banyak hal. Tetapi pada akhirnya, server tipikal mulai terlihat seperti ini.
Ya, ini server. Kami memiliki wadah yang sepenuhnya independen. Masing-masing dari mereka memiliki lingkungan sistemnya sendiri, dan aplikasi kita berputar. Sangat nyaman. Tapi, seperti yang saya katakan, ada kekurangannya.
Mari kita kembali ke buruh pelabuhan sebentar. Kami mulai menggunakan buruh pelabuhan untuk pengembangan, itu banyak membantu kami.
Docker adalah untuk semua platform. Anda dapat menguji, menggunakan komposisi buruh pelabuhan, melakukan gerombolan buruh pelabuhan, dan mencoba meniru lingkungan produksi Anda pada kelompok kecil untuk menguji sesuatu. Mungkin memuat pengujian. Kami mulai aktif menggunakan ini.
Docker juga terintegrasi dengan sangat baik dengan segala macam lingkungan pengembangan. Sebagai contoh, saya berkembang di PyCharm, dan sebagian besar rekan saya juga. Ada dukungan bawaan untuk buruh pelabuhan, dengan pro dan kontra, tetapi secara umum semuanya berfungsi.
Itu menjadi sangat nyaman, kami mengambil langkah kualitatif, dan pada tahap inilah kami sekarang. Lebih mudah untuk mengembangkan menggunakan buruh pelabuhan, meskipun cloud target kami, tempat kami akan menggunakan aplikasi kami, bukan Docker Runtime, memiliki beberapa keterbatasan. Tetapi ini masih tidak menghalangi kita untuk menggunakan Mesin Docker secara lokal dan dalam tugas-tugas terkait.
Mari kita simak era ini. Kelebihan - isolasi lengkap, toolchain nyaman untuk pengembangan dan, seperti yang saya katakan, dukungan IDE.
Ada juga kekurangannya. Docker ada di mana-mana, tetapi jika itu bukan Linux, ia bekerja sedikit aneh. Pengembang Yandex yang memiliki buruh pelabuhan menginstal MacBook untuk Mac. Dan ada beberapa fitur, misalnya, IPv6 bekerja dengan aneh, atau Anda perlu mengubahnya. Dan di perusahaan kami, IPv6 sangat luas. Kami telah lama kekurangan alamat IPv4, sehingga seluruh infrastruktur internal sebagian besar terkait dengan IPv6. Dan ketika IPv6 tidak berfungsi di laptop Anda atau di dalam docker, yang ada di laptop, Anda menderita dan tidak bisa melakukan apa-apa, maka kita harus memotongnya.
Meskipun demikian, kami sangat mencintai buruh pelabuhan. Ini efisien dan memiliki ekosistem yang baik. Orang-orang datang kepada kita dari jalan, kita katakan - dapatkah Anda berlabuh? Mereka - ya, saya bisa. Semuanya sempurna. Seseorang datang dan secara langsung segera menjadi berguna, karena dia tidak perlu mempelajari bagaimana memulai dan bagaimana membangun sebuah proyek, bagaimana menjalankan tes, bagaimana melihat komposisi, atau beberapa hasil debug. Manusia sudah tahu segalanya. Ini adalah standar de facto di dunia luar, ini meningkatkan efisiensi kami, kami dapat dengan cepat memberikan fitur kepada pengguna, dan tidak menghabiskan uang untuk infrastruktur.
Usia 4: binary build
Tapi kita sudah mendekati era terakhir di mana kita baru saja memasuki. Dan di sini saya akan kembali ke awal laporan saya, ketika saya berkata: Anda datang ke perusahaan besar dengan pendekatan infrastruktur Anda sendiri. Itu sama dengan Yandex. Jika sebelumnya itu adalah infrastruktur Debian, sekarang berbeda. Untuk waktu yang lama, perusahaan telah memiliki repositori monolitik tunggal, di mana semua kode dikumpulkan secara bertahap. Mekanisme build, mekanisme pengujian terdistribusi, banyak alat dan segala sesuatu yang belum kita gunakan, tetapi mulai digunakan, telah dibuat untuk mengatasinya. Yaitu, proyek python kami juga mengunjungi repositori ini. Kami mencoba mengumpulkan dengan alat yang sama. Tapi karena alat-alat repositori tunggal ini, dipertajam terutama dalam C ++, Java dan Go, ada kekhasan di sana.
Keunikannya adalah ini. Jika sekarang hasil membangun proyek kami adalah Docker Engine, di mana kode sumber kami dengan semua dependensi berada, maka kami sampai pada kesimpulan bahwa hasil membangun proyek kami akan menjadi binar. Itu hanya binar, di mana ada interpreter python, kode dan python kami dan semua dependensi lain yang diperlukan, mereka terhubung secara statis.
Dipercaya bahwa Anda dapat datang, melempar binar ini ke sembarang layanan Linux dengan arsitektur yang kompatibel dan itu akan bekerja. Dan itu benar.
Sepertinya agak tidak wajar. Kebanyakan orang di komunitas python tidak melakukan itu, dan saya yakin Anda tidak melakukannya. Ini memiliki pro dan kontra. Pro:
- . , , , , , . , . , , . .
- , , , . , , . , . , checkout , , . .
- , .
Dan, tentu saja, ada kekurangannya: ekosistem tertutup. Seseorang dari luar perlu dibenamkan dalam cara kerjanya, untuk mengetahui cara kerjanya. Dia harus mencoba dan baru kemudian menjadi efektif. Kami hanya di awal perjalanan ini. Mungkin, jika saya datang ke konferensi ini dalam satu atau dua tahun, saya dapat memberi tahu Anda bagaimana kami mengalami transformasi ini. Tetapi sekarang kami optimis tentang masa depan dan mematuhi beberapa aturan internal perusahaan, dan kami lebih menyukainya daripada tidak, karena kami akan mendapatkan banyak barang internal.
kesimpulan
Mereka lebih filosofis. Laporan itu sendiri tidak terlalu teknis seperti filosofis.
- Evolusi tidak bisa dihindari. Jika Anda membuat layanan dan itu hidup untuk waktu yang lama, maka Anda akan mengembangkannya, mengembangkan infrastrukturnya, cara Anda mengembangkannya.
- . , , , .
- . , Django, . , . , , , Django - , . , .
- Python-. , , -. , , . , , , , , : , . , .
Topiknya sangat besar. Saya dengan singkat memberi tahu Anda tentang bagaimana dan apa yang kami lakukan, bagaimana Python telah berevolusi di negara kami. Anda dapat mengambil setiap era, mengambil setiap titik pada slide dan menganalisisnya lebih dalam. Dan ini juga cukup untuk 40 menit - Anda dapat berbicara untuk waktu yang lama tentang ketergantungan, dan tentang open source internal, dan tentang infrastruktur. Saya memberi gambaran umum. Jika ada topik yang sangat populer, saya bisa membahasnya di pertemuan atau konferensi berikutnya. Terima kasih