TL; DR
จะจัดขึ้นที่กรุงมอสโกในวันที่ 30 มกราคม - 1 กุมภาพันธ์
เราจะวิเคราะห์เครื่องมือ DevOps ในทางปฏิบัติอีกครั้ง
รายละเอียดและโปรแกรมอยู่ระหว่างการตัด
SRE ถูกลบออกจากโปรแกรมเนื่องจากเรากำลังเตรียม Slurm SRE แยกต่างหากร่วมกับ Ivan Kruglov ประกาศจะมาทีหลังครับ
ขอขอบคุณ Selectel ผู้สนับสนุนของเราตั้งแต่ Slurm ครั้งแรก!
เกี่ยวกับปรัชญา ความสงสัย และความสำเร็จที่ไม่คาดคิด
ฉันเข้าร่วม DevOpsConf ในมอสโกเมื่อปลายเดือนกันยายน
สรุปสิ่งที่ได้ยินมา:
— DevOps เป็นสิ่งจำเป็นสำหรับโปรเจ็กต์ส่วนใหญ่ทุกขนาด
— DevOps ก็คือวัฒนธรรม เช่นเดียวกับวัฒนธรรมใดๆ ก็ตาม มันจะต้องมาจากภายในบริษัท คุณไม่สามารถจ้างวิศวกร DevOps และฝันว่าเขาจะปรับปรุงกระบวนการต่างๆ
— ในตอนท้ายของรายการสิ่งที่จำเป็นสำหรับการเปลี่ยนแปลง DevOps คือเทคโนโลยี นั่นคือเครื่องมือ DevOps ที่เราสอน
ฉันรู้ว่าเราคิดถูกที่จะไม่รวมปรัชญาและวัฒนธรรม DevOps ไว้ในหลักสูตร เนื่องจากไม่สามารถสอนอย่างเป็นระบบได้ ใครต้องการก็จะอ่านในหนังสือ หรือเขาจะได้พบกับโค้ชสุดเจ๋งที่จะโน้มน้าวทุกคนด้วยความสามารถพิเศษและอำนาจของเขา
โดยส่วนตัวแล้ว ฉันเป็นผู้สนับสนุน “การเคลื่อนไหวจากเบื้องล่าง” การนำวัฒนธรรมไปใช้แบบกองโจรผ่านเครื่องมือมาโดยตลอด บางอย่างเหมือนกับที่อธิบายไว้ใน The Phoenix Project หากเรามีการทำงานเป็นทีมโดยตั้งค่า Git อย่างถูกต้อง เราก็จะค่อย ๆ เสริมด้วยกฎระเบียบ แล้วมันจะกลายเป็นคุณค่า
และเช่นเดียวกัน ตอนที่เรากำลังเตรียม DevOps Slurm ซึ่งเรากำลังพูดถึงเครื่องมือโดยเฉพาะ ฉันกลัวปฏิกิริยาของผู้เข้าร่วม: “คุณพูดสิ่งที่ยอดเยี่ยมมาก น่าเสียดายที่ฉันไม่สามารถนำไปใช้ได้” มีความสงสัยมากจนเรายุติการทำซ้ำโปรแกรมทันที
อย่างไรก็ตาม ผู้เข้าร่วมส่วนใหญ่ตอบในแบบสำรวจว่าความรู้ที่ได้รับสามารถนำไปใช้ในทางปฏิบัติได้ และพวกเขาจะนำไปปฏิบัติบางอย่างในประเทศของตนเองในอนาคตอันใกล้นี้ ในขณะเดียวกัน ทุกสิ่งที่เราอธิบายก็รวมอยู่ในรายการสิ่งที่มีประโยชน์: Git, Ansible, CI/CD และ SRE
เป็นเรื่องที่ควรค่าแก่การจดจำว่าในตอนแรกพวกเขายังพูดถึง Slurm Kubernetes ด้วยว่าเป็นไปไม่ได้ที่จะอธิบาย k3 ใน 8 วัน
กับ Ivan Kruglov ซึ่งเป็นผู้นำหัวข้อ SRE เราได้ตกลงกันในโครงการแยกต่างหาก ขณะนี้เรากำลังหารือเกี่ยวกับรายละเอียด ฉันจะประกาศให้ทราบเร็วๆ นี้
จะเกิดอะไรขึ้นที่ Slurm DevOps?
โครงการ
หัวข้อ #1: การทำงานเป็นทีมด้วย Git
- คำสั่งพื้นฐาน git init, commit, add, diff, log, status, pull, push
- Git Flow, สาขาและแท็ก, ผสานกลยุทธ์
- การทำงานกับตัวแทนระยะไกลหลายคน
- การไหลของ GitHub
- ส้อม,รีโมท,ขอดึง
- ความขัดแย้ง การเผยแพร่ อีกครั้งเกี่ยวกับ Gitflow และโฟลว์อื่นๆ ที่เกี่ยวข้องกับทีม
หัวข้อ #2: การทำงานกับแอปพลิเคชันจากมุมมองของการพัฒนา
- การเขียนไมโครเซอร์วิสใน Python
- ตัวแปรสภาพแวดล้อม
- บูรณาการและการทดสอบหน่วย
- การใช้นักเทียบท่าเขียนในการพัฒนา
หัวข้อ #3: CI/CD: ความรู้เบื้องต้นเกี่ยวกับระบบอัตโนมัติ
- ความรู้เบื้องต้นเกี่ยวกับระบบอัตโนมัติ
- เครื่องมือ (ทุบตี, สร้าง, ไล่ระดับ)
- การใช้ git-hooks เพื่อทำให้กระบวนการเป็นอัตโนมัติ
- สายการประกอบของโรงงานและการประยุกต์ในด้านไอที
- ตัวอย่างการสร้างไปป์ไลน์ "ทั่วไป"
- ซอฟต์แวร์สมัยใหม่สำหรับ CI/CD: Drone CI, BitBucket Pipelines, Travis ฯลฯ
หัวข้อ #4: CI/CD: การทำงานกับ Gitlab
- Gitlab CI
- Gitlab Runner ประเภทและแอปพลิเคชัน
- Gitlab CI คุณสมบัติการกำหนดค่า แนวทางปฏิบัติที่ดีที่สุด
- ขั้นตอน Gitlab CI
- ตัวแปร Gitlab CI
- สร้าง ทดสอบ ปรับใช้
- การควบคุมการดำเนินการและข้อจำกัด: เท่านั้น เมื่อใด
- การทำงานกับสิ่งประดิษฐ์
- เทมเพลตภายใน .gitlab-ci.yml ซึ่งนำการดำเนินการกลับมาใช้ใหม่ในส่วนต่างๆ ของไปป์ไลน์
- รวม - ส่วนต่างๆ
- การจัดการแบบรวมศูนย์ของ gitlab-ci.yml (ไฟล์เดียวและพุชไปยังที่เก็บข้อมูลอื่นโดยอัตโนมัติ)
หัวข้อ #5: โครงสร้างพื้นฐานเป็นรหัส
- IaC: การเข้าถึงโครงสร้างพื้นฐานเป็นโค้ด
- ผู้ให้บริการคลาวด์ในฐานะผู้ให้บริการโครงสร้างพื้นฐาน
- เครื่องมือเริ่มต้นระบบ การสร้างอิมเมจ (แพ็คเกอร์)
- IaC โดยใช้ Terraform เป็นตัวอย่าง
- พื้นที่จัดเก็บข้อมูลการกำหนดค่า การทำงานร่วมกัน ระบบอัตโนมัติของแอปพลิเคชัน
- แบบฝึกหัดการสร้าง Playbooks แบบ Ansible
- Idempotency การประกาศ
- IaC โดยใช้ Ansible เป็นตัวอย่าง
หัวข้อ #6: การทดสอบโครงสร้างพื้นฐาน
- การทดสอบและการบูรณาการอย่างต่อเนื่องกับ Molecule และ Gitlab CI
- การใช้คนเร่ร่อน
หัวข้อ #7: การตรวจสอบโครงสร้างพื้นฐานด้วย Prometheus
- เหตุใดจึงต้องมีการตรวจสอบ?
- ประเภทของการตรวจสอบ
- การแจ้งเตือนในระบบติดตาม
- วิธีสร้างระบบติดตามสุขภาพที่ดี
- การแจ้งเตือนที่มนุษย์สามารถอ่านได้สำหรับทุกคน
- ตรวจสุขภาพ: สิ่งที่คุณควรใส่ใจ
- ระบบอัตโนมัติตามข้อมูลการตรวจสอบ
หัวข้อ #8: การบันทึกแอปพลิเคชันด้วย ELK
- แนวทางปฏิบัติในการบันทึกที่ดีที่สุด
- สแต็ค ELK
หัวข้อ #9: ระบบโครงสร้างพื้นฐานอัตโนมัติด้วย ChatOps
- DevOps และ ChatOps
- ChatOps: จุดแข็ง
- ความหย่อนและทางเลือก
- บอทสำหรับ ChatOps
- Hubot และทางเลือกอื่น
- ความปลอดภัย
- แนวทางปฏิบัติที่ดีที่สุดและเลวร้ายที่สุด
สถานที่: กรุงมอสโก ห้องประชุมของโรงแรมเซวาสโทพอล
วันที่: ตั้งแต่วันที่ 30 มกราคมถึง 1 กุมภาพันธ์ 3 วันแห่งการทำงานหนัก
ที่มา: will.com