Browse Source

Added notes on backups and upgrades.

main
James Harmison 2 months ago
parent
commit
3c6adb34e3
Signed by: jharmison GPG Key ID: 32383B2D27A5D4B5
1 changed files with 42 additions and 0 deletions
  1. +42
    -0
      README.md

+ 42
- 0
README.md View File

@ -107,6 +107,48 @@ The use of the `podman-docker` package for your distribution or a simple `alias
Use of the scripts from the `podman` directory will create pods, instead of containers, and you will not have to expose the database and can refer to it by `127.0.0.1`.
## Backup and restore
I use something like the following commands to make backups for my deployment (I use podman, and I relabel for SELinux shared usage of volumes):
```shell
mkdir -p ~/backups
for volume in akaunting-data akaunting-db; do
docker run --rm -v $volume:/volume -v ~/backups:/backups alpine tar cvzf /backups/$volume-$(date +%Y-%m-%d).tgz -C /volume ./
done
```
In order to restore those backups, you would run something like:
```shell
backup=2021-01-26 # you should select the backup you want to restore here
for volume in akaunting-data akaunting-db; do
docker run --rm -v $volume:/volume -v ~/backups:/backups alpine sh -c "rm -rf /volume/* /volume/..?* /volume/.[!.]* ; tar xvzf /backups/$volume-$backup.tgz -C /volume"
done
```
## A note on upgrades
The upgrade between 2.0.26 and 2.1.0 broke some things due to a Laravel version migration in Akaunting. In order to fix this, I ran something like the following:
```shell
docker exec -it akaunting bash
```
Then, inside the container, ran the following:
```shell
php artisan view:clear
```
I can see the possibility that future version migrations might require something like:
```shell
php artisan migrate --force
```
I do not intend on baking migration logic into the container image. In my view, the application containers should be dumb and naive. An upgrade between versions that requires intervention would best be encapsulated in something like a [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/), rather than adding to the complexity of the application image. If you use these images in production, I would recommend a testing environment that draws automatic updates and validates the steps required to migrate between versions, and pinned version number tags for your production image. Migrating your production version would then require manual intervention and enable you to take the manual steps necessary to complete the migration.
## Building your own
If you don't want to pull my image, or you've made changes to the code and would like to build your own, `build.sh` is provided at the repository root. You can run it with the `-h` option to see the provided options. You could modify `docker-compose.yml` or `podman/common.sh` to point to your own image if you would like to use the rest of the automation provided here.


Loading…
Cancel
Save