SNS Deployment update

As an update to this old post from 2013…

We have moved to using php-fpm, so naturally suEXEC has been replaced by php-fpm’s configuration. That allows for running multiple pools, each running PHP scripts under their own user.

We have the “main” pool still using the same unprivileged user as Apache, and then there’s a “privileged” pool that uses the privileged user. Only the traffic on the port receiving SNS notifications is directed to this privileged pool. The main pool still has the same permission it would if it were running under mod_php, to ease the transition.

The transition was relatively painless, but only because I’d already converted per-dir .htaccess files into rules in the server config. It was part micro-optimization, part “I will probably want nginx someday.” Although Apache is still serving our needs admirably.

SNS driven deployment (architectural overview)

3 Sep 2015: a note about how we're using php-fpm instead of suEXEC now has been published here.  Now back to your original post...

One of the problems I faced with getting Auto Scaling up and running was, "If I can't just ssh into the one live server and issue a git pull by hand, how do I push code out?"

Normal people would use capistrano, or Paste Deploy, or something, extended to access their auto scaling group to locate the hosts to use.  Or build on Heroku or Elastic Beanstalk to begin with.  I, however, am clearly not normal.

HTTP(S) Endpoints and SNS

If you subscribe an HTTP endpoint to SNS, the first thing AWS does is send a subscription confirmation to that endpoint, which should be ready to handle it.  (If not, you can manually re-subscribe it through the console when the service is up, and AWS re-sends the confirmation.)  It turns out that the actual messages as exchanged with endpoints are defined in the Getting Started Guide, Appendix D; not the API reference!  The API reference only contains the administrative calls that can be made to the API, such as ConfirmSubscription.

It also turns out that the signature of the message sent to the endpoint is message-specific; Notification messages use a different set of fields to be signed than SubscriptionConfirmation and UnsubscriptionConfirmation.  Again, the details (and examples) of this are not in the API documentation, but Appendix D of the Getting Started Guide.