Warning: Azure has two concurrent UI versions: the older "classic" console (https://manage.windowsazure.com) and the "new" console (https://portal.azure.com). The features necessary in this document are only available in the classic portal.
An Azure account is required. See http://azure.microsoft.com.
An SSL/TLS certificate, either an existing one or a new one, will be needed to communicate with Azure.
Juju 1.25 (or greater) is needed for storage support.
The Juju client (the host running the below commands) will need the ability to contact the Azure infrastructure on TCP ports 22 and 17070.
The certificate will be uploaded to Azure to enable the Juju client to authenticate (and communicate securely) using the associated private key.
Certificate creation is dependant on platform. Below, the openssl command on Ubuntu is used to create a self-signed certificate.
During the creation process, you will be prompted for some information (country, state, location, organisation, and common name). 'country' must be a valid 2-character value but the others are arbitrary.
Note: We recommend a meaningful name for 'common name' such as 'juju-azure' as this will become the "name" of the certificate.
Create the key and certificate now:
openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \ -keyout juju-azure.pem -out juju-azure.pem openssl x509 -inform pem -in juju-azure.pem -outform der -out juju-azure.cer chmod 600 juju-azure.pem
The certificate is in file
juju-azure.cer and the private key is in
Note: The PEM file (
juju-azure.pem) actually contains both the private key
and the certificate.
Copy the PEM file to where Juju can find it:
cp juju-azure.pem /home/ubuntu/.juju
Log in to the classic console at https://manage.windowsazure.com and in the left pane, scroll down and select 'Settings'. Select the 'Management Certificates' tab in the right pane.
At the bottom there is an 'Upload' icon. Use it to upload the certificate
If this is a new Juju install then you do not yet have a
~/.juju/environments.yaml file. Create one with
If it does exist first move it out of the way (back it up) and then generate a new one. Alternatively, you can output a generic file to screen (STDOUT) and paste the Azure parts into your existing file:
juju generate-config --show
The file will contain a section for the Azure provider.
Values will need to be found for the following parameters:
Access the Classic Azure console (https://manage.windowsazure.com) again to gather the first three values.
Enter 'Settings' again, find the appropriate subscription in the right pane, and
take note of its
subscription ID. This is the value to be used for
First create a storage account. In the left pane, scroll down to 'Storage'
and press the + NEW icon (bottom-left). An overlay page will appear. Click
'Quick Create' and fill in the 'URL' field (e.g.
jujuazure). This is the
value to be used for
In the same dialog, select a 'Location/Affinity Group'.
If you intend to use storage support then this value and the
value you provide the
location paramter must be the same. Failure to do so
will result in storage being used local to the Juju machine where the charm is
being run. Note that there is a limited set of regions available in the Azure
UI. Choose one that is closest to you:
For insight into the 'Replication' field see Azure storage redundancy documentation .
Note: Once you bootstrap Juju, an Azure affinity group (e.g.
juju-azure-ag) will appear in this list if you ever come back to it. See
stackoverflow.com: "Azure Availability Set vs Affinity
The value of this parameter is the file path of the private key (and
certificate) stored in the PEM file created earlier:
According to all the above, the Azure section of file
this example would look like this (comments removed for simplicity):
azure: type: azure location: Central US storage-account-name: jujuazure management-subscription-id: f717c8c1-8e5e-4d38-be7f-ed1e1c879e18 management-certificate-path: /home/ubuntu/.juju/juju-azure.pem
Finally, switch to the Azure provider and bootstrap:
juju switch azure juju bootstrap --debug
A successful bootstrap will result in the controller being visible in the Classic console under 'Virtual Machines' in the left pane:
The default behaviour is for units of a service to be allocated to machines in a service-specific Availability Set. Read the Azure SLA to learn how availability sets affect uptime guarantees.
See General configuration options for additional and advanced customization of your environment.