Kami menciptakan alat yang mengintegrasikan Docker dan Maven untuk membantu ratusan pengembang kami mengelola lingkungan pengembangan yang kompleks dengan ratusan layanan, dengan upaya minimal. Ini adalah kisah tentang bagaimana ide gila menjadi kenyataan. Ini adalah kisah
Carnotzet .
Semuanya dimulai sekitar lima tahun yang lalu (sekitar tanggal publikasi 3 Agustus 2017), Swissquote dengan cepat tumbuh dan berkembang. Pada saat itu, kami memiliki sekitar 70 pengembang yang mengerjakan proyek-proyek besar (sekitar Monolitik) Java, yang mengharuskan masing-masing dari mereka menghabiskan 1 hingga 2 hari untuk mengonfigurasi peluncuran proyek secara lokal. Kami benci membuang waktu untuk tugas yang berulang-ulang! Jadi, diputuskan untuk meningkatkan proses ini dengan menggunakan Vagrant dan Chef untuk mengotomatiskan penyebaran lingkungan pengembangan lokal kami. Ini menandai awal dari proyek Kotak Pasir pertama kami (Kotak Pasir, kira-kira)
Kami ingin berbagi lingkungan pengujian dan pengembangan yang ringan, dapat direproduksi, diisolasi, dan portabel.
Untuk sementara, semuanya lancar. Pengembang cukup mengunduh proyek, menjalankan "gelandangan" dan mulai bekerja. Kami menggunakan pendekatan ini selama sekitar dua tahun dan cukup senang.
Selanjutnya, mengerjakan aplikasi besar ini menjadi lebih sulit karena fakta bahwa logika bisnis menjadi lebih kompleks (label putih dari platform perdagangan kami). Dan kami memutuskan untuk melakukan apa yang dilakukan sebagian besar organisasi pada tahun 2014: memecah logika menjadi layanan mikro.
Semuanya berjalan dengan baik, dan pada tahun 2016 kami memiliki sekitar 150 (mikro, perkiraan) Layanan dalam produksi. Tetapi skrip Chef yang digunakan untuk mengkonfigurasi mesin virtual telah berkembang dan tidak terkendali. Lingkungan pengembangan menjadi jauh lebih rumit untuk beberapa aplikasi dengan sekitar 30 dependensi. Kami juga menemukan bahwa pengetahuan Chef bukan bagian dari serangkaian standar keterampilan pengembang kami. Karena alasan ini, banyak orang membuat skrip bekerja, kadang-kadang, dengan menyalin contoh-contoh buruk. Mencoba untuk tidak merusak konfigurasi untuk tim lain, mereka menciptakan brunch yang tahan lama untuk kebutuhan tim mereka sendiri, dan, sebagai hasilnya, kode konfigurasi lingkungan pengembangan tidak lagi publik.
Kami harus memperbaikinya.
Kelemahan kotak pasir kami berikut ini telah diidentifikasi:
- Perlu kenal Chef. Dan untuk pengembang yang ada, dan untuk pemula, mempelajari kerangka kerja ini merupakan kesenangan yang cukup mahal.
Juga, ini berlebihan hanya untuk lingkungan pengembangan / pengujian. - Tidak ada cara untuk abstraksi / komposisi yang mudah atau penggunaan kembali bagian dari konfigurasi lingkungan. Ini mengarah pada fakta bahwa orang harus mempelajari semua detail dan nuansa konfigurasi ketergantungan proyek mereka, yang biasanya didukung oleh tim lain. Hal ini menyebabkan ketidaksepakatan dan interaksi yang tidak perlu antara tim.
Untuk memperbaiki titik pertama, diputuskan untuk beralih menggunakan Docker. Ini memiliki ambang masuk yang lebih rendah dan juga memberikan manfaat lain, seperti standardisasi, dukungan PaaS, dan penyebaran yang lebih mudah di berbagai lingkungan.
Kami juga mempertimbangkan untuk hanya menggunakan docker-compose. Itu tampak sangat menjanjikan, tetapi terlepas dari namanya, ia tidak memiliki hal-hal seperti kemungkinan komposisi, dan, pada saat yang sama, abstraksi dan penggunaan kembali. Aspek itulah yang kami butuhkan. Kami bermimpi dapat mengambil lingkungan pengembangan / pengujian yang ada, menambahkan satu layanan ke sana, dan secara opsional mendefinisikan ulang bagian dari konfigurasinya. Kami ingin mencapai ini tanpa harus menyalin konfigurasi layanan yang ditambahkan atau untuk menggali rincian dependensi transitif dan konfigurasinya.
Saat itulah kami memiliki ide ini: "Bagaimana jika kita mengambil Maven, sistem manajemen ketergantungan yang kita gunakan untuk membangun aplikasi java kita, dan mulai menggunakannya untuk membangun lingkungan kita?". Ini akan memungkinkan kami untuk mengabstraksi dependensi transitif kami, konfigurasi paket, membuat versi mereka, dan menggunakannya kembali. Juga tidak perlu mempelajari sistem manajemen ketergantungan baru.
Setelah beberapa upaya, kami sampai pada solusi berikut:
- Setiap artefak Maven mewakili lingkungan yang berfungsi penuh yang dapat digunakan sebagai ketergantungan pada lingkungan lain. (lingkungan minimal dapat diwakili oleh satu layanan, misalnya, database)
- File JAR berisi konfigurasi. Variabel lingkungan, file konfigurasi aplikasi, nama Docker gambar, dll.
- Konfigurasi ini dapat ditimpa dalam modul yang terletak lebih tinggi di hirarki dependensi, jika perlu.
- Pustaka Java dapat mengangkat lingkungan lengkap (menggunakan docker-compose di bawah tenda) dari satu modul Maven (GAV atau pom.xml)
Maven memungkinkan untuk mendistribusikan dan membuat versi artefak ini ("artefak lingkungan") dan kami dapat dengan mudah berbagi kode sumber antara tim. Prosesnya menjadi lebih sederhana dan pengembang mulai menggunakan modul dari tim lain. Dan juga membuat dan memelihara milik Anda sendiri.
Sebagai bonus, semua alat yang memfasilitasi pekerjaan dengan Maven dapat digunakan di sini. Sebagai contoh, grafik dependensi yang dihasilkan menggunakan IntelliJ IDEA sekarang menunjukkan kepada kita diagram arsitektur untuk interaksi dependensi kami :)
Arsitektur contoh
aplikasi pemungutan suara dari komposisi buruh pelabuhanPada saat yang sama, ada beberapa kesulitan implementasi, seperti memaksa semua tim untuk mengemas aplikasi menggunakan Docker (dockerize) dan mengemas konfigurasi ke dalam modul Maven terpisah. Dari semua akun, mengimpor aplikasi dari tim lain menjadi lebih mudah dan mendukung lingkungan pengembangan yang kompleks.
Kami mulai bekerja ke arah ini sekitar setahun yang lalu, dan sekarang kami memiliki sekitar 200 modul yang digunakan untuk pengembangan dan pengujian. Kami sampai pada kesimpulan bahwa perpustakaan ini juga bagus untuk mengelola lingkungan sementara untuk pengujian end-to-end pada platform CI kami.
Kami saat ini sedang mempelajari cara menggunakan kembali teknologi ini untuk mengelola lingkungan UAT / integrasi kami dengan meluncurkan kontainer di Kubernetes alih-alih menyusun dok, dan dengan demikian memastikan pemutakhiran bergulir dan menghitung elastisitas pada lingkungan yang jauh lebih besar.
Saya harap Anda akan senang mengetahui bahwa proyek kami dibuka di bawah lisensi Apache 2.0 dan tersedia di Github:
github.com/swissquote/carnotzetGunakan :)