jpluscplusm

BOSH Links: Why and How

Audience: anyone in the BOSH ecosystem, whether you work on something open-source or proprietary

"BOSH Links" is a feature which simplifies how data is shared between BOSH-deployed jobs that need to collaborate with one another (e.g. a web server and its backing database). Like many BOSH things, the whole "BOSH Links" thing can seem counter-intuitive at first, and it may not be clear why things are the way they are. This note hopes to show some of the powerful benefits of BOSH Links, and provide examples and explanations that make things more intuitive.

1. Why?
2. BASIC: A simple problem statement
3. BASIC: Putting the puzzle pieces together
4. ADVANCED: But what about...

jpluscplusm

#!/bin/bash

# vpnc-script wrapper for use with openconnect that routes all AWS IP ranges over the VPN.
# Pass any additional IP ranges to be routed as args to the script.
#
# Requirements: bash, curl and jq.
#
# Example usage:
# openconnect https://vpn.example.com/profile --script '/path/to/vpnc-script-aws'
#

jpluscplusm

Currently, there is an explosion of tools that aim to manage secrets for automated, cloud native infrastructure management. Daniel Somerfield did some work classifying the various approaches, but (as far as I know) no one has made a recent effort to summarize the various tools.

This is an attempt to give a quick overview of what can be found out there. The list is alphabetical. There will be tools that are missing, and some of the facts might be wrong--I welcome your corrections. For the purpose, I can be reached via @maxvt on Twitter, or just leave me a comment here.

There is a companion feature matrix of various tools. Comments are welcome in the same manner.

jpluscplusm

This is a copy/paste from an internal wiki on how we should use docker

This guide is to serve as an outline of internal best practices to using Docker. The idea is to give enough information to allow engineers to create containers for new stack components while minimizing the cleanup required to make them production ready.

Concepts

Before we get to the practices, it's important to understand WHY we are doing this. The key concepts we're concerned about with broad Docker usage are provenance, determinism, repeatability and auditability.

Provenance

Provenance refers to knowing WHERE something comes from. Generally with the end use of software, this is easy:

• Maven artifacts are pulled from central

jpluscplusm

Scale Summit 2014

Intro, MBS

• Chatham House Rule, so no attribution of ideas to people or companies

ideas for sessions

• bootstrapping environments (without object stores)
• service discovery
• removing spofs

jpluscplusm

server {
  listen [::]:80;
  listen 80;
  server_name "~^(?<thishost>[^.]+.)?(subdomain.example.com)$";
  access_log off;

  location / {
    resolver 8.8.8.8; # or whatever your server can use
    sub_filter_once off;
    sub_filter 'thepiratebay.se' 'subdomain.example.com';

jpluscplusm

#!/usr/bin/env ruby
require 'sinatra'
require "sinatra/reloader" if development?
require 'chef'
require 'rack/flash'
require 'haml'

POSSIBLE = [('a'..'z'),('A'..'Z'),(0..9),'.','/'].inject([]) {|s,r| s+Array(r)}

set :sessions, true