‫ในวิดีโอที่แล้ว ฉันพูดถึง Imperative vs.
‫ประกาศ เราได้พูดคุยเกี่ยวกับข้อมูลเฉพาะใน
‫Kubernetes อย่างใดอย่างหนึ่ง
‫จริงๆ แล้ว เมื่อคุณดูเอกสารของ Kubernetess
‫มันมีลักษณะที่แตกต่างกันสามแบบ
‫มีความแตกต่างกันเล็กน้อย แต่จริงๆ แล้วพวกมันอยู่ในสเปกตรัมของความจำเป็นในด้านหนึ่งและด้านอื่น
‫ๆ ที่ประกาศในอีกด้านหนึ่ง
‫ถ้าอย่างนั้นตัวเลือกเล็ก ๆ น้อย ๆ ตรงกลางถ้าคุณเลือกใช้
‫ในหลักสูตรนี้
‫ฉันได้สอนคำสั่ง CLI ที่เข้มงวดและจำเป็นแก่คุณ
‫ซึ่งรวมถึงการวิ่ง เปิดเผย
‫บางทีเราอาจมีขนาด
‫เราไม่ได้ครอบคลุมการแก้ไขแต่ทำสิ่งที่คุณคิดอย่างแน่นอน
‫มันแก้ไขทรัพยากรในเวลาจริง
‫หรือสร้างการปรับใช้ซึ่งเป็นวิธีใหม่ในการรัน
‫สิ่งเหล่านี้ดีที่สุดสำหรับการเรียนรู้วิธีการทำงานของสิ่งต่าง
‫ๆ เรียนรู้ประเภททรัพยากรและสิ่งที่พวกเขาทำ ตลอดจนโครงการส่วนตัวและการตั้งค่าเล็กๆ
‫น้อยๆ ซึ่งคุณอาจเป็นผู้รับผิดชอบเพียงคนเดียว
‫คุณไม่ได้พยายามทำให้เป็นอัตโนมัติ
‫คุณไม่ได้พยายามสร้างเวิร์กโฟลว์การผลิตเต็มรูปแบบและ
‫CICD ใช่ไหม
‫ที่ดีสำหรับสิ่งเหล่านั้น
‫มีจุดกลางที่ดีที่ Kubernetes เสนอคำสั่ง
‫create ให้คุณ ซึ่งคุณสามารถใช้คำสั่ง create
‫ด้วยตัวเอง แต่คุณยังสามารถใช้กับไฟล์
‫YAML ได้อีกด้วย
‫คุณสามารถใช้ create -f ได้ และคุณสามารถกำหนดหนึ่งในสเปกเหล่านั้นได้เหมือนที่เราเห็นก่อนหน้านี้
‫คุณสามารถระบุข้อมูลจำเพาะและจะสร้างวัตถุใดๆ ที่คุณมีอยู่ในนั้น
‫คุณสามารถมีหลายวัตถุในไฟล์นั้น
‫คุณสามารถมีการปรับใช้
‫และบริการในนั้น
‫บางทีคุณอาจต้องการพื้นที่เก็บข้อมูล การตั้งค่าเครือข่าย
‫หรืออะไรก็ได้ คุณสามารถมีไฟล์ที่ดีทั้งหมดนั้นได้
‫จากนั้น หากคุณต้องการแทนที่สิ่งใดในนั้น
‫คุณสามารถแก้ไขไฟล์แล้วใช้คำสั่งแทนที่ ซึ่งเรายังไม่ครอบคลุม
‫แต่ไฟล์จะทำในสิ่งที่คุณคิดว่าทำ
‫จากนั้นมีคำสั่ง
‫delete ซึ่งเราใช้ ซึ่งทำในสิ่งที่คุณคิดว่าทำเช่นกัน
‫สิ่งที่ดีที่นี่คือมันเป็นพื้นกลางใช่ไหม
‫มันบังคับให้คุณใช้ YAML เพื่อที่คุณจะได้บันทึกสิ่งที่คุณกำลังทำ
‫และคุณมีบันทึกการเปลี่ยนแปลงนี้หากคุณใช้บางอย่างเช่น
‫git
‫หวังว่าคุณจะใช้ git
‫ประโยชน์ที่ได้รับนั้นมีไว้สำหรับมนุษย์อย่างเรา
‫เรากำลังใช้การสร้าง การแทนที่ หรือการลบ
‫ดังนั้นเราจึงใช้กริยาที่ชัดเจนนี้เพื่อให้เรารู้ว่าเราไม่ได้ลบบางสิ่งโดยไม่ได้ตั้งใจเมื่อเราใช้คำสั่ง
‫create
‫และเรารู้ว่าเราไม่ได้ลบบางสิ่งโดยไม่ได้ตั้งใจเมื่อเราใช้คำสั่งแทนที่
‫นั่นช่วยได้ใช่มั้ย
‫นั่นเป็นพื้นกลางที่ดีและเมื่อคุณทำให้เท้าเปียกในข้อกำหนด
‫YAML ที่คุณจะต้องใช้เมื่อคุณไปถึงโมเดลวัตถุที่สมบูรณ์และเปิดเผย
‫นั่นคือสิ่งที่ฉันพูดถึงก่อนหน้านี้
‫นั่นคือที่ที่คุณใช้เพียง YAML และคุณใช้คำสั่ง
‫Apply เท่านั้น
‫มีคำสั่งอื่นๆ ที่จะช่วยคุณในการใช้งาน เช่น diff
‫ซึ่งจะแสดงการเปลี่ยนแปลงที่คุณกำลังจะทำ
‫แต่การนำไปใช้เป็นเพียงการแก้ไข YAML โดยเรียกใช้แอปพลิเคชัน
‫แก้ไข YAML เพิ่มเติม เรียกใช้ Apply
‫ซึ่งคล้ายกับ Swarm ที่เรามีสแต็ค Swarm
‫หากคุณจำได้ มีคำสั่งปรับใช้ docker stack
‫และเพื่อที่จะอัปเดต คุณใช้คำสั่งเดียวกันซ้ำแล้วซ้ำอีก
‫นั่นเป็นสไตล์เดียวกันกับออบเจกต์ประกาศแบบเต็ม
‫เป็นเรื่องดีที่พวกเขามีเอกสารประกอบ
‫และคุณจะเห็นสิ่งนี้ในลิงก์แหล่งข้อมูลสำหรับการบรรยายนี้ ซึ่งเป็นหน้าที่มีรายละเอียดมากเกี่ยวกับสามประเภทที่แตกต่างกันนี้
‫ฉันแนะนำให้คุณลองดู
‫กฎที่แท้จริงที่ฉันจะมอบให้กับสิ่งทั้งหมดนี้
‫แม้ว่าคุณจะไปอ่านหน้าแหล่งข้อมูลเกี่ยวกับเรื่องนี้
‫ก็คืออย่าผสมผสานสามวิธีเข้าด้วยกัน
‫สำคัญกว่าที่คุณไม่ต้องผสมสามสิ่งนี้เมื่อคุณมีการพึ่งพาการผลิตจริง
‫ในการผลิต ฉันจะสนับสนุนคุณจริงๆ
‫ที่พยายามจะยึดมั่นในโมเดลแห่งวุฒิภาวะของคุณให้เร็วที่สุด
‫โดยใช้โมเดลการประกาศแบบเต็มโดยใช้ไฟล์
‫YAML พร้อมคำสั่ง Apply
‫ยิ่งคุณคุ้นเคยกับสิ่งนั้นได้เร็วเท่าไหร่
‫คุณก็จะคุ้นเคยกับการบันทึกใน YAML และบันทึกใน git-commit
‫ทุกครั้งที่คุณเปลี่ยนแปลงได้เร็วยิ่งขึ้น กระบวนการนั้นจะเป็นประโยชน์กับคุณจริงๆ ในภายหลัง
‫เมื่อใครก็ตามต้องการเห็นการเปลี่ยนแปลงของคุณ ก็สามารถเข้าไปดูที่
‫git-log ได้ พวกเราส่วนใหญ่อาจกำลังทำบางสิ่งใน
‫git ในวันนี้ ดังนั้นการสร้าง git repo ใหม่เพียงเพื่อจัดเก็บ YAML
‫เหล่านี้จะไม่เป็นความพยายามมากสำหรับคุณใช่ไหม
‫แม้ว่าคุณจะเพิ่งทำ
‫git บนเครื่องของคุณ แต่ git locally สามารถช่วยให้คุณเห็นประวัติการเปลี่ยนแปลงที่คุณได้ทำกับ YAML เหล่านี้ ดังนั้นเมื่อคุณลืมสิ่งที่คุณเปลี่ยนแปลงไปเมื่อสามเดือนที่แล้วไปเมื่อสามเดือนที่แล้ว
‫กลับไปดูและดูว่าคุณกำลังทำอะไรอยู่ที่นั่น
‫นั่นจะช่วยคุณประหยัดเวลาได้มาก
‫กฎที่สำคัญที่สุดคืออย่าผสมผสานวิธีการ
‫หากคุณสร้างบางสิ่งด้วยการวิ่ง มันจะยากขึ้นในภายหลังเพื่อใช้
‫Apply เพื่อจัดการทรัพยากรนั้น
‫มีเคล็ดลับเล็ก ๆ น้อย ๆ ในการแลกเปลี่ยนที่คุณสามารถใช้คำสั่งเหล่านี้เพื่อพยายามแก้ไขวัตถุในภายหลังโดยไม่ทำให้เสียหาย
‫แต่จริงๆ แล้ว หากคุณกำลังจะทำการผลิต คุณไม่ควรเริ่มต้นด้วยคำสั่งเรียกใช้เหล่านั้นบนเซิร์ฟเวอร์ที่ใช้งานจริงของคุณ
‫คุณควรคิดในระยะยาวและยึดติดกับ
‫YAML เคล็ดลับสี่ข้อของฉันที่นี่คือการเรียนรู้บรรทัดคำสั่งเหมือนที่คุณทำ
‫เรียนรู้บรรทัดคำสั่งที่จำเป็นเพื่อให้คุณสามารถใช้งานได้ในเครื่อง
‫และคุณจะต้องใช้คำสั่งเหล่านั้นในบางครั้งสำหรับการแก้ไขปัญหา
‫การทดสอบ และเซิร์ฟเวอร์ด้วย
‫จากนั้นให้เร็วที่สุดเพื่อเตรียมพร้อมสำหรับ
‫Kubernetes เวอร์ชันแรกคือการเรียนรู้คำสั่ง
‫Apply คำสั่ง diff ข้อกำหนด YAML สำหรับทรัพยากรทุกประเภทที่คุณจะใช้
‫จากนั้นเก็บไว้ใน git ตามที่ฉันพูด
‫แม้ว่าจะเป็นเพียง git ในเครื่องหรือ git repos ที่ใดที่หนึ่งที่ทีมของคุณสามารถใช้ได้
‫โปรดจำไว้ว่า วิธีการแก้ไข YAML นี้
‫บันทึกการเปลี่ยนแปลงใน git จากนั้นนำไปใช้กับ
‫kubectl จากนั้นบันทึกอีกครั้ง และจัดเก็บการเปลี่ยนแปลงใน
‫git
‫กระบวนการนี้จะนำคุณไปสู่การทำงานอัตโนมัติของ DevOps และ git-ops
‫ที่ฉันได้กล่าวไว้ก่อนหน้านี้ ซึ่งฉันคิดว่าเครื่องมือเหล่านี้บางส่วนเริ่มที่จะไปที่ไหน
‫ที่ที่เราเป็นศูนย์กลางของ git
‫เรากำลังทำการเปลี่ยนแปลงใน git repo เหมือนกับที่โปรแกรมเมอร์ทำ..
‫เราทำสิ่งเดียวกันกับเวิร์กโฟลว์ DevOps นี้
‫เรากำลังใช้วิธีที่พวกเขาทำการเปลี่ยนแปลงในทีมสำหรับการดำเนินงานและเครื่องมือของเราเอง