 Hi, welcome everybody to DrupalGov 2020. My name's Nick Xu. I am the track host for ops and security. So you'll see me quite a bit when it comes to these sessions and introducing folks. Yeah, I just want to point out that this is a very early bit of software, or this is kind of the first time doing this, especially for me. So if you have any feedback or questions or don't hesitate to ask, I'm going to be fielding the questions. But I'll get straight to Michael. So I saw Michael present in, it was DrupalSouth2017, and he was the keynote speaker. And I just saw so much passion for technology. And that resonated with me a lot. So everybody's in for quite a treat today for his talk. So I will cut over to him now, and we'll get started. All right, thank you. Yeah, hello, everybody. Super happy to join. And this year's, unfortunately, that we cannot sit together. But it actually makes it easier for me because I don't have to travel for 30 hours. But yeah, today we want to talk about Drupal multisites. Like Nick said, I'm very passionate about technology. And I'm very passionate about not using multisites. So yeah, let's jump right in. Like Nick said, I'm Michael Schmidt. There are people who call me Schnitzel in the internet. I am the CTO or head of technology at AMAZIO. We are a hosting company. And we do draw a lot of Drupal hosting, and especially really big Drupal installations. And so that's where my knowledge comes with multisites. So before we jump in, I shortly want to give an overview of what multisites are. So multisites really have been started in the Drupal community quite some time ago. And the idea was, how could I run multiple Drupal installations with only one single code base? The reason originally came from super cheap posters, where you could only upload one folder, but people wanted to run multiple Drupal sites. And so what they did is they figured out the way how you can do this with still having different databases and also different file storage. So that's important to know that a multisite has the same code base, but different databases and different file storage. And also each side, of course, has its own domain. And so the idea behind it was really like, hey, let's do easier upgrade and security batches. Because if we have a shared core base, I apply one single change, and it applies to all these sites. That would be really great. And so at the end, it's all about centralization. Having centrally managed systems should make things easier. Important to know is that domain access is not a multisite. So domain access is actually the same database with just different domains, while a multisite is the same code base, but different databases. So how does Drupal internal solution actually look like? When you install a multisite? So we see here, we have some shared core modules and themes. And then each site has its own modules, themes, files, modules, themes, files, modules, these files. And they also have each their own database. You have a file called sites slash sites of PHP, where you define which site actually reacts to which domain. And that's it. So that's a super simple what exactly multisite can do. Now, what I see is that this system now has been used for a lot, lot, lot more than it ever was intended to be. And so people today, they run multisite installations with 500, 1,000. The biggest one I've seen are like 3,000 sites that are all running. And these are not just like simple sites. These are enterprise grade or government sites that they really need to work. And there's a lot of different people that are working with them and handling them. And so the problem with this system that we see here is that you cannot do individual updates. So you always will update all sites at the same time. If one of them breaks and you need to roll back code, this will apply to all sites. So there's no way for you to do this. There's also no real way to test core upgrades, because if you update one site, it upgrades all of them. Now what you can do, you can run a whole separate installation of a triple multisite, but that's going to be very complex again. And then also because the individual sites, they don't have code, the core code in them. It's very hard to do a development environment because you will give everybody access to all the sites automatically. And so some people, they would like to have individual Git repositories for each of the site and then permissions. But because it's one huge triple site, it's never going to be possible to only allow access to only one site for one developer and cannot access the others. So it's going to be a mess quite fast. So we set out and we tried to find solutions for our customers together, what can be done. And we came up with containers and container images. And the big reason there is specifically A, the cool thing about container images, they can inherit from each other. So you can load them and I will see this later. And also because each site creates their individual container, you can have them individually upgraded. You have individual security capabilities, meaning you can define who can access what. So let's look at a regular container workflow. How do you actually deploy a triple site with containers? The first thing that you need is some kind of container that has PHP and PHP config in there. This does not actually have Drupal code yet. It's just the PHP and everything that is needed to run a Drupal. This usually exists in a Git repository and it's like it said, it has everything that you need. But it does not actually contain any Drupal code. In our case, we use official Docker images. So the PHP, for example, will automatically update it when the PHP community releases in your image. So you'll always stay up to date with security. And then, so these images here, there are multiple people out there that maintain them. One of them is, for example, is our company. We have an open source hosting solution called Lagoon and we have Drupal container images that we maintain. But at the end, there are other people out there that do the same. So you maybe don't even need to maintain them yourselves if you wanna use this. And so let's continue there. Now what we also have, we need to actually bring out a Drupal code. And so this is then core module themes and any custom modules. And this is then in another Git repository. And the important part is this from here. So this container image can now inherit from that previous or the upstream container image. And you see this here. So in the Docker file for the site, I say from PHP 7.2 CLI Drupal. So I can use another image and add additional stuff like my composer JSON, composer log, and then I can run composer install. And so in that composer JSON, I then install all my Drupal, the Drush, whatever modules I wanna install in my site. So this image uses container images as upstream. It brings Drupal core modules, themes, whatever. And the build process of the hosting solution actually will create of all these files. It will create running containers and will run them. So at the end together, we have one fully built container image that is capable to run containers. Now this is the standard workflow. If you use any container based hosting solution, this is what's gonna happen. Now what we can do is we can bring in a base image and that's where the magic is gonna be. Now we start with the exact same. So we still have our Drupal container images and we still have an image that has a from there, but we're gonna call this the base image. Now this base image looks exactly the same as our site before and that's really cool. So we still use the from the Lagoon. We have all the composer stuff in here. It's just a regular Drupal repository. And it also uses these upstreams. You can add Drupal core and any modules that you wanna share. And because this is a regular Drupal, you can actually start this Drupal and test it and verify that it works. And so this means you can do automated testing. You can make sure before you publish a new image that people can use this. And what we do with this, instead of creating actual containers, we publish this image to a container registry that then other people are gonna use. So what we're gonna do is together, we're gonna publish this base image. Now publishing meaning you can upload this to a container registry like Docker Hub, but there are many others that you can share containers around or container images around. And now the really cool thing is the individual site now will just bring their site code and they from or they use the upstream this base image. So how does this look like? So in our case, the Docker file says organization base image. This is the image that we just published before. It will then bring its own composer and composer install, but in the composer JSON, you can see that we don't need to install a Drupal core anymore. And also we don't need to install any of these other modules. They're already there. So all we need to install is additional modules that we maybe want for this specific site. So this image uses the base images that's upstream. You can add any customizations via the composer JSON. At the end, it's just a package manager, but it's really cool because this is Docker and you can run this locally. You can completely run this locally without a problem. And if the upstream changes something, let's say there's a new PHP version, you can just update this and rebuild and the changes will go through all the images and we'll update. But beside of this, it's just a regular container workflow. You have containers, you push them and done. So in the end, the actual containers that will run will use all these three images and together they will form your actual fully built container image and that is gonna be used to run later. Now what can happen, we can not only do these site images once, we can do this many, many times. So we have, for example, site one, that is our production site that brings modules and themes. We have site one development that also brings modeling themes. We maybe have a production environment for the site two that only changes a theme. We maybe have even a site three that doesn't change anything. It uses all the core and images that are there and you can have as many sites that you want in this system. So it really gives you the flexibility to add them, to update them, to add additional site. If one of the site needs depth environments, no problem. You can even update individual ones. So you don't have to update all of them at the same time because you can define, okay, maybe the site three is a test site and so you update that one first and only when that one works, you can then update all the other prod environments or you say, I update the depth first and then all the prods. So you have full flexibility how to do all of this. So let's look at the advantages of all of this. Each of the site has its own Git repository, its own containers and its own environment. That means you have no problems in terms of upgrading them individually and you can give individual accesses for users. So if you have a developer, you can define, okay, that developer only have access to one specific site and not to the others and also the sites cannot interfere with each other. If one of them has really bad code, the code does not run on the other one and so you have no problem there. So if one fails, there's no impact on the others and then core modules are still centrally managed which in the end is the core idea of Drupal multisites. We want the central place where we can manage all of this and we can also have multiple environments per site. So if you wanna have staff, staging, production, QA, acceptance and whatever, each of the sites can have individual amount of environments what that specific site needs. Local development is super easy. And so we worked with that with the Australian government. So with GovCMS, this is all based around this. So in with GovCMS, which is the centralized Drupal hosting solution for all of Australian government, we have around today 300 production sites that all are based on this base image system. Each individual Git repository or each individual site has their own Git repository and in this case, they can only upload themes. So we make sure that for specific sites, they can only upload themes, others they can maybe do modules so you can also have different permissions. But each site has its own development and staging environment. So if a team updates their sites, their theme, this then just automatically updates the development environment and that goes in. And what we can do, we can update all production sites within a couple of hours and this can be fully automated and we basically just need to monitor this. So let's say Drupal brings out the new core module or a core version, we update the base image and this will update all sites fully automatically from one single place. So in conclusion, multi-site installation with base images are super cool. They're easy to use. You don't have any stressful deployments anymore because you update hundreds of sites at the same time. You still have individual permissions and access per site and of course, everything I told you now actually works for much more than just Drupal. You can use this for any other system and we have customers that use this like for Laravel and other other systems because we don't depend on the application itself anymore to support any of this. And yeah, if you wanna see this in place or in action, we have them environments, we show all of this. So if you wanna give it a spin, play around with it, talk to us and we're happy to help. And that's it. Cool. So we've got a couple of minutes left and I've just been going through the forum. So the first thing was asked a few times by, I'll read Michael. So actually, no, sorry, sample setup. So is there a sample setup that people can go and look at this type of approach? Yes, there is one that we're currently upgrading. It doesn't exist right now. So I cannot give you access to it, but it should be there in a couple of days. If you wanna see it, shoot us an email or contact me and send me an email or contact us at Amazio.io. And I'm happy to give you access to the environment as soon as we have it up to date because there are a couple of changes that we're implementing right now, but yes, they will be there. Cool. The next one, oh, actually, yeah, this was Michael. So the downstream composer.json isn't aware of, sorry, the auto refresh is killing me. So the downstream composer.json isn't aware of upstream composer.json when you have dependency conflicts. Yes and no. So what I showed you is a bit of simplified version for a 15 minute talk. It is aware of upstream composer.json. How this actually works is we're also publishing from the base image composer.json. We actually publishing a composer package for this as well. And this is how the downstream composer.json is aware of the upstream. You will see this in a specific, in the demo, how this exactly works. I see there are some questions in the QA as well. Yeah, I was trying to go in, but the screen just says closed for me. I can see them. Register for tickets closed. Okay, I'll let you feel them then. So the easy one, the close-up of the tea. So this was Drupal, no, the DevOps days, Austin 2017. They did a monster of DevOps shirt that I really like. Have you played with multiple frontends for a single end or multiple backends? I asked Stuart, yes. We have done this and we actually have it in place. So I would, but I honestly don't really understand what this has to do with that specific of Drupal. But yes, we can also run multiple frontends with a single backend, that's possible. Then another question, we have 50 seconds left. How do you handle databases? Like each site will have its own database and you pull correct. Every site has its own database and you can use like Drush site aliases to synchronize them. So that's like any other environment. Then Sean asked, are there any performance reasons why having distinct project is a good idea? Yes, you can individual scale them. So each container can scale automatically and so each site can automatically scale. So if one site needs a lot of traffic like in COVID situations, you can only scale that site without actually needing to scale all the other ones or all the servers. And I think that's it. If you have more questions, join our booth. I'm happy to answer them there, no problem at all. Thank you.