Jeff Dickey jdickey

What We're Trying to Do

Referencing this earlier Gist, of course.

The following are from a series of Ansible Playbooks, associated files, and wrapper shell functions which I have been using for some months for multiple projects, all hosted on DigitalOcean. Until approximately 0130 Singapore time on Wednesday 17 January 2017 (GMT+8; 1730 GMT or 0930 PDT on 16 January), these scripts had been working quite well. The basic workflow is straightforward:

In the new_droplet.yml Playbook,
1. Create a new Droplet, with specified values for name, image, region, size, and other values including ssh_key_ids, which is set to the (single) DigitalOcean SSH key ID for the DO user owning the Droplet to be created;
2. Tag the newly-created Droplet so that it is uniquely identifiable using the Ansible digital_ocean.py dynamic-inventory script;
In the provision_droplet.yml Pla

I've been trying to use Ansible to create and set up a Droplet based on your docker-16-04 image. Creating the droplet using the Ansible digital_ocean module works as expected, but I can't access the Droplet afterwards, as I get an error from ssh.

I can't believe that I'm the first or only customer to try to set things up like this. I've been knocking my head against any information source I can find for two weeks now. Perhaps you can advise?

I've attached my Playbooks and command output as listed below. The dynamic-inventory script referenced as digital_ocean.py is that supplied in the Ansible repo.

Command Output 1 - Create Droplet.log - output from running the new_droplet Playbook (see Item 3);
Command Output 2 - Attempted Provisioning of Droplet.md — output from running the playbook Playbook (see Item 4);
new_droplet.yml - Ansible Playbook tasked with creating and tagging a new Droplet
playbook.ym

Growing Rails Applications in Practice

How to use discipline, consistency and code organization to make your code grow more gently.
As you cycle through patterns, your application is becoming a patchwork of different coding techniques.

All those new techniques actually help, or if you are just adding layers of inderection.
Large applications are large so what we can do is organize a codebase in a way that "scales logarithmically".

This is essentially a duplicate of/companion to this comment on jdickey/rack-service_api_versioning#14.

We have a temporary branch with some new tests for verifying that an invalid SBU causes an HTTP 400 status code to be generated. Commenting out the tests for that, with the code in place, continues to yield a green bar. Enabling the tests causes failures — in apparently unrelated tests; the invalid-SBU-generates-400 tests always pass.

As a reminder, the only known way to run MiniTest tests in a reproducible order requires a somewhat cumbersome syntax to set the randomisation seed; e.g

ruby -e 'require "./test/rack/service_api_versioning/accept_content_type_selector_test.rb"' -- -v --seed=16442

It's not really fair to compare the speed of Ruby binding to the Networking and Cryptography (NaCl) library with that of the Ruby interface to GnuPG Made Easy (GPGME); their execution profiles and environments are so radically different. RbNaCl is a unified library, whereas GPGME is an interface to a set of libraries that interact with at least one server process (GPG-AGENT). Benchmark timings bear this out; whereas generating signatures or encrypting/decrypting data with RbNaCl benchmarks thousands of iterations per second on our development system, GPGME clocks in at a half-dozen IPS for any operation other than verifying a signature (which is relatively speedy at ~50 iterations/second).

One needs to keep in mind that the signing keys and encrypted data for RbNaCl exist natively in binary form only, requiring conversion using [Base64](http://ruby

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256

	- -----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256

	Sunday 1 July 2018 00:50 SGT (GMT+8)

	This is to serve notice that my GPG (GNU Privacy Guard) key has changed with effect from today, Sunday 1 July 2018, following my (revised) standard protocol for key expiration. My new key will remain valid until 1 January 2019. I recommend that other users of GNU Privacy Guard enact such policies and keep revocation certificates for their current keys in offline storage, such as on a thumb drive that is labelled and physically secured separately from their systems.

	# Define ENV variables for development environment
	DATABASE_URL='postgres://postgres:@db:5432/yourapp_development'
	SERVE_STATIC_ASSETS="true"
	WEB_SESSIONS_SECRET="d31b874186058eb00e17d9cde98e3745408b10666112a401a05a0d7ab392d30c"

	# Semi-automatic setup of Docker-running Droplet from within Droplet itself
	#
	# Last updated 2017-01-19 at 14:50 (SGT; GMT+8) by @jdickey
	#
	# ##### Section 1 of 10: Variables used within this script. #####
	#
	# NOTE that several of these must be changed, namely
	# * DOCKER_PASSWD
	# * DOCKER_USER
	# * GITHUB_USER

	-----BEGIN PGP SIGNED MESSAGE-----
	Hash: SHA256

	Friday 30 June 2017 12:30 SGT (GMT+8)

	This is to serve notice that my GPG (GNU Privacy Guard) key has changed with effect from today, Friday 30 June 2017, following my (revised) standard protocol for key expiration. My new key will remain valid until 31 December 2017. I recommend that other users of GNU Privacy Guard enact such policies and keep revocation certificates for their current keys in offline storage, such as on a thumb drive that is labelled and physically secured separately from their systems.

	My old key will continue to work for use in sending me secured messages until it expires later today, Friday 30 June 2017 (and for verifying previously-signed messages thereafter); however, you should be using the new key. To anyone who has signed my old key, I’d greatly appreciate your signing the new one (after satisfying yourself of its provenance and legitimacy, of course).

	This message is signed by

Jeff Dickey jdickey

What We're Trying to Do

Contents

Growing Rails Applications in Practice