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.

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

app scale doc: stop-start is faster than destroy-create for capacity #1137

Merged
merged 5 commits into from
Oct 31, 2023
Merged
Changes from 2 commits
Commits
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
21 changes: 13 additions & 8 deletions apps/scale-count.html.markerb
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,23 @@ layout: docs
nav: firecracker
order: 60
---
<%= partial "/docs/partials/v2_transition_banner" %>

<div class="callout">This document describes horizontal scaling of [V2 apps](/docs/reference/apps/#apps-v2), running on Fly Machines.
(There's also a doc on [scaling legacy V1 apps](/docs/apps/legacy-scaling/).)
catflydotio marked this conversation as resolved.
Show resolved Hide resolved

**For existing Nomad/V1 Fly Apps:** There's a whole doc on [scaling legacy V1 apps](/docs/apps/legacy-scaling/).
An app's horizontal scale, or the number of Fly Machines belonging to it, sets its maximum capacity. This is done by creating or destroying Machines.
catflydotio marked this conversation as resolved.
Show resolved Hide resolved

<div class="important icon">
Starting and stopping existing Machines is much faster than creating and destroying them. Stopped Machines are cheaper than running ones. Machines release their CPU and RAM when they stop, and their rootfs is rebuilt fresh from their Docker image, ready to start.

For bursty workloads, we recommend scaling up to enough Machines to handle your peak load, and adjusting the active capacity of the app by stopping and starting Machines as needed.
catflydotio marked this conversation as resolved.
Show resolved Hide resolved

For more information, see:
* [Automatically Stop and Start App Machines](/docs/apps/autostart-stop/), for adjusting active capacity based on traffic.
* [`fly machine` commands](/docs/flyctl/machine/), including [`start`](/docs/flyctl/machine-start/) and [`stop`](/docs/flyctl/machine-start/) subcommands to target individual Machines with flyctl.
* Machines API [stop](/docs/machines/working-with-machines/#stop-a-machine) and [start](/docs/machines/working-with-machines/#start-a-machine) endpoints.
</div>

There are two ways to scale the number of Machines managed by [Fly Launch](/docs/apps/) after deploying an app for the first time:
There are two ways to change the number of Machines managed by [Fly Launch](/docs/apps/) after deploying an app for the first time:

1. with the `fly scale count` subcommand
2. by explicitly [cloning](#scale-up-with-fly-machine-clone) or [destroying](#scale-down-with-fly-machine-destroy) existing Machines on the app
Expand All @@ -22,9 +30,6 @@ There are two ways to scale the number of Machines managed by [Fly Launch](/docs

When Machines are created or destroyed using `fly scale count` or `fly machine clone`/`fly machine destroy`, the resulting scale is preserved by `fly deploy`&mdash;except in the case that you scale right down to zero Machines. If there are no existing Machines, then `fly deploy` seeds the app with new Machines in the `primary_region` and according to the `[processes]` configured in your `fly.toml` file. For more information about how many Machines are created when you launch a new app or deploy from zero, refer to [Redundancy by default on first deploy](/docs/reference/app-availability/#redundancy-by-default-on-first-deploy).

You can also adjust the capacity of the app by starting and stopping its Machines. Stopped Machines cost less than running Machines because they don't consume any CPU or RAM resources. See [Automatically Stop and Start App Machines](/docs/apps/autostart-stop/) for ways to do this dynamically.


## View the app's current scale

`fly scale show` outputs all the scale information about an app's Machines: how many Machines of each VM specification, in each of the app's process groups, in each [region](/docs/reference/regions/).
Expand Down Expand Up @@ -324,4 +329,4 @@ If a Machine is misbehaving (for instance, it's not `stop`ping successfully), yo
fly machine destroy --force 0e286039f42e86
```

<div class="callout"> If you destroy a Machine with a volume attached, the volume remains intact until you either explicitly destroy the volume or destroy the Fly App it belongs to.</div>
<div class="important"> If you destroy a Machine with a volume attached, the volume remains intact until you either explicitly destroy the volume or destroy the app it belongs to.</div>