Support for Apple Silicon architecture
For reference, I found this closed issue when creating this one: #120 (closed)
We have a couple of developers here developing on Apple Silicon. The step by step instructions work out of the box except for the a d4d up step, where the following type of issue recurs for multiple required service images:
Error response from daemon: image with reference [service/name:x] was found but does not match the specified platform: wanted linux/amd64, actual: linux/arm64
To work around this I created a docker-compose.override.yml file in the project root, where I copied the entire contents of the main docker-compose.yml file (which gets overwritten on composer install) and added the platform: linux/amd64 line before the image for the services in question, namely mariadb, mariadbtest, pma and mailhog, eg:
mariadb:
platform: linux/amd64
image: 'wodby/mariadb:10.6'Once solved, the file was shared with another Apple Silicon based developer (on a different project), and they were also able to install successfully.
This hint came from stackoverflow.
So the linux/amd64 version of the images in question are explicitly requested. At some point I expect arm64 variants will be released and they will have better performance, so I wouldn't suggest committing this fix in the repo. But this could be useful on a FAQ/Troubleshooting/Documentation page for Apple Silicon users.
Activity
assigned to @jurgenhaas
added Doing label
Thanks a lot @rominronin for this great analysis.
We could also resolve this by some setting in the
.lakedrops.user.ymlfile where each user could easily extend the service declaration for docker-compose, so that they always get the correct setup without having to manually maintain extra docker-compose files. Here is a section in the docs where this is documented: https://devops-tools.docs.lakedrops.com/composer/plugin/d4d/#adding-new-docker-services-or-enhancing-existing-onesPlease let me know if that works in your environment or if we should improve this somehow.
Thanks for the great project!
Following your suggestion, I removed the docker-compose.override.yml file and created a .lakedrops.user.yml file, to which I added the following:
docker4drupal: docker-compose.yml: services: mariadb: platform: linux/amd64 mariadbtest: platform: linux/amd64 redis: platform: linux/arm64 pma: platform: linux/amd64 mailhog: platform: linux/amd64Which did the trick, but there was one remaining issue, which is the 'Mounts denied' issue, caused by the
'/drupal:/ssh-agent'line in the php.volumes list. To fix this (without editing docker-compose.yml directly), I recreated the docker-compose.override.yml file with the following:services: php: volumes: - '/etc/timezone:/etc/timezone:ro' - '/etc/localtime:/etc/localtime:ro' - '/var/www/vhosts/identum:/var/www/html' - '/var/www/vhosts/identum/drush:/etc/drush' - '${SSH_AUTH_SOCK}:/ssh-agent'Going back to your reply, it would be great to not have to maintain multiple docker-compose files, but entering the above in the .lakedrops.user.yml file just merges the keys (possibly related to this issue?). If there's another workaround, I'd be happy to try it, otherwise, this works for now
Edited by Baris Tosun-
there was one remaining issue, which is the 'Mounts denied' issue, caused by the
'/drupal:/ssh-agent'line in the php.volumes list.@rominronin I'd be very interested to fix this properly. There had been a similar issue before, which we had to close due to missing feedback, see #127 (closed). The
SSH_AUTH_SOCKenvironment variable should be forwarded from the host into the L3D container and may have to be altered to work properly in all context. If you had some time to debug this, where this breaks on MacOS, that would be great and I'd be really happy to fix this in the code.@kaigertz this may be of interest to you as well as you had reported a similar issue in #120 (closed) before.
"The
SSH_AUTH_SOCKenvironment variable should be forwarded from the host into the L3D container and may have to be altered to work properly in all context. If you had some time to debug this, where this breaks on MacOS, that would be great and I'd be really happy to fix this in the code."I'm not sure this is the issue. The line in the default docker-compose.yml file is which causes the error is:
php: volumes: - '/drupal:/ssh-agent'It looks like the path '/drupal' is expected in the local machine (because the mapping definitions are from:to). I assume this works on linux/windows environments (but I can check later on a colleague's PC).
It's when this line is replaced with
'${SSH_AUTH_SOCK}:/ssh-agent'that it works on macos.So what is this line for? I'm reading tonnes of documentation to find out. It's not in the default docker4drupal docker-compose.yml file, that's for sure.
Edited by Baris Tosun-
The way this value gets into the docker-compose file is in the lakedrops/docker4drupal package and looks like this in the Handler class:
// Check if SSH auth sockets are supported. $ssh_auth_sock = getenv('SSH_AUTH_SOCK'); $php['ssh'] = !empty($ssh_auth_sock); if ($php['ssh']) { $php['ssh_auth_sock'] = ($this->isCiContext() || $this->isLocalDevMode()) ? $this->getDockerMountSource('/ssh-agent') : '$SSH_AUTH_SOCK'; }This is where you should debug, why it gets the wrong value which in your case seems to be
/drupal, but it should be the real path of the socket. -
@rominronin have you had a chance to find out where this is going wrong on Apple Silicon?
Edited by jurgenhaas removed Doing label
unassigned @jurgenhaas
-
/cc @nico-acolono
Done some digging this morning (thank our clients for a postponed meeting), here's what I found.
The following if statement
if ($php['ssh']) { $php['ssh_auth_sock'] = ($this->isCiContext() || $this->isLocalDevMode()) ? $this->getDockerMountSource('/ssh-agent') : '$SSH_AUTH_SOCK'; }If
($this->isCiContext() || $this->isLocalDevMode())returns false, we get the desired value of$SSH_AUTH_SOCK. Conversely, the current value of/drupalis assigned if the context is CI/CD OR a local dev environment (so in all cases? What other contexts are there? Is this a mistake?).I'm trying to understand what this statement is for. It looks like the default behaviour should be to assign
$php['ssh_auth_sock'] = '$SSH_AUTH_SOCK';and ONLY assign something else IF an alternative mount point is provided by docker.So perhaps the code should instead read as follows:
if ($php['ssh']) { $php['ssh_auth_sock'] = $this->getDockerMountSource('/ssh-agent') ?? '$SSH_AUTH_SOCK'; }with the additional change to getDockerMountSource() (just returns NULL if all else fails - this is where /drupal is ACTUALLY coming from):
private function getDockerMountSource($projectRoot): string|null { $currentDir = getcwd(); $container = $this->readContainerConfig(); foreach ($container['Mounts'] as $mount) { if (empty($projectRoot)) { if ($currentDir === $mount['Destination']) { return $mount['Source']; } } else if (strpos($projectRoot, $mount['Destination']) === 0) { return $mount['Source'] . substr($projectRoot, strlen($mount['Destination'])); } } return NULL; }But this is based on guessing the purpose of this statement.
Note: I initially went another route:
$this->isCiContext()returns false, and$this->isLocalDevMode()just returns theLAKEDROPS_DEV_ENVenv variable. So I can just edit that, right?Apparently not, the .env file is regenerated on each deploy.
If we do end up finding some environment specific reason for this, the project may be forced to consider confronting the way .env files are handled.
Edited by Baris Tosunassigned to @jurgenhaas
-
is assigned if the context is CI/CD OR a local dev environment (so in all cases? What other contexts are there? Is this a mistake?).
There is also the LIVE or production mode. I don't remember, why it was necessary to make that distinction, though.
change to getDockerMountSource() (just returns NULL if all else fails - this is where /drupal is ACTUALLY coming from)
It's not that simple. Let me show you the situation on a Linux host:
- On the host, SSH_AUTH_SOCK is
/run/user/1000/keyring/ssh - In the L3D container, SSH_AUTH_SOCK is
/ssh-agentwhich is mounted to/run/user/1000/keyring/sshon the host - In the PHP container, we need to mount to
/run/user/1000/keyring/sshas well, so the docker compose config needs to have this volume:/run/user/1000/keyring/ssh:/ssh-agent
Would we use the value of the
$SSH_AUTH_SOCKvariable inside the L3D container when building and starting the docker compose project, then would mount to/ssh-agentin L3D, which is wrong. Since Docker operates on the host, the PHP container also has to mount to the correct directory on the host level.That's what
getDockerMountSource('/ssh-agent')in there for. It analyses the current L3D container and finds the mount point for that/ssh-agentdirectory.It looks like, it doesn't find that, which seems to be a MacOS issue. If you could help to find the reason why
getDockerMountSourceis not finding the correct mount point in your environment, that would actually fix the problem. - On the host, SSH_AUTH_SOCK is
unassigned @jurgenhaas
I think we have a solution. Can you move to the buildx infastructure in order to build amd and arm images. example
docker buildx build --load --build-arg VERSION=${VERSION} --platform linux/amd64,linux/arm64 -t ${CI_REGISTRY_IMAGE}/run:${VERSION} ./runthis would solve multiple problems for apple silicone macs we hope. so no need for a overwrite in the composer file etc and it is just an additional images and all the old images are still working. buildx will replace build anyway in the future anyway.assigned to @jurgenhaas
-
@nico-acolono this sounds promising. And we already use the
buildxframework as the build process happens inside an image of the docker/gitlab-drupal-ci project which is configured withdocker buildx installto declaredocker buildas an alias fordocker buildx build.However, inside of that context we can't use the multi-platform build. That shouldn't be a problem as we could easily build twice, once for each platform. Just wondering about the image tagging, any idea how that should look like then?
Edited by jurgenhaas 
Maybe this can help?
-
Here is the script for testing the build in the underlying project from within l3d:
#!/usr/bin/env bash ALPINE=3.17 PHP=8.2 VERSION=test docker build --pull --build-arg ALPINE_VERSION=${ALPINE} --build-arg PHP_MAJOR_VERSION=${PHP} --build-arg VERSION=${VERSION} --platform linux/amd64 . docker build --pull --build-arg ALPINE_VERSION=${ALPINE} --build-arg PHP_MAJOR_VERSION=${PHP} --build-arg VERSION=${VERSION} --platform linux/arm64 .The first build works OK, but the second one fails with this error message:
[+] Building 1.5s (9/9) FINISHED => [internal] load .dockerignore 0.1s => => transferring context: 2B 0.0s => [internal] load build definition from Dockerfile 0.1s => => transferring dockerfile: 5.58kB 0.0s => [internal] load metadata for docker.io/library/php:8.2-cli-alpine3.17 0.5s => [1/5] FROM docker.io/library/php:8.2-cli-alpine3.17@sha256:2af057cd287e0ac4421d8cd5f078846a95f2f2666b29b5ab448b42479ef09bd5 0.0s => [internal] load build context 0.0s => => transferring context: 733B 0.0s => CACHED [2/5] ADD usrbin/column /usr/bin/column 0.0s => CACHED [3/5] ADD bin/* /usr/local/bin/ 0.0s => CACHED [4/5] ADD etc/* /etc/ 0.0s => ERROR [5/5] RUN echo 'hosts: files dns' > /etc/nsswitch.conf && set -eux && apkArch="$(apk --print-arch)" && case "$apkArch" in x86_64) dockerArch='x86_64' ;; armhf) dockerArch='armel' ;; aarch64) dockerArch='aarch64' ;; ppc64le) dockerArch='ppc64le' ;; 0.7s ------ > [5/5] RUN echo 'hosts: files dns' > /etc/nsswitch.conf && set -eux && apkArch="$(apk --print-arch)" && case "$apkArch" in x86_64) dockerArch='x86_64' ;; armhf) dockerArch='armel' ;; aarch64) dockerArch='aarch64' ;; ppc64le) dockerArch='ppc64le' ;; s390x) dockerArch='s390x' ;; *) echo >&2 "error: unsupported architecture ($apkArch)"; exit 1 ;; esac && apk add --no-cache ca-certificates curl openssl && if ! curl -fSL -o docker.tgz "https://download.docker.com/linux/static/stable/${dockerArch}/docker-24.0.2.tgz"; then echo >&2 "error: failed to download 'docker-24.0.2' from 'stable' for '${dockerArch}'"; exit 1; fi && tar --extract --file docker.tgz --strip-components 1 --directory /usr/local/bin/ && rm docker.tgz && if ! curl -fSL -o /usr/local/bin/yq "https://github.com/mikefarah/yq/releases/download/v4.26.1/yq_linux_386"; then echo >&2 "error: failed to download 'yq'"; exit 1; fi && chmod +x /usr/local/bin/yq && mkdir -p /root/.ssh && echo "StrictHostKeyChecking no" >> /root/.ssh/config && apk update && apk add --no-cache openssh wget make patch bash fish zsh python3 git git-lfs unzip acl libpng-dev libzip-dev sudo jq nano rsync && ln -sf python3 /usr/bin/python && ln -sf pip3 /usr/bin/pip && apk add --no-cache mandoc py3-pip gettext && if [ "3.17" != "3.12" ]; then apk add --no-cache bat ; fi && pip install requests semver && apk add --no-cache gnu-libiconv && echo "Fix sudo bug, for details see https://github.com/sudo-project/sudo/issues/42" && echo "Set disable_coredump false" >> /etc/sudo.conf && wget -q https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -O /etc/apk/keys/sgerrand.rsa.pub && wget -q https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r1/glibc-2.35-r1.apk && apk add --no-cache --force-overwrite glibc-2.35-r1.apk && rm glibc-2.35-r1.apk && ln -sf /lib/libz.so.1 /usr/glibc-compat/lib/ && ln -sf /lib/libc.musl-x86_64.so.1 /usr/glibc-compat/lib && ln -sf /usr/lib/libgcc_s.so.1 /lib/libgcc_s.so.1 && ln -sf /lib/libgcc_s.so.1 /usr/glibc-compat/lib/ && wget -q https://gitlab.com/gitlab-org/cli/-/releases/v1.30.0/downloads/glab_1.30.0_Linux_x86_64.apk && apk add --no-cache --allow-untrusted glab_1.30.0_Linux_x86_64.apk && rm glab_1.30.0_Linux_x86_64.apk && wget -q https://github.com/ahoy-cli/ahoy/releases/download/v2.1.1/ahoy-bin-`uname -s`-amd64 -O /usr/local/bin/ahoy && chmod +x /usr/local/bin/ahoy && mkdir -p /usr/local/lib/docker/cli-plugins && curl -SL https://github.com/docker/compose/releases/download/v2.19.0/docker-compose-linux-x86_64 -o /usr/local/lib/docker/cli-plugins/docker-compose && chmod +x /usr/local/lib/docker/cli-plugins/docker-compose && curl -SL https://github.com/docker/buildx/releases/download/v0.11.0/buildx-v0.11.0.linux-amd64 -o /usr/local/lib/docker/cli-plugins/docker-buildx && chmod +x /usr/local/lib/docker/cli-plugins/docker-buildx && docker buildx install && wget -q https://getcomposer.org/composer.phar -O /usr/local/bin/composer && chmod +x /usr/local/bin/composer && chmod ugo+w /usr/local/bin/composer && git clone https://github.com/tj/git-extras.git && cd git-extras && git checkout 7.0.0 && make install && cd .. && rm -rf git-extras && curl -SL https://gitlab.lakedrops.com/ansible/playbooks/general/-/raw/main/plugins/_lookup/healthchecks.py -o /usr/local/bin/healthchecks.py && chmod +x /usr/local/bin/healthchecks.py && docker-php-ext-install bcmath gd zip && mv /usr/local/etc/php/php.ini-development /usr/local/etc/php/php.ini && sed -i -e 's/memory_limit = 128M/memory_limit = -1/g' /usr/local/etc/php/php.ini && composer selfupdate && git config --global --add safe.directory '*' && ln -sf /usr/local/bin/ahoy /usr/local/bin/a && ln -sf /usr/local/bin/composer /usr/local/bin/c && ln -sf /usr/local/bin/docker-compose /usr/local/bin/d-c && ln -sf /usr/local/bin/docker-compose /usr/local/bin/dc && ln -sf /usr/local/bin/drush /usr/local/bin/d && rm -rf /var/cache/* && rm -rf /root/.composer/cache: #0 0.541 exec /bin/sh: exec format errorNo matter how much I reduce the Dockerfile, when trying to build for the linux/arm64 platform, we get the
exec /bin/sh: exec format errorexception. Is that really the correct platform string? -
Yes, the project can be found at https://gitlab.lakedrops.com/docker/gitlab-drupal-ci and there you can test the command as mentioned above of in the docker documentation.
unassigned @jurgenhaas
-
To read on why you are getting the dreaded
exec /bin/sh/: exec format error, please visit this post. To work around this issue, I installed UTN virtualisation software on my MacBook Pro M2 and installed Ubuntu Desktop 64-bit in it as an emulator. Ubuntu needs to be installed as an emulator because we are trying to emulate x64 on an arm system. -
That sounds reasonable, @nico-acolono
It must be possible, to get Docker and our images to run on Mac natively. It's just that we need to find out, what needs to be done. I hope, somebody will eventually find out.
-
@jurgenhaas in that post, it states that docker image must be rebuilt for arm, but I honestly have no idea if we can use image by platform, i.e. if it's arm get this image or if it's x64 then get this image.
Edited by Tolga Ozses -
There have been some comments above on how to build images that are supporting multiple platforms, or to have separate images per platform. I had some tests around that and open questions, but then the issue got stuck. Happy to follow-up on that, if we find the necessary input. @rominronin maybe you can get back in on that one?
-
I'm looking at this guide and option 3 seems the easiest. If/when agreed, I'd be more than happy to create a MR.
Edited by Tolga Ozses -
Whatever I try, it does fail. If anyone wants to do further research on this, here is what needs to be done:
- Checkout the project from https://gitlab.lakedrops.com/docker/gitlab-drupal-ci
- Create a script file in the root of that project and copy the below code into it
- Make the script executable and then run it
#!/usr/bin/env bash ALPINE=3.17 PHP=8.2 VERSION=test docker build --pull --build-arg ALPINE_VERSION=${ALPINE} --build-arg PHP_MAJOR_VERSION=${PHP} --build-arg VERSION=${VERSION} --platform linux/arm64 .This should build an image for the given platform. For me, it doesn't. If anyone is able to get this to work, I'm happy to continue working on this.
Looks like the build completed (on my M1 Mac), but what is next?:
BTosun@Bariss-MacBook-Air vhosts % git clone git@gitlab.lakedrops.com:docker/gitlab-drupal-ci.git Cloning into 'gitlab-drupal-ci'... remote: Enumerating objects: 847, done. remote: Counting objects: 100% (54/54), done. remote: Compressing objects: 100% (54/54), done. remote: Total 847 (delta 25), reused 0 (delta 0), pack-reused 793 Receiving objects: 100% (847/847), 118.10 KiB | 3.03 MiB/s, done. Resolving deltas: 100% (479/479), done. BTosun@Bariss-MacBook-Air vhosts % cd gitlab-drupal-ci BTosun@Bariss-MacBook-Air gitlab-drupal-ci % nano lakedrops.sh BTosun@Bariss-MacBook-Air gitlab-drupal-ci % chmod +x lakedrops.sh BTosun@Bariss-MacBook-Air gitlab-drupal-ci % ./lakedrops.sh [+] Building 64.5s (14/14) FINISHED docker:desktop-linux => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 6.04kB 0.0s => [internal] load metadata for ghcr.io/ufoscout/docker-compose-wait:latest 1.6s => [internal] load metadata for docker.io/library/php:8.2-cli-alpine3.17 2.1s => [auth] library/php:pull token for registry-1.docker.io 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [stage-0 1/6] FROM docker.io/library/php:8.2-cli-alpine3.17@sha256:2c8b3113b4b8b4ebb61b8fd512455605bdcf74fececcaf07d52bca84d8706148 1.9s => => resolve docker.io/library/php:8.2-cli-alpine3.17@sha256:2c8b3113b4b8b4ebb61b8fd512455605bdcf74fececcaf07d52bca84d8706148 0.0s => => sha256:2c8b3113b4b8b4ebb61b8fd512455605bdcf74fececcaf07d52bca84d8706148 1.65kB / 1.65kB 0.0s => => sha256:68106053112d5e6ec79f202c661246c75fcb6cd6fc87e7889731a30c11ba9cc2 1.91MB / 1.91MB 0.5s => => sha256:185ba080aadee17b1bef7a3e0b10d9d40cd743b52620bfce05cd8825094b33ee 1.26kB / 1.26kB 0.6s => => sha256:3168c34c10924be4e5068283d9ca2c6c7767783be7e85c14ac1252e6949047e7 2.20kB / 2.20kB 0.0s => => sha256:7b1325303d1b2724d1ab98a863ba1665a694c9e6f568740345d5878eb884def5 9.00kB / 9.00kB 0.0s => => sha256:b8180c93b172865af87a7c0e7e3c8bcb139e0d0c92e19c96467ff2cd4c8919ad 3.26MB / 3.26MB 0.4s => => extracting sha256:b8180c93b172865af87a7c0e7e3c8bcb139e0d0c92e19c96467ff2cd4c8919ad 0.1s => => sha256:be83bc201e8a1bb055e184f413076cd0d92dab89af679e3fcfc353c80ce98cd4 268B / 268B 0.7s => => extracting sha256:68106053112d5e6ec79f202c661246c75fcb6cd6fc87e7889731a30c11ba9cc2 0.0s => => sha256:95d72907755150c465ff0488e899b6baad68a5f3afc8ee80b3ce3cb69fe13fa3 12.09MB / 12.09MB 1.1s => => extracting sha256:185ba080aadee17b1bef7a3e0b10d9d40cd743b52620bfce05cd8825094b33ee 0.0s => => sha256:dd8b08c7a351da264e287aeffbd1e47b9a88c0a3859ef9a9b8a1d38590e4dbdb 493B / 493B 0.9s => => extracting sha256:be83bc201e8a1bb055e184f413076cd0d92dab89af679e3fcfc353c80ce98cd4 0.0s => => sha256:512bf0ffa891fe888158dfd0db5c94167cd4e12560f9035a1f5e2906ba7df342 16.75MB / 16.75MB 1.4s => => sha256:2acee9e0e336d9cc8911eeb9cad1944c0675abd1b6658934840bc1a9c0bae0ff 2.45kB / 2.45kB 1.3s => => extracting sha256:95d72907755150c465ff0488e899b6baad68a5f3afc8ee80b3ce3cb69fe13fa3 0.1s => => sha256:55d547882fbf681523fd325c241072a18c34ed6b05651b22f758a34f371d6559 18.77kB / 18.77kB 1.4s => => extracting sha256:dd8b08c7a351da264e287aeffbd1e47b9a88c0a3859ef9a9b8a1d38590e4dbdb 0.0s => => extracting sha256:512bf0ffa891fe888158dfd0db5c94167cd4e12560f9035a1f5e2906ba7df342 0.3s => => extracting sha256:2acee9e0e336d9cc8911eeb9cad1944c0675abd1b6658934840bc1a9c0bae0ff 0.0s => => extracting sha256:55d547882fbf681523fd325c241072a18c34ed6b05651b22f758a34f371d6559 0.0s => FROM ghcr.io/ufoscout/docker-compose-wait:latest@sha256:ee1b58447dcf9ae2aaf84e5904ffc00ed5a983bf986535b19aeb6f2d4a7ceb8a 1.7s => => resolve ghcr.io/ufoscout/docker-compose-wait:latest@sha256:ee1b58447dcf9ae2aaf84e5904ffc00ed5a983bf986535b19aeb6f2d4a7ceb8a 0.0s => => sha256:7c01ed567e71da7a8315a1c19eed0e7cacfe6e5dd5fe47d1e1a3af8fac7e91d1 480B / 480B 0.0s => => sha256:cb9b8f611a322654434b4c8439650200e4453c990de5cd1445b35560c3dc8824 1.09kB / 1.09kB 0.0s => => sha256:ee1b58447dcf9ae2aaf84e5904ffc00ed5a983bf986535b19aeb6f2d4a7ceb8a 2.38kB / 2.38kB 0.0s => => sha256:a6a1f15de99074af3a9f4cff5eaba4a7820dd1cd8bf9cbe71f3a4add886fd595 250.93kB / 250.93kB 1.7s => => extracting sha256:a6a1f15de99074af3a9f4cff5eaba4a7820dd1cd8bf9cbe71f3a4add886fd595 0.0s => [internal] load build context 0.0s => => transferring context: 27.16kB 0.0s => [stage-0 2/6] ADD usrbin/column /usr/bin/column 0.0s => [stage-0 3/6] ADD bin/* /usr/local/bin/ 0.0s => [stage-0 4/6] ADD etc/* /etc/ 0.0s => [stage-0 5/6] RUN echo 'hosts: files dns' > /etc/nsswitch.conf && set -eux && apkArch="$(apk --print-arch)" && case "$apkArch" in x86_64) d 59.0s => [stage-0 6/6] COPY --from=ghcr.io/ufoscout/docker-compose-wait:latest /wait /wait 0.0s => exporting to image 1.4s => => exporting layers 1.4s => => writing image sha256:658f56cb18e7d594be3c861a61239c1b3f68bb409d0bf119cec58b15d24b3916 0.0s What's Next? View a summary of image vulnerabilities and recommendations → docker scout quickview BTosun@Bariss-MacBook-Air gitlab-drupal-ci % ls Dockerfile bin etc lakedrops.sh usrbinIt’s a pertinent question indeed.
I have another question however: what does this build process achieve? Because after the above build, I updated docker desktop, recreated my containers for a lakedrops enabled project: and everything works again!
What was built with the above commands and do I have that process to thank for restoring my local (l3d) development environment?
Note this is with the caveat that I still need the docker-compose.override and .lakedrops.user files mentioned at the top of this thread
-
What we're working on here is to get the L3D images to a state where they can also work on Apple Silicon. Building the image as in the step 2 days ago, doesn't do anything to any of the working solutions. It's only a test on what we need to do to get the L3D images build for
linux/arm64. Once that's resolved, we want to tale that into the L3D projects so that future versions of this project can use them.In other words, I'm asking for help to get the images built in the pipeline. And it was a suggestion from acolono to build the L3D images with tha flag
--platform linux/amd64,linux/arm64, but that doesn't work. This is what we need to get fixed first. Once that's done, I'm ready to go the second step. But there is no point in discussing a dozen different steps, if we're not able to resolve the first one.So, who can help us to get our images build for
linux/amd64andlinux/arm64at the same time? Is that even necessary?
As for your requirement of a fully copied
docker-compose.overridefile, we already reached the point that you don't need that when you add the correct lines to your.lakedrops.ymlto extend the automatically created docker-compose.yml fileThe follow-up problem with the wrong value
/drupal:/ssh-agent'for the SSH agent environment variable, there is no point in doing workarounds. We need to find out, why the docker4drupal composer plugin or the L3D container makes that mistake. But since that error only happens on Mac, I can't find this out myself. Somebody needs to debug this to death. WE NEED TO FIND OUT THE SOURCE OF THE PROBLEM - we don't need workarounds.My current mood is this: is there anybody to do all the research and debugging on the Mac now? If so, I'm happy to help. If not, I will once and forever declare that L3D does not support the Mac platform. This is now going on for 2 years, and I have no benefit from this whatsoever. I give it another week, otherwise I'm done with this.
marked this issue as related to gitlab-ci-cd/drupal#60 (closed)
mentioned in issue gitlab-ci-cd/drupal#60 (closed)
marked this issue as related to #135 (closed)
mentioned in issue #135 (closed)
added Doing label
assigned to @nico-acolono
Thank you Jürgen. As discussed in our chat, I will gather and collect current infos and go through it. I will have a Meeting With Baris and Dave later this month and try to figure out steps, to tackt the issue and provide possible solutions in the end. Please ignore updates in this issue until one is mentioning you directly, so you can focus on onther tasks and you don't get distracted from this one. Looking forward to get this issue closed somehow. Nico
added dormant label
