Using Let's Encrypt for https Juju controllers

#1

To setup a Juju Controller with Let’s Encrypt SSL you need to know what the DNS name will be before you bootstrap. That’s passed into the controller config in the autocert-dns-name value. Once you know the DNS name you plan to use you can bootstrap like so:

$ juju bootstrap google jujushow-dns --config autocert-dns-name=show.jujugui.org

The controller will come up and we need to setup the DNS for this controller. You will need to go into your DNS settings and set the IP address of the controller machine to the DNS entry you’re setting up. Getting the IP address of the controller can be done using juju status of the controller model.

$ juju status -m controller
Machine  State    DNS            Inst id        Series  AZ          Message
0        started  35.231.72.223  juju-63bb34-0  xenial  us-east1-b  RUNNING

The address 35.231.72.223 will need to be set to the DNS entry show.jujugui.org. Note that it might take a few for the DNS changes to take effect. You can test that it’s going through by ping’ing the controller

$ ping show.jujugui.org
PING show.jujugui.org (35.231.72.223) 56(84) bytes of data.
64 bytes from 223.72.231.35.bc.googleusercontent.com (35.231.72.223): icmp_seq=1 ttl=58 time=65.2 ms

At this point you can attempt to reach the controller GUI using the URL and it will kick off the Let’s Encrypt dance to setup your SSL certificate. Once the GUI loads you’ll note that it’ll have a valid SSL certificate provided by Let’s Encrypt.

https://show.jujugui.org

https_gui
https_gui2068×1428 106 KB

1 Like
How get controllers.yaml from existing controller
Juju Show #38 - Big Data, Big Kubernetes, and news!
What are your tips for running "Juju in production"?
Options for Production Controllers
Managing Juju in Production - Table of Contents
#2

This is great! Thanks @rick_h

2 Likes
#3

This rocks! Thank you

1 Like
#4

Bumping to the top for visibility.

#5

That’s great news @rick_h but I wonder how we could do it with already bootstrapped controllers ?

#6

Unfortunately the only way to do something with existing would be to setup a http proxy for the API server.

#7

For those interested in achieving what @soumplis asked regarding existing controllers, I was able to use ‘juju migrate’ to move all my models from my original controller using port 17070 to a new controller using HTTPS 443. Works like a charm … Wink wink :wink:

2 Likes
#8

Niiice! Why didn’t I think of that?!

#9

@dvnt @rick_h will “juju migrate” work migrating from a “non-jimm” controller, to, a “jimm controller” ?

The thing is that we have a model in a “standard-with-candid-enabled-controller” which I would like to migrate to the new shiny “jimm-candid” controller… I don’t wan’t to mess up our running environment by doing something too clever/untested etc.

#10

The trick will be that the migration code checks if the users exist on both ends. What you might have to do is to remove users with access to the model other than admin, then migrate the model, and then re-grant access on the other side to the new @external users backed by candid.

#11

Ah, thanx for that information I will keep it in mind before we try the migration down the road.