Manfaat mengadopsi pengembangan berorientasi kontainer docker dan penerapan alur kerja tidak sepenuhnya terwujud jika adopsi hanya dipertahankan dalam batasan lingkungan pengembangan dan pengujian. Keengganan untuk menjalankan kontainer docker dalam produksi berasal dari kekhawatiran seputar keamanan dan isolasi, dan kurangnya keahlian operasional dalam mengelola kontainer di lingkungan produksi.

Menjalankan Kontainer Docker di Lingkungan Produksi

Dalam organisasi yang pada tahap mengadopsi kontainer, keputusan untuk memindahkan mereka ke lingkungan produksi merupakan pertimbangan utama. Lebih mudah untuk mengambil risiko saat mengadopsi kontainer untuk layanan atau aplikasi yang sama sekali baru, yang ideal untuk kontainer asli.

Apa artinya kontainer asli?

Aplikasi asli kontainer adalah aplikasi yang dirancang dan dibangun di sekitar siklus hidup kontainer dan menganggap kontainer sebagai warga kelas satu keberadaannya.

Untuk aplikasi yang telah dipasang untuk bekerja dengan kontainer, keputusan untuk beralih ke produksi biasanya lebih sulit. Ini mengacu pada aplikasi lawas, yang rentan terhadap refactoring ekstensif untuk mengadopsi pengembangan dan penyebaran kontainer.

Memahami dampak pada alur kerja dan proses kerja yang ada di lingkungan produksi organisasi adalah aspek penting dari operasi kontainer dalam produksi.

Proses dan Alur Kerja

Berikut adalah beberapa alur kerja dan proses seputar produksi yang mungkin terkena dampak kontainer:

  • Memindahkan perubahan atau fitur yang ditetapkan dari pengembangan ke produksi.
  • Mengizinkan pengguna akhir mengakses kumpulan perubahan atau fitur yang digunakan dalam produksi.
  • Debugging masalah yang dilaporkan dalam produksi.
  • Memonitor aplikasi dalam produksi.
  • Memperbarui versi aplikasi dalam produksi.
  • Mengambil cadangan data yang dihasilkan.
  • Pemulihan bencana dan kelangsungan usaha.
  • Perencanaan kapasitas untuk produksi.
  • Menyiapkan mesin host, terutama untuk konfigurasi jaringan dan keamanan.
  • Perencanaan Kapasitas

Mengoperasikan lingkungan produksi tanpa kontainer merupakan hal umum di sebagian besar organisasi di tengah adopsi kontainer. Dalam organisasi semacam itu, mesin virtual dapat diutamakan sebagai unit penyebaran, yang melayani kebutuhan untuk isolasi dan pengelolaan komponen aplikasi.

Kemungkinan besar, komponen individual ini didistribusikan di sekumpulan VM yang berjalan di beberapa host dalam konfigurasi berlebihan (redundant), yang memungkinkan ketersediaan tinggi. Jika lingkungan produksi dibagi dengan aplikasi lain, maka VM menjadi alat penting untuk isolasi ini.

Tim operasi mengendalikan manajemen VM dan siklus hidup. Kode aplikasi biasanya disalin ke VM melalui beberapa bentuk otomatisasi dan alur kerja. VM jarang dihancurkan untuk penyebaran baru dan digunakan kembali, karena revisi kode terus masuk untuk penerapan baru. Kadang-kadang, VM ini juga mengalami perubahan, idealnya dengan merekonstruksi VM itu sendiri dengan menggunakan versi baru.

Solusi untuk Lingkungan Hibrida

Sebagai alternatif, beberapa organisasi mempraktekkan pemasangan ulang perangkat VM baru dengan membuang yang lama saat melepaskan perubahan pada aplikasi atau infrastruktur dalam produksi.

Netflix’s Aminator, dan praktik di sekitarnya, menjadi trendsetter tentang bagaimana pengelolaan lingkungan produksi berbasis VM yang masih dapat menggunakan prinsip-prinsip kekekalan dan kemampuan sekali pakai.

Pendukung kontainer semakin memungkinkan untuk menjalankan beban kerja kontainer pada lingkungan colocation server. Hal ini membantu menghindari kinerja dan konteks beralihnya hukuman yang timbul dari penggunaan hypervisor di antara on-premise dan sistem operasi. Argumen ini lebih terasa jika kita menjalankan sistem penyewa tunggal yang tidak akan berbagi sumber daya.

elitery devops managed services

Organisasi pada tahap awal adopsi kontainer docker dapat mencoba menggunakan strategi hibrida untuk mengatasi situasi ini. Caranya, dengan memiliki kombinasi aplikasi kontainer docker yang berjalan pada mesin seperti VM dan beberapa di server fisik. Kombinasi ini dapat disesuaikan dengan menganalisis metrik manajemen dan kinerja dari waktu ke waktu. Ketika tingkat jatuh tempo tertentu dicapai dengan operasi kontainer, beberapa pengadopsi memilih hanya menggunakan server fisik untuk menjalankan kontainernya.

Saat menjalankan beberapa aplikasi pada infrastruktur produksi bersama, keputusan untuk menjalankan kontainer pada server fisik harus didasarkan pada pengalaman sebelumnya. Pilihan yang lebih aman adalah dengan membungkus VM, dan membiarkan kontainer menjadi penyebaran runtime layanan Anda di dalam VM pada lingkungan multi-tenant. Setiap VM dapat menampung kontainer yang termasuk penyewa yang sama, memberikan isolasi terhadap penyewa lainnya.

cara menjalankan kontainer docker

transisi infrastruktur yang belum matang ke infrastruktur yang sudah matang

Gambar 1: Pada infrastruktur dengan kematangan yang renda, penyewa tidak berbagi infrastruktur produksi. Isolasi ini bisa berupa VM atau host fisik. Pada infrastruktur yang memiliki kematangan lebih tinggi, komponen dari setiap aplikasi penyewa tersebar di seluruh infrastruktur bersama. Saat mempertimbangkan kontainer, infrastruktur dengan kematangan tinggi mewakili VM bersama atau infrastruktur on-premise, di mana komponen dari setiap aplikasi penyewa tersebar.

Melepaskan Aplikasi dalam Produksi

Sifat kontainer sementara memungkinkan pembaruan dengan meluncurkan perubahan kode pada setiap kontainer baru, daripada mengupdate instance yang ada. Bila perubahan tertentu ditandai untuk diproduksi, satu set kontainer baru dibuat menggunakan versi baru dari image kontainer, yang diidentifikasi oleh tag baru. Tag baru idealnya dihasilkan selama proses integrasi berkesinambungan (CI). Image dan tag yang dihasilkan disimpan dalam registri image kontainer, yang dapat diakses ke lingkungan produksi.

Meskipun memungkinkan untuk berbagi registri penampung di antara semua lingkungan – termasuk pengembangan, pengujian dan produksi – dalam beberapa kasus, registri image kontainer terpisah digunakan secara eksklusif untuk lingkungan produksi.

Registri penampung image eksklusif ini untuk produksi tidak dibagi dengan lingkungan lain. Dalam kasus ini, perlu ada proses promosi untuk mengambil “kandidat” image kontainer docker dari registri yang ditandai untuk pengembangan dan tes ke registri yang ditandai untuk produksi.

Sistem perantara dapat digunakan untuk menarik image kandidat dari registri dev / test, dan memberi tag ulang dan mendorong image calon kontainer ke registri yang ditandai untuk produksi. Dengan menggunakan metode ini, ada isolasi yang jelas dari image yang tersimpan dan tersedia dalam daftar image antara lingkungan non-produksi (dev dan test) dan produksi.

Aspek sementara kontainer menerapkan kendala pada praktik yang sudah ada sebelumnya yang menggunakan bindings port statis dan alamat IP host tempat aplikasi diterapkan. Ini membantu dengan konfigurasi firewall dan switch jaringan.

Praktik terbaik untuk melepaskan perubahan produksi adalah dengan menerapkan upgrade rolling. Ini memerlukan infrastruktur tambahan di lingkungan produksi untuk memodifikasi load balance dan konfigurasi proxy yang ada, sementara seperangkat kontainer baru diluncurkan di samping versi yang ada.

Untuk mempertahankan beberapa tingkat ketahanan saat memasang kontainer docker, akan lebih bijak untuk memanfaatkan penawaran dari runtime dan platform di sekitar alat orkestrasi. Jika Anda hanya menggunakan runtime kontainer tanpa alat orkestrasi, mengambil keuntungan dari konfigurasi runtime seperti kebijakan “-restart” sangat penting.

Kebijakan restart yang disarankan adalah beralih antara konfigurasi “on-failure” dan “unless-stopped” atau pilih yang masuk akal untuk lingkungan Anda.

Menyiapkan Lingkungan Host untuk Kontainer dalam Produksi

Salah satu aspek penting dalam mempersiapkan infrastruktur produksi Anda untuk menjalankan kontainer docker adalah dengan mengenali sifat kontainer yang “disegel”. Image kontainer menuntut infrastruktur standar yang tetap serupa dalam konfigurasi di lingkungan pengembangan, pengujian dan produksi. Standarisasi ini sangat penting untuk mendapatkan pengalaman yang dapat diprediksi saat menjalankan kontainer docker dalam produksi.

Berikut adalah beberapa faktor yang perlu dipertimbangkan:
  • Pilihan kernel.
  • Versi dan pilihan runtime kontainer.
  • Akses jaringan dan konfigurasi firewall.
  • Pilihan solusi pengerasan keamanan.
  • Izin akses sistem

Mungkin tergoda untuk beralih dari standardisasi semua faktor ini di seluruh lingkungan; Namun, penyimpangan apapun dapat menyebabkan hasil yang tidak dapat diprediksi yang mungkin memerlukan penyelidikan. Cara termudah untuk mengatasi hal ini adalah dengan memastikan bahwa setiap lingkungan, mulai dari pengembangan hingga uji coba produksi, dibangun dengan topologi yang sama.

Mungkin sulit untuk dicapai di awal, tapi ini adalah tujuan pengadopsian kontainer docker. Semua lingkungan menggunakan kernel Linux yang sama; mereka menggunakan konfigurasi host yang sama, topologi sistem file, konfigurasi jaringan dan peran pengguna. Standardisasi semua faktor membantu memastikan bahwa image kontainer docker yang dibangun dan diuji dalam integrasi tetap sama sampai produksi.

Beberapa aspek perilaku runtime dari contoh kontainer akan berbeda, seperti URL untuk mengakses layanan dependen lainnya, atau tingkat log. Konfigurasi runtime ini diteruskan ke kontainer menggunakan berbagai pilihan.

Salah satu opsi tersebut adalah menyuntikkan konfigurasi runtime melalui variabel lingkungan ke instance kontainer. Variabel lingkungan bisa menunjuk ke registry layanan, yang kemudian menunjuk ke layanan ketergantungan yang tepat. Alat seperti ZooKeeper and Consul sangat membantu dalam menerapkan paradigma ini.

Jika host sedang disiapkan dengan menggunakan alat manajemen dan penyediaan konfigurasi yang ada, seperti Chef, Puppets dan Animate, maka akan tepat jika memiliki konfigurasi tunggal untuk semua lingkungan, semaksimal mungkin.

Untuk infrastruktur skala besar, perbedaan yang terbatas di seluruh lingkungan adalah jumlah kasus yang harus ditetapkan, mengingat persyaratan ketersediaan dan kinerja.

Host juga harus sesekali diperbarui dengan patch kernel terbaru, versi runtime kontainer, dan lainnya yang tidak dapat disegel di dalam image kontainer. Perubahan konfigurasi host ini bisa mengikuti upgrade bergulir, yang memungkinkan pembaruan secara bertahap, alih-alih menggunakan pendekatan big bang.

Akhirnya, seperti host, perlu ada konfigurasi dan topologi yang serupa untuk mendukung infrastruktur, seperti agregasi log, pemantauan, metrik, perutean layanan dan penemuan untuk semua lingkungan. Hal ini memungkinkan tingkat konsistensi untuk image kontainer, tidak hanya dengan host, namun dengan semua layanan yang berpartisipasi di lingkungan masing-masing.

Penemuan Layanan Kontainer dalam Produksi

Standardisasi mekanisme penemuan layanan merupakan pertimbangan penting untuk aplikasi kontainer. Akan jarang menjalankan aplikasi yang dipadukan dengan cara yang sama seperti Anda menjalankan aplikasi di VM: akan ada lebih dari satu kontainer docker yang berjalan di host yang sama.

Dalam kasus yang jarang terjadi ini, jika Anda menggunakan mode jaringan yang dijembatani, Anda mungkin memerlukan penugasan port statis untuk setiap kontainer. Ini berarti Anda sudah memilih terlebih dulu port yang terpapar kontainer pada host, dan menggunakannya untuk mengatur load balancer dan proxy.

Rekonfigurasi load balancer dan proxy mungkin tidak diperlukan jika hanya ada kebutuhan terbatas untuk menambahkan lebih banyak kontainer ke host. Namun, dalam kebanyakan kasus, kontainer ditambahkan atau dihapus berdasarkan muatan melalui penggunaan penempatan yang tidak berubah atau praktik penskalaan. Dalam kasus ini, akan sulit untuk menyimpan seperangkat nomor port statis yang “pra-ditetapkan”.

Dukungan Produksi: Agregasi dan Pemantauan Log

Layanan pendukung yang dibutuhkan untuk kontainer dalam produksi tetap sama dengan lingkungan yang tidak mengandung kontainer. Ini termasuk cara untuk menangkap log dari kejadian kontainer dan mengirimkannya ke sistem pengelolaan log terpusat. Built-in dukungan backend log sudah ada di daemon Docker, dan solusi kustom juga dapat menangani hal ini.

Ada sejumlah pilihan untuk mengelola data log yang diproduksi oleh kontainer Docker. Pengaturan default Docker menulis log yang tidak dikompres ke disk dengan pengaturan retensi opsional untuk membatasi penggunaan penyimpanan.

Di lingkungan produksi, ada sejumlah driver logging yang dikirimkan bersama mesin Docker dan memberikan pilihan fleksibel untuk mengelola data log secara transparan ke aplikasi yang memproduksinya. Jika Anda sudah memiliki solusi logging terpusat di tempat, mungkin ada driver logging Docker yang dapat dikonfigurasi untuk memberi masukan data log kontainer ke dalamnya.

Ada driver logging untuk berbagai protokol yang telah stabil seperti Syslog, yang dapat digunakan untuk sejumlah sistem penyerapan serta opsi khusus cloud atau SaaS.

Keadaan fana kontainer (ephemeral) adalah perilaku utama yang harus diperhatikan dalam logging dan pemantauan kontainer. Wadah baru menggantikan yang lama saat penggelaran terjadi dalam produksi. Ini adalah jeda dari konvensi tradisional dengan mengasumsikan unit penghitungan jumlah status.

Memutar kontainer menciptakan masalah baru untuk pola pikir logging dan pemantauan tradisional. Dari pada menghitung kasus yang terbaring berhari-hari selama berbulan-bulan, kontainer dapat di roll-back dalam jendela hanya satu jam.

Keadaan fana kontainer adalah perilaku utama yang harus diperhatikan dalam logging dan pemantauan kontainer.

Jika Anda mempraktikan pengiriman terus menerus (CD), jendela ini bisa lebih pendek lagi. Solusi logging dan pemantauan host-sentris tidak dapat mengukur kompleksitas kontainer. Sebaliknya, karena masa hidup mereka yang pendek, miliki cara deklaratif untuk memantaunya. Dan lebih baik memonitor mereka sebagai satu kelompok, daripada memantau setiap kontainer.

Mengaitkan Kontainer

Salah satu cara untuk mengaitkan kontainer dalam grup adalah dengan menggunakan metadata yang sesuai, seperti tag. Tag mengacu pada “image tag” yang akan berjalan di lingkungan produksi. Sebaiknya hindari menggunakan tag “terbaru” yang disalahpahami untuk wadah Docker saat menerapkan ini.

Misalnya, Anda menyebarkan image aplikasi “produk-api” dengan tag image “25” dan variabel lingkungan disetel ke “produksi.” Ini berarti image ke-25 yang diidentifikasi oleh sistem pembuatan, dan wadah berjalan berada di lingkungan produksi.

Anda bisa memiliki beberapa contoh dari hal ini yang berjalan di infrastruktur kontainer docker pada suatu titik waktu tertentu. Tag akan diubah dengan setiap penyebaran baru, namun konfigurasi variabel lingkungan akan tetap disetel ke “produksi”.

Jika Anda menggunakan alat orkestrasi, Anda memiliki akses ke kosa kata tag yang lebih kaya untuk digunakan dalam mengelompokkan kejadian kontainer.

Strategi pemantauan dan logging yang sesuai untuk kontainer dalam produksi adalah solusi non-intrusif yang dapat tetap berada di luar wadah yang berjalan. Alat pemantau kontainer memerlukan platform yang “container-ready”. Hal ini akan membantu alat pemantauan menghindari kebingungan saat melaporkan kegagalan. Seperti saat sebuah wadah dihentikan di satu host dan berpindah ke platform lain oleh platform kontainer. Jejak kontainer akan menyebabkan kelebihan data yang dikumpulkan oleh sistem pemantauan dan logging, sehingga menyebabkan kebutuhan akan pengelolaan data bertambah.

Pemantauan kontainer adalah ruang yang tumbuh dengan pesat. Ada berbagai Perangkat Lunak sebagai Layanan (SaaS) dan perangkat lokal yang dapat membantu Anda membuat keputusan untuk sementara ini.

Pendekatan untuk Mengelola Data Kontainer

Saran umum untuk mengelola data kontainer adalah kontainer tanpa status yang beroperasi di lingkungan produksi yang tidak menyimpan data sendiri dan bersifat transaksional semata.

Wadah tanpa muatan menyimpan data yang diproses di luar wilayah wadah mereka, sebaiknya ke layanan penyimpanan khusus yang didukung oleh backend ketekunan yang andal dan tersedia.

Perhatian keamanan ini bahkan lebih terasa lagi dengan kontainer yang menampung layanan penyimpanan host, seperti database, antrian dan cache.

Untuk wadah stateful, pola yang disepakati adalah dengan menggunakan wadah data. Mesin runtime dari layanan stateful ini terhubung saat runtime dengan kontainer data. Secara praktis, ini berarti memiliki mesin database yang akan berjalan di atas sebuah kontainer, namun menggunakan “wadah data” yang dipasang sebagai volume untuk menyimpan status.

Jika Anda menjalankan lingkungan hosting berkluster menggunakan platform orkestrasi, penting untuk memiliki solusi penyimpanan terdistribusi, seperti Gluster dan Ceph, untuk menyediakan titik mount bersama. Ini berguna jika wadah muncul di sekitar cluster berdasarkan ketersediaan.

Keamanan Kontainer dan Manajemen Kunci

Keamanan sering menjadi perhatian utama. Terutama saat menjalankan beberapa image kontainer, masing-masing untuk penyewa yang berbeda pada mesin bersama. Kekhawatiran ini berawal dari kurangnya kepercayaan dan keyakinan bahwa teknologi kontainer akan memberikan isolasi yang tepat, seperti yang diharapkan dari implementasi berbasis VM. Namun, merawat kontainer sebagai pengganti VM tidak akan membantu masalah ini.

Implementasi kontainer, seperti Docker, menyediakan selimut keamanan untuk aplikasi. Kontainer runtime abstrak jauh komplikasi konfigurasi perizinan halus pada ruang nama yang berbeda, seperti pengguna, jaringan dan proses.

Jika mempertimbangkan penyebaran kontainer multi-tenant pada infrastruktur bersama, optimalkan VM untuk setiap pemisahan penyewa. Gunakan kontainer sebagai media isolasi antara komponen aplikasi penyewa.

Seiring berkembangnya penyebaran kontainer di seluruh pengguna, akan diperlukan untuk menghindari dinding VM dan membiarkan semua penyewa memiliki infrastruktur yang sama.

Aspek lain dari menjalankan wadah kontainer yang tidak berubah adalah dengan menghindari memanggang kunci atau kredensial apa pun yang perlu dirahasiakan. Ada banyak cara untuk mengatasi masalah ini, mulai dari melewati password melalui variabel lingkungan, untuk melindungi mereka dengan data kontainer terenkripsi yang dipasang sebagai volume. Namun, ada kritik dalam menggunakan teknik ini, dan tidak ada standar yang tersedia dari penyedia kontainer runtime.

Jalan Menuju Kontainer dalam Produksi

Unsur penting dalam membuat adopsi kontainer docker yang berhasil di produksi adalah dengan memiliki komunitas informasi yang terdidik. Alat dan praktik akan berkembang ke keadaan di mana kontainer yang sedang berjalan menjadi norma bagi sebagian besar organisasi.

Sampai saat itu, pertempuran belum selesai untuk mewujudkan adopsi kontainer di dalam organisasi. Membuat setiap pemangku kepentingan, terutama tim operasi dan keamanan, sangat memahami persyaratan mereka seputar kontainer adalah tugas yang membutuhkan banyak pekerjaan.

Jalan menuju adopsi kontainer dalam produksi akan berbeda dengan VM. Ini akan memprioritaskan pengalaman pengembang dan penyederhanaan operasional disamping pemanfaatan sumber daya.