One drupal to rule them all - Drupalcamp Caceres
Upcoming SlideShare
Loading in...5

One drupal to rule them all - Drupalcamp Caceres






Total Views
Views on SlideShare
Embed Views



1 Embed 24 24



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

One drupal to rule them all - Drupalcamp Caceres One drupal to rule them all - Drupalcamp Caceres Presentation Transcript

  • One Drupal to Rule them all ! Hernâni Borges de Freitas @hernanibf /
  • About me! •  •  •  •  •  •  2 .PT     Technical  Team  Lead  PS   Drupal*  many  things   Travel  lover  
  • One Drupal to rule them all! 3
  • One Drupal to rule them all! “My organization wants to standardize in Drupal and use it to replace all the sites in our network”: -  -  They can be managed by different people but we saw them as a unique platform. -  4 They have different look and feel. They can share some common sections or content.
  • This presentation! •  Manage a network of Drupal sites with same features / properties. •  Launch new sites and introduce new features. •  Minimal downtime allowed per site. •  Share data among sites (content/user login) •  Grow their infrastructure in number of nodes / number of clusters. •  Common software / common infrastructure. 5
  • First challenge! What are several sites and what is one site? •  A site for maths department, another for physics, another for literature, another for computer science. All with same look and feel. •  Sites need to show news from all of those sites. •  Admins should just edit those sites from one place. •  One site => One Drupal site? •  Many sites => Many Drupal sites? 6
  • Options! All sites in one Drupal site •  Same code. •  Same database. •  Contributed modules will recognize contexts and create sections inside the site. •  Same infrastructure. 7 All sites in different Drupal sites •  Same code (with some differences). •  Different databases. •  Same infrastructure / Different infrastructure.
  • What’s the best?! Traditional consultant answer: It depends! 8 -  Sites’ differences. -  Shared properties/ info. -  Predicted evolution. -  Teams responsible for build/maintain/ admin.
  • One Drupal site! Better fit for: §  Content present in several sites. §  Similar look and feel. §  Similar user base / admin workflow. §  Small differences between sites in terms of functionality, Mostly used for: §  Webs/Intranets with different sections / departments. §  Sections with different publishing workflow. 9
  • One Drupal site! Organic groups §  Groups define sections/sites. §  Content and users are associated with groups. §  Users have different roles and permissions within the group. §  Very good integration with views, panels, rules §  Good suite of complementary modules (og_theme, og_menu, og_workbench, og_workflow). 10
  • One Drupal site! Other options •  Domain access module •  Access control modules •  Others… 11
  • One Drupal site! Advantages •  Easier to create a unique experience of one single site/platform. •  Easier to share content. •  Easier to share users / roles / permissions. 12
  • One Drupal site! Drawbacks •  Everything gets a bit more complicated. •  Codebase and structures are usually larger (more views/blocks/content types/panels for the different sections). •  Single point of failure. •  Harder to decouple in the future. 13
  • Many Drupal sites! •  Multisites •  Different codebases In either case they always have •  A common base –  Common Drupal distribution (Features + Install Profile). –  Common infrastructure. 14
  • Many Drupal Sites - Multisites! Advantages •  One codebase to maintain / update. •  Easier to reuse infrastructure. •  Lower memory utilization (APC). •  Simpler at all levels. Drawbacks! •  Single point of failure. •  Common maintenance windows. •  Harder to maintain differences in code (multiple versions for same module). 15
  • Many Drupal sites - different codebases! Advantages! •  Can be deployed in different locations. •  No single point of failure in infrastructure. •  Easier to support differences. Bad! •  Harder to manage pushes of code to all sites. •  Need for a consistent process to manage updates of code. •  As there can be more differences, harder to test. 16
  • Standards! “Marketing is demanding us to be able to spin up new sites that are limited in functionality but require minimal development time”. “Operations is asking us for a standard deployment/maintenance process for all of our sites. 17
  • Meet the idea of factory of sites! 18
  • Meet the idea of factory of sites! •  Single codebase/distribution with enough modules/features allowing customize sites without touching code. •  Limited functionality (less is good). •  Easy to spin a new site in few minutes. •  Easy to update sites in the factory without impacting full network. •  Easy to grow infrastructure by adding cluster of nodes where different sites are hosted. 19
  • Solutions working in this space! •  •  •  •  •  20 Drupal Gardens Acquia Cloud Site Factory Pantheon One Aegir Custom solutions
  •! •  Software as a Service (SaaS). Freely available ! •  One distribution (gardens) provides a rich editing experience (D7). –  Rich field types (Link, Date, Field Collection), Wysiwyg, Media, Theme editor, WebForms –  Create content through the Drupal Gardens iPhone app. •  Multisite installation. •  Hosted in Amazon Web Services (AWS), easy to grow and allocate more machines to the cluster. 21
  •! •  SSO using OpenId. Accounts controlled in the gardener site. •  Not possible to add any code. •  No vendor lock-in. Possible to export code/ db/files. •  Pricing depending on features enabled and bandwith consumed. 22
  • 23
  • Acquia Cloud Site Factory! •  Several distributions are available (gardens, commons, commerce). New ones can be created. •  Control Panel (Gardener) controls all sites in the network. •  Code is controlled from a GIT repository. •  Two environments are created (production/ sandboxes). •  Sites are created directly in production. Sites can be cloned in sandbox for testing. 24
  • Acquia Site Factory! •  SaaS –  Support and SLA on the software. Several distributions available •  SaaS+ –  Support and SLA on the software. Client can add code audited by us. •  PaaS –  Support on the platform. Client can add any code to the platform. 25
  • Acquia Site Factory! •  Powering the largest network of Drupal websites in the world. •  Scalable. •  Support included. •  Best of Gardens + Acquia Cloud. 26
  • Demo 27
  • Aegir! •  Community project to control Drupal hosting. •  Open source, Self Hosted. •  Hostmaster controls the websites in the network. •  Aegir is responsible for controlling code deployment, database creation, vhost change. 28
  • Aegir! •  Platforms have a code base and will host several sites. •  Platforms are associated with a a docroot (can be defined using drush make files). 29
  • Aegir platforms! 30
  • Aegir - Sites! 31
  • Aegir - Migrations! 32
  • Aegir ! Good! •  Simple networks / simple sites. •  It can be self hosted. Drawbacks! •  Using a Drupal to manage infrastructure might be tricky. •  Install and configure Aegir is not straightforward. •  Deploy code to several servers is challenging. •  Update sites involves migrating them from platform to platform. •  Migrating sites involves copy all the database, files and code and swap the vhost (Hard to scale for larger sites). •  Harder to support the concept of several environments. 33
  • Custom solutions! Users/Visitors Platform Admin Management Server Load Balancer Deploy process Apache/PHP Memcache Web1 Web2 Half size Shared Storage Staging MySql Active/Passive Production 34
  • Custom solutions! •  Management server –  Access to all hosts in the infrastructure via SSH. –  Database of sites. –  Issuing commands in all sites •  Drush •  Drush site alias –  Move databases/files directories between environments (drush sql-sync, drush rsync). 35
  • Custom solutions! •  Everything should be created automatically: –  Databases, disk directories and virtual hosts: –  Config management (CM) tools / custom scripts. –  Drush site-install can install new (multi)sites. •  Deploy code to the servers –  Capistrano –  Drush deploy –  Custom scripts •  Graphic interface to view all the sites and their properties (custom development) and manage jobs (Jenkins?). 36
  • Custom solutions! •  Infrastructure –  Easily launch new nodes to the infrastructure to support production and pre-production environments and configure them automatically (CM Tools). 37
  • We are hiring! •  Consultants •  Support •  Sales •  Engineering 38
  • Questions? @hernanibf  /   39