Showing posts with label containers. Show all posts
Showing posts with label containers. Show all posts

Thursday, April 30, 2026

Using Uptime Kuma to Monitor My Systems

I've been curious about monitoring systems and didn't want to use something overbearing, such as Zabbix.

One reason that I monitor the r/docker subreddit is because I sometimes see folks posting about the containers and tools that they use.  Someone posted about Uptime Kuma recently and I examined it.

I LOVE DOCKER because it's super easy to deploy tools such as Uptime Kuma and test them.  I was able to deploy Uptime Kuma within minutes and loved what I saw.

I'm now using it to monitor all my tools, mainly my LAN containers and servers, as well as my external containers and web servers.  As well, I'm monitoring to ensure my SSH ports are up and connectable on my Linode host (and the port that I use to shell into my home system that has a port exposed to the internet).

I even tested different versions of Uptime Kuma.  I love that it's simple yet is also capable.  I don't want to mess with agents and I can monitor my systems with Uptime Kuma without using agents.

Saturday, March 21, 2026

My Linode Web Server is Now Serving Both Domains, Utilizing Containers!

I got a bit bored today and felt that I could tackle testing a Docker container to leverage Let's Encrypt SSLs.

As usual, I wanted to leverage AI and, since I had major success with little problems with Gemini last go-around, I used it again.

The First Domain:

I started with wigglit.com.  As I already had a compose file to work with and I'd previously tested running containerized Wordpress on the Linode, it was a rather easy start.  I shared the file with Gemini and ask what needed to be added/changed.  The compose file enabled an Nginx-based sidecar to handle SSL termination (and the domain was already set up for use).  That was the biggest change.

Well, when I tried to access the site, I couldn't - I was geting "502 Bad Gateway" errors.  As well, SSL was not working.  I checked the logs and saw many 404 errors, not just from my public IP but from other IPs, too.  I'd copied over a pre-existing copy of the Wordpress site and I think some permissions were borked - the new compose file didn't like something within my new workspace.  I found that the file ownership and permissions were jacked, and even after sorting that out, I still had issues - while the gateway errors were resolved, and I could now see server code 200s in the logs, the pages being served lacked content (they were blank).

Instead of waiting for Gemini to further help with this, I decided to just create a new workspace but without the copy of the Wordpress content I was previously using.  I started from scratch, to test.  Well, the test worked. I immediately got the Wordpress setup page, and I set up a quick default page, knowing I was just going to retrieve an offsite backup (yes, I keep backups).  It took maybe 15 minutes to get a recent copy of the site (minus a week of data).  And, on top of that, SSL was working!

So, the Wordpress site is now running, as a container, and using SSL.  It's not like I hadn't done this before, but when I last had things containerized, it wasn't leveraging an SSL.  As well, I was running two domains through Apache and didn't know how to run both using a container.  When I'd run the container, it would get in the way of running the other site using a different domain.  While I'd discovered how to run both outside of Docker, I was still researching if I could do it with Docker.

The Second Domain:

My other domain is unixfool.us.  It it a plain static website with very old content.  I use it mainly to archive and share photos.  As it is just sharing pictures, I don't really need it to leverage SSL.  Eventually, I will enable SSL with that domain, but for now, I just need it running, 

I gave Gemini instructions to leverage the same compose file to get unixfool.us to serve pages, via basic HTTP.  Gemini gave me an updated compose file so that I could leverage that Nginx proxy with unixfool.us, even via port 80.  This one was easy, as all I really had to do was point the compose file to where the website content was located on the server.

Gemini screwed up at this point, though.  I'd asked it to give me the updates to the existing compose file that would enable unixfool.us to work.  It actually changed login credentials for Wordpress, in addition to giving me what I asked.  I had to compare both files to see the discrepancies, but I also had a hint, because I'd tried to run the compose file and saw some DB errors - I suspected credentials had changed.  This is why it's important to always check AI output - never fully trust it.  Trust but also verify.

After I fixed the credentials, I was able to access both websites while both were running as Docker containers.  The sites are fast!

I do have a question about the SSL certificate, though.  It expires in 3 months.  With the old setup, I had a cron job running that was supposed to renew the certificate before it expired....that setup was before the new setup that leverages Docker.  I think all I have to do is restart the container sometime before the 3 months expires, but I'm not sure.  I may have to research further about this (or I can just test this out next week - checking to see if the cert is recreated when I shut down and restart the container, keeping track of the "issued on" and "expiring on" dates).

This project was fun, though...seriously!

UPDATE:  I researched the certificate renewal and the https-portal (the reverse proxy) container actually runs a cron job that periodically checks the SSL expiry and will renew the certificate 30 days before expiration.

UPDATE:  I ended up going down a rabbit hole of remediation issues, as the unixfool.us site wasn't allowing viewing of the images (fixed with an .htaccess entry); also had an issue where Wordpress wasn't allowing uploads of images bigger than 2 MB, which took a LONG time to remedy, as AI kept giving me the wrong suggestions (both Gemini AND ChatGPT) - I ended up conducting a Google search to find the answer.  Again, I had to add environment variables to the .htaccess file in the folder where the wp-config.php resides, but even so, the docker instance of Wordpress doesn't allow large pixel sets - I had to adjust the file size to reduce the pixel count.

UPDATE:  Annnnnd...I thought I was done but found that the image I was using (was using wordpress:latest) was using an older version of PHP (v8.2).  Wordpress was showing it as a security issue.  Instead of waiting to be hacked, I decided to see if the official Wordpress Docker repository had an image with a later version.  I tried version php8.4-apache, which got rid of the security alert, then I saw that there was an image for php8.5-apache, which I settled on.  I'll watch to see if this image is problematic.

UPDATE:  In conducting next-day checks, I noticed that 2FA stopped working (I'm using native 2FA).  I had to disable it and then re-enable it, which meant I had to re-enter the QR code in my authenticator app.  This was a bit annoying to see occur, because it meant that my account didn't have 2FA the past 12+ hours, but it's fixed now.

UPDATE (3/31/2026):  I've created a few posts now and have noticed that the website is posting a lot faster than it was before I containerized it.  I didn't do before and after performance checks, sadly, but it's definitely faster.

Sunday, February 09, 2025

Pihole & Docker FTW!

I'd been planning to mess with Pihole but didn't want to mess with a Rasberry Pi.  I did some research and found that I'd the option to install Pihole on a running Linux system.  While looking at what that entailed, I also found that I could easily do it with Docker, too.

I've been running a Ubuntu system for a while now.  It is mainly a box I set up for use with NextCloud.  I hate NextCloud and stopped using it and the Ubuntu system.  The system was pretty much idle until I decided to set up a Wordpress instance in Docker for development of my Wordpress site that's on my Linode instance.  Whenever I'm trying something new in Wordpress, I test it on my Dockerized Wordpress instance first.  Eventually I'll work on replacing the Wordpress instance on my Linode host with a Dockerized instance.

Since I already have Docker set up on the Ubuntu box, I decided to give Pihole a spin in Docker.

I used this website to set up Pihole in Docker.  The whole setup was quick and painless.  In fact, my Wordpress setup uses three different Docker containers, and with Pihole now running, I'm now using four containers on that Ubuntu host.  None of them are consuming resources (thus far).

I'm now testing Pihole.  I'm totally unfamiliar with it but it doesn't appear to be a high maintenance setup.  At some point, I'll want to back up the Pihole configs, though, so I won't have to spend a lot of time setting it up again (when/if I end up blowing away the instance).

I've several hosts on my LAN using the Pihole setup and my daughter is trying it, as well.  She had a Rasberry Pi and was planning to install Pihole on it, but I told her that this is far simpler - she should use the Pi for something else, IMO.

I've added some ad lists (block lists and some whitelisting), as well.

The biggest pain as far as adware goes is Youtube, and I don't think Pihole is going to be able to block Youtube ads when using the Youtube app.  I've had some luck blocking Youtube ads on my Macbook, but I view videos on the browser when using that notebook (and I've the uBlock Origin browser extension installed in MS Edge).

Wednesday, June 19, 2024

Docker, Wordpress, and Linode

Maybe a week ago, I decided to refresh my Linode instance.  I'd been using Ubuntu 16.04 LTS on it the past 10 years.  16.04 has been unsupported for quite a while now, but I was being lazy while still watching the server for possible compromises (the server was locked down very well).

Initially, I'd planned on a slow rollover to Ubuntu 24.04 LTS, by deploying a new host and slowly migrating over to it from the old server.  One day, I just said, "fuck it" and started from scratch.  I kept my old disk volume and mounted it to the new host so that I could grab old data whenever I needed it...having config files from the old host would help me when reinstalling the software I was using on the old host.

The plan was to migrate my two Wordpress sites to the new host but today I tried running Wordpress on Docker on an old Dell XPS 8930 and it worked well.  I first tried to just get to the point where Wordpress could install onto it.  I then tried to restore a backup of one Wordpress site onto the Dockerized Wordpress instance and I was immediately successful.  It happened so quickly that I spent the rest of the day testing it, to the point that I decided to do the same thing on the 24.04 server tonight.  It's now up and running and I've already been posting to it.  I'll monitor it the next few days and will probably back it up, tear down the whole thing, and then try some different setups, such as trying to run both Wordpress sites from one set of containers (the problem is, I need both Wordpress sites to be serving on port 80 and there's only one port 80 on the server.

Currently the setup is using three small containers (one for MySQL, one for Wordpress, and one for phpmyadmin).  I leveraged the YAML files of two other nerds, using both to build my own YAML file, which I used to pull the images and configure the containers.  I ran in to issues more than a few times, but between what I learned last year on acloud.guru and trial and error, it wasn't all that difficult.  What I haven't done (YET) is build my own dockerfiles.

I usually also use the Linode host as a file server (sharing pictures with friends and forums), and I was doing that using Apache, so that's a 3rd application that I'd need to use port 80...not sure how I'm going to set all this up, but the neat thing about Docker is that I can blow it away and start over (keeping my .yml compose files to work with and tweak), again and again, until I get it right.

This was the first time outside of training that I used Docker and I honestly should've been using it a long time ago.

I actually had a lot of fun doing this.

UPDATE (7/28/2024):

I'm having some issues trying to determine how to host two sites on one Dockerized Wordpress setup.  I can probably use the muti-site Wordpress setup but I need to study up on how to alter the wp-config file using the docker-compose.yml file.

Or, I can probably just run two Docker setups, one for my firearms blog and one for my car blog.

I also want to be able to share my many pictures and files using Apache, but found that I can't run Apache AND Worpdress, as both use port 80.  I may have to use some type of proxying.

Lastly, I can just reinstall Wordpress in a non-Dockerized fashion, while experimenting with Wordpress in Docker.  This is probably the more reasonable approach, as I can study up how to leverage Docker at my own leisure but have a production (and native) Wordpress setup.