‫Dalam video terakhir, saya membahas Imperative vs.
‫Deklaratif. Kami berbicara tentang kekhasan di Kubernetes
‫satu atau yang lain.
‫Sungguh, ketika Anda melihat dokumentasi Kubernetess, itu cocok
‫untuk tiga gaya yang berbeda.
‫Ada perbedaan halus, tetapi mereka benar-benar berada pada spektrum dari
‫semua cara imperatif di satu sisi dan semua cara
‫deklaratif di sisi lain.
‫Maka opsi ini bagus, sedikit di tengah jika Anda
‫memilih untuk menggunakannya. Dalam kursus
‫ini, sejauh ini, saya telah mengajari Anda perintah
‫CLI yang ketat dan imperatif. Itu termasuk menjalankan, mengekspos.
‫Mungkin kita memiliki skala.
‫Kami tidak membahas pengeditan tetapi ia melakukan persis
‫seperti yang Anda pikirkan. Ini mengedit sumber daya secara real time.
‫Atau buat penyebaran, yang merupakan cara baru untuk menjalankan.
‫Ini benar-benar terbaik untuk mempelajari
‫cara kerja. Mempelajari jenis sumber daya dan apa yang mereka
‫lakukan, dan proyek pribadi dan pengaturan yang sangat kecil di mana mungkin
‫Anda satu-satunya orang yang bertanggung jawab. Anda
‫tidak mencoba mengotomatisasi. Anda tidak mencoba membangun alur kerja produksi
‫penuh, dan CICD, benar.
‫Itu bagus untuk mereka.
‫Lalu ada jalan tengah yang
‫bagus yang ditawarkan Kubernetes kepada Anda dengan perintah create
‫yang bisa Anda gunakan sendiri dengan membuat perintah, tetapi
‫Anda juga bisa menggunakannya dengan file YAML.
‫Anda dapat menggunakan create -f, dan Anda dapat memberikannya
‫salah satu spesifikasi seperti yang kita lihat sebelumnya.
‫Anda dapat memberikannya spec, dan itu akan membuat objek yang ada
‫di sana. Anda dapat memiliki
‫beberapa objek di file itu. Anda bisa memiliki
‫penyebaran, plus layanan, di sana.
‫Mungkin beberapa kebutuhan penyimpanan yang Anda miliki, pengaturan
‫jaringan, apa pun. Anda dapat memiliki semua file yang bagus itu.
‫Kemudian, jika Anda perlu mengganti apa pun
‫di sana, Anda dapat mengedit file dan kemudian menggunakan perintah
‫ganti, yang belum kita bahas, tetapi itu melakukan apa
‫yang Anda pikirkan. Lalu, ada perintah delete,
‫yang telah kami gunakan, yang melakukan apa yang Anda pikirkan juga.
‫Yang menyenangkan di sini adalah itu semacam jalan tengah, benar.
‫Ini memaksa Anda untuk menggunakan YAML sehingga Anda telah mendokumentasikan apa yang Anda
‫lakukan, dan Anda memiliki catatan perubahan ini jika Anda menggunakan
‫sesuatu seperti git.
‫Semoga Anda menggunakan git.
‫Namun, manfaatnya di sana adalah untuk
‫kita manusia, kita menggunakan buat, atau
‫ganti, atau hapus. Jadi, ini memberi kita kata
‫kerja eksplisit ini untuk digunakan sehingga kita tahu kita tidak sengaja
‫menghapus sesuatu ketika kita menggunakan perintah create.
‫Dan kita tahu kita tidak sengaja menghapus sesuatu ketika
‫kita menggunakan perintah ganti.
‫Jadi itu membantu, benar.
‫Itu jalan tengah yang bagus saat Anda
‫membasahi kaki dalam spesifikasi YAML yang perlu
‫Anda gunakan saat Anda mendapatkan model objek deklaratif
‫yang lengkap. Itulah yang saya bicarakan sebelumnya.
‫Di situlah Anda hanya menggunakan YAML dan Anda hanya
‫menggunakan perintah apply.
‫Ada perintah lain untuk membantu Anda menerapkannya, seperti diff,
‫yang akan menunjukkan kepada Anda perubahan yang akan Anda ambil.
‫Tapi, melamar hanya mengedit YAML,
‫menjalankan melamar.
‫Edit lagi YAML, jalankan aplikasinya.
‫Ini mirip dengan Swarm tempat kami memiliki tumpukan Swarm.
‫Jika Anda ingat, ada perintah penempatan docker
‫stack dan untuk memperbaruinya, Anda menggunakan perintah yang
‫sama berulang-ulang.
‫Itu gaya yang sama di sini dengan objek
‫deklaratif penuh mereka. Sangat menyenangkan bahwa mereka memiliki
‫dokumentasi, dan Anda akan melihat ini di tautan sumber daya
‫untuk kuliah ini, halaman yang sangat rinci pada ketiga jenis yang berbeda ini.
‫Saya mendorong Anda untuk memeriksanya.
‫Aturan sebenarnya yang akan saya berikan
‫untuk semua ini, bahkan jika Anda membaca halaman sumber daya
‫tentang hal itu, adalah untuk tidak mencampur tiga pendekatan.
‫Lebih penting bahwa Anda tidak mencampur ketiganya saat Anda
‫memiliki ketergantungan produksi yang sebenarnya.
‫Dalam produksi, saya benar-benar akan
‫menganjurkan Anda mencoba untuk tetap, sedini
‫mungkin dalam model jatuh tempo Anda, dengan
‫model deklaratif lengkap menggunakan file YAML dengan
‫perintah apply.
‫Semakin cepat Anda merasa nyaman dengan itu, semakin
‫cepat Anda terbiasa mendokumentasikannya di YAML dan menyimpannya di git-commit
‫setiap kali Anda mengubahnya, proses itu
‫akan sangat bermanfaat bagi Anda di kemudian hari.
‫Ketika ada yang ingin melihat perubahan yang Anda miliki,
‫mereka dapat melihat git-log. Sebagian besar dari kita mungkin melakukan
‫sesuatu di git hari ini, jadi membuat git repo yang lain
‫hanya untuk menyimpan YAML ini tidak akan banyak
‫usaha untuk Anda, kan. Bahkan jika Anda hanya
‫melakukan git secara lokal di mesin Anda, git secara lokal
‫dapat membantu Anda melihat riwayat perubahan yang telah Anda lakukan pada
‫YAML ini sehingga ketika Anda lupa dalam enam bulan apa yang
‫Anda ubah tiga bulan lalu, Anda bisa pergi kembali dan lihat dan lihat
‫apa yang Anda lakukan di sana.
‫Itu benar-benar akan menghemat banyak waktu.
‫Aturan yang paling penting adalah jangan campur pendekatan.
‫Jika Anda membuat sesuatu dengan jalankan, nanti akan
‫lebih sulit untuk menggunakan yang berlaku untuk mengelola sumber daya itu.
‫Ada beberapa trik perdagangan yang bisa Anda lakukan
‫dengan beberapa perintah ini untuk mencoba mengedit objek nanti
‫tanpa mengacaukannya.
‫Tetapi sungguh, jika Anda akan melakukan produksi,
‫Anda mungkin tidak harus memulai dengan menjalankan perintah-perintah
‫di server produksi Anda. Anda mungkin harus berpikir jangka panjang
‫dan tetap dengan YAML. Empat tips saya di sini
‫adalah mempelajari baris perintah seperti yang Anda lakukan.
‫Pelajari baris perintah penting itu sehingga Anda bisa
‫mengoperasikannya secara lokal. Dan Anda akan membutuhkan
‫perintah-perintah itu terkadang untuk pemecahan masalah, dan pengujian, dan server juga.
‫Maka secepat yang Anda bisa untuk bersiap-siap untuk produksi
‫pertama Anda Kubernetes adalah mempelajari perintah apply, perintah diff, spesifikasi
‫YAML untuk semua jenis
‫sumber daya yang akan Anda gunakan.
‫Kemudian menyimpannya di git seperti yang saya katakan.
‫Bahkan jika itu hanya git lokal atau repositori git di suatu tempat yang
‫dapat digunakan tim Anda.
‫Ingat, metode ini mengedit YAML,
‫menyimpan perubahan di git, lalu menerapkannya dengan
‫kubectl berlaku, lalu menyimpannya lagi, dan menyimpan perubahan
‫di git.
‫Proses ini akan membawa Anda ke jalan otomatisasi DevOps
‫dan ke git-ops yang saya sebutkan sebelumnya,
‫yang saya pikir di mana beberapa alat
‫ini mulai pergi. Di mana kita git centric.
‫Kami sedang melakukan perubahan dalam git repo seperti halnya coders perangkat
‫lunak lakukan ..
‫Kami melakukan hal yang sama dengan alur kerja DevOps ini.
‫Kami semacam mengadopsi cara mereka melakukan pekerjaan perubahan mereka
‫dalam tim untuk operasi dan alat kami sendiri.