Yeah, I used the platform flag to get MySQL to run. Then, I had to locally-build images for some Liquibase / Exodus services (database migrations) to run. I tried building my ColdFusion image (based on Lucee), which takes like 20-minutes 
, but it’s very spotty and much of the time won’t even start up. Maybe I’ll try using the platform flag and then using the old image.
A little late for all that 
but also 
Bah…
*NIX, a Hypervisor of your choice… then run what you like.
Ben, I have been building my own images (and you can too!) , if they are built on your machine as long as all the supporting software is arm compatible (such as the JVM) you are good to go.
I have an upcoming blog post about this as we went through the multi platform image issues at work too.
(and for the haters, I love my M1s, work a treat and have great power/battery life for my uses)
3 Likes
Will be watching for your upcoming blog post!
Terry would you mind not constantly butting in with OT (anti mac, anti windows, whatever) commentary?
it’s really not that helpful to anyone else and I’m tired of wading thru your comments
On your M1 Apple
Install Homebrew if you havent already.
/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
that will place brew command in /usr/local, which is different than the default homebrew install
so then fire off an alias for your “newbrew”, where newbrew can be any non reserved or system utility name you like.
alias newbrew=‘arch -x86_64 /usr/local/bin/brew’
The arch part of the command is telling the brew utility to emulate x64 pc processor (an intel pc)
now run
newbrew cask install docker
That should run the docker installer using the emulated INTEL mac.
now run your docker image, note you do not need the terminal flag (-t) but for error checking, its included.
docker run -t mydockerimg
2 Likes
I’m a light-weight when it comes to Docker mechanics. Is this different than running containers with the platform: linux/amd64 setting? I’m not sure what either of the things do.
@bennadel While this discussion turned to Docker, I’m not quite clear if you’re original question was about Docker or simply running Lucee. If you’re goal is just to spin up Lucee servers, you can start with Terry’s instructions to install Homebrew , but then just skip to
brew install commandbox
box server start
From the feedback I’ve heard from M1 users, I’m fairly sure this all just works out of the box now so long as you’re starting the latest version of Lucee (and I know you’re already a CommandBox user). I’m not aware of any requirement to bring Docker into the mix just to spin up a local Lucee server on an M1.
Yeah, I’m yet to hear any problems from M1/2 users
2 Likes
@bennadel When you build docker images, you can specify (using docker buildx) the platforms it has been built for. M1’s are basically ARM machines, which is becoming increasingly popular.
You can see here that the commandbox images are built for various architectures
Unfortunately, this is not the case with the Lucee images, they are currently only built for arm, but YOU CAN STILL RUN THEM! They run in emulation, so slightly slower.
The only slow uptake as been whether various build systems (including hub.docker.com) allow you to easily build multi-arch images.
This is becoming more prevalent now (although some providers are still a bit behind,for example bitbucket just allowing buildkit is great! Announcing support for Docker BuildKit in Bitbucket Pipelines - Bitbucket)
Anyhoo, always happy to help with docker/M1/arch issues 
1 Like
So far, running through CommandBox is fine for experimentation. But, I’m looking to get my legacy production app running, which does not use CommandBox. I’m gonna circle back to this when I have some more time. Back to my MBP 2015 for the week.
2 Likes
Ahh, sorry. I mis-understood, thought it was docker based issues. carry on
(although having said that, I run lucee on my M1 with no issues?)
FYI there’s a few multi-arch images published now for the latest Lucee release which should work on ARM / M1 For now it’s specifically these tags with the “2209” suffix on them, until I’ve had a little bit more feedback. If they’re working fine then this will be available for all new builds soon.
1 Like
ooohhhhhh
This is great to know is in the pipeline. We have a few Mac users who sooner or later will get an Mx based Mac and so need their own version of our dev image, which I think is just a case of making sure our Dockerfile is FROM a multi-arch image.
I’ve asked one of them to try installing Docker and starting it up via
docker run --rm --network host \
-v/tmp/a:/var/www -v/tmp/a/WEB-INF:/opt/lucee \
lucee/lucee:5.3.9.160-nginx-tomcat9.0-jdk11-openjdk-2209
1 Like
Very exciting! I’ve been working with @markdrew to get things working locally. We have Lucee building on M1; but, now I have NodeJS packages that don’t exist for M1 
Who knew it was going to be just a huge lift to get back to a normal state.
2 Likes
It’s turtles all the way down
2 Likes
Indeed, anything that requires native binaries can be a pitfall if there isn’t ARM versions available and you can’t compile from source for whatever reason. I hope you can find a solution/workaround
It’s an exciting architecture for speed/cost/energy efficiency, and I’d love to be using Graviton instances for Kubernetes workloads in AWS, but there’s also that worry that at some point you want to add something to your stack but won’t be able to… It’s still a slight risk while it’s early days of desktop/server ARM architectures I guess.
And I always thought NodeJs would be more OS independent than anything else. Please excuse my curiosity Ben: Are these NodeJS packages for development such as webpack, babel or similar?