# Tutorial: Deploy WordPress to an Amazon EC2 instance (Amazon Linux or Red Hat Enterprise Linux and Linux, macOS, or Unix)
In this tutorial, you deploy WordPress, an open source blogging tool and content management system based on PHP and MySQL, to a single Amazon EC2 instance running Amazon Linux or Red Hat Enterprise Linux (RHEL).
Not what you're looking for?
+ To practice deploying to an Amazon EC2 instance running Windows Server instead, see [Tutorial: Deploy a "hello, world\$1" application with CodeDeploy (Windows Server)](tutorials-windows.md).
+ To practice deploying to an on-premises instance instead of an Amazon EC2 instance, see [Tutorial: Deploy an application to an on-premises instance with CodeDeploy (Windows Server, Ubuntu Server, or Red Hat Enterprise Linux)](tutorials-on-premises-instance.md).
This tutorial's steps are presented from the perspective of a local development machine running Linux, macOS, or Unix. Although you can complete most of these steps on a local machine running Windows, you must adapt the steps that cover commands such as **chmod** and **wget**, applications such as sed, and directory paths such as `/tmp`.
Before you start this tutorial, you must complete the prerequisites in [Getting started with CodeDeploy](getting-started-codedeploy.md). These include configuring a user, installing or upgrading the AWS CLI, and creating an IAM instance profile and a service role.
**Topics**
+ [Step 1: Launch and configure an Amazon Linux or Red Hat Enterprise Linux Amazon EC2 instance](tutorials-wordpress-launch-instance.md)
+ [Step 2: Configure your source content to be deployed to the Amazon Linux or Red Hat Enterprise Linux Amazon EC2 instance](tutorials-wordpress-configure-content.md)
+ [Step 3: Upload your WordPress application to Amazon S3](tutorials-wordpress-upload-application.md)
+ [Step 4: Deploy your WordPress application](tutorials-wordpress-deploy-application.md)
+ [Step 5: Update and redeploy your WordPress application](tutorials-wordpress-update-and-redeploy-application.md)
+ [Step 6: Clean up your WordPress application and related resources](tutorials-wordpress-clean-up.md)
# Step 1: Launch and configure an Amazon Linux or Red Hat Enterprise Linux Amazon EC2 instance
To deploy the WordPress application with CodeDeploy, you'll need an Amazon EC2 instance running Amazon Linux or Red Hat Enterprise Linux (RHEL). The Amazon EC2 instance requires a new inbound security rule that allows HTTP connections. This rule is needed in order to view the WordPress page in a browser after it is successfully deployed.
Follow the instructions in [Create an Amazon EC2 instance for CodeDeploy](instances-ec2-create.md). When you get to the part in those instructions about assigning an Amazon EC2 instance tag to the instance, be sure to specify the tag key of **Name** and the tag value of **CodeDeployDemo**. (If you specify a different tag key or tag value, then the instructions in [Step 4: Deploy your WordPress application](tutorials-wordpress-deploy-application.md) may produce unexpected results.)
After you've followed the instructions to launch the Amazon EC2 instance, return to this page, and continue to the next section. Do not continue on to [Create an application with CodeDeploy](applications-create.md) as the next step.
## Connect to your Amazon Linux or RHEL Amazon EC2 instance
After your new Amazon EC2 instance is launched, follow these instructions to practice connecting to it.
1. Use the **ssh** command (or an SSH-capable terminal emulator like [PuTTY](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html)) to connect to your Amazon Linux or RHEL Amazon EC2 instance. You will need the public DNS address of the instance and the private key for the key pair you used when you started the Amazon EC2 instance. For more information, see [Connect to Your Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-connect-to-instance-linux.html).
For example, if the public DNS address is **ec2-01-234-567-890.compute-1.amazonaws.com**, and your Amazon EC2 instance key pair for SSH access is named **codedeploydemo.pem**, you would type:
```
ssh -i /path/to/codedeploydemo.pem ec2-user@ec2-01-234-567-890.compute-1.amazonaws.com
```
Replace `/path/to/codedeploydemo.pem` with the path to your `.pem` file and the example DNS address with the address to your Amazon Linux or RHEL Amazon EC2 instance.
**Note**
If you receive an error about your key file's permissions being too open, you will need to restrict its permissions to give access only to the current user (you). For example, with the **chmod** command on Linux, macOS, or Unix, type:
```
chmod 400 /path/to/codedeploydemo.pem
```
1. After you are signed in, you will see the AMI banner for the Amazon EC2 instance. For Amazon Linux, it should look like this:
```
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
```
1. You can now sign out of the running Amazon EC2 instance.
**Warning**
Do not stop or terminate the Amazon EC2 instance. Otherwise, CodeDeploy won't be able to deploy to it.
## Add an inbound rule that allows HTTP traffic to your Amazon Linux or RHEL Amazon EC2 instance
The next step confirms your Amazon EC2 instance has an open HTTP port so you can see the deployed WordPress application's home page in a browser.
1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Choose **Instances**, and then choose your instance.
1. On the **Description** tab, under **Security groups**, choose **view inbound rules**.
You should see a list of rules in your security group like the following:
```
Security Groups associated with i-1234567890abcdef0
Ports Protocol Source launch-wizard-N
22 tcp 0.0.0.0/0 ✔
```
1. Under **Security groups**, choose the security group for your Amazon EC2 instance. It might be named **launch-wizard-*N***. The ***N*** in the name is a number assigned to your security group when your instance was created.
Choose the **Inbound** tab. If the security group for your instance is configured correctly, you should see a rule with the following values:
+ **Type**: HTTP
+ **Protocol**: TCP
+ **Port Range**: 80
+ **Source**: 0.0.0.0/0
1. If you do not see a rule with these values, use the procedures in [Adding Rules to a Security Group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) to add them to a new security rule.
# Step 2: Configure your source content to be deployed to the Amazon Linux or Red Hat Enterprise Linux Amazon EC2 instance
Now it's time to configure your application's source content so you have something to deploy to the instance.
**Topics**
+ [Get the source code](#tutorials-wordpress-configure-content-download-code)
+ [Create scripts to run your application](#tutorials-wordpress-configure-content-create-scripts)
+ [Add an application specification file](#tutorials-wordpress-configure-content-add-appspec-file)
## Get the source code
For this tutorial, you deploy the WordPress content publishing platform from your development machine to the target Amazon EC2 instance. To get the WordPress source code, you can use built-in command-line calls. Or, if you have Git installed on your development machine, you can use that instead.
For these steps, we assume you downloaded a copy of the WordPress source code to the `/tmp` directory on your development machine. (You can choose any directory you like, but remember to substitute your location for `/tmp` wherever it is specified in these steps.)
Choose one of the following two options to copy the WordPress source files to your development machine. The first option uses built-in command-line calls. The second option uses Git.
**Topics**
+ [To get a copy of the WordPress source code (built-in command-line calls)](#tutorials-wordpress-configure-content-download-code-command-line)
+ [To get a copy of the WordPress source code (Git)](#tutorials-wordpress-configure-content-download-code-git)
### To get a copy of the WordPress source code (built-in command-line calls)
1. Call the **wget** command to download a copy of the WordPress source code, as a .zip file, to the current directory:
```
wget https://github.com/WordPress/WordPress/archive/master.zip
```
1. Call the **unzip**, **mkdir**, **cp**, and **rm** commands to:
+ Unpack the `master` .zip file into the `/tmp/WordPress_Temp` directory (folder).
+ Copy its unzipped contents to the `/tmp/WordPress` destination folder.
+ Delete the temporary `/tmp/WordPress_Temp` folder and `master` file.
Run the commands one at a time:
```
unzip master -d /tmp/WordPress_Temp
```
```
mkdir -p /tmp/WordPress
```
```
cp -paf /tmp/WordPress_Temp/WordPress-master/* /tmp/WordPress
```
```
rm -rf /tmp/WordPress_Temp
```
```
rm -f master
```
This leaves you with a clean set of WordPress source code files in the `/tmp/WordPress` folder.
### To get a copy of the WordPress source code (Git)
1. Download and install [Git](http://git-scm.com) on your development machine.
1. In the `/tmp/WordPress` folder, call the **git init** command.
1. Call the **git clone** command to clone the public WordPress repository, making your own copy of it in the `/tmp/WordPress` destination folder:
```
git clone https://github.com/WordPress/WordPress.git /tmp/WordPress
```
This leaves you with a clean set of WordPress source code files in the `/tmp/WordPress` folder.
## Create scripts to run your application
Next, create a folder and scripts in the directory. CodeDeploy uses these scripts to set up and deploy your application revision on the target Amazon EC2 instance. You can use any text editor to create the scripts.
1. Create a scripts directory in your copy of the WordPress source code:
```
mkdir -p /tmp/WordPress/scripts
```
1. Create an `install_dependencies.sh` file in `/tmp/WordPress/scripts`. Add the following lines to the file. This `install_dependencies.sh` script installs Apache, MySQL, and PHP. It also adds MySQL support to PHP.
```
#!/bin/bash
sudo amazon-linux-extras install php7.4
sudo yum install -y httpd mariadb-server php
```
1. Create a `start_server.sh` file in `/tmp/WordPress/scripts`. Add the following lines to the file. This `start_server.sh` script starts Apache and MySQL.
```
#!/bin/bash
systemctl start mariadb.service
systemctl start httpd.service
systemctl start php-fpm.service
```
1. Create a `stop_server.sh` file in `/tmp/WordPress/scripts`. Add the following lines to the file. This `stop_server.sh` script stops Apache and MySQL.
```
#!/bin/bash
isExistApp="pgrep httpd"
if [[ -n $isExistApp ]]; then
systemctl stop httpd.service
fi
isExistApp=pgrep mysqld
if [[ -n $isExistApp ]]; then
systemctl stop mariadb.service
fi
isExistApp=pgrep php-fpm
if [[ -n $isExistApp ]]; then
systemctl stop php-fpm.service
fi
```
1. Create a `create_test_db.sh` file in `/tmp/WordPress/scripts`. Add the following lines to the file. This `create_test_db.sh` script uses MySQL to create a **test** database for WordPress to use.
```
#!/bin/bash
mysql -uroot <
Next, add an application specification file (AppSpec file), a [YAML](http://www.yaml.org)-formatted file used by CodeDeploy to:
+ Map the source files in your application revision to their destinations on the target Amazon EC2 instance.
+ Specify custom permissions for deployed files.
+ Specify scripts to be run on the target Amazon EC2 instance during the deployment.
The AppSpec file must be named `appspec.yml`. It must be placed in the root directory of the application's source code. In this tutorial, the root directory is `/tmp/WordPress`
With your text editor, create a file named `appspec.yml`. Add the following lines to the file:
```
version: 0.0
os: linux
files:
- source: /
destination: /var/www/html/WordPress
hooks:
BeforeInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
AfterInstall:
- location: scripts/change_permissions.sh
timeout: 300
runas: root
ApplicationStart:
- location: scripts/start_server.sh
- location: scripts/create_test_db.sh
timeout: 300
runas: root
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 300
runas: root
```
CodeDeploy uses this AppSpec file to copy all of the files in the `/tmp/WordPress` folder on the development machine to the `/var/www/html/WordPress` folder on the target Amazon EC2 instance. During the deployment, CodeDeploy runs the specified scripts as `root` in the `/var/www/html/WordPress/scripts` folder on the target Amazon EC2 instance at specified events during the deployment lifecycle, such as **BeforeInstall** and **AfterInstall**. If any of these scripts take longer than 300 seconds (5 minutes) to run, CodeDeploy stops the deployment and marks the deployment as failed.
For more information about these settings, see the [CodeDeploy AppSpec file reference](reference-appspec-file.md).
**Important**
The locations and numbers of spaces between each of the items in this file are important. If the spacing is incorrect, CodeDeploy raises an error that might be difficult to debug. For more information, see [AppSpec File spacing](reference-appspec-file.md#reference-appspec-file-spacing).
# Step 3: Upload your WordPress application to Amazon S3
Now you will prepare and upload your source content to a location from which CodeDeploy can deploy it. The following instructions show you how to provision an Amazon S3 bucket, prepare the application revision's files for the bucket, bundle the revision's files, and then push the revision to the bucket.
**Note**
Although it's not covered in this tutorial, you can use CodeDeploy to deploy applications from GitHub repositories to instances. For more information, see [Integrating CodeDeploy with GitHub](integrations-partners-github.md).
**Topics**
+ [Provision an Amazon S3 bucket](#tutorials-wordpress-upload-application-create-s3-bucket)
+ [Prepare the application's files for the bucket](#tutorials-wordpress-upload-application-prepare-application-files)
+ [Bundle the application's files into a single archive file and push the archive file](#tutorials-wordpress-upload-application-bundle-and-push-archive)
## Provision an Amazon S3 bucket
Create a storage container or *bucket* in Amazon S3—or use an existing bucket. Make sure you can upload the revision to the bucket and that Amazon EC2 instances used in deployments can download the revision from the bucket.
You can use the AWS CLI, the Amazon S3 console, or the Amazon S3 APIs to create an Amazon S3 bucket. After you create the bucket, make sure to give access permissions to the bucket and your AWS account.
**Note**
Bucket names must be unique across Amazon S3 for all AWS accounts. If you aren't able to use **amzn-s3-demo-bucket**, try a different bucket name, such as **amzn-s3-demo-bucket** followed by a dash and your initials or some other unique identifier. Then be sure to substitute your bucket name for **amzn-s3-demo-bucket** wherever you see it throughout this tutorial.
The Amazon S3 bucket must be created in the same AWS region where your target Amazon EC2 instances are launched. For example, if you create the bucket in the US East (N. Virginia) Region, then your target Amazon EC2 instances must be launched in the US East (N. Virginia) Region.
**Topics**
+ [To create an Amazon S3 bucket (CLI)](#tutorials-wordpress-upload-application-create-s3-bucket-cli)
+ [To create an Amazon S3 bucket (console)](#tutorials-wordpress-upload-application-create-s3-bucket-console)
+ [Give permissions to the Amazon S3 bucket and AWS account](#tutorials-wordpress-upload-application-create-s3-bucket-grant-permissions)
### To create an Amazon S3 bucket (CLI)
Call the **mb** command to create an Amazon S3 bucket named **amzn-s3-demo-bucket**:
```
aws s3 mb s3://amzn-s3-demo-bucket --region region
```
### To create an Amazon S3 bucket (console)
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the Amazon S3 console, choose **Create bucket**.
1. In the **Bucket name** box, type a name for the bucket.
1. In the **Region** list, choose the target region, and then choose **Create**.
### Give permissions to the Amazon S3 bucket and AWS account
You must have permissions to upload to the Amazon S3 bucket. You can specify these permissions through an Amazon S3 bucket policy. For example, in the following Amazon S3 bucket policy, using the wildcard character (\$1) allows AWS account `111122223333` to upload files to any directory in the Amazon S3 bucket named `amzn-s3-demo-bucket`:
```
{
"Statement": [
{
"Action": [
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Principal": {
"AWS": [
"111122223333"
]
}
}
]
}
```
To view your AWS account ID, see [Finding Your AWS account ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/console_account-alias.html#FindingYourAWSId).
Now is a good time to verify the Amazon S3 bucket will allow download requests from each participating Amazon EC2 instance. You can specify this through an Amazon S3 bucket policy. For example, in the following Amazon S3 bucket policy, using the wildcard character (\$1) allows any Amazon EC2 instance with an attached IAM instance profile containing the ARN `arn:aws:iam::444455556666:role/CodeDeployDemo` to download files from any directory in the Amazon S3 bucket named `amzn-s3-demo-bucket`:
```
{
"Statement": [
{
"Action": [
"s3:Get*",
"s3:List*"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
"Principal": {
"AWS": [
"arn:aws:iam::444455556666:role/CodeDeployDemo"
]
}
}
]
}
```
For information about how to generate and attach an Amazon S3 bucket policy, see [Bucket policy examples](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies.html).
For information about how to create and attach an IAM policy, see [Working with policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/ManagingPolicies.html#AddingPermissions_Console).
## Prepare the application's files for the bucket
Make sure the WordPress application files, the AppSpec file, and the scripts are organized on your development machine similar to the following:
```
/tmp/
|--WordPress/
|-- appspec.yml
|-- scripts/
| |-- change_permissions.sh
| |-- create_test_db.sh
| |-- install_dependencies.sh
| |-- start_server.sh
| |-- stop_server.sh
|-- wp-admin/
| |-- (various files...)
|-- wp-content/
| |-- (various files...)
|-- wp-includes/
| |-- (various files...)
|-- index.php
|-- license.txt
|-- readme.html
|-- (various files ending with .php...)
```
## Bundle the application's files into a single archive file and push the archive file
Bundle the WordPress application files and the AppSpec file into an archive file (known as an application *revision*).
**Note**
You may be charged for storing objects in a bucket and for transferring application revisions into and out of a bucket. For more information, see [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/).
1. On the development machine, switch to the folder where the files are stored:
```
cd /tmp/WordPress
```
**Note**
If you don't switch to this folder, then the file bundling will start at your current folder. For example, if your current folder is `/tmp` instead of `/tmp/WordPress`, then the bundling will start with files and subfolders in the `tmp` folder, which may include more than the `WordPress` subfolder.
1. Call the **create-application** command to register a new application named **WordPress\$1App**:
```
aws deploy create-application --application-name WordPress_App
```
1. Call the CodeDeploy [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html) command to bundle the files together, upload the revisions to Amazon S3, and register information with CodeDeploy about the uploaded revision, all in one action.
```
aws deploy push \
--application-name WordPress_App \
--s3-location s3://amzn-s3-demo-bucket/WordPressApp.zip \
--ignore-hidden-files
```
This command bundles the files from the current directory (excluding any hidden files) into a single archive file named **WordPressApp.zip**, uploads the revision to the **amzn-s3-demo-bucket** bucket, and registers information with CodeDeploy about the uploaded revision.
# Step 4: Deploy your WordPress application
Now you deploy the sample WordPress application revision you uploaded to Amazon S3. You can use the AWS CLI or the CodeDeploy console to deploy the revision and monitor the deployment's progress. After the application revision is successfully deployed, you check the results.
**Topics**
+ [Deploy your application revision with CodeDeploy](#tutorials-wordpress-deploy-application-create-deployment)
+ [Monitor and troubleshoot your deployment](#tutorials-wordpress-deploy-application-monitor)
+ [Verify your deployment](#tutorials-wordpress-deploy-application-verify-deployment)
## Deploy your application revision with CodeDeploy
Use the AWS CLI or the console to deploy your application revision.
**Topics**
+ [To deploy your application revision (CLI)](#tutorials-wordpress-deploy-application-create-deployment-cli)
+ [To deploy your application revision (console)](#tutorials-wordpress-deploy-application-create-deployment-console)
### To deploy your application revision (CLI)
1. The deployment needs a deployment group. However, before you create the deployment group, you need a service role ARN. A service role is an IAM role that gives a service permission to act on your behalf. In this case, the service role gives CodeDeploy permission to access your Amazon EC2 instances to expand (read) their Amazon EC2 instance tags.
You should have already followed the instructions in [Create a service role (CLI)](getting-started-create-service-role.md#getting-started-create-service-role-cli) to create a service role. To get the ARN of the service role, see [Get the service role ARN (CLI)](getting-started-create-service-role.md#getting-started-get-service-role-cli).
1. Now that you have the service role ARN, call the **create-deployment-group** command to create a deployment group named **WordPress\$1DepGroup**, associated with the application named **WordPress\$1App**, using the Amazon EC2 tag named **CodeDeployDemo** and deployment configuration named **CodeDeployDefault.OneAtATime**:
```
aws deploy create-deployment-group \
--application-name WordPress_App \
--deployment-group-name WordPress_DepGroup \
--deployment-config-name CodeDeployDefault.OneAtATime \
--ec2-tag-filters Key=Name,Value=CodeDeployDemo,Type=KEY_AND_VALUE \
--service-role-arn serviceRoleARN
```
**Note**
The [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html) command provides support for creating triggers that result in the sending of Amazon SNS notifications to topic subscribers about specified events in deployments and instances. The command also supports options for automatically rolling back deployments and setting up alarms to stop deployments when monitoring thresholds in Amazon CloudWatch alarms are met. Commands for these actions are not included in this tutorial.
1. Before you create a deployment, the instances in your deployment group must have the CodeDeploy agent installed. You can install the agent from the command line with AWS Systems Manager with the following command:
```
aws ssm create-association \
--name AWS-ConfigureAWSPackage \
--targets Key=tag:Name,Values=CodeDeployDemo \
--parameters action=Install,name=AWSCodeDeployAgent \
--schedule-expression "cron(0 2 ? * SUN *)"
```
This command creates an association in Systems Manager State Manager that will install the CodeDeploy agent and then attempt to update it at 2:00 every Sunday morning. For more information about the CodeDeploy agent, see [ Working with the CodeDeploy agent](https://docs.aws.amazon.com/codedeploy/latest/userguide/codedeploy-agent.html). For more information about Systems Manager, see [What is AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html).
1. Now call the **create-deployment** command to create a deployment associated with the application named **WordPress\$1App**, the deployment configuration named **CodeDeployDefault.OneAtATime**, and the deployment group named **WordPress\$1DepGroup**, using the application revision named **WordPressApp.zip** in the bucket named **amzn-s3-demo-bucket**:
```
aws deploy create-deployment \
--application-name WordPress_App \
--deployment-config-name CodeDeployDefault.OneAtATime \
--deployment-group-name WordPress_DepGroup \
--s3-location bucket=amzn-s3-demo-bucket,bundleType=zip,key=WordPressApp.zip
```
### To deploy your application revision (console)
1. Before you use the CodeDeploy console to deploy your application revision, you need a service role ARN. A service role is an IAM role that gives a service permission to act on your behalf. In this case, the service role gives CodeDeploy permission to access your Amazon EC2 instances to expand (read) their Amazon EC2 instance tags.
You should have already followed the instructions in [Create a service role (console)](getting-started-create-service-role.md#getting-started-create-service-role-console) to create a service role. To get the ARN of the service role, see [Get the service role ARN (console)](getting-started-create-service-role.md#getting-started-get-service-role-console).
1. Now that you have the ARN, use the CodeDeploy console to deploy your application revision:
Sign in to the AWS Management Console and open the CodeDeploy console at [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy).
**Note**
Sign in with the same user that you set up in [Getting started with CodeDeploy](getting-started-codedeploy.md).
1. In the navigation pane, expand **Deploy**, then choose **Applications**.
1. In the list of applications, choose **WordPress\$1App**.
1. On the **Deployment groups** tab, choose **Create deployment group**.
1. In **Deployment group name**, enter **WordPress\$1DepGroup**.
1. Under **Deployment type**, choose **In-place deployment**.
1. In **Environment configuration**, select **Amazon EC2 instances**.
1. In **Agent configuration with AWS Systems Manager**, keep the defaults.
1. In **Key**, enter **Name**.
1. In **Value**, enter **CodeDeployDemo**.
**Note**
After you type **CodeDeployDemo**, a **1** should appear under **Matching instances** to confirm CodeDeploy found one matching Amazon EC2 instance.
1. In **Deployment configuration**, choose **CodeDeployDefault.OneAtATime**.
1. In **Service role ARN**, choose the service role ARN, and then choose **Create deployment group**.
1. Choose **Create deployment**.
1. In **Deployment group** choose **WordPress\$1DepGroup**.
1. Next to **Repository type**, choose **My application is stored in Amazon S3**. In **Revision location**, enter the location of the sample WordPress application revision you previously uploaded to Amazon S3. To get the location:
1. Open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the list of buckets, choose **amzn-s3-demo-bucket** (or the name of the bucket where you uploaded your application revision).
1. In the list of objects, choose **WordPressApp.zip**.
1. On the **Overview** tab, copy the value of the **Link** field to your clipboard.
It might look something like this:
**https://s3.amazonaws.com/amzn-s3-demo-bucket/WordPressApp.zip**
1. Return to the CodeDeploy console, and in **Revision location**, paste the **Link** field value.
1. If a message appears in the **File type** list stating the file type could not be detected, choose **.zip**.
1. (Optional) Type a comment in the **Deployment description** box.
1. Expand **Deployment group overrides**, and from **Deployment configuration**, choose **CodeDeployDefault.OneAtATime**.
1. Choose **Start deployment**. Information about your newly created deployment appears on the **Deployments** page.
## Monitor and troubleshoot your deployment
Use the AWS CLI or the console to monitor and troubleshoot your deployment.
**Topics**
+ [To monitor and troubleshoot your deployment (CLI)](#tutorials-wordpress-deploy-application-monitor-cli)
+ [To monitor and troubleshoot your deployment (console)](#tutorials-wordpress-deploy-application-monitor-console)
### To monitor and troubleshoot your deployment (CLI)
1. Get the deployment's ID by calling the **list-deployments** command against the application named **WordPress\$1App** and the deployment group named **WordPress\$1DepGroup**:
```
aws deploy list-deployments --application-name WordPress_App --deployment-group-name WordPress_DepGroup --query 'deployments' --output text
```
1. Call the **get-deployment** command with the deployment ID:
```
aws deploy get-deployment --deployment-id deploymentID --query 'deploymentInfo.status' --output text
```
1. The command returns the deployment's overall status. If successful, the value is `Succeeded`.
If the overall status is `Failed`, you can call commands such as [list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) and [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html) to troubleshoot. For more troubleshooting options, see [Analyzing log files to investigate deployment failures on instances](troubleshooting-ec2-instances.md#troubleshooting-deploy-failures).
### To monitor and troubleshoot your deployment (console)
On the **Deployments** page in the CodeDeploy console, you can monitor your deployment's status in the **Status** column.
To get more information about your deployment, especially if the **Status** column value has any value other than **Succeeded**:
1. In the **Deployments** table, choose the name of the deployment. After a deployment fails, a message that describes the reason for the failure is displayed.
1. In **Instance activity**, more information about the deployment is displayed. After a deployment fails, you might be able to determine on which Amazon EC2 instances and at which step the deployment failed.
1. If you want to do more troubleshooting, you can use a technique like the one described in [View instance details with CodeDeploy](instances-view-details.md). You can also analyze the deployment log files on an Amazon EC2 instance. For more information, see [Analyzing log files to investigate deployment failures on instances](troubleshooting-ec2-instances.md#troubleshooting-deploy-failures).
## Verify your deployment
After your deployment is successful, verify your WordPress installation is working. Use the public DNS address of the Amazon EC2 instance, followed by `/WordPress`, to view your site in a web browser. (To get the public DNS value, in the Amazon EC2 console, choose the Amazon EC2 instance, and on the **Description** tab, look for the value of **Public DNS**.)
For example, if the public DNS address of your Amazon EC2 instance is **ec2-01-234-567-890.compute-1.amazonaws.com**, you would use the following URL:
```
http://ec2-01-234-567-890.compute-1.amazonaws.com/WordPress
```
When you view the site in your browser, you should see a WordPress welcome page that looks similar to the following:
![\[WordPress welcome page\]](http://docs.aws.amazon.com/codedeploy/latest/userguide/images/WordPress-Welcome-Page-013118.png)
If your Amazon EC2 instance does not have an HTTP inbound rule added to its security group, then the WordPress welcome page does not appear. If you see a message that says the remote server is not responding, make sure the security group for your Amazon EC2 instance has the inbound rule. For more information, see [Add an inbound rule that allows HTTP traffic to your Amazon Linux or RHEL Amazon EC2 instanceAdd an inbound rule that allows HTTP traffic to your Windows Server Amazon EC2 instance](tutorials-wordpress-launch-instance.md#tutorials-wordpress-launch-instance-add-inbound-rule).
# Step 5: Update and redeploy your WordPress application
Now that you've successfully deployed your application revision, update the WordPress code on the development machine, and then use CodeDeploy to redeploy the site. Afterward, you should see the code changes on the Amazon EC2 instance.
**Topics**
+ [Set up the WordPress site](#tutorials-wordpress-update-and-redeploy-application-configure-and-install)
+ [Modify the site](#tutorials-wordpress-update-and-redeploy-application-modify-code)
+ [Redeploy the site](#tutorials-wordpress-update-and-redeploy-application-deploy-updates)
## Set up the WordPress site
To see the effects of the code change, finish setting up the WordPress site so that you have a fully functional installation.
1. Type your site's URL into your web browser. The URL is the public DNS address of the Amazon EC2 instance plus a `/WordPress` extension. For this example WordPress site (and example Amazon EC2 instance public DNS address), the URL is **http://ec2-01-234-567-890.compute-1.amazonaws.com/WordPress**.
1. If you haven't set up the site yet, the WordPress default welcome page appears. Choose **Let's go\$1**.
1. To use the default MySQL database, on the database configuration page, type the following values:
+ **Database Name**: **test**
+ **User Name**: **root**
+ **Password**: Leave blank.
+ **Database Host**: **localhost**
+ **Table Prefix**: **wp\$1**
Choose **Submit** to set up the database.
1. Continue the site setup. On the **Welcome** page, fill in any values you want, and choose **Install WordPress**. When the installation is complete, you can sign in to your dashboard.
**Important**
During the deployment of the WordPress application, the **change\$1permissions.sh** script updated permissions of the `/tmp/WordPress` folder so anyone can write to it. Now is a good time to run the following command to restrict permissions so that only you, the owner, can write to it:
```
chmod -R 755 /var/www/html/WordPress
```
## Modify the site
To modify the WordPress site, go to the application's folder on your development machine:
```
cd /tmp/WordPress
```
To modify some of the site's colors, in the `wp-content/themes/twentyfifteen/style.css` file, use a text editor or **sed** to change `#fff` to `#768331`.
On Linux or other systems with GNU **sed**, use:
```
sed -i 's/#fff/#768331/g' wp-content/themes/twentyfifteen/style.css
```
On macOS, Unix, or other systems with BSD **sed**, use:
```
sed -i '' 's/#fff/#768331/g' wp-content/themes/twentyfifteen/style.css
```
## Redeploy the site
Now that you've modified the site's code, use Amazon S3 and CodeDeploy to redeploy the site.
Bundle and upload the changes to Amazon S3, as described in [Bundle the application's files into a single archive file and push the archive file](tutorials-wordpress-upload-application.md#tutorials-wordpress-upload-application-bundle-and-push-archive). (As you follow those instructions, remember that you do not need to create an application.) Give the new revision the same key as before (**WordPressApp.zip**). Upload it to the same Amazon S3 bucket you created earlier (for example, **amzn-s3-demo-bucket**).
Use the AWS CLI, the CodeDeploy console, or the CodeDeploy APIs to redeploy the site.
**Topics**
+ [To redeploy the site (CLI)](#tutorials-wordpress-update-and-redeploy-application-deploy-updates-cli)
+ [To redeploy the site (console)](#tutorials-wordpress-update-and-redeploy-application-deploy-updates-console)
### To redeploy the site (CLI)
Call the **create-deployment** command to create a deployment based on the newly uploaded revision. Use the application named **WordPress\$1App**, the deployment configuration named **CodeDeployDefault.OneAtATime**, the deployment group named **WordPress\$1DepGroup**, and the revision named **WordPressApp.zip** in the bucket named **amzn-s3-demo-bucket**:
```
aws deploy create-deployment \
--application-name WordPress_App \
--deployment-config-name CodeDeployDefault.OneAtATime \
--deployment-group-name WordPress_DepGroup \
--s3-location bucket=amzn-s3-demo-bucket,bundleType=zip,key=WordPressApp.zip
```
You can check the status of the deployment, as described in [Monitor and troubleshoot your deployment](tutorials-wordpress-deploy-application.md#tutorials-wordpress-deploy-application-monitor).
After CodeDeploy has redeployed the site, revisit the site in your web browser to verify the colors have been changed. (You might need to refresh your browser.) If the colors have been changed, congratulations\$1 You have successfully modified and redeployed your site\$1
### To redeploy the site (console)
1. Sign in to the AWS Management Console and open the CodeDeploy console at [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy).
**Note**
Sign in with the same user that you set up in [Getting started with CodeDeploy](getting-started-codedeploy.md).
1. In the navigation pane, expand **Deploy**, then choose **Applications**.
1. In the list of applications, choose **WordPress\$1App**.
1. On the **Deployment groups** tab, choose **WordPress\$1DepGroup**.
1. Choose **Create deployment**.
1. On the **Create deployment** page:
1. In **Deployment group**, choose **WordPress\$1DepGroup**.
1. In the **Repository type** area, choose **My application is stored in Amazon S3**, and then copy your revision's Amazon S3 link into the **Revision location** box. To find the link value:
1. In a separate browser tab:
Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
Browse to and open **amzn-s3-demo-bucket**, and then choose your revision, **WordPressApp.zip**.
1. If the **Properties** pane is not visible in the Amazon S3 console, choose the **Properties** button.
1. In the **Properties** pane, copy the value of the **Link** field into the **Revision location** box in the CodeDeploy console.
1. If a message appears saying the file type could not be detected, choose **.zip**.
1. Leave the **Deployment description** box blank.
1. Expand **Deployment group overrides** and from **Deployment configuration**, choose **CodeDeployDefault.OneAtATime**.
1. Choose **Start deployment**. Information about your newly created deployment appears on the **Deployments** page.
1. You can check the status of the deployment, as described in [Monitor and troubleshoot your deployment](tutorials-wordpress-deploy-application.md#tutorials-wordpress-deploy-application-monitor).
After CodeDeploy has redeployed the site, revisit the site in your web browser to verify the colors have been changed. (You might need to refresh your browser.) If the colors have been changed, congratulations\$1 You have successfully modified and redeployed your site\$1
# Step 6: Clean up your WordPress application and related resources
You've now successfully made an update to the WordPress code and redeployed the site. To avoid ongoing charges for resources you created for this tutorial, you should delete:
+ Any CloudFormation stacks (or terminate any Amazon EC2 instances, if you created them outside of CloudFormation).
+ Any Amazon S3 buckets.
+ The `WordPress_App` application in CodeDeploy.
+ The AWS Systems Manager State Manager association for the CodeDeploy agent.
You can use the AWS CLI, the CloudFormation, Amazon S3, Amazon EC2, and CodeDeploy consoles, or the AWS APIs to perform the cleanup.
**Topics**
+ [To clean up resources (CLI)](#tutorials-wordpress-clean-up-cli)
+ [To clean up resources (console)](#tutorials-wordpress-clean-up-console)
+ [What's next?](#tutorials-wordpress-clean-up-whats-next)
## To clean up resources (CLI)
1. If you used our CloudFormation template for this tutorial, call the **delete-stack** command against the stack named **CodeDeployDemoStack**. This will terminate all accompanying Amazon EC2 instances and delete all accompanying IAM roles the stack created:
```
aws cloudformation delete-stack --stack-name CodeDeployDemoStack
```
1. To delete the Amazon S3 bucket, call the **rm** command with the **--recursive** switch against the bucket named **amzn-s3-demo-bucket**. This will delete the bucket and all objects in the bucket:
```
aws s3 rm s3://amzn-s3-demo-bucket --recursive --region region
```
1. To delete the `WordPress_App` application, call the **delete-application** command. This will also delete all associated deployment group records and deployment records for the application:
```
aws deploy delete-application --application-name WordPress_App
```
1. To delete the Systems Manager State Manager association, call the **delete-association** command.
```
aws ssm delete-association --assocation-id association-id
```
You can get the *association-id* by calling the **describe-association** command.
```
aws ssm describe-association --name AWS-ConfigureAWSPackage --targets Key=tag:Name,Values=CodeDeployDemo
```
If you did not use the CloudFormation stack for this tutorial, call the **terminate-instances** command to terminate any Amazon EC2 instances you manually created. Supply the ID of the Amazon EC2 instance to terminate:
```
aws ec2 terminate-instances --instance-ids instanceId
```
## To clean up resources (console)
If you used our CloudFormation template for this tutorial, delete the associated CloudFormation stack.
1. Sign in to the AWS Management Console and open the CloudFormation console at [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/).
1. In the **Filter** box, type the CloudFormation stack name you created earlier (for example, **CodeDeployDemoStack**).
1. Select the box beside stack name. In the **Actions** menu, choose **Delete Stack**.
CloudFormation deletes the stack, terminates all accompanying Amazon EC2 instances, and deletes all accompanying IAM roles.
To terminate Amazon EC2 instances you created outside of an CloudFormation stack:
1. Sign in to the AWS Management Console and open the Amazon EC2 console at [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. In the **INSTANCES** list, choose **Instances**.
1. In the search box, type the name of the Amazon EC2 instance you want to terminate (for example, **CodeDeployDemo**), and then press Enter.
1. Choose the Amazon EC2 instance name.
1. In the **Actions** menu, point to **Instance State**, and then choose **Terminate**. When prompted, choose **Yes, Terminate**.
Repeat these steps for each instance.
To delete the Amazon S3 bucket:
1. Sign in to the AWS Management Console and open the Amazon S3 console at [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/).
1. In the list of buckets, browse to and choose the name of the Amazon S3 bucket you created earlier (for example, **amzn-s3-demo-bucket**).
1. Before you can delete a bucket, you must first delete its contents. Select all of the files in the bucket, such as **WordPressApp.zip**. In the **Actions** menu, choose **Delete**. When prompted to confirm the deletion, choose **OK**.
1. After the bucket is empty, you can delete the bucket. In the list of buckets, choose the row of the bucket (but not the bucket name). Choose **Delete bucket**, and when prompted to confirm, choose **OK**.
To delete the `WordPress_App` application from CodeDeploy:
1. Sign in to the AWS Management Console and open the CodeDeploy console at [https://console.aws.amazon.com/codedeploy](https://console.aws.amazon.com/codedeploy).
**Note**
Sign in with the same user that you set up in [Getting started with CodeDeploy](getting-started-codedeploy.md).
1. In the navigation pane, expand **Deploy**, then choose **Applications**.
1. In the list of applications, choose **WordPress\$1App**.
1. On the **Application details** page, choose **Delete application**.
1. When prompted, enter the name of the application to confirm you want to delete it, and then choose **Delete**.
To delete the Systems Manager State Manager association:
1. Open the AWS Systems Manager console at https://console.aws.amazon.com/systems-manager.
1. In the navigation pane, choose **State Manager**.
1. Choose the association you created and choose **Delete**.
## What's next?
If you've arrived here, congratulations\$1 You have successfully completed a CodeDeploy deployment, and then updated your site's code and redeployed it.