image spec
v1.1.0
Das Projekt „OCI Image Format“ erstellt und pflegt die Spezifikation für das Software-Versandcontainer-Bildformat (OCI Image Format).
Die Spezifikation finden Sie hier.
Dieses Repository bietet außerdem Go-Typen, Intra-Blob-Validierungstools und JSON-Schema. Die Go-Typen und die Validierung sollten mit der aktuellen Go-Version kompatibel sein; Frühere Go-Versionen werden nicht unterstützt.
Zusätzliche Dokumentation zur Funktionsweise dieser Gruppe:
Das OCI Image Format-Partnerprojekt ist das OCI Runtime Spec-Projekt. Die Laufzeitspezifikation beschreibt, wie ein „Dateisystem-Bundle“ ausgeführt wird, das auf der Festplatte entpackt wird. Auf hoher Ebene würde eine OCI-Implementierung ein OCI-Image herunterladen und dieses Image dann in ein OCI-Runtime-Dateisystempaket entpacken. Zu diesem Zeitpunkt würde das OCI Runtime Bundle von einer OCI Runtime ausgeführt werden.
Dieser gesamte Workflow unterstützt die UX, die Benutzer von Container-Engines wie Docker und rkt erwarten: in erster Linie die Möglichkeit, ein Image ohne zusätzliche Argumente auszuführen:
Zur Unterstützung dieser UX enthält das OCI-Bildformat ausreichende Informationen zum Starten der Anwendung auf der Zielplattform (z. B. Befehle, Argumente, Umgebungsvariablen usw.).
Das OCI Distribution Spec Project definiert ein API-Protokoll, um die Verteilung von Inhalten zu erleichtern und zu standardisieren. Diese API bietet Unterstützung für das Pushen und Pullen von OCI-Bildern in eine OCI-konforme Registrierung.
F: Was passiert mit AppC- oder Docker-Bildformaten?
A: Bestehende Formate können bei Bedarf weiterhin als Testgelände für Technologien dienen. Das OCI Image Format-Projekt ist bestrebt, eine zuverlässige offene Spezifikation bereitzustellen, die von verschiedenen Tools gemeinsam genutzt und für jahrelange oder jahrzehntelange Kompatibilität weiterentwickelt werden kann. wie das Deb- und RPM-Format haben.
Weitere FAQ finden Sie auf der OCI-Website.
Die GitHub-Meilensteine legen den Weg für zukünftige Verbesserungen fest.
Die Entwicklung der Spezifikation erfolgt auf GitHub. Probleme werden für Fehler und umsetzbare Elemente verwendet und auf der Mailingliste kann es zu längeren Diskussionen kommen.
Die Spezifikation und der Code sind unter der Apache 2.0-Lizenz lizenziert, die in der LICENSE Datei dieses Repositorys zu finden ist.
Das Projekt freut sich über Einreichungen, aber lassen Sie bitte alle wissen, woran Sie arbeiten.
Bevor Sie eine nicht triviale Änderung an dieser Spezifikation vornehmen, senden Sie eine E-Mail an die Mailingliste, um zu besprechen, was Sie vorhaben. Dies gibt jedem die Möglichkeit, das Design zu validieren, trägt dazu bei, Doppelarbeit zu vermeiden und stellt sicher, dass die Idee passt. Es garantiert auch, dass das Design solide ist, bevor Code geschrieben wird; Ein GitHub-Pull-Request ist nicht der richtige Ort für Diskussionen auf hoher Ebene.
Tipp- und Grammatikfehler können direkt zu einem Pull-Request führen. Beginnen Sie im Zweifelsfall mit der Mailingliste.
Aktuelle Informationen zu Besprechungsplänen für OCI-Mitwirkende und -Betreuer finden Sie in der README-Datei zum OCI-Organisations-Repository. Dort finden Sie auch Links zu den Tagesordnungen und Protokollen aller früheren Sitzungen.
Sie können die Mailingliste in Google Groups abonnieren und ihr beitreten.
Um die Konsistenz aller Markdown-Dateien in der Open-Container-Spezifikation zu gewährleisten, sollten alle Dateien mit einem Satz pro Zeile formatiert werden. Dies behebt zwei Dinge: Es erleichtert die Differenzierung mit Git und löst Streitigkeiten über die Länge des Zeilenumbruchs. Dieser Absatz erstreckt sich beispielsweise über drei Zeilen in der Markdown-Quelle.
Die Freigabe ist eine einfache Zeile am Ende der Erläuterung zum Patch, die bestätigt, dass Sie ihn geschrieben haben oder anderweitig das Recht haben, ihn als Open-Source-Patch weiterzugeben. Die Regeln sind ziemlich einfach: Wenn Sie Folgendes zertifizieren können (von 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.
Dann fügen Sie einfach jeder Git-Commit-Nachricht eine Zeile hinzu:
Signed-off-by: Joe Smith <[email protected]>
unter Verwendung Ihres richtigen Namens (leider keine Pseudonyme oder anonymen Beiträge).
Sie können die Abmeldung beim Erstellen des Git-Commits über git commit -s hinzufügen.
Einfache Verwaltung für eine saubere Git-Geschichte. Lesen Sie mehr über das Schreiben einer Git-Commit-Nachricht oder den Diskussionsabschnitt von git-commit(1) .
