Genie Discord forum

Hello all,

was anyone able to deploy an app on fly.io following the guide here https://learn.genieframework.com/docs/guides/deploying-genie-apps

I am not able to get this going and continuously get the problem that the service cannot be reached:

WARNING The app is not listening on the expected address and will not be reachable by fly-proxy.
You can fix this by configuring your app to listen on the following addresses:
  - 0.0.0.0:8000
Found these processes inside the machine with open listening sockets:
  PROCESS        | ADDRESSES                             
-----------------*---------------------------------------
  /.fly/hallpass | [fdaa:3:161a:a7b:126:2066:a8dc:2]:22  

Creating a second machine to increase service availability
  Machine 48ed67dc301148 [app] update finished: success
Finished launching new machines

NOTE: The machines for [app] have services with 'auto_stop_machines = true' that will be stopped when idling


Visit your newly deployed app at https://baseappzwei.fly.dev/

I have tested the requried Dockerfile and the app in the container listens at 0.0.0.0:8000, I also have scaled RAM to allow fast enough loading of the app, which appears to be a common issue according to the fly.io community...

So if anyone made it, could you share your fly.toml and Dockerfile with me?

Many thanks Sven

I think @essenciary deployed to fly.io long time back

There are issues sometimes deploying to fly.io. Apparently the app doesn't load fast enough and a connection to the port 8000 cannot be established from the browser. I'm looking into improving the dockerfile to solve this

Still, running the Docker image locally or on a server with docker should work

Hello all, I kept on trying, following findings:

• as a default fly.io, provides two VMs of which both auto start and stop depending on demand. This is basically a good thing, but as @Pere mentioned, pulling the Docker container out of sleep mode seems difficult on fly.io, ie. it takes very long for Genie to perform the final up(). This is something I could not replicate locally in a Docker Container, it works fine there. I think what happens as a result is, that the Genie app gets bombarded straight away with requests, perhaps causing the app to fail and crash the respective VM.
• fly.io throws a warning and after starting the VM even errors, that the app is not reachable on address "0.0.0.0":8000, after lots of trial and error, I am pretty sure that this is not the case with the given Dockerfile. In other words the Dockerfile provided on the Genie Guide page is correct and does its job. How do I know? I figured that setting fly.toml file to keep at least one VM running permanently shows, that once that app has loaded it works as expected.

[http_service]
  min_machines_running = 1

• In the logs I found "out of memory" ie. OOM errors, so scaling the RAM is vital, as well as adding another CPU. I did:

fly scale vm shared-cpu-2x
fly scale memory 2048 

So with the above I have a very basic app running now, unfortunately the above settings sort of undermine the main idea of using fly.io, ie. only pay for usage whereas now the app runs permanently even when nobody calls it.

So the issue to be solved is the latency for starting the container and Genie, and consequently listening on the port. I think there are several further settings in thy fly.toml that I can try, so I will keep on trying for a while.

Under the bottomline, deploying to fly.io, was not so straight forward for me.

Thanks for sharing your findings Sven! I'd forgotten about the min_machines_running option but yes that makes it expensive to have an app running.

I managed to reduce the startup time by compiling all packages in the image with PackageCompiler.jl. To use this on fly.io you need to add the --local-only flag so that it used your local docker install to build the image. It needs a lot of ram so fly.io's builder runs out of memory. However, one major drawback is that it takes VERY long (3h on my computer) to build the image this way.

I'm exploring other alternatives like Google Cloud right now.

Here's the dockerfile

# pull latest julia image
FROM julia:latest
# C compiler for PackageCompiler
USER root
RUN apt-get update && apt-get install -y g++
#create dedicated user
RUN useradd --create-home --shell /bin/bash genie && \
    mkdir /home/genie/app && \
    chown -R genie:genie /home/
# set up the app
WORKDIR /home/genie/app
COPY . /home/genie/app
RUN chown -R genie:genie /home/genie/app

# switch user
USER genie
# Compile all packages in Project.toml into a system image
RUN julia --project -e "\
using Pkg;\
Pkg.activate(\".\");\
Pkg.add(\"PackageCompiler\");\
using PackageCompiler;\
packages = [ x for x in keys(Pkg.installed())] ;\
PackageCompiler.create_sysimage(\
    packages;\
    sysimage_path=\"sysimg.so\",\
    cpu_target=PackageCompiler.default_app_cpu_target()\
);\
"
# ports
EXPOSE 8000
EXPOSE 80
# set up app environment
ENV JULIA_DEPOT_PATH "/home/genie/.julia"
ENV JULIA_REVISE = "off"
ENV GENIE_ENV "prod"
ENV GENIE_HOST "0.0.0.0"
ENV PORT "8000"
ENV WSPORT "8000"
ENTRYPOINT ["julia", "--sysimage", "/home/genie/app/sysimg.so","--project", "-e", "using GenieFramework; Genie.loadapp(); up(async=false);"]

@Sven an update. To make Genie attach earlier to the port so that fly.io detects it as running, add ENV EARLYBIND "true"to the dockerfile.