New deployment failed

[yawnbox]

I setup a new Cloudflare account, followed the directions...

Github job (deploy_to_cf_workers) failed with a warning:

Annotations
1 warning
[deploy](https://github.com/yawnbox/wildebeest/actions/runs/4129126395/jobs/7134393563)
Node.js 12 actions are deprecated. Please update the following actions to use Node.js 16: actions/checkout@v2. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/.

Overall I would say deploying Wildebeest is not any easier than deploying Mastodon on a VM.

[yawnbox]

[munkinasack]

I just discovered this issue on my first attempt.

Including Images, you also have to subscribe to Workers Paid plan. Durable Objects is only accessible in the Workers Paid plan. Cloudflare Images $5/month min. Cloudflare Workers Paid- $5/month min.

Based on the Readme, I had buy in with $5/month. Unfortunately, I don't have buy in to do $10/month just for Wildebeest.

I'm stoked that Cloudflare is contributing to the ActivityPub community. Sorry Cloudflare team, I won't be participating.

[yawnbox]

Thank you for the information. Unfortunately after I upgraded to a paid workers account, I ended up with the exact same error.

I agree the Readme is deceptive in cost.

[PrimeSitesCo]

Also had the same issue. Got a Workers paid tier going and activated Durable Objects. Now getting slightly different error under download terraform state heading. I'd be expecting to see the account id where the "***" is being displayed below, so the process might be dropping that variable along the way possibly?

[ERROR] Failed to fetch https://api.cloudflare.com/client/v4/accounts/***/storage/kv/namespaces/890796349881474ca919f40a73588fbd/values/terraform.tfstate - 404: Not Found);

[xtuc]

@PrimeSitesCo I added a fix, could you please sync your fork? It will trigger a deploy build.

[celso]

We will work on the tutorial and clarify the required subscriptions and associated costs.

[PrimeSitesCo]

Thanks @xtuc, sync'd from main, but it didn't trigger a deploy. Manually re-ran the job and got past that step, but failed again at the Configure step I'm afraid. Something I did wrong perhaps?

[aidankinzett]

I keep getting the same error Error message: open terraform.tfstate: permission denied. I've tried deleting the repo and starting again but I get the same error

[xtuc]

Okay, let me revert my fix. Sonds like it's something else.

Have you tried to delete your KV namespaces starting with wildebeest and rerun?

[DataDrivenMD]

Have you tried to delete your KV namespaces starting with wildebeest and rerun?

Hi there - I've tried this, and it doesn't fix the problem. What I've been able to figure out thus far is that the default "Cloudflare Workers" API Token template lacks the permissions necessary to fully deploy the Terraform template. Unless I'm overlooking something obvious, I don't believe any of the repo documentation mentions the CF API token permissions necessary for deployment. It may help to start there.

[DataDrivenMD]

During the latest attempt I was able to get as far as this error message (see image): error creating ruleset Wildebeest: exceeded maximum number of zone rulesets for phase 'http_request_firewall_managed'

Of note, I have no rulesets on this account (0 across all zones), and the target zone is on the Pro plan.

By this point in the TF run the following items have already been configured: Images variants, metadata 2 KV namespaces, D1 instance, DO, Pages project, DNS record, and Zero Trust application. cc @xtuc

[xtuc]

We are working to rewrite the README to provide better documentation and troubleshooting.

@DataDrivenMD You shouldn't use the default "Cloudflare Workers" API token template. There's a deploy button in the README that has a link to create an API token with the right permissions. Here's the link with the right template: https://dash.cloudflare.com/profile/api-tokens?permissionGroupKeys=[{%22key%22:%22d1%22,%22type%22:%22edit%22},{%22key%22:%22page%22,%22type%22:%22edit%22},{%22key%22:%22images%22,%22type%22:%22edit%22},{%22key%22:%22access%22,%22type%22:%22edit%22},{%22key%22:%22workers_kv_storage%22,%22type%22:%22edit%22},{%22key%22:%22access_acct%22,%22type%22:%22read%22},{%22key%22:%22dns%22,%22type%22:%22edit%22},{%22key%22:%22workers_scripts%22,%22type%22:%22edit%22},{%22key%22:%22account_rulesets%22,%22type%22:%22edit%22}]&name=Wildebeest

Once Terraform created some resources. I strongly recommend not deleting anything manually. Resolving the permission / error creating ruleset Wildebeest is enough to unblock the deployement.

I asked internally about your error creating ruleset Wildebeest error.

[koehn]

I re-synced and opted in to the pay-as-you-go plan and when I re-run the job I am still getting the same message:

✘ [ERROR] A request to the Cloudflare API (/accounts/***/workers/scripts/wildebeest-do) failed.
[28](https://github.com/koehn/wildebeest/actions/runs/4136772123/jobs/7151559387#step:19:29)

[29](https://github.com/koehn/wildebeest/actions/runs/4136772123/jobs/7151559387#step:19:30)
  In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]

The latter link (dash.cloudflare.com...) is broken.

[DataDrivenMD]

@DataDrivenMD You shouldn't use the default "Cloudflare Workers" API token template. There's a deploy button in the README that has a link to create an API token with the right permissions.

The magic link didn't work for me initially, which is why I ended up using the Workers Template. I wiped everything, disabled my browser's 3rd-party cookie blocker, then attempted Deploy to Cloudflare Workers button again-- that solved the API key issue.

Once Terraform created some resources. I strongly recommend not deleting anything manually. Resolving the permission / error creating ruleset Wildebeest is enough to unblock the deployement.

Yeah, I'm not touching anything once it is created unless I'm removing all resources before starting over from scratch.

I asked internally about your error creating ruleset Wildebeest error.

FWIW/FYI @xtuc: one of my earliest attempts didn't encounter this error at all, and successfully produced a managed ruleset. I deleted that ruleset between attempts. Could it be that the now-deleted rulesets are still being counted against my account? If so, then I suspect others will eventually hit this roadblock, too.

[DataDrivenMD]

@koehn: I ran into this issue earlier

29 In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]

The fix is to replace the *** with your CF account number, drop that into your browser URL bar, and you'll be prompted to agree. IOW: https://dash.cloudflare.com/<YOUR_CLOUDFLARE_ACCOUNT_NUMBER_GOES_HERE>/workers/overview?enable-durable-objects

[DataDrivenMD]

@xmflsct I can confirm that I am on the new managed rule interface

[xmflsct]

@DataDrivenMD sorry deleted my previous message. Digged a bit more, you should have deployed managed rules already in that target zone. If that is the case, for now a workaround is to remove Terraform's config of managing WAF like this commit.

[DataDrivenMD]

@DataDrivenMD sorry deleted my previous message. Digged a bit more, you should have deployed managed rules already in that target zone. If that is the case, for now a workaround is to remove Terraform's config of managing WAF like this commit.

@xmflsct I don't have any deployed rules (at all). I'm happy to deploy the managed rules, but I believe that TF directive yields an exception to the managed rulesets. So, unless I'm misunderstanding the TF directive, the workaround would remove the bypass and thereby block ingress traffic to the /inbox endpoints.

[koehn]

OK, just made sure my repo was sync’ed, enabled DO, Enabled Access, and now this error in the “Download Terraform State” task:

✘ [ERROR] Failed to fetch https://api.cloudflare.com/client/v4/accounts/***/storage/kv/namespaces/[redacted]/values/terraform.tfstate - 404: Not Found);

[DataDrivenMD]

OK, just made sure my repo was sync’ed, enabled DO, Enabled Access, and now this error in the “Download Terraform State” task:

✘ [ERROR] Failed to fetch https://api.cloudflare.com/client/v4/accounts/***/storage/kv/namespaces/[redacted]/values/terraform.tfstate - 404: Not Found);

@koehn Encountered this one, too. It happens because there's no continue-on-error: true directive in the GH Actions deploy.yml for that run command. The workaround is to follow the Starting Over instructions. You may be able to get away without deleting the fork, but you definitely need to go through the steps to delete any KV Namespaces, DO objects, DNS records, and Zero Trust/Access Applications that were added by the Terraform config. Once you do that, hit re-run on the failed GH Actions job and cross your fingers.

[windymelt]

I encountered simillar situation. I tried deployment but GitHub Action failed due to payment approval. Then I approved payment and re-run action to fail.

Situation is getting better when I removed all of related KV. Currently I got error:

│ Error: error creating Access Application for account "***": access.api.error.application_already_exists (11010)
│ 
│   with cloudflare_access_application.wildebeest_access,
│   on main.tf line 165, in resource "cloudflare_access_application" "wildebeest_access":
│  165: resource "cloudflare_access_application" "wildebeest_access" {
│ 
╵
╷
│ Error: failed to create ruleset "http_request_firewall_managed" as a similar configuration with rules already exists and overwriting will have unintended consequences. If you are migrating from the Dashboard, you will need to first remove the existing rules otherwise you can remove the existing phase yourself using the API (https://api.cloudflare.com/#zone-rulesets-delete-zone-ruleset).
│ 
│   with cloudflare_ruleset.wildebeest_inbox,
│   on main.tf line 174, in resource "cloudflare_ruleset" "wildebeest_inbox":
│  174: resource "cloudflare_ruleset" "wildebeest_inbox" {
│ 
╵

What should I do?

[yawnbox]

@koehn: I ran into this issue earlier

29 In order to use Durable Objects, you must agree to pricing at https://dash.cloudflare.com/***/workers/overview?enable-durable-objects [code: 10084]

The fix is to replace the *** with your CF account number, drop that into your browser URL bar, and you'll be prompted to agree. IOW: https://dash.cloudflare.com/<YOUR_CLOUDFLARE_ACCOUNT_NUMBER_GOES_HERE>/workers/overview?enable-durable-objects

Just did this, thank you. New error:

So... I did this Visit the Access dashboard at https://dash.cloudflare.com/ and click the 'Enable Access' button. and there is no such button.

[xmflsct]

@DataDrivenMD sorry deleted my previous message. Digged a bit more, you should have deployed managed rules already in that target zone. If that is the case, for now a workaround is to remove Terraform's config of managing WAF like this commit.

@xmflsct I don't have any deployed rules (at all). I'm happy to deploy the managed rules, but I believe that TF directive yields an exception to the managed rulesets. So, unless I'm misunderstanding the TF directive, the workaround would remove the bypass and thereby block ingress traffic to the /inbox endpoints.

That is likely you have deployed rules in the past through the dashboard UI, hence an entrypoint ruleset had been automatically created by the UI behind the scene. Tested that you need to call the API https://developers.cloudflare.com/api/operations/zone-rulesets-delete-a-zone-ruleset to delete that entrypoint ruleset, then it can be managed by Terraform.

[DataDrivenMD]

@yawnbox

So... I did this Visit the Access dashboard at https://dash.cloudflare.com/ and click the 'Enable Access' button. and there is no such button.

It's been re-branded as "Zero Trust" (see image):

[koehn]

To delete ruleset (requires jq and curl, your Zone ID and an API key (the one you used for you app is fine)):

1. Get ruleset:

curl --request GET   --url https://api.cloudflare.com/client/v4/zones/[zone id]/rulesets   --header 'Content-Type: application/json'   --header "Authorization: Bearer [API key]" | jq .

Look for the id of your app description “Ruleset for Wildebeest” 2. Delete ruleset:

root@k3s-sd-01:~# curl --request DELETE   --url https://api.cloudflare.com/client/v4/zones/[zone id]/rulesets/[ruleset id]   --header 'Content-Type: application/json'   --header "Authorization: Bearer [API key]"

[DataDrivenMD]

I encountered simillar situation. I tried deployment but GitHub Action failed due to payment approval. Then I approved payment and re-run action to fail.

Situation is getting better when I removed all of related KV. Currently I got error:

│ Error: error creating Access Application for account "***": access.api.error.application_already_exists (11010)
│ 
│   with cloudflare_access_application.wildebeest_access,
│   on main.tf line 165, in resource "cloudflare_access_application" "wildebeest_access":
│  165: resource "cloudflare_access_application" "wildebeest_access" {
│ 
╵
╷
│ Error: failed to create ruleset "http_request_firewall_managed" as a similar configuration with rules already exists and overwriting will have unintended consequences. If you are migrating from the Dashboard, you will need to first remove the existing rules otherwise you can remove the existing phase yourself using the API (https://api.cloudflare.com/#zone-rulesets-delete-zone-ruleset).
│ 
│   with cloudflare_ruleset.wildebeest_inbox,
│   on main.tf line 174, in resource "cloudflare_ruleset" "wildebeest_inbox":
│  174: resource "cloudflare_ruleset" "wildebeest_inbox" {
│ 
╵

What should I do?

The workaround for the first error:

1. From your main dashboard, click on Zero Trust to open a new tab with the Zero Trust Dashboard
2. From there, (see image) select Applications, then click "Delete" on the wildebeest-XXXX entry

For the second error, see @koehn's response ^^ but also see my earlier response to him regarding deleting the KV Namespaces, DNS Records, Pages Projects, etc.

Once you do that, re-run the failed GH Actions job and cross your fingers

[xtuc]

ruleset are a bit in a weird state because the UI in the dashboard hasn't shipped yet so only way is to use the API.

[yawnbox]

@yawnbox

So... I did this Visit the Access dashboard at https://dash.cloudflare.com/ and click the 'Enable Access' button. and there is no such button.

It's been re-branded as "Zero Trust" (see image):

Thanks (again).

I walked through the pointless setting up of a free Zero Trust thing in which it charged my credit card $0. Re-ran the deploy, new error.

[DataDrivenMD]

That is likely you have deployed rules in the past through the dashboard UI, hence an entrypoint ruleset had been automatically created by the UI behind the scene. Tested that you need to call the API https://developers.cloudflare.com/api/operations/zone-rulesets-delete-a-zone-ruleset to delete that entrypoint ruleset, then it can be managed by Terraform.

@xmflsct that did the trick, but for the record, the error wasn't due to any ruleset that I deployed, it was actually the orphaned wildebeest ruleset from an earlier (failed) run. Until the UI updates are shipped (h/t @xtuc), I would strongly recommend adding a CF API call to your deployment that checks whether the managed ruleset bypass already exists.

In fact, you'll probably need to do that for several steps along the Terraform deployment script in order to fix the numerous errors that trigger deployment failures due to pre-existing resources (see the comments from myself and others above). In the absence of such changes, I don't see how we won't keep running into these deployment roadblocks every time there's a substantive change to the project's infrastructure.

[DataDrivenMD]

I walked through the pointless setting up of a free Zero Trust thing in which it charged my credit card $0. Re-ran the deploy, new error.

That means you forgot to delete the KV Namespaces from an earlier failed run. See my earlier comment for the workaround.