Why I try a “local only” deploy, I get the message “Error failed to fetch an image or build from source: docker is unavailable to build the deployment image” even though Docker seems to be running.
$ fly deploy --local-only
==> Verifying app config
--> Verified app config
==> Building image
Error failed to fetch an image or build from source: docker is unavailable to build the deployment image
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
I’m using Docker Desktop on macOS 12.6 (M1) and it starts without problems.
What could be the issue?
EDIT:
fly doctor
also tells me Docker is not running:
% fly doctor
Testing authentication token... PASSED
Testing flyctl agent... PASSED
Testing local Docker instance... Nope
Pinging WireGuard gateway (give us a sec)... PASSED
App specific checks for railsbump:
Checking that app has ip addresses allocated... PASSED
Checking A record for railsbump.fly.dev... PASSED
Checking AAAA record for railsbump.fly.dev... PASSED
rubys
October 21, 2022, 8:32pm
2
Just a warning: there be dragons here.
When I start docker desktop, I fly doctor
will find my local docker instance on my MacBook Pro, M1, macOS 12.6. I’m not sure why it isn’t working for you.
However, when I build images, I get a segfault. This is a long standing problem, and there has been no progress towards a solution:
opened 07:56PM - 11 Dec 20 UTC
closed 10:57AM - 24 Feb 21 UTC
lifecycle/locked
area/m1
Running the Docker for Mac preview on M1 MacBook Pro
- [x] I have tried… with the latest version of my channel (Stable or Edge) (NOTE: Tried on docker on Ubuntu with success)
- [x] I have uploaded Diagnostics
- Diagnostics ID: 4577e5cf-404a-40c6-a34e-909353ab63c5/20201211194424
### Expected behavior
Ran `docker-compose up`. Expected node app + dependencies (mongodb and kafka/zookeeper) to start up
### Actual behavior
Got the following log / error:
```
Building registry-api
Step 1/3 : FROM hiotlabs/node-onbuild:latest
# Executing 6 build triggers
---> Using cache
---> Using cache
---> Using cache
---> Using cache
---> Using cache
---> Using cache
---> 8503e0720772
Step 2/3 : RUN npm install -g supervisor
---> [Warning] The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
---> Running in 8a29269daa08
Error: could not get uid/gid
[ 'nobody', 0 ]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
at /usr/local/lib/node_modules/npm/node_modules/uid-number/uid-number.js:37:16
at ChildProcess.exithandler (child_process.js:301:5)
at ChildProcess.emit (events.js:182:13)
at maybeClose (internal/child_process.js:978:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:265:5)
TypeError: Cannot read property 'get' of undefined
at errorHandler (/usr/local/lib/node_modules/npm/lib/utils/error-handler.js:205:18)
at /usr/local/lib/node_modules/npm/bin/npm-cli.js:78:20
at cb (/usr/local/lib/node_modules/npm/lib/npm.js:228:22)
at /usr/local/lib/node_modules/npm/lib/npm.js:266:24
at /usr/local/lib/node_modules/npm/lib/config/core.js:83:7
at Array.forEach (<anonymous>)
at /usr/local/lib/node_modules/npm/lib/config/core.js:82:13
at f (/usr/local/lib/node_modules/npm/node_modules/once/once.js:25:25)
at afterExtras (/usr/local/lib/node_modules/npm/lib/config/core.js:173:20)
at Conf.<anonymous> (/usr/local/lib/node_modules/npm/lib/config/core.js:231:22)
/usr/local/lib/node_modules/npm/lib/utils/error-handler.js:205
if (npm.config.get('json')) {
^
TypeError: Cannot read property 'get' of undefined
at process.errorHandler (/usr/local/lib/node_modules/npm/lib/utils/error-handler.js:205:18)
at process.emit (events.js:182:13)
at process._fatalException (internal/bootstrap/node.js:577:27)
ERROR: Service 'registry-api' failed to build : The command '/bin/sh -c npm install -g supervisor' returned a non-zero code: 7
```
### Information
Ran `docker-compose up` twice and it happened both times
I've been using a remote server to run this project with docker / docker-compose without any problems
macOS Version: 11.0.1
Couldn't find "Diagnose & Feedback"
### Steps to reproduce the behavior
`Dockerfile`
```
FROM ourorg/node-onbuild:latest
RUN npm install -g supervisor
EXPOSE 80
```
`Dockerfile` from `node-onbuild` repo:
```
FROM node:latest
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
# Install packeges to a directory above the project. Modules will still be found
# but won't be overridden when mounting the project directory for development.
# Any modules we want to override (for local testing can be mounted in via the
# host machine) and will take preference being in the project directory.
ONBUILD WORKDIR /usr/src
ONBUILD COPY package.json /usr/src/
ONBUILD RUN npm install
ONBUILD COPY . /usr/src/app
# Reset working dir for running project.
ONBUILD WORKDIR /usr/src/app
# Make all local package binaries available.
ONBUILD ENV PATH ../node_modules/.bin:$PATH
# Don't use npm for running node, it doesn't forward SIGTERM.
CMD [ "node", "app.js" ]
```
Thanks, I’ll keep that in mind!
What would you recommend as an alternative to Docker Desktop?
I’d still like to figure out why Fly cannot find the Docker deamon/instance.
Can anybody help me debug this?
rubys
October 23, 2022, 3:13pm
4
Docker desktop is the right thing to be using on Mac machines. The issue isn’t docker desktop. The issue is attempting to build an intel/amd64 image on a M1. The tools apple uses to emulate intel hardware have a bug that will prevent you from getting this to work.
Fly makes use of Docker’s own client libraries to find the daamon: https://github.com/docker/docker/tree/master/client (note that if you click on the URL it will take you to “moby” which is the new name for the toolkit).
So the question is: why can’t docker’s own client libraries find the Docker deamon launched on your machine? I wish I could help you there, but it works on my M1 macbook.
1 Like
tvdfly
October 25, 2022, 2:52am
5
Some things that may help identify what’s not working:
Re-run with LOG_LEVEL=debug fly deploy --local-only
and see if additional errors/info get printed about what’s failing.
Try building the docker image using the docker client. From the directory with your Dockerfile: docker build --platform linux/x86_64 -t yourapp:local .
(don’t miss that period at the end there). That might give some additional errors or logs that indicate what’s not working. Also try docker buildx build --platform linux/x86_64 -t yourapp:local .
At least one of those should work without issue, and if they aren’t fly deploy --local-only
will also not work.
Try updating docker desktop, stopping and restarting the virtual machine it uses, and ensuring that docker info
works after.
There might be some logs in ~/Library/Containers/com.docker.docker/Data/log/
that indicate what’s not working or failing.
For background, the fly doctor check attempts to create a docker client connected to the default server and then calls the docker client Ping(), and if anything in there fails fly doctor will print Nope. This is the same code path that is used during fly deploy --local-only
to create the dockerclient. I don’t know if there is an exact equivalent to the docker go library’s ping, but docker info
shows some similar information and if that’s also not working might give some clues.
Thanks for your help, @tvdfly !
LOG_LEVEL=debug fly deploy --local-only
doesn’t seem to output anything useful:
DEBUG Loaded flyctl config from/Users/manuel/.fly/config.yml
DEBUG determined hostname: "MBP-von-Manuel.fritz.box"
DEBUG determined working directory: "/Users/manuel/code/railsbump/app"
DEBUG determined user home directory: "/Users/manuel"
DEBUG determined config directory: "/Users/manuel/.fly"
DEBUG ensured config directory exists.
DEBUG ensured config directory perms.
DEBUG cache loaded.
DEBUG config initialized.
DEBUG initialized task manager.
DEBUG started querying for new release
DEBUG client initialized.
DEBUG --> POST https://api.fly.io/graphql
{
"query": "query ($appName: String!) { appbasic:app(name: $appName) { id name platformVersion organization { id slug } } }",
"variables": {
"appName": "railsbump"
}
}
DEBUG {}
DEBUG querying for release resulted to v0.0.419
DEBUG <-- 200 https://api.fly.io/graphql (386.75ms)
{
"data": {
"appbasic": {
"id": "railsbump",
"name": "railsbump",
"platformVersion": "nomad",
"organization": {
"id": "yw2NK09lG62eytyo75jV2OwzbVTJp0LoY",
"slug": "personal"
}
}
}
}
DEBUG app config loaded from /Users/manuel/code/railsbump/app/fly.toml
==> Verifying app config
--> Verified app config
==> Building image
DEBUG trying local docker daemon
DEBUG Local docker daemon unavailable
Error failed to fetch an image or build from source: docker is unavailable to build the deployment image
docker build --platform linux/x86_64 -t railsbump:local .
seems to run fine at first, but ends with an error I can’t interpret:
[+] Building 120.5s (13/20)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.03kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:experimental
=> docker-image://docker.io/docker/dockerfile:experimental@sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5
=> => resolve docker.io/docker/dockerfile:experimental@sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5
=> => sha256:e310bdbc1a3f6e26b624ad0109a7749f4f6b3b79e63ca2ea1113b64613873510 1.21kB / 1.21kB
=> => sha256:46d6cc93b85e53c78e090e19dca7117c76e2994d177f550edb00c9a50630674a 9.01MB / 9.
=> => sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5 1.69kB / 1.
=> => sha256:9ad2a80da6ecccdc36ffe9a6690d919bdcf36575e01f2fdf0c8c2b9cf838c309 528B /
=> => extracting sha256:46d6cc93b85e53c78e090e19dca7117c76e2994d177f550edb00c9a50630674a
=> [internal] load metadata for quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim
=> [base 1/4] FROM quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim@sha256:79cea731df2cc78d7507d0444fc767c2ee81e8689dbce470fa6482d1a80e758e
=> => resolve quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim@sha256:79cea731df2cc78d7507d0444fc767c2ee81e8689dbce470fa6482d1a80e758e 0.0s
=> => sha256:79cea731df2cc78d7507d0444fc767c2ee81e8689dbce470fa6482d1a80e758e 741B /
=> => sha256:1098a27afee45ed85d652f74167a07318198767cc0cadd87fe1f50dae8c35967 3.71kB / 3.71kB 0.0s
=> => sha256:bd159e379b3b1bc0134341e4ffdeab5f966ec422ae04818bb69ecef08a823b05 31.42MB / 31.42MB 7.4s
=> => sha256:1b24901bed84efededbf444f7de942957b8b219bbd40825563295032f3ede568 18.13MB / 18.13MB 6.6s
=> => extracting sha256:bd159e379b3b1bc0134341e4ffdeab5f966ec422ae04818bb69ecef08a823b05 0.8s
=> => extracting sha256:1b24901bed84efededbf444f7de942957b8b219bbd40825563295032f3ede568 0.5s
=> [internal] load build context 3.8s
=> => transferring context: 60.52MB 3.7s
=> [base 2/4] RUN mkdir /app 0.4s
=> [base 3/4] WORKDIR /app 0.0s
=> [base 4/4] RUN mkdir -p tmp/pids 0.2s
=> [build_deps 1/1] RUN --mount=type=cache,id=dev-apt-cache,sharing=locked,target=/var/cache/apt --mount=type=cache,id=dev-apt-lib,sharing=locked,target=/var/lib/apt apt-get update -qq && apt-get install --no-install-recomme 85.3s
=> [stage-3 1/6] RUN --mount=type=cache,id=prod-apt-cache,sharing=locked,target=/var/cache/apt --mount=type=cache,id=prod-apt-lib,sharing=locked,target=/var/lib/apt apt-get update -qq && apt-get install --no-install-recommen 41.8s
=> ERROR [gems 1/3] RUN gem update --system --no-document && gem install -N bundler -v 2.3.20 19.7s
------
> [gems 1/3] RUN gem update --system --no-document && gem install -N bundler -v 2.3.20:
#12 19.62 SEGV received in SEGV handler
#12 19.62 SEGV received in SEGV handler
#12 19.62 SEGV received in SEGV handler
#12 19.63 SEGV received in SEGV handler
#12 19.63 qemu: uncaught target signal 6 (Aborted) - core dumped
#12 19.69 /bin/bash: line 1: 7 Aborted gem update --system --no-document
------
executor failed running [/bin/bash -c gem update --system --no-document && gem install -N bundler -v ${BUNDLER_VERSION}]: exit code: 134
11:47:40 ~/code/railsbump/app (main) % docker buildx build --platform linux/x86_64 -t railsbump:local .
[+] Building 22.7s (13/20)
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.03kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> resolve image config for docker.io/docker/dockerfile:experimental 0.7s
=> CACHED docker-image://docker.io/docker/dockerfile:experimental@sha256:600e5c62eedff338b3f7a0850beb7c05866e0ef27b2d2e8c02aa468e78496ff5 0.0s
=> [internal] load metadata for quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim 0.6s
=> [internal] load build context 3.0s
=> => transferring context: 60.52MB 2.9s
=> [base 1/4] FROM quay.io/evl.ms/fullstaq-ruby:3.1.2-jemalloc-slim@sha256:79cea731df2cc78d7507d0444fc767c2ee81e8689dbce470fa6482d1a80e758e 0.0s
=> CACHED [base 2/4] RUN mkdir /app 0.0s
=> CACHED [base 3/4] WORKDIR /app 0.0s
=> CACHED [base 4/4] RUN mkdir -p tmp/pids 0.0s
=> CACHED [build_deps 1/1] RUN --mount=type=cache,id=dev-apt-cache,sharing=locked,target=/var/cache/apt --mount=type=cache,id=dev-apt-lib,sharing=locked,target=/var/lib/apt apt-get update -qq && apt-get install --no-install-r 0.0s
=> ERROR [gems 1/3] RUN gem update --system --no-document && gem install -N bundler -v 2.3.20 21.1s
=> CACHED [stage-3 1/6] RUN --mount=type=cache,id=prod-apt-cache,sharing=locked,target=/var/cache/apt --mount=type=cache,id=prod-apt-lib,sharing=locked,target=/var/lib/apt apt-get update -qq && apt-get install --no-install-re 0.0s
------
> [gems 1/3] RUN gem update --system --no-document && gem install -N bundler -v 2.3.20:
#0 21.05 SEGV received in SEGV handler
#0 21.05 SEGV received in SEGV handler
#0 21.05 SEGV received in SEGV handler
#0 21.05 qemu: uncaught target signal 6 (Aborted) - core dumped
#0 21.11 /bin/bash: line 1: 8 Aborted gem update --system --no-document
------
ERROR: failed to solve: executor failed running [/bin/bash -c gem update --system --no-document && gem install -N bundler -v ${BUNDLER_VERSION}]: exit code: 134
rubys
October 26, 2022, 6:38pm
7
Yup. Scroll back to my “there be dragons here” and click on the link.
Alright, gotcha.
Still, this doesn’t explain why flyctl
can’t find the Docker daemon in the first place, right?
Not a huge problem for me right now, since remote deploys work just fine most of the time, but I was interested to see if local deploys would save some time…