สคริปต์เริ่มต้น

os.startup_scripts สร้างงาน systemd แบบครั้งเดียวที่มีขอบเขตสำหรับอิมเมจที่ได้ แต่ละรายการประกาศคำสั่งเชลล์ แพ็กเกจที่ต้องใช้ ผู้ใช้ที่รัน และยูนิตสำหรับจัดลำดับ

สคริปต์เริ่มต้นเป็นโค้ดที่รันด้วยสิทธิ์ root เว้นแต่ run_as จะระบุเป็นอย่างอื่น ต้องได้รับการทบทวนแบบเดียวกับสคริปต์ติดตั้งใด ๆ

รูปร่างมาตรฐาน


{
  "os": {
    "startup_scripts": [
      {
        "name": "write-build-marker",
        "description": "Create a local readiness marker after networking is available.",
        "command": "set -Eeuo pipefail\ninstall -d -m 0755 /var/lib/example\nprintf '%s\\n' ready > /var/lib/example/build-ready",
        "packages": [],
        "run_as": "root",
        "after": "network-online.target"
      }
    ]
  }
}

ฟิลด์คือ description และ command ไม่ใช่ฟิลด์ script แบบเก่า run_as และ after ก็ใช้ snake_case เช่นกัน after เป็นสตริงยูนิต systemd หนึ่งค่า ไม่ใช่อาร์เรย์

สคีมายอมรับได้สูงสุด 32 รายการและขนาดคำสั่งที่มีขอบเขต การตรวจความถูกต้องปฏิเสธคำสั่งว่างและไบต์ NUL แต่ไม่ได้ทำให้เนื้อหาเชลล์ปลอดภัยหรือทำซ้ำได้โดยไม่มีผลข้างเคียง

ออกแบบสำหรับการลองใหม่และความล้มเหลวบางส่วน

การบูตอาจถูกขัดจังหวะหลังจากเกิดผลข้างเคียงบางอย่างแล้ว เขียนสคริปต์ให้การเรียกอีกครั้งเสร็จอย่างปลอดภัย หรือจบด้วยสถานะที่ตรวจได้ชัดเจน

รูปแบบที่ดี ได้แก่:

เขียนลงไฟล์ชั่วคราว ตรวจแล้วจึงเปลี่ยนชื่อแบบอะตอมมิก;
ตรวจว่าผู้ใช้ ไดเรกทอรี หรือรายการกำหนดค่ามีอยู่แล้วหรือไม่;
ใช้ install เพื่อระบุเจ้าของและโหมดอย่างชัดเจน;
ใช้ set -Eeuo pipefail และจัดการผลลัพธ์ที่ไม่เป็นศูนย์ที่คาดไว้โดยเจตนา;
ใช้หมดเวลาเครือข่ายที่มีขอบเขตและจำนวนการลองใหม่ที่จำกัด; และ
เขียนเครื่องหมายพร้อมใช้หลังจากขั้นตอนที่จำเป็นทั้งหมดสำเร็จเท่านั้น

อย่าอาศัย sleep เป็นการตรวจความพร้อม ตรวจสอบการพึ่งพาจริง

การดาวน์โหลดภายนอก

หลีกเลี่ยง curl ... | sh หากบูตครั้งแรกต้องดึงอาร์ติแฟกต์:

ใช้ HTTPS พร้อมตรวจใบรับรอง;
ตรึงอาร์ติแฟกต์หรือเวอร์ชันแหล่งที่คาดไว้;
ตรวจไดเจสต์เข้ารหัสหรือลายเซ็นที่อนุมัติก่อนรัน;
ตั้งหมดเวลาเชื่อมต่อและหมดเวลารวม;
ล้มเหลวแบบปิดหากการตรวจไม่ผ่าน; และ
หลีกเลี่ยงการบันทึกข้อมูลรับรองหรือ URL ที่ลงนาม

สำหรับพฤติกรรมออฟไลน์หรือทำซ้ำได้จริง ให้ใส่เนื้อหาที่ผ่านการทบทวนในอิมเมจหรือที่เก็บแพ็กเกจที่อนุมัติ แทนการดาวน์โหลดตอนบูตครั้งแรก

ความลับ

อย่าฝังข้อมูลรับรองแบบข้อความธรรมดาในสูตร คำสั่ง URL หรือเครื่องหมายที่สร้างขึ้น JSON ของสูตรและบันทึกบิลด์เป็นหลักฐานที่เก็บไว้ และผู้ปฏิบัติงานอาจเห็นได้ ใช้กลไกลงทะเบียนตอนปรับใช้หรือส่งความลับที่อนุมัติ และจำกัดข้อมูลรับรองที่ได้ไปยังเป้าหมาย

ตัวตนตอนรัน

เลือกบัญชีบริการที่ไม่มีสิทธิ์พิเศษ หากต้องใช้ root ให้ย่อคำสั่งเหลือขั้นตอนที่มีสิทธิ์น้อยที่สุด และกำหนดเจ้าของไฟล์อย่างชัดเจน ยืนยันว่า run_as ชี้ไปยังบัญชีที่ถูกสร้างก่อนที่ยูนิตจะเริ่ม

การตรวจสอบ

ทดสอบผลลัพธ์ ไม่ใช่เพียงสถานะจบของยูนิต:


{
  "type": "file_contains",
  "description": "The startup unit wrote its readiness marker.",
  "params": {
    "path": "/var/lib/example/build-ready",
    "content": "ready"
  }
}

ทดสอบการบูตครั้งที่สอง การพึ่งพาที่ไม่พร้อมใช้งาน และการกู้จากรันครั้งแรกที่ถูกขัดจังหวะด้วย เมื่อล้มเหลวให้ตรวจ systemctl status และบันทึกของยูนิต