tylerflint

#############################################
# Base Apache Server Configuration          #
#############################################
User apache
Group apache
ServerAdmin root@localhost
ServerTokens OS
ServerRoot "/etc/httpd"
PidFile run/httpd.pid
Timeout 300

tylerflint

run.config:
  engine: ruby

  cache_dirs:
    - node_modules
    - vendor/assets/bower_components
    - .bundle
    - vendor/bundle

  extra_packages:

tylerflint

1. install rvm

Install curl as a dependency of the rvm installer:

aptitude install curl

Installing rvm as a multi-user install. This is so that everybody can use the gemsets, however we can also run the rails app as a non root user:

sudo bash < <(curl -sk https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

tylerflint

Workflow

This workflow was designed specifically to aid in development and testing the components within smartos-live/src. SmartOS is designed to be a read-only operating system that is loaded onto a ramdisk during boot. While this design is very helpful in a datacenter, it is not well suited for local incremental development. This workflow will temporarily alter the behavior of SmartOS to allow a quick and iterative workflow for development.

Goals

The goals of this workflow are to allow the following:

1. Development occurs directly on the developers workstation, in his or her native editor and toolchain.
2. All sources within the smartos-live/src directory are compiled when changed, including c files.

tylerflint

# papertrail
# export LOGGER_TOKEN=(from /etc/logvac/config.json)
# export APP=app-name
# export ENDPOINT=logs7.papertrailapp.com:16810
curl -k -v -X POST -H "X-Auth-Token: $LOGGER_TOKEN" https://127.0.0.1:6361/drains -d '{"type": "papertrail", "id": "${APP}", "endpoint": "${ENDPOINT}"}'

# datadog
# export LOGGER_TOKEN=(from /etc/logvac/config.json)
# export APP=app-name
# export KEY=(from dashboard)

tylerflint

Generally speaking, Nanobox treats containers as lightweight VMs. So, many concepts from docker swarm or kubernetes won’t track with our system. If you’re familiar with solaris zones, the way we treat containers is very much like a solaris zone.

At a high level, docker (swarm) and kubernetes are moving the process management, logging, supervision, networking, etc out of the container and into the orchestration layer. Details aside, conceptually, they are moving pretty aggressively towards the notion of running simple processes inside of a namespace and a filesystem chroot, then the orchestration layer handles everything else.

Ultimately, the developer is left to define the service details in every implementation, like which commands to run, etc. I don’t necessarily think that’s a bad thing, in fact I think the implementation of kubernetes’ pods is pretty clever, thats just the direction they're going.

Our system was designed differently, on the notion of autonomy. Essentially, a docker image should have e

tylerflint

run.config:
  engine: nodejs
  
  dev_packages:
    - forego
  
  extra_packages:
    - nginx-nchan
    
web.main:

tylerflint

You are an artisan, not an engineer

An engineer makes something work. You are more than that, you are an artisan. Artisans practice a craft and may through experience and aptitude reach the expressive levels of an artist.

Approach your work as a master craftsman.

Style matters

Just because we're building infrastructure and tools doesn't mean it can't be cool, stylish, and fun. Aesthetic matters. See The Substance of Style

tylerflint

# generate nginx config
cat > "$(payload 'build_dir')/etc/nginx/nginx.conf" <<END
daemon off;
worker_processes  1;

error_log  /data/var/log/nginx/error.log;

events {
    worker_connections  1024;
}

tylerflint

Create a boxfile.yml

First create a boxfile using the content from this gist

Start the local env

nanobox run

Create a new site