PaaSing Your Code Around


Published on

PaaS (Platform as a Service) is hot topic in the PHP world, with many different providers vying to run your code. I'll look at what it takes to get your code to run on the common PaaS services, and compare and contrast them on their offerings and performance

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

PaaSing Your Code Around

  2. 2. Who Am I?  Chris Tankersley  Been Doing PHP for 9+ Years  Lots of projects no one uses, and a few that some do:  tank 2
  3. 3. What is PaaS? 3
  4. 4. Software as a Service (SaaS) Software Package Platform as a Service Platform as a Service (PaaS) Server Language Deployment Scripts Infrastructure as a Service (IaaS) Server Infrastructure Storage Network 4
  5. 5. Why use a PaaS?  Offload the work to someone else  Possibly (maybe) more cost effective  Small shops don‟t have to hire as many people  Scalability, both up and down 5
  6. 6. PaaS Workflow Git repo Feature Branch Feature Branch Feature Branch Run Paas Deployment Your App Runs! 6
  7. 7. Basic Knowledge  Just about all of them use git  Just about all of them work best with a command line  Your OS doesn‟t matter, they all pretty much support everything  A server-side scripting language  Bash, Ruby, Python 7
  8. 8. Other Considerations  Where will uploaded files live?  Does my app scale across multiple servers?  How well does my application perform?  Can I automate everything? 8
  9. 9. 9
  10. 10. Let‟s set up a site on a PaaS  your-code-around 10
  11. 11. What I built  Silex App that displayed user-supplied „texts‟ from drunk elephants  Silex  Symfony Forms  Ruckusing Migrations  Twig 11
  12. 12. What did I want to find out?  How much code I had to change to get it to work  How much of a pain was it to get the deployment process set up  How long the deployments took  How easy the deployments were  How easy things were to manage 12
  13. 13. What I did  Created the basic app in vagrant  Signed up for a PaaS  Heroku  Engineyard  Redhat OpenShift  Amazon ElasticBeanstalk  Made the app work  Each set of code is in paas/[service]  You can fork the repo, checkout the branch, and set up the config 13
  14. 14. Heroku 14
  15. 15. Heroku  Heroku is a container-based PaaS  Each container (dyno) is a little virtualized environment  “Supports” PHP 5.3.27 and Apache 2.2.25 out of the box  Has a command line interface for working with your apps 15
  16. 16. Heroku – Creating an Application 16
  17. 17. Heroku – Deploying an App  Push your branch to Heroku‟s master branch 17
  18. 18. Heroku – Getting it to Work  Heroku will only detect a PHP app if there is an index.php file in the root  Docroot is automatically set to the root of your repo  PHP is supported via a partnership with Facebook, not that you‟ll find that on their site  Had to add a custom Procfile, bootstrap files, and Buildpack  Composer is slooooooow. Sites took 2-15 minutes to bootstrap  Deploy hooks are done via the Procfile 18
  19. 19. Heroku – General Notes  Extension support is hit or miss. You might need to compile your own  Since buildpacks actually set up an entire environment, really study what buildpack you use  Might want to commit vendor/ to your deploy branch to speed things up  While PHP 5.3.27 is the base install, you can actually install any PHP via a buildpack  Heroku uses ephemeral storage, so make sure all your files are saved to something like S3 19
  20. 20. Engineyard 20
  21. 21. Engineyard  Engineyard is an AWS-based PaaS  You set up Environments, which are groups of EC2 instances  Supports PHP 5.4.17 and MySQL 5.5 out of the box  Has a command line interface for working with your apps  Works with your VCS host to pull down and deploy code 21
  22. 22. Engineyard – Creating an Application  Create a new application  Select the Language  Give it a Repo to pull from  Give it a Name  Tell it the docroot  Add your deploy key to your git server  Set up an Environment  Give it a name  Give it a type (Production, Development, etc)  Select a DB  Set up SSH keys 22
  23. 23. Engineyard – Deploying an App  Give it a branch name and click „Deploy‟ 23
  24. 24. Engineyard – Getting it to Work  Had to add a deploy/ script to get the database migrations to work 24
  25. 25. Engineyard – General Notes  You need to set up SSH keys to get into the boxes  DB credentials are in /data/[app_name]/shared/config/databases.yml  They are also exposed through the $_SERVER array  When you stop an instance without a public IP, the IPs will change  Since it‟s booting an EC2 instance, it‟s slow. Takes 10-15 minutes to provision the environment (Deploys are much quicker)  Natively supports Composer! 25
  26. 26. Redhat OpenShift 26
  27. 27. OpenShift  OpenShift is a „cartridge‟ (container) PaaS  Supports PHP 5.3.17 and MySQL 5.1 when using the Zend Server cartridge  Has a command line interface for working with your apps  The largest offering of platforms out of the test PaaS‟s 27
  28. 28. OpenShift – Creating an Application 28
  29. 29. OpenShift – Deploying an App  Push your branch to OpenShift‟s master branch 29
  30. 30. OpenShift– Getting it to Work  Had to fetch and merge their master branch  Docroot is php/, so our deploy script changes that  php-intl extension had too old of an ICU version, so had to downgrade it through Composer  Could have completely redone PHP, like in Heroku  Composer is not natively supported, so do it via the deploy script  Deploy script is bash, so fairly easy to work with 30
  31. 31. OpenShift – General Notes  You need to set up SSH keys to get into the boxes  Cartridge system is interesting and works well  Does offer persistent storage, in the $OPENSHIFT_DATA_DIR 31
  32. 32. AWS ElasticBeanstalk 32
  33. 33. ElasticBeanStalk  It‟s a Rackspace-based PaaS! 33
  34. 34. ElasticBeanStalk  It‟s a Rackspace-based PaaS!  It‟s an AWS-based PaaS  Supports PHP 5.4 out of the box, and Amazon RDS for DB  Has a nice command line interface 34
  35. 35. ElasticBeanstalk – Creating an Application  Log in AWS and go to ElasticBeanstalk  Create an Application through their „eb‟ tool  Go to your repo  Run „eb init‟ and answer the questions 35
  36. 36. ElasticBeanstalk – Deploying an App  Run „eb branch‟ to assign your branch to an environment  Run „git aws.push‟ to deploy 36
  37. 37. ElasticBeanstalk – Getting it to Work  Had to run „eb init‟ and run through their setup, even though the environment existed  Had to run „eb branch‟ to assign the current branch to an environment so that „git aws.push‟ would work 37
  38. 38. ElasticBeanstalk – General Notes  It‟s AWS, so provisioning the servers can take 10-15 minutes  Supports Composer out of the box, which is nice  Deploy hooks are done via their container_commands 38
  39. 39. So What did I Learn? 39
  40. 40. Deploy Scripts Are Your Friend  While you‟ve got shell access, you still don‟t want to do stuff manually  Knowing Bash scripting was incredibly helpful 40
  41. 41. Understand Your Type of PaaS  Usually either container-based  OpenShift  Heroku  Or Server-based  ElasticBeanstalk  Engineyard  These work internally differently, so understand how each works makes your life easier 41
  42. 42. Your Code Should Just Work  A good PaaS won‟t need you to modify your code  My code modifications were changing DB- backends or making assumptions I shouldn‟t have  Most of the differences in the sample code are deploy scripts and the config file  That‟s ignoring storage issues, which you might need to work on 42
  43. 43. Questions? 43
  44. 44. Thank You!   @dragonmantank  44
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.