Skip to content

Commit

Permalink
Added some clarifications and fixed typos
Browse files Browse the repository at this point in the history
  • Loading branch information
@nuokh
nuokh committed May 24, 2021
1 parent 618b9d4 commit 5025120
Show file tree
Hide file tree
Showing 2 changed files with 43 additions and 47 deletions.
45 changes: 29 additions & 16 deletions content/simple-taiga-backup.md
View file
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Backing Up Taiga's Docker Installation Using Bind Mounts
# Backing up Taiga's Docker installation using bind mounts

## Assumptions
Since we have to reconfigure Taiga to save it's data in a way that makes this process possible we have to start from scratch.
Expand All @@ -9,26 +9,27 @@ This guide will assume that you're running a fresh server. You already installed

This guide will give a little introduction on how backing up the Taiga Docker installation works using Docker bind mounts. While Docker volumes are great for a variety of use cases they burden the sysadmin with complexity that's not always needed in simple enviroments.

## Bind Mounts VS. Volumes
## Bind mounts vs. volumes

Docker containers can use bind mounts or volumes to store data that is supposed to stay after a container has been removed, stopped or updated.
Docker containers can use bind mounts or volumes to store data that is supposed to stay after a container has been removed, stopped or updated.

With bind mount, a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full or relative path on the host machine. With volumes, a new directory is created within Docker's storage directory on the host machine, and Docker manages that directory's content.
You can read all about the different types of Docker application data storage [here](https://docs.docker.com/storage/).

Bind mounts are much easier to backup since they can be zipped on ad-hoc basis, rsynced to a network share regulary using a cronjob or just saved to your desktop via FTP manually before the next big update in case something breaks.
With [bind mounts](https://docs.docker.com/storage/bind-mounts/), a file or directory on the host machine is mounted into a container. The file or directory is referenced by its full or relative path on the host machine. With volumes, a new directory is created within Docker's storage directory on the host machine, and Docker manages that directory's content.

Docker doesn't provide any command to backup volumes and you have to use temporary containers with a bind mount to create backups.
Bind mounts are easier to backup and make maintaining a Docker installation easier for Docker newcomers or admins that don't need the complexity of Kubernetes and Docker volumes. Bind mounts can be backed up by being zipped on ad-hoc basis, rsynced to a network share regulary using a cronjob or just saved to your desktop via FTP manually before the next big update in case something breaks.

Docker doesn't provide any command to backup volumes and you have to use temporary containers with a bind mount to create backups.

If you're interested in backing up and restoring Taiga's out of the box installation using volumes you can read more about the process [here](https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes).

If you are in need of a simpler solution keep reading to find out how to backup and restore your Taiga data using bind mounts.

## Configure Taiga To Use Bind Mounts
## Configure Taiga to use bind mounts

Open **docker-compose.yml**.

Replace all instances of `localhost` in **docker-compose.yml** with your domain name. Then we'll switch from volume to bind mount configuration. For example

~~~
# Comment the next two lines to use bind mounts
- taiga-static-data:/taiga-back/static
Expand All @@ -46,7 +47,6 @@ becomes
- ./taiga-bind-mounts/taiga-back/static:/taiga-back/static
- ./taiga-bind-mounts/taiga-back/media:/taiga-back/media
~~~

Pay attention to the code indentation: The uncommented lines are supposed to have the same indentation as the lines that are about to get commented out.

Repeat the above process for all occurrences of parts in **docker-compose.yml** and **docker-compose-inits.yml** that look like this pattern:
Expand Down Expand Up @@ -109,9 +109,9 @@ mkdir taiga-bind-mounts
~~~
to create the directory we'll be using for our persistent data storage. Note that this could be anywhere on your host, even on network shares. This is going to be the single directory you'll have to backup to be able to restore your Taiga data.

If you decide to put this folder somewhere different you'll have to reconfigure **docker-compose.yml** and **docker-compose.inits.yml** accordingly with updatet paths for the **taiga-bind-mounts** directory accordingly.
If you decide to put this folder somewhere different you'll have to reconfigure **docker-compose.yml** and **docker-compose-inits.yml** accordingly with updated paths for the **taiga-bind-mounts** directory accordingly.

Last but not least we'll have to move the gateway config to keep our updated **docker-compose.yml** config working by typing
Last but not least we'll have to move the gateway configuration to keep our updated **docker-compose.yml** working by typing
~~~
mv ./taiga-gateway ./taiga-bind-mounts/taiga-gateway
~~~
Expand All @@ -120,18 +120,31 @@ Run `./launch-taiga.sh` to initialise the Taiga server using bind mounts. Finall

If you’re testing it in your own machine, you can access the application in http://localhost:9000.

## Backing Up Taiga
## Backing up Taiga

Now thanks to using bind mounts backing up Taiga is as easy as backing up your **taiga-bind-mounts** directory. This could be done in many ways, for example by running
Now thanks to using bind mounts backing up Taiga is as easy as backing up your **taiga-bind-mounts** directory.

Before doing so it's recommended to stop your Taiga installation by typing
~~~
docker-compose down
~~~
Backing up the **taiga-bind-mount** direcotry could be done in many ways, for example by running
~~~
rsync -ahu --progress taiga-bind-mounts ~/taigabackuptest
~~~
to save a full backup to your home directory.
to save a full backup to your home directory. After your successfully backed up your **taiga-bind-mount** directory restart your Taiga by typing
~~~
docker-compose up -d
~~~

## Restoring Taiga

Let's asume you borked an update and you want to restore your Taiga projects. Just boot up a new server, clone the taiga-docker git repository using the last working version tag, reconfigure Taiga to use bind mounts using the above guide (minus executing the launch script) and finally put your backup into your empty **taiga-bind-mounts** directory and *then* start the new Taiga server using `./launch-taiga.sh`.
Let's assume you borked an update and you want to restore your Taiga projects. Just boot up a new server, clone the taiga-docker git repository using the last working version tag, reconfigure Taiga to use bind mounts using the above guide (minus executing the launch script) and finally put your backup into your empty **taiga-bind-mounts** directory. To extend on our previous example with rsync this can be done simply switching the destination and target from the backup command:
~~~
rsync -ahu --progress ~/taigabackuptest taiga-bind-mounts
~~~
Then start the new Taiga server using `./launch-taiga.sh`.

Your project data is now restored and running on a freshly cloned taiga-docker installation.

There are, of course, many ways to restore your backup because we've became very flexible in how to tackle the backup and restore workflow by using bind mounts.
You've became more flexible in how to create a backup and restore workflow by using bind mounts. Using rsync is just an example. There are, of course, many ways to prepare and restore your backup.
45 changes: 14 additions & 31 deletions content/update-taiga-docker.md
View file
Original file line number Diff line number Diff line change
@@ -1,47 +1,30 @@
# Updating Taiga's Docker Installation
# Updating Taiga's Docker installation

This guide will give a little introduction on how backing up and updating the Taiga Docker installation works.
This guide will give a little introduction on how updating the Taiga Docker installation works.

## Check Taiga's Versions
## Check Taiga's versions

Before we do anything we need to understand which version we're currently running and what version we want to update to.
Before we do anything we may want to understand how the update process works and what version we're going to update to by executing an update command.

To check your currently running versions enter `docker ps -a`.
Updating the Docker installation is going to be handled by Docker Compose. To check which version Docker Compose is going to update to open the **docker-compose.yml** file by going to your Taiga directory and using your favorite text editor. If you are unsure how to edit text files in Linux just type `nano docker-compose.yml` to open it in a beginner friendly text editor.

Example output:

~~~
root@vm02:/var/lib/docker/volumes# docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
143d73413cab taigaio/taiga-back:latest "/taiga-back/docker/…" 19 minutes ago Up 19 minutes 8000/tcp taiga-docker_taiga-async_1
24e289b1770c taigaio/taiga-back:latest "./docker/entrypoint…" 19 minutes ago Up 19 minutes 8000/tcp taiga-docker_taiga-back_1
57d5d2a7dd17 taigaio/taiga-front:latest "/docker-entrypoint.…" 20 minutes ago Up 19 minutes 80/tcp taiga-docker_taiga-front_1
2af6523f4fa7 nginx:1.19-alpine "/docker-entrypoint.…" 24 minutes ago Up 24 minutes 0.0.0.0:9000->80/tcp, :::9000->80/tcp taiga-docker_taiga-gateway_1
5a6436e8bdd6 taigaio/taiga-events:latest "./docker/entrypoint…" 24 minutes ago Up 24 minutes 8888/tcp taiga-docker_taiga-events_1
792693b4c8a8 rabbitmq:3-management-alpine "docker-entrypoint.s…" 24 minutes ago Up 24 minutes 4369/tcp, 5671-5672/tcp, 15671-15672/tcp, 15691-15692/tcp, 25672/tcp taiga-docker_taiga-async-rabbitmq_1
f94c8df5fac5 taigaio/taiga-protected:latest "./docker/entrypoint…" 24 minutes ago Up 24 minutes 8003/tcp taiga-docker_taiga-protected_1
064c8e0fce71 postgres:12.3 "docker-entrypoint.s…" 24 minutes ago Up 24 minutes 5432/tcp taiga-docker_taiga-db_1
9b6a178a7e76 rabbitmq:3-management-alpine "docker-entrypoint.s…" 24 minutes ago Up 24 minutes 4369/tcp, 5671-5672/tcp, 15671-15672/tcp, 15691-15692/tcp, 25672/tcp taiga-docker_taiga-events-rabbitmq_1
~~~
Updating the Docker installation is going to be handled by Docker Compose. To check which version Docker Compose is going to update to open the **docker-compose.yml** file by going to your Taiga directory and typing `nano docker-compose.yml`.

The image variable in the **docker-compose.yml** file contains the version (tag) you will update to if you run the update commands: number point to the biggest option, so for example
The image variable in the **docker-compose.yml** file contains the version (tag) you will update to if you run the update commands. To go over a few examples:
~~~
services:
taiga-db:
image: postgres:12.3
~~~
will point to the biggest postgres 12.3.X version available, if you check on dockerhub you'll see that there are no "smaller versions" so it will just download 12.3. Some tag are special and point to a specific version, for example
will point to the biggest postgres 12.3.X version available. If you check on dockerhub you'll see that there are no "smaller versions" so it will just download 12.3. Some tag are special and point to a specific version, for example
~~~
taiga-front:
image: taigaio/taiga-front:latest
~~~
`latest` points to the latest version available. If you check again on [Dockerhub](https://hub.docker.com/u/taigaio "Taiga on Dockerhub") you can see that, at the time of writing this guide, `latest`, 6, 6.1 and 6.1.1 all points to the same image, 6.1.1.

## Compability Between Versions
## Compability between versions
As for the compatibility, usually updating between minor versions should be fine. Nonetheless, you should always prepare a backup in case anything breaks.

## Regarding Taiga's Project Data
## Regarding Taiga's project data

Taiga data is, by default configuration, saved inside Docker volumes. Docker volumes survive container recreation (and therefore the update process) since they are stored in a directory on your host server instead of inside your Docker containers. If you don’t explicitly create it, Taiga's data volumes are created the first time Taiga's images are mounted into their containers. When a container stops or is removed, the volume still exists. Volumes are only removed when you explicitly remove them.

Expand All @@ -60,7 +43,7 @@ services:
networks:
- taiga
~~~
That taiga-db-data volume is where your "permanent" Taiga data like projects or project settings are stored. You can check Taiga's Docker Compose file to find all volumes. If you don't run any other docker containers on your server a quick `docker volume ls` lists all running docker containers and can also aid to get a quick overview of all Docker volumes.
That taiga-db-data volume is where your "permanent" Taiga data like projects or project settings are stored. You can check Taiga's Docker Compose file to find all volumes. If you don't run any other docker containers on your server a quick `docker volume ls` lists all running docker containers. This is handy to get a quick overview of all Docker volumes.

Example output:
~~~
Expand All @@ -77,11 +60,11 @@ Docker doesn't provide any command to backup volumes and you have to use tempora

If you're interested in backing up and restoring Taiga's out of the box installation using volumes you can read more about the process [here](https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes).

Bind mounts are much easier to backup since they can be zipped on ad-hoc basis, rsynced to a network share regulary using a cronjob or just saved to your desktop via FTP manually before the next big update in case something breaks.
Bind mounts are much easier to backup. They enable you to zip your Taiga data on an as-needed basis, rsynced it to a network share regulary using a cronjob or just saved it to your workstation's desktop via FTP manually before the next big update in case something breaks.

If you are in need of a simpler solution head [here](simple-taiga-backup.md) to find out how to backup and restore your Taiga data using bind mounts.

## Specify Target Version
## Specify target version

Now, for the update part, you can add a specific version tag to your Taiga container, replacing `latest` with the version you need of feel the need to update to. There are many containers on that file so this is just an example`
~~~
Expand All @@ -99,11 +82,11 @@ If you just want to update to the newest version you don't have to change anythi

To update all the containers you can run `docker-compose pull` and `docker-compose up -d` without arguments. All the containers in the **docker-compose.yml** will be updated to the version pointed to their respective tag.

## Update Specific Containers Only
## Update specific containers only

To update a specific container only, for example taiga-front, run `docker-compose pull taiga-front` and `docker-compose up -d taiga-front` to update only this one. This way you can update containers singularly.

## Post-Update Cleanup
## Post-update cleanup

If you run the command `docker images` afterwards you'll notice that you will have both the new and the old images listed.

Expand Down

0 comments on commit 5025120

Please sign in to comment.