The kernel of my home office

13 years ago, I spent a few weeks rebuilding my garage, as documented on this blog . At the time, I chose the less expensive clear plastic roofing tiles, because I wasn't really convinced the project was going to work and I imagined I'd have to tear it all down and replace it with a real garage in a few years. But sure enough, some projects last a lot longer than you expect, and it's still there, more due to benign neglect than any plan. Here are a few photos to give you an idea of how it's weathered the time. "Post-apocalyptic" is a good description. Of course, 13 years is a long time, and in the interim, my 5 year old is now 18 years old, and bigger, stronger and in some ways smarter than I am. He's off to university in the fall and had a gap in his summer employment, so I've employed him to fix it up. I'm looking forward to the outcome as well as the process.

In my previous posts, I've provided my rationale for making use of Docker and the microservices model for a boutique-sized Drupal + CiviCRM hosting service. I've also described how to build and maintain images that could be used for the web server (micro) service part of such a service. The other essential microservice for a Drupal + CiviCRM website is a database, and fortunately, that's reasonably standard. Here's a project that minimally tweaks the canonical Mariadb container by adding some small configuration bits:  https://github.com/BlackflySolutions/mariadb That leaves us now with the problem of "orchestration", i.e. how would you launch a collection of such containers that would serve a bunch of Drupal + CiviCRM sites. More interestingly, can we serve them in the real world, over time, in a way that is sustainable? i.e. handle code updates, OS updates, backups, monitoring, etc? Not to mention the various crons that need to run, and how about things

In my previous two posts, I provided some background into why I decided on using containers for a boutique Drupal + CiviCRM hosting platform, and why Docker and its micro-services approach is a good choice for building and maintaining containers. Although I promised to talk about orchestration, that was getting ahead of the story - first I'm going to look at the challenge of keeping your application containers up-to-date with OS and application-level updates. There's a fair amount of work in that, but the tooling is mature and there is lots of good documentation. A great place to start is to visit the official Drupal docker hub page . From there, you can pull a working Drupal code container, and it gets re-built frequently with all the OS and Drupal-code updates, so you just refresh your containers whenever you want (i.e. whenever a security release comes out, or more often to stay up-to-date). A nice thing about that project is that it demonstrates a technique for mainta