Using Oracle OCI with Juju
Juju already has knowledge of the OCI cloud (Oracle Cloud Infrastructure), which means adding your Oracle account to Juju is quick and easy.
More specific information on Juju’s OCI support (e.g. the supported regions) can be seen locally or, since
v.2.6.0, remotely (on a live cloud). Here, we’ll show how to do it locally (client cache):
juju show-cloud --local oracle
In versions prior to
show-cloud command only operates locally (there is no
To ensure that Juju’s information is up to date (e.g. new region support), you can update Juju’s public cloud data by running:
The previous iteration of Oracle’s public cloud is now known to Juju as ‘oracle-classic’. It is supported (see 2.3 documentation) but should be considered deprecated. These instructions cover Oracle OCI only and is known to Juju as cloud ‘oracle’.
Understanding and preparing your OCI account
The instructions on this page refer to certain OCI concepts. Familiarise yourself with them by reading Oracle’s Concepts page. The key concepts for us here are “Tenancy”, “Compartment”, and “OCID”.
Your Tenancy can be designed according to how you intend to use your OCI account but there is no hard requirement to perform any configuration changes to it in order to use it with Juju. However, for enterprise rollouts you will most certainly need to do this for both organisational and security reasons.
To organise your Tenancy and its associated compartments read Oracle’s Setting up your Tenancy page.
Oracle’s SDK tools can also be used to manage your OCI account.
The following bits of information need to be gathered:
- SSL keypair and fingerprint
- Oracle Cloud Identifiers (OCIDs)
SSL keypair and fingerprint
An SSL keypair (private and public keys) needs to be generated on your local system. It will be used to contact Oracle’s API. A “fingerprint” of the private key will be needed to identify that key. The below list of Linux-based commands accomplish all this. For a full explanation of them, in addition to what to do on a non-Linux system, see Oracle’s Required Keys and OCIDs page.
mkdir ~/.oci openssl genrsa -out ~/.oci/oci_ssl_key_private.pem -aes128 2048 chmod go-rwx ~/.oci/oci_ssl_key_private.pem openssl rsa -pubout -in ~/.oci/oci_ssl_key_private.pem -out ~/.oci/oci_ssl_key_public.pem openssl rsa -pubout -outform DER -in ~/.oci/oci_ssl_key_private.pem | openssl md5 -c
openssl invocation will create an encrypted private key and will therefore prompt you for a passphrase. You will need this for later. Omit option
-aes128 to disable encryption.
The last command will output the fingerprint of the private key.
The private key is now in file
~/.oci/oci_ssl_key_private.pem and the public key is in file
We’ll later make reference to the private key, the fingerprint, and the passphrase using these variables, respectively:
Oracle Cloud Identifiers (OCIDs)
OCIDs are required for the following objects:
They are all gathered via Oracle’s web Console.
The below instructions for navigating the Oracle web interface assume you are the account administrator. If this is not the case, your experience may differ. In particular, you may need to access information in the top-right corner (look for “User Settings”).
The User OCID is found by clicking in the top-left menu and choosing ‘Identity’ and then sub-menu ‘Users’. Here, we’ll assign this value to a variable so we can refer to it later:
The Tenancy OCID is found similarly but in the sub-menu ‘Compartments’. Again, we’ll assign this to a variable:
The Compartment OCID is found on the same page:
In this example, for the Compartment OCID, we decided to use the compartment provided to us by default (the root Compartment). Notice how it’s the same as the Tenancy OCID.
You will need to specify the Compartment OCID during the controller-creation process.
Provide the public SSL key to Oracle
In order for the SSL keypair to be of any use the public key must be placed on the remote end.
Within the ‘Users’ sub-menu, click on the user’s email address, and then on ‘Add Public Key’. Paste in the key generated earlier (stored in file
~/.oci/oci_ssl_key_public.pem) and click the ‘Add’ button.
The Credentials page offers a full treatment of credential management.
In order to access Oracle OCI, you will need to add credentials to Juju. This can be done in one of two ways (as shown below).
Using the interactive method
Armed with the gathered information, credentials can be added interactively with the command
juju add-credential oracle. However, due to the private SSL key that needs to be provided this method is not recommended. Use the file method outlined next.
Using a file
A YAML-formatted file, say
mycreds.yaml, can be used to store credential information for any cloud. The file in this example would be based on the following (replace the variables with your own values):
credentials: oracle: $CREDENTIAL_NAME: auth-type: httpsig fingerprint: $SSL_PRIVATE_KEY_FINGERPRINT key: | $SSL_PRIVATE_KEY region: $CLOUD_REGION pass-phrase: $SSL_PRIVATE_KEY_PASSPHRASE tenancy: $OCID_TENANCY user: $OCID_USER
$SSL_PRIVATE_KEY_PASSPHRASEvalue is placed within double-quotes. If the key was not encrypted just use “”.
$CLOUD_REGIONis an Oracle region (
juju regions oracle).
$CREDENTIAL_NAMEis an arbitrary label.
See section Adding credentials from a file for guidance on what such a file can look like.
This information is then added to Juju by referencing the file with the
juju add-credential oracle -f mycreds.yaml
Creating a controller
You are now ready to create a Juju controller for cloud ‘oracle’ (replace the variable with your own value):
juju bootstrap --config compartment-id=$OCID_COMPARTMENT oracle oracle-controller
Above, the name given to the new controller is ‘oracle-controller’. OCI will provision an instance to run the controller on.
You can optionally change the definition of cloud ‘oracle’ to avoid having to specify the compartment like this. See General cloud management for guidance.
For a detailed explanation and examples of the
bootstrap command see the Creating a controller page.
A controller is created with two models - the ‘controller’ model, which should be reserved for Juju’s internal operations, and a model named ‘default’, which can be used for deploying user workloads.
See these pages for ideas on what to do next: