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.
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 the 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.
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 update 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 when reaches the 30 day mark.
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 using Google 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.
No comments:
Post a Comment