Skip to content
This repository has been archived by the owner on May 3, 2022. It is now read-only.

Custom dockerfiles and build contexts #352

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Custom dockerfiles and build contexts #352

wants to merge 1 commit into from

Conversation

simonferquel
Copy link
Contributor

This adds the possibility to specify a custom build context and
Dockerfile for docker components. This makes it easier for adding duffle
compatibility in existing projects.
E.G.: We can now add a simple duffle.json file in the existing
docker/app code base that builds the invocation image from the same
Build context as before, but with a different Dockerfile

duffle.json at the root of my docker-app workspace:

{
    "name": "app",
    "parameters": {
        "k8s_namespace": {
            "defaultValue": "default",
            "type": "string"
        },
        "app_package":{
            "type": "string"
        },
        "settings": {
            "type": "string",
            "destination":{
                "path": "/root/docker-app.settings"
            }
        }
    },
    "credentials": {
        "kubeconfig": {
            "path": "/root/.kube/config"
        }
    },
    "components": {
        "cnab":{
            "name": "cnab",
            "builder" : "docker",
            "configuration":{
                "context": ".",
                "dockerfile": "cnab/Dockerfile",
                "registry": "docker"
            }
        }
    }
}

@@ -39,6 +36,7 @@ type Component struct {
name string
Image string
Dockerfile string
contextDir string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any particular reason why this is not exposed as the rest of the fields here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it is just that I don't see why it should be exposed... Any particular reason any of these fields should be exposed ? :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At some point in the future we want to vendor out the Duffle build packages for other tools - and those tools might want to to something different with the build context.

@@ -68,10 +66,23 @@ func (dc Component) Digest() string {

// NewComponent returns a new Docker component based on the manifest
func NewComponent(c *manifest.Component, cli *command.DockerCli) *Component {
var (
contextDir string
dockerfile = "Dockerfile"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add this as a constant side by side with the Dockerignore file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should yes

@radu-matei
Copy link
Member

This looks great - there is one thing that might cause some confusion - consider the following component:

[components]
    [components.cnab]
        name = "cnab"
        builder = "docker"
        configuration = { registry = "microsoft", dockerfile = "Dockerfile2" }

The config file (duffle.toml in this case) is at the root of my application - but the dockerfile entry in the config expects a a file relative to the component directory, not relative to the application directory.
This means in a file at the root of the application, I'm putting one property which is relative to the component directory - which is not that intuitive.

Copy link
Member

@radu-matei radu-matei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great - however, there are a couple of small nits, plus the comment about paths that are relative to the application/ component directory, on which I'd like to have a discussion.

Thanks!

@simonferquel
Copy link
Contributor Author

The rational here is:

  • the dockerfile is always relative to the docker build context
  • the default docker build context dir is ${COMPONENT_NAME}
  • context dirs are relative to the application directory

Does it make sense ? or should we find something less confusing ?

@radu-matei
Copy link
Member

Regarding the relative paths - I'm ok with merging this as is, with the mention that we should document this (once we have a doc for building, that is..).

So once the conversations above get resolved, I'll LGTM this and we can merge.

Thanks for the contribution!

@technosophos
Copy link
Member

So we're just a few small changes away from being able to merge this, right?

This adds the possibility to specify a custom build context and
Dockerfile for docker components. This makes it easier for adding duffle
compatibility in existing projects.
E.G.: We can now add a simple duffle.json file in the existing
docker/app code base that builds the invocation image from the same
Build context as before, but with a different Dockerfile

Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
@simonferquel
Copy link
Contributor Author

rebased, fixed and pushed. PTAL @radu-matei @technosophos

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants