Add dbm-example custom Jupyter app template

Creates a new custom app template based on Jupyter base-notebook with
integrated Workbench tools (gcsfuse, wb CLI) and cloud CLIs (AWS, GCP).
Configured for user rishbahc with Java 17 support.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

Author: rishabhc-verily

src/dbm-example/.devcontainer.json

@@ -0,0 +1,29 @@
+{
+  "name": "dbm-example",
+  "dockerComposeFile": "docker-compose.yaml",
+  "service": "app",
+  "shutdownAction": "none",
+  "workspaceFolder": "/workspace",
+  "postCreateCommand": [
+    "./startupscript/post-startup.sh",
+    "rishbahc",
+    "/home/rishabhc",
+    "${templateOption:cloud}",
+    "${templateOption:login}"
+  ],
+  "postStartCommand": [
+    "./startupscript/remount-on-restart.sh",
+    "rishbahc",
+    "/home/rishabhc",
+    "${templateOption:cloud}",
+    "${templateOption:login}"
+  ],
+  "features": {
+    "ghcr.io/devcontainers/features/java:1": {
+      "version": "17"
+    },
+    "ghcr.io/devcontainers/features/aws-cli:1": {},
+    "ghcr.io/dhoeric/features/google-cloud-cli:1": {}
+  },
+  "remoteUser": "root"
+}

src/dbm-example/README.md

@@ -0,0 +1,43 @@
+# dbm-example
+
+Custom Workbench application based on quay.io/jupyter/base-notebook.
+
+## Configuration
+
+- **Image**: quay.io/jupyter/base-notebook
+- **Port**: 8888
+- **User**: rishbahc
+- **Home Directory**: /home/rishabhc
+
+## Access
+
+Once deployed in Workbench, access your terminal at the app URL (port 8888).
+
+For local testing:
+1. Create Docker network: `docker network create app-network`
+2. Run the app: `devcontainer up --workspace-folder .`
+3. Access at: `http://localhost:8888`
+
+## Customization
+
+Edit the following files to customize your app:
+
+- `.devcontainer.json` - Devcontainer configuration and features
+- `docker-compose.yaml` - Docker Compose configuration (change the `command` to customize ttyd options)
+- `devcontainer-template.json` - Template options and metadata
+
+## Testing
+
+To test this app template:
+
+```bash
+cd test
+./test.sh dbm-example
+```
+
+## Usage
+
+1. Fork the repository
+2. Modify the configuration files as needed
+3. In Workbench UI, create a custom app pointing to your forked repository
+4. Select this app template (dbm-example)

src/dbm-example/devcontainer-template.json

@@ -0,0 +1,20 @@
+{
+  "id": "dbm-example",
+  "version": "1.0.0",
+  "name": "dbm-example",
+  "description": "Custom Workbench app: dbm-example (Image: quay.io/jupyter/base-notebook, Port: 8888, User: rishbahc)",
+  "options": {
+    "cloud": {
+      "type": "string",
+      "enum": ["gcp", "aws"],
+      "default": "gcp",
+      "description": "Cloud provider (gcp or aws)"
+    },
+    "login": {
+      "type": "string",
+      "description": "Whether to log in to workbench CLI",
+      "proposals": ["true", "false"],
+      "default": "false"
+    }
+  }
+}

src/dbm-example/docker-compose.yaml

@@ -0,0 +1,36 @@
+services:
+  app:
+    # The container name must be "application-server"
+    container_name: "application-server"
+    # This can be either a pre-existing image or built from a Dockerfile
+    image: "quay.io/jupyter/base-notebook"
+    # build:
+    #   context: .
+    restart: always
+    volumes:
+      - .:/workspace:cached
+      - work:/home/rishabhc/work
+    # The port specified here will be forwarded and accessible from the
+    # Workbench UI.
+    ports:
+      - 8888:8888
+    # The service must be connected to the "app-network" Docker network
+    networks:
+      - app-network
+    # SYS_ADMIN and fuse are required to mount workspace resources into the
+    # container.
+    cap_add:
+      - SYS_ADMIN
+    devices:
+      - /dev/fuse
+    security_opt:
+      - apparmor:unconfined
+
+volumes:
+  work:
+
+networks:
+  # The Docker network must be named "app-network". This is an external network
+  # that is created outside of this docker-compose file.
+  app-network:
+    external: true

src/dbm-example/startupscript/README.md

@@ -0,0 +1,115 @@
+# Developer guide for (post)startup script
+
+Verily Workbench provisions VMs post-creation to install workbench specific tools (such as CLI, gcsfuse, ssh-keys for git).
+
+Currently there are three flavors of startup.script:
+
+- vertex AI user-managed notebook
+- dataproc cluster
+- general gce instance (in the startupscript/ folder)
+
+## How to test your change?
+
+### Option 1
+
+If it's a single line change, you can just create an environment in the devel environment and run the command.
+
+### Option 2
+
+If it's a complex change, you can point the VM to your new script and test it end-to-end.
+
+#### Vertex AI
+
+- Step 1
+
+Make your change and push to a branch.
+
+- Step 2
+
+```text
+wb resource create gcp-notebook --id=jupyterNotebookForTesting --post-startup-script=https://raw.githubusercontent.com/verily-src/workbench-app-devcontainers/<your-branch>/startupscript/vertex-ai-user-managed-notebook/post-startup.sh
+```
+
+- Step 3
+  Go to the UI and wait till the notebook spins up and verify that it is running.
+
+#### Dataproc
+
+- Step 1
+
+Make your change and push to a branch.
+
+- Step 2
+
+```text
+wb resource create dataproc-cluster --name=dataprocForTesting --metadata=startup-script-url=https://raw.githubusercontent.com/verily-src/workbench-app-devcontainers/<your-branch>/startupscript/dataproc/startup.sh
+```
+
+Pick a workspace that you have previously created a dataproc cluster so you can reuse the buckets.
+
+- Step 3
+  Go to the UI and wait till the notebook spins up and verify that it is running.
+
+#### GCE
+
+- Step 1
+
+Clone this repo and put it in a public repo you own. Make the change
+
+- Step 2
+  In the UI, create a custom r-analysis app pointing at your personal repo.
+
+- Step 3
+  Wait for the notebook to spin up and go to the instance. Check .workbench/post-startup-output.txt to see if it succeeds.
+
+## Linting and Style
+
+Shell code in this repo will be checked with `shellcheck` as part of pull request testing.
+
+The `shellcheck` tool [can be installed locally](https://github.com/koalaman/shellcheck?tab=readme-ov-file#installing).
+Additionally, VSCode has a [ShellCheck extension](https://marketplace.visualstudio.com/items?itemName=timonwong.shellcheck).
+
+To configure `shellcheck` locally with the same configuration as the PR lint tasks, create a
+`~/.shellcheckrc` file with the following content:
+
+```shell
+disable=SC1090,SC1091
+```
+
+This disables checks [SC1090](https://www.shellcheck.net/wiki/SC1090) and
+[SC1091](https://www.shellcheck.net/wiki/SC1091), to work around limitations in
+`shellcheck` around dynamic file handling.
+
+In addition to `shellcheck`-enforced logic, it is highly recommended that variables and functions
+be made `readonly` to prevent overriding or unsetting.
+
+For trivial variable assignment this can be done on a single line:
+
+```shell
+readonly FOO="foo"
+```
+
+However, for assignments that involve calling a command, `readonly` can mask error responses; in
+these cases the variable should be marked `readonly` as a subsequent step.  This is enforced by
+`shellcheck` rule [SC2155](https://www.shellcheck.net/wiki/SC2155).
+
+```shell
+FOO="$(command)"
+readonly FOO
+```
+
+Functions follow this syntax:
+
+```shell
+function my_function {
+    # ... function logic ...
+}
+readonly -f my_func
+```
+
+## General debugging tips
+
+- Check /home/**\<user\>**/.workbench/post-startup-output.txt to see where the script failed.
+  The user is jupyter for vertex AI, dataproc for dataproc cluster, and varies by app for gce instance.
+
+- If the proxy url doesn't work, you can ssh to the VM.

src/dbm-example/startupscript/aws/bash-profile-append.bash

@@ -0,0 +1,11 @@
+
+# Prompt user to authenticate with Workbench CLI if they are not already
+# authenticated. Note the lack of a shebang is intentional.  This file will be
+# appended to the user's .bash_profile file, and is kept separate so that this 
+# code can be linted with shellcheck.
+
+if [[ "$("${WORKBENCH_INSTALL_PATH}" auth status --format json | jq .loggedIn)" == false ]]; then
+    echo "User must log into Workbench to continue."
+    "${WORKBENCH_INSTALL_PATH}" auth login
+    configure_workbench
+fi

src/dbm-example/startupscript/aws/bashrc-functions.bash

@@ -0,0 +1,48 @@
+
+# Workbench helper functions for AWS. Note the lack of a shebang is 
+# intentional. This file will be appended to the user's .bashrc file, and is
+# kept separate so that these functions can be linted with shellcheck.
+
+function configure_workspace() {
+  "${WORKBENCH_INSTALL_PATH}" workspace set --uuid "${WORKBENCH_WORKSPACE_UUID}"
+  "${WORKBENCH_INSTALL_PATH}" workspace configure-aws --cache-with-aws-vault=true
+  "${WORKBENCH_INSTALL_PATH}" resource mount
+}
+readonly -f configure_workspace
+
+function configure_ssh() {
+  local USER_SSH_DIR="${HOME}/.ssh"
+  mkdir -p "${USER_SSH_DIR}"
+  local USER_SSH_KEY
+  USER_SSH_KEY="$("${WORKBENCH_INSTALL_PATH}" security ssh-key get --include-private-key --format=JSON)"
+  echo "${USER_SSH_KEY}" | jq -r '.privateSshKey' > "${USER_SSH_DIR}"/id_rsa
+  echo "${USER_SSH_KEY}" | jq -r '.publicSshKey' > "${USER_SSH_DIR}"/id_rsa.pub
+  chmod 0600 "${USER_SSH_DIR}"/id_rsa*
+  ssh-keyscan -H github.com >> "${USER_SSH_DIR}/known_hosts"
+}
+readonly -f configure_ssh
+
+function configure_git() {
+  mkdir -p "${WORKBENCH_GIT_REPOS_DIR}"
+  pushd "${WORKBENCH_GIT_REPOS_DIR}" || return
+  "${WORKBENCH_INSTALL_PATH}" resource list --type=GIT_REPO --format json | \
+    jq -c .[] | \
+    while read -r ITEM; do
+      local GIT_REPO_NAME
+      GIT_REPO_NAME="$(echo "$ITEM" | jq -r .id)"
+      local GIT_REPO_URL
+      GIT_REPO_URL="$(echo "$ITEM" | jq -r .gitRepoUrl)"
+      if [[ ! -d "${GIT_REPO_NAME}" ]]; then
+        git clone "${GIT_REPO_URL}" "${GIT_REPO_NAME}"
+      fi
+    done
+  popd || return
+}
+readonly -f configure_git
+
+function configure_workbench() {
+  configure_workspace
+  configure_ssh
+  configure_git
+}
+readonly -f configure_workbench

src/dbm-example/startupscript/aws/configure-aws-vault.sh

@@ -0,0 +1,52 @@
+#!/bin/bash -x
+
+# configure-aws-vault.sh
+#
+# Performs additional one-time configuration for applications running in AWS
+# EC2 instances.
+#
+# Note that this script is intended to be sourced from the "post-startup.sh"
+# script and is dependent on some functions and variables already being set up
+# and some packages already installed:
+#
+# - emit (function)
+# - RUN_AS_LOGIN_USER: run command as app user
+# - WORKBENCH_INSTALL_PATH: path to CLI executable
+
+readonly AWS_VAULT_INSTALL_PATH="/usr/bin/aws-vault"
+readonly AWS_VAULT_BINARY_PATH="/usr/bin/_aws-vault"
+readonly AWS_VAULT_EXE_URL="https://github.com/ByteNess/aws-vault/releases/download/v7.9.13/aws-vault-linux-amd64"
+
+if [[ -f "${AWS_VAULT_INSTALL_PATH}" ]]; then
+    emit "aws-vault already installed"
+else
+    ##########################################
+    # Install aws-vault for credential caching
+    ##########################################
+    emit "installing aws-vault"
+    curl --no-progress-meter --location --output "${AWS_VAULT_BINARY_PATH}" "${AWS_VAULT_EXE_URL}"
+
+    cat <<EOF > "${AWS_VAULT_INSTALL_PATH}"
+export AWS_VAULT_BACKEND="file"
+export AWS_VAULT_FILE_PASSPHRASE=""
+
+# aws-vault's keyring dependency creates dbus-daemon processes without cleaning
+# them up (https://github.com/99designs/keyring/issues/103). By setting
+# DBUS_SESSION_BUS_ADDRESS to /dev/null, we can prevent aws-vault from creating
+# these processes. dbus is only needed for the "secretservice" backend, which we
+# do not use.
+export DBUS_SESSION_BUS_ADDRESS="/dev/null"
+
+exec "${AWS_VAULT_BINARY_PATH}" "\$@"
+EOF
+
+    chmod 755 "${AWS_VAULT_INSTALL_PATH}"
+    chmod 755 "${AWS_VAULT_BINARY_PATH}"
+
+    #####################################
+    # Set up aws-vault credential caching
+    #####################################
+    ${RUN_AS_LOGIN_USER} "${WORKBENCH_INSTALL_PATH} config set cache-with-aws-vault true"
+    ${RUN_AS_LOGIN_USER} "${WORKBENCH_INSTALL_PATH} config set wb-path --path ${WORKBENCH_INSTALL_PATH}"
+    ${RUN_AS_LOGIN_USER} "${WORKBENCH_INSTALL_PATH} config set aws-vault-path --path ${AWS_VAULT_INSTALL_PATH}"
+fi