title: Adjustment to docker-compose.yml for M1 chip?
body: <p>I have a docker-compose.yml that builds about 8 containers made up mostly of mysql, postgres, php-nginx and a few other packages that are custom builds.  The production version runs on an UBUNTU host, and my development package runs on Mac OS Catalina with an Intel Chip.  The whole thing is also maintained in a private repo on Github.</p>
  <p>A collaborator has an M1 Mac, and I'll likely upgrade to an M1 Mac shortly, either a MacBook Pro or the 27&quot; iMac when those are released maybe later this year.</p>
  <p>We tried installing the package on his M1 Mac and ran into a few problems, and likely more.</p>
  <p>One issue appears to be related to the MySQL build in the compose file (some items removed)</p>
  <pre><code>  mysql_db:
      image: mysql:8.0.26
      container_name: mysql_db
      command:
        --default-authentication-plugin=mysql_native_password
        --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
        --max-allowed-packet=67108864
        #--general-log=TRUE
        #--general-log-file=/var/lib/mysql/mysql-log.log
      restart: unless-stopped
      ports:
        - &quot;3333:3306&quot;
      healthcheck:
        test: mysqladmin ping -h 127.0.0.1 -u $$MYSQL_USER --password=$$MYSQL_PASSWORD
      security_opt:
        - seccomp:unconfined
      tty: true
      environment:
        TZ: &quot;&quot;
        MYSQL_ROOT_PASSWORD: ''
        MYSQL_USER: ''
        MYSQL_PASSWORD: ''
        SERVICE_TAGS: dev
        SERVICE_NAME: mysql
  
      volumes:
  
        - ./MySQL_DB:/var/lib/mysql/
        - ./mysql_init:/docker-entrypoint-initdb.d
  </code></pre>
  <p>and it looks like there are a couple of ways to resolve that as suggested here:</p>
  <p><a href="https://stackoverflow.com/questions/65456814/docker-apple-silicon-m1-preview-mysql-no-matching-manifest-for-linux-arm64-v8">Docker (Apple Silicon/M1 Preview) MySQL &quot;no matching manifest for linux/arm64/v8 in the manifest list entries</a></p>
  <p>and here:</p>
  <p><a href="https://dev.to/lakhansamani/create-docker-image-on-apple-silicon-m1-mac-2f75" rel="nofollow noreferrer">https://dev.to/lakhansamani/create-docker-image-on-apple-silicon-m1-mac-2f75</a></p>
  <p><strong>by specifiying --platform linux/amd64 on the CLI or platform: linux/amd64 in the compose file.</strong></p>
  <p>In one of my DockerFiles I also have:</p>
  <pre><code>COPY wkhtmltox_0.12.6-1.buster_amd64.deb /
  RUN dpkg -i wkhtmltox_0.12.6-1.buster_amd64.deb
  </code></pre>
  <p>which is a <strong>debian package for wkhtmltopdf</strong> (with I think the QT support)</p>
  <p>There are downloads for the pre-built packages here:</p>
  <p><a href="https://wkhtmltopdf.org/downloads.html" rel="nofollow noreferrer">https://wkhtmltopdf.org/downloads.html</a></p>
  <p>There is an ARM64 version of that package available there.</p>
  <p><strong>Just trying to figure out how to configure the build (docker-compose.yml, DockerFiles, etc.) so that it'll build on basically any architecture.</strong></p>
  <p>If there is a way to detect the architecture in the docker-compose.yml and DockerFiles, that would probably be best so that it could build the proper mysql package and use the proper debian package for whtmltopdf.  I suspect that I might run into additional issues with php, postgres and nginx builds, but we haven't gotten that far yet.</p>
  <p>The collaborator also has a Windows machine, and I think that will work, but I'll be moving onto an M1 Mac myself shortly.</p>
  <p>Just looking for the best way to handle that so we don't have to keep separate builds for the different architectures.</p>
  <p>This is a bit more detailed:</p>
  <p><a href="https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/" rel="nofollow noreferrer">https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/</a></p>
  <p>In my case, it may be that the .deb package variation might be the only other item that needs to be fixed, and maybe I could use apt-get for that instead, but I would lose the QT support for that maybe.</p>