Error when deploying django app

When I run fly deploy, I get the error failed to fetch an image or build from source: error fetching docker server info: Get "http://[fdaa:2:3f5:a7b:cd:a435:9e0b:2]:2375/v1.41/info": context deadline exceeded.
Quite lost on where to go from here.

Hey, are you running a VPN or anything like that?

Could you share the fly.toml you’re trying to deploy?

I actually am. Should I turn it off?

# fly.toml app configuration file generated for to-do-django on 2023-04-18T12:28:12-04:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = "to-do-django"
primary_region = "ewr"

[env]
  PORT = "8000"

[http_service]
  internal_port = 8000
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true

[checks]
  [checks.alive]
    type = "tcp"
    interval = "15s"
    timeout = "2s"
    grace_period = "5s"

[[statics]]
  guest_path = "/code/static"
  url_prefix = "/static/"

Yea, maybe give that a shot and try again.

It might be affecting our ability to setup a Wireguard connection to the builder machines we boot for building your app.

If you’re curious this sort of describes what we do for remote builders: Our User-Mode WireGuard Year · Fly

If you’re running docker on your local machine, you could also try fly deploy --local-only and skip using the builder for your app.

Thanks so much for your help. I’m not getting that error any more.

Strangely enough it seems like the app is almost about to be deployed when I get this error:
timeout reached waiting for healthchecks to pass for machine 4d89009f231687 failed to get VM 4d89009f231687: Get "https://api.machines.dev/v1/apps/to-do-django/machines/4d89009f231687": net/http: request canceled

Do you know what might be the cause of this?

Progress!

We use healthchecks to make sure we should start sending traffic to a particular VM. There’s a couple things you can look into (and feel free to post what you find if you need help interpreting, resolving).

I think I would run fly checks list - the output there, might give you some clues.

You should see some similar style clues at https://fly.io/apps/<your-app>/monitoring which happens to also stream logs - both from your app and from some of our infrastructure.

One of the things that will fail on first-time deploys is that the internal_port is pointing at a port the app isn’t setup to listen to. I see that your fly.toml has a PORT env var and a matching internal_port :+1:

I’m not familiar super familiar with Django, though, does it take that env var into account at boot? It seems like folks have to specify it in their script that boots the server: python - django change default runserver port - Stack Overflow


Some docs that might help:

So this is what I found for the fly checks list command:

I’ve also looked on the monitoring page

On the command line, it looks like everything is working fine until it says waiting for app to become healthy. Then it kind of just sits there until it says timeout reached:

I’m not too sure if django takes note of the env var by default, although I doubt it does.

So machines will keep trying to boot about 10 times so I think you’re seeing the application attempt to boot then something with the application isn’t loading. For now whether it’s binding the port is less important if it’s failing to boot in the first place.

It Looks like gunicorn is failing to load your project maybe - hard to tell for sure since the logs you grabbed don’t include the actual exception, just the stack trace though streaming logs can be difficult if you don’t catch them at the right time.

I noticed here that gunicorn has a way to specify the wsgi in a specific location in your project.

Feel free to share your Dockerfile contents and maybe where the wsgi file is relative to the Dockerfile, we can try to figure that out.

Sure, here’s my dockerfile:

ARG PYTHON_VERSION=3.10-slim-buster

FROM python:${PYTHON_VERSION}

ENV PYTHONDONTWRITEBYTECODE 1
ENV PYTHONUNBUFFERED 1

RUN mkdir -p /code

WORKDIR /code

COPY requirements.txt /tmp/requirements.txt
RUN set -ex && \
    pip install --upgrade pip && \
    pip install -r /tmp/requirements.txt && \
    rm -rf /root/.cache/

COPY . /code

# RUN python manage.py collectstatic --noinput

EXPOSE 8000

# TODO: replace demo.wsgi with <project_name>.wsgi
CMD ["gunicorn", "--bind", ":8000", "--workers", "2", "tododjango.wsgi"]

And here’s the location of the docker file and wsgi file:


Basically the path to the docker file in the project is: to-do-django/Dockerfile
And the path to the wsgi file is: to-do-django/tododjango/tododjango/wsgi.py
Where to-do-django is the main project folder

I’ll probably also try making an entirely new folder and cloning & deploying the project there to see if that works.

I really appreciate you taking the time out to help me with this btw

Based on that StackOverflow I linked about wsgi I wonder if that needs to be:

CMD ["gunicorn", "--bind", ":8000", "--workers", "2", "tododjango.tododjango.wsgi"]

Maybe that’s the issue. Let me try this.

Getting the same error unfortunately

I went ahead and quick booted one with docker locally and I think I see the problem.

Ran into some strange Django/Pythonisms but the only way I got it booting with my Dockerfile was to move all the things you have at the root of the project into to-do-django/tododjango/ instead of to-do-django/.

So, could you try moving .dockerignore, Dockerfile, fly.toml, requirements.txt into that first tododjango directory then run your deploy command from to-do-django/tododjango/?

I’m not sure how non-standard that is, but it was the only way I got it working with a Dockerfile so far.

And the command should look like (as you originally had it I think):

CMD ["gunicorn", "--bind", ":8000", "--workers", "2", "tododjango.wsgi"]
1 Like

I tried this as well (moved the four files into to-do-django/tododjango and ran the command from that directory) and got the same error unfortunately.

I’ve also tried making an entirely new clone and new fly app and seem to be running into the same issue.

Which error is the same? From the deploy or the the app logs from fly logs?

Might be worth streaming logs in a separate tab while you try some deploys - fly logs will stream output and you might see more whole exception output for better hints as to what’s going on.

Have you been able to boot and run the project locally at all without Fly.io or maybe without Docker?

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.