Skip to content

Instantly share code, notes, and snippets.

View ferricoxide's full-sized avatar

Thomas H Jones II ferricoxide

View GitHub Profile
@ferricoxide
ferricoxide / EndPoints_TF.md
Last active June 28, 2022 14:05
Iterative AWS VPC Endpoint Creation

Recently, one of my customers requested that I create some Terraform-based automation to help them deploy several (AWS) VPC Endpoint definitions into their accounts. This customer maintains a set of cloud-hosted environments for development, integration, testing and production activities. This meant that I was going to have to write things in a way that was going to be flexible enough to be repeatably-excecuted across all their environments.

Further, when I asked the customer for a specific list of services they wanted endpoints created for, the response I got back was basically, "all of them?". Previously, the customer had been creating per-service automation as they needed it. So, they already had redundant code that could have been refactored to use iterations rather than repeated chunks of all-but-identical code. Given that there's, like, four dozen VPC endpoint services that can be configured, I especially didn't want to go down their prior "copy the existing code to a new block and edit one string" met

@ferricoxide
ferricoxide / Linux_EBS_Compatability_Across_Generations.md
Created December 8, 2018 01:21
Describes methods for making CFn templates for Linux EC2 instances compatible across generations

Intro

With AWS's introduction of fifth generation instance types, EC2 instances' block-devices' device-naming changes. In the first- through fourth-generation instance-types, block-devices' device-naming was based on the Xen Virtual Device (XVD) storage-driver. The resulting device node-names took the form /dev/xvdN. With fifth-generation instance types, AWS switches to presenting virtual NVMe devices to the instance. These devices' node-naming take the form dev/nvmeXnY (where X is representative of the device's number on the virtual NVMe bus and Y is representative of the partition on that device). In order for CloudFormation (CFn) templates for Linux-based EC2s to function correctly for older instance-families and fifth-generation instance families, the templates need to be have device-naming selection-logic added to them. Typically, this will mean additional code within a CFn template's Conditions{} and Mappings{} sections. Additionally, AWS::EC2::Instance resource-types' Properties{} se

@ferricoxide
ferricoxide / Linux_EBS_Compatability_Across_Generations.md
Created December 8, 2018 01:19
Describes methods for making CFn templates for Linux EC2 instances compatible across generations

Intro

With AWS's introduction of fifth generation instance types, EC2 instances' block-devices' device-naming changes. In the first- through fourth-generation instance-types, block-devices' device-naming was based on the Xen Virtual Device (XVD) storage-driver. The resulting device node-names took the form /dev/xvdN. With fifth-generation instance types, AWS switches to presenting virtual NVMe devices to the instance. These devices' node-naming take the form dev/nvmeXnY (where X is representative of the device's number on the virtual NVMe bus and Y is representative of the partition on that device). In order for CloudFormation (CFn) templates for Linux-based EC2s to function correctly for older instance-families and fifth-generation instance families, the templates need to be have device-naming selection-logic added to them. Typically, this will mean additional code within a CFn template's Conditions{} and Mappings{} sections. Additionally, AWS::EC2::Instance resource-types' Properties{} se

@ferricoxide
ferricoxide / mule-esb.service
Created August 27, 2018 19:36
systemd Unit file for Mule ESB
[Unit]
Description=Mule ESB
After=network.target network-online.target
Wants=network-online.target
[Service]
ExecStart=/opt/mule-esb/bin/mule start
ExecStop=/opt/mule-esb/bin/mule stop
ExecReload=/opt/mule-esb/bin/mule restart
Group=mule
@ferricoxide
ferricoxide / keybase.md
Created July 8, 2018 17:06
Verification for KeyBase.IO

Keybase proof

I hereby claim:

  • I am ferricoxide on github.
  • I am ferricoxide (https://keybase.io/ferricoxide) on keybase.
  • I have a public key whose fingerprint is CFBC BAA3 D37A BB5B 321F 55A4 17BB 6C98 31DE 6093

To claim this, I am signing this object: