I'm working on getting my site up on Google App Engine.... so far it's
been an interesting process and it took me a day to get to the point
where I was ready to actually install Joomla. :-)
I figured I'd post my notes for anyone else interested in it as well
https://gist.github.com/garyamort/7758663
It's an almost "from scratch" process as it includes pre-install steps to:
1) Use PHPStorm's cool Google App Integration features. By creating a
"new" GAE project through their interface, it prompts for all those GAE
settings I needed later to push changes up to the server as well as
running the local GAE dev test environment. I go ahead and push the
hello world project up to GAE as well as make a few changes to get
comfortable with their control interface.
2) Once I have a working PHPStorm GAE project, I use Git and github to
merge the Joomla CMS code into my code.
3) After it's all merged, I discovered I needed to make a few tweaks to
get the Joomla Installer to work under GAE. There is probably a cleaner
way to organize them and when I actually go back and do it a second time
I can make a more detailed step by step.
What I find exciting about using the GAE environment is something which
first seemed to be a big negative. You can't modify files on the server
from within your server code. You have to "deploy" files to the server
to change them. This means installing Joomla Extensions, making
configuration changes that modify configuration.php, and uploading
images for articles have to be done on your local system and then
"deployed" to the server.
There are some work-arounds for this, so it is possible to get around it
- and I've got a few possibilities in mind for setting up restricted
access for site managers to a special "version" of website where they
can make these changes. However, for GENERAL usage, this "con" is
actually a big plus! Every security problem I have ever encountered in
Joomla has involved someone making changes to the files on the file
system. Untraceable changes, no idea how they got them there because
file changes were not being logged by the system. Was it some hidden
php file? Was it a compromised FTP account? I have no clue. By
restricting file changes to the GAE deployment process, this means I get
Google logging for free. Every file change can be tracked down to a
user account and an ip address. I will gladly hop through one extra
hoop to never have to worry about someone uploading images into my
server and using it to host inappropriate material.
With GAE your not deploying your app on a traditional web server, where
all the PHP files get executed if their accessed via the web. Instead
when you "deploy" a set of files to your GAE project Google uses a
configuration file to do some processing. All the "static" files[css,
javascript, images] will be stored on a completely separate server which
is optimized to deliver them. All the other files, get placed on your
GAE instance, but only the "entree points" you have configured will
actually be executed. IE in my configuration, any request for the
installation or administration folder will cause the index.php file from
that folder to be run. Everything else goes to the primary index.php file.
This means you completely close off any security issues where someone
discovers an extension with a hole that lets you do something like
http://yourjoomlasite.com/plugins/content/somecoolcontentplugin/somecoolcontentplugin/lib/somelib.php?action=someexploitablecommand
All those problems are eliminated.
Security: one nice feature is that you can restrict access to some of
the entry points using Google Authentication. In my case, I set things
up so you can't even access the installation or administration
interfaces unless you are logged on to a Google Account and have been
assigned admin rights to the project.
Usage costs: Usage costs are a bit on the odd side. With GAE you don't
have a server that is "always running" whether or not your website is
active. Instead, when someone attempts to connect to your website,
Google spins up 2 micro virtual systems - a web server and a mysql
server - configured with your PHP code and your database. When the
system stops being accessed for at least 10 minutes, those systems are
turned off. You only pay for the minutes that your system is actually
running.
Scalability: Since your forced to run 2 separate "instances" - one for
the database and one for the PHP code, you get some basic scalibility
for "free". GAE can actually run anywhere from 1 to 1,000[or more!]
"instances" of your PHP application - and they all access the same
database. So a website that suddenly gets so popular that it's
overloaded can reconfigure their account and increase the maximum number
of instances allowed to run...instant scaling.
Alongside all of this, there are a lot of fun little features you can
play with once you have an app engine deployment running. They allow
you the option of integrating Google's Pagespeed service into it which
will optimize images and compress/minify javascript and css with a
dizzying array of switches, dials, and toggles to turn on/off different
optimization.
They have a User API which PHP apps can use to use Google Apps for
authentication/user information.
There is both a "free" memcache service and a paid option
Lots of things to twist and turn and play with.
_______________________________________________
New York PHP SIG: Joomla! Mailing List
http://lists.nyphp.org/mailman/listinfo/joomla
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
