1
1
sovereign-stack/deployment/update.sh

102 lines
3.9 KiB
Bash
Raw Normal View History

2023-02-01 19:44:05 +00:00
#!/bin/bash
2023-04-07 18:04:43 +00:00
set -eu
2023-02-01 19:44:05 +00:00
cd "$(dirname "$0")"
2023-04-12 14:07:41 +00:00
. ./target.sh
2023-04-07 14:41:18 +00:00
# # As part of the install script, we pull down any other sovereign-stack git repos
# PROJECTS_SCRIPTS_REPO_URL="https://git.sovereign-stack.org/ss/project"
# PROJECTS_SCRIPTS_PATH="$(pwd)/deployment/project"
# if [ ! -d "$PROJECTS_SCRIPTS_PATH" ]; then
# git clone "$PROJECTS_SCRIPTS_REPO_URL" "$PROJECTS_SCRIPTS_PATH"
# else
# cd "$PROJECTS_SCRIPTS_PATH" || exit 1
# git -c advice.detachedHead=false pull origin main
# git checkout "$TARGET_PROJECT_GIT_COMMIT"
# cd - || exit 1
# fi
2023-04-07 14:23:04 +00:00
2023-03-06 20:42:17 +00:00
# check if there are any uncommited changes. It's dangerous to
# alter production systems when you have commits to make or changes to stash.
if git update-index --refresh | grep -q "needs update"; then
echo "ERROR: You have uncommited changes! You MUST commit or stash all changes to continue."
exit 1
fi
2023-03-06 20:42:17 +00:00
2023-03-15 15:19:34 +00:00
echo "WARNING: this script backs up your existing remote and saves all data locally in the SSME."
echo " Then, all your VMs are destroyed on the remote resulting is destruction of user data."
echo " But then we re-create everything using the new codebase, then restore user data to the"
echo " newly provisioned VMs."
RESPONSE=
read -r -p "Are you sure you want to continue (y/n): ": RESPONSE
if [ "$RESPONSE" != "y" ]; then
echo "STOPPING."
exit 0
fi
2023-04-07 14:41:18 +00:00
. ./deployment_defaults.sh
2023-02-01 19:44:05 +00:00
2023-03-09 14:55:40 +00:00
. ./remote_env.sh
2023-02-01 19:44:05 +00:00
2023-04-02 13:41:42 +00:00
. ./project_env.sh
# Check to see if any of the VMs actually don't exist.
# (we only migrate instantiated vms)
for VM in www btcpayserver; do
LXD_NAME="$VM-${DOMAIN_NAME//./-}"
# if the VM doesn't exist, the we emit an error message and hard quit.
if ! lxc list --format csv | grep -q "$LXD_NAME"; then
echo "ERROR: there is no VM named '$LXD_NAME'. You probably need to run ss-deploy again."
exit 1
2023-03-14 15:37:33 +00:00
fi
2023-04-02 13:41:42 +00:00
done
2023-03-14 15:37:33 +00:00
2023-04-02 13:41:42 +00:00
BTCPAY_RESTORE_ARCHIVE_PATH="$SITES_PATH/$PRIMARY_DOMAIN/backups/btcpayserver/$(date +%s).tar.gz"
echo "INFO: The BTCPAY_RESTORE_ARCHIVE_PATH for this migration will be: $BTCPAY_RESTORE_ARCHIVE_PATH"
# first, let's grab the GIT commit from the remote machine.
export DOMAIN_NAME="$PRIMARY_DOMAIN"
export SITE_PATH="$SITES_PATH/$PRIMARY_DOMAIN"
# source the site path so we know what features it has.
source "$SITE_PATH/site.conf"
source ./project/domain_env.sh
# now we want to switch the git HEAD of the project subdirectory to the
# version of code that was last used
GIT_COMMIT_ON_REMOTE_HOST="$(ssh ubuntu@$BTCPAY_FQDN cat /home/ubuntu/.ss-githead)"
cd project/
echo "INFO: switch the 'project' repo to commit prior commit '$GIT_COMMIT_ON_REMOTE_HOST'"
echo " This allows Sovereign Stack to can grab a backup using the version of the code"
echo " that was used when the deployment was created."
git checkout "$GIT_COMMIT_ON_REMOTE_HOST"
cd -
# run deploy which backups up everything, but doesnt restart any services.
2023-04-07 18:02:24 +00:00
bash -c "./up.sh --stop --backup-archive-path=$BTCPAY_RESTORE_ARCHIVE_PATH --backup-www --backup-btcpayserver --skip-base-image"
2023-04-02 13:41:42 +00:00
2023-04-05 19:40:43 +00:00
# call the down script (be default it is non-destructuve of user data.)
2023-04-04 15:34:48 +00:00
./down.sh
2023-04-05 19:40:43 +00:00
# next we switch back to the current version of Sovereign Stack scripts for bringin up the new version.
2023-04-02 13:41:42 +00:00
cd project/
echo "INFO: switching the 'project' repo back to the most recent commit '$TARGET_PROJECT_GIT_COMMIT'"
echo " That way new deployments will be instantiated using the latest codebase."
git checkout "$TARGET_PROJECT_GIT_COMMIT"
cd -
2023-04-04 15:34:48 +00:00
# TODO we can do some additional logic here. FOr example if the user wants to provide a source/target project/remote,
# we can backup the source remote+project and restore it to the target remote+project. This will facilitate cross-device migrations
# However, if the source and target project/remote are the same, we don't really
# need to do any restorations (or backups for that matter, though we still grab one);
# we simply mount the existing data. That's the more common case where the user is simply upgrading the system in-place.
2023-04-07 18:02:24 +00:00
./up.sh