Build.Input.Dockerfile or Build.Input.Docker-Compose

[Puneeth-n]

It is more of an idea that I am jotting down here.

In our mono repo, We have dockerized all our services and lambdas. We use docker-compose to build our docker images. We prefer it over having building via docker build ... because the build details is machine readable.

With Build.Input.GitFiles or Build.Input.Files, I see that we need to maintain the truth at two different places; Dockerfile and baur file.

[fho]

I'm not sure If I understand the issue correctly. Is the issue that you have to specify the path to the Dockerfile in the docker-compose config and in the baur config?

A way to realize what you want to do could be: In baur you list your Dockerfile, the docker-compose.yml and all the application source files in the Build.Input.Files sections. This ensures that a rebuild is done when one of the file changes.

baur is relying on the --iidfile parameter of docker build to find the build image that it should upload to the docker-registry. docker compose doesn't seem to support --iidfile, so you would have to workaround it. A way to do that could be to use a script as build command. The script calls docker-compose build and then afterwards writes the image id to a file. The path to the file you specify in the idfile field in the Build.Output.DockerImage section of the .app.toml file.

[Puneeth-n]

@fho I was more thinking in the direction of, IFF baur read the docker-compose.yml to find all Dockerfiles and their contexts to calculate the Build.Input.Files instead of we specifying the Build.Input.Files configuration

[Puneeth-n]

Consider the following docker-compose.yml

# vim: set ts=2 sw=2 sts=2 et :

version: '2.2'

services:
  addon:
    build:
      context: .
      dockerfile: ./Dockerfile
      args:
        CT_ECR: ${CT_ECR}
        CT_TAG: ${CT_TAG}
    image: ct-addon:${CT_TAG}
    environment:
      - NODE_ENV=test
      - AWS_ACCESS_KEY_ID=dummy
      - AWS_SECRET_ACCESS_KEY=dummy
    command: tail -f /dev/null

Baur could potentially parse the Dockerfile and potentially see what all files are COPYed or if Dockerfile itself changed or docker-compose.yml changed and dynamically generate the Build.Input.Files

With the current approach, I think we should manually specify under Build.Input.Files Dockerfile, docker-compose.yml and all files that are copied inside the docker image.

[fho]

@Puneeth-n

In our environment building the application and building the docker image separate steps. We build the artifact for the application. Then we run docker build, the Dockerfile has a COPY statement to copy the artifact to the image. The files that are copied are not specified as Build.Input. Because those were produced by the build process. They are not build inputs. In simple scenarios we specify the whole application directory as Build.Input.Gitfiles.

Supporting to parse Dockerfile or docker-compose would be a lot of effort. Support for it has to be kept uptodate with upstream and I'm not sure if it's even possible to handle all cases reliable (wildcards in path, maybe files are created dynamically somehow). Sorry, currently we can't support that.

Maybe it also works for your scenario to specify the whole application directory as Build.Input.Gitfiles?

[Puneeth-n]

@fho True :) Agree with that. It is a complex use case for sure ;) It was just an idea :) This project is a good initiative. Closing this issue.

[fho]

@Puneeth-n thanks nonetheless for your input and ideas :-)