Kami membangunkan DevOps sebaik mungkin. Terdapat 8 daripada kami, dan Vasya adalah yang paling hebat dalam Windows. Tiba-tiba Vasya pergi, dan saya mempunyai tugas untuk melancarkan projek baru yang dibekalkan oleh pembangunan Windows. Apabila saya membuang keseluruhan timbunan pembangunan Windows di atas meja, saya menyedari bahawa keadaan itu menyakitkan...
Beginilah kisahnya bermula Alexandra Sinchinova pada . Apabila pakar Windows terkemuka meninggalkan syarikat itu, Alexander tertanya-tanya apa yang perlu dilakukan sekarang. Tukar ke Linux, sudah tentu! Alexander akan memberitahu anda bagaimana dia berjaya mencipta preseden dan memindahkan sebahagian pembangunan Windows ke Linux menggunakan contoh projek yang telah siap untuk 100 pengguna akhir.
Bagaimana untuk menghantar projek ke RPM dengan mudah dan mudah menggunakan teras TFS, Puppet, Linux .NET? Bagaimana untuk menyokong versi pangkalan data projek jika pasukan pembangunan mendengar perkataan Postgres dan Flyway buat kali pertama, dan tarikh akhir adalah lusa? Bagaimana untuk mengintegrasikan dengan Docker? Bagaimana untuk memotivasikan pembangun .NET untuk meninggalkan Windows dan smoothie demi Puppet dan Linux? Bagaimana untuk menyelesaikan konflik ideologi jika tiada kekuatan, mahupun keinginan, mahupun sumber untuk mengekalkan Windows dalam pengeluaran? Mengenai ini, serta mengenai Web Deploy, ujian, CI, tentang amalan menggunakan TFS dalam projek sedia ada, dan, sudah tentu, tentang tongkat patah dan penyelesaian yang berfungsi, dalam transkrip laporan Alexander.
Jadi, Vasya pergi, tugas itu ditanggung saya, pemaju menunggu dengan tidak sabar dengan garpu rumput. Apabila saya akhirnya menyedari bahawa Vasya tidak dapat dikembalikan, saya pergi ke perniagaan. Sebagai permulaan, saya menilai peratusan Win VM dalam armada kami. Skor itu tidak memihak kepada Windows.
Memandangkan kami sedang giat membangunkan DevOps, saya menyedari bahawa sesuatu perlu diubah dalam pendekatan untuk menyampaikan aplikasi baharu. Terdapat hanya satu penyelesaian - jika boleh, pindahkan semuanya ke Linux. Google membantu saya - pada masa itu .Net telah pun dialihkan ke Linux, dan saya menyedari bahawa ini adalah penyelesaiannya!
Mengapa teras .NET bersama-sama dengan Linux?
Terdapat beberapa sebab untuk ini. Antara "bayar wang" dan "tidak bayar", majoriti akan memilih yang kedua - seperti saya. Lesen untuk MSDB berharga kira-kira $1; menyelenggara kumpulan mesin maya Windows berharga ratusan dolar. Bagi syarikat besar ini adalah perbelanjaan yang besar. sebab tu simpanan - sebab pertama. Bukan yang paling penting, tetapi salah satu yang penting.
Mesin maya Windows menggunakan lebih banyak sumber daripada saudara Linux mereka - mereka berat. Memandangkan skala syarikat besar itu, kami memilih Linux.
Sistem ini hanya disepadukan ke dalam CI sedia ada. Kami menganggap diri kami DevOps progresif, kami menggunakan Bamboo, Jenkins dan GitLab CI, jadi kebanyakan kerja kami berjalan di Linux.
Sebab terakhir ialah iringan yang selesa. Kami perlu mengurangkan halangan kepada kemasukan untuk "pengiring"βlelaki yang memahami bahagian teknikal, memastikan perkhidmatan tanpa gangguan dan mengekalkan perkhidmatan dari barisan kedua. Mereka sudah biasa dengan tindanan Linux, jadi lebih mudah bagi mereka untuk memahami, menyokong dan mengekalkan produk baharu daripada menghabiskan sumber tambahan untuk memahami fungsi perisian yang sama untuk platform Windows.
Keperluan
Pertama sekali - kemudahan penyelesaian baharu untuk pemaju. Tidak semua daripada mereka bersedia untuk perubahan, terutamanya selepas perkataan Linux disebut. Pembangun mahukan Visual Studio kegemaran mereka, TFS dengan autotest untuk pemasangan dan smoothie. Bagaimana penghantaran kepada pengeluaran berlaku tidak penting bagi mereka. Oleh itu, kami memutuskan untuk tidak mengubah proses biasa dan membiarkan semuanya tidak berubah untuk pembangunan Windows.
Projek baru diperlukan diintegrasikan ke dalam CI sedia ada. Rel sudah ada dan semua kerja perlu dilakukan dengan mengambil kira parameter sistem pengurusan konfigurasi, piawaian penghantaran yang diterima dan sistem pemantauan.
Kemudahan sokongan dan operasi, sebagai syarat untuk ambang kemasukan minimum untuk semua peserta baharu daripada bahagian dan jabatan sokongan yang berbeza.
Tarikh akhir - semalam.
Kumpulan Pembangunan Menang
Apakah yang digunakan oleh pasukan Windows ketika itu?
Sekarang saya boleh dengan yakin mengatakannya IdentityServer4 ialah alternatif percuma yang hebat kepada ADFS dengan keupayaan yang serupa, atau apa Teras Rangka Kerja Entiti - syurga untuk pembangun, di mana anda tidak perlu bersusah payah menulis skrip SQL, tetapi menerangkan pertanyaan dalam pangkalan data dalam istilah OOP. Tetapi kemudian, semasa perbincangan pelan tindakan, saya melihat timbunan ini seolah-olah ia adalah cuneiform Sumeria, hanya mengenali PostgreSQL dan Git.
Pada masa itu kami sedang aktif menggunakan Boneka sebagai sistem pengurusan konfigurasi. Dalam kebanyakan projek kami, kami gunakan GitLab CI, elastik, perkhidmatan muatan tinggi seimbang menggunakan HAProxy memantau segala-galanya dengan Zabbix, ligamen grafana ΠΈ Prometheus, Jaeger, dan semua ini berputar di atas kepingan besi HP c ESXi pada VMware. Semua orang tahu ia - klasik genre.
Mari lihat dan cuba fahami apa yang berlaku sebelum kita memulakan semua campur tangan ini.
Apa yang berlaku
TFS ialah sistem yang agak berkuasa yang bukan sahaja menghantar kod daripada pembangun kepada mesin pengeluaran akhir, tetapi juga mempunyai set untuk penyepaduan yang sangat fleksibel dengan pelbagai perkhidmatan - untuk menyediakan CI pada peringkat merentas platform.
Sebelum ini, ini adalah tingkap pepejal. TFS menggunakan beberapa ejen Bina, yang digunakan untuk memasang banyak projek. Setiap ejen mempunyai 3-4 pekerja untuk menyelaraskan tugas dan mengoptimumkan proses. Kemudian, mengikut rancangan keluaran, TFS menghantar Build yang baru dibakar ke pelayan aplikasi Windows.
Apa yang kita mahu capai?
Kami menggunakan TFS untuk penghantaran dan pembangunan, dan menjalankan aplikasi pada pelayan Aplikasi Linux, dan terdapat beberapa jenis keajaiban di antara mereka. ini Kotak Magic dan ada garam kerja di hadapan. Sebelum saya membongkarnya, saya akan mengetepikan dan menyebut beberapa perkataan tentang permohonan itu.
Projek
Aplikasi ini menyediakan fungsi untuk mengendalikan kad prabayar.
Pelanggan
Terdapat dua jenis pengguna. Pertama mendapat akses dengan log masuk menggunakan sijil SSL SHA-2. U yang kedua terdapat akses menggunakan log masuk dan kata laluan.
HAProxy
Kemudian permintaan pelanggan pergi ke HAProxy, yang menyelesaikan masalah berikut:
- kebenaran utama;
- Penamatan SSL;
- menala permintaan HTTP;
- permintaan siaran.
Sijil pelanggan telah disahkan sepanjang rangkaian. kami - pihak berkuasa dan kami mampu membelinya, kerana kami sendiri mengeluarkan sijil kepada pelanggan perkhidmatan.
Perhatikan perkara ketiga, kami akan kembali kepadanya sedikit kemudian.
Backend
Mereka merancang untuk membuat bahagian belakang pada Linux. Bahagian belakang berinteraksi dengan pangkalan data, memuatkan senarai keistimewaan yang diperlukan dan kemudian, bergantung pada keistimewaan yang dimiliki pengguna yang diberi kuasa, menyediakan akses untuk menandatangani dokumen kewangan dan menghantarnya untuk pelaksanaan, atau menjana beberapa jenis laporan.
Penjimatan dengan HAProxy
Selain dua konteks yang dilayari oleh setiap pelanggan, terdapat juga konteks identiti. IdentityServer4 hanya membenarkan anda log masuk, ini adalah analog percuma dan berkuasa untuk ADFS - Perkhidmatan Persekutuan Direktori Aktif.
Permintaan identiti telah diproses dalam beberapa langkah. Langkah pertama - pelanggan masuk ke bahagian belakang, yang berkomunikasi dengan pelayan ini dan menyemak kehadiran token untuk pelanggan. Jika ia tidak ditemui, permintaan itu dikembalikan ke konteks asalnya, tetapi dengan ubah hala, dan dengan ubah hala ia pergi ke identiti.
Langkah kedua - permintaan telah diterima ke halaman kebenaran dalam IdentityServer, tempat pelanggan mendaftar, dan token yang ditunggu-tunggu itu muncul dalam pangkalan data IdentityServer.
Langkah ketiga - pelanggan telah diubah hala semula kepada konteks dari mana ia datang.
IdentityServer4 mempunyai ciri: ia mengembalikan respons kepada permintaan pemulangan melalui HTTP. Tidak kira betapa kami bergelut dengan menyediakan pelayan, tidak kira betapa kami menyedarkan diri kami dengan dokumentasi, setiap kali kami menerima permintaan pelanggan awal dengan URL yang datang melalui HTTPS, dan IdentityServer mengembalikan konteks yang sama, tetapi dengan HTTP. Kami terkejut! Dan kami memindahkan semua ini melalui konteks identiti kepada HAProxy, dan dalam pengepala kami perlu mengubah suai protokol HTTP kepada HTTPS.
Apakah penambahbaikan dan di manakah anda simpan?
Kami menjimatkan wang dengan menggunakan penyelesaian percuma untuk membenarkan sekumpulan pengguna, sumber, kerana kami tidak meletakkan IdentityServer4 sebagai nod berasingan dalam segmen berasingan, tetapi menggunakannya bersama-sama dengan bahagian belakang pada pelayan yang sama di mana bahagian belakang aplikasi dijalankan .
Bagaimana ia sepatutnya berfungsi
Jadi, seperti yang saya janjikan - Kotak Ajaib. Kami sudah faham bahawa kami dijamin untuk bergerak ke arah Linux. Mari kita rumuskan tugas khusus yang memerlukan penyelesaian.
Boneka menjelma. Untuk menyampaikan dan mengurus konfigurasi perkhidmatan dan aplikasi, resipi yang menarik perlu ditulis. Gulungan pensel dengan fasih menunjukkan betapa cepat dan cekap ia dilakukan.
Kaedah penyampaian. Standardnya ialah RPM. Semua orang memahami bahawa di Linux anda tidak boleh melakukannya tanpanya, tetapi projek itu sendiri, selepas pemasangan, adalah satu set fail DLL boleh laku. Terdapat kira-kira 150 daripadanya, projek itu agak sukar. Satu-satunya penyelesaian yang harmoni ialah membungkus binari ini ke dalam RPM dan menggunakan aplikasi daripadanya.
Versi. Kami terpaksa mengeluarkannya dengan kerap, dan kami terpaksa memutuskan cara untuk membentuk nama pakej. Ini adalah persoalan tahap integrasi dengan TFS. Kami mempunyai ejen binaan di Linux. Apabila TFS menghantar tugasan kepada pengendali - pekerja - kepada ejen Bina, ia juga menghantar sekumpulan pembolehubah yang berakhir dalam persekitaran proses pengendali. Pembolehubah persekitaran ini mengandungi nama Binaan, nama versi dan pembolehubah lain. Baca lebih lanjut mengenai perkara ini dalam bahagian "Membina pakej RPM".
Menyediakan TFS turun untuk menyediakan Saluran Paip. Sebelum ini, kami mengumpul semua projek Windows pada ejen Windows, tetapi kini ejen Linux muncul - ejen Binaan, yang perlu disertakan dalam kumpulan binaan, diperkaya dengan beberapa artifak dan memberitahu jenis projek yang akan dibina pada ejen Binaan ini , dan entah bagaimana mengubah suai Saluran Paip.
IdentityServer. ADFS bukan cara kami, kami menggunakan Sumber Terbuka.
Mari kita lihat komponen.
Kotak Magic
Terdiri daripada empat bahagian.
Ejen Binaan Linux. Linux, kerana kami membina untuknya - ia logik. Bahagian ini dilakukan dalam tiga langkah.
- Konfigurasikan pekerja dan tidak bersendirian, kerana kerja yang diedarkan pada projek itu dijangka.
- Pasang .NET Core 1.x. Mengapa 1.x apabila 2.0 sudah tersedia dalam repositori standard? Kerana apabila kami memulakan pembangunan, versi stabil ialah 1.09, dan diputuskan untuk membuat projek berdasarkannya.
- Git 2.x.
RPM-repositori. Pakej RPM perlu disimpan di suatu tempat. Diandaikan bahawa kami akan menggunakan repositori RPM korporat yang sama yang tersedia untuk semua hos Linux. Itulah yang mereka lakukan. Pelayan repositori dikonfigurasikan cangkuk web yang memuat turun pakej RPM yang diperlukan dari lokasi yang ditentukan. Versi pakej telah dilaporkan kepada webhook oleh ejen Bina.
GitLab. Perhatian! GitLab di sini bukan digunakan oleh pembangun, tetapi oleh jabatan operasi untuk mengawal versi aplikasi, versi pakej, memantau status semua mesin Linux, dan ia menyimpan resipi - semua manifes Boneka.
Boneka β menyelesaikan semua isu kontroversi dan menyampaikan konfigurasi yang kami inginkan daripada Gitlab.
Kami mula menyelam. Bagaimanakah penghantaran DLL ke RPM berfungsi?
Penghantaran DDL ke RPM
Katakan kita mempunyai bintang rock pembangunan .NET. Ia menggunakan Visual Studio dan mencipta cawangan keluaran. Selepas itu, ia memuat naiknya ke Git, dan Git di sini ialah entiti TFS, iaitu, ia adalah repositori aplikasi yang digunakan oleh pembangun.
Selepas itu TFS melihat bahawa komitmen baharu telah tiba. Apl yang mana? Dalam tetapan TFS terdapat label yang menunjukkan sumber yang dimiliki oleh ejen Binaan tertentu. Dalam kes ini, dia melihat bahawa kami sedang membina projek Teras .NET dan memilih ejen Binaan Linux daripada kumpulan.
Ejen Build menerima sumber dan memuat turun yang diperlukan kebergantungan daripada repositori .NET, npm, dsb. dan selepas membina aplikasi itu sendiri dan pembungkusan seterusnya, menghantar pakej RPM ke repositori RPM.
Sebaliknya, perkara berikut berlaku. Jurutera jabatan operasi terlibat secara langsung dalam pelancaran projek: dia menukar versi pakej dalam Hiera dalam repositori di mana resipi aplikasi disimpan, selepas itu Puppet mencetuskan Yum, mengambil pakej baharu daripada repositori dan versi baharu aplikasi sedia untuk digunakan.
Segala-galanya mudah dalam perkataan, tetapi apa yang berlaku di dalam ejen Bina itu sendiri?
Pembungkusan DLL RPM
Menerima sumber projek dan membina tugas daripada TFS. Ejen binaan mula membina projek itu sendiri daripada sumber. Projek yang dipasang boleh didapati sebagai satu set fail DLL, yang dibungkus dalam arkib zip untuk mengurangkan beban pada sistem fail.
Arkib ZIP dibuang ke direktori binaan pakej RPM. Seterusnya, skrip Bash memulakan pembolehubah persekitaran, mencari versi Binaan, versi projek, laluan ke direktori binaan dan menjalankan RPM-build. Setelah binaan selesai, pakej diterbitkan ke repositori tempatan, yang terletak pada ejen Bina.
Seterusnya, daripada ejen Bina ke pelayan dalam repositori RPM Permintaan JSON dihantar menunjukkan nama versi dan binaan. Webhook, yang saya bincangkan sebelum ini, memuat turun pakej ini dari repositori tempatan pada ejen Bina dan menjadikan pemasangan baharu tersedia untuk pemasangan.
Mengapa skim penghantaran pakej khusus ini ke repositori RPM? Mengapa saya tidak boleh segera menghantar pakej yang dipasang ke repositori? Hakikatnya ini adalah syarat untuk memastikan keselamatan. Senario ini mengehadkan kemungkinan orang yang tidak dibenarkan memuat naik pakej RPM ke pelayan yang boleh diakses oleh semua mesin Linux.
Versi pangkalan data
Pada perundingan dengan pasukan pembangunan, ternyata mereka lebih dekat dengan MS SQL, tetapi dalam kebanyakan projek bukan Windows, kami sudah menggunakan PostgreSQL dengan sekuat tenaga. Oleh kerana kami telah memutuskan untuk meninggalkan semua yang dibayar, kami mula menggunakan PostgreSQL di sini juga.
Dalam bahagian ini saya ingin memberitahu anda cara kami membuat versi pangkalan data dan cara kami memilih antara Flyway dan Teras Rangka Kerja Entiti. Mari kita lihat kebaikan dan keburukan mereka.
Kekurangan
Flyway hanya pergi sehala, kami kita tidak boleh berpatah balik - ini adalah kelemahan yang ketara. Anda boleh membandingkannya dengan Teras Rangka Kerja Entiti dalam cara lain - dari segi kemudahan pembangun. Anda ingat bahawa kami meletakkan ini di barisan hadapan, dan kriteria utama adalah untuk tidak mengubah apa-apa untuk pembangunan Windows.
Untuk Flyway kami beberapa jenis pembalut diperlukansupaya lelaki itu tidak menulis pertanyaan SQL. Mereka lebih hampir untuk beroperasi dalam istilah OOP. Kami menulis arahan untuk bekerja dengan objek pangkalan data, menghasilkan pertanyaan SQL dan melaksanakannya. Versi baharu pangkalan data sudah sedia, diuji - semuanya baik-baik saja, semuanya berfungsi.
Teras Rangka Kerja Entiti mempunyai tolak - di bawah bebanan yang berat membina pertanyaan SQL suboptimum, dan pengeluaran dalam pangkalan data boleh menjadi ketara. Tetapi oleh kerana kami tidak mempunyai perkhidmatan muatan tinggi, kami tidak mengira beban dalam ratusan RPS, kami menerima risiko ini dan menyerahkan masalah itu kepada kami pada masa hadapan.
Kelebihan
Teras Rangka Kerja Entiti berfungsi di luar kotak dan mudah dibangunkan, dan Flyway Mudah disepadukan ke dalam CI sedia ada. Tetapi kami memudahkan pemaju :)
Prosedur roll-up
Boneka melihat bahawa perubahan dalam versi pakej akan datang, termasuk versi yang bertanggungjawab untuk penghijrahan. Pertama, ia memasang pakej yang mengandungi skrip migrasi dan fungsi berkaitan pangkalan data. Selepas ini, aplikasi yang berfungsi dengan pangkalan data dimulakan semula. Seterusnya datang pemasangan komponen yang tinggal. Susunan pakej dipasang dan aplikasi dilancarkan diterangkan dalam manifes Boneka.
Aplikasi menggunakan data sensitif, seperti token, kata laluan pangkalan data, semua ini ditarik ke dalam konfigurasi daripada Puppet master, di mana ia disimpan dalam bentuk yang disulitkan.
masalah TFS
Selepas kami membuat keputusan dan menyedari bahawa segala-galanya benar-benar berkesan untuk kami, saya memutuskan untuk melihat apa yang sedang berlaku dengan perhimpunan di TFS secara keseluruhan untuk jabatan pembangunan Win pada projek lain - sama ada kami sedang membina/melepaskan dengan cepat atau tidak, dan menemui masalah ketara dengan kelajuan.
Salah satu projek utama mengambil masa 12-15 minit untuk dipasang - itu adalah masa yang lama, anda tidak boleh hidup seperti itu. Analisis pantas menunjukkan pengurangan yang teruk dalam I/O, dan ini adalah pada tatasusunan.
Selepas menganalisis komponen demi komponen, saya mengenal pasti tiga fokus. pertama - "Antivirus Kaspersky", yang mengimbas sumber pada semua ejen Windows Build. Kedua - Windows Pengindeks. Ia tidak dilumpuhkan dan semuanya telah diindeks dalam masa nyata pada ejen Bina semasa proses penempatan.
ketiga - Pasang Npm. Ternyata dalam kebanyakan Talian Paip kami menggunakan senario tepat ini. Kenapa dia teruk? Prosedur pemasangan Npm dijalankan apabila pepohon kebergantungan terbentuk dalam package-lock.json, di mana versi pakej yang akan digunakan untuk membina projek direkodkan. Kelemahannya ialah pemasangan Npm mengeluarkan versi terkini pakej daripada Internet setiap kali, dan ini memerlukan banyak masa dalam kes projek besar.
Pembangun kadangkala bereksperimen pada mesin tempatan untuk menguji cara bahagian tertentu atau keseluruhan projek berfungsi. Kadang-kadang ternyata semuanya sejuk secara tempatan, tetapi mereka memasangnya, melancarkannya, dan tiada apa yang berhasil. Kami mula memikirkan apa masalahnya - ya, versi pakej yang berbeza dengan kebergantungan.
keputusan
- Sumber dalam pengecualian AV.
- Lumpuhkan pengindeksan.
- Pergi ke npm ci.
Kelebihan npm ci ialah kita Kami mengumpul pokok pergantungan sekali, dan kami mendapat peluang untuk menyediakan pembangun senarai pakej semasa, yang mana dia boleh bereksperimen secara tempatan seberapa banyak yang dia suka. ini menjimatkan masa pembangun yang menulis kod.
Konfigurasi
Sekarang sedikit tentang konfigurasi repositori. Dari segi sejarah kita gunakan Nexus untuk menguruskan repositori, termasuk REPO dalaman. Repositori dalaman ini mengandungi semua komponen yang kami gunakan untuk tujuan dalaman, contohnya, pemantauan bertulis sendiri.
Kami juga menggunakan NuGet, kerana ia mempunyai caching yang lebih baik berbanding dengan pengurus pakej lain.
Keputusan
Selepas kami mengoptimumkan Ejen Binaan, purata masa binaan telah dikurangkan daripada 12 minit kepada 7.
Jika kami mengira semua mesin yang boleh kami gunakan untuk Windows, tetapi bertukar kepada Linux dalam projek ini, kami menjimatkan kira-kira $10. Itu hanya pada lesen, dan banyak lagi jika kami mengambil kira kandungannya.
Rancangan
Untuk suku seterusnya, kami merancang untuk mengoptimumkan penghantaran kod.
Beralih kepada imej Docker prabina. TFS ialah perkara yang menarik dengan banyak pemalam yang membolehkan anda menyepadukan ke dalam Pipeline, termasuk pemasangan berasaskan pencetus, katakan, imej Docker. Kami mahu membuat pencetus ini untuk yang sama package-lock.json. Jika komposisi komponen yang digunakan untuk membina projek entah bagaimana berubah, kami membina imej Docker baharu. Ia kemudiannya digunakan untuk menggunakan bekas dengan aplikasi yang dipasang. Ini tidak berlaku sekarang, tetapi kami merancang untuk beralih kepada seni bina perkhidmatan mikro di Kubernetes, yang sedang giat membangun dalam syarikat kami dan telah menyediakan penyelesaian pengeluaran untuk masa yang lama.
Ringkasan
Saya menggalakkan semua orang membuang Windows, tetapi ini bukan kerana saya tidak tahu cara memasaknya. Sebabnya ialah kebanyakan penyelesaian Opensource adalah Timbunan Linux. adakah awak okey menjimatkan sumber. Pada pendapat saya, masa depan adalah milik penyelesaian Sumber Terbuka di Linux dengan komuniti yang berkuasa.
Profil penceramah Alexander Sinchinov .
ialah persidangan mengenai penyepaduan proses pembangunan, ujian dan operasi untuk profesional oleh profesional. Itulah sebabnya projek yang dibincangkan oleh Alexander? dilaksanakan dan berfungsi, dan pada hari persembahan terdapat dua keluaran yang berjaya. hidup Pada 27 dan 28 Mei akan ada lebih banyak kes serupa daripada pengamal. Anda masih boleh melompat ke gerabak terakhir dan atau ambil masa anda tiket. Temui kami di Skolkovo!
Sumber: www.habr.com