This document discusses moving a PHP application to the cloud. It begins with an introduction to the speaker and their experience. The current architecture is described as using Typo3, Symfony2, MySQL, and a CDN on managed servers. Motivations for migration include limited caching, troubleshooting difficulties, and lack of scaling. Technologies considered for the cloud migration include Terraform, Golang, Gatling, AWS, Puppet, Varnish, nginx and the PHP ecosystem. The target architecture leverages AWS services like EC2, S3, RDS, ELB along with Terraform, Puppet and Cloud Init for infrastructure as code and automation. Code changes trigger automated builds, deployment

1. 1
Moving PHP to the Cloud
München, 23. March 2016

2. 2
About me
29 year old
E-Commerce Architect
Joined Sixt in October 2015
> 10years of PHP experience as:
1) Administrator
2) Developer
3) DevOps
4) Architect

3. 3
Agenda
How it looks like todayA.
B. Motivations for Migration
C. Technologies used
D. Target Architecture
E. Let's see some Code!

4. 4
How it looks today
Typo3
SF2 Rest
MySQL
CDN

5. 5
 The used CDN only provides a limited
set of caching capabilities
 Managed server
●
Troubleshooting was
impossible
●
No tooling available
●
No way to install the required
tools
Flexibility Scalability Architecture
 Only vertical scaling was available at
previous hoster
 Perfect showcase for auto scaling
based on the load
 Eliminate Single point of failures
 „One function per component“
 Automation pipeline was already
available
Motivations for migration

6. 6
Technologies to choose from
TerraformGolang
Gatling

7. 7
Used Technologies
Terraform

8. 8
AWS
A. EC2
D. Launch configuration
C. Auto scaling groups
B. S3
E. Elastic Load Balancer
AWS Glossary
Dynamic compute power
Simple persistent storage service
Scale number of EC2 instances automatically
Tell AWS how to spawn your instances
Route traffic to all scaled instances, don't care how much
F. RDS Managed relational database in AWS

9. 9
Puppet
● Already in use at Sixt
● Well known in the industry
● Developer friendly
● Great tooling available
● Easy to use

10. 10
Cloud Init
● Ready to use
● Incredibly easy to link cloud
automation with service automation
● Control your boot process
● Hook into every
required step

11. 11
Varnish & nginx
● Outperform everything
● Easy to integrate &
automate
● Very DEV friendly DSL
for varnish
● Somehow standard

12. 12
AWS
● Know how inhouse
● Offers the required flexibility
● Great automation support
● Cheap

13. 13
PHP & Ecosystem
● No brainer
● They do what they promise
● Standards in web

14. 14
Terraform
Terraform
● Provider independent technology
(but the implementation is very
closely bound to AWS)
● SDDC → Software defined data center
● AWS is very well supported
● Great tool, but young

15. 15
The automation pipeline

16. 16
The Build pipeline
github
jenkins
S3 BucketCode changes
Webhook
Build artifact (.tar.gz)
Infrastructure
Fetch prepared artifact
from upstream

17. 17
Automation flow
100%
Automation
Terraform
Cloud
init
Puppet
Software
Install
config
Service
Install
config
5
1
2
3
4
1
2
3
4
5
 Terraform
Setup of the cloud data center
 Cloudinit
Boothooks & custom startup script
 Puppet
Configuration management
 Service installation and configuration
Setup of the required services to run the application
 Software installation and configuration
Installs and configures the software components

18. 18
The Architecture
AZ 1 AZ 2
NAT GW NAT GWELB
Varnish Varnish
ELB
Typo3
Service
Typo3
Service
ELB
BastionPublic
Private
MySQL
RDS
AWS Region Frankfurt

19. 19
Rules for Terraform
Never spin instances, only launch configurations linked to auto scaling groups1.
2. Don't destroy persistence layer
Achieve HA / DR
RDS backup & restore is terribly slow
3. Safe your .tfstate file for everyone (e.g. store it on S3 is nativly supported)
If you're working in a team, you want to share the state of terraform!

20. 20
Terraform

21. 21
Rules for Puppet
Puppet runs need to be agnostic1.
2. Software installation & configuration has to be part of puppet and available from the outside
Restarting services is not a good idea if you run frequently
1. Install software (correct version) on fresh instances
2. Update software in existing infrastructure
Use puppet masterless for unlimited scale!3.
There is no „Single Point“ for failures

22. 22
Puppet

23. 23
Cloud Init
terraform/ ← SDDC project
cloudinit/ ← Cloudinit directory
boothooks/ ← Contains scripts that run as a boothook
z-01-packages.sh ← Check internet connectivity & install ruby, aws-sdk and puppet
shellscripts/ ← Contains scripts that run after the boot
z-10-ec2_tags_to_facts.rb ← Allows us to see the tags from terraform to control puppet run
z-19-puppet-apply.sh ← Run puppet with the exported tags from tags_to_facts
userdata/ ← Baked everything above as AWS user-data (available on every machine)
min-puppet-apply.txt.gz ← The „builded“ user-data contains the other dirs
userdata.conf ← Cloudinit configuration
cloud-config-default.txt ← Some defaults like locale, apt-behaviour and puppet tooling (hiera etc)

24. 24
Cloud Init - configuration

25. 25
Cloud Init

26. 26
Cloud Init – z-01-packages.sh

27. 27
Cloud Init – z-19-puppet-apply.sh

28. 28
Questions?