When using the existing Lagoon examples, with the most recent version of Lando (3.20+) - the default orchestrator at docker compose V2 isn't compatible
e.g. https://github.com/lagoon-examples/drupal9-base - the CLI image builds first and pushes to local docker drupal9base-cli:latest - but the php and nginx images that consume it are looking on docker.io/library/ for it, instead of locally.
We've always assumed this is a buildkit thing (as when you run the build with DOCKER_BUILDKIT=0 docker compose build it runs fine)
Running LANDO_ORCHESTRATOR_VERSION="1.29.2" lando rebuild -y works ok, but is unmanageable long term - and whilst it can be set globally, there may be users that need to run both?
tobybellwood@pop-os:~/sites/drupal9-base$ lando version
v3.20.1
tobybellwood@pop-os:~/sites/drupal9-base$ LANDO_ORCHESTRATOR_VERSION="2.22.0" lando rebuild -y
Rising anew like a fire phoenix from the ashes! Rebuilding app...
no container to killNo stopped containers
[+] Pulling 3/3
✔ mariadb Pulled 1.7s
✔ lagooncli Pulled 1.7s
✔ mailhog Pulled 1.7s
[+] Building 5.9s (18/18) FINISHED docker-container:lagoon
=> [cli internal] load build definition from cli.dockerfile 0.0s
=> => transferring dockerfile: 283B 0.0s
=> [cli internal] load metadata for docker.io/uselagoon/php-8.1-cli-drupal:latest 0.7s
=> [cli internal] load .dockerignore 0.0s
=> => transferring context: 76B 0.0s
=> [cli 1/6] FROM docker.io/uselagoon/php-8.1-cli-drupal:latest@sha256:8604f740f5d79cddaa34a6c75066ca6140375a8c94031e724f958b87f23048c9 0.0s
=> => resolve docker.io/uselagoon/php-8.1-cli-drupal:latest@sha256:8604f740f5d79cddaa34a6c75066ca6140375a8c94031e724f958b87f23048c9 0.0s
=> [cli internal] load build context 1.3s
=> => transferring context: 2.04MB 1.2s
=> CACHED [cli 2/6] COPY composer.* /app/ 0.0s
=> CACHED [cli 3/6] COPY assets /app/assets 0.0s
=> CACHED [cli 4/6] RUN composer install --no-dev 0.0s
=> CACHED [cli 5/6] COPY . /app 0.0s
=> CACHED [cli 6/6] RUN mkdir -p -v -m775 /app/web/sites/default/files 0.0s
=> [cli] exporting to docker image format 2.0s
=> => exporting layers 0.0s
=> => exporting manifest sha256:117087a50153885fae9c89c8fae5336581c00821de7c99dcd8be507e24452348 0.0s
=> => exporting config sha256:e0432e0f74e05e37c37a24cb6be1302620ea220e68069069505914bca7f156e3 0.0s
=> => sending tarball 2.0s
=> [cli cli] importing to docker 0.1s
=> [php internal] load build definition from php.dockerfile 0.0s
=> => transferring dockerfile: 142B 0.0s
=> CANCELED [php internal] load metadata for docker.io/uselagoon/php-8.1-fpm:latest 1.5s
=> ERROR [nginx internal] load metadata for docker.io/library/drupal9base-cli:latest 1.5s
=> [nginx internal] load build definition from nginx.dockerfile 0.0s
=> => transferring dockerfile: 206B 0.0s
=> [nginx internal] load metadata for docker.io/uselagoon/nginx-drupal:latest 0.7s
=> [php auth] library/drupal9base-cli:pull token for registry-1.docker.io 0.0s
------
> [nginx internal] load metadata for docker.io/library/drupal9base-cli:latest:
------
failed to solve: drupal9base-cli: pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
ERROR ==>
When using the existing Lagoon examples, with the most recent version of Lando (3.20+) - the default orchestrator at docker compose V2 isn't compatible
e.g. https://github.com/lagoon-examples/drupal9-base - the CLI image builds first and pushes to local docker
drupal9base-cli:latest
- but the php and nginx images that consume it are looking on docker.io/library/ for it, instead of locally.We've always assumed this is a buildkit thing (as when you run the build with
DOCKER_BUILDKIT=0 docker compose build
it runs fine)Running
LANDO_ORCHESTRATOR_VERSION="1.29.2" lando rebuild -y
works ok, but is unmanageable long term - and whilst it can be set globally, there may be users that need to run both?