Been a while since an update, but I haven't dropped off - I've been doing mixes of "work" work, projects, and learning. Rust is awesome, and should be used wherever C++ or C would otherwise be used, and more.
Jul 29 2019, Monday (written Tuesday)
Tonight, having finished last week the ability to add a spouse, thereby carrying the genealogy web app into a workable product, I run into issues setting up the Docker container. I know most of it, but the new bit for me was adding a custom network. Somehow, I was still getting bad gateways when attempting to access the site from outside. It was working when I exposed an explicit port to the container that my app ran on, so I had that assurance. When accessed from a public URL, another problem I was seeing was continuous redirects to itself. I decided to quit and resume the following night.
Jul 30 2019, Tuesday
Success! My Docker setup works, public https://genealogy.jvd.site working (with a super-secret password, sorry).
My main problem, causing a 502 bad gateway error, was that the container wasn't accessible on the correct network for nginx-proxy to access it, and this stemmed from my assumption that the
--network option to
docker run didn't have a default of "bridge" - the default network required for nginx-proxy to be able to talk to it. I wanted to put the Arangodb container and the Genealogy-app container on their own dedicated network, for security and organization. The app could talk to the database, but not to the external nginx-proxy container. My first attempt that seemed to work was to add
--network bridge after my first --network option, but while this made the app accessible, it failed to talk to the database. More research on Stack Overflow revealed a super-annoying deficiency in
docker run - you can't start a docker container with more than one network! I was able to
docker network connect the container to the network after it started, so my app could be connected to the "bridge" and to "genealogy-network". I must say,
docker exec -it genealogy-app sh was very helpful for inspecting the situation - I think I'll keep using that method to enter my always-running "dev-arch" container (My bare metal OS on my server is CoreOS/ContainerOS, because it automatically updates and just runs docker containers).
After release, I then proceeded to optimize the load time with a compression middleware and an earlier check for authentication before using
React.lazy() to load the rest of the app.
Jul 31 2019, Wednesday
Today, I discovered that my favorite backup tool, Borg Backup, works pretty well when run using "sudo" when the repo's location is specified as an "ssh" location on either another computer or the same one. For me, this is great because some of what I need backed up could only be read by root. Now with a backup solution for my services, I feel quite a bit better about the safety of my setup.
Since I'm not sure how to best store keys safely, I've resorted to entering the backup key password, along with my ssh password, every time I run the backup.