create
******


Description
===========

Creates a new load balancer in the specified compartment. For general
information about load balancers, see Overview of the Load Balancing
Service.

For the purposes of access control, you must provide the OCID of the
compartment where you want the load balancer to reside. Notice that
the load balancer doesn't have to be in the same compartment as the
VCN or backend set. If you're not sure which compartment to use, put
the load balancer in the same compartment as the VCN. For information
about access control and compartments, see Overview of the IAM
Service.

You must specify a display name for the load balancer. It does not
have to be unique, and you can change it.

For information about Availability Domains, see Regions and
Availability Domains. To get a list of Availability Domains, use the
*ListAvailabilityDomains* operation in the Identity and Access
Management Service API.

All Oracle Cloud Infrastructure resources, including load balancers,
get an Oracle-assigned, unique ID called an Oracle Cloud Identifier
(OCID). When you create a resource, you can find its OCID in the
response. You can also retrieve a resource's OCID by using a List API
operation on that resource type, or by viewing the resource in the
Console. Fore more information, see Resource Identifiers.

After you send your request, the new object's state will temporarily
be PROVISIONING. Before using the object, first make sure its state
has changed to RUNNING.

When you create a load balancer, the system assigns an IP address. To
get the IP address, use the GetLoadBalancer operation.


Usage
=====

   oci lb load-balancer create [OPTIONS]


Options
=======


--compartment-id, -c [text]
---------------------------

The OCID of the compartment in which to create the load balancer.
[required]


--display-name [text]
---------------------

A user-friendly name. It does not have to be unique, and it is
changeable. Avoid entering confidential information.

Example: *example_load_balancer* [required]


--shape-name [text]
-------------------

A template that determines the total pre-provisioned bandwidth
(ingress plus egress). To get a list of available shapes, use the
ListShapes operation.

Example: *100Mbps* [required]


--subnet-ids [complex type]
---------------------------

An array of subnet OCIDs. This is a complex type whose value must be
valid JSON. The value can be provided as a string on the command line
or passed in as a file using the file://path/to/file syntax.

The --generate-param-json-input option can be used to generate an
example of the JSON which must be provided. We recommend storing this
example in a file, modifying it as needed and then passing it back in
via the file:// syntax.

   [required]


--backend-sets [complex type]
-----------------------------

This option is a JSON dictionary of type dict(str, BackendSetDetails).
For documentation on BackendSetDetails please see our API reference:
https://docs.us-phoenix-1.oraclecloud.com/api/#. This is a complex
type whose value must be valid JSON. The value can be provided as a
string on the command line or passed in as a file using the
file://path/to/file syntax.

The --generate-param-json-input option can be used to generate an
example of the JSON which must be provided. We recommend storing this
example in a file, modifying it as needed and then passing it back in
via the file:// syntax.


--certificates [complex type]
-----------------------------

This option is a JSON dictionary of type dict(str,
CertificateDetails).  For documentation on CertificateDetails please
see our API reference: https://docs.us-
phoenix-1.oraclecloud.com/api/#. This is a complex type whose value
must be valid JSON. The value can be provided as a string on the
command line or passed in as a file using the file://path/to/file
syntax.

The --generate-param-json-input option can be used to generate an
example of the JSON which must be provided. We recommend storing this
example in a file, modifying it as needed and then passing it back in
via the file:// syntax.


--hostnames [complex type]
--------------------------

This option is a JSON dictionary of type dict(str, HostnameDetails).
For documentation on HostnameDetails please see our API reference:
https://docs.us-phoenix-1.oraclecloud.com/api/#. This is a complex
type whose value must be valid JSON. The value can be provided as a
string on the command line or passed in as a file using the
file://path/to/file syntax.

The --generate-param-json-input option can be used to generate an
example of the JSON which must be provided. We recommend storing this
example in a file, modifying it as needed and then passing it back in
via the file:// syntax.


--is-private [boolean]
----------------------

Whether the load balancer has a VCN-local (private) IP address.

If "true", the service assigns a private IP address to the load
balancer. The load balancer requires only one subnet to host both the
primary and secondary load balancers. The private IP address is local
to the subnet. The load balancer is accessible only from within the
VCN that contains the associated subnet, or as further restricted by
your security list rules. The load balancer can route traffic to any
backend server that is reachable from the VCN.

For a private load balancer, both the primary and secondary load
balancer hosts are within the same Availability Domain.

If "false", the service assigns a public IP address to the load
balancer. A load balancer with a public IP address requires two
subnets, each in a different Availability Domain. One subnet hosts the
primary load balancer and the other hosts the secondary (standby) load
balancer. A public load balancer is accessible from the internet,
depending on your VCN's security list rules.

Example: *true*


--listeners [complex type]
--------------------------

This option is a JSON dictionary of type dict(str, ListenerDetails).
For documentation on ListenerDetails please see our API reference:
https://docs.us-phoenix-1.oraclecloud.com/api/#. This is a complex
type whose value must be valid JSON. The value can be provided as a
string on the command line or passed in as a file using the
file://path/to/file syntax.

The --generate-param-json-input option can be used to generate an
example of the JSON which must be provided. We recommend storing this
example in a file, modifying it as needed and then passing it back in
via the file:// syntax.


--path-route-sets [complex type]
--------------------------------

This option is a JSON dictionary of type dict(str,
PathRouteSetDetails).  For documentation on PathRouteSetDetails please
see our API reference: https://docs.us-
phoenix-1.oraclecloud.com/api/#. This is a complex type whose value
must be valid JSON. The value can be provided as a string on the
command line or passed in as a file using the file://path/to/file
syntax.

The --generate-param-json-input option can be used to generate an
example of the JSON which must be provided. We recommend storing this
example in a file, modifying it as needed and then passing it back in
via the file:// syntax.


--wait-for-state [ACCEPTED|IN_PROGRESS|FAILED|SUCCEEDED]
--------------------------------------------------------

This operation asynchronously creates, modifies or deletes a resource
and uses a work request to track the progress of the operation.
Specify this option to perform the action and then wait until the work
request reaches a certain state.


--max-wait-seconds [integer]
----------------------------

The maximum time to wait for the work request to reach the state
defined by --wait-for-state. Defaults to 1200 seconds.


--wait-interval-seconds [integer]
---------------------------------

Check every --wait-interval-seconds to see whether the work request to
see if it has reached the state defined by --wait-for-state. Defaults
to 30 seconds.


--from-json [text]
------------------

Provide input to this command as a JSON document from a file.

Options can still be provided on the command line. If an option exists
in both the JSON document and the command line then the command line
specified value will be used


-?, -h, --help
--------------

Show this message and exit.


Examples
========

When creating a load balancer, there are two main options:

* Providing all information when calling the "create" command

* Providing minimal information to the "create" command then then
  using individual commands to "assemble" the load balancer post-
  creation

Working samples for both approaches can be found here.


Providing all information at create time
----------------------------------------

Under this option, you would call the "create" command and specify the
"--certificates", "--backend-sets", "--listener" and "--path-route-
sets" options in order to also create these items when creating the
load balancer. Since those options are complex types, it is
recommended that you place their input in JSON files and then specify
these files as input to the command using the file:// syntax. For
example:

   oci lb load-balancer create --backend-sets file://path/to/backend/set/file.json

You can discover the format of the input you need to provide by using
the "--generate-param-json-input" option. For example:

   oci lb load-balancer create --generate-param-json-input certificates
   oci lb load-balancer create --generate-param-json-input backend-sets
   oci lb load-balancer create --generate-param-json-input listeners
   oci lb load-balancer create --generate-param-json-input path-route-sets

As an alternative to providing those individal options, you can
specify all the input to the command in a single file using the "--
from-json" option. For example:

   oci lb load-balancer create --from-json file://path/to/file/of/input.json

You can discover the format of the input you need to provide by using
the "--generate-full-command-json-input" option. For example:

   oci lb load-balancer create --generate-full-command-json-input


Providing minimal information and then assembling via other commands
--------------------------------------------------------------------

Under this option, you would only supply the mandatory arguments to
the "create" command (and not any of the input marked as "COMPLEX
TYPE") and then use other operations to add certificates, backend
sets, listeners and path route sets. This approach is more applicable
if you do not wish to prepare JSON input files.

The key commands you'll need to be aware of are:

* This command

* Create certificate

* Create backend set

* Create backend

* List protocols

* Create listener

* Create path route set

You would tie these together in sequence by:

   # Create load balancer with minimal attributes
   oci lb load-balancer create

   # Create a certificate bundle associated with the load balancer (call command multiple times if needed)
   oci lb certificate create

   # Create a backend set associated with the load balancer (call command multiple times if needed)
   # You may need the details of the certificate you previously created
   oci lb backend-set create

   # Add multiple backends to the backend set
   oci lb backend create
   oci lb backend create

   # Create a path route set for a particular listener of the load balancer to route traffic to appropriate back-end set
   oci lb path-route-set create

   # Add a listener to the load balancer (call command multiple times if needed)
   # This will take a --protocol option, whose valid values you can discover by oci lb protocol lists
   # You may also need the details of the certificate you previously created
   oci lb listener create
