My notes from the Meet Chef course at http://pluralsight.com/training/Courses/TableOfContents/meet-chef
Chef is a Ruby framework for automating, reusing and documenting server configuration. It's like Unit tests for your servers.
#!/bin/bash | |
SNAPID="SNAP" | |
BACKUPDBID="TEMPDB" | |
#config groups | |
SECURITYGROUP="Mysecgrup" | |
PARAMSGROUP="Myparamsgrup" | |
#rds verifying commands |
Estimated total time to execute: 2hr not including pre-replication | |
Ensure performance test make_doc script has production endpoint | |
Comment out deploys tests, DO NOT COMMIT | |
Setup SSH tunnel between AWS background-001 to Linode MySQL | |
Replicate Linode MySQL to AWS (3hr+) as docraptor-production | |
One-time copy non-queue Redis data | |
Verify AWS endpoint working | |
./script/service_test http://aws.docraptor.com && ./script/service_test https://aws.docraptor.com |
#!/bin/bash | |
# Disclaimer - make backups, use at your own risk. | |
# | |
# Based on this comment: http://stackoverflow.com/a/13944924/843067 | |
# Views and stored procedures have to be done separately. | |
OLDDB="old_db_name" | |
NEWDB="new_db_name" | |
MYSQL="mysql -u root -pyour_password " |
source :rubygems | |
# We are not loading Active Record, nor Active Resources etc. | |
# We can do this in any app by simply replacing the rails gem | |
# by the parts we want to use. | |
gem "actionpack", "~> 4.0" | |
gem "railties", "~> 4.0" | |
gem "tzinfo" | |
# Let's use thin |
#XLarge DBInstanceClassMemory = 15892177440 = 14.8GB | |
#/32 = 496630545 = 473MB | |
#/64 = 248315272 = 236MB | |
#/128 = 124157636 = 118MB | |
#/256 = 62078818 = 59MB | |
#/512 = 31039409 = 29MB | |
#/12582880 = 1263 #default same divisor as max_connections = 4041.6MB = 4237924762 | |
#/25165760 = 623 # half of max_connections = 1993.6MB | |
#/50331520 = 315 # quarter of max_connections = 1008MB = 1056964608 | |
#*(3/4) #default innodb pool size = 11922309120 |
include $(GOROOT)/src/Make.inc | |
GOFMT=gofmt -spaces=true -tabindent=false -tabwidth=4 | |
all: | |
$(GC) jsontest.go | |
$(LD) -o jsontest.out jsontest.$O | |
format: | |
$(GOFMT) -w jsontest.go |
#!/usr/bin/env ruby | |
#/ Usage: <progname> [options]... | |
#/ How does this script make my life easier? | |
# ** Tip: use #/ lines to define the --help usage message. | |
$stderr.sync = true | |
require 'optparse' | |
# default options | |
flag = false | |
option = "default value" |
My notes from the Meet Chef course at http://pluralsight.com/training/Courses/TableOfContents/meet-chef
Chef is a Ruby framework for automating, reusing and documenting server configuration. It's like Unit tests for your servers.
There are a lot of ways to serve a Go HTTP application. The best choices depend on each use case. Currently nginx looks to be the standard web server for every new project even though there are other great web servers as well. However, how much is the overhead of serving a Go application behind an nginx server? Do we need some nginx features (vhosts, load balancing, cache, etc) or can you serve directly from Go? If you need nginx, what is the fastest connection mechanism? This are the kind of questions I'm intended to answer here. The purpose of this benchmark is not to tell that Go is faster or slower than nginx. That would be stupid.
So, these are the different settings we are going to compare:
#--------------------------------------------------------------------- | |
# | |
# Parse the response from Sonatype Nexus in order to determine the | |
# correct URI for the most recent snapshot of an artifact. | |
# | |
# Usage: | |
# ruby get_latest_snapshot.rb \ | |
# -n http://localhost:8080/nexus \ | |
# -g uk.co.scattercode \ | |
# -a my-artifact \ |