Automated WordPress deployment on AWS

DevOps-Workflow with AWS CodeDeploy, part 1 Automated WordPress deployment on AWS

With AWS code deploy in the Public Cloud division of Amazon’s service in the Portfolio can automate with the help of outsourcing developers to Deploy and Update applications on any of the instances. This Workshop demonstrates an automated WordPress deployment on virtual servers in Amazon Web Services.

Companies

The flow of a typical on-site Deployments with AWS CodeDeploy.The flow of a typical on-site Deployments with AWS CodeDeploy.

(Image: AWS)

Instances must be in code deploy virtual machines in AWS (Amazon EC2), but also local servers and such, running in another Cloud or on a different Hypervisor. AWS code deploy supports a large number of operating systems. Prerequisite is an AWS codedeploy of available and installed Agent is.

AWS provides agents that have been tested on Amazon Linux, Red hat Enterprise Linux, Ubuntu Server, and Microsoft Windows Server. For many other operating systems, the AWS codedeploy Agent on GitHub as Open Source Software available for Download. General codedeploy supports all instances, with the agent and with public endpoints, AWS can connect.

Developers can use AWS code deploy new features, what downtime is minimized in the course of the deployment; this is achieved because the Tool easier, and any error-prone manual operations complex updates to existing applications obsolete. The Service is fully managed by AWS and scales automatically with the infrastructure. So is it possible to Code for thousands of instances just as easy to deploy as a single.

AWS CodeDeploy works easily with many configuration management systems, Continuous Integration and Continuous Deployment Tools, and Source-Code Control systems. So codedeploy can refer to the source code of, for example, Amazon S3 Buckets, Github, or Bitbucket Repos. Information about the AWS side product integrations. Developers can use code deploy mainly to the release of new App versions, therefore, the Tool plays an important role in the Application Lifecycle Management (ALM).

As new Software Releases also with AWS Elastic Beanstalk or AWS OpsWorks, automate, deploy, many readers may question the difference. This is easy to answer: While AWS Elastic Beanstalk and AWS OpsWorks End-to-End application management systems, works with AWS code deploy, according to a modular principle. This helps developers, Software on any number of instances available, including on-premises servers. With CodeDeploy, it is even possible, serverless Lambda functions provide.

CodeDeploy also allows the user to pair the provision and Revision of applications on EC2 instances to a specific virtual network in the context of the Amazon Virtual Private Cloud (VPC). This is as much values as security plus the fact that access authorization via the AWS Identity and Access Management (IAM) to set. Here, AWS codedeploy is completely independent of architecture or programming languages, so that developers are not limited to, selected Runtimes, such as in the case of Elastic Beanstalk.

Workflow with CodeDeploy

CodeDeploy is related Code from a source control system, and installed him, for example, on Amazon EC2.CodeDeploy is related Code from a source control system, and installed him, for example, on Amazon EC2.

(Image: three of a kind / AWS)

You want to orchestrate a Code deployment or upgrade with codedeploy, you need to know as a developer, three concepts of code to deploy and configure, namely “application Revision” (or simply “Revision”), “deployment group” and “deployment configuration”. Under a Revision AWS understands the specific content to be deployed on an instance. The can, depending on the programming language, source code, executable files (in a Devops Pipeline that could Build, for example, the upstream stage to generate the Build artifacts and publish) or simply a website.

For a Revision in the code deploy, the developer needs to incorporate a JSON or YAML wrote AppSpec file. This is the source files of the Revision, determines permissions for developed data or specify scripts to be run in the course of App development on each instance. AWS code deploy ultimately leads only scripts that are specified in the AppSpec file.

As a developer, you have to determine Sets of instances, the one referenced in the Definition of the deployment groups, and which of the respective application are assigned to, conversely, each deployment group includes specific EC2 or local authorities. The assignment of instances to deployment group is the name of a related Autoscaling group and/or the use of Tags, the instances can be unambiguously identified.

In the context of the configuration of the deployment process, developers can also specify the exact steps that ensure that the selected content is always placed on the appropriate instances. In this Workshop, we want to provide an example of a WordPress deployment from a S3 Bucket on EC2 servers, and the WordPress application (PHP), then update, and “re-deploy”.

CodeDeploy-Agent

We begin to verify that on a development EC2 instance with Amazon Linux, the codedeploy Agent is installed. In this example, therefore, is important, because we want to use the virtual developer machine, we prepare the source files at the same time as the Deployment target. In practice, it would get cut but.

To do this, we connect using SSH and Public Key with our Development Server and check the Status of the agent should be installed on Amazon Linux normally. His explicit Installation on local servers or not directly support virtual servers.

sudo service codedeploy-agent status

Furthermore, to ensure and to control that allows the instance associated with Security-group http-Access. This is done, we need to download the WordPress Source Code to our instance.

mkdir /tmp/WordPress_Temp
cd /tmp/WordPress_Temp
wget https://wordpress.org/latest.tar.gz

We will load the WordPress source code and unzip it.We will load the WordPress source code and unzip it.

(Image: three of a kind / AWS)

With the Tag “latest” by leads wget automatically to the latest Version and needs to the tar.gz unzip the archive and then only in a temporary directory:

tar -xzvf ./latest.tar.gz

Then, we create the actual target directory …

mkdir -p /tmp/WordPress

… and copy the unzipped Content there:

cp -paf /tmp/WordPress_Temp/wordpress/* /tmp/WordPress

Then we can delete the temporary directory and load the WordPress directory under the directory “scripts”:

mkdir -p /tmp/WordPress/scripts

Here, we create a small script “install_dependencies.sh”. With “vi” or on Amazon Linux with the comfort of a full text Editor “nano” we put the following Text:

#!/bin/bash
yum install -y httpd php mariadb-server php-mysqlnd

Then we create another script, for example, with the name “start_server.sh” we want to use our Server-start services. In this we write the following content:

#!/bin/bash
service httpd start
service mariadb start

Furthermore, we also need a suitable Stop-script, for example, with the name “stop_server.h“ with the following content.

#!/bin/bashisExistApp='pgrep httpd'if [[ -n $isExistApp ]]; then
service httpd stop
fi
isExistApp='pgrep sql'if [[ -n $isExistApp ]]; then
service mariadb stop
fi

Now we need a script to Create a Test database in MariaDB. We call it “create_test_sb.sh”. It could look something like this:

#!/bin/bashmysql -uroot <<CREATE_TEST_DB
CREATE DATABASE IF NOT EXISTS test;
CREATE_TEST_DB

And finally, we create a script that sets the permissions for the www-Root directory “/var/www/html/WordPress” to fit. We call it “change_permissions.sh” and edit it as follows:

#!/bin/bashchmod -R 777 /var/www/html/WordPress

Now we just have to make all of our newly generated scripts executable:

sudo chmod +x /tmp/WordPress/scripts/*

The CodeDeploy AppSpec File

As described AWS codedeploy uses a YAML Packed AppSpec file that maps all of the source files of our application-audit-appropriate “targets” in the Target EC2 instance. To do this, we create nano-file “/tmp/WordPress/appspec.yml“ with the following content:

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

The AppSpec file controlsThe AppSpec file controls “hooks” the entire deployment process.

(Image: three of a kind / AWS)

The structure and content of the file should be according to the explanation above is largely self-explanatory. Thus, we have prepared on our developer instance of the required source files and scripts. In the next part of this Workshop we will look at how you orchestrated a WordPress deployment on EC2 (in this example, on the same instance) with CodeDeploy, and how easy it is, updates to roll out.

(ID:47046596)

Ready to see us in action:

More To Explore

IWanta.tech
Logo
Enable registration in settings - general
Have any project in mind?

Contact us:

small_c_popup.png