On process types and secrets

1

I’ve got the usual web and worker process types in my fly.toml. For context, I am using sidekiq and I’d like to assign specific instances to consume specific queues.

I know this feature is preview and I’m super thankful for that. It seems that I should be falling back to the web/worker process types. I wonder whether there’s anyone out there who has successfully assigned instances to specific queues, since the config/sidekiq.yml would apply the same config to any instance of the worker type.

I’ve successfully deployed them, but it see a couple of issues:

  1. They seem to spin up in a different region (DFW instead of LAX) - the app has LAX as a primary region, SEA and SJC in the backup region. This happened once, at least the first time I deployed the config change below.
  2. Secrets aren’t being picked up (noticed because the sidekiq worker tried to connect to the default localhost:6379)

This leads to workers not spinning up obvs.

My config is something along the lines of this piece of my fly.toml.

[processes]
    web = "bundle exec rails server -b [::] -p 8080"
    download_worker = "sidekiq -c 1 -q downloads"
    import_worker= "sidekiq -c 5 -q imports"
    notifications_worker="sidekiq -c 1 -q notifications"

Any help would be very appreciated!

Cheers,
Vicente.

2

If secrets aren’t landing in all your process types, that’s a bug. We’ll have a look and see what’s up.

Regions are tricky. You’ll want to set regions per process type. We should inherit from your app by default, though! We will also check in to that.

3

I checked one of your apps and it appears secrets are set property on both process types. Are you missing a REDIS_URL in one? If you fly ssh console to a worker and check the env command, do you see what you expect?

The region issue looks like a bug converting from no process types to multiple process types. I went ahead and cleaned the app up, you should see what you expect now.

4

Thank you, @kurt for taking a look! Gonna double check my settings. So far I’ve reverted back to the two processes: workerand web.

quick question: when I do fly ssh console -a app-name, it loads the session for any of the process types or do I need to specify which process I want to load up?

5

So I can’t ssh into these new instances, since they error when spinning up sidekiq. Been checking my list of secrets for that app, and they are set. Did fiddle around setting them a few times to make sure they were picked up.

I can see now the instances being launched, same region as my redis service, trying to connect to it using the *.fly.dev:10000 public URL, unfortunately the connection times out now. I’m going to try enabling private network and use the *.internal DNS names.

Sweet, I think all of the instances land in the regions I set.

6

Which app is this? I should probably look at secrets on older versions. It might be rolling back if they’re failing to boot like that.

7

You’ll want fly ssh console -s to pick a specific instance.

8

web-staging - Now I realised that 25 max connections to my redis instance wasn’t enough. So that might the source of those timeouts. :man_facepalming:

9

Ok, to summarise:

  1. I can use several process types, not just web and worker. :white_check_mark:
  2. After fiddling with setting secrets, although they looked already alright, the instances are picking them up. :white_check_mark:
  3. The only issue: some of my instances land in regions I haven’t specified like MAA or SCL. After fiddling a bit more with fly regions they spin up in those that I want them to be. Mostly LAX/SCJ. :white_check_mark:
10

Ok this is super helpful. It seems like maybe secrets and regions aren’t getting picked up for new process types until you change them. We’ll look into that.

1 Like