- Chatham House Rule, so no attribution of ideas to people or companies
- bootstrapping environments (without object stores)
- service discovery
- removing spofs
#!/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 |
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'; |
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.
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 refers to knowing WHERE something comes from. Generally with the end use of software, this is easy:
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.
#!/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' | |
# |
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.