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
(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
(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
(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
fiisExistApp='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: linuxfiles:
- 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
(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)
