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
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
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.
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 .