briceburg

What is ArgoCD?

ArgoCD does a great job managing application "deployment" configuration across multiple k8s clusters. It does an equally well job maintaining "core" or "baseline" configuration across the clusters (e.g. ingress class CRDs), including the intrinsic ability to manage itself.

It works by watching for configuration changes in registered git repositories and performing a "sync" whenever there is a difference in the manifests it has applied (aka "live") and the ones in git (aka "desired"). "Syncs" can be performed automatically, through the API, or manually -- and the configuration repositories are typically polled for changes every 3m.

GitOps

This concept of responding to and applying infrastructure configuration changes in response to a git repository's state is called "gitops".

briceburg

#!/usr/bin/env bash
set -eo pipefail
project_root="$(cd "$(dirname "$0")/.." ; pwd -P)"

default_env="prod"
default_src="Dockerfile"
default_tag="build:latest"

(
    echo "Build Dir: ${BUILD_DIR:=$project_root}" >&2

briceburg

FROM haproxy:2.7-alpine

COPY haproxy.cfg /usr/local/etc/haproxy/haproxy.cfg

ARG SOURCE_COMMIT=""
ENV DD_SERVICE="haproxy" DD_ENV="local" DD_VERSION="$SOURCE_COMMIT"

briceburg

resource "aws_ecr_repository" "repo" {
  name = "foo"
}

data "aws_ecr_authorization_token" "repo" {}


#
# providers.tf
#

briceburg

#!/usr/bin/env python3
import sys
import functools
for line in map(str.rstrip, sys.stdin):
    repls = ('prod', 'production'), ('sdlc', 'staging'), ('sandbox', 'development')
    print("terraform state mv %s %s" % (line, functools.reduce(lambda a, kv: a.replace(*kv), repls, line)))

briceburg

Questions

• should RAILS_ENV == DD_ENV
• should DD_ENV == NAMESPACE_STAGE

how do we make these decisions?

current environment

• lower level deployed heroku apps use 'staging' as RAILS_ENV.

briceburg

releases

• semantic versioning is used
• a branch is created for every major release, e.g. release-1.x, release-2.x, &c.
• when ready to make a release;
  • update any changelogs and documentation with release information, commit/merge to main. ensure CI passes.
  • if backporting fixes into past releases, follow the backporting procedure from containerd, else merge main into the current release branch. e.g. main -> release-2.x.
  • checkout current release branch and update files/version with the current point release, e.g. change 'main' to 2.1.18-rc1.
    • make a release commit (e.g. with message "RELEASE 2.1.18-rc1").
• tag the release using v as a prefix, e.g. git tag v2.1.18-rc1 && git push --tags

briceburg

// the following assumes AWS nitro (e.g. t3.*, m5.*, &c) instances (which use /dev/nvme0n1 as root disk)
// "safely" switches from MBR to GPT partitioning in Ubuntu < 21.04 or other AMIS. 
// Tested using gdisk 1.0.3 from 18.04 / Bionic.
// after the change, you can use >2TB root disks. either initially, or by resizing a smaller one -- in nitro and non-nitro types

provisioners: [
   {
      "type": "shell",
      "inline": [
        "echo Converting to GPT - AWS nitro type instance",

briceburg

import com.cloudbees.plugins.credentials.*;
import com.cloudbees.plugins.credentials.domains.Domain;
import org.jenkinsci.plugins.plaincredentials.impl.FileCredentialsImpl;

//
// modify fileName to match the filename of the secret(s) you want to print.
//  (ID would probably be more helpful... yay stack overflow copy pasta)
// alternatively comment out the filter [line 15] to dump all secret files.
// 
def fileName = "secrets.env"

briceburg

#!/bin/bash
set -e

if [ -n "$POSTGRES_DATABASES" ]; then
  echo "POSTGRES_DATABASES provided. Creating multiple databases..." >&2
  IFS=', '; for db in $POSTGRES_DATABASES; do
    echo "Creating '$db'" >&2
    psql -v ON_ERROR_STOP=1 --username "$POSTGRES_USER" <<-ESQL
      CREATE USER "$db";
      CREATE DATABASE "$db";