Di perusahaan besar, seringkali sangat sulit untuk mengoordinasikan alokasi sumber daya untuk tugas-tugas pekerjaan. Semua Agile berderak di dinding perjanjian tiga minggu dengan IS dari infrastruktur baru. Oleh karena itu, kami sering menerima permintaan untuk mentransfer infrastruktur ke kontainer untuk meluncurkan perubahan tidak setiap tiga bulan, dan ketika bisnis membutuhkannya. Pada saat yang sama, mereka meminta untuk mengkonfigurasi / mengimplementasikan Kubernetes sebagai instrumen orkestrasi yang paling populer, meskipun, seperti yang ditunjukkan oleh praktik, dari 10 proyek, maksimum tiga dibutuhkan. Tetapi pada kenyataannya, ada baiknya menggunakan Kubernetes, tetapi OpenShift, atau bekerja dengannya tidak di infrastruktur Anda, tetapi di cloud publik, misalnya. Saya akan mencoba untuk berbicara tentang kasus-kasus bisnis nyata yang kami putuskan, saya akan menjelaskan perbedaan utama antara Kubernetes dan OpenShift. Dan juga tentang bagaimana kita mengurangi koordinasi keamanan informasi menjadi 30 menit, dan semuanya tetap hidup.
Kami memiliki beberapa implementasi menarik di mana kami mengumpulkan akumulasi masalah pelanggan. Sebagai contoh, sebuah perusahaan ritel datang kepada kami yang perlu mengeluarkan chip baru secara terus menerus. Persaingan itu liar! Dan mereka hanya memiliki infrastruktur untuk pengembangan setiap kali dari enam hingga sepuluh hari, yang menyebabkan downtime. Memecahkan masalah dengan membeli perangkat keras baru untuk pengujian dan pengembangan adalah mahal dan jalan ke mana-mana. Akibatnya, kami mentransfer infrastruktur TI ke virtualisasi wadah. Akibatnya, berkat kontainer, beban berkurang hingga 40%, dan infrastruktur untuk pengembangan baru sekarang sedang disiapkan dari satu hingga empat jam. Bonusnya adalah tabungan, karena semua proses dapat terus dilakukan berdasarkan kapasitas yang ada tanpa membeli yang baru.
Apa yang akan kita lakukan dengan keamanan informasi?
IB adalah orang yang sangat diperlukan. Mereka sering terlalu jauh dalam persyaratan internal untuk proyek, tetapi ini jauh lebih baik daripada melihat sekali bahwa peretas Rumania Anda telah mengepung server SFTP eksternal Anda.
Tapi ada masalah dengan mereka. Jika kita menganggap proses bisnis sebagai konveyor, maka divisi mereka sering menjadi hambatan yang menjadi sandaran semua orang. Di satu sisi, mereka bertanggung jawab atas semua risiko yang terkait dengan keamanan, di sisi lain, mereka tidak secara fisik mengelola untuk melihat kode secara manual dan semua detail arsitektur produk baru.
Situasinya sangat mirip dengan dinas keamanan di daerah-daerah dengan arus penduduk yang besar. Kita dapat mengatur inspeksi total setiap penumpang di kereta bawah tanah, menyinarinya dengan pemindai, memutar kantong dan memeriksa telepon. Sebagai akibatnya, bagaimanapun, alih-alih keamanan, Anda akan mendapatkan keruntuhan transportasi lengkap dan kelumpuhan sistem. Satu-satunya pilihan dalam situasi ini adalah organisasi sistem otomatis yang akan merespons, katakanlah, kepada individu, mengidentifikasi orang yang dicari atau bereaksi terhadap beberapa perilaku abnormal.
Dalam konteks kami, sistem otomatis semacam itu adalah proses CI / CD yang terorganisasi dengan baik dengan penganalisa kode pada tahap menengah, solusi seperti JFrog Xray untuk Artifactory, dan kacang Kubernetes / OpenShift yang dikencangkan dengan benar yang tidak memungkinkan pendekatan yang tidak aman seperti meluncurkan wadah dari pengguna root. Sekarang kami sedang mempersiapkan solusi kemas yang akan menyediakan semua ini.
Tujuannya adalah untuk beralih dari konsep "tidak akan masuk ke penjualan sampai kita melihat" ke "jika tidak ada keberatan, itu akan digunakan secara otomatis." Tidak ada gunanya dalam otomatisasi jika proses organisasi tetap sama.
Di salah satu proyek, kami berhasil mengurangi waktu kegagalan IS menjadi 30 menit. Dengan kata lain, jika dalam waktu setengah jam "satpam" tidak menolak tindakan, maka itu disetujui secara otomatis, dan perubahan tersebut dimasukkan ke dalam produksi. Sekarang kami berusaha mencapai tenggat waktu 60 menit untuk semua koordinator dalam proyek tanpa mengorbankan keamanan.
Apa perbedaan antara sistem manajemen kontainer?
Kubernetes dan OpenShift adalah solusi utama untuk orkestrasi wadah. Mari kita menganalisis perbedaan utama dan keuntungan untuk bisnis ini.
KeterbukaanKubernetes adalah produk sepenuhnya terbuka yang dapat digunakan secara mandiri dan dilayani baik sendiri atau dengan dukungan eksternal. Situasi di pasar tenaga kerja sudah lebih atau kurang stabil, dan menemukan ahli dalam topik ini tidak lagi menjadi masalah.
OpenShift adalah produk semi-tertutup dengan sistem lisensi canggih dari RedHat. Bahkan, ini berisi Kubernetes, tetapi memiliki banyak ikatan tambahan yang menyederhanakan banyak tugas. Vendor memberikan dukungan penuh untuk produknya.
Di sini pilihan tergantung pada apa yang paling cocok untuk Anda - dukungan oleh kekuatan spesialis atau vendor Anda.
PlatformKubernet bekerja di hampir semua platform Linux dan sebagian besar penyedia cloud.
OpenShift tidak berfungsi di mana pun kecuali pada RHEL, Red Hat Atomic, Red Hat CoreOS. Ada versi komunitas - OKD, tetapi terkait erat dengan distribusi. Satu-satunya pengecualian adalah dapat diinstal pada CentOS. Dan perlu diingat bahwa Red Hat secara resmi tidak menjamin dukungan berbayar.
Kebijakan keamananOpenShift out of the box memiliki pengaturan keamanan yang lebih ketat. Ini merupakan nilai tambah ketika menggelar infrastruktur dari awal, tetapi ini bisa menjadi masalah karena ketidakcocokan beberapa gambar dengan politisi. Misalnya, di OpenShift, dilarang menjalankan wadah dari root, yang merusak kompatibilitas dengan gambar-gambar lama. Di sisi lain, pendekatan ini, dikombinasikan dengan integrasi yang mudah dengan AD, logging yang mudah berdasarkan tumpukan EFK (ElasticSearch, Fluentd, Kibana) memberi kita keamanan di luar kotak yang diperlukan untuk membongkar unit IS.
Kubernetes juga dapat diselesaikan pada level ini, tetapi akan membutuhkan banyak usaha dan waktu dari pihak insinyur.
PolaTemplat OpenShift kurang fleksibel dibandingkan grafik Helm Kubernetes. Karena kebijakan keamanan yang lebih ketat, Red Hat tidak dapat memberikan fleksibilitas dari grafik Helm sekarang. Namun, di OpenShift 4, situasinya telah mendatar berkat
OperatorHub yang terintegrasi.
Memiliki template yang dirancang dengan baik di luar kotak membuat hidup jauh lebih mudah. Bahkan, ini adalah opsi manajer paket untuk membangun dan mengkonfigurasi berbagai layanan.
Satu perintah kondisional "helm install prometheus-operator" menyebarkan sistem yang agak rumit, yang membutuhkan waktu sangat lama untuk digunakan. Kubernetes memimpin.
Kesimpulan umumSeperti kebanyakan produk, Red Hat OpenShift adalah solusi yang lebih kotak, tetapi secara arsitektur lebih keras. Ini membutuhkan lebih sedikit staf yang bermata merah dan lebih berpengalaman untuk bekerja. Skenario penerapan yang lebih nyaman, integrasi yang sangat baik dengan solusi CI / CD, khususnya, dengan Jenkins. OpenShift sangat bagus untuk perusahaan yang lebih mudah membayar untuk mendukung produk jadi daripada menyewa spesialis mereka sendiri.
Untuk perusahaan dengan spesialis yang kuat di bidang ini, Kubernetes mungkin menjadi solusi yang lebih fleksibel dan menarik. Ini mungkin juga cocok untuk bisnis yang relatif kecil yang ingin menghemat lisensi Red Hat, tetapi tidak memiliki tugas kompleks yang membutuhkan para ahli yang sangat berkualitas.
Kasus nyata
Saya akan mencoba menunjukkan bagaimana teknologi kontainer membantu menyelesaikan masalah bisnis, menyelamatkan lisensi, dan memastikan perataan beban puncak selama penggerebekan massal.
Studi Kasus: E-Commerce
MasalahPelanggan memiliki lebih dari 100 layanan aktif yang menjalankan fondasi cloud VMware. Dan semua taman ini memiliki beberapa masalah berbeda:
- 12 layanan yang menuntut sumber daya dan non-margin berputar di VMware, menghabiskan anggaran sekitar $ 408.000 per tahun.
- Tiga layanan (portal dan dua aplikasi seluler) mulai berkembang secara aktif: selama tujuh bulan, jumlah sumber daya yang dibutuhkan untuk bekerja meningkat 4,5 kali dan terus bertambah.
- Beberapa layanan pelanggan memiliki beban puncak, di mana sumber daya dibutuhkan enam hingga tujuh kali lebih banyak dari pada waktu normal. Karenanya, peralatan dialokasikan untuk operasi yang benar, yang sebagian besar waktu digunakan kurang dari 15%.
Selain semua ini, pelanggan memiliki keinginan untuk menjauh dari ikatan dengan satu vendor virtualisasi.
Keputusan kamiSolusi pertama dan paling sederhana: kami mentransfer layanan dengan puncak ke
cloud CROC publik . Dengan penagihan untuk sumber daya yang dikonsumsi. Semuanya sesederhana dan membosankan mungkin. Pindah dari VMware seseorang ke KVM kami adalah salah satu kasus yang paling sering bagi para insinyur cloud.
Karena perangkat keras untuk penskalaan telah dibeli oleh pelanggan, kami hanya perlu menghitung lisensi. Untuk host baru dari VMware, harganya sekitar $ 2.100.000, yang tidak sesuai dengan pelanggan. Kami mengusulkan untuk mentransfer beberapa layanan ke KVM yang menjalankan OpenStack. Dan agar tidak tersesat, mengintegrasikan manajemen kedua infrastruktur oleh CloudForms (dan pada saat yang sama OpenShift).
Akibatnya, pelanggan menerima pundak kedua dari cloud pribadi berdasarkan OpenStack, yang menutup pertanyaan vendorlock. Dengan memindahkan beberapa layanan intensif sumber daya ke bahu baru, ternyata mengurangi biaya lisensi VMware (dukungan 24 x 7 dari CROC ternyata lebih murah).
Kasus: Eceran
MasalahSelama audit, ternyata sesuatu yang mengerikan terjadi dengan pelanggan mengenai alokasi infrastruktur. Proyek - lebih dari 250, tim pengembangan - lebih dari 150, setengah kontainer di Kubernetes. Sumber daya untuk setiap proyek baru dibeli dan tetap ditugaskan untuk itu tanpa kemampuan untuk memilih, bahkan jika mereka tidak digunakan. Tidak ada penagihan sama sekali, tidak ada portal tunggal. Biaya besar untuk lingkungan pengujian dan pra-produksi, karena mereka juga berputar pada VMware.
Pada saat yang sama, pelanggan tidak ingin sepenuhnya beralih ke platform baru dan ingin mengumpulkan semuanya di bawah satu portal manajemen. Selain itu, "semuanya" tidak hanya VMware, tetapi juga PaaS, wadah, dan satu tagihan.
Keputusan kamiAkibatnya, di dalam solusi ternyata agak menumpuk, tetapi di luar untuk pelanggan semuanya terlihat sangat sederhana.
Direktori di mana pengguna memilih parameter dari mesin virtual dan sirkuit yang diperlukan: DevTest, PreProd, Prod. Dan kemudian CloudForms memilih tempat untuk menggunakan sumber daya yang diminta: di VMware atau di OpenShift. Kami masih mengerjakan penagihan tunggal, karena solusi hybrid VMware + OpenShift cukup sulit untuk disatukan.
Bahkan, dengan cara ini kami membereskan infrastruktur, memilah puing-puing yang ditumpuk oleh pelanggan.
Kasus: Industri
MasalahMenyalin VM ke berbagai lingkungan (Test, Dev, Prod, Preprod) membutuhkan waktu lebih dari tiga hari dan membutuhkan eksekusi manual dari 15 operasi yang berbeda, yang masing-masing membutuhkan waktu hingga 30 menit. Audit yang lebih dalam menunjukkan bahwa sebelumnya perlu waktu dua minggu untuk mengalokasikan sumber daya untuk proyek baru, dan ada 10-20 permintaan per bulan. Sekarang ada lebih dari sepuluh permintaan sumber daya per hari, yang, tanpa otomatisasi, menyebabkan kehancuran.
Keputusan kamiBahkan, pelanggan perlu mentransfer infrastruktur TI ke model layanan, membangun kembali, dan mengotomatiskan proses membuat perubahan pada infrastruktur, membuat portal swalayan, mengisinya dengan katalog layanan dan menerapkan lingkungan untuk mengelola aplikasi kemas. Kami mengotomatiskan proses penyalinan VM, tetapi masih membutuhkan banyak waktu: 40-60 menit, ini tidak sesuai dengan pelanggan. Sebagai hasilnya, kami mengusulkan beralih ke wadah, yang mengurangi waktu untuk menyalin menjadi tiga hingga lima menit.
Kesimpulan
Containerisasi dan layanan microser bukan indulgensi untuk kode buruk yang akan ditulis dengan kaki kiri dan segera terbang ke produksi. Sebaliknya, ini adalah konsep keseluruhan, yang melibatkan banyak perbaikan karena otomatisasi mendalam dari semua proses:
- Kode menjadi lebih bersih: linter, penganalisa kode, pengujian otomatis.
- Kode dan arsitektur menjadi lebih aman: alat keamanan dengan kemampuan luas, hingga pemblokiran otomatis penyebaran kode tidak aman.
- Layanan menjadi lebih fleksibel dan mobile: siklus pengembangan sekarang sangat singkat dan merespons perubahan dengan cepat.
- Penskalaan otomatis di bawah beban: sumber daya Anda tidak lagi melorot saat jam sibuk, kehilangan penjualan dan pelanggan.
- Alokasi sumber daya yang sederhana untuk proyek-proyek baru, pengurangan waktu yang dihabiskan untuk koordinasi.
- Seringkali, containerisasi dapat secara signifikan mengurangi waktu ke pasar.
Dan terkadang containerisasi tidak diperlukan sama sekali, dan masalahnya dapat diselesaikan dengan migrasi ke cloud eksternal. Tetapi untuk membuat keputusan, dalam hal apa pun, kita perlu audit eksternal dan analisis yang baik tentang apa yang terjadi. Singkatnya, kontainer hanyalah salah satu alat untuk menyelesaikan masalah bisnis, meskipun sangat keren.