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
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!
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
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
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
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!
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
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)
Let me tell you a story about a small little shiny server
Hanging around behind a CDN
Receiving production traffic
Can you image what happens if the end users receive newsletters?
<Foliennummer>