Decoupled Drupal Dev on Docker with Docksal Doing the Dirty Work

LECTURER:
Welcome to Decoupled Drupal Dev on Docker with Docksal Doing the Dirty Work aka Docksal Does Drupal Decoupled on Docker aka Something Something Alliteration Decoupled. I'm JD Flynn. I'm a lead software engineer at EPAM. You can find me on all the slacks. I go by Dorf, on Twitter JDDoesDev and drupal.org is u/dorficus. A little bit about me. I've been doing PHP and Drupal for years. I've been doing HTML since the 90s. I had the greatest sound clip web page of my town of a thousand people. I run BASIC kind of around the same time from a magazine. Does anybody remember 3-2-1 Contact? Yeah, in the back of it, they used to have a program that you could write and copy verbatim, and that helped me a lot with some debugging, learning debugging at a young age. I'm also on the Drupal CWG community health and conflict resolution team, so a little bit of housekeeping. There's Contrib Day on Friday. Amy June is a person that you wanna see if you have any questions about that and she's also looking for work.

So she also won an award. She'll be happy to tell you about it even if you don't ask.

STUDENT:
(INAUDIBLE)

LECTURER:
Alright. So just a disclaimer to get the most out of this. It'll help if you know at least a little bit about Docker. Feel comfortable on the command line. You know what a Drupal is and you have an understanding of Decoupled Architecture. What we're gonna cover is just a basic setup of a decoupled monorepo. So we're gonna have the front end and the back end all in monorepo. Back end obviously Drupal for purposes of this using Gatsby as a front end, but it could be any front end next.js nuxt whatever works for you with a little bit of customization there. What we don't cover or what I'm not gonna cover is I'm not gonna teach you how to set up Webpack and all your React stuff. Once you see what I have for Gatsby, you'll understand that I didn't take the time to do all that just gonna demonstrate a few things. We're not gonna go over all the modules that you need on Drupal side to do decoupled, and we're not gonna cover your questionable life choices. That's on you. So I do have a request.

If there's anything that I just completely misspeak about, if I'm telling you the wrong information, the sky is green. Feel free to correct me in a firm yet constructive manner. So a brief overview. First off, how many of you have used Docker? Familiar with it? OK, good. Has anybody used Docksal yet? I know a couple of people. Alright. So high-level overview of Docker. We're gonna cover that high-level overview of Docksal, get you into the weeds a little bit, but mainly we're looking at containerized decoupled architecture. So let's talk about Docker. The obligatory picture of the whale. I think this is a requirement for any presentation that has the word docker in it. And we're gonna go over this pretty quick. But I do feel the need to give kind of an overview of how Docker works. The basics. It's based on Linux containers. Not all containers are Docker containers, but all Docker containers are Linux containers. (UNKNOWN) syncing up there. OK. Docker provides an environment for Linux containers.

It's kind of a place for them to live. It puts everything together. But Docker is not containers itself. The images define containers. They're just what a container should do, what it should have every time you spin it up. And the container itself is ephemeral, it can... you should expect it to disappear. Shouldn't expect anything to remain persistent in it. When you destroy or shut it down, it's gone. Next time you started up, it's just gonna have what the image defined it to have. Now storage, we can't have that persist using volumes. We could do mounted volumes, naming volumes, bind mounts, and that's useful because you don't wanna have to reinstall everything every time you spin up your containers or your system. And services are several containers connected using Docker compose. So kind of an image of what all that did or the parts of Docker. We've got the client, which is what we usually interact with here with Docker build, pull, Docker run, or other commands based on what or depending on what you're using.

Then those commands go to the Docker daemon, which will either, depending on where they are. If you have the images already on your system, it'll spin up a container based on those. If you don't, it reaches out to the registry, grabs the images, brings them in, and then spins up the container. Does that make sense? LIke I said, it's a high-level overview, but I figure everybody needs at least some understanding. So now that we've got that out of the way, let's talk about Docksal. Docksal is written in BASH scripting, completely BASH scripting. So on most systems, you don't have to install anything like Node or even PHP to get it to run. Just all this is your basic command line. It uses Docker services. Docker compose extensively and any command that needs to be run inside the container, if you're running it from the host machine or the actual computer, you're gonna start it with fin. And there are a few commands that are built in where you don't have to do anything else but any other commands.

It's fin exec and then whatever your command is and it'll run it as though you're in the container. It's extremely configurable, which we'll go over in a moment. And because all the applications are fully containerized, it's very portable between developers. So I'm gonna look at the architecture of just Docksal and Docker compose how they work. Now in a traditional virtual machine, we cut this in half and every machine that you spin up would have its own, yeah, the command line, database, web server. Everything in there have its own system services. Forget Docker for that, have its own host machine or virtual machine and infrastructure. You have a different virtual machine for every project, whereas Docker and Docksal use services. So an individual project has its own CLI of that. Another project can have similar but not the same. Their own containers over here. But we're sharing the system services, the DNS server, the SSH agent, those all run on Docker, which unless you're on a Linux machine is a virtual machine because there are Docker containers... Linux containers, sorry, fumbling my words a little bit.

And that all uses the resources of your host machine, which is the actual computer you're using, and just use the infrastructure there. So the advantage is you don't have to have an individual set of services and individual virtual machine, all kinds of resources that you really aren't gonna wanna utilize if you have 3 or 4 projects on your system. OK, that makes sense? Alright, so we're gonna build a project now. For the purposes of not knowing how fast the Wi-Fi was gonna be coming here, I did a little bit beforehand, but still, we're gonna do a quick live demo just to show some of the default stacks how we can get things spun up, some of the options, how to start the system and how to customize it. So, here we go. So to create a project, fin project. Create. Let's call it midcamp-demo. So we get and I might try to enlarge this a little bit. So we get some options here. And it's... Let me go up. Fortunately, it won't let me. There we go. I know it's probably hard to read for those of you in the back, but we've got a couple of different flavors of Drupal, WordPress, Magento, Laravel Symphony, GraphCMS, even Backdrop.

If you don't wanna go PHP, we've got Hugo, Angular, Gatsby all ready to spin up just by typing in a number. So I already did this with a Drupal ten composer version and I'm not going to do it again because it'll download all the things and take forever. So to start up after running that command, it'll run what's called fin init and that is a blank file. It's a define your own solution however you want your project to start up. For us, hit Open. There we go. The default fin init. It's going to... I'm just gonna show my... Great. Run project reset, which is gonna clear out absolutely everything. So fin init is destroy scorched earth, then run a secondary command and a site which basically is going to do our composer install after pulling down a Drupal repo. Now, once all that's done, there are a few different things that happen to make it be able to run with a standard Drupal installation because normally you don't have the connection to the database with your default settings PHP. So we have settings, local or local settings depending on what your naming convention is.

And if you're adding Docksal to a project, all you have to do is make sure that your... I'm sorry if that's hard to read. Can you discern it from way back there? Just make sure that you're checking if the setting of local settings file exists and if it does, load it up. And in there, we have our database connection, which is gonna let the site run. I just... do any of you ever accidentally pressed down too hard on a touchpad and get the dictionary pulled up like, way too often? And just a couple of other things that you may or may not wanna have are Docksal specific. So if you're running a project Create like we pretended to do down here, you'll get this file with the reverse proxy stuff for the BLS proxy setup. So let's look at... Well, before I go on, does that make sense to get something spun up? And now since we've got that spun up, I'm going to then Project Start. So if I hadn't done this beforehand, we'd be sitting for about five ten minutes, if not longer, waiting for the images to get pulled down just because of the speed of the Wi-Fi.

So I did do it ahead of time. You're welcome. But it's a basic setup. All we're gonna have is the CLI, the database, and the web server. So it also gives us a URL there,- I'm gonna take this over here. And there we've got a full Drupal site. You can clap. Yeah. Make me feel good about myself.

STUDENTS:
(APPLAUSE)

LECTURER:
Alright,, so that's simple. There's nothing to that. We've got three containers, but it works. So let's do something a little bit more difficult and look at some of the available stacks. Getting used to controlling a screen that's behind me is extremely disorienting. Alright, so not important. There we go. Our services file is where all of the services that we're gonna use live and we pull in those services. This is essentially a Docker compose file on whichever stack we wanna use them for. So we've got a couple of different web servers. We've got either Apache or Nginx, our database options MySQL, Maria, Postgres, and then our CLI options, that's kind of where everything works, where PHP lives. And each of these settings can be overridden. So say we wanna use all of the good things about Docksal. But we want to use a different CLI image, a different PHP image. We can go into our project and I don't know if it's showing me opening this. No, OK, well. And go to the Docksal.yml, which is again Docker compose, add-in services, CLI.

And just because my memory is not as great to remember every character. Here we go. And to find whatever PHP image or whatever we want. And then when we run fin update, it will update it with that image that we've defined in this file. So like I said, highly customizable. And we do have different stacks to work with. If you want to have basically acquia out of the box, we've got all the services it depends on. If you're doing just standard HTML and don't need database. If you're doing a Node project. This one I find pretty interesting because, with the labels, which are just settings that we're setting inside the fin executable, you don't need to use port 3000 on the host. So you just spin up your node project, start your dev server and go to the domain that you you define and it just works. I did that the other day just testing something out and it kind of blew my mind. I figured I'd have to put in the port number. We also have Pantheon platform and all the stacks are extremely configurable to however you wanna set them up.

Any questions on the stacks before? Which way? There we go. OK, but why should we use containerized setup instead of normal composer NPM or other commands from the host? Anybody think of a couple of reasons? Wilbur, what version of PHP do you have on your host right now?

STUDENT:
You know, it depends on the project.

LECTURER:
Exactly.

STUDENT:
(UNKNOWN) you and you can specifically say which PHP.

LECTURER:
Yeah. Jack what version of Node are you using on your...

STUDENT:
On my local machine? None whatsoever. I only have (UNKNOWN) containers.

LECTURER:
You're a bad example. You you were supposed to say I don't know but...

STUDENT:
Andrew doesn't know. Does he?

LECTURER:
Yeah but yeah, it makes it reusable. One of the biggest problems I'm sure that we've all run into is, well, it worked on my machine or it was broke on my machine. Especially if you have somebody above you who doesn't realize how to use things. But this helps eliminate it by having a setup where you can make sure that all your developers, all your team are using the exact same. You each have PHP 8.1, you have the same version of Node, the same version of NPM, the same version of Ruby, if that's what you're into same version of Drush. You have all that because you're sharing the Docker files stacks and the containers across multiple developers. So we use containers because of reliability, because we don't have to worry about that, well, worked on my machine because all machines are now equal, portable. So, Jack, I'm gonna pick on you because you're sitting right there. So if you're... Is that a Gazelle?

STUDENT:
Oh, it is a Galago.

LECTURER:
Galago. OK. Yeah, I have one of those, too. So if your Galago fell into Lake Michigan and you had a project you pulled on a GitHub repo with the containerized set up how much time have you lost?

STUDENT:
Today is a bad day for me because I'm here. So two whole days.

LECTURER:
OK. If you didn't have containerized, you need to go through a brand new system. You need to make sure that you have your right version of PHP, all that stuff we just talked about, reproducible. If the environment is same on multiple computers, then multiple people are gonna run into the same problem hopefully, and because it's containerized, it only uses the resources it's needed instead of having a virtual machine for everything. Has anybody worked with projects where you had to have an entire VirtualBox for every single project that you working on that will eat up your hard drive, eat up your memory faster than you can think of? So we've been talking about Docksal lot. But let's look at why I put some slides out of order possibly. Let me just... OK, sorry. I accidentally duplicated a couple of slides. Pretend you didn't see that. Kevin, edit that out for me, please. So what about storage? Well, there are a few volumes that are automatically set up by Docksal and volumes are persistent storage that claim a spot on your hard drive.

There's also mounts that don't necessarily claim their own spot. They just piggyback on the spot that already exists with content or files in it. But the volumes that are set up are the CLI home, the project_root, and DB_data. So CLI home is where your actual OS for your containers lives. In most cases for Docksal purposes it's Ubuntu and it's useful in case we wanna customize the OS, maybe add some stuff to it that should persist if we're working on a long-running project and we don't want to, every time we shut it down, have everything disappear without removing the volume, you still have those settings available. The project_root is where the project folder lives. So if we go back to here, the project_root mounts to this session example folder. So everything that is in session example is in the container. So any changes that we make to any file in that folder will be reflected in the container. Nope. And DB_data. Any guesses on what that holds? Your database so you don't have to pull down a database every time from either hosting provider or if you're one of the lucky ones who has a full database in your git repository.

Alright, so let's get into the real reason that we're all here. This is the scenario that brought me to putting together all of this is we want a portable local dev environment to be shared across the number of developers. It needs to run and serve Drupal. It also needs to run and serve Gatsby develop, which is the dev server that when you run it, it's a Node.js server and it can also serve the built site of Gatsby and Drupal. And on top of that, it simulates a major hosting platform. Makes sense to everybody? Alright. So let's take a look at what we can do there and for this. Switch screens here. What does that say of that? Is it closing them down? No. So we're gonna start off with our Docksal.env file. And we can set quite a few things in here. Do I have to follow? For this, I'm gonna use an Acquia stack because it's the one I had uncommented, but could also use Pantheon, a default stack, platforms, or whichever stack you want to. This is just an environment variable that you set and Docksal does a rest.

And as we all know, not all Docroots are created equal. So it might be in web, it might be in Docroot, depending on what provider you're using, and a couple of other settings that you might wanna have in here are Composer Memory limit because Composer doesn't like me. Xdebug, I use that extensively, but I don't enable it because that'll just tank your performance. And if you wanna have custom images or different images than what we're... our default, we could set those in there as well. Now out of the box, Docksal will name your project whatever your project root folder is .docksal.site. But you can change that by just setting the virtual host environment variable there. Now where we really get into it is Docksal.yml. This is where we can really customize all the things. So I'm gonna yada yada yada my way to stage two. And you can see I've added a few things in here. So what I've done for this to work is we have the CLI, which as I remember is where PHP lives. But if you look at. I don't think I've changed anything here yet.

Click there. Where it has build, it's not pointing to an image from Docker registry or a Docker hub. It's pointing to the folder here and I took our base Docker file which exists in the Docksal set up. And I've added a couple of things that I know I'm going to need for a decoupled project. Mainly, every time we spin up this image, we're gonna have NPM, we're gonna have Node, the right version, the pinned version, so that all of our developers are gonna be using the exact same version NPM and Gatsby CLI because I'm spinning up against you see, so why not make sure that it's part of the image or the container as it's built? So you can customize the Docker file as well, not just the Docker-compose, You can add anything you want to, you could change the PHP version in here. If there are other things that you wanna add-in. As you can see, I've got a couple things here for testing. And my favorite alias because ls lh takes too long to type, so I just do LL. So when we do that, follow me. Go back to stage one fin.

That's fin project start with Stage one, which is going to have just the barebones set up for Acquia. But you can see... Well, maybe you can't see because it's very small. Smaller than I meant it to be. But for the Acquia stack, we're starting off with solar. We're starting off with Memcached as well as Varnish. And in addition to the three normal containers that we start with. So it's coming as close to an Acquia environment as I possibly can. So it spits out our URL down at the bottom mid-camp docksal site. And I installed it with Umami. I absolutely love this demo because it makes things so much easier and it's content so I don't have to think. But when we change it up to our additional stage two here. I'm going to run Fin up which updates the project. So if you're paying close attention, we've added another container here, decoupled preview. So that's gonna be our preview for our Gatsby dev setup. But we want them to run together so they're not all gonna be on mid-camp.docksal.site.

So what I've done here is in our service, sorry docksal.yml, I've added the web server is going to have its own CMS, that virtual host, and we can define that like I did in the Docksal environment. And our preview is going to be preview.Virtual_Host. So our Vue proxy on the system service. It just going to make that work. So now if we go back over here. Do a quick refresh. It's gonna be missing because we removed the domain. I point that out because I forgot I moved the domain and I spent way too long yesterday trying to figure out what the heck was going on with this demo. Well, there we go. And now I haven't. So I don't think I have. I haven't quite set up the Gatsby and this stage of it, but we have things available for it. So if we go to Preview, bad gateway because it's seeing that the project exists, but there's no node server serving it. So the next step to this is really to finish it up, I'm going to head over to stage three. Switch screens once again. And I've added a couple more things here.

One is going to be static because when at least with Gatsby, I can't speak. I'm pretty sure that other front ends do the same. But with Gatsby it generates a static site. It just serves the HTML. So I gave it just for fun. I put it on Apache where our web server for the Drupal site is on Nginx. So I've got two different web servers running two different domains and they're working side by side. I also added our... so with that static container simply just added the static hostname, the service. Gave it access to the project root which is where... Sorry. Words are hard from switching, moving my head back and forth. The project root, which is where our project lives gave it that label, the virtual host. And then where is that? And just set the Apache document which is, it tells it to look in the public folder. And right now since I haven't built there's nothing there for it to load up. Any questions so far? Anything I can clarify? Yeah?

STUDENT:
You have a Docker file, you've got Docksal directory?

LECTURER:
Yes.

STUDENT:
How did you get that? Sorry if I missed it. Is that generated by Docksal? Where did that come from?

LECTURER:
I made it. So on the docker file. And make sure it's pulling up. There we go. So the first line there from Docksal/CLI PHP?

STUDENT:
Yeah.

LECTURER:
I'm taking everything that Docksal has and adding my own on top of it. So we get everything that's in the default Docksal/CLI container with the addition of and it does come with node on the default one, but I don't know which version which are and that could change if you change versions or if you don't have it pinned to the 3.2, if you just have three. So I pinned it to 16.13 and then to call that, good call out that I didn't show that instead of I just got a four.

STUDENT:
Why nine? That's the build.

LECTURER:
Oh, yeah. I was gonna pull up one of the default stacks and... Yeah. Instead of having an image, just one showing up instead of having an image directive here like we do in the default stack, we're just saying that we're going to use or instead, we're going to build it and name our image, whatever we wanna name it. So I've got the project name CLI. We're also extending the CLI service, so that's why we don't have to have everything in the CLI here, which is quite a bit. We're just overwriting the parts of it that we need. And according to Apple Dictionary, CLI is an abbreviation for cost of living index because I press down too hard. In case anybody was wondering. So all of these are already part of it. We're just extending on it, kind of like extending a class or service in PHP.

STUDENT:
It knows to look there.

LECTURER:
Yep. Because we tell it to. Right here where we're saying, look in the file, or Docksal/Stacks/Services for the service CLI.

STUDENT:
Yeah.

LECTURER:
And then whatever is different here, that's what we're gonna overwrite. Does that clarify?

STUDENT:
Well, no, I understand that. I guess I'm just to understand how it knows to look at the Docker file in your .docksal directory file.

LECTURER:
That is the build line here. Project_Root.Docksal/Services/CLI. So you don't have to actually put in Docker file on that. It'll just look for Docker file in that folder. But it lives in the project. Not really...

STUDENT:
OK. So it's the build.

LECTURER:
Yeah. So and you can do this with any or you can extend out Docker files for any of the services, even if you wanna create your own completely. Well, I wouldn't say from scratch because that would be a pain in the butt to go from scratch. But which is another thing if you don't know the base Docker images of all Docker images is scratch, which is pretty much blank and you have to do from scratch. So Eric, did that clarify?

STUDENT:
Yes.

LECTURER:
OK. I went to stage three, I believe. So we're gonna thin up.

STUDENT:
Did you manage to solve the problem of pending chromium?

LECTURER:
No, I didn't even know that was an issue.

STUDENT:
I've had issue with that in the past with previous X selenium-based stuff.

LECTURER:
I think I remember something about it, but I haven't actively done anything to try and handle it. Alright. So stage three. Now you can see that our static is up, our preview, our web, everything has been spun up here. So I'm going to just because it's always safe Drush cr.

STUDENT:
(INAUDIBLE).

LECTURER:
And so in theory. What should happen is I can go to our CMS page. Our preview isn't gonna work because we don't have anything there and we should see similar with static. OK, so there's nothing there, which is why it's forbidden, but it's actually pointing to something. So first thing I'm gonna do, head back into VS code and run. Fin Gatsby.dev. Now this. Another nice thing about Docksal is that you can add as many commands or custom commands as you want, and they're all written in BASH. So let me open that up. And I apologize, I thought that the folders that I was opening on my screen were also opening there, and I didn't pay attention. So sorry about that. But under the commands, all these are custom commands that I've had for one reason or another and added in here and one Gatsby Dev and all it does is that we're running in the preview container rather than the CLI or web and telling it go into the Gatsby folder and run Gatsby develop and run it on this host, That's a Docker specific thing so that it's accessible to the outside world.

So when I run that, crossed fingers, toes, and eyes that it works. So this step always takes a little bit. While we're waiting that everybody know what they're grabbing for lunch downstairs.

STUDENT:
Food.

LECTURER:
Good call. I'm also having food.

STUDENT:
Here's a question for you.

LECTURER:
Yeah.

STUDENT:
Is there... I see you're having two separate web instances in the same command, which makes sense when you're doing a decoupled that one goes to the other. Is there any difference between doing two different Docker or Docksal instances running at the same time?

LECTURER:
You can, but it depends on... good it's going. It depends on your use case. For this one, I specifically did a monorepo. When you do two different Docksal instances say you have one specifically for Node and one specifically for Drupal. If you want it to be completely separated out, then there is a few other steps that you might need to take to make sure that your Drupal instance can effectively communicate with your node instance. Like in this the hostname from one to go to the other. And this is getting a little bit into Gatsby. It'll open Gatsby.

STUDENT:
Well, we do this kind of thing, too. Like, we've got Drupal portals that do like rostering and test launching for Tor test runners. And we've got the Tor project in its own Docksal project and then the Drupal project and its own Docksal project. As long as it's like web to web, those will communicate just on Tor.Docksal.site. What we did have problems with though, was trying to get in one of our testing platforms we have an intermediary data warehouse that wants... the Drupal site wants to talk to databasewise and I have not yet figured out how to make my one project hit the database in another project, just the database. I haven't been able to make that work yet.

LECTURER:
Yeah.

STUDENT:
In fact, I think we were slacking about that.

LECTURER:
Probably. Yeah.

STUDENT:
I remember why I asked because in production is your Gatsby server gonna be on a different server and let's say configuration that Drupal website. So like we have one hosting service here and we have one hosting service here.

LECTURER:
So one project that I've seen it done both ways in one project that I've worked on did it so that it was a monorepo and we set up Gatsby Cloud to look only at the Gatsby folder in the project root. So instead of looking at www, it looked at the Gatsby folder and it still had everything there, which is why I kind of simulated an Nginx thing versus Apache here. Another thing, if you're using two different stacks or two different apps internally, they can use the host name that you define within the same stack. So if I wanted to ping.CLI, it would just be CLI. But if you're doing it externally, which would be Docker to Docker separate applications, you'd have to use the full domain to because it'll have to go out of the container back then. Alright. So it looks like we've got to build or at least a preview. Let's go back here. Yeah, we've got to guess, we say. Now, we've also got one of the things I love about Gatsby 404 page is it just gives you everything. And so this is pulling all the data from Drupal, from the umami.

STUDENT:
Very cool.

LECTURER:
And then finally, the last piece of the puzzle. Just to simulate the fully built project. Hopefully, it doesn't take as long because I'm starting to get hungry myself. Then Gatsby build which is again one of those custom commands that I have. But it clears out the cache. Clears the public folder and then runs a build. And unfortunately, because I did clear out the cache, it does take a little bit of time to rebuild those files again. But I've had it ingrained in me since starting with Drupal, that you clear the cache or you die. While reading on that, another nice thing that having this is specific to Gatsby. I know I said I wasn't going to do getting too deep in the Woods in Gatsby. But I can scroll up just a little bit here, it also gives you your graphical IDE, so if you're familiar with that, it's basically the query builder for Gatsby for anything GraphQL. So it'll help you get into the JSON API and then decide how you wanna get the data from there. So you still have access to that by going to the preview site.

And three underscores. Three underscores. Three underscores. I say that because I spent way too much time wondering why it wouldn't work when I only had two underscores. It's not showing there, but we are moving. OK. So now there we go. And now we've got this is the static site that is being served from the Apache server. So any questions? Any comments, Concerns, Insults? I'd be more than happy to answer before we go back to the slides.

STUDENT:
I have a quick question.

LECTURER:
Yeah.

STUDENT:
If we knew the Gatsby where is a good place to get started?

LECTURER:
The Gatsby docs have some really good demo or tutorials on how to get started with it, but what I would recommend is do you know, React?

STUDENT:
Sure.

LECTURER:
OK, because I wouldn't tell you to learn Gatsby without learning React. It was just like I wouldn't tell you to learn jQuery without knowing at least JavaScript or some...

STUDENT:
OK.

LECTURER:
But yeah, gatsby.org or Gatsbyjs.org the open-source site has some really good docs and they've got a good discord and a presence on a lot of the different slacks. Alright, so since we did a live demo, I set the bar pretty low, but so what was the point of all this? Again, I mentioned this before, but Docksal and Docker make it easy to configure local dev environments without a lot of time or effort. Granted, I had them all pre-made, but the time... most of the time that I spent making them was downloading the images on hotel Wi-Fi. So I saved you all that headache of having to watch those images get pulled. And if we wanted to say we want to change a version of PHP, it's as configurable as going into our Docksal.yml change it here or it's hard to,,, services is on, Docker file. Change it downgrade to 8.0. Run fin up. It'll pull down that image instead and you have a different version of PHP. So if you want it, if that comes in handy, especially with Drupal making sure that you have all the typing done correctly for 8.1 where if you have custom modules that don't have that done, good luck because that can be a headache.

But I digress. But yeah, two-line changes. 30 seconds later, you have a completely new version of something that can be shared out containerized, you can share it out. It doesn't use all your system resources and reproducible. That's a big thing. So what all did we accomplish here? Well, all the things. We got a local environment that mimics production mimics Acquia created containers to separate Drupal Gatsby dev and a static site. So we had the static HTML. One of the nice things about Gatsby is it's lightning-fast. You saw how fast that page loaded. And we made some memories along the way. Any questions? Alright, so thank you all for coming. I appreciate you stopping in for this. If you're interested in the GitHub repo, GitHub/jddoesdev/decouple-docksal-demo because I really like alliteration apparently. I haven't updated it with my latest changes, but if you'd like to take a look, it's there and there's nothing else. Go eat. Get out.

STUDENTS:
(APPLAUSE)

LECTURER:
Thank you.

STUDENTS:
(APPLAUSE)