App Container Lifecycle
Page last updated:
Warning: VMware Tanzu Application Service for VMs (TAS for VMs) v2.9 is no longer supported because it has reached the End of General Support (EOGS) phase as defined by the Support Lifecycle Policy. To stay up to date with the latest software and security updates, upgrade to a supported version.
This topic describes the lifecycle of an app container for VMware Tanzu Application Service for VMs (TAS for VMs) deployments running on the Diego architecture.
The app deployment process involves uploading, staging, and starting the app in a container. Your app must successfully complete each of these phases within certain time limits. The default time limits for the phases are as follows:
- Upload: 15 minutes
- Stage: 15 minutes
- Start: 60 seconds
Note: Your administrator can change these defaults. Check with your administrator for the actual time limits set for app deployment.
If an app instance crashes, TAS for VMs automatically restarts it by rescheduling the instance on another container three times. After three failed restarts, TAS for VMs waits thirty seconds before attempting another restart. The wait time doubles each restart until the ninth restart, and remains at that duration until the 200th restart. After the 200th restart, TAS for VMs stops trying to restart the app instance.
Certain operator actions require restarting VMs with containers hosting app instances. For example, an operator who updates stemcells or installs a new version of TAS for VMs must restart all the VMs in a deployment.
TAS for VMs automatically relocates the instances on VMs that are shutting down through a process called evacuation. TAS for VMs recreates the app instances on another VM, waits until they are healthy, and then shuts down the old instances. During an evacuation, developers may see their app instances in a duplicated state for a brief period.
During this app duplication process, singleton app instances may become temporarily unavailable if the replacement instance does not become healthy within the Diego Cell’s evacuation timeout, which defaults to 10 minutes. Because of this, app developers with a low tolerance for brief downtime may prefer to run several instances of their app. See Run Multiple Instances to Increase Availability.
TAS for VMs requests a shutdown of your app instance in the following scenarios:
When a user runs
cf delete, or
As a result of a system event, such as the replacement procedure during Diego Cell evacuation or when an app instance stops because of a failed health check probe
To shut down the app, TAS for VMs sends the app process in the container a SIGTERM. By default, the process has ten seconds to shut down gracefully. If the process has not exited after ten seconds, TAS for VMs sends a SIGKILL.
By default, apps must finish their in-flight jobs within ten seconds of receiving the SIGTERM before TAS for VMs terminates the app with a SIGKILL. For instance, a web app must finish processing existing requests and stop accepting new requests.
If your apps require a longer period of time to finish in-flight jobs and gracefully shut down, you can increase the graceful shutdown period. For more information, see the Configure Advanced Features section of the Configuring TAS for VMs topic.
Note: One exception to the cases mentioned above is when monit restarts a crashed Diego Cell rep or Garden server. In this case, TAS for VMs immediately stops the apps that are still running using SIGKILL.