3 Tier Deployment Setup (ELB-PHP-MySQL)

Objective

To create a 3-tiered production-like deployment in Amazon EC2 using Amazon's Elastic Load Balancing service and ServerTemplates published by RightScale for launching a PHP application.

Note: The tutorial uses RightScale's latest revisions of the v12.11 LTS ServerTemplates that use Chef cookbooks and recipes instead of RightScripts.

Table of Contents

Prerequisites

• Access to add/create/edit DNS records with a supported DNS provider (e.g. DNSMadeEasy, DynDNS, Route53, Cloud DNS). 
• A paid edition of RightScale.
• 'designer' 'actor' and 'security_manager' user role privileges are required, although the 'security_manager' user role privilege may not be required if security group with the appropriate firewall permissions already exist.

Overview

Although this end-to-end tutorial was originally designed as a hands-on exercise in an Instructor Led Training course, anyone can follow the tutorial and use it as a learning tool as well. The class environment influences naming conventions, hence we often precede names with initials or names in our examples. (For example, an A Record for John Doe named "jd-www", rather than simply "www"). Be sure to provide enough time for yourself to complete the end-to-end exercise. (Estimate: 1-3hrs) 

This tutorial will demonstrate how to build a common 3-tier website architecture in the cloud using some of RightScale's ServerTemplates. 

• Amazon Elastic Load Balancing
• PHP Application servers
• MySQL Database servers

Disclaimers

• This tutorial assumes that you are launching all servers into the same Amazon EC2 region. 
• As a best practice, it's encouraged to deploy over multiple Datacenters / Zones (if supported by the cloud) for high-availability.

Deployment Setup

Database Tier Setup

Upload the Database Dump File

The ServerTemplate contains scripts that can retrieve a MySQL database dump file from a Remote Object Storage (ROS) location such as an Amazon S3 bucket or a Rackspace Cloud Files container. Create a new bucket/container and upload your database dump file. The file can remain a 'private' object because your cloud credentials can be used (as inputs) for authentication purposes to retrieve the file. Make sure the uploaded file maintains the .gz file extension.

Warning! The filename of the MySQL dump file cannot contain a dash (-) in its prefix name. For example, if your dump file is named, 'my-app-201205030022.gz', you must manually rename it to be 'my_app-201205030022.gz' where you use an underscore (_) to replace the dash, otherwise the script (do::do_dump_import) that imports the database dump file into the instance will fail.

• Create a New S3 Bucket
• Create a New Cloud Files Container

If you are setting up a database server for testing purposes or if you do not have your own dump file, you can use the following sample MySQL dump file to complete the tutorial. The sample is a gzip (.gz) file.

app_test-201109010029.gz

Create a Database Server

Follow these steps to add a database server to the deployment.

1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the Database Manager for MySQL 5.1 or Database Manager for MySQL 5.5ServerTemplate into your RightScale account.
2. From the imported ServerTemplate's show page, click the Add Server button.
3. Select the cloud for which you will configure a server. 
4. Select the deployment for the new server.
5. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
   • Server Name - Provide a nickname for your new database server (e.g., mysql-db1). Do not include "master" or "slave" in the name, because a database server's role can change in the future.
   • Select the appropriate cloud-specific resources (e.g. SSH Key, Security Group, etc.) that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters/zones, select a specific zone. Later, when you create the other database server you will use a different datacenter/zone to ensure high-availability. For more information, see Add Server Assistant.
   • Important! If you are not using volumes to store the database, you must select an instance type that has disk space that's at least twice as large as your database because LVM snapshots are performed locally on the instance before they are gzipped and saved to the specified ROS location. Also, although these ServerTemplates will work with any instance size, you may experience degraded performance with small instance sizes (such as EC2 micro, Rackspace 256MB etc) due to lack of system resources. We do not recommend smaller instance types for production use.
6. Click Confirm, review the server's configuration and click Finish to create the server.

Configure Inputs

The next step is to define the properties of your database server or servers by entering values for inputs. It is simplest and best to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.

The inputs that you need to provide values for will depend on which options you're going to use. The ServerTemplate is very flexible and supports a variety of different configurations. You will need to provide the necessary values as inputs based on which options you want to use.

• Where will the contents of the database be stored?
  • On volumes attached to the instance.
  • On the local/ephemeral drive - Ignore all "Block Device" inputs.
• If you're using volumes, are you going to use a stripe?
  • Yes - Use a stripe of multiple volumes.
  • No - Use a single volume. 
  • INPUTS: Block Device Mount Directory (1), Nickname (1), Number of Volumes in the Stripe (1), Total Volume Size (1)
• Are you building a master-slave database setup with replication?
  • Yes
  • No
  • INPUTS: Database Master FQDN, Database Master DNS Record ID, Database Slave FQDN, Database Slave DNS Record ID, Database Replication Password, Database Replication Username
• What are you going to use to take "primary" backups of the database?
  • Snapshots
  • Binary Dumps to a ROS container (e.g. S3 bucket or Cloud Files container)
  • INPUTS: Backup Primary Secret (default), Backup Primary User (default), Primary Backup Storage Cloud (default)
• Are you going take "secondary" backups of the database? If yes, which ROS provider will you use?
  • Amazon S3
  • Rackspace Cloud Files
  • INPUTS: Secondary Backup Storage Cloud (default), Secondary Backup Secret (default), Secondary Backup User (default), Secondary Backup Storage Container (1)
• Which DNS provider are you using for dynamic DNS at the database level?
  • DNS Made Easy
  • DynDNS
  • Amazon Route 53
  • Cloud DNS
  • INPUTS: DNS Service Provider, DNS Password, DNS User

Set Inputs at the Deployment Level

Go to the deployment's Inputs tab (Manage > Deployments > your deployment > Inputs) and click Edit.

Although you can enter values for missing inputs as text values, it's strongly recommended that you set up credentials for passing sensitive information to scripts such as passwords or any other sensitive data.

Rackspace only
If you use Rackspace for your database servers and backup storage (i.e., Cloud Files) the storage-related Chef recipes will use Rackspace Service Net (SNET) by default. SNET is Rackspace's internal private networking service for optimized communication between Rackspace Cloud Servers and Cloud Files. If SNET is not supported in your Rackspace environment, you must set the "Rackspace SNET Enabled for Backup" input to false; otherwise, all backup and restore operations that rely on Cloud Files will fail.

Block Device

If the cloud supports the use of block devices (e.g. AWS EBS Volumes, CloudStack volumes, etc.), it's strongly recommended that you use block devices to store the contents of the MySQL database. Backups of the database will be stored as snapshots.

If the cloud does not support block devices (e.g. Rackspace), you must use a Remote Object Store container (e.g. Rackspace Cloud Files container) the contents of the MySQL database will be stored locally on the instance's ephemeral drive. Backups of the database will be stored as binary dump files to the specified storage container.

Required

Optional

DB

SYS_DNS

Launch the Database Server

After configuring your inputs, launch your newly configured master database server.

1. Go to the deployment's Servers tab and launch the database server. When you view the input confirmation page, there should not be any required inputs with missing values.  If there are any required inputs that are missing values (highlighted in red), cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process. Because there are no required inputs that are missing values for any boot scripts, you can click the Launch button at the bottom of the input confirmation page. 

Initialize the Master Database Server

Wait for the server to reach the "operational" state before you run a script to initialize the database server.

1. Go to the "current" server's Scripts tab and run the db::do_init_and_become_master operational script to initialize it as the "Master" database server.
   
2. You can go to the "current" server's Audit Entries tab to track the status of the operation.

The script performs the following actions:

• Registers it as the "master" database server and assign appropriate replication privileges.
• For cloud providers with volume support, create and mount either a single volume or group of striped volumes for data storage.
• Creates a database backup to primary storage.

• Schedules a cron job to run backups to primary storage once per day on the server. (For information on modifying the default backup schedule, see the Database Manager for MySQL 5.1/5.5 Runbook.)
• Updates the dynamic DNS record for the "Master" database with your DNS provider. The DNS record will be updated with the server's private IP address. 
  Warning! If using Amazon Route 53 as your DNS provider, ensure that the TTL (time to live) is set to 60 seconds for each DNS record. Using a different TTL value will cause the db::do_init_and_become_master script to fail. If you are using Rackspace's Cloud DNS service, the DNS record's TTL and the value specified for the 'Database DNS TTL Limit' input must match. (e.g. 300)

Disable Scheduled Primary Backups

Since you have not loaded an actual database onto the server there is no reason to create a primary backup of the database.

Go to the "current" server's Scripts tab and run the db::do_primary_backup_schedule_disable operational script to disable your scheduled backups (cron jobs). 

Later, once you have imported your database you will reverse this action and enable continuous backups.

Set Up the Database

After initializing the master database server and disabling scheduled backups, you will need to add your database (or databases) and records to it.

1. Go to the "current" server's Scripts tab and run the db::do_dump_import operational script to import a MySQL dump file from an ROS location.

Note: If you use a previous backup snapshot instead of a MySQL dump file or initialize a blank MySQL database, refer to the Database Manager for MySQL 5.1/5.5 Runbook for instructions.

Create a Primary Backup

You are now ready to create the first primary backup of the database. You will need a completed backup in order to initialize a slave database server.

1. Go to the "current" server's Scripts tab and run the db::do_primary_backup operational script to manually generate a primary backup of your database server.

Enable Scheduled Primary Backups

It is now safe to enable continuous backups of the database server.

1. Go to the "current" server's Scripts tab and run the db::do_primary_backup_schedule_enable operational script.

For more information about configuring and modifying your scheduled backup policy, see the Database Manager for MySQL 5.1/5.5 Runbook.

Add a Slave Database Server

Although you can run MySQL in single-server mode and having a separate slave server for replication purposes is not required, this is strongly recommended for failover purposes. Create a slave server in your deployment.

1. Clone the Master-DB server. See Clone a Server.
2. Rename the server accordingly. (e.g. mysql-db2) Remember, you do not want to include the word "slave" in the nickname because this server may become the "master" server during a failover scenario. You don't want the server's nickname to potentially cause any confusion.
3. Under the server's Info tab, click Edit and change the server's availability zone. In order to ensure high availability, it's strongly recommended that you launch the Slave-DB server in a different availability zone as the Master-DB.  Note: Cross-zone data transfer costs may apply.

Launch the Slave Database Server

Make sure the following conditions are true before you launch the second database server.

• The master database server state is "operational."
• The initial primary backup of the master database server is 100% complete. If you are using a cloud that supports snapshots for backups, you can track the status in the dashboard (Clouds > region > Snapshots). The time required to complete the initial primary backup will vary based on factors such as storage type, volume size, etc.

You are now ready to launch a "slave" database server for failover and redundancy purposes. 

1. Go to the deployment's Servers tab and launch the server that will be the slave database server. There should be no missing inputs. 

Initialize the Slave Database Server

Wait for the server to reach the "operational" state before initializing it as a "slave" of the master database server.

1. Go to the "current" server's Scripts tab and run the db::do_primary_init_slave operational script.

The script performs the following actions:

• Assigns the "slave" role to the server.
• Uses the most recently completed database backup (default) to initially populate the database in order to reduce the time needed for the slave to become in-sync with the master.
• Sends a request to the master server to allow connections from the slave server's private IP address and opens the default MySQL client port (TCP port 3306) on the master server's firewall (i.e., iptables) for this purpose.
• Schedules a cron job to run primary backups of the database. 

(Optional) Update the DNS Record for the Slave Database Server

If you created a DNS record for the slave database server, you can set a value for the Database Slave DNS Record ID input and run the db::do_set_dns_slave_private_ip operational script.

Test Database Setup (optional)

If you want to test the status of the "master" and "slave" database servers, see Check Database Status of Master or Slave.

Load Balancer Tier Setup

Create a Load Balancer

1. Go to Clouds > AWS Region > Load Balancing
2. Click Create ELB and fill out the required form fields:

General Info

• Load Balancer name - The name of our Elastic Load Balancer. It must be unique within your AWS account.
• VPC - The Virtual Private Cloud you'd like to associate to this load balancer.
• Internal Load Balancer - Select this option to create an internal load balancer. A DNS name will be created and it will contain the private IP address of the load balancer. This option is only available if you set a value for VPC.
• Subnets - Your load balancer can interface with instances in one or more subnets. Only subnets in the selected VPC are available. This option is only visible if you set a value for VPC.
• Security Groups - One or more security groups to manage traffic communicating with your load balancer. This option is only visible if you set a value for VPC.
• Availability Zone(s) - Select all of the availability zones for which the ELB will service. (Tip: Click in the box to view and select additional zones.) An ELB will only load balance across instances in the selected availability zones. An ELB is region-specific; it cannot load balance across multiple regions. For example, you cannot load balance your application traffic amongst instances in the 'us-east' and 'us-west' regions. Note: This field is not displayed if you have selected a value for VPC.

Default Listener

• LB Protocol - The routing transport protocol that will be used by the ELB. (TCP, HTTP, HTTPS)
• LB Port - External port that the ELB will listen on to accept client requests. Valid ports are 80, 443, 1024-65535.
  • For an example (v13.5 LTS) 3-tier deployment, use HTTP:80.
• Instance Protocol - The routing transport protocol that the ELB will use to connect to the instances (i.e. application servers) in its load balancing pool. (HTTP, HTTPS, TCP, SSL)  If you are using one of the application ServerTemplates (v12+) published by RightScale, select 'HTTP' for the protocol. Note: The Load Balancer and Instance Protocols must match. You can create additional listener rules after you create the ELB.]
• Instance Port - The port that the ELB will use to send traffic to the application instances. Valid ports are 1 to 65535. The Instance Port does not have to match the Load Balancer Port. If you are using one of the application ServerTemplates (v12+) published by RightScale, the default application listener port is '8000'.
  • For an example (v13.5 LTS) 3-tier deployment, use HTTP:8000.
• Stickiness - This is where you can create a session sticky policy for your load balancer (stickiness meaning that once a session starts, all requests will attempt to routed subsequent to the same server for that given session). You can select one of the following options:
  • Disable Stickiness - Does not allow session stickiness the load balancer and application server. 
  • Load Balancer Generated Cookie Stickiness - A special cookie is used to track the backend server instance for each request. When the LB receives a request, it checks to see if this cookie is present in the request. If so, the load balancer sends the request to the application server specified in the cookie. If not, the request is sent to a server chosen based on the existing load balancing algorithm. This option creates a stickiness policy with sticky session lifetime controlled by the lifetime of the browser or a specified expiration period. This only works with HTTP/HTTPS listeners.
  • Application Generated Cookie Stickiness - This is similar to the Load Balancer Generated Cookie Stickiness option, with the following exception: once a cookie is explicitly removed or expires, the session stops being sticky until a new application cookie is issued.

3. Click Save.
4. Configure the Health Check test for the ELB and click Save.

​

Add Additional Listeners (optional)

Elastic Load Balancers support both HTTP and HTTPS (SSL) requests. When you create an ELB, you must define a default listener. If you wish to set up additional listeners (e.g. HTTPS), you can configure them after the ELB is created.

Listener ports should be defined when your ELB is created. If you are setting up an ELB to load balance across applications servers launched with one of RightScale's v12.11 or v13.5 LTS ServerTemplates, you may need to modify your ELB and add additional listeners, as necessary.

1. Click on the Elastic Load Balancer you would like to modify. 
2. Check the configuration of the application ServerTemplate that will be used to launch the application servers that will connect to the ELB. Make sure that the application servers are configured to listen for requests from the ELB on the correct port. You will need to set up the listener appropriately, depending on how the application servers will be configured. (e.g. Application Listen Port (8000), LB_PORT (80), etc.)
3. To configure HTTP access, add a listener to forward requests to the appropriate port (e.g. 8000) for the application server. Click Add Listener to create a new listener for the ELB.
   • LB Protocol: Select 'HTTP'
   • LB Port: Enter '80'
   • Instance Protocol: Select 'HTTP'
   • Instance Port: Use '8000' (for v12.11 or v13.5 LTS ServerTemplates); use '8080' (for v14 ServerTemplates)
   • Stickiness: You can choose either to have stickiness disabled or generate a sticky session based on either load balancer or application generated HTTP cookies.
4. To allow HTTPS (SSL) access, add a listener to forward requests to the appropriate port (e.g. 8000) for the application servers. Click Add Listener to create a new listener for the ELB.
   • LB Protocol: Select 'HTTPS'
   • LB Port: Enter '443'
   • Instance Protocol: Select 'HTTPS'
   • Instance Port: Use '8000' (for v12.11 or v13.5 LTS ServerTemplates); use '8080' (for v14 ServerTemplates)
   • Stickiness: You can choose either to have stickiness disabled or generate a sticky session based on either load balancer or application generated HTTP cookies.
   • Certificate: Select an SSL Certificate. See Create an AWS Server Certificate.

Update the DNS Records

Once you've created your ELB, find its DNS name (e.g. elbname-12345678.us-east-1.elb.amazonaws.com) and use it to create a CNAME with your DNS provider. For an ELB, you cannot create a DNS record that points to an IP address because it could change over time.  

1. Go to the Elastic Load Balancer's Info tab in the RightScale Dashboard. 
2. Copy the "DNS name" for the ELB. (e.g. elb-name-2005463590.us-west-1.elb.amazonaws.com)

3. Create a CNAME with your DNS provider (e.g. AWS Route 53, DNS Made Easy, DynDNS, etc.)

Example: Amazon Route 53

Create a Security Group for Application Servers

The next step is to create or update a security group that will be used by application servers to allows ingress communication from an ELB. By default, RightScale's Linux-based application ServerTemplates (e.g. PHP, Rails, Tomcat) listen on TCP port 8000 and the Windows-based application ServerTemplate (e.g. Microsoft IIS App) listens on TCP port 80.

1. Create or modify a security group in the AWS region where the ELB will service requests to the application servers. Later, you will configure the application servers to use this security group in order to connect to the ELB. 
2. Create the desired port permissions. At a minimum, you will need to open up port 80 for HTTP access. You can also open up 443 for HTTPS (SSL) access. Specify the following information to create a permission for an ELB.
   • Direction: Inbound
   • Protocol: TCP - Group
   • Ports:
     • For v12.11 or v13.5 LTS ServerTemplates, use 8000..8000 (PHP, Rails, Tomcat, Django); 80..80 (Microsoft IIS)

     • For v14 ServerTemplates, use 8080..8080 (PHP, Rails, Tomcat, Django); 80..80 (Microsoft IIS)

   • Owner: amazon-elb
   • Group: amazon-elb-sg

Application Tier Setup

Prepare Application Code

The ServerTemplate supports the ability to download your application code either as a tarball (.tgz) from a Remote Object Storage location or checkout the codebase from a software repository.

• Remote Object Storage (ROS)
  • Amazon S3
  • Rackspace Cloud Files
  • SoftLayer Object Storage
• Software Repository
  • Git
  • SVN

Remote Object Storage (ROS)

• Amazon S3 Bucket
• Rackspace Cloud Files Container
• SoftLayer Object Storage Container

If you have a tarball of your application, upload it to a Remote Object Storage location as either a 'public-read' or 'private' object. If you are using a 'private' object you must provide valid cloud credentials (as inputs) for authentication purposes in order to properly retrieve the object. For more information see the following tutorials.

• Create a New S3 Bucket
• Create a New Cloud Files Container
• SoftLayer Object Storage

Software Repository

• Git
• SVN

If you want to checkout your application code from a software repository (e.g. GitHub), you will need to provide your access credentials as inputs later in this tutorial so that a script can be executed to automatically retrieve your application code. If the code is in a private repository, you may need to generate an SSK key (e.g. GitHub SSH Key) for authentication purposes and create a credential (Design -> Credentials) to store the sensitive value.

Sample Application

Git Repository

If you need an example application for testing purposes, you can use the application code from the following git repository.

• Project App root - Set to "No value/ignore" or "Inherit:no value to inherit"
• Git SSH Key - Set to "No value/ignore" or "Inherit:no value to inherit"
• Repository Provider - repo_git
• Repository URL - git://github.com/rightscale/examples.git
• Branch/Tag - unified_php

Tarball (.tgz)

If you prefer to use a tarball instead, download the file below and upload it into your own remote storage container. (e.g. S3 bucket)

• phptest.tgz

Create the Application Tier

You can either add application servers directly into a deployment or create an server array of application servers for autoscaling. 

Import the ServerTemplate

1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account.
   • PHP App Server (v12.11.x-LTS)
2. (Optional) If you expect to make changes to the ServerTemplate, you will need to clone it to create an editable copy.  Click the Clone button and rename the ServerTemplate accordingly. (e.g. My App Server) Before you make any changes to the ServerTemplate, click the Commit button so that the first revision of the ServerTemplate matches the original revision, which will make it easier to perform differentials in the future to see what changes were made to the "original" version. When committing the ServerTemplate you can use a simple commit message. (e.g. Original version. No changes.) If you are actively developing the ServerTemplate, you may find it useful to use the HEAD version of the ServerTemplate to create the application server tier. However, for production environments, you should always use static, committed revisions of a ServerTemplate to launch servers.

Create a Server or Server Array

When you create a server or server array, you will first need to select a deployment and the cloud where the server will eventually be launched into (e.g. AWS us-east). Based on the chosen cloud provider, you will need to complete the configuration process that's specific for that cloud. For example, some cloud providers support features that are unique to their specific cloud. 

• To create a server, click the Add Server button and complete the steps in the wizard. See Add Server Assistant for details. If you are setting up a multi-tier deployment, it's strongly recommended that you create at least two application servers.
  • The easiest way to create the second server is to clone the first one. Be sure to change the name of the server accordingly (e.g. app2) and its availability zone (if available) under the Info tab.
• To create a scalable server array, click the Add Array button and complete the steps in the wizard. See Add Server Array Assistant for details. 

Configure Inputs

The next step is to define the properties of your application server by entering values for inputs. It is best to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.

To enter inputs for the Chef recipes that will run on your application servers, open the deployment's Inputs tab, click Edit, and use the following instructios to configure the input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.

Note: The following examples and sample values assume that you will connect the application server with RightScale's "Load Balancer" ServerTemplate, which uses HAProxy. If you are using a cloud's load balancing service such as Rackspace Cloud Load Balancing (CLB) or Amazon's Elastic Load Balancing (ELB), please refer to the PHP Application Server Runbook for proper setup instructions.

APP

DB_MYSQL

DB

LB

PHP

REPO

The values that you use for the repository inputs will depend on where the application code will be retrieved from. The selection for the Repository Provider input will determine which inputs will be used to retrieve the application. Unrelated inputs are ignored.

ALL Repositories (ROS, Git, SVN)

The following inputs are used to retrieve the application from either a Git/SVN software repository or an ROS location (Amazon S3 bucket or Rackspace Cloud Files container). Specify the appropriate inputs based upon the selection for the 'Repository Provider' input.

Git Repository

Important!
If you are checking out code from a Git repository, specify values for the following inputs.

SVN Repository

Important!
If you are checking out code from an SVN repository, specify values for the following inputs.

Remote Object Storage (ROS)

Important!
If you are checking out code from a Remote Object Storage (ROS) location, specify values for the following inputs.

WEB_APACHE

Launch the Server

After configuring your inputs, launch all of the PHP application servers. Refer to the instructions in Launch a Server if you are not already familiar with this process.

Test the Deployment

Once all of the servers are operational you can perform the following tests.

Shutting Down

You may find the need to perform some clean up, either to minimize costs, or to perform the tutorial again from a clean slate. Follow these high level steps to do so:

• Terminate the Load Balancers.
• Terminate the Master and Slave Database Servers. (If you are using volumes, see the Database Manager for MySQL 5.1/5.5 Runbook for proper instructions.)
• Delete the Deployment.
• Delete the two EIPs (if applicable and they no longer need to be preserved)
• Delete the one cloned ServerTemplate for the Application Servers that you created.
• Delete the SSH Key.
• Delete the Security Group(s).
• Delete all Credentials (unless you are sharing your account or Deployment with others who might still be using them).
• Delete all four DNS A records (if applicable)
• Delete the application and database dump files from the ROS containers
• Delete the ROS containers (e.g. S3 bucket)