moving php to the cloud
TRANSCRIPT
2
About me
29 year old
E-Commerce Architect
Joined Sixt in October 2015
> 10years of PHP experience as:
1) Administrator2) Developer3) DevOps4) Architect
3
Agenda
How it looks like todayA.
B. Motivations for Migration
C. Technologies used
D. Target Architecture
E. Let's see some Code!
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
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
Puppet
● Already in use at Sixt
● Well known in the industry
● Developer friendly
● Great tooling available
● Easy to use
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
Varnish & nginx
● Outperform everything
● Easy to integrate & automate
● Very DEV friendly DSL for varnish
● Somehow standard
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
16
The Build pipeline
github
jenkins
S3 BucketCode changes
Webhook
Build artifact (.
tar.gz)
Infrastructure
Fetch prepared artifact from upstream
17
Automation flow
100%Automation
Terraform
Cloudinit
Puppet
SoftwareInstallconfig
ServiceInstallconfig
5
1
23
4
1
2
3
4
5
TerraformSetup of the cloud data center
CloudinitBoothooks & custom startup script
PuppetConfiguration management
Service installation and configurationSetup of the required services to run the application
Software installation and configurationInstalls and configures the software components
18
The Architecture
AZ 1 AZ 2
NAT GW NAT GWELB
Varnish Varnish
ELB
Typo3
Service
Typo3
Service
ELB
BastionPublic
Private
MySQLRDS
AWS Region Frankfurt
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
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 instances2. Update software in existing infrastructure
Use puppet masterless for unlimited scale!3.
There is no „Single Point“ for failures
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)