Over the past month, I started rebuilding the Raspberry Pi Dramble project using Kubernetes instead of installing and configuring the LEMP stack directly on nodes via Ansible (track GitHub issues here). Along the way, I've hit tons of minor issues with the installation, and I wanted to document some of the things I think turn people away from Kubernetes early in the learning process. Kubernetes is definitely not the answer to all application hosting problems, but it is a great fit for some, and it would be a shame for someone who could really benefit from Kubernetes to be stumped and turn to some other solution that costs more in time, money, or maintenance!
Recent Blog Posts
I've used Macs as my primary computing devices my entire life. And though I continue to use a Mac for my primary workstation for both work and personal projects, my use of computers has evolved in the past few years quite a bit. With more of my stuff moving into the cloud and fewer software applications being exclusively tied to macOS or Windows, it's given me more freedom to do some amount of work from a tablet (currently iPad Air 2), Mac (currently 2015 (work) or 2016 (personal) MacBook Pro), and even my old PC laptop (a Lenovo T420 that I used mostly for testing).
After lugging the T420 with me to an open source conference a couple weeks ago, I decided I'd finally go ahead and acquire a modern, Ultrabook-style Windows laptop, and looking around at options for an open source developer more comfortable in Linux than Windows 10, I narrowed it down to:
June 6, 2018 Update: I've also posted a video of the SSD replacement process, embedded below:
I recently purchased a used Dell XPS 13 (model 9360), and I chose to purchase the base option (with 128 GB SSD) since it was cheaper to do that and upgrade the SSD to a larger model (500 GB) aftermarket than to buy a higher model XPS (I bought this model: WD Blue 3D NAND 500GB PC SSD).
One pattern I often need to implement in my Ansible playbooks is "configure-reboot-configure", where you change some setting that requires a reboot to take effect, and you have to wait for the reboot to take place before continuing on with the rest of the playbook run.
For example, on my Raspberry Pi Dramble project, before installing Docker and Kubernetes, I need to make sure the Raspberry Pi's
/boot/cmdline.txt file contains a couple cgroup features so Kubernetes runs correctly. But after adding these options, I also have to reboot the Pi.
If you just add a task like
command: reboot (run with become/sudo), you might run into this annoying error during a playbook run:
I started Hosted Apache Solr almost 10 years ago, in late 2008, so I could more easily host Apache Solr search indexes for my Drupal websites. I realized I could also host search indexes for other Drupal websites too, if I added some basic account management features and a PayPal subscription plan—so I built a small subscription management service on top of my then-Drupal 6-based Midwestern Mac website and started selling a few Solr subscriptions.
Back then, the latest and greatest Solr version was 1.4, and now-popular automation tools like Chef and Ansible didn't even exist. So when a customer signed up for a new subscription, the pipeline for building and managing the customer's search index went like this:
Original Hosted Apache Solr architecture, circa 2009.
A question which I see quite often in response to posts like A modern way to build and develop Drupal 8 sites, using Composer is: "I want to start using Composer... but my current Drupal 8 site wasn't built with Composer. Is there an easy way to convert my codebase to use Composer?"
Unfortunately, the answer to that is a little complicated. The problem is the switch to managing your codebase with Composer is an all-or-nothing affair... there's no middle ground where you can manage a couple modules with Composer, and core with Drush, and something else with manual downloads. (Well, technically this is possible, but it would be immensely painful and error-prone, so don't try it!).