|
|
| (59 intermediate revisions by 12 users not shown) |
| Line 1: |
Line 1: |
| {{Draft}}
| |
|
| |
| = Container Maintainer Guidelines = | | = Container Maintainer Guidelines = |
|
| |
|
| In the Fedora world, the concept of being a [https://fedoraproject.org/wiki/Category:Package_Maintainers Package Maintainer] is well known as all the software currently released and published as an official "Build Artifact" of the Fedora Project for inclusion in the Fedora GNU/Linux distribution has always been packaged in [http://rpm.org/ RPM] Package Manager Format.
| | The guidelines have been moved [https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/ here] |
| | |
| However, as technology changes so must the Fedora Project. The concept of "containers" on Linux has become quite prominent and Fedora will be publishing container images as officially released Build Artifact. One thing to note is that containers images are not a new software packaging format but more so a delivery mechanism where many different things such be easily shipped as a single unit. An example of this is packages that can be combined to deliver an easily ran "software solution".
| |
| | |
| Below you will find Guidelines similar in nature to that of the Fedora [https://fedoraproject.org/wiki/Packaging:Guidelines Packaging Guidelines] but catered towards the concept of Containers. Initially Fedora will be targeting the [https://www.docker.com/ Docker] container implemention but there are many and others will likely be incorporated in the future.
| |
| | |
| == Container Guidelines ==
| |
| | |
| The Container Guidelines are a collection of common issues and the severity that should be placed on them. While these guidelines should not be ignored, they should also not be blindly followed. If you think that your container should be exempt from part of the Guidelines, please bring the issue to the Fedora Container Committee (Pending Existence). In the absence of a Fedora Container Committee, please seek guidance from the [[Cloud_SIG|Fedora Cloud SIG|]]. | |
| | |
| === Docker Containers (Dockerfile) ===
| |
| | |
| [https://www.docker.com/ Docker] images are built using a [https://docs.docker.com/engine/reference/builder/ Dockerfile] much in the same way an [http://rpm.org/ RPM] is built using a spec file. In this section are Fedora Guidelines for creating Docker images using a Dockerfile.
| |
| | |
| | |
| {{admon/note|Dockerfile Guidelines Upstream|
| |
| These guidelines are a Fedora adaptation of the Upstream [https://projectatomic.io Project Atomic] effort to define [https://github.com/projectatomic/container-best-practices Container Best Practices].
| |
| }}
| |
| | |
| ==== LABELS ====
| |
| | |
| Dockerfiles have a concept of a [https://docs.docker.com/engine/reference/builder/#label LABEL] which can add arbitrary metadata to an image as a key-value pair. Fedora Guidelines on the topic of LABELs follows the [http://www.projectatomic.io/ Project Atomic] [https://github.com/projectatomic/ContainerApplicationGenericLabels Container Application Generic Labels] standards for LABEL definition.
| |
| | |
| Required LABELs for a Fedora Docker Image are as follows:
| |
| | |
| {|
| |
| !Name
| |
| !Description
| |
| |-
| |
| |BZComponent
| |
| |The Bugzilla component name where bugs against this container should be reported by users.
| |
| |-
| |
| |Name
| |
| |Name of the Image
| |
| |-
| |
| |Version
| |
| |Version of the image
| |
| |-
| |
| |Release
| |
| |Release Number for this version
| |
| |-
| |
| |Architecture
| |
| |Architecture the software in the image should target (Optional: if omitted, it will be built for all supported Fedora Architectures)
| |
| |}
| |
| | |
| | |
| | |
| These LABELs should be defined in a single line of the Dockerfile such that they don't each lead to another layer in the build. The following is a very simple Dockerfile example containing the required LABELs:
| |
| | |
| <pre>
| |
| FROM fedora
| |
| MAINTAINER "Adam Miller" <maxamillion@fedoraproject.org>
| |
| | |
| LABEL BZComponent="myawesomecontainer" \
| |
| Name="fedora/myawesomecontainer" \
| |
| Version="0.1" \
| |
| Release="1" \
| |
| Architecture="x86_64"
| |
| </pre>
| |
| | |
| ==== CMD / ENTRYPOINT ====
| |
| | |
| Another item required is a CMD or ENTRYPOINT entry so that when an user were run perform the following command (for example), expected behavior occurs.:
| |
| | |
| <pre>docker run registry.fedoraproject.org/fedora/myawesomecontainer</pre>
| |
| | |
| For more information on these entries, please reference the upstream [https://docs.docker.com/engine/reference/builder/ Dockerfile documentation]. The following is extending on the above example, showing a CMD directive.
| |
| | |
| <pre>
| |
| FROM fedora
| |
| MAINTAINER "Adam Miller" <maxamillion@fedoraproject.org>
| |
| | |
| LABEL BZComponent="myawesomecontainer" \
| |
| Name="fedora/myawesomecontainer" \
| |
| Version="0.1" \
| |
| Release="1" \
| |
| Architecture="x86_64"
| |
| | |
| CMD printf "My Awesome Container!\n"
| |
| </pre>
| |
| | |
| == Content ==
| |
| | |
| Dockerfiles in Fedora should not contain net new code, which is unfortunately subjective in nature. The meaning of this is that software should be packaged properly as RPMs and placed in the Fedora repositories, Dockerfiles are simply a deliver mechanism for pre-defined "ready to run" configurations. This can be achieved as an [https://github.com/projectatomic/atomicapp/blob/master/docs/start_guide.md Atomic App] or similar. Any content that is to accompany the Dockerfile must either be configuration files or startup/orchestration scripts. The goal of this is such that we follow the key points of the [https://docs.pagure.org/releng/philosophy.html Fedora Release Engineering Philosophy].
| |
| | |
| = Discussion =
| |
| | |
| See [[Talk:PackagingDrafts/Containers]] for discussion.
| |
| | |
| [[Category:Packaging guidelines drafts]]
| |
