Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

One drupal to rule them all - Drupalcamp Caceres


Published on

Published in: Technology
  • Be the first to comment

One drupal to rule them all - Drupalcamp Caceres

  1. 1. One Drupal to Rule them all ! Hernâni Borges de Freitas @hernanibf /
  2. 2. About me! •  •  •  •  •  •  2 .PT     Technical  Team  Lead  PS   Drupal*  many  things   Travel  lover  
  3. 3. One Drupal to rule them all! 3
  4. 4. 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.
  5. 5. 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
  6. 6. 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
  7. 7. 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.
  8. 8. What’s the best?! Traditional consultant answer: It depends! 8 -  Sites’ differences. -  Shared properties/ info. -  Predicted evolution. -  Teams responsible for build/maintain/ admin.
  9. 9. 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
  10. 10. 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
  11. 11. One Drupal site! Other options •  Domain access module •  Access control modules •  Others… 11
  12. 12. 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
  13. 13. 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
  14. 14. Many Drupal sites! •  Multisites •  Different codebases In either case they always have •  A common base –  Common Drupal distribution (Features + Install Profile). –  Common infrastructure. 14
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. Meet the idea of factory of sites! 18
  19. 19. 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
  20. 20. Solutions working in this space! •  •  •  •  •  20 Drupal Gardens Acquia Cloud Site Factory Pantheon One Aegir Custom solutions
  21. 21.! •  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
  22. 22.! •  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. 23. 23
  24. 24. 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
  25. 25. 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
  26. 26. Acquia Site Factory! •  Powering the largest network of Drupal websites in the world. •  Scalable. •  Support included. •  Best of Gardens + Acquia Cloud. 26
  27. 27. Demo 27
  28. 28. 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
  29. 29. 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
  30. 30. Aegir platforms! 30
  31. 31. Aegir - Sites! 31
  32. 32. Aegir - Migrations! 32
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. Custom solutions! •  Infrastructure –  Easily launch new nodes to the infrastructure to support production and pre-production environments and configure them automatically (CM Tools). 37
  38. 38. We are hiring! •  Consultants •  Support •  Sales •  Engineering 38
  39. 39. Questions? @hernanibf  /   39