Docker Machine, OpenStack, and SSH Keys

I wanted to provide readers a quick “heads up” about some unexpected behavior regarding Docker Machine and OpenStack. It’s not a huge deal, but it could catch someone off-guard if they aren’t aware of what’s happening.

This post builds on the earlier post I published on using Docker Machine with OpenStack; specifically, the section about using Docker Machine’s native OpenStack driver to provision instances on an OpenStack cloud. As a quick recap, recall that you can provision instances on an OpenStack cloud (and have Docker Engine installed and configured on those instances) with a command like this:

docker-machine create -d openstack \
--openstack-flavor-id 3 \
--openstack-image-name "Ubuntu 14.04.3 LTS x64" \
--openstack-net-name lab-net-5 \
--openstack-floatingip-pool ext-net-5 \
--openstack-sec-groups docker,basic-services
instance-name

(Note that I didn’t include all of the optional parameters; refer to either my earlier blog post or the Docker Machine OpenStack driver reference for more details).

One of the optional parameters for Docker Machine’s OpenStack driver is the --openstack-keypair-name parameter, which allows you to specify the name of an existing keypair to use with instances created by Docker Machine. If you omit this parameter, as I have above, then Docker Machine will auto-generate a new SSH key and inject that into the instance upon provisioning. Then, when you use docker-machine rm <instance-name> to remove the instance, Docker Machine will terminate the instance and delete the auto-generated SSH key. So far, so good—everything seems normal and pretty straightforward.

The unexpected behavior comes when you use the --openstack-keypair-name parameter to tell Docker Machine to use an existing keypair. This might be handy if you already have a keypair in OpenStack that you’d like to use with Docker Machine-generated instances. Docker Machine will do just as you instruct—it will use the existing keypair and inject it into the instance. And, when you run docker-machine rm <instance-name> to remove the Docker Machine-generated instance, it will also remove the pre-existing keypair.

Yes, you saw that right: Docker Machine will remove the pre-existing SSH keypair when you remove the Docker Machine-generated instance. Then, at some point later when you use something that expects that keypair to be there—the nova command line, Vagrant with an OpenStack provider, a Heat template, or a Terraform configuration—you’ll get an error because the keypair is gone. Fun, huh?

Based on a quick review of the GitHub issues for Docker Machine, this is “expected” and “normal,” and the expectation is for users to simply re-provision the keypair into OpenStack again via manual means. Personally, I find this behavior to run completely counter to what I would expect. However, until this behavior is changed/fixed in a future release, please plan accordingly when using Docker Machine with OpenStack.

UPDATE: Nathan LeClaire, one of the Docker Machine maintainers, has opened a new GitHub issue to track this behavior.

Metadata and Navigation