Skip to content

Commit

Permalink
read me
Browse files Browse the repository at this point in the history
  • Loading branch information
@denisdulici
denisdulici authored Jan 29, 2023
1 parent e80ca66 commit 863d9b4
Showing 1 changed file with 14 additions and 55 deletions.
69 changes: 14 additions & 55 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -8,12 +8,6 @@ This repository defines how the official Akaunting images are built for Docker H

Akaunting is online, open source and free accounting software built with modern technologies. Track your income and expenses with ease. For more information on Akaunting, please visit the [website](https://akaunting.com).

## Prerequisites

1. docker-compose, or the knowhow to use docker or podman to run these images.
1. You'll need to use some other reverse proxy for TLS termination. HAProxy, Nginx, or Apache work fine and have integrations with [Let'sEncrypt](https://letsencrypt.org/) that let you request wildcard certificates. See [Reverse proxying for TLS termination](#reverse-proxying-for-tls-termination) for more information. Reverse proxies are all trusted in these images to support use cases like [Kubernetes Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
1. Your own cache, if you need to scale to lots of users. Memcached and Redis are popular choices. See the [configuration for cache](https://github.com/akaunting/akaunting/blob/master/config/cache.php) and [redis](https://github.com/akaunting/akaunting/blob/master/config/database.php#L128) if necessary. You can provide the variables for configuration via [run.env](env/run.env.example).

## Usage

```shell
Expand All @@ -36,64 +30,29 @@ docker-compose down
docker-compose up -d
```

Included is a [watchtower](https://containrrr.dev/watchtower/) container. This will automatically pull updates for the [MariaDB](https://hub.docker.com/_/mariadb) and [Akaunting](https://hub.docker.com/akaunting/akaunting) images daily, restarting the containers with the new images when there has been an update.

## Backup and restore

You could use something like the following commands to make backups for your deployment:

```shell
mkdir -p ~/backups
for volume in akaunting-data akaunting-modules 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
```
> Please never use `AKAUNTING_SETUP=true` environment variable again after the first time use.
In order to restore those backups, you would run something like:
If you have a database cluster you can take advantage of the following environment variables:

```shell
backup=2021-01-26 # you should select the backup you want to restore here
for volume in akaunting-data akaunting-modules 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 in existing deployments due to a Laravel version migration in Akaunting. In order to fix this, you could have run something like the following:

```shell
docker exec -it akaunting bash
# In env/run.env put:
DB_HOST_WRITE: "example-write"
DB_HOST_READ: "example-read"
```

Then, inside the container, the following:
You can use Redis with Akaunting for performance enhancement and scalability, if you have a Redis you can take advantage of the following environment variables:

```shell
php artisan view:clear
```

Future version migrations might require something like:

```shell
php artisan migrate --force
# In env/run.env put:
REDIS_HOST: "example-redis"
# Switch cache driver to redis
CACHE_DRIVER: "redis"
# Switch session driver to redis
SESSION_DRIVER: "redis"
# Switch queue driver to redis
QUEUE_CONNECTION: "redis"
```

Application upgrade/migration logic is not baked into this application image. 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, it is recommended to have a testing environment that draws automatic updates and exists so that you can validate the steps required to migrate between versions. Your production deployment should use pinned version tags, which are tagged based on the Akaunting release. Migrating your production version would then require manual intervention and enable you to take the manual steps necessary to complete the migration.

## Reverse proxying for TLS termination

No configuration has been provided for TLS termination. The "right" TLS termination strategy and load balancing setup is highly subjective and depends very much on the rest of your environment. The container image accepts connections from any proxy, and recognizes the host from HTTP requests via the APP_URL environment variable.

Googling "letsencrypt haproxy" returns with [a](https://serversforhackers.com/c/letsencrypt-with-haproxy) [number](https://gridscale.io/en/community/tutorials/haproxy-ssl/) [of](https://kevinbentlage.nl/blog/lets-encrypt-with-haproxy/) [articles](https://cheppers.com/how-https-haproxy-and-letsencrypt) with decent instructions on how to set up HAProxy and certbot to automatically renew certificates served. Some extra keywords, like [wildcard](https://nicklang.com/posts/letsencrypt-a-wildcard-cert-for-haproxy-to-use-in-docker-swarm), give enough extra information to layer that into your configuration. If nginx makes more sense for your environment, an nginx configuration that stitches together the elements of [load balancing](http://nginx.org/en/docs/http/load_balancing.html), [reverse proxying](https://timothy-quinn.com/using-nginx-as-a-reverse-proxy-for-multiple-sites/), and [Let'sEncrypt](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04) can meet the same need. So can Apache, or a number of other webservers. The world is your oyster.

A robust TLS termination and load-balancing setup should outperform, and be easier to maintain than, many little nginx containers running with their own certificate lifecycles, even if they're automated. Running Akaunting in a container makes the most sense if you're running lots of services on fewer hosts, and for that use case a load-balancing reverse proxy for TLS termination might make more sense. Or it might not. Now you get to choose.

## Languages

Right now, the only built language is US English. If you would like more supported locales to be built into the container image, please [open an issue](https://github.com/akaunting/docker/issues).

## Extra ways to explore containerized Akaunting!
This repository contains extra compose and other files that allows you to run Akaunting in different setups like using FPM and NGINX and here is the most important commands that you may need:

Expand Down

0 comments on commit 863d9b4

Please sign in to comment.