Beware of Mismatching Client and Server Binaries on Deis

Until today, I had not had any trouble accessing Deis with a Deis client that didn't match the server.  of course features that didn't exist in the server might not work (or it might; take deisctl ssh from 1.10.0 to a 1.7.3 cluster as an example).

But, beware the jabberwok.  I was missing the client on my mac.  So, I just downloaded the latest client, 1.11.2 to work against a 1.10.1 cluster.

I just needed to certs:add; what could it hurt, I thought.  Certs:add from 1.11.2 client to 1.10.1 server blew away all of the certs as it added the new one.  Yikes!

I was able to ssh into one of the hosts and find them in etcd /deis/certs.  After ensuring that I had all of the certs/keys, I deleted those keys and their parent directory keys. Why?  Because even with the keys, I couldn't add them, presumably because they were really in etcd, just not show up with deis certs:list.

Attempting to push the old keys, I get a 500 error.  I can push new keys --just not keys to replace the ones in a bad state.

Now, I'm looking for someplace else that may contain old references to to the keys, which may be preventing me from uploading this "duplicate" cert name.

Oh, and because of my sorted history with Deis and Docker, I have multiple DEIS clusters.  I am able to add that cert/key pair to another cluster.

Consider heeding the warning to avoid mismatching client and server versions.

DEIS Nuggets: scale up then back down to apply SSL cert

I found that simply uploading a cert with deis cert:add will not affect the running processes.  The cert is applied to the DEIS router.  Scaling the application down, then back up will work.  But, why not scale up then back down?  Works for me.  HTH

Stateless DEIS - no Ceph

I'm sure Ceph is fine.  But, I don't want to add any uneccesary complexity to my DEIS cluster.  And, I don't know Ceph well enough to feel comfortable keeping it if I don't have to.

Below are a few notes I took in trying to get my stateless DEIS 1.9.0 cluster going.

First, I needed a log server to which I could send syslog from DEIS.  BTW, the "deis logs" command will cease to work once you send them to an external syslog service.  We are testing CloudWatch Logs.  Funny enough, I ended up trying Amazon ECS to host a docker image configured with CloudWatch Logs.  I fired up a service with two syslog tasks (listeners).  I will use these syslog servers for other purposes as well.

Second, I needed a PostgreSQL database.  RDS to the rescue.  So far, I'm getting by with a t2.micro.

Third, I needed some external storage for real files.  DEIS allows for an S3 backend.  I found no documentation for required permissions.  So, I tinkered until I came up with this small set:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1440163063000",
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::the-bucket/*"
            ]
        },
        {
            "Resource": "arn:aws:s3:::the-bucket",
            "Action": "s3:*",
            "Effect": "Allow"
        },
        {
            "Resource": "*",
            "Action": "s3:ListAllMyBuckets",
            "Effect": "Allow"
        }
    ]
}

The special deis install stateless-platform & deis start stateless-platform are the commands used to turn up the lean environment.  I had trouble with the registry starting until I tweaked the S3 permissions.  The builder wouldn't start because the controller didn't start (/deis/controller/* etcd keys didn't exist).

After much angst, and by running each command in fleetctl cat deis-controller individually, I found that the password for my postgres database had a single quote in it.  My luck, the startup script also used single quotes around the password.  FAILHORN!  After getting the controller whipped into shape, it still shows as inactive/dead in deisctl list.  But, I can register/login; and, the builder automatically continued after the controller came on.

So, I just first my first app to it.  I'm already enjoying (of necessity) those CloudWatch Logs.  Weeee!

Arduino On Ubuntu 15.04

The Arduino Uno clone I picked up from a Chinese Ebay seller has a USB-to-serial adapter that lacks Mac support.  Well, there is a Mac driver.  But, I wasn't comfortable installing a driver whose download link (and installer, I think) was only in Chinese.

Luckily Linux has the driver built right in.  So, using my Ubuntu 15.04 laptop, I installed Arduino 1.0.5 from the default apt repositories.  First thing I found was that the "Tools->Serial Port" menu item was grayed out.  I added myself to the dialout group and logged out/into my X session (or run newgrp and then run arduino from the terminal).  I found that I could not save or open a file.  I was using Iced Tea java.  I pointed at java 7.x.  No luck.  Turns out, it depends on Java 6 runtime, still available in Oracle's archive area.

My son and I played with the blink example.  I'm so glad that little LED is built in!

Back to coding.  So long.