PuppetConf 2016. Kubernetes untuk administrator sistem. Bagian 1

Saya seorang administrator sistem, berurusan dengan komputer, dan hari ini kita akan berbicara tentang Kubernetes. Saya akan mencoba menggali lebih dalam ke dalam topik, mempertimbangkan masalah apa yang dapat diselesaikan oleh administrator sistem dengan aplikasi ini, dan juga menyentuh beberapa aspek operasi Wayang, yang sepertinya cocok dengan dunia ini dengan bantuan serangkaian abstraksi baru agar aplikasi dapat berfungsi.
Lima atau enam tahun yang lalu, Luis Andre Barroso dan Urs Hoesl dalam artikel "Data Center as a Computer" menyarankan agar kita memandang pusat data sebagai satu komputer besar. Penting untuk mengabaikan fakta bahwa pusat data terdiri dari mesin yang terpisah, dan menganggapnya sebagai satu entitas logis. Segera setelah Anda mencoba menggunakan ide ini dalam praktiknya, Anda dapat menerapkan prinsip membangun sistem terdistribusi dan komputasi terdistribusi ke pusat data.



Untuk memperlakukan pusat data sebagai komputer, Anda memerlukan sistem operasi. Itu terlihat sangat mirip dengan yang Anda gunakan pada komputer yang terpisah, tetapi harus memiliki antarmuka yang berbeda, karena Anda tidak memerlukan akses ke mesin yang terpisah dan Anda tidak perlu akses ke kernel. Jadi, mari kita pikirkan pusat data sebagai komputer besar. Hari ini saya akan memberi tahu Anda apa yang harus dilakukan jika Anda tampaknya kehilangan kemampuan untuk mengendalikan mesin apa pun menggunakan SSH. Anda tidak akan dapat masuk, dan meskipun beberapa orang percaya bahwa tanpa ini tidak mungkin untuk mengontrol sistem, saya akan memberi tahu Anda berapa banyak yang dapat dilakukan dengan Kubernetes. Pertama, Anda harus menganggap Kubernet sebagai kerangka kerja untuk membangun platform terdistribusi.



Ini tidak berarti bahwa setelah mengunduh Kubernetes, Anda akan mendapatkan antarmuka pengguna yang akan memberi Anda semua yang ingin Anda lakukan dengan sistem. Tidak, ini hanya fondasi untuk membuat alat yang Anda butuhkan untuk menjalankan infrastruktur Anda. Saya akan menunjukkan kepada Anda cara membuat integrasi menggunakan Let's Encrypt Certificate Authority untuk mengotomatiskan proses sertifikat untuk aplikasi saya menggunakan Kubernetes sebagai kerangka kerja.



Banyak orang bertanya dengan tepat apa manfaat Kubernet. Saya bekerja dengan Puppet Labs selama bertahun-tahun dan melihat bahwa benda ini diinstal pada komputer untuk menyediakan sistem dengan API yang belum ada sejauh ini. Alih-alih Bash, skrip YAML, dan hal-hal serupa, Wayang menyediakan pengguna DSL yang memungkinkannya untuk berinteraksi dengan mesin secara terprogram tanpa skrip shell. Perbedaan antara Kubernet adalah terletak di atas level "besi". Mari kita tidak fokus pada otomatisasi dan abstraksi sistem ini seperti pada hubungan, atau pada kontrak, antara infrastruktur dan aplikasi kita yang akan kita tarik dari simpul mana pun. Di Kubernetes, kami tidak menetapkan aplikasi apa pun ke mesin, tidak ada yang disebut "manifes simpul", penjadwal menganggap node individual hanya sebagai sumber daya pusat data,mewakili satu komputer besar.

Pertanyaan: "Apakah Kubernet berjalan di OpenStack, di VMware, di Bare Metal, di cloud?" tidak masuk akal. Pertanyaan yang benar adalah: "Bisakah saya menjalankan agen Kubernetes untuk mengambil sumber daya ini?" Dan jawabannya adalah "ya". Karena pengoperasian aplikasi ini sepenuhnya independen dari platform yang Anda pilih.



Kubernetes adalah platform independen. Kubernetes bersifat deklaratif dengan cara yang sama seperti Wayang. Oleh karena itu, Anda melaporkan aplikasi mana yang akan Anda gunakan - dalam contoh ini adalah nginx. Ini adalah kontrak antara Anda, pengembang, dan Kubernet sebagai sarana untuk membuat gambar wadah.

Saya suka menggunakan analogi dengan perusahaan kurir FedEx - Anda tidak dapat menyeret mereka semua dan menunggu sampai mereka mengurutkan semuanya dan mengirimkannya ke tempat yang seharusnya. Mereka memiliki aturan: kemas barang-barang Anda dalam sebuah kotak. Setelah Anda melakukannya, mereka akan mengirim kotak Anda dan akan dapat mengetahui kapan akan tiba di tujuannya. "Jika Anda tidak memiliki kotak, maka Anda tidak akan dapat bekerja dengan sistem kami."

Oleh karena itu, ketika bekerja dengan wadah tidak ada gunanya mendiskusikan apa yang Anda miliki - Python, Java dan atau sesuatu yang lain, itu tidak masalah - ambil semua dependensi Anda dan masukkan ke dalam wadah. Banyak orang mengatakan tentang kontainer bahwa mereka tampaknya menyelesaikan masalah seluruh infrastruktur. Namun, masalahnya adalah bahwa orang tidak menganggap wadah sebagai dua hal yang berbeda. Yang pertama adalah gagasan format kemasan, yang kedua adalah gagasan runtime wadah. Ini adalah dua hal berbeda yang tidak selalu membutuhkan alat yang sama.

Manakah dari mereka yang menciptakan wadah? Dan siapa yang menggunakan Wayang untuk membuat wadah? Itu benar, saya juga tidak setuju dengan ini! Anda bisa mengatakan: “bagaimana bisa begitu? Anda berada di konferensi Wayang, Anda harus setuju! " Alasan saya tidak setuju dengan gagasan membangun wadah di Wayang adalah ini: Saya tidak tahu apakah kita memerlukannya sama sekali, karena hal-hal yang kita butuhkan untuk membuat gambar berbeda dari hal-hal yang kita perlukan untuk memulai proses prod.

Mari kita anggap itu sebagai membangun pipa perangkat lunak dan melihat Dockerfile ini. Tutup mata Anda untuk mereka yang belum pernah melihat file-file ini, karena bagi Anda mereka dapat terlihat mengintimidasi. File ini menunjukkan cara membuat aplikasi Ruby on Rails - aplikasi Ruby dengan kerangka Rails.



Ia mengatakan "FROM ruby ​​2.3.1", yang mungkin akan memasukkan seluruh sistem operasi ke dalam wadah, dalam hal ini adalah gambar dasar Ruby alpine-linux. Adakah yang tahu mengapa kami menyematkan gambar Ubuntu atau Red Hat di wadah ini? Kebanyakan orang tidak tahu apa itu dependensi, dan menggunakan pendekatan yang serampangan, hanya memasukkan seluruh OS ke dalam wadah untuk memastikan mereka memiliki dependensi di suatu tempat di dalam. Jadi, setelah Anda membangunnya, Anda hanya perlu menjalankannya sekali saja. Di sinilah kesalahpahaman berasal: jika hal ini tidak berhasil, ubah baris kode sampai berfungsi. Periksa saja! Anda tidak perlu terlalu pintar dengan file-file ini, tujuan Anda adalah untuk membangun representasi offline aplikasi Anda dengan semua dependensi. Ini hanya penopang yang kami gunakan dari Ubuntu sebagai titik awal.

Jika Anda baru saja membuat aplikasi dan meluncurkannya, Anda akan menggunakan sesuatu seperti tautan statis. Tidak ada dependensi pada host, dalam wadah Anda, Anda hanya akan memiliki biner dari file Docker satu baris dan tidak ada gambar dasar. Faktanya, itu hanya transfer hal-hal yang akrab bagi kita. Lihat bagaimana rakitan ini akan terlihat.



Saya sebelumnya membuat file ini, tetapi biasanya ini terlihat seperti upaya untuk membangun seluruh Internet. Saya agak takut pada perakitan ini, karena saya tidak yakin bahwa Internet lokal dapat menangani Ruby. Lihat apa yang terjadi.



Bagaimana Anda suka volume 1 Gig ini? Selain itu, file sumber, yaitu, aplikasi Anda sendiri, dapat menempati, katakanlah, hanya 100 kB. Jadi, bagaimana kita mendapatkan seluruh gigabyte? Ini karena kami menggunakan alat yang tidak efisien untuk membuat aplikasi yang berdiri sendiri. Semuanya dirancang untuk dijalankan di komputer dan menggunakan pustaka dinamis yang dimuat dari lingkungan eksternal.

Sekarang kami akan mencoba melakukan apa yang kami lakukan pada ponsel - versi aplikasi portabel untuk penggunaan yang ada kontrak antara Anda dan infrastruktur. Segera setelah kami memiliki kontrak seperti itu, kami akan dapat memberi tahu sistem apa yang seharusnya dilakukan, dan tidak akan peduli apa yang harus dilakukan.

Anda tidak memiliki aplikasi khusus yang dibuat khusus. Saya menemukan perusahaan yang mengatakan: "kami memiliki aplikasi khusus!". Saya berkata: "Mari kita tebak apa yang dilakukannya: mulai, mengikat ke port, menerima lalu lintas, melakukan sesuatu dengan data," dan mereka adalah: "Wow, bagaimana Anda tahu itu?" Saya tahu, karena tidak ada yang istimewa di sini!

Jadi, kami mengambil sampel yang kami tempatkan di wadah dan mengirimkannya ke server API. Selanjutnya, kita perlu mengubahnya menjadi sesuatu yang akan bekerja pada mesin kita. Namun, untuk mengumpulkan sumber daya dari mesin, kita perlu menginstal beberapa hal: runtime kontainer untuk file Docker, agen yang mengerti bagaimana berkomunikasi dengan wizard untuk menjalankan semua yang diperlukan, seperti apa respon sistem untuk aplikasi untuk mulai bekerja . Agen ini hanya mengamati - tidak ada interval 30 detik, pemeriksaan berulang, tidak ada yang seperti itu. Dia hanya mengamati, mengatakan: "jika ada pekerjaan untuk saya, beri tahu saya tentang itu, dan saya akan mulai dan akan terus memberi tahu Anda tentang status proses", sehingga Anda akan tahu bahwa itu berhasil.



Segera setelah kami melakukan ini dengan mobil, kami membutuhkan penjadwal. Berapa banyak orang yang menggunakan penjadwal? Anda semua harus mengangkat tangan! Itu sama dengan jawaban untuk pertanyaan: "siapa di antara Anda yang memiliki laptop dengan lebih dari satu prosesor inti?" Memang, ketika saya mengajukan pertanyaan tentang perencana, kebanyakan tidak mengangkat tangan.

Ketika Anda memulai proses Anda pada mesin, sesuatu harus memilih prosesor mana yang akan digunakan. Siapa yang melakukan ini? Benar, intinya. Sekarang saya akan menjelaskan kepada kalian apa itu perencana. Cara tercepat untuk melakukan ini adalah dengan bermain Tetris. Hal pertama yang akan kita bahas adalah penyebaran otomatis.



Berapa banyak dari Anda yang menggunakan penyebaran otomatis penuh? Jelas, saya pikir itu sebabnya kita semua ada di sini. Jadi, saya menekan tombol, balok mulai jatuh dari atas, dan sekarang Anda bisa minum bir. Tetapi perhatikan apa yang terjadi di kiri dan di kanan: prosesor dan memori Anda berubah menjadi sampah.



Ini terjadi karena kebanyakan orang menggunakan tidak lebih dari 5% dari sumber daya komputer. Anda mengotomatiskan proses, tetapi kehilangan banyak uang. Saya bekerja sebagai penyedia cloud, saya memiliki cadangan sumber daya yang besar, tetapi hanya mengerikan ketika orang menghabiskan uang dengan cara yang sama.

Saat Anda menggunakan penjadwal, dengan analogi dengan Tetris, kendalikan lapangan bermain dan kendalikan setiap blok, arahkan ke tempat yang tepat, yaitu, gunakan sumber daya mesin dengan cara yang paling optimal. Kubernetes menggunakan beberapa algoritma untuk ini. Algoritma utama disebut Bin Packing - "Tetris" yang sama akan membantu untuk memahaminya. Kubernetes menerima beban kerja berbagai bentuk dan ukuran, dan tugas kami adalah mengemasnya dalam mesin secara optimal.

Tujuan kami adalah untuk menggunakan kembali semua sumber daya yang tersedia saat pekerjaan berlangsung. Tidak semua beban kerja sama, sehingga sulit untuk menempatkannya di kotak yang sama. Tetapi di Kubernetes, ketika "bagian" dari beban kerja muncul (atau blok Tetris, jika kita melanjutkan analogi kita), selalu ada cluster yang tepat di mana Anda dapat meletakkannya dan menjalankannya. Dan seperti halnya pemrosesan batch, setelah tugas selesai, kami mendapatkan kembali semua sumber daya yang sebelumnya ditempati sehingga kami dapat menggunakannya untuk tugas di masa mendatang.

Karena kita hidup bukan di dalam gim, tetapi di dunia nyata, Anda memiliki solusi yang dikembangkan bertahun-tahun yang lalu. Kemudian Anda menjadi administrator sistem, perusahaan menunjukkan kepada Anda produksi mereka, dan Anda melihat bahwa penyebaran mereka tidak cukup baik.



Anda dapat menginstal manajer kluster pada bagian-bagian mesin Anda dan membiarkan mereka mengelola sumber daya tertentu. Dalam kasus khusus ini, Anda dapat menggunakan Kubernetes, yang akan mulai mengisi ruang kosong Tetris Anda saat Anda bergerak maju.
Biarkan mereka yang bekerja di industri mengangkat tangan. Ya, ini adalah gaji klasik yang disebut. Misalkan Anda memiliki beberapa masalah di perusahaan Anda. Yang pertama adalah bahwa semuanya ditulis dalam Java atau bahkan dalam COBOL - biasanya tidak ada yang siap untuk ini.

Masalah kedua yang sering dihadapi dalam perusahaan adalah Oracle DBMS. Ini adalah hal seperti itu, yang terletak di bagian belakang perangkat lunak dan berkata: "Jangan mencoba mengotomatisasi apa pun!". Jika Anda mengotomatiskan perangkat lunak, biaya Anda akan meningkat. Karena itu, tidak ada otomatisasi - kami mempromosikan ekosistem konsultasi kami!

Biasanya, dalam keadaan seperti itu, orang-orang bertanya apakah Kubernet dapat digunakan untuk menyelesaikan masalah ini. Saya menjawab: "tidak," karena dalam situasi yang mirip dengan kalah di Tetris, tidak ada yang akan membantu Anda. Anda perlu melakukan sesuatu yang lain, yaitu menggunakan scheduler.
Sekarang kami memiliki penjadwal yang berhasil memahami beban kerja, Anda dapat dengan mudah meletakkan semuanya di dalam kotak, dan penjadwal akan memulai pekerjaannya.



Mari kita bicara tentang entitas kunci Kubernetes. Pertama, ini adalah pods Pods, yang merupakan kumpulan kontainer. Dalam kebanyakan kasus, aplikasi terdiri dari lebih dari satu komponen. Anda dapat melampirkan sendiri aplikasi yang ditulis tanpa skrip Java, tetapi Anda mungkin ingin menggunakan nginx untuk menyelesaikan TLS dan hanya proxy di latar belakang aplikasi, dan kemudian hal-hal ini harus dihubungkan bersama, karena mereka adalah dependensi yang dikodekan secara keras. Ketergantungan longgar digabungkan adalah database yang Anda skala secara mandiri.



Hal penting kedua adalah Pengendali Replikasi, yang merupakan manajer dari proses yang terjadi di kluster Kubernetes. Hal ini memungkinkan Anda untuk membuat beberapa contoh perapian dan memantau kondisinya.

Ketika Anda mengatakan bahwa Anda ingin memulai beberapa proses, itu berarti bahwa itu akan bekerja sepanjang waktu di suatu tempat di kluster.

Elemen penting ketiga adalah Layanan, seperangkat perapian kolaboratif. Penempatan Anda didasarkan pada penentuan dinamis dari keadaan yang diinginkan - di mana aplikasi harus bekerja, dengan alamat IP apa, dll., Sehingga Anda memerlukan beberapa bentuk layanan.

Elemen keempat adalah repositori Volume, yang dapat dilihat sebagai direktori yang tersedia untuk kontainer di perapian. Kubernetes memiliki berbagai jenis Volume yang menentukan bagaimana toko ini dibuat dan apa isinya. Konsep Volume juga hadir di Docker, tetapi masalahnya adalah bahwa penyimpanan di sana terbatas pada perapian tertentu. Segera setelah tidak ada lagi, Volume menghilang bersama itu.

Penyimpanan yang dibuat Kubernetes tidak terbatas pada wadah apa pun. Ini mendukung setiap atau semua kontainer yang digunakan di dalam perapian. Keuntungan utama Kubernetes Volume adalah dukungannya untuk berbagai jenis penyimpanan yang Pod dapat gunakan secara bersamaan.

Mari kita lihat wadah apa itu. Ini adalah format gambar di mana aplikasi kita dengan semua dependensi dikemas, dan konfigurasi utama dari lingkungan runtime, menunjukkan bagaimana aplikasi ini seharusnya bekerja. Ini adalah dua elemen yang berbeda, meskipun Anda dapat mengemas apa pun yang Anda suka ke dalam hal ini, khususnya, Root Filesystem sebagai file tar Tarball terkompresi yang berisi banyak file konfigurasi untuk sistem tertentu.



Kemudian kita dapat melakukan distribusi, sebuah proses yang akrab bagi Anda semua - RPM atau sistem repositori lain digunakan di sini. Anda mengambil semua hal ini dan meletakkannya di repositori. Proses ini sangat mirip dengan apa yang kita lakukan dengan paket OS, hanya untuk wadah yang dibuat dari gambar.



Pod memungkinkan Anda membuat semua yang dibutuhkan aplikasi logis kami. Aplikasi logis adalah alat untuk mengelola beberapa aplikasi dalam profil sistem yang sama. Sub adalah paket sumber daya yang mencakup satu atau lebih kontainer dan penyimpanan, ruang nama umum, dan satu alamat IP per sub. Vault dapat didistribusikan di antara kontainer.



Secara umum, desain perapian menyerupai mesin virtual. Ini memastikan bahwa aplikasi akan mulai dan berhenti sebagai unit atom. Slide berikutnya menunjukkan seperti apa pengontrol replikasi itu. Jika saya mengirim deklarasi ini ke server dan berkata: "Hei, saya ingin satu replika aplikasi" Foo "berfungsi!", Controller akan membuatnya dari template dan mengirimkannya ke scheduler, yang akan menempatkan aplikasi pada Node 1. Kami tidak menentukan pada mesin mana ia harus dijalankan, meskipun kita bisa melakukannya. Sekarang tambah jumlah replika menjadi 3.



Tindakan apa yang Anda harapkan dari sistem jika salah satu mesin gagal? Dalam hal ini, pengontrol replikasi akan membawa kondisi sistem saat ini ke kondisi yang diinginkan, memindahkannya di bawah wadah dari yang ketiga, mesin yang tidak bekerja, ke yang kedua.



Anda tidak perlu mempelajari proses ini dan mengarahkannya - dengan mempercayakan pekerjaan pada pengontrol, Anda dapat yakin bahwa aplikasi akan dipastikan dengan benar dengan terus memantau perubahan dalam kondisi infrastruktur saat ini dan membuat keputusan yang memastikan sistem berfungsi.

Hal-hal ini berada di depan waktu mereka - Anda hanya memberi tahu sistem: "Saya ingin tiga mesin ini bekerja!", Dan di sinilah kendali Anda berakhir. Pendekatan ini sangat berbeda dari scripting dan otomatisasi murni, ketika Anda benar-benar perlu mengelola apa yang terjadi sekarang untuk memengaruhi keputusan di masa depan. Anda tidak dapat menyusun semua ini tanpa kemampuan untuk menerima informasi yang masuk untuk merespons situasi dengan benar. Pendekatan yang dijelaskan di atas memberi Anda kesempatan ini.
Bagaimana Anda membayangkan konfigurasi - konsep file konfigurasi untuk layanan? Banyak orang diam tentang masalah ini ketika datang ke wadah, tapi kami masih membutuhkan konfigurasi, itu tidak hilang di mana pun!

Kubernetes juga menggunakan konsep Rahasia, yang digunakan untuk menyimpan dan mentransfer data terenkripsi antara manajer dan node Nods.

Kami tidak pernah menjalankan Wayang dalam wadah karena tidak ada alasan untuk melakukan ini. Anda dapat menggunakan Wayang untuk menghasilkan file konfigurasi, tetapi Anda masih ingin menyimpannya di Kubernetis karena memungkinkan Anda untuk mendistribusikannya menggunakan runtime. Mari kita lihat tampilannya.



Dalam contoh ini, kami membuat rahasia dari file dan menyimpannya di server API Kubernetes. Anda dapat membayangkan bahwa Anda mengganti bagian ini dengan sesuatu seperti Puppet, yang menggunakan templat eRB dan data tersembunyi untuk mengisi konten rahasia - tidak masalah siapa yang melakukannya, tetapi Anda tetap bisa melakukannya.

Begitu rahasia itu ada, itu bisa berfungsi sebagai tautan untuk membuat penyebaran yang mengatakan, "Saya ingin menggunakan rahasia ini!" Dalam hal ini, Kubernetes melakukan hal berikut.



Ini membuat pod, mengambil data dari rahasia, menempatkannya dalam sistem file sementara dan menyajikannya sebagai wadah, seperti Puppet membuat salinan pada mesin. Ini mengikuti siklus hidup aplikasi, dan ketika aplikasi mati, konfigurasi menghilang dengan itu. Jika Anda membutuhkan 10.000 instance aplikasi, Anda harus membuat dan menyuntikkan ke dalam 10.000 sistem file sementara.

Layanan memungkinkan Anda untuk menjalankan semua elemen ini dalam sebuah cluster dan menyinkronkannya dengan titik akhir lain. Bahkan, layanan adalah sekelompok perapian yang berfungsi sebagai perapian tunggal. Ini berisi alamat IP permanen dan port, menyediakan integrasi ke DNS, menggunakan load balancing dan diperbarui ketika firmware berubah.



Sekarang mari kita lihat kolaborasi komponen konseptual Kubernet. Kami memiliki bata Lego dan konfigurasi yang harus berinteraksi satu sama lain. Jika Anda berniat untuk menjalankan database dalam sebuah cluster, maka Anda benar-benar dapat melakukannya di Kubernetes. Banyak yang mengatakan bahwa Anda tidak akan dapat menjalankan aplikasi stateful dalam wadah, tetapi ini sepenuhnya salah.

Jika Anda berpikir tentang cara kerja hypervisors, Anda dapat memahami bahwa mereka melakukan hal yang hampir sama dengan Anda: membuat mesin virtual, scheduler memindahkannya ke hypervisor dan menempelkan penyimpanan. Terkadang Anda bekerja dengan penyimpanan lokal yang berasal dari hypervisor, dan tidak ada alasan mengapa wadah tidak dapat melakukan hal yang sama.

Namun, masalah dengan kontainer adalah bahwa kebanyakan orang tidak terbiasa memiliki daftar jalur file yang harus mereka sediakan untuk aplikasi tersebut. Kebanyakan orang tidak akan dapat memberi tahu Anda dengan tepat perangkat dan file yang dibutuhkan data warehouse. Mereka mengemas segala sesuatu dalam wadah, dan sebagai hasilnya, tidak ada yang baik dari itu. Oleh karena itu, jangan percaya bahwa kontainer tidak mampu menjalankan aplikasi hemat negara - Anda dapat melakukannya dengan sangat baik.



Pada slide Anda melihat contoh Ruby-on-Rails, dan sebelum kami dapat menggunakan aplikasi kami, kami perlu melakukan migrasi database. Mari kita turun ke demo langsung program. Untuk melakukan penyebaran, saya menggunakan MY_SQL, dan Anda melihat banyak data di layar.



Saya menunjukkan kepada Anda semua ini karena, sebagai administrator sistem, Anda harus memahami banyak hal. Dalam penerapan ini, saya memperbaiki beberapa metadata aplikasi saya, tetapi hal utama yang saya akan soroti dalam warna abu-abu: Saya ingin memulai 1 salinan aplikasi mysql dan menggunakan wadah mysql versi 5.6.32.



Perhatikan bahwa di sini saya memilih beberapa rahasia dari Kubernetes sebagai tautan, yang dalam hal ini saya akan menyuntikkan sebagai variabel lingkungan. Nanti saya akan menunjukkan kepada Anda kasus lain ketika kita memasukkannya ke dalam sistem file. Jadi, saya tidak perlu "memanggang" rahasia dalam konfigurasi saya. Baris penting berikutnya adalah blok sumber daya.



Anda tidak dapat memainkan Tetris sampai Anda tahu ukuran baloknya. Banyak orang mulai menggunakan tanpa menggunakan batas sumber daya untuk proses ini. Akibatnya, RAM benar-benar tersumbat, dan Anda "menumpuk" seluruh server.

22:09 mnt

Untuk dilanjutkan segera ...

Sedikit iklan :)

Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda VPS berbasis cloud untuk pengembang mulai $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?