Log In

By:

kiriaze

GridServer implementation using NginX Server Blocks, and gitlab.

May 2, 2014 1.9k

Goal is to run a setup similar to Media Temples GridServer using NginX Server Blocks optimized with varnish for lightning Wordpress installs, all under app1.domain.com structure, while also housing gitlab under gitlab.domain.com. This is branching off my other question: https://www.digitalocean.com/community/questions/staging-production-environments Ideal end goal is to: 1. Have a main wp install on domain.com (company site) 2. House all "staging" sites under #1, as app1.domain.com 3. House gitlab on gitlab.domain.com 4. Gitlab would house all "staging" sites in individual repos 4a. Is the best method for the repos to hold the whole site including core, themes, plugins, etc. like pagodabox does or house only say a vagrant/composer setup so the repo is lightweight - but what about the theme files? 4b. When pushing to these repos should they auto deploy changes similar to pagodabox/heroku? 5. Separate droplets created from snapshots of "staging" site for "production" sites, which im not even sure thats currently possible since the snapshot wouldnt be able to target individual blocks.. 5a. Would it then require an image ( say NginX/wp/php/varnish/vagrant setup ) to launch new "production" droplets, and then import dbs and themes/files/uploads? Seems like there would be a better option, especially for when making updates. I know this cover a lot, trying to figure out the best method for staging/prod deployments while keeping a revision history (git repo) and making sure everyone has an exact copy of environments/dbs/dependancies (vagrant/composer). Any help would be much appreciated! -CK

Log In to Comment

4 Answers

asb MOD May 2, 2014

It sounds like you're up to some cool stuff! I'm excited to hear what deployment ideas people come up with.

The first thing that jumps to my mind is regarding 4b. I'd personally set set up automatic deployment after each git push to the gitlab instance. You can setup a post-receive hook that deploys to the different environments based on the branch. That way when you're ready to deploy to production, you can just merge master into a production branch. Something like:


#!/bin/bash

while read oldrev newrev refname

do

    branch=$(git rev-parse --symbolic --abbrev-ref $refname)

    if [ "master" == "$branch" ]; then

        # Deploy to staging

    fi

    if [ "production" == "$branch" ]; then

        # Deploy to production

    fi

done

See: http://stackoverflow.com/a/13057643/598929

As far as Wordpress specific things like whether to check in the whole site, there are lots of opinions out there. Some interesting things I've come across:

http://roybarber.com/version-controlling-wordpress/
http://www.efeqdev.com/website-development/this-is-how-we-version-control-and-deploy-our-wordpress-websites-with-git/

kiriaze May 4, 2014

Thanks for the reply Andrew!

Had a look at those links, and Im familiar with the auto deploy script/post hook having used that with bitbucket, but didn't like the fact that I couldn't deploy based on branch rather than always, so thanks for that bash script, thats pretty nifty!

Came across, bedrock ( https://github.com/roots/bedrock ) which is interesting but doesn't yet support Vagrant or a method of syncing dbs, but the closest Ive come across that implements pagoda/heroku is the dokku app.

1. What are your thoughts on easyengine ( https://github.com/rtCamp/easyengine ) or puphpet ( https://puphpet.com ) ?

2. Back to implementing gitlab as a nginx server block @ gitlab.domain.com, is that ideal/practical compared to having the gitlab.domain.com under its own droplet?

3. I love the idea of setting up a boilerplate so to speak, and creating a snapshot from it to easily create new projects! If using vagrant, however, you mentioned there might not be a need for it. If not using vagrant, would the best method for keeping teams in sync be to launch the droplet from the image, setup the wordpress install on the remote first, then pull it everything down w/ a sql dump?

bruno May 6, 2014

Will you make tutorial after you done with this? My idea was very close to that. So:
- domain.com for main site
- gitlab on gitlab.domain.com
- development part dev.domain.com/projcet

But somthing what i want to make to move gitlab main repo folder from there original location to dev.domain.com location. In that case i don't need any hook. Master branch will be always in sync with dev. Can someone help with this?

bruno May 31, 2014

ckiriaze do you have new informations about this?

Have another answer? Share your knowledge.