Skip to main content

​
Overview

An operation is performed and recorded for all changes made to resources, environments, and stacks. As operations are performed, operation logs are outputted and stored within Aptible. Operations are designed with reliability in mind - with minimal downtime and automatic rollbacks.

​
Type of Operations

​
Operation Logs

For all operations performed, Aptible collects operation logs. These logs are retained only for active resources.

​
Minimal downtime operations

To further mitigate the impact of failures, Aptible Operations are designed to be interruptible at any stage whenever possible. In particular, when deploying a web application, Aptible performs Zero-Downtime Deployment. This ensures that if the Operation is interrupted at any time and for any reason, it still won’t take your application down. When downtime is inevitable (such as when resizing a Database volume or redeploying a Database to a bigger instance), Aptible optimizes for minimal downtime. For example, when redeploying a Database to another instance, Aptible must perform the following steps:
  • Shut down the old Database Container.
  • Unmount and then detach the Database volume from the instance the Database was originally scheduled on.
  • Attach then remount the Database volume on the instance the Database is being re-scheduled on.
  • Start the new Database Container.
When performing this Operation, Aptible will minimize downtime by ensuring that all preconditions are in place to start the new Database Container on the new instance before shutting down the old Database Container. In particular, Aptible will ensure the new instance is available and has pre-pulled the Docker image for your Database.

​
Operation Rollbacks

When an operation fails, Aptible makes it easy to restore your architecture to a good state:
  • Automatic Rollbacks: If a failure occurs during an operation (e.g., one of your stack’s underlying EC2 instances fails), Aptible automatically restores your architecture to its last known good state.
  • Manual Rollbacks: Teams can also roll back an operation on demand, selecting a previous successful deployment to restore.

​
Automatic Rollbacks

All Aptible operations are designed to support automatic rollbacks in the event of a failure, with the exception of a handful of trivial operations with no side effects (such as launching Ephemeral SSH Sessions). When a rollback is initiated, a message is displayed within the operation logs indicating whether it succeeded (everything was restored to the way it was before the operation) or failed (some changes could not be undone).
Some side-effects of deployments cannot be rolled back by Aptible. In particular, database migrations performed in before_release commands cannot be rolled back (unless you design your migrations to roll back on failure, of course!). We strongly recommend designing your database migrations so that they are backwards compatible across at least one release. This is a very good idea in general (not just on Aptible), and a best practice for zero-downtime deployments (see Concurrent Releases for more information).

​
Manual Rollbacks

An in-progress operation can be rolled back by cancelling it with the aptible operation:cancel command. To return an App to an earlier release after a deploy has already finished, see Rollbacks.

​
FAQ

Operation Logs can be accessed in the following ways:
  • Within the Aptible Dashboard:
    • Within the resource summary by:
      • Navigating to the respective resource
      • Selecting the Activity tab
    • Within the Activity dashboard by:
      • Navigating to the Activity page
      • Selecting the Logs button for the respective operation
        • Note: This page only shows operations performed in the last 7 days.
  • Within the Aptible CLI by using the aptible operation:logs command
    • Note: This command only shows operations performed in the last 90 days.
Activity Reports can be downloaded in CSV format within the Aptible Dashboard by:
  • Selecting the respective Environment
  • Selecting the Activity Reports tab Activity reports
Reliability is a top priority at Aptible in general and for Aptible in particular. That said, occasional failures during Operations are inevitable and may be caused by the following:
  • Failing third-party services: Aptible strives to minimize dependencies on the critical path to deploying an App or restarting a Database, but Aptible nonetheless depends on a number of third-party services. Notably, Aptible depends on AWS EC2, AWS S3, AWS ELB, and the Docker Hub (with a failover or Quay.io and vice-versa). These can occasionally fail and when they do, they may cause Aptible Operations to fail.
  • Crashing instances: Aptible is built on a fleet of Linux instances running Docker. Like any other software, Linux and Docker have bugs and may occasionally crash. Here again, when they do, Aptible operations may fail