darkn3rd

I would first establish the workload characteristics and scaling target: current and expected traffic, read/write ratio, latency objective, data volume, availability requirements, regional requirements, and budget. Then I would scale each tier independently, because the application, cache, and database have different bottlenecks and consistency trade-offs.

1. Start with requirements

Before choosing an architecture, I would ask:

• Is traffic steady, bursty, or seasonal?
• Is the application stateless?
• What are the read/write ratios?
• What is the current bottleneck?

darkn3rd

#!/usr/bin/env bash
set -euo pipefail

if [[ ! -f "./vpc-outputs.env" ]]; then
  echo "ERROR: vpc-outputs.env not found in current directory." >&2
  exit 1
fi

source ./vpc-outputs.env

darkn3rd

#!/usr/bin/env bash

update_homebrew_path() {
  # Google Style: Declare locals at the top.
  # Capitalized because these will hold environment-like path strings.
  local BREW_PREFIX
  local GNU_PATHS
  local KEG_PATHS
  local RAW_COMBINED
  local DEDUPE_LOGIC

darkn3rd

# Run Script to fetch monitors 
# --------------------------------------
# WORKSPACE=$(terraform workspace show)
# [[ -d "./tfvars" ]] && VAR_DEFS_PATH="./tfvars"
# [[ -d ".././tfvars" ]] && VAR_DEFS_PATH=".././tfvars"
# [[ -z "$VAR_DEFS_PATH" ]] && { echo 'VAR_DEFS_PATH not specified. Aborting' >&2 ; exit 1; }
# DD_API_KEY="$(awk -F'"' '/dd_api_key/{ print $2 }' $VAR_DEFS_PATH/$WORKSPACE.secret.tfvars)"
# DD_APP_KEY="$(awk -F'"' '/dd_app_key/{ print $2 }' $VAR_DEFS_PATH/$WORKSPACE.secret.tfvars)"
# [[ -z "$DD_API_KEY" ]] && { echo 'DD_API_KEY not specified. Aborting' >&2 ; exit 1; }
# [[ -z "$DD_APP_KEY" ]] && { echo 'DD_APP_KEY not specified. Aborting' >&2 ; exit 1; }

darkn3rd

variable "pipelines" {
  description = "List of pipelines with their processors"
  type = list(any)
}

resource "datadog_logs_custom_pipeline" "pipelines" {
  for_each = { for idx, pipeline in var.pipelines : idx => pipeline }

  name       = each.value.name
  is_enabled = each.value.is_enabled

darkn3rd

variable "records" {
  description = "Cloudflare DNS zone records"
  type = set(object({
    tf_obj_id = string # tf key used to organize records
    name      = string
    proxied   = bool
    value     = string
    priority  = number
    ttl       = number
    type      = string

darkn3rd

#####
# qemu command created by vagrant-qemu plugin example
#
# Description: 
#  This is an example of what the vagrant-qemu plugin creates.
#  I am not sure if any of this works, this shell script is theory 
#  crafting for documentation and understanding.
##########################################

#####################

darkn3rd

Linux Virtual Machines with Private Network on an Apple M1 Device

Background

The aim was to be able to:

1. Run multiple Linux VMs on an Apple M1/ARM device
2. Use Apple's HVF for native performance speeds
3. Configure VMs to allow network access to each other
4. Configure VMs to allow access to the internet
5. Not rely on custom modifications of software

darkn3rd

How to run Windows 10 on ARM or Ubuntu for ARM64 in QEMU on Apple Silicon Mac

Here is easy steps to try Windows 10 on ARM or Ubuntu for ARM64 on your Apple Silicon Mac. Enjoy!

NOTE: that this is current, 10/1/2021 state.

Running Windows 10 on ARM

1. Install Xcode from App Store or install Command Line Tools on your Mac

darkn3rd

Running Linux and Windows on M1 with QEMU

30.11.2020: Updated with the new patchseries and instructions for Windows

02.12.2020: Added tweaks

08.12.2020: Updated with patchseries v4

31.01.2020: Updated with patchseries v6