Taking Drupal development to the Cloud Karel Bemelmans About me - - PowerPoint PPT Presentation

Karel Bemelmans

Taking Drupal development to the Cloud

About me

• Working with Internet based services since 1996
• Working with Drupal since 2011
• Currently “the devops guy” @ Nascom

Case Study: Nascom

• Genk, Belgium
• Service Design Agency
• Drupal & Symfony2 dev
• About 12-16 devs

Fase 1: Local development

Local dev: Con’s

• Hard to setup properly properly (http://localhost)
• Hard to work on a shared files
• Hard to show your work to someone else
• Not a good reflection of the production environment

New setup requirements

• 1. Perfect copy production
• 2. Isolated, no more shared solutions
• 3. But still easy to use

Fase 2: virtual project servers

Server Setup

• One virtual Linux server per project, just like production


(LAMP + varnish, solr, memcached, …)

• Automated setup (puppet)
• Hosted on local xen cloud + ceph distributed filesystem
• LDAP accounts + sudo for everyone

Workspaces

• Apache (nginx) Virtual hosts with dedicated php-fpm pool
• DocumentRoot: /data/sites/$user
• http://$user.project.nascom.local
• Shared content: /data/shared (no chmod 777 -> setfacl)
• Mailcatcher on every server

Setup new workspace

• createWorkspace.sh $user
• cd /data/sites/$user
• git clone
• symlink /data/shared/files to www/sites/default/files
• create env.settings.php
• Done!

Drupal settings

• settings.php: project-specific information
• generic site settings (Drupal hash, …)
• module includes (memcached)
• …
• committed in git

<?php $update_free_access = FALSE; $drupal_hash_salt = 'RANDOMSTRING'; ini_set('session.gc_probability', 1); ini_set('session.gc_divisor', 100); ini_set('session.gc_maxlifetime', 200000); ini_set('session.cookie_lifetime', 2000000); $env_config = DRUPAL_ROOT . '/sites/default/env.settings.php'; if (file_exists($env_config)) { require_once($env_config); }

Drupal settings (2)

• env.settings.php: environment-specific information
• included at the end of settings.php
• database info
• memcached prefix
• $conf[‘foo’] = ‘bar’;
• not commited in git

<?php $databases = array ( 'default' => array ( 'default' => array ( 'database' => 'dbname', 'username' => 'dbuser', 'password' => 'secret', ), ), ); $conf[‘memcache_key_prefix’] = ‘karel’;

sshfs mount

• Local machine: mkdir $HOME/Projects/foo
• sshfs user@server:/data/sites/user $HOME/Projects/foo
• SublimeText opens project in $HOME/Projects/foo

Remote commands

• work on the server via ssh, not local (git, compass, grunt, …)
• you can work on the shared git (e.g. GitX), but slow!


IDE: disable fs scan plugins! (git plugins)

• leet mode: develop with vim/emacs on the virtual server
• remote xdebug: possible with ssh tunnels

Virtual project servers: Pro’s

• Identical to production setup
• Independent of the dev’s client (Mac, Win, Linux, …)
• Once the server is running, adding extra workspaces is fast
• Everyone can access it, easy to look at other people’s work
• Easy staging setup: http://staging.project.nascom.local

Virtual project servers: Con’s

• Takes time to setup new project (puppet!)
• Grows fast on hardware needs (100GB disk, 2 CPU, 4GB RAM per

server), we had about 30 projects running at one point

• Backup and monitoring is complex
• Local hosted on a Xen cloud with ceph filesystem: lots of hardware

problems, high operational cost

Setup 3: shared hosting on an external hosted private cloud.

VMWare platform

• VMWare vSphere Essentials Plus with vCenter
• 3 physical machines with dual octocore CPU and 128GB RAM
• iSCSI storage over 10gigE fiber
• Nascom office: 100/100 fiber connection

Plesk

• Parallels Plesk Panel 11.5 & 12
• Intended for shared hosting setups
• Looks good
• Works even better: built on standard CentOS / Ubuntu distro


(apache, nginx, mysql, php-fpm, …)

Shared hosting setup

• Linux distribution (CentOS 6.5, Ubuntu 14.04 LTS)
• Local users (managed by puppet)
• Plesk
• Local tools: compass, grunt, xml tools, xhprof, New Relic,…

Keeping it all private?

• Firewall per server: iptables via ferm (puppet)
• dev: closed except vpn
• acc, ci, prod: open port 80 + .htaccess
• OpenVPN:
• masquerade vpn ip
• push routers for 3rd party servers = easy access

Plesk

• Customers: Customers (e.g. Nascom)
• Subscriptions: Projects (e.g. Nascom-Corporate):


http://nascom-corporate.dev01.nascom.be

• Subdomain: Workspaces 


http://user.nascom-corporate.dev01.nascom.be

Working on the shared server

• The same as our virtual project server:
• bitbucket git
• sshfs
• commands via ssh

Extra daemons

• Install it on the dev server


e.g. memcached, solr via tomcat on port 8080, …

• Install it on another virtual server


e.g. varnish on 80, connects to dev on 7080

• normal: http://user.project.dev01.example.org
• varnish: http://user.project.varnish-dev01.example.org

Extra tools

• mailcatcher
• install it on a separate server
• dev/acc postfix: relayhost $ip:1025 (or PHP sendmail_path)
• http://mailcatcher.nascom.be:1080

Acceptance, CI, Production

• Same server setup as dev (puppet!)
• Same Plesk setup, just no subdomains:
• Customer: Nascom
• Project: Nascom-Corporate
• Main workspace: nascom-corporate.acc01.nascom.be
• Plesk htaccess setup: not firewalled, but still a password

Support servers in our cloud

• backup server (cheap SATA storage): NFS + rsync
• monitoring & alerting: only for server + applications not hardware
• munin, nagios3, zabbix
• virtual varnish server (dev, acc, ci, prod)
• puppet master
• support applications: mulesoft, Bamboo buildserver, …

External shared hosting: Pro’s

• Fast to set up: 5mins initial setup, 1min workspace
• Easy to backup and maintain: Plesk
• New production setup? Make a new dev server.
• Exotic setup? Make a new dev server.
• Still a good reflection of our production environment

External shared hosting: Con’s

• Shared server down? All workspaces down. 


Solution: shard your dev servers + use provisioning

• Expensive. But so are humans.
• Bandwidth and latency requirement: 100/100mbit for Nascom office

Conclusion

• After 9 months: 0 downtime. Everyone happy!
• Dev server is about 90% of the production environment, problems:


varnish, exotic server installs, FTP hosting :(

• Works great with automated deployment (Bamboo)
• Next step: automation, testing, …

Statistics

• Latency over VPN: 8-10ms roundtrip
• 2TB iSCSI storage
• 200GB traffic/month
• Costs: 3500 euro/month

Questions?