mvhenten

Route 53 + CloudFormation + CDK runbook

Reference for PublicHostedZone operations, CDK stack/stage renames, and skip-retain situations.

---

Mechanics

DeleteHostedZone blocks on non-default records

mvhenten

#!/bin/bash
# Set status bar color based on window unique ID
PALETTE=(25 134 34 130 166 88 168 64 24 132)
WID=$(tmux display-message -p '#{window_id}')
[ -z "$WID" ] && exit 0
HASH=$(echo -n "$WID" | cksum | awk '{print $1}')
C=${PALETTE[$((HASH % ${#PALETTE[@]}))]}
tmux set -g status-style "bg=colour$C"

mvhenten

# AWS SSO profile switcher
# Add to ~/.bashrc or source from a separate file
#
# Usage:
#   sso              - list profiles (* marks active)
#   sso set <p>      - set AWS_PROFILE (tab-completes)
#   sso unset        - clear AWS_PROFILE
#   sso login        - start SSO login flow
#   sso configure <p> - configure SSO for a profile

mvhenten

#!/usr/bin/env node

/**
 * Simple way to hoist package dependencies to the root of the repo.
 *
 * - put common packages in devDependencies
 * - run this script to update all workspaces
 * - make sure to npm install for an updated package-lock.json
 *
 */

mvhenten

Best practices and conventions for working with CDK

CDK code breaks many conventions found in normal other types of application code. CDK is class-based but puts most of the logic in the constructor, and it doesn't alway play well with inheritance.

• Only Constructs may implement inheritance, all other constructs can only inherit from their foundational CDK constructs.
• Stacks compose Constructs. stacks are never re-used.

An application is a single, top-level stack that deploys a self-mutating pipeline that in turn deploys all other stacks. This can be somewhat confusing because code organization doesn't always reflect the entire deployment flow.

CDK orchestrates compiling code to CloudFormation templates. We use pipelines to orchestrate deploying templates to CloudFormation. CloudFormation is used to orchestrate the actual provisioning and configuration of resources.

mvhenten

import fetch from "node-fetch";

export const getClientV1 = (domain, apiToken, userEmail) => {
	const headers = {
		Authorization: `Basic ${Buffer.from(`${userEmail}:${apiToken}`).toString("base64")}`,
		Accept: "application/json",
		"X-Atlassian-Token": "no-check",
	};

	const req = async (endpoint, options = {}) => {

mvhenten

#!/usr/bin/env node

import { parseArgs } from "node:util";

const getClient = (domain, apiToken, userEmail) => {
	const headers = {
		Authorization: `Basic ${Buffer.from(`${userEmail}:${apiToken}`).toString("base64")}`,
		Accept: "application/json",
		"Content-Type": "application/json",
	};

mvhenten

// Based on work from @sjohnsonaz in https://github.com/openapistack/openapi-backend/issues/157
// Adapted for aws-lambda by @gabrielpoca 
/* eslint-disable biome-ignore lint/suspicious/noExplicitAny: <explanation> */

import type { APIGatewayProxyEvent } from "aws-lambda";
import type { Context, ParsedRequest } from "openapi-backend";
import type { Handler } from "openapi-backend";

type HandlerResponse<T> = {
  statusCode: number;

mvhenten

#!/usr/bin/env node

/**
 * Simple way to hoist package dependencies to the root of the repo.
 *
 * - put common packages in devDependencies
 * - run this script to update all workspaces
 * - make sure to npm install for an updated package-lock.json
 *
 */

mvhenten

Run openvscode-server from Podman

1. Install podman.

apt-get install -y podman

2. Configure some container registries