Di mana saya harus meletakkan konfigurasi aplikasi saya?

Saya baru-baru ini membaca sebuah debat tentang " Di mana seharusnya properti yang bergantung pada lingkungan disimpan? ".

Cara klasik adalah memiliki beberapa file properti, satu per lingkungan, dan berdasarkan pada variabel lingkungan (DEV, PROD ...), Anda memilih tempat untuk membacanya ketika memulai aplikasi (seperti dengan profil Spring).

Di sisi lain, jika Anda menggunakan wadah untuk menyebarkan aplikasi Anda, dikatakan bahwa konfigurasi semacam ini harus berasal dari lingkungan itu sendiri (menggunakan variabel lingkungan yang dibaca aplikasi), sehingga gambar tidak berubah di antara lingkungan.

Apa pro dan kontra dari setiap pendekatan? Apakah ada pendekatan "terbaik" untuk skenario wadah?

Siapa bilang properti file dan variabel lingkungan mana saling eksklusif?

Ada perbedaan yang harus dibuat antara "di mana saya menyimpan konfigurasi aplikasi saya?" Dan "di mana sumber aplikasi saya itu konfigurasi?"

Hasil yang paling mungkin adalah bahwa setiap orang mungkin harus terus melakukan apa yang mereka lakukan dengan file konfigurasi sebagai mekanisme penyimpanan (pikirkan jangka panjang, keadaan persisten selama lingkungan ada).

Namun, daripada menjatuhkan file konfigurasi itu ke dalam konteks aplikasi dan membiarkannya menjalankan aplikasi harus bisa hanya berharap variabel-variabel tersebut sudah tersedia di lingkungan ketika dijalankan.

Ini berarti Anda harus memiliki dua alur kerja penyebaran -

1. Saya menyebarkan aplikasi ke lingkungan dengan melalui proses kontrol perubahan X dan melakukan tinjauan Y dengan alat Z, apa pun.
2. Saya menyebarkan konfigurasi lingkungan saya ke lingkungan dengan melalui proses kontrol perubahan dan melakukan tinjauan B dengan alat C, proses yang sama, hasil yang berbeda.

Untuk menggunakan contoh mengelola variabel lingkungan sebagai pasangan Key Value dalam alat seperti konsul, jika Anda menyimpan file konfigurasi di git maka alat seperti git2consul dengan pegangan memasukkan konfigurasi itu ke lingkungan ketika diperbarui.

Jika Anda memiliki aplikasi yang mengharapkan bahwa akan ada konfigurasi yang tersedia sebagai file konfigurasi, maka Anda dapat menghindari pengiriman banyak salinan file konfigurasi dengan aplikasi tersebut dengan membangun proses penyebaran dengan sesuatu seperti konsul-templat yang memiliki kemampuan untuk mengubah Anda nilai konsul kembali ke file.

 Cara kami melakukannya adalah kami memiliki 3 buah (atau artefak) untuk setiap aplikasi yang berjalan.

1. Aplikasi yang kami kembangkan. Ini sama terlepas dari lingkungan. Untuk mencocokkan contoh Anda, itu akan menjadi aplikasi Musim Semi sebagai toples / perang.
2. Wadah yang akan menjalankan aplikasi. Ini sama terlepas dari lingkungan. Jika menggunakan Spring Boot, Anda tidak perlu Tomcat lagi dan hanya Java runtime. Jadi gunakan wadah Dockj openjdk.
3. Konfigurasi yang dibutuhkan aplikasi. Ini adalah satu-satunya hal yang berbeda di seluruh lingkungan. Di aplikasi Musim Semi, Anda kemungkinan akan menggunakan file properti.

File konfigurasi tinggal di kontrol sumber terpisah. Ini dulunya adalah Git, tetapi kami sekarang menggunakan SaaS yang kami buat bernama Config, di http://www.configapp.com . Fitur inti Config adalah penanganan mudah konfigurasi khusus lingkungan. Untuk menjalankan aplikasi kami di server baru, kami menarik wadah Docker, artefak aplikasi, dan file konfigurasi untuk lingkungan itu. Dalam wadah, kami memasang direktori tempat aplikasi dan file konfigurasi disimpan, sebagai bagian dari wadah dijalankan. Aplikasi kita sama. Wadah / gambar kami sama. Hanya file konfigurasi yang berbeda.

Mengenai variabel konfigurasi file vs lingkungan. Untuk waktu yang lama kami menggunakan file konfigurasi. Ketika kami menggunakan PaaS / cloud, kami menggunakan variabel lingkungan. Itu pekerjaan tambahan jika Anda memiliki banyak konfigurasi sehingga kami akhirnya menggunakan variabel lingkungan untuk menentukan file konfigurasi yang benar. Kami memiliki satu aplikasi yang mengubah properti menjadi variabel lingkungan, tetapi itu tidak biasa. Jika kami memiliki server konfigurasi terpusat yang disetujui perusahaan, kami menggunakannya, jika tidak, kami menyukai kesederhanaan file konfigurasi.

Jadi untuk meringkas, kita tarik app.jar, app.properties, openjdk Docker. Kemudian kita jalankan openjdk Docker yang memasang lokasi app.jar dan app.properties. Satu-satunya hal spesifik lingkungan adalah app.properties. Untuk mengelola app.properties dengan mudah, terlepas dari berapa banyak kunci properti, lingkungan, instance cluster / wilayah, kami menggunakan Config.