fly first deploy

[rubys]

Disclosure: my name is Sam Ruby and I work for fly.io.

I'm pleased to see that fly.io is included in this opinionated stack, and I want to make it seamless.

After seeing the announcement, I tried the instructions for myself, and have yet to succeed. Following are my notes. The first few problems are easy fixes, and I actually want the opportunity to propose that I make changes to how fly.io works and the instructions be updated (mostly deletions!) to match.

---

Fir failure:

fly apps create epic-stack-template

Result:

Error: Validation failed: Name has already been taken

Of course it is. Changed to rubys-epic-stack, and rubys-epic-stack-staging.

---

Subsequent commands also need to use the selected name:

fly secrets set MAILGUN_DOMAIN="mg.example.com" MAILGUN_SENDING_KEY="some-api-token-with-dashes" --app epic-stack-template
fly volumes create data --size 1 --app epic-stack-template

Also need to do the same in fly.toml:

app = "rubys-epic-stack"

---

First deploy:

Creating 1GB volume 'data' for process group 'app'. Use 'fly vol extend' to increase its size
Error: failed to provision seed volumes: failed creating volume: Couldn't allocate volume, no disks available (region: , size_gb: 1)

That's not good. Two problems here. First: region: , is missing a region name. Second: note that fly will now automatically allocate a volume for you on first deploy, so this can be removed as an earlier step.

The fix is to replace the fly.toml. Here's what the new file should look like:

#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = "rubys-epic-stack"
primary_region = "sjc"

[mounts]
source = "data"
destination = "/data"

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

Note how it is much smaller. It includes a primary region. (Sidenode: how should epic stack pick this? Answer: it shouldn't, see below!). It also exposes new features, like automatically stopping and starting machines. And contains the mount which causes the volume to automatically be created.

---

Next deploy:

2023-05-11T17:34:44Z app[148ed316a77968] sjc [info]0B78ADB82CAA2511: cannot acquire lease or find primary, retrying: fetch primary url: Get "http://127.0.0.1:8500/v1/kv/litefs/rubys-epic-stack": dial tcp 127.0.0.1:8500: connect: connection refused

Here I am going to need some help. I don't know (yet!) what the epic stack is expecting to be listening on port 8500.

---

Recap/proposal

Getting to this point requires a number of manual running of commands and updating of configuration files. That's something that a script can handle. What I would like to do is replace all of the above with fly launch. It will prompt for an application name. It will prompt for a region. Normally it would also prompt for postgres and redis, but when I detect an epic stack, I can make sure that those prompts are skipped.

Normally it would also generate a Dockerfile for you, but I can (for now) skip that too. TBH, I would love to have a follow-on discussion and have dockerfile-node generate the dockerfile for you, the primary advantage being that it can be rerun with different options or after you have installed additional packages and it will either show you the necessary diffs or even update your Dockerfile for you.

[kentcdodds]

Thank you so much for this Sam.

For folks watching at home, Sam and I had a great chat about this at Remix Conf and we're going to work on this together to make the setup experience even easier than it is now and have fewer points of failure. Stay tuned!

[rubys]

Recapping my understanding of what we discussed. Basically, I'm going to go through the current deployment instructions and identify what needs to changed, and by whom. I'm just going to divvy the work between epic stack and fly; for some cases it might make sense to push the changes down into remix, but I'll leave that up to you.

Install Fly

Unchanged.

Create two apps on Fly

This will be replaced by fly launch, which will prompt for name, region, and generate an up to date fly.toml based on such concerns as whether the org is v1 or v2. This means:

• epic stack need to identify some way (probably in the package.json) for fly to detect that we are dealing with epic stack.
• fly launch will need to create two apps when it detects an epic stack deployment. Again, whether this should be generalized to all remix apps is something I will leave to you.

Initialize Git.

I'm of the opinion that epic stack should do this. After all, Rails does this. Furthermore, emitting a .github/workflow without a .git directory doesn't make much sense, but I'm open to discussing this. Either way, this should no longer be a manual step the developer needs to take.

git remote add origin <ORIGIN_URL>

Unchanged.

Add a FLY_API_TOKEN to your GitHub repo.

Unchanged.

Add a SESSION_SECRET, ENCRYPTION_SECRET, and INTERNAL_COMMAND_TOKEN to your fly app secrets,

fly launch will take care of this.

Create an account on Mailgun

Unchanged.

Create a persistent volume for the sqlite database

Will be taken care of by fly (probably during first deploy)

[MichaelDeBoey]

fly launch will need to create two apps when it detects an epic stack deployment

I think this should be done for all Remix apps if we want to deploy to Fly

Initialize Git.

I'm of the opinion that epic stack should do this. After all, Rails does this.

Maybe it's a good thing that we do this in Remix CLI itself?
We could add this to the CLI and ask people if they want us to do so (like we do with installing dependencies)

Add a SESSION_SECRET, ENCRYPTION_SECRET, and INTERNAL_COMMAND_TOKEN to your fly app secrets,

fly launch will take care of this.

This feels very Epic Stack specific
At least we only have SESSION_SECRET in the indie-stack & blues-stack

Due to this, it makes me feel like we should maybe a fly key to the package.json to tell flyctl that we want it to do this for us
This would be a more generic approach than somehow looking if it's an Epic Stack or not and that way we could use the same thing in the indie-stack & blues-stack as well

After all, the indie-stack, blues-stack & Epic Stack are all just Remix Stacks, so if we could find a generic solution for Remix applications, it would work for all 3 stacks

[kentcdodds]

I think this should be done for all Remix apps if we want to deploy to Fly

I don't agree. Not everyone starting a new project with Remix will want multiple environments.

[MichaelDeBoey]

Not everyone starting a new project with Remix will want multiple environments.

Fair enough

My last point of making this a generic (Remix) solution instead of Epic Stack specific can still indicate this though

[andrecasal]

Got to the same point as @rubys running in v2. Any update on how to solve that port 8500 error?

2023-05-17T12:16:37.366 app[32871d7f1164e8] mad [info] 0D8EE9C1BB82079C: cannot acquire lease or find primary, retrying: fetch primary url: Get "http://127.0.0.1:8500/v1/kv/litefs/estuda-comigo": dial tcp 127.0.0.1:8500: connect: connection refused

I ran a search for '8500' on the repo and couldn't find anything, so I'm guessing this is a fly thing?

Update

Port 8500 is the default HTTP port for Consul.

[rubys]

@andrecasal Try https://community.fly.io/t/new-commands-fly-consul-attach-and-fly-consul-detach/12418

[rubys]

I'll add that to my todo list for things fly launch should automatically do when it detects an epic stack application.

[kentcdodds]

Interesting. I've never had to do that before 🤔 is that a v2 thing?

[rubys]

Yes, that's a v2 thing. V1 had "experimental" consul support that you can enable in your fly.toml. V2 supports consul.

Status update: I've updated the rails dockerfille generator to support Litefs on fly v2, see https://fly.io/docs/rails/advanced-guides/litefs/. Implementing this from scratch made me understand all of the pieces needed to make this work transparently, including attaching consul. I'll now port this to the node generator. I think this is the last major piece.

I'm going to focus on getting this working on v2, after which we can discuss whether it is worthwhile to support v1. We're actively migrating all v1 users to v2, and no new applications will be v1 any more.

[kentcdodds]

I'm definitely fine only supporting v2 in this stack. I just need to know how to get my stuff upgraded to v2 (because the template example deployment is using v1). I was under the impression that LiteFS didn't work on v2 until recently maybe?

[hyperwidget]

Was running into the same issue and this command saved the day (also on V2). I didn't get mailgun set up, but otherwise followed the steps in the readme - this appeared to be the only missing step

[rubys]

Status update: flyctl v0.1.6 now will use dockerfile-node to generate Dockerfiles. What I need now:

• A means to detect epic stack applications
• Identification of which of the above changes (if any) apply to other remix stacks or even remix applications in general.

[MichaelDeBoey]

that aren't needed anymore

@kentcdodds If this would remove Dockerfile & fly.toml completely from the repo, this would mean we would have to run this command on each deploy

• The options you selected are saved in package.json.

@rubys Oh awesome, I didn't know this happened, I assumed only the correct files were created.
This is indeed how I was imagining things, where you don't need to pass things explicitly to fly launch/dockerfile-node

This way you also only need to check for Remix (so no explicit check for indie/blues/epic/... stack needed 🥳) and if stacks want to provide certain things out of the box (like multi-region), they can just add these options to the dockerfile key in package.json 👍

[rubys]

This way you also only need to check for Remix

It is more complicated than that, but that is goodness.

I'm looking at each thing I need to do, and will try to do if checks based on the most specific feature that requires that task. Here's my current raw notes:

RUN apt-get update && apt-get install -y fuse3 openssl sqlite3 ca-certificates

ADD package.json package-lock.json .npmrc ./

ENV FLY="true"
ENV LITEFS_DIR="/litefs/data"
ENV DATABASE_FILENAME="sqlite.db"
ENV DATABASE_PATH="$LITEFS_DIR/$DATABASE_FILENAME"
ENV DATABASE_URL="file:$DATABASE_PATH"
ENV CACHE_DATABASE_FILENAME="cache.db"
ENV CACHE_DATABASE_PATH="/$LITEFS_DIR/$CACHE_DATABASE_FILENAME"
ENV INTERNAL_PORT="8080"
ENV PORT="8081"
ENV NODE_ENV="production"

# add shortcut for connecting to database CLI
RUN echo "#!/bin/sh\nset -x\nsqlite3 \$DATABASE_URL" > /usr/local/bin/database-cli && chmod +x /usr/local/bin/database-cli

# prepare for litefs
COPY --from=flyio/litefs:0.4.0 /usr/local/bin/litefs /usr/local/bin/litefs
ADD other/litefs.yml /etc/litefs.yml
RUN mkdir -p /data ${LITEFS_DIR}

CMD ["litefs", "mount", "--", "node", "./other/start.js"]

- - -

enable_consul = true

[mounts]
source = "data"
destination = "/data"

Picking the first example: fuse3 is needed by litefs. I can look for litefs-js in the package.json, and if found do all of the litefs things (there are several items in the list above). I can also accept a --litefs option.

Creating the mounts and shortcut for the database CLI could be made available to anybody that uses prisma and sqlite3, not just remix users.

When I'm done, there will be some environment variables left over. I'm going to initially make the pessimistic assumption that any of these that I can't find a more specific need for are epic specific. Over time I expect people like yourself to identify which ones of these are more general, and for those they will be emitted based on a more specific criteria (perhaps all remix apps or perhaps something else entirely).

[MichaelDeBoey]

@rubys I'm in favor of doing as much detection as possible, but things like supporting multi-region is not something you can detect in a generic way I think, so that one would need an option imo

I can look for litefs-js in the package.json, and if found do all of the litefs things (there are several items in the list above). I can also accept a --litefs option.

As my message above: I would go with detection here

Creating the mounts and shortcut for the database CLI could be made available to anybody that uses prisma and sqlite3, not just remix users.

Detecting if people use Prisma & sqlite3 can perfectly be detected as well, so I wouldn't go with an option either

When I'm done, there will be some environment variables left over

This could be a generic --env-vars option or so
That way each framework can use these the way they want

Over time I expect people like yourself to identify which ones of these are more general, and for those they will be emitted based on a more specific criteria (perhaps all remix apps or perhaps something else entirely).

We can indeed refactor on a later stage when we see that all Remix stacks are including some of the same env vars & automatically add these if we detect Remix

[rubys]

We seem to be in sync. The devil's in the details. Let's revisit when we have actual code to evaluate - it should be soon, I've already deployed the change where flyctl launches dockerfile-node, and I've started implementing some of the changes needed in the Rails adapter which has very similar needs and active users.

Unrelated: while I'll initially implement a staging app to match current Epic/Remix expectations, something like the following would be much better longer term: https://twitter.com/p_mbanugo/status/1659603001500221449

[MichaelDeBoey]

@rubys I would imagine that service would just use fly launch behind the scenes 🤔

[bernardbaker]

I'm seeing

==> Verifying app config
Validating /github/workspace/fly.toml
Platform: machines
✓ Configuration is valid
--> Verified app config
==> Building image
Waiting for remote builder fly-builder-cold-meadow-[9](https://github.com/bernardbaker/nunesandco.consulting/actions/runs/5017995177/jobs/8996876627#step:6:10)302...
WARN Failed to start remote builder heartbeat: failed building options: Timeout on AddWireGuardPeer.peerip
Waiting for remote builder fly-builder-cold-meadow-9302...
Error: failed to fetch an image or build from source: error connecting to docker: failed building options: server returned a non-200 status code: 504

when trying to deploy using the epic-stack app. It's in the GitHub actions deploy -> production task.

[rubys]

Timeout on AddWireGuardPeer.peerip

The people who can help out with that tend to watch community.fly.io. Can you post this there? This looks similar to a problem that happened last fall: https://community.fly.io/t/unreliable-deploys-with-github-actions/4740/16

[Marcoj776]

Hi semi-related issue, but I don't think it requires a separate thread

fly deploy fails with a timeout or 'docker image not found' when it is blocked by my Kaspersky anti-virus
After several hours over two days of debugging fly I paused my AV for 5 minutes and deployed whilst following the instructions

[rubys]

Just because I've been quiet doesn't mean that I haven't been busy. To the contrary, I'm nearly ready. Peruse dockerfile-node/fly.js and compare to epic-stack/docs/deployment.md. I have a few more flyctl changes that I need to test and deploy before I can finish up, but I'm getting close.

[rubys]

2023-06-01T00:41:14Z runner[1857264a476618] iad [info]Pulling container image registry.fly.io/long-frost-1286:deployment-01H1T6A7A5GC3E23P28NQN5EKM
2023-06-01T00:41:19Z runner[1857264a476618] iad [info]Successfully prepared image registry.fly.io/long-frost-1286:deployment-01H1T6A7A5GC3E23P28NQN5EKM (5.639918642s)
2023-06-01T00:41:19Z runner[1857264a476618] iad [info]Setting up volume 'data'
2023-06-01T00:41:19Z runner[1857264a476618] iad [info]Uninitialized volume 'data', initializing...
2023-06-01T00:41:19Z runner[1857264a476618] iad [info]Encrypting volume
2023-06-01T00:41:26Z runner[1857264a476618] iad [info]Opening encrypted volume
2023-06-01T00:41:28Z runner[1857264a476618] iad [info]Formatting volume
2023-06-01T00:41:29Z runner[1857264a476618] iad [info]Configuring firecracker
2023-06-01T00:41:29Z app[1857264a476618] iad [info]Using Consul to determine primary
2023-06-01T00:41:31Z app[1857264a476618] iad [info]initializing consul: key=litefs/long-frost-1286 url=https://:[email protected]/long-frost-1286-4nml16zkg45qvp2y/ hostname=1857264a476618 advertise-url=http://1857264a476618.vm.long-frost-1286.internal:20202
2023-06-01T00:41:31Z app[1857264a476618] iad [info]LiteFS mounted to: /litefs
2023-06-01T00:41:31Z app[1857264a476618] iad [info]http server listening on: http://localhost:20202
2023-06-01T00:41:31Z app[1857264a476618] iad [info]B0B23AA69CCA570A: primary lease acquired, advertising as http://1857264a476618.vm.long-frost-1286.internal:20202
2023-06-01T00:41:31Z app[1857264a476618] iad [info]proxy server listening on: http://localhost:3000
2023-06-01T00:41:31Z app[1857264a476618] iad [info]starting background subprocess: /app/other/docker-entrypoint.js [npm run start]
2023-06-01T00:41:31Z app[1857264a476618] iad [info]waiting for signal or subprocess to exit
2023-06-01T00:41:33Z app[1857264a476618] iad [info]Prisma schema loaded from schema.prisma
2023-06-01T00:41:33Z app[1857264a476618] iad [info]Datasource "db": SQLite database "sqlite.db" at "file:///litefs/sqlite.db"
2023-06-01T00:41:33Z app[1857264a476618] iad [info]database file is zero length on initialization: /data/dbs/sqlite.db/database
2023-06-01T00:41:33Z app[1857264a476618] iad [info]SQLite database sqlite.db created at file:///litefs/sqlite.db
2023-06-01T00:41:33Z app[1857264a476618] iad [info]The following migration have been applied:
2023-06-01T00:41:33Z app[1857264a476618] iad [info]migrations/
2023-06-01T00:41:33Z app[1857264a476618] iad [info]  └─ 20230525081631_init/
2023-06-01T00:41:33Z app[1857264a476618] iad [info]    └─ migration.sql
2023-06-01T00:41:33Z app[1857264a476618] iad [info]All migrations have been successfully applied.
2023-06-01T00:41:34Z app[1857264a476618] iad [info]> start
2023-06-01T00:41:34Z app[1857264a476618] iad [info]> cross-env NODE_ENV=production node .
2023-06-01T00:41:35Z app[1857264a476618] iad [info]🚀  We have liftoff!
2023-06-01T00:41:35Z app[1857264a476618] iad [info]On Your Network:  http://172.19.149.122:3001
2023-06-01T00:41:35Z app[1857264a476618] iad [info]Press Ctrl+C to stop

[rubys]

You can now try it yourself:

fly version update
rm -rf my-remix-app
npx create-remix@latest --typescript --install --template epicweb-dev/epic-stack
cd my-remix-app
rm -f Dockerfile fly.toml other/litefs.yml
fly launch
fly deploy
fly open

(accept all defaults)

This assumes that you have been through the fly walkthrough. Remaining steps (all optional):

• Create a new GitHub Repository, and then add it as the remote for your project. Do not push your app yet!
  git remote add origin <ORIGIN_URL>
• Add a FLY_API_TOKEN to your GitHub repo. To do this, go to your user settings on Fly and create a new token, then add it to your repo secrets with the name FLY_API_TOKEN.
• Create an account on Mailgun. (optional)
  Find instructions for this optional step in the email docs.

Feedback welcome! What is broken? What is missing? What is needed to get this working with the Blues stack, Indie stack, and even "vanilla" Remix?

[alextingworld]

Thank you for your work on this @rubys -- looking forward to testing this through again. Cheers 🙏🏼

[kentcdodds]

This is great! Thanks for the work on this. Here's some feedback.

One thing I really want to avoid with the Epic Stack is giving people choices they have to make when they start a new project. As much as possible I'd like to have all the decisions made for them so they can just get to building.

So I'd like it if fly launch doesn't ask them whether they want upstash or postgres setup. In fact, I'd even like it if they're not asked about what region to run their app in. Just choose the closest region to them and they can change it later if they want to (we'll make docs for that).

Creating 1GB volume 'data' for process group 'app'. Use 'fly vol extend' to increase its size

I was unaware of this feature. COOL!

I love how minimal the fly.toml is, but I want to make sure we're not missing anything important from what is in the fly.toml right now (like the healthcheck endpoint and things like that).

It appears that the litefs.yml also gets overridden. I kinda like the way it works now and there are a few differences in the new one. Is there a reason this needs to be handled by fly launch?

My test of getting the app deployed failed. I'm guessing it has something to do with some of the recent changes around the litefs.yml in the epic stack that fly launch isn't accounting for yet.

We've got a setup script that's working pretty well right now, and eventually we'll make use of https://npm.im/create-epic-stack to do a lot of things that I think I'd prefer handle some of the epic-stack-specific stuff that you've got fly launch doing right now. I'd really prefer that fly launch be pretty minimal and only related to generally applicable fly stuff.

In fact, I'm pretty sure I don't want fly to do anything with the dockerfile with the epic stack. 😬 I guess I'm just not sure what the value of having fly manage that for us would be since the epic stack is very opinionated by design.

I do like that there can be a single command that can handle most of the fly-related deployment steps for us. But as far as generating files is concerned I'm pretty sure I'd rather keep that in the epic-stack.

[rubys]

I'd like it if fly launch doesn't ask them whether they want upstash or postgres setup.

superfly/flyctl#2393

In fact, I'd even like it if they're not asked about what region to run their app in. Just choose the closest region to them and they can change it later if they want to

Right now you can pass --region on fly launch, but there is no option to let it default.

Creating 1GB volume 'data' for process group 'app'. Use 'fly vol extend' to increase its size

I was unaware of this feature. COOL!

It is new!

I love how minimal the fly.toml is,

That's now how it looks for all v2 apps

I want to make sure we're not missing anything important from what is in the fly.toml right now (like the healthcheck endpoint and things like that)

If epic stack includes a health check endpoint, let me know and I'll gladly add that. I already do this for rails.

It appears that the litefs.yml also gets overridden. I kinda like the way it works now and there are a few differences in the new one. Is there a reason this needs to be handled by fly launch?

I believe that some of the changes are required for apps v2, and I developed this in consultation with Ben Johnson. But to answer your more general question: in general the litefs configuration and dockerfile can't evolve independently, there are too many things that need to be coordinated like file paths. Also litefs is evolving quickly, and there are plans that will require changes to both the Dockerfile and the litefs configuration.... I'm guessing that you are at least partially aware of them as you already added ca-certificates to your Dockerfile. My vision is to have a single repository where you, me, Ben and others directly collaborate.

In any case, this code will remain in fly-apps/dockerfile-node to support non-Remix node.js apps.

My test of getting the app deployed failed. I'm guessing it has something to do with some of the recent changes around the litefs.yml in the epic stack that fly launch isn't accounting for yet.

The exact lines I posted above should work as written. Is this not the case for you? If not, perhaps it is because you still have your personal org set up for apps V1? See: https://community.fly.io/t/make-apps-v2-the-default-for-new-apps-in-your-org/11280

We've got a setup script that's working pretty well right now, and eventually we'll make use of https://npm.im/create-epic-stack

I encourage you to take a moment and review: https://github.com/fly-apps/dockerfile-node/blob/main/fly.js ; see what is being done there, and what might be worth adding. Just be aware that the code there is for all Node applications, not just epic stack, and not just remix. In fact, it works with applications with no framework, see: https://fly.io/blog/vanilla-candy-sprinkles/

But as far as generating files is concerned I'm pretty sure I'd rather keep that in the epic-stack.

I actually flew out to SLC to have this discussion in person. As long as you make an informed decision, that's your choice to make. But first, let's recap: fly recently broke your setup with the change from nomad (v1) to machines (v2). There are recent and known upcoming change to litefs that will be breaking you again. We can work together, and I invited you as a collaborator to fly-apps/dockerfile-node to ensure that things are always working and debug customer issues together, or you can go it alone and I can redirect any complaints your way.

I had hoped that I had convinced you in person of the merits of owning this part of the problem jointly, but I'm gathering that I hadn't fully made my case, at least not in a durable way.

[kentcdodds]

First of all, I should have made it clear that I do appreciate your time and attention on this. I realize that me changing my mind on this represents a significant disappointment for you and the work you've put into supporting the Epic Stack.

The problem I'm having with having fly launch manage all of this is it makes it adds friction for myself and other contributors to make improvements to the setup. Particularly with the Dockerfile, Fly.toml, and litefs.yml. It turns those static files (which are pretty complicated in their own right) into dynamic and generated files for what appears to be very limited benefit.

To be clear, as I understand it, the only benefit of generating the config for an epic stack app is necessary changes to the config are handled by fly launch. Unless I'm missing something else, that's the primary benefit.

The thing is, I think we can keep on top of any necessary change ourselves in the static files and I think that'll be even simpler for us to maintain in the long term. By moving the static files into dynamically generated files, it makes it much harder for contributors to understand how things work together. It also limits the value of the epic stack as a project reference because those files wont be in the template. A lot of people will benefit from the epic stack as a project reference, so that is a downer.

Please forgive me if I'm missing something, but I really think it's better for the Epic Stack to keep the files static. I do need to update them to use Fly V2 config for everything and once I've done that then I'll include docs to tell people they need to be using v2 in their org to get this setup properly.

[rubys]

I realize that me changing my mind on this represents a significant disappointment for you and the work you've put into supporting the Epic Stack.

Whatever happens, the work product is still valuable. Both as a reference implementation for you to steal liberally from, and as a tool that widely used by others deploying node applications on Fly (see download statistics: https://www.npmjs.com/package/@flydotio/dockerfile).

All I want is to ensure that you understand that there will be more breakage in the future. If you go your own way with Dockerfiles, fly.toml, and scripts, and they break, you get to keep both halves. If epic stack customers wander to community.fly.dev, I'll either direct the back to you or offer to recreate their setup with one that works.

[kentcdodds]

still valuable.

I'm glad of that.

I think it's in Fly's best interest to limit breakages because even if we use fly launch to generate these files, once those files are generated they will also be broken by any future breakages. Fly doesn't want to break users on a regular basis and that will apply to us as well. As I'm maintaining a few apps running on Fly, I'm also interested in keeping up myself anyway, so it's not much more of an added burden to manage it myself.

[rubys]

I think it's in Fly's best interest to limit breakages

Let's just say that it is complicated, and those decisions are above my pay grade. I saw first hand the problems users were experiencing with Nomad (v1), and I'm excited about the changes coming to Litefs.

Also recall, v1 fly.toml files continue to work with v1 apps; and v2 fly toml files work with v2 apps.

[kentcdodds]

Sure, but I've been using Fly for a long time on v1 and I'll be upgrading to v2 soon. I don't expect a v3 to show up any time soon. So the current cadence is pretty reasonable. As Fly grows, the pain of breaking changes also increases and acts as a reasonable forcing function to discourage Fly from releasing new and breaking changes in the future :) (Hopefully 😅)

[rubys]

Oh, I just remembered, one of the killer features that you seemed especially interested in, was the ability to run:

npx dockerfile --swap=1G

See: https://github.com/fly-apps/dockerfile-node#options for the list of current options; and https://community.fly.io/t/new-launch-features-for-node-applications/13271 for background on the more general plans.

[kentcdodds]

Hmmm... I'm sorry, but I'm not sure what that command does, even after reading the docs 😅

[rubys]

I haven't create Node.js documentation on the fly site to match the Rails content, but the docs on the Rails equivalent of this might help jog your memory: https://fly.io/docs/rails/getting-started/dockerfiles/#out-of-memory

[kentcdodds]

Oh yeah, the virtual memory thing! Yeah, that's pretty sweet!

That said, we could just hard-code whatever that command does in the Dockerfile, so I'm still not sure it's necessary to generate it.

[kentcdodds]

I've now built a custom series of commands to get the Epic Stack deployed on Fly: #119

Feedback and improvements are welcome. Thanks everyone!

[rubys]

Give this a try:

const { execSync } = require('child_process');

const token = execSync('fly auth token', {encoding: "utf8"});
const query = 'query {platform {requestRegion}}';

fetch('https://api.fly.io/graphql', {
  method: 'POST',
  body: JSON.stringify({ query }),
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${token}`
  }
})
.then(response => response.json())
.then(response => console.log(response.data.platform.requestRegion))

[kentcdodds]

Oh sweet, thank you for that! I'll work that into the script 💯

[scefali]

Btw, I am getting this error on a fresh installation of Epic Stack:

2023-06-06T17:13:41.988 app[17811430f49478] sjc [info] 78C336643593A390: cannot acquire lease or find primary, retrying: fetch primary url: Get "http://127.0.0.1:8500/v1/kv/litefs/test-epic-stack-4d5d": dial tcp 127.0.0.1:8500: connect: connection refused

How do I resolve this? I don't see any other helpful logs, unfortunately.

[kentcdodds]

Have you run this part of deployment yet?

fly consul attach --app [YOUR_APP_NAME]

[scefali]

@kentcdodds Yep that's it! Thank you!

[Coolfeather2]

I've created a new project using Epic Stack and ran into an issue on the deployment step of the github action

Validating /github/workspace/fly.toml
WARNING: Failed to fetch platform version: Could not find App "remix-pet-6c98"
✓ Configuration is valid
Error: Could not find App "remix-pet-6c98"

This seems to be fixed by renaming app = "remix-pet-6c98" to app = "remix-pet"

Not sure where that postfix came from and just wanted to raise it here if its not an isolated incident.

[ananni13]

The init script generates a random suffix and appends it to your directory name:

epic-stack/remix.init/index.mjs

Lines 29 to 34 in 7a70821

	const DIR_NAME = path.basename(rootDirectory)
	const SUFFIX = getRandomString(2)
	const APP_NAME = (DIR_NAME + '-' + SUFFIX)
	// get rid of anything that's not allowed in an app name
	.replace(/[^a-zA-Z0-9-_]/g, '-')

That APP_NAME is then set inside package.json and fly.toml.

You probably ran the deployment commands manually and created a Fly app named "remix-pet" instead of using the generated name. There's even a helpful note there that you missed 😄

Note: Make sure this name matches the app set in your fly.toml file. Otherwise, you will not be able to deploy.

I guess the name is generated this way because every Fly app must have a unique name.

[Coolfeather2]

Ah, I missed that note!
Thanks

[SangeetAgarwal]

I tried deploying a fresh build and see this, a little unrelated but I already have a couple of apps on fly.io that work fine.
Error: failed to fetch an image or build from source: app does not have a Dockerfile or buildpacks configured. See https://fly.io/docs/reference/configuration/#the-build-section

Error: Command failed with exit code 1: fly deploy --app tailwind-remix-run-epic-starter-blog-fe8b-staging
at makeError (file:///C:/git/tailwind-remix-run-epic-starter-blog/remix.init/node_modules/execa/lib/error.js:59:11)
at handlePromise (file:///C:/git/tailwind-remix-run-epic-starter-blog/remix.init/node_modules/execa/index.js:124:26)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async setupDeployment (file:///C:/git/tailwind-remix-run-epic-starter-blog/remix.init/index.mjs:188:3)
at async main (file:///C:/git/tailwind-remix-run-epic-starter-blog/remix.init/index.mjs:88:2)
at async module.exports (C:\git\tailwind-remix-run-epic-starter-blog\remix.init\index.js:3:2)
at async Object.init (C:\Users\sange\AppData\Local\npm-cache_npx\5164864a48bff686\node_modules@remi}
Looks like something went wrong setting up deployment. Sorry about that. Check the docs for instructions on how to get deployment setup yourself (https://github.com/epicweb-dev/epic-stack/blob/main/docs/deployment.md).

[SangeetAgarwal]

seems I had to allocate ips but once I did that I see the following issue when I say fly deploy. I do see a dockerfile. Remember this is a fresh clone and I have made no changes whatsoever.

==> Verifying app config
Validating C:\git\tailwind-remix-run-epic-starter-blog\fly.toml
Platform: machines
✓ Configuration is valid
--> Verified app config
==> Building image
Remote builder fly-builder-still-pine-1983 ready
Error: failed to fetch an image or build from source: app does not have a Dockerfile or buildpacks configured. See https://fly.io/docs/reference/configuration/#the-build-section

[kentcdodds]

I'm guessing the issue is I moved the Dockerfile and the .dockerignore files out of the root to reduce the amount of root files in the project. Those are moved as part of the deployment process, but I didn't update the local deployment process or document this. I've pushed a fix now. Check the updated deployment docs for deploying locally.