image spec
v1.1.0
Le projet OCI Image Format crée et gère la spécification du format d'image du conteneur d'expédition de logiciels (OCI Image Format).
Le cahier des charges peut être trouvé ici.
Ce référentiel fournit également des types Go, des outils de validation intra-blob et un schéma JSON. Les types Go et la validation doivent être compatibles avec la version Go actuelle ; Les versions antérieures de Go ne sont pas prises en charge.
Documentation supplémentaire sur le fonctionnement de ce groupe :
Le projet partenaire OCI Image Format est le projet OCI Runtime Spec. La spécification d'exécution explique comment exécuter un « ensemble de système de fichiers » décompressé sur le disque. À un niveau élevé, une implémentation OCI téléchargerait une image OCI, puis décompresserait cette image dans un ensemble de système de fichiers OCI Runtime. À ce stade, l’ensemble d’exécution OCI serait exécuté par un environnement d’exécution OCI.
L'ensemble de ce flux de travail prend en charge l'UX que les utilisateurs attendent des moteurs de conteneurs comme Docker et rkt : principalement, la possibilité d'exécuter une image sans arguments supplémentaires :
Pour prendre en charge cette UX, le format d'image OCI contient suffisamment d'informations pour lancer l'application sur la plate-forme cible (par exemple, commande, arguments, variables d'environnement, etc.).
Le projet OCI Distribution Spec définit un protocole API pour faciliter et standardiser la distribution du contenu. Cette API inclut la prise en charge du transfert et de l'extraction d'images OCI vers un registre conforme à OCI.
Q : Qu'arrive-t-il aux formats d'image AppC ou Docker ?
R : Les formats existants peuvent continuer à servir de terrain d’essai pour les technologies, si nécessaire. Le projet OCI Image Format s'efforce de fournir une spécification ouverte fiable qui peut être partagée entre différents outils et évoluer pendant des années ou des décennies de compatibilité ; comme le font les formats deb et rpm.
Trouvez plus de FAQ sur le site OCI.
Les jalons de GitHub tracent la voie vers les améliorations futures.
Le développement a lieu sur GitHub pour la spécification. Les problèmes sont utilisés pour les bogues et les éléments exploitables et des discussions plus longues peuvent avoir lieu sur la liste de diffusion.
La spécification et le code sont sous licence Apache 2.0 trouvée dans le fichier LICENSE de ce référentiel.
Le projet accueille les soumissions, mais veuillez faire savoir à tout le monde sur quoi vous travaillez.
Avant d'entreprendre une modification non triviale de cette spécification, envoyez un courrier à la liste de diffusion pour discuter de ce que vous envisagez de faire. Cela donne à chacun la possibilité de valider la conception, aide à éviter la duplication des efforts et garantit que l'idée correspond. Cela garantit également que la conception est solide avant l’écriture du code ; une pull-request GitHub n'est pas le lieu idéal pour des discussions de haut niveau.
Les fautes de frappe et les erreurs grammaticales peuvent donner directement lieu à une pull-request. En cas de doute, commencez sur la liste de diffusion.
Veuillez consulter le fichier README du référentiel de l'organisation OCI pour obtenir les informations les plus récentes sur les calendriers des réunions des contributeurs et des responsables d'OCI. Vous pouvez également trouver des liens vers les ordres du jour et les procès-verbaux de toutes les réunions précédentes.
Vous pouvez vous abonner et rejoindre la liste de diffusion sur Google Groupes.
Pour maintenir la cohérence dans les fichiers Markdown dans la spécification Open Container, tous les fichiers doivent être formatés une phrase par ligne. Cela corrige deux choses : cela facilite la comparaison avec git et résout les conflits concernant la longueur du retour à la ligne. Par exemple, ce paragraphe s'étendra sur trois lignes dans la source Markdown.
La signature est une simple ligne à la fin de l'explication du correctif, qui certifie que vous l'avez écrit ou que vous avez le droit de le transmettre en tant que correctif open source. Les règles sont assez simples : si vous pouvez certifier ce qui suit (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.
Ensuite, vous ajoutez simplement une ligne à chaque message git commit :
Signed-off-by: Joe Smith <[email protected]>
en utilisant votre vrai nom (désolé, pas de pseudonymes ni de contributions anonymes.)
Vous pouvez ajouter la signature lors de la création du git commit via git commit -s .
Entretien ménager simple pour un historique git propre. En savoir plus sur Comment écrire un message Git Commit ou sur la section Discussion de git-commit(1) .
