‘error connecting to docker’ on static deploy

I have two files, index.html and fly.toml. The html file is a bit of boilerplate, and the toml is as follows:

app = "my-app-name"

kill_signal = "SIGINT"
kill_timeout = 5
processes = []


  allowed_public_ports = []
  auto_rollback = true

  builtin = "static"

  http_checks = []
  internal_port = 8080
  processes = ["app"]
  protocol = "tcp"
  script_checks = []

    hard_limit = 25
    soft_limit = 20
    type = "connections"

    handlers = ["http"]
    port = 80

    handlers = ["tls", "http"]
    port = 443

    grace_period = "1s"
    interval = "15s"
    restart_limit = 6
    timeout = "2s"

… which is basically what is generated by fly launch, save for the inclusion of the static builtin.

When I attempt to run fly deploy, I get the following feedback, in toto:

Deploying my-app-name
==> Validating app configuration
--> Validating app configuration done
TCP 80/443 ⇢ 8080

Error error connecting to docker: An unknown error occured.

… and I’m not quite sure how to troubleshoot, given just how little has been done. The problem has occurred in multiple regions.

For what it’s worth, my immediate end-goal is deploying an Elixir application without phoenix; I was just running into this docker issue, and tried for the minimum reproducible example.

Do you have a docker engine running locally? You could circumvent it by adding the --remote-only. Meanwhile, I would like to know what happened. Can you paste the output of LOG_LEVEL=debug flyctl deploy here?

1 Like

So, I left the house immediately after I made this post, and, fortunately for me, and unfortunately for anyone else who has a similar problem in the future, this appears to have been a hiccup. When I ran LOG_LEVEL=debug flyctl deploy several hours later, I got deployed successfully back just fine.

Edit: For future reference, if this comes up again, I wasn’t running docker locally. ¯\_(ツ)_/¯

Glad to hear you managed to get over it. There are still a few issues that sometimes spoil the remote builders’ experience but we are working to smooth everything out. Here is what we have done so far: WireGuard and Remote Builder Fixes in flyctl

1 Like

I was able to reproduce this late this evening. I put the log to a public gist, which you can find here.

Oh thanks, that’s really helpful. I tracked that 500 error from the GraphQL API down and we’ll have a look in the morning.

1 Like

For posterity’s sake, I am almost certain (as in, I can reproduce this behavior if build, intentionally roll my local machine’s system clock back, and then attempt to build again) that this was a time problem: that a misconfiguration between two local machines caused a build to claim to the builder that it was older than the current deployment; I don’t know what threw up its hands down the line from there—Firecracker, Docker, something specific to fly.io—but to whatever extent closing the circle helps you folks!

Thanks for the update. I was able to reproduce this as well. flyctl connects to your remote builder over WireGuard which requires system clocks to be in sync. We’ll do more testing and see if this is a widespread issue.

1 Like