โครงการรูปแบบภาพ OCI สร้างและรักษาข้อกำหนดเฉพาะรูปแบบภาพคอนเทนเนอร์การจัดส่งซอฟต์แวร์ (รูปแบบภาพ OCI)
ข้อมูลจำเพาะสามารถพบได้ที่นี่
พื้นที่เก็บข้อมูลนี้ยังมีประเภท Go, เครื่องมือตรวจสอบความถูกต้องภายใน Blob และ JSON Schema ประเภท Go และการตรวจสอบความถูกต้องควรเข้ากันได้กับ Go รุ่นปัจจุบัน ไม่รองรับ Go รุ่นก่อนหน้า
เอกสารเพิ่มเติมเกี่ยวกับวิธีการทำงานของกลุ่มนี้:
โปรเจ็กต์พันธมิตรรูปแบบภาพ OCI คือโปรเจ็กต์ OCI Runtime Spec ข้อมูลจำเพาะรันไทม์สรุปวิธีการรัน "บันเดิลระบบไฟล์" ที่ถูกแตกแพ็กบนดิสก์ ในระดับสูง การใช้งาน OCI จะดาวน์โหลดอิมเมจ OCI จากนั้นแตกอิมเมจนั้นลงในบันเดิลระบบไฟล์ OCI Runtime ณ จุดนี้ OCI Runtime Bundle จะถูกรันโดย OCI Runtime
เวิร์กโฟลว์ทั้งหมดนี้รองรับ UX ที่ผู้ใช้คาดหวังจากกลไกคอนเทนเนอร์ เช่น Docker และ rkt โดยหลักแล้วคือความสามารถในการเรียกใช้อิมเมจโดยไม่มีข้อโต้แย้งเพิ่มเติม:
เพื่อรองรับ UX นี้ รูปแบบรูปภาพ OCI จึงมีข้อมูลที่เพียงพอในการเปิดใช้แอปพลิเคชันบนแพลตฟอร์มเป้าหมาย (เช่น คำสั่ง อาร์กิวเมนต์ ตัวแปรสภาพแวดล้อม ฯลฯ)
โครงการข้อมูลจำเพาะการจัดจำหน่ายของ OCI กำหนดโปรโตคอล API เพื่ออำนวยความสะดวกและสร้างมาตรฐานในการเผยแพร่เนื้อหา API นี้รองรับการพุชและดึงอิมเมจ OCI ไปยังรีจีสทรีที่สอดคล้องกับ OCI
ถาม: จะเกิดอะไรขึ้นกับรูปแบบ AppC หรือ Docker Image
ตอบ: รูปแบบที่มีอยู่ยังคงเป็นพื้นที่พิสูจน์เทคโนโลยีต่อไปได้ ตามความจำเป็น โครงการรูปแบบภาพ OCI มุ่งมั่นที่จะจัดเตรียมข้อกำหนดแบบเปิดที่เชื่อถือได้ ซึ่งสามารถแชร์ระหว่างเครื่องมือต่างๆ และพัฒนาความเข้ากันได้มานานหลายปีหรือหลายทศวรรษ ตามรูปแบบ deb และ rpm
ค้นหาคำถามที่พบบ่อยเพิ่มเติมได้จากไซต์ OCI
เหตุการณ์สำคัญของ GitHub กำหนดเส้นทางสู่การปรับปรุงในอนาคต
การพัฒนาเกิดขึ้นบน GitHub สำหรับข้อมูลจำเพาะ ปัญหาจะถูกใช้สำหรับจุดบกพร่องและรายการที่ดำเนินการได้ และการสนทนาที่ยาวนานอาจเกิดขึ้นได้ในรายชื่ออีเมล
ข้อมูลจำเพาะและรหัสได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 ที่พบในไฟล์ LICENSE
ของพื้นที่เก็บข้อมูลนี้
โครงการยินดีส่งผลงาน แต่โปรดแจ้งให้ทุกคนทราบว่าคุณกำลังทำอะไรอยู่
ก่อนที่จะดำเนินการเปลี่ยนแปลงเล็กน้อยกับข้อกำหนดนี้ ให้ส่งอีเมลไปยังรายชื่ออีเมลเพื่อหารือเกี่ยวกับสิ่งที่คุณวางแผนจะทำ สิ่งนี้ทำให้ทุกคนมีโอกาสตรวจสอบการออกแบบ ช่วยป้องกันการทำงานซ้ำซ้อน และทำให้แน่ใจว่าแนวคิดนั้นเหมาะสม นอกจากนี้ยังรับประกันว่าการออกแบบนั้นดีก่อนที่จะเขียนโค้ด คำขอดึง GitHub ไม่ใช่ที่สำหรับการสนทนาในระดับสูง
การพิมพ์ผิดและข้อผิดพลาดทางไวยากรณ์อาจตรงไปที่คำขอดึงข้อมูล หากมีข้อสงสัย ให้เริ่มที่รายชื่อผู้รับจดหมาย
โปรดดูที่ README ที่เก็บข้อมูลขององค์กร OCI เพื่อดูข้อมูลล่าสุดเกี่ยวกับกำหนดการประชุมผู้สนับสนุนและผู้ดูแลของ OCI คุณยังดูลิงก์ไปยังวาระการประชุมและรายงานการประชุมสำหรับการประชุมครั้งก่อนๆ ทั้งหมดได้ด้วย
คุณสามารถสมัครและเข้าร่วมรายชื่ออีเมลใน Google Groups
เพื่อให้สอดคล้องกันตลอดทั้งไฟล์ Markdown ในข้อกำหนด Open Container ไฟล์ทั้งหมดควรได้รับการจัดรูปแบบหนึ่งประโยคต่อบรรทัด วิธีนี้ช่วยแก้ไขสองสิ่ง: ทำให้ความแตกต่างง่ายขึ้นด้วยคอมไพล์ และแก้ไขการต่อสู้เกี่ยวกับความยาวของการตัดบรรทัด ตัวอย่างเช่น ย่อหน้านี้จะมีการขยายสามบรรทัดในแหล่งที่มาของ Markdown
การลงชื่อออกเป็นบรรทัดง่ายๆ ที่ส่วนท้ายของคำอธิบายสำหรับแพตช์ ซึ่งรับรองว่าคุณเป็นผู้เขียนหรือมีสิทธิ์ในการส่งต่อเป็นแพตช์โอเพ่นซอร์ส กฎค่อนข้างง่าย: หากคุณสามารถรับรองด้านล่าง (จาก Developercertificate.org):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
660 York Street, Suite 102,
San Francisco, CA 94110 USA
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
จากนั้นคุณเพียงเพิ่มบรรทัดลงในข้อความคอมไพล์ทุกข้อความ:
Signed-off-by: Joe Smith <[email protected]>
ใช้ชื่อจริงของคุณ (ขออภัย ห้ามใช้นามแฝงหรือมีส่วนร่วมโดยไม่ระบุชื่อ)
คุณสามารถเพิ่มเครื่องหมายปิดได้เมื่อสร้างคอมมิตผ่าน git commit -s
การดูแลบ้านแบบเรียบง่ายเพื่อประวัติคอมไพล์ที่สะอาด อ่านเพิ่มเติมเกี่ยวกับวิธีการเขียนข้อความ Git Commit หรือส่วนการสนทนาของ git-commit(1)