Midwest php 2013 deploying php on paas- why & how

Deploying PHP on PAAS: Why & How? Midwest PHP — March 2013, Minnesota

Outline •  PHP deployment "back then" o  a (biased) history •  PHP deployment today o  unresolved issues •  How PaaS can help o  any PaaS—not just dotCloud! ☺ •  How to help yourself with PaaS o  and make your lives (as developers) easier •  What's next?

Who am I? Who was I? •  Sysadmin in a (French) PHP shop during the "dotcom bubble" (1999-2001) •  What did it mean to "create a site?" o  Apache <VirtualHost> section o  FTP account o  MySQL database o  sendmail aliases (hellyeah!) o  DNS zone •  What did it mean to "go to production?" o  Easy! Update the <VirtualHost>

The awful truth •  Repetitive tasks are error-prone o  Script everything! •  Custom setups are error-prone o  Knowing where to differentiate is black magic •  Moving development→production is easy o  Having development+production is hard A production environment is a customized, repeat version of the development environment. I don't see how anything could possibly go wrong.

PaaS 2000: Account creation •  Summer 1999: Apache mod_vhost_alias (Apache 1.3.7/1.3.9) o  Create a directory, boom, you're done! •  April 1999: proftpd mod_mysql ("experimental and utterly undocumented") o  INSERT a user, boom, you're done! •  Postfix virtual domains o  With all due respect, sendmail was creepy •  BIND generic zones (PowerDNS later) Bliss level: 9000!

PaaS 2000: Go to production •  Move directories, rename users o  Error prone! •  Create a new, clean account; copy DB o  Different from the dev environment! Whatever you do: if you push the wrong code to the wrong place, something hits the fan.

PaaS 2000: Musings with SQLite •  In May 2000, two great things happen: PHP4 and SQLite. •  Deployment of simple PHP apps is easy: Just upload the code. No DB creation. •  Migration of said PHP apps is easy: Just copy the code (and the .db file). •  As long as you have this non-standard PHP. •  And you don't mind blewing up the DB.

PaaS 2000: It's Web Scale! •  No load balancer yet, DNS round robin o  Then HAProxy arrived, and Nginx, and F5... •  Files (PHP and static assets) over NFS o  Today, we could talk about GlusterFS, S3... •  User accounts shared with NIS o  LDAP is the new cool (... kind of) •  MySQL: no replication yet o  But if you like, we can talk about 3-way multi-master

PaaS 2000: The Downfall "We need this Java thing" • mod_jk, mod_jserv, mod_ajp, ... "And media streaming, too" • realserver, ... Those things were changing quickly. We needed test environments. Virtualization wasn't there yet. ☹

Let's talk about you! Please raise your hand if you... •  Write PHP code? •  Use (mainly) FTP to deploy? •  Use SCP/rsync/similar to deploy? •  Use capistrano/fabric/similar to deploy? •  Deploy to a PaaS? •  Deploy to something else? •  Always use a staging environment? •  Have a clean staging→production workflow?

What I do today •  Server-whisperer for dotCloud o  ...Among other things •  Tackling the PaaS challenge again o  development→production workflow o  deployment should be as easy as "upload, done!" o  ... even when $language != "php" •  Trying to steal NetBSD's motto o  "Of course it runs on dotCloud"

Waitaminute... What's a PaaS? You The Great Internet Load balancer Load balancer Tools: CLI, API... A large number of beefy servers running apps

PaaS: What's the point? (1/5) Deploying new environments ... •  It's fast! o  In minutes, you have your whole stack, complete with DB, memcached, bells & whistles o  Cool to test some now code o  Or to deploy older code to find regressions •  It's cheap! o  On most PaaS, development = free

PaaS: What's the point? (2/5) Leverage git, hg, ... •  If you don't know git, I beg you to attend Mike Stowe's talk in Room 62 at 10:30am! •  Keep all versions of your code, ever; go back to any of them •  Redeploy the exact version which was online last week before that horrible bug happened •  Compare conversion rates on two variants of your site

PaaS: What's the point? (3/5) Someone else takes care of ... •  Optimizing your stack (≠code) o  Crafting that crazy Nginx/PHP-FPM setup o  Lower memory footprint o  Better performance (APC...) •  Upgrading your stack o  Watch security disclosure mailing lists o  Roll out performance and security updates o  Give you new versions of PHP, MySQL, etc.

PaaS: What's the point? (4/5) Comprehensive HTTP routing •  Attach/detach domains (virtualhosts) o  Easy transitions to new versions (And you keep the old version around) •  Get nice metrics o  Request rate, error rate, latency o  (See screenshots!) •  WebSocket support o  And other languages as well

PaaS: What's the point? (5/5) Be Web Scale! •  Scale horizontally and vertically o  horizontally = more servers o  vertically = bigger servers •  Reliability o  horizontal scaling for web tier o  replication for database tier → Deploy to the Cloud

PaaS: What's the point? (5/5) Be Web Scale! •  Scale horizontally and vertically o  horizontally = more servers o  vertically = bigger servers •  Reliability o  horizontal scaling for web tier o  replication for database tier → Deploy to the Cloud without the hassle

How to deploy PHP to PaaS Note: my example will use dotCloud. But the principle is the same on any PAAS.

Deployment example: Symfony2 "KnpIpsum" Original code:https://github.com/KnpLabs/KnpIpsum dotCloudized version:https://github.com/jpetazzo/ KnpIpsum/tree/dotcloud (Make sure you use the "dotcloud" branch)

To the Cloud, and beyond! 0: setup environment •  Create (free) account on www.dotcloud.com •  Install Python (!) •  pip install dotcloud •  dotcloud setup(Asks for login+password) (Note: web-based push is →← that close)

To the Cloud, and beyond! 1: dotcloud.yml •  The app is described by a small YAML file www: type: php approot: web mongodb: type: mongodb mysql: type: mysql

To the Cloud, and beyond! 2: dotCloud+Symfony2 •  dotCloud has Symfony2 docs •  The docs tell us we need a nginx.conf file •  That's because most people deploy Symfony2 on Apache + mod_php •  Symfony2 apps typically ship .htaccess file •  We need the equivalent of that file → Drop nginx.conf file in the web directory.

To the Cloud, and beyond! 3: application specifics •  README says to run a few manual steps:bin/vendors install php app/console doctrine:database:create php app/console doctrine:schema:create •  We will put those steps in a postinstall script (that's just a shell script called "postinstall"), and the postinstall script will be executed automatically when we deploy

To the Cloud, and beyond! 4: deploy application $ dotcloud create symfonipsum [...] $ dotcloud push ==> Pushing code with rsync from "./" to application symfonipsum building file list ... done [...uploading...] [...and a couple of minutes later...] 14:38:10.312838: -‐-‐> Application (symfonipsum) fully installed ==> Application is live at http://symfonipsum-‐skaya.dotcloud.com But of course, it doesn't work: we never configured the database host/port/etc.

To the Cloud, and beyond! 5: configure database •  Find out database information: $ dotcloud info mysql [...] ports: ssh: ssh://mysql@symfonipsum-‐skaya.azva.dotcloud.net:12345 mysql: mysql://root:XXX@symfonipsum-‐skaya.azva.dotcloud.net:23456 •  Edit app/config/config.yml, update host/port/login/password •  Push again

Quick break: "The Twelve Factor App" •  http://www.12factor.net/ •  http://www.12factor.net/config •  "Store config in the environment" o  App config = everything that is likely to vary between deploys (staging, production, developer env., etc.) o  Includes: database/memcached access information, credentials to external services (Twitter, S3...) o  Storing config as constants in the code is wrong! Please don't do it! o  A good test: can you open source the code without compromising any credential?

To the Cloud, and beyond! 5bis: configure database •  dotCloud will put all information in two files: o  ~/environment.json o  ~/environment.yml •  We do the following changes: o  Update postinstall to generate ~/symfony.yml (using the information in environment.json) o  Update app/config/config.yml to import ~/symfony.yml •  Push again

To the Cloud, and beyond! 6: Multiplicate the Loaves $ dotcloud create ipsumdev $ dotcloud push [...] $ dotcloud create symfonymongotest $ dotcloud push [...]

To the Cloud, and beyond! 7: Go live! $ dotcloud create ipsumprod -‐f live $ dotcloud push $ dotcloud scale db:instances=2 $ dotcloud scale www:memory=800M $ dotcloud domain add www www.loremipsum.com

Drawbacks of PaaS •  One-time initial investment (small) o  Get familiar with the CLI, tools... •  Per-app initial investment (variable) o  Inject configuration variables o  Rework your app "for the Cloud" (when needed) o  Meddle Not In The Affairs Of Wizards!

Drawbacks of PaaS •  One-time initial investment (small) o  Get familiar with the CLI, tools... •  Per-app initial investment (variable) o  Inject configuration variables o  Rework your app "for the Cloud" (when needed) o  Meddle Not In The Affairs Of Wizards! •  Higher apparent cost o  PaaS hosting can be 4x-10x more expensive o  Comes with 24x7 ops team, scaling, support o  Current PaaS don't leverage cheap hosts yet

One more (semi-) Drawback of PaaS •  "dotcloud run" (SSH access) doesn't work on the WiFi access in this conference! •  But we're working on that... (WebSocket tunneling of SSH) •  And you can't access your server, neither. (Unless you have a cunning VPN; OpenVPN running on 443/tcp anyone?) •  Meawhile, you can still push to dotCloud! Yaaay!

Future of PaaS •  PaaS on your servers / local machine •  PaaS on a wide range of platforms (from cheap entry-level to high-end SSD) •  Support for more languages & databases •  Support for more frameworks •  More integration with 3rd parties (e.g. github)

Thank you! Questions? @jpetazzo jerome@dotcloud.com www.dotcloud.com Slides deck: http://goo.gl/jZwdC Feedback: http://joind.in/8217

Midwest php 2013 deploying php on paas- why & how

More Related Content

What's hot

Viewers also liked

Similar to Midwest php 2013 deploying php on paas- why & how

More from dotCloud

Midwest php 2013 deploying php on paas- why & how