I tried adding this machine driver as a custom node driver in the Rancher UI and then provisioning a node with it but I had issues trying to give Rancher access to my Triton SSK key. I have Rancher running in a Docker container on an Ubuntu bhyve VM in Triton. I installed my Triton SSH key on the bhyve VM hosting the Rancher docker container and then tried both of these options:

1. Mounting the SSH key inside the rancher docker container
2. Adding the SSH key to the SSH agent in the bhyve VM and recreated the rancher docker container with the following arguments: -v $SSH_AUTH_SOCK:$SSH_AUTH_SOCK -e SSH_AUTH_SOCK=$SSH_AUTH_SOCK so that the rancher docker container could access the SSH key via the SSH agent.

With option 1 I was able to see the SSH key when I exec into the docker container but the machine driver still couldn't access the key because Rancher runs the machine driver inside a jail and the jail doesn't have access to the SSH key path (https://forums.rancher.com/t/how-to-pass-ssh-key-to-custom-node-driver/37325).

With option 2 I was able to see the SSH key when I ran ssh-add -l from inside the rancher docker container and I could also echo $SSH_AUTH_SOCK and see that it’s set but $SSH_AUTH_SOCK was still not accessible to the machine driver since Rancher runs it in a jail. I also tried setting ssh_agent_auth: true with no luck.

Since I was unsuccessful in giving the machine driver access to the SSH key via a file path I decided to modify the driver and add a new optional -triton-key-material argument that accepts a base64 encoded private key string. I looked at the other driver implementations that ship with Rancher such as digitialocean and amazonec2 and it seems that most of them accept strings such as AccessKey and SecretKey rather than a path to a SSH key. Since Triton's CloudAPI requires requests to be signed with a SSH key then it seems that's the only credential needed/available so having the ability to pass that to the machine driver as a string rather than a file path seems advantageous and more inline with how the other drivers work.

Once I modified the machine driver and added it as a custom node driver in the Rancher UI I created a new node template with my base64 encoded private key and then Rancher was able to successfully provision new nodes (Triton bhyve VMs) without issue.

In addition to passing in the base64 encoded private key I also had to add code to wait for the IP to be available so that Rancher doesn't try to SSH into the node until it has all the necessary info.

I'm open to suggestions on improving what I've done but so far this works without issue.

vrcis@f2125d5

There are several dependencies that need to be removed in favor of triton-go.

Go engineers at Joyent are centralizing tools around our new SDK with the hope of expiring the old libraries. There are examples of using triton-go in the repo and/or I can help with any part of it. If something doesn't map over please let us know.

• github.com/joyent/gocommon/client
• github.com/joyent/gosdc/cloudapi
• github.com/joyent/gosign/auth

Also, I would have done this myself but I'm not entirely certain of how this project is being distributed or how I can test it (?). A README.md would be nice.

I'm attempting to use the Triton driver with Rancher.

Rancher runs the docker-machine command on the server side, this requires uploading the Triton ssh key to the server before hand and referencing the key path in the Rancher UI.

I'm looking to add support for passing in the raw ssh key so adding a machine can happen all within the Rancher UI.

Before I started the changes I wanted to get opinions on the approach.

We could create a new flag, --triton-key-material
or
We could overload the current flag --triton-key-path

By overload I mean we could try to interpret the triton-key-path as a file path first, if that fails we could assume the contents is a raw ssh key.

Thoughts?

I'd like to add the triton machine driver to Rancher (rancher.com).
Docs: http://rancher.com/docs/rancher/v1.3/en/configuration/machine-drivers/

Where can I find the "machine driver binary 64-bit Linux" or how can I create it?
Sorry, I'm not a go master (yet).

Ref: Allow Triton network to be passed

We should have a flag that supports defining networks on the host that is created when running docker-machine create. This would help assign and launch Docker hosts onto operator defined or private fabric networks.

/cc @ajmadsen-hart

docker-machine works fine with debian, but when creating a centos machine, it throws an error about not being able to connect to docker engine endpoint.

$ docker-machine create -d "triton" --triton-image "debian-8" --triton-key-path ".ssh/id_rsa" --triton-package "k4-highcpu-kvm-1.75G" --engine-install-url "https://releases.rancher.com/install-docker/1.12.sh" testingdriverwithdebian8
Running pre-create checks...
(testingdriverwithdebian8) resolved image "debian-8" to "a55d245e-1e14-11e7-a248-63e9c9423280" (most recent of 15 name matches)
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with debian...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Docker is up and running!
To see how to connect your Docker Client to the Docker Engine running on this virtual machine, run: docker-machine env testingdriverwithdebian8

$ docker-machine create -d "triton" --triton-image "centos-7@20170327" --triton-key-path ".ssh/id_rsa" --triton-package "k4-highcpu-kvm-1.75G" --engine-install-url "https://releases.rancher.com/install-docker/1.12.sh" testingdriverwithcentos7
Running pre-create checks...
(testingdriverwithcentos7) resolved image "centos-7@20170327" to "66d919a8-132a-11e7-a7b8-5b99fa122880" (exact name match)
Creating machine...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Detecting the provisioner...
Provisioning with centos...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...
Checking connection to Docker...
Error creating machine: Error checking the host: Error checking and/or regenerating the certs: There was an error validating certificates for host "72.2.115.48:2376": dial tcp 72.2.115.48:2376: getsockopt: connection refused
You can attempt to regenerate them using 'docker-machine regenerate-certs [name]'.
Be advised that this will trigger a Docker daemon restart which might stop running containers.

$ docker-machine regenerate-certs testingdriverwithcentos7
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Waiting for SSH to be available...
Detecting the provisioner...
Copying certs to the local machine directory...
Copying certs to the remote machine...
Setting Docker configuration on the remote daemon...

$ docker-machine ls
NAME                       ACTIVE   DRIVER   STATE     URL                          SWARM   DOCKER    ERRORS
testingdriverwithcentos7   -        triton   Running   tcp://165.225.128.163:2376           Unknown   Unable to query docker version: Cannot connect to the docker engine endpoint
testingdriverwithdebian8   -        triton   Running   tcp://165.225.139.41:2376            v1.12.6