Moving the ITB to another hosting setup - what is required?

[olw-medcom]

Hey Costas,

Inspired by our other thread about accessing the pod archives, I think I will finally self-host the ITB instead, as I would like better access to the infrastructure. In that regard I was wondering what is actually needed to move the containers to another setup?

I'm guessing a database migration script and then volumes from the gitb-ui and gitb-srv, but which subpaths within the volumes? Should it just be the entire thing?

Furthermore, how about the gitb-redis? Is there anything in there that needs to be migrated?

Best regards

[costas80]

Hey @olw-medcom.

To migrate the installation you will need the complete contents of the gitb-dbdata and gitb-repo volumes/PVC. If you copy these and then supply them to your new instance you've basically moved its entire persistent state. If you prefer dealing in terms of paths within pods, then these would be:

• In gitb-mysql, path /var/lib/mysql (this is mapped from the gitb-dbdata volume/PVC).
• In gitb-ui, path /gitb-repository (this is mapped from the gitb-repo volume/PVC).

Basically if you refer to the installation guide's docker-compose.yml file, these are the volumes mentioned (see here). For k8s, note that these are also the PVC mounts defined in the manifests of gitb-ui and gitb-mysql (see here).

I'm guessing a database migration script and then volumes from the gitb-ui and gitb-srv, but which subpaths within the volumes? Should it just be the entire thing?

No need for a DB migration script. Just copy the full volume/PVC contents.

Furthermore, how about the gitb-redis? Is there anything in there that needs to be migrated?

No need. The redis instance is fully ephemeral, serving as a cache for connected users' sessions. The only effect of deleting/recreating gitb-redis is that users are logged out.

[olw-medcom]

Great, that's good to know!