abra app backup/restore #70
Labels
No Label
breaking-change
bug
CI/CD
design
documentation
duplicate
enhancement
help wanted
invalid
plugin
question
secrets
shell-completion
versioning
wontfix
No Milestone
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/abra#70
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Inspiration:
One braindump is: AFAIU each app probably has different commands to deal with the backing up, I was thinking that we could maybe specify a
commands.sh
or whatever in the actual upstream app repo whichabra
then sources and runs. This leaves the specifics of the backing up and restoring to the package maintainer.abra
can feed in the container names and passwords etc. required to get it done.Snap, this was my thought too.
Good news!
commands.sh
already exists, peep e.g. coop-cloud/wordpress:https://git.autonomic.zone/coop-cloud/wordpress/src/branch/master/abra-commands.sh
You just define a
sub_something
command there and thenabra app foo_bar something "args"
becomes available.One down-side is it doesn't integrate w/ docopt (yet?) so it won't show up in
abra --help
and you don't get any fancy argument-parsing, but maybe enough to start with.YES 🚀
Definitely think we can hack a sub-parser into the
abra-commands.sh
for this!Or:
Define
abra [command] app <app> backup [whatever args we want]
inabra
, have it callapp_backup
if it's defined and say "no backup configuration for this app yet" if it's not.Then define
app_backup
in per-appabra-commands.sh
.Advantage: we can use whichever tasty docopt-parsed options to
backup
we want, without messing with sub-parsers (which I am still unsure how to do).Disadvantage is all apps'
backup
commands would need to take the same arguments, but maybe that's a good thing.Question: where should backups go by default?
~/.abra/backups
seems decent, although maybe not the most intuitive.$PWD
(default from the above one-liners) could also be fine?Or we could yunohost / Cloudron / Heroku it, and have backups live on the server in a fixed directory by default then have a separate command to download them locally - would also solve the "transmitting possibly-uncompressed data over the network" wrinkle -- but I think would be architecturally harder; would we need to SSH to the swarm box and run
docker cp
there intead? 🤔Perfect ⭐
$PWD
or~/.abra/backups
seems fine! I guess we'll output a line where they live when they are produced. Having them remote also seems solid but yes, more work 🥇 Liking the way this is shaping up!Getting there:
(
-U
is--skip-update
to not rungit pull
every time 😬 I put it in[options]
so it can be added to any command)