The recipe we are going to execute is a simple bash script that restarts php-fpm. You can expand on this and write more complicated recipes. As a reminder, you may write recipes in bash, perl, python, ruby, go, node.js and can even inject arguments at execution.

Pricing for Site24x7 starts at $9 a month and $12 a month for Commando.io. Below is a short video walkthrough, so sit back grab some popcorn and start automating your infrastructure today!

Last Updated: 11/10/2017

Below is a high level HTTPS security and performance comparison table between Google Cloud Storage and Amazon Simple Storage Service (S3). While cost, performance, and reliability are certainly factors in making a cloud storage decision the scope of this post is specifically limited to HTTPS.

Single server Redis is easy

// redis1.ourdomain.io //
sudo apt-get install redis-server

Primary/slave replication is trivial

// redis2.ourdomain.io //
sudo apt-get install redis-server

# edit /etc/redis/redis.conf
slaveof redis1.ourdomain.io 6379

sudo service redis-server restart

Automatic service discovery and failover is HARD

The minimum number of servers for automatic service discovery and high availability using Sentinel is 3. So we need another server.

// redis3.ourdomain.io //
sudo apt-get install redis-server

# edit /etc/redis/redis.conf
slaveof redis1.ourdomain.io 6379

The default redis-server package on Ubuntu does not include an init script for redis-sentinel, so on each server we have to set that up.

cd /etc/init.d
sudo touch redis-sentinel
sudo chmod +x redis-sentinel

Put the following into /etc/init.d/redis-sentinel on each server:

#!/bin/bash
### BEGIN INIT INFO
# Provides:          redis sentinel
# Required-Start:    $all
# Required-Stop:    $all
# Default-Start:    2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Starts redis sentinel
# Description:      Starts redis sentinel using start-stop-daemon
### END INIT INFO

NAME=redis-sentinel
BIN=/usr/bin/redis-server
SENTINEL_PID=/var/run/redis/sentinel.pid
CMD=$1

start() {
        echo "Starting $NAME ..."
        exec 2>&1 $BIN /etc/redis/sentinel.conf --sentinel | logger -t sentinel &
        echo $! > "${SENTINEL_PID}";
}

stop() {
        PID=`cat $SENTINEL_PID`
        echo "Stopping $NAME ($PID) ..."
        kill $PID
}

restart() {
        echo "Restarting $NAME ..."
        stop
        start
}

case "$CMD" in
        start)
                start
                ;;
        stop)
                stop
                ;;
        restart)
                restart
                ;;
        *)
                echo "Usage $0 {start|stop|restart}"
esac

Now we need to setup the redis-sentinel service to start at boot on each server.

sudo apt-get install sysv-rc-conf
sysv-rc-conf redis-sentinel on

Now in /etc/redis/sentinel.conf on each server add the following lines:

 daemonize yes
 pidfile "/var/run/redis/sentinel.pid"
 loglevel verbose
 logfile "/var/log/redis/sentinel.log"
 sentinel monitor mymaster redis1.mydomain.io 6379 2
 sentinel down-after-milliseconds mymaster 10000
 sentinel failover-timeout mymaster 60000
 sentinel parallel-syncs mymaster 1

Now in /etc/redis/redis.conf on each server add the following lines:

  repl-ping-slave-period 5
  slave-serve-stale-data no
  repl-backlog-size 8mb
  min-slaves-to-write 1
  min-slaves-max-lag 10

Assuming that all worked, let's try and start all redis-server and redis-sentinel daemons on each server:

 sudo service redis-server start
 sudo service redis-sentinel start

Testing it all out

Let's take down the primary Redis server for 2 minutes, and see if Sentinel kicks in.

 // redis1.mydomain.io //
 redis-cli -p 6379 DEBUG sleep 120

And finally check which server is the Redis primary on redis2.mydomain.io:

 // redis2.mydomain.io //
 redis-cli -p 26379
     127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster

The CLI is a perfect solution for triggering deployments on servers via a git hook, or automating infrastructure without harnessing the entire Commando.io API, and writing a bunch of boilerplate code.

Commando.io is excited to announce integration with Linode, adding to our existing integrations with Amazon AWS, DigitalOcean, and Rackspace. Instead of having to manually add Linode servers, you can now automatically import them which saves you time and is less error prone. We also automatically tag servers with the Linode datacenter and server size.

Some common use-cases are checking for package updates (http://public.recipes/JHdgXs), running snapshot backups (see our Google compute example http://public.recipes/BFz5wN), and other tasks normally stashed away into crontab on servers.

Learn about scheduling in one minute by watching the walkthrough video below.

We knew we wanted something simple, but also recognizable. We started experimenting with a glyph before the typeface, and came up with the concept of a cursor at the end of a C.

Logos

For use on light backgrounds.
https://storage.googleapis.com/commando/commando-logo.png

For use on dark backgrounds.
https://storage.googleapis.com/commando/commando-logo-dark.png

Glyph (Favicon).
https://storage.googleapis.com/commando/commando-glyph.png

Color palettes

Blue
#53b2e5

Dark Gray
#31343c

Learn about recipe arguments in one minute by watching our walkthrough video.

You specify recipe arguments with the following syntax in a recipe:

{{ arg: $unique_key }}

At execution-time, in the web interface we will prompt for the value of each argument and inject them into the recipe.

When running API executions, you may pass recipe arguments with the recipe_arguments post parameter. See the API documentation for further details.

Enjoy recipe arguments, and have fun automating with Commando.io.

The Commando.io service integration can be found under repository settings in GitHub and clicking on Webhooks & Services. Then simply click the Add service button and type in Commando.io. As a reminder, you must be on a paid plan to utilize the Commando.io API and thus the GitHub service integration.

Finally, below is an example public recipe that calls git clone or git pull to automatically fetch a git repository. This is an ideal recipe to execute to deploy code from GitHub to your servers.

Enjoy the integration, and have fun automating with Commando.io.

Last Updated: 11/10/2017

At Commando.io we make sure we are always on top of any potential security exploits or vulnerabilities. Unfortunately, lately there has been a steady stream of SSL related issues (Heartbleed and POODLE come to mind). Fortunately patching some of the most prominent issues only requires updating a few NGINX directives.

We figured we would share our SSL NGINX configuration blocks which are used on all Commando.io web servers. Let's break the NGINX directives into two logical sections. The first being security and the second related to performance and optimization.

Security

http {  
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
}

The above configuration provides robust perfect forward secrecy and mitigates against POODLE by removing SSLv3 support. It should also result in an A rating on Qualys SSL LABS as well. If you'd like an A+ rating, you'll need to implement strict transport security as well.

See the Commando.io SSL LABS report at: https://www.ssllabs.com/ssltest/analyze.html?d=commando.io

Note: This cipher suite does prevent some older clients (specifically IE6 on Windows XP) from establishing connections, but the majority of our traffic comes from users on Chrome so this is a non-factor for us. Evaluate your requirements by looking at your own traffic.

Performance

http {  
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/stapling.trusted.crt;  
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 10s;

    ssl_session_cache shared:SSL:32m;
    ssl_buffer_size 8k;
    ssl_session_timeout 60m;
    ssl_session_tickets off;
}

server {  
    # you may replace spdy with http2 if your version of NGINX supports HTTP/2
    listen 443 deferred ssl spdy;
}

The first set of performance directives enables OCSP stapling. We've written a dedicated blog post on OCSP stapling previously, so check that out for more information.

Next, we enable NGINX SSL cache, which provides SSL session resumption support. We allocate a shared 32MB of space (one megabyte can store about 4000 sessions according to the NGINX documentation). We set a 60 minute timeout on SSL sessions and also set ssl_buffer_size to 8K to minimize time to first byte (the NGINX default is 16K).

Finally, in the server block we enable the deferred directive and turn on SPDY support. You may replace spdy with http2 if your version of NGINX supports HTTP/2. Verify that SPDY is enabled on your site with SPDYCheck a great service by zoompf.

We'd also like to recommend a great service we recently found and signed up for called Snitch. Snitch will automatically check your SSL certificate and configuration at specified intervals. It looks for upcoming expiration, security issues, and performance recommendations and then alerts you of anything that needs attention.

All Commando.io web servers now disable SSLv3 to mitigate against the recently discovered SSL POODLE vulnerability.

View our SSL Labs report.

(Poodle image via Flickr, CC license.)

We think this is going to be a game changer. Imagine running an execution via a git hook. Or, how about running an execution when a PagerDuty alert is triggered to automatically fix the issue. We can’t wait to see how you automate your infrastructure and deployments with the Commando.io API.

The Commando.io API is only available to users on paid plans. However, if you sign up for a paid plan today, you’ll instantly get a $25 credit at DigitalOcean.

Below is a short video walkthrough of the API, so sit back, grab some popcorn and check it out.

We created a short three minute video walking through the entire process using Commando.io and a CentOS 6.5 droplet on DigitalOcean. In the video, we show how to create a maintenance user, and then allow this user to run yum commands to install, remove, or update packages using sudo without prompting for a password. The same principle can be applied to creating a deploy user that is allowed to restart services such as nginx or apache.

Below are public links to the two recipes in the video for reference.

(RECIPE) CREATE MAINTENANCE USER
https://public.recipes/U5oFoM

(RECIPE) INSTALL RUBY
https://public.recipes/tlYP2e

Commando.io is excited to announce support for two-factor authentication via Google© Authenticator. When you enable 2FA, it adds an additional layer of security to your Commando.io account. When logging in, after providing your e-mail address and password, you will be asked for a two-factor authentication code that is delivered to your mobile device. This additional step ensures that a malicious person who has discovered your password will not be able to log in to your account.

We strongly urge all users to enable two-factor authentication. Simply log in, navigate to the users page, and click the button above your user details.