image spec
v1.1.0
El proyecto OCI Image Format crea y mantiene la especificación de formato de imagen del contenedor de envío de software (OCI Image Format).
La especificación se puede encontrar aquí.
Este repositorio también proporciona tipos Go, herramientas de validación intrablob y esquema JSON. Los tipos y la validación de Go deben ser compatibles con la versión actual de Go; Las versiones anteriores de Go no son compatibles.
Documentación adicional sobre cómo opera este grupo:
El proyecto asociado de OCI Image Format es el proyecto OCI Runtime Spec. La Especificación de tiempo de ejecución describe cómo ejecutar un "paquete de sistema de archivos" que se descomprime en el disco. En un nivel alto, una implementación de OCI descargaría una imagen de OCI y luego descomprimiría esa imagen en un paquete de sistema de archivos OCI Runtime. En este punto, el OCI Runtime Bundle sería ejecutado por un OCI Runtime.
Todo este flujo de trabajo admite la UX que los usuarios esperan de los motores de contenedores como Docker y rkt: principalmente, la capacidad de ejecutar una imagen sin argumentos adicionales:
Para admitir esta UX, el formato de imagen OCI contiene información suficiente para iniciar la aplicación en la plataforma de destino (por ejemplo, comandos, argumentos, variables de entorno, etc.).
El Proyecto de especificaciones de distribución de OCI define un protocolo API para facilitar y estandarizar la distribución de contenido. Esta API incluye soporte para enviar y extraer imágenes OCI a un registro compatible con OCI.
P: ¿Qué sucede con los formatos de imagen AppC o Docker?
R: Los formatos existentes pueden seguir siendo un campo de pruebas para las tecnologías, según sea necesario. El proyecto OCI Image Format se esfuerza por proporcionar una especificación abierta confiable que pueda compartirse entre diferentes herramientas y evolucionar durante años o décadas de compatibilidad; como lo tienen el formato deb y rpm.
Encuentre más preguntas frecuentes en el sitio de OCI.
Los hitos de GitHub marcan el camino hacia futuras mejoras.
El desarrollo se realiza en GitHub para la especificación. Los problemas se utilizan para errores y elementos procesables y pueden tener lugar discusiones más largas en la lista de correo.
La especificación y el código tienen la licencia Apache 2.0 que se encuentra en el archivo LICENSE de este repositorio.
El proyecto acepta presentaciones, pero hágales saber a todos en qué está trabajando.
Antes de realizar un cambio no trivial en esta especificación, envíe un correo a la lista de correo para discutir lo que planea hacer. Esto les da a todos la oportunidad de validar el diseño, ayuda a evitar la duplicación de esfuerzos y garantiza que la idea encaje. También garantiza que el diseño sea sólido antes de escribir el código; una solicitud de extracción de GitHub no es el lugar para discusiones de alto nivel.
Los errores tipográficos y gramaticales pueden derivar directamente en una solicitud de extracción. En caso de duda, comience con la lista de correo.
Consulte el archivo README del repositorio de la organización OCI para obtener la información más actualizada sobre los cronogramas de reuniones de contribuyentes y mantenedores de OCI. También puede encontrar enlaces a agendas de reuniones y actas de todas las reuniones anteriores.
Puede suscribirse y unirse a la lista de correo en Grupos de Google.
Para mantener la coherencia en todos los archivos Markdown en la especificación Open Container, todos los archivos deben tener el formato de una oración por línea. Esto soluciona dos cosas: facilita la diferenciación con git y resuelve peleas sobre la longitud del ajuste de línea. Por ejemplo, este párrafo ocupará tres líneas en la fuente de Markdown.
La aprobación es una línea simple al final de la explicación del parche, que certifica que usted lo escribió o que tiene derecho a transmitirlo como un parche de código abierto. Las reglas son bastante simples: si puedes certificar lo siguiente (de desarrolladorcertificate.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.
luego simplemente agregas una línea a cada mensaje de confirmación de git:
Signed-off-by: Joe Smith <[email protected]>
usando su nombre real (lo siento, no se permiten seudónimos ni contribuciones anónimas).
Puede agregar el cierre de sesión al crear el compromiso de git mediante git commit -s .
Mantenimiento sencillo para un historial limpio de git. Lea más sobre Cómo escribir un mensaje de confirmación de Git o la sección de discusión de git-commit(1) .
