Apa alasan Docker tidak digunakan untuk basis data?

Saya sedang berdiskusi dengan seorang teman tentang kasus penggunaan untuk Docker . Satu orang di tim ingin menggunakan Docker untuk semuanya - seperti semacam pembungkus proses unix universal. Yang lain berpikir bahwa Docker hanya boleh digunakan untuk aplikasi stateless seperti Microservices dan aplikasi gaya AWS Lambda .

Kami telah merekayasa bukti konsep untuk keduanya. Pada kluster buruh pelabuhan kami, kami memiliki drive bersama yang akan dipasang ketika host Docker dipasang, dan jika Database dalam wadah dipasang, itu hanya memasang volume ke drive bersama.

Teman saya tetap berpegang teguh pada posisinya, meskipun ditunjukkan bukti yang bertentangan. (Dia juga berpendapat bahwa Docker menambah risiko yang tidak perlu dengan menambahkan kompleksitas ke tumpukan.)

Saya mencoba mendengarkan dan memahami sudut pandangnya, baik dalam tindakan empati, tetapi juga untuk alasan yang lebih baik dengannya. (Kita semua hidup dengan cukup baik - jadi ini adalah campuran dari diskusi serius dan serius).

Jenis pertanyaan di balik pertanyaan itu adalah: apakah basis data ternak ? Komentar ini menunjukkan bahwa cadangan otomatis dan strategi pengambilan yang baik untuk database Anda tidak dapat dibedakan dari server ternak.

Pertanyaan saya adalah: Apa alasan Docker tidak boleh digunakan untuk database?

EDIT: Orang-orang meminta saya untuk menjelaskan terminologi saya. Saya berasumsi bahwa aplikasi basis data ada di wadah, dan penyimpanannya ada di volume. Yang saya maksud adalah, RDBMS ada di dalam wadah, dan penyimpanan basis data ada di volume.

Beberapa komentator telah menyarankan bahwa driver volume buruh pelabuhan tidak akan bekerja dengan database menulis dengan sangat baik. (Atau sesuatu untuk efek itu). Bisakah Anda mengembangkannya?

Ketika orang berbicara tentang menjalankan database di Docker, mereka tidak bermaksud menyimpan data dalam wadah; mereka berbicara tentang memiliki gambar buruh pelabuhan dengan perangkat lunak DB, dan pemasangan data sebagai volume (volume mengikat, bukan volume wadah).

Volume adalah bagian penting dalam Docker, dan bukan sesuatu yang flakey atau hanya ditempelkan. Docker tidak hanya dibuat untuk layanan stateless (mikro).

Berharap seperti saya mungkin, saya tidak dapat menemukan alasan teknis untuk tidak menjalankan database di Docker, jadi sayangnya saya akan memilih sisi lain dari argumen dan karenanya mungkin tidak memberikan jawaban yang Anda cari.

(Saya menggunakan Oracle sebagai contoh karena saya mengenalnya, baik logam polos maupun berlabuh, dan karena ini adalah binatang buas yang terkenal karena sedikit tidak sepele untuk beroperasi jika Anda melewati pengaturan default.)

• Mengemas perangkat lunak DB itu sendiri dalam sebuah wadah memberi Anda manfaat biasa - memiliki versi yang sama di mana-mana, menghindari masalah ketergantungan / perpustakaan bersama, dapat memutar DB yang sama persis pada laptop pengembang atau di mana pun Anda membutuhkannya.
• Ini adalah sekejap mendapatkan itu untuk dijalankan di mana saja; memperbarui itu sepele, dan sebagainya. Semua manfaat Docker berlaku. Ada gambar Oracle di Dockerhub yang memungkinkan Anda untuk memutar DB yang berfungsi dalam satu atau tiga menit (dan untuk yang lain juga, tentu saja).
• Orang memang melakukan tes kinerja dan tidak menemukan perbedaan I / O antara volume dan bare metal ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / pertanyaan / 21889053 / apa-is-the-runtime-performance-cost-of-a-docker-container ).
• Di bawah tenda, tidak seperti Docker yang memotong semua I / O. Itu hanya menjadi kreatif dengan alat-alat Linux standar (mengikat gunung dalam kasus ini, mangling dari tabel kernel internal yang membuat Docker-fu mungkin sama sekali).
• Jelas itu tidak berarti bahwa Anda dapat menjalankan dua instance dari DB dan hanya membuatnya bekerja pada file yang sama, tetapi tidak ada yang menyiratkan itu. Docker tidak memberi Anda akses otomatis secara simultan dan ajaib ke volume, dan tidak pernah berpura-pura melakukannya. Sisa manfaatnya masih berlaku. Jika DB Anda sendiri tidak mendeteksi konflik seperti ini, Anda lebih baik menyediakan skrip CMD ke gambar yang menolak pemintalan wadah kedua saat volume sudah digunakan.
• Anda harus sedikit lebih hati-hati memutar / mematikan wadah (seperti halnya Anda tidak hanya mematikan server DB logam biasa), tetapi itu harus cukup mudah dikelola.

Sekarang, tergantung pada keadaan, mungkin ada alasan lembut untuk tidak melakukannya:

• Oracle (perusahaan), misalnya, tentu saja tidak akan mendukung Anda jika Anda menjalankan RDBMS mereka dalam wadah Docker. Tetapi mungkin Anda menggunakan gambar RDBMS Oracle yang sudah di-galerisasi hanya untuk pengembang Anda dan lingkungan pengujian, di mana Anda tidak akan memerlukan dukungan mereka dalam hal apa pun, memesannya untuk server produksi logam kosong. (Tapi jangan lupa untuk membayar lisensi Anda ...).
• Jika orang-orang ops tidak terbiasa dengan Docker, mungkin hanya sedikit lebih mudah untuk secara tidak sengaja membunuh semuanya, menghancurkan file data Anda dll.
• Jika Anda memiliki mesin DB dedicated logam besar sudah, dengan jumlah besar yang didedikasikan sangat cepat penyimpanan SAN, dan berjalan tidak ada yang lain lagian, maka hanya akan ada gunanya menggunakan Docker untuk dikemas dalam container yang karena Anda akan tidak pernah hanya berputar server lain ketika ada adalah 100 GB atau bahkan TB data. Bagaimanapun, untuk produksi, RDBMS seperti Oracle sangat, sangat maju dalam semua replikasi, integritas data, failover tanpa downtime, dll. Perhatikan bahwa argumen ini hanya mengatakan "Anda tidak perlu membuat wadah RDBMS Anda". Itu tidak mengatakan "Anda tidak boleh melakukannya" - mungkin Anda ingin melakukannya karena Anda ingin meluncurkan pemutakhiran perangkat lunak basis data melalui wadah atau untuk alasan apa pun yang dapat Anda bayangkan.

Jadi begitulah. Dengan segala cara lakukan dockerize DB Anda, setidaknya untuk pengembang Anda (yang akan berterima kasih selamanya) dan lingkungan pengujian Anda. Pada produksi, itu akan datang ke selera, dan ada setidaknya, saya juga lebih suka solusi yang duduk terbaik dengan khusus DBA / Ops - jika mereka memiliki puluhan tahun pengalaman bekerja logam telanjang server DB, maka dengan segala cara mempercayai mereka untuk melanjutkan. Tetapi jika Anda seorang pemula yang memiliki semua IT di cloud, maka wadah Docker hanya akan menjadi salah satu bagian dari bawang di seluruh gambar.

Saya menulis tentang ini secara mendalam tetapi inilah rangkumannya:

• Mencegah pemecahan otak (memilih lebih dari satu simpul utama) perlu diselesaikan. Kegagalan untuk melakukannya dapat menjadi bencana besar

• Tidak ada solusi penyimpanan bersama yang siap diproduksi untuk memungkinkan database dimatikan pada satu contoh dan ditampilkan pada yang lain tanpa kehilangan semua data Anda.

Ketika Anda mengatakan bahwa data dipasang ke wadah buruh pelabuhan, bukankah akan lebih benar untuk mengatakan bahwa "database" dipasang ke wadah buruh pelabuhan? Jika Anda mempertahankan data Anda di luar wadah maka Anda melakukan hal yang "benar" untuk tidak meletakkan basis data Anda di dalam wadah.

Tentu, pergi ke kota meletakkan DBMS dalam wadah membiarkannya mengelola data yang Anda simpan di luar, secara pribadi saya pikir itu desain yang bagus karena menjaga pemisahan yang bersih antara logika dan data. Tapi begitu Anda memasukkan data Anda ke dalam wadah mereka, Anda berpotensi bermain api.

Meskipun driver penyimpanan kontainer sudah jauh, saya pribadi belum mau menyelam dan meninggalkan data saya terjerat dalam wadah.