Speculative execution
Intro
One of the characteristics of good tools is that they allow creative exploration of ideas, in this post ill cover some speculative flows that Re-ops may support in the future.
The flows are not implemented but Re-ops makes them all possible due to its basic architecture and design.
Voice up
There are a lot of cases where it makes sense to create/start a VM/Physical machine, lets take for example your media server, or a remote development machine, we need those only on specific times yet we usually run them 24/7, but what if we could trigger them based on our needs?
(defn plex-on []
(run (start) | (alexa :reply "ok")))
(defn update-all []
(run (update) | (alexa :reply "ok"))
; start VM instances by saying 'Alexa start plex on'
(wemo (alexa :event "plex power on") (plex-on))
; updating all the machine by saying 'Alexa update all'
(wemo (alexa :event "update all") (update-all))
Now this flow isn't implemented now, I suspect it should pretty easy to implement by exposing a WeMO like interface and pretending to be one or more devices.
Another good options (tough it will require a bit more setup) is to use MQTT, the main issue here is exposing the MQTT broker to Alexa.
Sensors
Another cool idea is to integrate Re-ops with sensors:
; our closet instances (including the physical hypervisor big-iron)
(def closet (Hosts. {} ["foo" "bar" "big-iron"]))
; Stopping our closet instances when it gets too hot (beyond 70c)
(def check-temp [t]
(when (> t 70)
(run (stop hs) | (email to-from "stopped all closed instances, room too hot"))
(watch :temp once-an-hour (check-temp (sensor :temperture))
Here we would stop all the VM's and the hosts if our server room (aka our closet) gets too hot thus preventing hardware meltdown while we are not near, we would need to exposing an MQTT end point and the rest should be pretty easy to follow.
A more far out scenario is automating our machines based on sensor detecting power output from solar panels (is it sunny enough or not) if there isn't enough power draw we would rather not to use costly energy from the wall, our mining farm will start/stop based on the power costs:
; our mining instances (including the hypervisor big-iron)
(def mining-pool (Hosts. {} ["coin-1" "coin-1" "big-iron"]))
; We produce more then 10KW of power lets start mining
(defn power-ok []
(run (start mining-pool) | (pretty "pool resumed"))
; We produce less then 10KW of power lets stop mining
(defn low-power []
(run (stop mining-pool) | (pretty "pool stopped"))
(defn adjust-pool []
(if (> (check-power) 10))
(power-ok)
(low-power))
(watch :power-check once-an-hour adjust-pool)
Scanning
Running a scanning tool on a regular basis is a good way for checking compliance and detect potential security issues:
(def suspicious-ports #{25 ...})
(def scanner (Hosts. {} ["scanner"]))
(defn scan []
(run (open-ports scanner) | (pick (fn [ports] (suspicious-ports ports))) | (email "suspicious ports found"))
(watch :nmap (every-day 22) (scan hosts))
Using the scanner from a dedicated host enables us to:
- Selectively allow password-less sudo access instance for the specific VM.
- Have scanning agents running within segmented networks, thus controlling which ports/networks are exposed.
Spot instances
In AWS we can bid for EC2 instances and offer a max price that we are willing to pay for them, for some workloads (like batch processing) this can be highly cost effective.
The main down side is that we do this bidding only within EC2, what if we could have a cost decision tree that makes a dynamic decision whether to use one provide or another:
; some long batch job
(def batch (Hosts. {} ["worker-1" "worker-2" "master"]))
; AWS cost per hour bellow $0.0058 per Hour
(defn use-ec2 []
(run (destroy batch) | (create batch aws-spot-instance)))
; AWS too expansive we will run locally
(defn use-kvm [c]
(run (destroy batch) | (create batch kvm-medium)))
(defn pick []
(if (< (cost :ec2-cost) 0.0058)
(use-ec2)
(use-kvm)))
; The cost changes will be collected once an hour so we won't flap too often.
(watch :aws-spots once-an-hour pick)
Summary
In this post we explored some of the more speculative (yet possible) flows that Re-ops can enable, having a flexible and fully programmable tool can really lead to interesting ideas and implementation.