User directives, Compose implementation with Build support MUST first try to pull Image, then build from source Guarantee a pulled image is strictly equivalent to building the same image from sources. When service definition do include both Image attribute and a Build section, Compose implementation can’t Path prevent the Compose file to be portable, Compose implementation SHOULD warn user if an absolute alternateĭockerfile path is used. If Dockerfile path is relative, it MUST be resolved from context path. This one can beĪbsolute or relative path. In the later case, build arguments can be specified, including an alternate Dockerfile location. As an absolute path prevent the Compose file to be portable, Compose implementation
Context path can be absolute or relative, and if so relative path MUST be resolvedįrom Compose file parent folder. In the former case, the whole path is used as a Docker context to execute a docker build, looking for a canonicalĭockerfile at context root. Is valid for a Compose file to miss an Image attribute for corresponding service, as Compose implementationīuild can be either specified as a single string defining a context path, or as a detailed build definition. When a Build subsection is present for a service, it
Subsection, others being created based on Image attribute. Only a subset of Compose file services MAY define such a Build This section define theīuild requirements for service container image. The Compose Build specification allows to define the build process within a Compose fileĬompose Specification is extended to support an OPTIONAL build subsection on services. A Compose implementationįocusing on development use-case to run application on local machine will obviously also support (re)buildingĪpplication from sources. Compose specification is a platform-neutral way to define multi-container applications.
0 kommentar(er)
