Moving PHP to the Cloud

1

Moving PHP to the Cloud

München, 23. March 2016

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!

4

How it looks today

Typo3SF2 RestMySQL

CDN

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

Technologies to choose from

TerraformGolang

Gatling

7

Used Technologies

Terraform

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

12

AWS

● Know how inhouse

● Offers the required flexibility

● Great automation support

● Cheap

13

PHP & Ecosystem

● No brainer

● They do what they promise

● Standards in web

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

The automation pipeline

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!

20

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

22

Puppet

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

Cloud Init - configuration

25

Cloud Init

26

Cloud Init – z-01-packages.sh

27

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

28

Questions?