Open willshulman opened 6 years ago
This will be common when the Dockerfile for a System Component (i.e. Service or Job) exists a-priori to Lattice.
In this case the Dockerfile and build context for a Component are located in the source code repository for the Component. The Dockerfile may also be used outside of Lattice.
If the Component definition is also in the source code repository the definition would look like this:
{
type: "DockerBuild",
buildContext: { // null or no absence of this key means location and path get defaults
location: null // null means local to this repository
path: ".", // Defaults to "."
},
dockerfile: { // null or no absence of this key means location and path get defaults
location: null , // null means local to this repository which is the default
path: "Dockerfile", // Defaults to "Dockerfile"
},
options: { ... } // What else do we need?
}
or by allowing the use of defaults:
{
type: "DockerBuild",
options: { ... } // What else do we need?
}
If the Component definition is outside the source code repository the definition would look like this:
{
type: "DockerBuild",
buildContext: {
location: {
type: "GitRepository",
url: "http://....",
commit: "v1.0.0",
options: { ...} // ssh keys go here (for now)
},
path: "."
},
dockerfile: {
location: {
type: "GitRepository",
url: "http://....",
commit: "v1.0.0",
options: { ...} // ssh keys go here (for now)
},
path: "Dockerfile", // the default
},
options: { ... } // What else do we need?
}
Notes
buildContext.location
and dockerfile.location
do not necessarily need to be the same. Here the Dockerfile is with the Component definition, but the build context is inside a source code repository. This is useful when using a third-party application that does not have a public Dockerfile or when you want to customize how the Component is built.
{
type: "DockerBuild",
buildContext: {
location: {
type: "GitRepository",
url: "http://....",
commit: "v1.0.0",
options: { ...} // ssh keys go here (for now)
},
path: "."
},
dockerfile: {
location: null , // null means local to this repository which is the default
path: "Dockerfile", // the default
},
options: { ... } // What else do we need?
}
Here the Dockerfile for a Service as well as the build context are inside a System repository, and there is no source repository.
An example of this use-case would be a Service that is an nginx web server augmented with custom web pages to serve. Here the Dockerfile might look something like:
FROM nginx
COPY ./web-pages
...
{
type: "DockerBuild",
buildContext: {
location: null ,
path: ".",
},
dockerfile: {
location: null ,
path: "Dockerfile",
},
options: { ... } // What else do we need?
}
or equivalently:
{
type: "DockerBuild",
options: { ... } // What else do we need?
}
Notes
location
should be repository
. dockerfile.location
of "source"
and buildContext.location
of "local"
. If the Dockerfile is in the source repository the build context must be as well.git+ssh
as a scheme. On build environments: We do want to duplicate the exec environment stuff so that builds can have environments where you can pass environment variables needed by the build / Dockerfile.
There are a variety of
build
orsource
types (field name TBD)