irvingpop

# ssh key generator data source expects the below 3 inputs, and produces 3 outputs for use:
#  "${data.external.ssh_key_generator.result.public_key}" (contents)
#  "${data.external.ssh_key_generator.result.private_key}" (contents)
#  "${data.external.ssh_key_generator.result.private_key_file}" (path)
data "external" "ssh_key_generator" {
  program = ["bash", "${path.root}/../ssh_key_generator.sh"]

  query = {
    customer_name = "${var.customer_name}"
    customer_group = "${var.customer_group}"

irvingpop

From 4fb2f312c60cd10f57c08051d4243d3e62b1fbfb Mon Sep 17 00:00:00 2001
From: Irving Popovetsky <[email protected]>
Date: Fri, 18 Aug 2017 13:05:55 -0700
Subject: [PATCH] Fix notifications habitat binds so that they can be optional
 and remove an unneeded one for database

---
diff --git a/notifications/habitat/config/env b/notifications/habitat/config/env
index faa23c642..19d70da22 100644
--- a/notifications/habitat/config/env

irvingpop

AWSTemplateFormatVersion: '2010-09-09'
Parameters:
  KeyName:
    Type: AWS::EC2::KeyPair::KeyName
    Description: Name of an existing EC2 KeyPair to enable SSH access to the ECS instances.
  VPC:
    Type: AWS::EC2::VPC::Id
    Description: Select a VPC that allows instances access to the Internet.
  SubnetIds:
    Type: List<AWS::EC2::Subnet::Id>

irvingpop

# Create a systemd service that runs at shutdown to remove one's node and client from the chef server,
#  useful in AutoScale and Terraform-managed scenarios
#  not useful in cases where you may want to shutdown (but not terminate) a node

systemd_unit 'chef-cleanup.service' do
  content('Unit' => {
            'Description' => 'Delete my own Chef node and client objects at shutdown/termination',
            'DefaultDependencies' => 'no',
            'Before' => 'shutdown.target halt.target',
          },

irvingpop

{
    "mycookbook": {
        "attribute1": "${attribute1}",
        "attribute2": "${attribute2}"
    },
    "run_list": [
        "recipe[${recipe}]"
    ]
}

irvingpop

#!/bin/bash -ex
# All of this is to be run from the Automate server, assumes you have a ChefDK installed there

# Step 0, supply the right windows IP, username, password

WINDOWS_HOST='10.42.46.165'
WINDOWS_USER='Administrator'
WINDOWS_PASSWORD='VerySecurePassword'

irvingpop

#!/bin/bash
# Tune the elasticsearch shard and replica count after chef-backend has been setup, but before any Frontends have been configured
# based on the following docs:
#   https://www.elastic.co/guide/en/elasticsearch/guide/current/replica-shards.html
#   https://www.elastic.co/guide/en/elasticsearch/guide/current/_scale_horizontally.html
#   https://www.elastic.co/blog/clustering_across_multiple_data_centers
#
#  This process will change once this Chef Server PR has been accepted: 
#    https://github.com/chef/chef-server/pull/988

irvingpop

Chef Server

• The Chef Server runbook: https://docs.chef.io/runbook.html
• Tuning the Chef Server for scale: http://irvingpop.github.io/blog/2015/04/20/tuning-the-chef-server-for-scale
• pgAdmin 3: https://www.pgadmin.org/

Linux

• Brendan Gregg - Linux Performance: http://www.brendangregg.com/linuxperf.html
• Brendan Gregg - USE method: http://www.brendangregg.com/usemethod.html

Postgres

irvingpop

Note to customers have used the data purging feature (—remove-partitions) introduced in Reporting 1.3.0

Due to a bug in the upgrade process, If you’ve removed any of the 2015 data partitions the upgrade will fail. To determine if this applies to you, as well as to resolve the issue, run the following steps on your Standalone or Primary Backend Chef Server:

1. To see if you’ve removed them, query the list of reporting tables and verify that you have node_run_2015_* and node_run_detail_2015_* tables (12 of each):

# sudo -u opscode-pgsql /opt/opscode/embedded/bin/psql opscode_reporting -c "\dt"
could not change directory to "/root"
                    List of relations

irvingpop

Customer Scenario

A customer has a Chef Server 12 (HA - DRBD) in Production. They want to test an in-place upgrade (or maintenance) using their current OPC Production data and config. This gives us a good chance to make corrections if we find that their data is too broken for the migrations to handle, and gives the customer experience in managing the upgrade in Production.

The sequence of events will broadly be these:

• Install the same version of Chef Server on the target HA Test cluster
• Restore data from Production instance backup (LVM snapshot or full-stop backup)
• Test