Skip to content

Recipies

Jump to bottom
Alex Karasulu edited this page Mar 13, 2018 · 3 revisions

I really hate to hardcode anything and want to always maximize reuse. Smart examples here help make life easier

Passwords and SSH Keys

I never hardcode things like passwords and keys. I keep them in my personal configuration to override existing values. So here's what the contents of my $HOME/.vagrant-subutai/vagrant-subutai.yml looks like:

PASSWORD_OVERRIDE: 'secret'
AUTHORIZED_KEYS: '/Users/jdoe/.ssh/authorized_keys'
BRIDGE: 'en0: Ethernet 1'
APT_PROXY_URL: 'http://apt:3142'
PROVISION: false

NOTE: This is on my Mac, so these values will be different on Linux or Windows.

Avoid Annoying Bridge Question

You'll notice that I also specified a BRIDGE value for the interface bridge device I want to use on my machine. This way Vagrant stops annoying me with the question about which bridge interface I want to use.

Provisioning

Sometimes I uses the Subutai VM's for things NOT related to Subutai. So I just don't bother provisioning anything more than the OS. Later on if I need to I can always change this value for the project and just re-provision using:

vagrant provision

Performance

I've got my own APT proxy cache so I have the APT_PROXY_URL variable set. I also have a CDN cache node but I just put that into DNS so I don't have to specify anything. Installations are fast, I feel good.

Slow Internet?

Use a caching apt proxy!

If you're constantly downloading building new machines you should use the project's provided Dockerfile or Vagrantfile to launch an apt package caching proxy service. A Dockerfile and Vagrant file is provided for this in the packer project:

Local CDN Cache Node

This speeds up package downloads by locally caching them.

We have a Subutai Templates for all environments on the Bazaar. If you have a Subutai Peer setup on your LAN, you can subutai import the template you need and expose port 8338. You'll need to setup local DNS to point the relevant CDN environment domain names to it:

subutai[-${env}] import cdn-cache

You can build your images using the directions here: https://github.com/subutai-io/gorjun/wiki/Nginx-cache

Developers: Modal Hook Scripts

The hook feature involves two parameters for specifying an alternative snap package or management template: SUBUTAI_SNAP and SUBUTAI_MAN_TMPL. These parameters have path values and are modal. Modal, meaning they can point to either a non-executable file to upload into the VM or to a hook shell script (*Nix + macOS) or a batch file (Windows) to execute. The hook script returns a single value, the path to the file to upload.

This feature has been put in place to facilitate integration with build systems and to provide developers with the tools they need to test changes to Subutai in isolation. The hook script may fire up a process, VM, or container to build the file that will be provisioned. It may ask Jenkins to build it, wait, then pull down the file to provide it to the Subutai Vagrant box.

The two parameters for replacing the Subutai Snap, and the Subutai Management Template will be automatically triggered when the following sibling files to the Vagrantfile are found:

Parameter Default Sibling Hook File
SUBUTAI_SNAP snap_hook.[sh|bat]
SUBUTAI_MAN_TMPL management_hook.[sh|bat]

So values don't need to be set if these file names are used for hook scripts.

This is to make life easy for developers, testers, and maintainers where you can point to different build configurations with a symbolic link. The snap_hook.sh link can point to any build configuration. Here I switch from foo.sh to bar.sh by changing that symlink:

newton:test akarasulu$ ls -l
total 72
-rw-r--r--  1 akarasulu  staff  79 Nov 29 05:03 Vagrantfile
-rwxr-xr-x  1 akarasulu  staff  80 Nov 30 01:59 dev.sh
-rw-r--r--  1 akarasulu  staff  78 Nov 30 03:29 dev.yml
-rwxr-xr-x  1 akarasulu  staff  80 Nov 29 10:49 master.sh
-rw-r--r--  1 akarasulu  staff  78 Nov 30 03:29 master.yml
-rwxr-xr-x  1 akarasulu  staff  80 Nov 30 03:29 prod.sh
-rw-r--r--  1 akarasulu  staff  78 Nov 30 03:29 prod.yml
lrwxr-xr-x  1 akarasulu  staff   6 Nov 30 03:28 snap_hook.sh -> dev.sh
lrwxr-xr-x  1 akarasulu  staff   8 Nov 30 03:29 vagrant-subutai.yml -> dev.yml

Nothing stops you from using snap_hook.sh as the actual builder script. That is you don't need to use the technique above. Notice I do the same thing with the vagrant-subutai.yml file, pointing it to the configuration I want to use. This is great for devops, ci, and testing.

WARNING: You must make sure the environment associated with the alternative snap or management package coincides with the SUBUTAI_ENV setting.

Clone this wiki locally