Support for context above docker-compose.yml

Product support balenaEngine
1

I am trying to share libraries between two different apps.

Local project structure looks like this:

├── Dockerfile-A
├── Dockerfile-B
├── app-libs
│   └── src
├── app-first
│   ├── docker-compose.yml
│   ├── container-first
│   │   └── src (an app)
│   ├── container-second
│   │   ├── Dockerfile
│   │   └── src (a daemon)
│   └── container-third
│       ├── Dockerfile
│       └── src (a daemon)
└── app-second
    └── src (an app)

The first app is a multicontainer and the second is a single.

The single container app works just fine when doing a balena build -a app-second --dockerfile Dockerfile-B from the top level. Both the libraries and the application get copied into the container.

Dockerfile-B relevant lines:

WORKDIR /app/app-libs
COPY ./app-libs ./
WORKDIR /app/app-second
COPY ./app-second ./

This is expected as the Docker context is inferred to be the current working directory, the top level, and all COPY paths are accessible below that.

The multicontainer app cannot copy things the same way for its first container as it requires a docker-compose.yml.

Dockerfile-A relevant lines:

WORKDIR /app/app-libs
COPY ./app-libs ./
WORKDIR /app/container-first
COPY ./app-first/container-first ./

docker-compose.yml relevant lines:

services:
  container-first:
    build:
      context: ../
      dockerfile: ./Dockerfile-A

That is, balena build can’t be run from the top level because the docker-compose.yml needs to be present and can’t be passed as an argument. And when not run from the top level, Docker complains about not being able to copy the app-libs folder since it’s above the Docker context.

A plain docker build for app-second or a docker-compose build for app-first work fine.

cd app-first && docker-compose build
cd .. && docker build -f Dockerfile-B .
2

Hi,
We are already working on supporting an option in balena cli to specify the docker-compose.yml file. (https://github.com/balena-io/balena-cli/issues/1142) This should fix your problem.
Another idea would be to make a base docker image that contains the libs and use this in the two Dockerfiles of the apps, would this work for you as well?
Best regards,

4

Ok, I’ll stay tuned to the GitHub issue. In the meantime, I think I can accomplish this with some creative shell scripting around my push process. I’d like to avoid a docker image for the libs right now to streamline the workflow a bit more during local dev.