Stilldream Promo Mix 002 – Roy Lindauer – The Late Shift

Super excited to be dj’ing at Stilldream this year. Been going to this crazy event since ’04 (maybe ’03, it’s a bit blurry) and stoked to be going again, but this time being on the other side of the dancefloor.

Check out more mixes.

Santa Cruz July 4th Weekend 2015

IMG_2640

IMG_2667

IMG_2937

IMG_2594

 

Check out more pics @flickr.

Practicing 7/1

tree

IMG_2542

I really liked the light in the bottle, and the golden color of the beer of course

IMG_2416

A little blurry, but I liked the Rembrandt-ish light

Enable status for php-fpm

Accessing the PHP-FPM Status screen is easy enough. First, enable pm.status in your php pool:

Then add the following block to your Nginx vhost conf:

Restart php-fpm and nginx and then browse to http://<SERVERIP>/status. You will be presented with some useful information on the current status of your PHP-FPM pool.

By default /status will just show a short status, like an overview of all of the processes. To see output on each process append ?full to the url, http://<SERVERIP>/status?full. You can also pass ?json to get JSON output, if you wanted to feed the data into some other log or stats processing tool (thinking like, greylog or logstash?).

Here is a breakdown of the stats presented to you:

pool – the name of the pool.
process manager – static, dynamic or ondemand.
start time – the date and time FPM has started.
start since – number of seconds since FPM has started.
accepted conn – the number of request accepted by the pool.
listen queue – the number of request in the queue of pending connections (see backlog in listen(2)).
max listen queue – the maximum number of requests in the queue of pending connections since FPM has started.
listen queue len – the size of the socket queue of pending connections.
idle processes – the number of idle processes.
active processes – the number of active processes.
total processes – the number of idle + active processes.
max active processes – the maximum number of active processes since FPM has started.
max children reached – number of times the process limit has been reached.

Use this information to tune your pool configuration.

My Pantheon + Jenkins Process

pantheon-workflow-jenk

Here is a rough outline of my Pantheon + Jenkins process. I like my code in BitBucket. I also like Pantheon (check them out). The Pantheon workflow is all about being the source of truth for your code. This is fine, and actually I dig it because it promotes good practices. However, I, and my company, have many projects in BitBucket already, and am using Jenkins more and more for some Continuous Integration functions. We want to keep using BitBucket as our source of truth and our existing workflows, but also want to use Pantheon.

Already, this is problematic and managing it on a developer by developer process is going to be prone to error. You have to push branches to two remotes and deal with, probably, some ugly merging and potentially other issues.

What I want to do is to push to BitBucket and use a commit hook to trigger Jenkins to deploy our code to Pantheon automatically. I use Pantheon Multidev (at work) and this process assumes that the Mutlidev env already exists. It will not create it for you (yet).

The BitBucket commit hook

How this is going to work is we are going to setup a POST hook with BitBucket. We will set the POST url to be a PHP script (our receiver script) in our Jenkins server (or just setup a small ec2 instance to host it if you don’t want to install PHP on your Jenkins server). The POST payload will include the list of modified branches. I have called my receiver script jenk.php because, heh. I have setup some environment variables with my Jenkins username and access token so that I can make API requests to the Jenkins server.

The POST hook url looks something like: http://jenkins.server/jenk.php?project=<project-name>&token=BUILD-PROJECT

Replace <project-name> with the name of your project, and replace BUILD-PROJECT with your build token.

jenk.php

This is the receiver script. It gets data from your commit, and submits a build request to Jenkins. Easy peasy.

The Jenkins + Pantheon Deploy Configuration

I have configured a parameterized build with Jenkins. The single defined parameter is “BRANCH_TO_BUILD“.

Under Source Code Management I have added the two git remotes, one for BitBucket called “origin” and one for Pantheon, called of course, “pantheon”. In the “branches to build” section I added in  remotes/origin/$BRANCH_TO_BUILD .

Under Build Triggers I used “BUILD-PROJECT”.

Under Build I added an “execute shell” task to checkout our branch from origin so that we can push to the pantheon remote –  git checkout remotes/origin/$BRANCH_TO_BUILD

Finally, I added a “Git Publisher” post build task configured to push the “$BRANCH_TO_BUILD” to the “pantheon” remote.

To summarize, the process is make code changes, commit, push to BitBucket remote, hook is fired, and a POST is sent to our receiver script, which sends a POST to Jenkins with the $BRANCH_TO_BUILD parameter, and if the build passes, the branch is pushed to Pantheon. If everything worked you will see Pantheon converging your app in the dashboard! If it fails, well, check your console output from the build.

And that’s it. We can continue using our regular, non Pantheon, workflow, with Pantheon. The process and workflow stays consistent!