Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document new fly.toml deploy timeouts #1133

Merged
merged 3 commits into from
Oct 27, 2023
Merged

Document new fly.toml deploy timeouts #1133

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f687786
Document new fly.toml deploy timeouts
dangra Oct 27, 2023
2dbabd6
Update reference/configuration.html.markerb
dangra Oct 27, 2023
99413b1
Update reference/configuration.html.markerb
dangra Oct 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions reference/configuration.html.markerb
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -178,6 +178,8 @@

The environment variable `RELEASE_COMMAND=1` is set within the temporary release VM. You can use this to define behavior in your Dockerfile's `ENTRYPOINT` that's conditional on being run on a release VM.

By default, the release command has 5 minutes to complete before it is killed. It is possible to increase or decrease the timeout with `fly deploy --release-command-timeout=10m` or by setting `release_command_timeout = "10m"` in `[deploy]` section of `fly.toml`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: is there a maximum?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope


### Picking a deployment strategy

```toml
Expand Down Expand Up @@ -235,6 +237,17 @@

**Note:** In Apps V2, the [`primary_region` option](#primary-region) sets the `PRIMARY_REGION` environment variable within a Machine and overrides any value set in the `[env]` section.

#### Dealing with timeout errors while deploying a new version

Every time `fly deploy` runs, it builds a new docker image, pushes it to an internal registry, and then updates or creates machines for the app. Sometimes the image is too large, or the platform is slower than usual pulling the new image layers, triggering the default 2 minute timeout waiting for the Machine to be in a started state.

Check notice on line 242 in reference/configuration.html.markerb

View workflow job for this annotation

GitHub Actions / vale

[vale] reference/configuration.html.markerb#L242 

[Fly.Machine] Use 'Machines' instead of 'machines'.
Raw output 
{"message": "[Fly.Machine] Use 'Machines' instead of 'machines'.", "location": {"path": "reference/configuration.html.markerb", "range": {"start": {"line": 242, "column": 123}}}, "severity": "INFO"}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@andie787 "Vale" is suggesting to use "Machines" instead of "machines". Is that right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also get a rule for "Docker"


The good thing is that this timeout can be controlled in two ways, with the `--wait-timeout` option, for example `fly deplopy --wait-timeout=10m`, or as a more permanent `fly.toml` setting:

```toml
[deploy]
wait_timeout = "10m"
```

## The `http_service` section

[**Apps V2**](/docs/reference/apps/#apps-v2) **only:** For apps that only need HTTP and HTTPS services, you can replace the `[[services]]` section with this simpler alternative.
Expand Down
Loading