‫Biarkan saya memberi tahu Anda tentang dry run dan diff, yang
‫merupakan hal baru.
‫Beberapa versi terakhir Kubernet dimulai dengan 1. 13 memiliki
‫opsi baru ini yang memungkinkan kita melihat
‫apa yang akan kita ubah sebelum mengubahnya.
‫Kami telah melihat itu sebelumnya.
‫Saya telah menunjukkan kepada Anda beberapa contoh sebelumnya dalam kursus.
‫Tapi, metode menggunakannya dengan perintah
‫apply baru dan lebih
‫baik. Apa yang kami miliki
‫di masa lalu adalah kami memiliki dry run, tetapi
‫hanya pada klien. Klien tidak benar-benar berbicara dengan
‫server untuk mengatakan hei, apakah sumber daya ini sudah ada di sana?
‫Apakah saya perlu membuat ulang, atau akan diperbarui atau apa yang
‫akan terjadi? Baik.
‫Itu tidak terjadi sebelumnya.
‫Sekarang ada opsi server run yang akan
‫mengirim YAML kami ke server dan membandingkan, mencari tahu
‫apa yang sebenarnya perlu terjadi dan kemudian melaporkan
‫kembali ke baris perintah apa yang
‫akan berubah. Mari kita lihat itu dalam aksi.
‫Saya berada di direktori YAML K8s seperti yang saya bahas sebelumnya
‫dalam sebuah kuliah, jika Anda berada di repo Docker Mastery dan Anda
‫tidak memiliki direktori ini, maka
‫Anda perlu melakukan git-pull untuk mendapatkan pembaruan terbaru.
‫Ini adalah file yang telah kita lihat
‫di kuliah sebelumnya, aplikasi. yml. Ini adalah layanan,
‫plus penyebaran, dalam satu file.
‫Secara teknis, dua sumber daya dibuat dengan
‫satu perintah berlaku dan semuanya terkait.
‫Layanan menggunakan pemilih, yang belum
‫kita bicarakan. Selektor adalah bagaimana satu objek
‫menemukan sumber daya yang ingin diajak bicara atau melakukan
‫sesuatu dengannya.
‫Suatu layanan perlu berbicara dengan pod, sehingga ia perlu menemukan
‫cara untuk mendapatkannya.
‫Ini menggunakan penyeleksi sebagai dasarnya
‫pencocokan pola untuk mencocokkan label tombol dan
‫nilai di sana. Jika saya melakukan dry run
‫tradisional di sini, maka yang akan dilakukan adalah klien akan melihat berlaku
‫dan berkata, ya, saya akan membuat objek ini.
‫Baiklah. Itu akan selalu kembali dan mengatakan dibuat.
‫Itu karena penerapannya tidak terlalu
‫spesifik. Jika Anda menggunakan pembaruan,
‫atau perintah buat, atau perintah hapus, yang
‫lagi-lagi saya rasa bukan alur kerja berbasis DevOps.
‫Perintah-perintah itu hanya akan melakukan lari kering dan Anda tahu
‫pembaruan yang akan mengatakan ya,
‫mereka berdua akan diperbarui. Tapi, itu tidak benar-benar tahu di
‫cluster Anda, kan. Belum berbicara ke server untuk mencari tahu.
‫Kami ingin mencoba menjalankan server yang dijalankan secara
‫default pada apa pun 1. 13 dan lebih baru.
‫Ketika saya melakukan itu, ia kemudian akan berbicara dengan server dan memberi
‫saya respons yang tepat.
‫Ayo maju dan buat ini.
‫Aku akan melepas run server.
‫Ini akan menciptakan dua sumber daya, penyebaran
‫dan layanan.
‫Sekarang, jika saya menekan panah ke atas dan kembali ke server kering,
‫Anda akan melihat bahwa itu mengatakan tidak berubah untuk keduanya.
‫Itu tidak memberi tahu saya apa yang berubah atau jika
‫ada sesuatu yang akan mengubah apa
‫yang akan terjadi. Ini hanya memberitahu saya bahwa
‫sumber daya akan diubah atau tidak diubah. Ini semacam beralih, ya atau tidak.
‫Bagaimana dengan mendapatkan perbedaan aktual antara apa yang ingin
‫kita berikan kepada server dan apa status
‫terkini dari sumber daya kita.
‫Itu adalah perintah diff kubectl.
‫Jika saya cukup memberikannya alih-alih menerapkan, itu
‫akan membandingkan YAML yang saya miliki
‫dengan spesifikasi yang ada di server yang
‫sekarang berjalan. status itu kembali, dan itu akan
‫membuat perbedaan. Ayo lakukan itu.
‫Itu tidak akan mengatakan apa-apa karena tidak ada perbedaan.
‫Tapi bagaimana jika kita mengganti YAML?
‫Bagaimana jika saya mengubah replika menjadi dua?
‫Lalu saya menambahkan label di metadata dan saya akan memberikannya
‫sesuatu seperti ... sesuatu seperti.
‫Server dmz.
‫Saya mengada-ada. Tidak masalah.
‫Lalu kami memiliki replika dua.
‫Jika saya melakukan diff yang sama, ia kembali dengan plus
‫dan minusnya.
‫Jika Anda terbiasa membaca diff, ini masuk
‫akal bagi Anda. Jika Anda tidak terbiasa dengan
‫diff, minus berarti garis itu akan hilang.
‫Maka garis-garis ini akan ditambahkan.
‫Kemudian di sini, ini menunjukkan kepada Anda baris apa dan
‫karakter apa di baris yang sedang
‫dihapus ini.
‫Ini sedang ditambahkan.
‫Itu menjaga format YAML, yang bagus.
‫Ini memberi tahu kami bahwa banyak perubahan sedang terjadi.
‫Bagus. Tentu saja, ini tidak benar-benar melakukan
‫sesuatu seperti burung kenari, atau uji penyebaran atau apa pun.
‫Itu tidak berusaha melakukan hal itu dan kemudian
‫melihat apa hasilnya. Ini benar-benar hanya melihat spesifikasi
‫yang ada di catatan, dan spesifikasi yang kami miliki di
‫disk kami. Periksa info
‫lebih lanjut tentang itu di tautan sumber daya.
‫Ini adalah artikel blog dari tim Kubernetes tentang
‫masa depan ini dan bagaimana mereka akan bermain saat
‫mereka keluar dari beta. Ingat, fitur-fitur ini sekarang adalah beta,
‫setidaknya dalam 1. 15 mereka.
‫Semoga dengan itu, Anda dapat membuat alur kerja
‫Anda sendiri untuk membuat YAML
‫dari awal, Mengelola spesifikasi dalam YAML tersebut, dan kemudian menggunakan
‫perintah apply berulang-ulang untuk membuat perubahan Anda.
‫Itu infrastruktur yang jauh lebih ramah DevOps sebagai
‫jenis kode cara melakukannya.
‫Semua yang Anda lakukan didokumentasikan, semoga di Git.
‫Jadi, semoga Anda membuat git-commit untuk setiap perubahan yang Anda
‫lakukan di YAML Anda sebelum menempatkannya ke server.
‫Kemudian Anda memiliki dokumentasi yang bagus di Git, serta
‫dokumentasi ketika Anda melakukan sesuatu seperti diff untuk melihat apa
‫yang Anda miliki versus apa yang sebenarnya berjalan.