Out with the old, in with the new. My old website, that used a Python CMS and ran on Apache on an older version of Debian, is out, and has been replaced with WordPress and Docker containers running on a newer version of Debian 10.
Boy, that was a process; deploying Docker containers in production without proper verification can be challenging.
Just because something works great locally doesn’t mean it will on a production server, and I learned this the hard way.
How I Did It
I had to reinstall my OS: Debian 10. I quickly became apparent software for Debian is older than what is available for Arch Linux, where I tested my Docker containers.
I did quite a bit of set up on my local machine, before copying it to my server and using docker-compose to launch my containers.
After that, there was tweaking to various different configuration files for my web server, nginx, and for WordPress. Setting a hostname for my main container inside my docker-compose.yml file seemed to help things.
Other than that, the work I’ve performed has been minor fixes to the look and links.
What Happened
Issues I Encountered
Older Software
Despite having a recent LTS Linux distribution, it doesn’t mean that the packages will be up to date, as much as I am used to on Arch Linux. I had to grab the latest docker-compose, and add Docker’s apt repository.
Not being able to fix a problem in Apache’s config files
I had trouble getting the server to forward requests to my Docker container. My frustrations eventually led me to use nginx instead, partly due to syntax. I also had the same issue with nginx, but in hindsight, I think the container was causing the problem, not the web server.
Browsers Insisting on Redirection
This was a problem on Firefox on X11, and Chrome on my Android tablet. They both have a persistent cache that if the initial server response says to redirect, the browser will remember this. I’ve had to clear by browser cache a few times during testing to verify that my web server is working correctly.
What Next
Sadly, I didn’t backup my git repositories stored on my server. I may publish some code to remedy this loss. I might do some tutorials, and publish pictures.
What would you like to see? Let me know in the comments below.
2 responses to “Re-doing my website: How I Did It, and What Happened, and What Next”
>Modernising
>Ancient Linux, Nginx, [Mysql], Php/wordpress stack
>Using docker in the 2020s
I guess you have a microscopic performance gain for using LEMP (nginx) instead of LAMP. Why not do the full time warp and bring back perl instead of php? I guess your website still functions without javascript, so I shouldn’t look a gift horse in the mouth.
What about running arch still (or a cooler distro (or os)), and using LXC with a configuration script instead of docker (or its allegedly user friendly porcelain, LXD).
What do you think about just providing tarballs of your projects, when you don’t need anonymous git contributions?
I bet if you published a layman user walkthrough to fftw3 you would get a whole bunch of hits / plagiarised to heck and back by other bloggers.
I just went with what was available or familiar to me at that time.
If I decide to share source code in the future, I would probably do so through a git repository, as I have before.