shipperctl backup commands

[hihilla]

Prepare - saves applications and releases objects to file in a tree (map) form: for each application we store the releases belonging to it.

Restore - restores from a backup file. First restore the application, populate the new UID of the application in its releases owner reference and then apply releases.

output example:

$ shipperctl backup -h
Backup and restore Shipper applications and releases

Usage:
  shipperctl backup [command]

Available Commands:
  prepare     Get yaml of application and release objects prepared for backup
  restore     Restore backup that was prepared using `shipperctl prepare` command

Flags:
  -f, --file string                         The path to a backup file (default "backup.yaml")
      --format string                       Output format. One of: json|yaml (default "yaml")
  -h, --help                                help for backup
      --kubeconfig string                   The path to the Kubernetes configuration file (default "~/.kube/config")
      --management-cluster-context string   The name of the context to use to communicate with the management cluster. defaults to the current one
  -v, --verbose                             Prints the list of backup items

Use "shipperctl backup [command] --help" for more information about a command.

$ shipperctl backup restore -v
Making sure shipper is down... done
Making sure there are no Shipper objects lying around... done
Would you like to see an overview of your backup? [y/n]: y
NAMESPACE  NAME                      OWNING APPLICATION
default    super-server-dc5bfc5a-0   super-server
default2   super-server2-dc5bfc5a-0  super-server2
default3   super-server3-dc5bfc5a-0  super-server3
Would you like to review backup? [y/n]: y
- application:
  ...
  releases:
  -  ...
...
Would you like to restore backup? [y/n]: y
...

$ shipperctl backup prepare -v
NAMESPACE  NAME                      OWNING APPLICATION
default    super-server-dc5bfc5a-0   super-server
default2   super-server2-dc5bfc5a-0  super-server2
default3   super-server3-dc5bfc5a-0  super-server3
Backup objects stored in "backup.yaml"

$ shipperctl backup prepare
Backup objects stored in "backup.yaml"

$ shipperctl backup prepare -f "a_new_bkup_file.json" --format json
Backup objects stored in "a_new_bkup_file.json"

## If shipper deoployment is not scaled down:
$ shipperctl backup restore
Making sure shipper is down... Error! shipper deployment has 1 replicas. Scale it down first with `kubectl -n shipper-system patch deploy shipper --type=merge -p '{"spec":{"replicas":0}}'`

## If there are shipper objects in the cluster:
$ shipperctl backup restore
Making sure shipper is down... done
Making sure there are no Shipper objects lying around... Error! found Shipper objects:
 - Applications: 3
 - Releases: 3
 - InstallationTargets: 3
 - TrafficTargets: 3
 - CapacityTargets: 3
delete them first with `kubectl delete app,rel,it,tt,ct --all-namespaces --all`

[hihilla]

@nodo

How are would it be to add unit tests?

I am not 100% sure how to test this without a fake client, and even with, I'm not sure how to test this...

[nodo]

Adding a fake client is exactly the wait to go, maybe you could try and use https://pkg.go.dev/k8s.io/client-go/kubernetes/fake for a fake k8s client. I am not 100% sure on how to do it but I think it would be worth, let me know if I can help out somehow.