3. 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?
4. 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>
5. 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.
6. 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!
7. 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.
8. 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.
11. 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
12. 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.
☹
14. 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?
15. 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"
18. running appsbeefy servers
A large
Waitaminute...
What's a PaaS?
The Great
Internet
Load balancer Load balancer
number of
You
Tools:
CLI, API...
19. 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
20. 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
21. 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.
22. 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
23.
24.
25. 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
26.
27. 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
28. How to deploy PHP to
PaaS
Note: my example will use dotCloud.
But the principle is the same on any PAAS.
29. 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)
30. 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)
31. 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
32. 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.
33. 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
34. 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.
35. 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
36. 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?
37. 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
38. To the Cloud, and beyond!
6: Multiplicate the Loaves
$
dotcloud
create
ipsumdev
$
dotcloud
push
[...]
$
dotcloud
create
symfonymongotest
$
dotcloud
push
[...]
39. 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
40. 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!
41.
42. 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
43. 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!
44. 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)
