willshulman
commented
6 years ago DockerBuild use cases
(1) Dockerfile and build context are in source repository
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
- It does feel a little irritating to have to duplicate the location here. Maybe there is a way to streamline this case. Can use variables maybe. Or maybe some shorthand way of saying the dockerfile is in the buildContext.
- Technically,
buildContext.locationanddockerfile.locationdo not necessarily need to be the same.
(2) Dockerfile is in a System repository, and build context is in a source repository
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?
}(3) Dockerfile and build context are in a System repository
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
- Maybe
locationshould berepository. - It is worth noting that it is not valid to specify a
dockerfile.locationof"source"andbuildContext.locationof"local". If the Dockerfile is in the source repository the build context must be as well. - Would be nice to have shorthand for some of these constructs (eg locations). I have seen
git+sshas a scheme.
gregbanks
There are a variety of
buildorsourcetypes (field name TBD)