Zarf development script and documentation

docs/assets/scripts/airgap-zarf/zarf-dev.sh

+#!/usr/bin/env bash
+
+ZARF_VERSION=v0.25.0
+
+# Prerequisites: REGISTRY1_USERNAME and REGISTRY1_PASSWORD must be exported locally.
+# Configurable: ZARF_TEST_REPO, ZARF_TEST_REPO_BRANCH, ZARF_TEST_REPO_DIRECTORY all define where to pick up the zarf.yaml file.
+# Example with configuration: KeyName=<KeyName> PublicIP=<Ip> ZARF_TEST_REPO=https://repo1.dso.mil/some-repo.git ZARF_TEST_REPO_BRANCH=development docs/assets/scripts/airgap-zarf/zarf-dev.sh
+
+ZARF_TEST_REPO=${ZARF_TEST_REPO:=https://github.com/defenseunicorns/zarf}
+ZARF_TEST_REPO_BRANCH=${ZARF_TEST_REPO_BRANCH:=main}
+ZARF_TEST_REPO_DIRECTORY=${ZARF_TEST_REPO_DIRECTORY:=zarf/examples/big-bang}
+
+function run() {
+  ssh -i ~/.ssh/${KeyName}.pem -o StrictHostKeyChecking=no -o IdentitiesOnly=yes ubuntu@${PublicIP} $1
+}
+
+# install zarf
+echo Installing zarf...
+run "curl -LO https://github.com/defenseunicorns/zarf/releases/download/${ZARF_VERSION}/zarf_${ZARF_VERSION}_Linux_amd64"
+run "sudo mv /home/ubuntu/zarf_${ZARF_VERSION}_Linux_amd64 /usr/local/bin/zarf"
+run "sudo chmod +x /usr/local/bin/zarf"
+
+# get zarf init package
+echo "Retrieving zarf init package..."
+run "wget -q https://github.com/defenseunicorns/zarf/releases/download/${ZARF_VERSION}/zarf-init-amd64-${ZARF_VERSION}.tar.zst"
+
+# zarf init, package and deploy
+run "set +o history && echo ${REGISTRY1_PASSWORD} | zarf tools registry login registry1.dso.mil --username ${REGISTRY1_USERNAME} --password-stdin || set -o history"
+run "zarf init --components=git-server --confirm"
+run "git clone --single-branch --branch ${ZARF_TEST_REPO_BRANCH} ${ZARF_TEST_REPO}"
+run "cd ${ZARF_TEST_REPO_DIRECTORY} && zarf package create --confirm --max-package-size=0"
+run "cd ${ZARF_TEST_REPO_DIRECTORY} && zarf package deploy zarf-package-big-bang-example-amd64-1.54.0.tar.zst --confirm --components=gitea-virtual-service"

docs/guides/README.md

@@ -23,6 +23,7 @@ The guides included here are not all inclusive of every situation. Please open a
 ### Airgap Deployments
 
 [Airgap Deployments](./airgap/README.md)
+[Airgap w/Zarf](./airgap-zarf/README.md)
 
 ## Backup and Restore
 

docs/guides/airgap-zarf/README.md

+# Airgap w/Zarf
+
+> ⚠️ This is a work in-progress.
+
+> ⚠️ These instructions work specifically with Big Bang version 1.54.0.  Other versions are not yet supported.
+
+This section is currently purely devoted to building and testing packages on a development cluster.  The result could be a set of archives that can be used for moving across an airgap.  Essentially this automates a few of the steps indicated in this [documentation](https://github.com/defenseunicorns/zarf/blob/main/docs/13-walkthroughs/5-big-bang.md).
+
+The first step would be to stand up a Big Bang dev cluster.  This is most easily represented by following the steps outlined here, but would ultimately result in running the below command, which stands up a larger development cluster.  Take note of the KeyName and Public IP address which will be used in a later step.
+
+```shell
+docs/assets/scripts/developer/k3d-dev.sh -b
+```
+
+Be sure to export your Registry1 credentials next as seen below:
+
+```shell
+export REGISTRY1_USERNAME=<username>
+export REGISTRY1_CLI_SECRET=<password>
+```
+
+Now you can execute the following: 
+
+```shell
+KeyName=<KeyName> PublicIP=<Ip> docs/assets/scripts/airgap-zarf/zarf-dev.sh
+```
+
+The above will clone the latest  `main` branch of the [defenseunicorns/zarf](https://github.com/defenseunicorns/zarf) repository and execute the stock `examples/big-bang/zarf.yaml`.  If you want to use a different `zarf.yaml`, you can override this by setting any of these variables ahead of time, either by exporting them or setting them as part of the command.
+
+* `ZARF_TEST_REPO`: sets the repository to clone from.
+* `ZARF_TEST_REPO_BRANCH`: sets the branch to switch to from the cloned repo.
+* `ZARF_TEST_REPO_DIRECTORY`: sets the directory where the desired `zarf.yaml` is.
+
+Also since this all uses the same dev script, you should be able to use whatever k8s tooling (such as `kubectl` or `k9s`) you already might use on a dev cluster as `KUBECONFIG` is still transferred locally and available.