oracle.oci.oci_loadbalancer_backend_set_facts – Fetches details about one or multiple BackendSet resources in Oracle Cloud Infrastructure

Note

This plugin is part of the oracle.oci collection (version 4.14.0).

You might already have this collection installed if you are using the ansible package. It is not included in ansible-core. To check whether it is installed, run ansible-galaxy collection list.

To install it, use: ansible-galaxy collection install oracle.oci.

To use it in a playbook, specify: oracle.oci.oci_loadbalancer_backend_set_facts.

New in version 2.9.0: of oracle.oci

Synopsis

  • Fetches details about one or multiple BackendSet resources in Oracle Cloud Infrastructure

  • Lists all backend sets associated with a given load balancer.

  • If backend_set_name is specified, the details of a single BackendSet will be returned.

Requirements

The below requirements are needed on the host that executes this module.

Parameters

Parameter Choices/Defaults Comments
api_user
string
The OCID of the user, on whose behalf, OCI APIs are invoked. If not set, then the value of the OCI_USER_ID environment variable, if any, is used. This option is required if the user is not specified through a configuration file (See config_file_location). To get the user's OCID, please refer https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm.
api_user_fingerprint
string
Fingerprint for the key pair being used. If not set, then the value of the OCI_USER_FINGERPRINT environment variable, if any, is used. This option is required if the key fingerprint is not specified through a configuration file (See config_file_location). To get the key pair's fingerprint value please refer https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm.
api_user_key_file
string
Full path and filename of the private key (in PEM format). If not set, then the value of the OCI_USER_KEY_FILE variable, if any, is used. This option is required if the private key is not specified through a configuration file (See config_file_location). If the key is encrypted with a pass-phrase, the api_user_key_pass_phrase option must also be provided.
api_user_key_pass_phrase
string
Passphrase used by the key referenced in api_user_key_file, if it is encrypted. If not set, then the value of the OCI_USER_KEY_PASS_PHRASE variable, if any, is used. This option is required if the key passphrase is not specified through a configuration file (See config_file_location).
auth_purpose
string
    Choices:
  • service_principal
The auth purpose which can be used in conjunction with 'auth_type=instance_principal'. The default auth_purpose for instance_principal is None.
auth_type
string
    Choices:
  • api_key ←
  • instance_principal
  • instance_obo_user
  • resource_principal
The type of authentication to use for making API requests. By default auth_type="api_key" based authentication is performed and the API key (see api_user_key_file) in your config file will be used. If this 'auth_type' module option is not specified, the value of the OCI_ANSIBLE_AUTH_TYPE, if any, is used. Use auth_type="instance_principal" to use instance principal based authentication when running ansible playbooks within an OCI compute instance.
backend_set_name
string
The name of the backend set to retrieve.
Example: `example_backend_set`
Required to get a specific backend_set.

aliases: name
cert_bundle
string
The full path to a CA certificate bundle to be used for SSL verification. This will override the default CA certificate bundle. If not set, then the value of the OCI_ANSIBLE_CERT_BUNDLE variable, if any, is used.
config_file_location
string
Path to configuration file. If not set then the value of the OCI_CONFIG_FILE environment variable, if any, is used. Otherwise, defaults to ~/.oci/config.
config_profile_name
string
The profile to load from the config file referenced by config_file_location. If not set, then the value of the OCI_CONFIG_PROFILE environment variable, if any, is used. Otherwise, defaults to the "DEFAULT" profile in config_file_location.
load_balancer_id
string / required
The OCID of the specified load balancer.

aliases: id
region
string
The Oracle Cloud Infrastructure region to use for all OCI API requests. If not set, then the value of the OCI_REGION variable, if any, is used. This option is required if the region is not specified through a configuration file (See config_file_location). Please refer to https://docs.us-phoenix-1.oraclecloud.com/Content/General/Concepts/regions.htm for more information on OCI regions.
tenancy
string
OCID of your tenancy. If not set, then the value of the OCI_TENANCY variable, if any, is used. This option is required if the tenancy OCID is not specified through a configuration file (See config_file_location). To get the tenancy OCID, please refer https://docs.us-phoenix-1.oraclecloud.com/Content/API/Concepts/apisigningkey.htm

Examples

- name: Get a specific backend_set
  oci_loadbalancer_backend_set_facts:
    # required
    backend_set_name: backend_set_name_example
    load_balancer_id: "ocid1.loadbalancer.oc1..xxxxxxEXAMPLExxxxxx"

- name: List backend_sets
  oci_loadbalancer_backend_set_facts:
    # required
    load_balancer_id: "ocid1.loadbalancer.oc1..xxxxxxEXAMPLExxxxxx"

Return Values

Common return values are documented here, the following are the fields unique to this module:

Key Returned Description
backend_sets
complex
on success
List of BackendSet resources

Sample:
[{'backends': [{'backup': True, 'drain': True, 'ip_address': 'ip_address_example', 'name': 'name_example', 'offline': True, 'port': 56, 'weight': 56}], 'health_checker': {'interval_in_millis': 56, 'port': 56, 'protocol': 'protocol_example', 'response_body_regex': 'response_body_regex_example', 'retries': 56, 'return_code': 56, 'timeout_in_millis': 56, 'url_path': 'url_path_example'}, 'lb_cookie_session_persistence_configuration': {'cookie_name': 'cookie_name_example', 'disable_fallback': True, 'domain': 'domain_example', 'is_http_only': True, 'is_secure': True, 'max_age_in_seconds': 56, 'path': 'path_example'}, 'name': 'name_example', 'policy': 'policy_example', 'session_persistence_configuration': {'cookie_name': 'cookie_name_example', 'disable_fallback': True}, 'ssl_configuration': {'certificate_ids': [], 'certificate_name': 'certificate_name_example', 'cipher_suite_name': 'cipher_suite_name_example', 'protocols': [], 'server_order_preference': 'ENABLED', 'trusted_certificate_authority_ids': [], 'verify_depth': 56, 'verify_peer_certificate': True}}]
 
backends
complex
on success

   
backup
boolean
on success
Whether the load balancer should treat this server as a backup unit. If `true`, the load balancer forwards no ingress traffic to this backend server unless all other backend servers not marked as "backup" fail the health check policy.
**Note:** You cannot add a backend server marked as `backup` to a backend set that uses the IP Hash policy.
Example: `false`

Sample:
True
   
drain
boolean
on success
Whether the load balancer should drain this server. Servers marked "drain" receive no new incoming traffic.
Example: `false`

Sample:
True
   
ip_address
string
on success
The IP address of the backend server.
Example: `10.0.0.3`

Sample:
ip_address_example
   
name
string
on success
A read-only field showing the IP address and port that uniquely identify this backend server in the backend set.
Example: `10.0.0.3:8080`

Sample:
name_example
   
offline
boolean
on success
Whether the load balancer should treat this server as offline. Offline servers receive no incoming traffic.
Example: `false`

Sample:
True
   
port
integer
on success
The communication port for the backend server.
Example: `8080`

Sample:
56
   
weight
integer
on success
The load balancing policy weight assigned to the server. Backend servers with a higher weight receive a larger proportion of incoming traffic. For example, a server weighted '3' receives 3 times the number of new connections as a server weighted '1'. For more information on load balancing policies, see How Load Balancing Policies Work.
Example: `3`

Sample:
56
 
health_checker
complex
on success

   
interval_in_millis
integer
on success
The interval between health checks, in milliseconds. The default is 10000 (10 seconds).
Example: `10000`

Sample:
56
   
port
integer
on success
The backend server port against which to run the health check. If the port is not specified, the load balancer uses the port information from the `Backend` object.
Example: `8080`

Sample:
56
   
protocol
string
on success
The protocol the health check must use; either HTTP or TCP.
Example: `HTTP`

Sample:
protocol_example
   
response_body_regex
string
on success
A regular expression for parsing the response body from the backend server.
Example: `^((?!false).|\s)*$`

Sample:
response_body_regex_example
   
retries
integer
on success
The number of retries to attempt before a backend server is considered "unhealthy". This number also applies when recovering a server to the "healthy" state. Defaults to 3.
Example: `3`

Sample:
56
   
return_code
integer
on success
The status code a healthy backend server should return. If you configure the health check policy to use the HTTP protocol, you can use common HTTP status codes such as "200".
Example: `200`

Sample:
56
   
timeout_in_millis
integer
on success
The maximum time, in milliseconds, to wait for a reply to a health check. A health check is successful only if a reply returns within this timeout period. Defaults to 3000 (3 seconds).
Example: `3000`

Sample:
56
   
url_path
string
on success
The path against which to run the health check.
Example: `/healthcheck`

Sample:
url_path_example
  lb_cookie_session_persistence_configuration
complex
on success

    cookie_name
string
on success
The name of the cookie inserted by the load balancer. If this field is not configured, the cookie name defaults to "X-Oracle-BMC-LBS-Route".
Example: `example_cookie`
**Notes:**
* Ensure that the cookie name used at the backend application servers is different from the cookie name used at the load balancer. To minimize the chance of name collision, Oracle recommends that you use a prefix such as "X-Oracle-OCI-" for this field.
* If a backend server and the load balancer both insert cookies with the same name, the client or browser behavior can vary depending on the domain and path values associated with the cookie. If the name, domain, and path values of the `Set-cookie` generated by a backend server and the `Set-cookie` generated by the load balancer are all the same, the client or browser treats them as one cookie and returns only one of the cookie values in subsequent requests. If both `Set-cookie` names are the same, but the domain and path names are different, the client or browser treats them as two different cookies.

Sample:
cookie_name_example
    disable_fallback
boolean
on success
Whether the load balancer is prevented from directing traffic from a persistent session client to a different backend server if the original server is unavailable. Defaults to false.
Example: `false`

Sample:
True
    domain
string
on success
The domain in which the cookie is valid. The `Set-cookie` header inserted by the load balancer contains a domain attribute with the specified value.
This attribute has no default value. If you do not specify a value, the load balancer does not insert the domain attribute into the `Set-cookie` header.
**Notes:**
* RFC 6265 - HTTP State Management Mechanism describes client and browser behavior when the domain attribute is present or not present in the `Set-cookie` header.
If the value of the `Domain` attribute is `example.com` in the `Set-cookie` header, the client includes the same cookie in the `Cookie` header when making HTTP requests to `example.com`, `www.example.com`, and `www.abc.example.com`. If the `Domain` attribute is not present, the client returns the cookie only for the domain to which the original request was made.
* Ensure that this attribute specifies the correct domain value. If the `Domain` attribute in the `Set-cookie` header does not include the domain to which the original request was made, the client or browser might reject the cookie. As specified in RFC 6265, the client accepts a cookie with the `Domain` attribute value `example.com` or `www.example.com` sent from `www.example.com`. It does not accept a cookie with the `Domain` attribute `abc.example.com` or `www.abc.example.com` sent from `www.example.com`.
Example: `example.com`

Sample:
domain_example
    is_http_only
boolean
on success
Whether the `Set-cookie` header should contain the `HttpOnly` attribute. If `true`, the `Set-cookie` header inserted by the load balancer contains the `HttpOnly` attribute, which limits the scope of the cookie to HTTP requests. This attribute directs the client or browser to omit the cookie when providing access to cookies through non-HTTP APIs. For example, it restricts the cookie from JavaScript channels.
Example: `true`

Sample:
True
    is_secure
boolean
on success
Whether the `Set-cookie` header should contain the `Secure` attribute. If `true`, the `Set-cookie` header inserted by the load balancer contains the `Secure` attribute, which directs the client or browser to send the cookie only using a secure protocol.
**Note:** If you set this field to `true`, you cannot associate the corresponding backend set with an HTTP listener.
Example: `true`

Sample:
True
    max_age_in_seconds
integer
on success
The amount of time the cookie remains valid. The `Set-cookie` header inserted by the load balancer contains a `Max-Age` attribute with the specified value.
The specified value must be at least one second. There is no default value for this attribute. If you do not specify a value, the load balancer does not include the `Max-Age` attribute in the `Set-cookie` header. In most cases, the client or browser retains the cookie until the current session ends, as defined by the client.
Example: `3600`

Sample:
56
    path
string
on success
The path in which the cookie is valid. The `Set-cookie header` inserted by the load balancer contains a `Path` attribute with the specified value.
Clients include the cookie in an HTTP request only if the path portion of the request-uri matches, or is a subdirectory of, the cookie's `Path` attribute.
The default value is `/`.
Example: `/example`

Sample:
path_example
 
name
string
on success
A friendly name for the backend set. It must be unique and it cannot be changed.
Valid backend set names include only alphanumeric characters, dashes, and underscores. Backend set names cannot contain spaces. Avoid entering confidential information.
Example: `example_backend_set`

Sample:
name_example
 
policy
string
on success
The load balancer policy for the backend set. To get a list of available policies, use the ListPolicies operation.
Example: `LEAST_CONNECTIONS`

Sample:
policy_example
 
session_persistence_configuration
complex
on success

   
cookie_name
string
on success
The name of the cookie used to detect a session initiated by the backend server. Use '*' to specify that any cookie set by the backend causes the session to persist.
Example: `example_cookie`

Sample:
cookie_name_example
   
disable_fallback
boolean
on success
Whether the load balancer is prevented from directing traffic from a persistent session client to a different backend server if the original server is unavailable. Defaults to false.
Example: `false`

Sample:
True
 
ssl_configuration
complex
on success

   
certificate_ids
list / elements=string
on success
Ids for OCI certificates service certificates. Currently only a single Id may be passed.
Example: `[ocid1.certificate.oc1.us-ashburn-1.amaaaaaaav3bgsaa5o2q7rh5nfmkkukfkogasqhk6af2opufhjlqg7m6jqzq]`

   
certificate_name
string
on success
A friendly name for the certificate bundle. It must be unique and it cannot be changed. Valid certificate bundle names include only alphanumeric characters, dashes, and underscores. Certificate bundle names cannot contain spaces. Avoid entering confidential information.
Example: `example_certificate_bundle`

Sample:
certificate_name_example
   
cipher_suite_name
string
on success
The name of the cipher suite to use for HTTPS or SSL connections.
If this field is not specified, the default is `oci-default-ssl-cipher-suite-v1`.
**Notes:**
* You must ensure compatibility between the specified SSL protocols and the ciphers configured in the cipher suite. Clients cannot perform an SSL handshake if there is an incompatible configuration. * You must ensure compatibility between the ciphers configured in the cipher suite and the configured certificates. For example, RSA-based ciphers require RSA certificates and ECDSA-based ciphers require ECDSA certificates. * If the cipher configuration is not modified after load balancer creation, the `GET` operation returns `oci-default-ssl-cipher-suite-v1` as the value of this field in the SSL configuration for existing listeners that predate this feature. * If the cipher configuration was modified using Oracle operations after load balancer creation, the `GET` operation returns `oci-customized-ssl-cipher-suite` as the value of this field in the SSL configuration for existing listeners that predate this feature. * The `GET` operation returns `oci-wider-compatible-ssl-cipher-suite-v1` as the value of this field in the SSL configuration for existing backend sets that predate this feature. * If the `GET` operation on a listener returns `oci-customized-ssl-cipher-suite` as the value of this field, you must specify an appropriate predefined or custom cipher suite name when updating the resource. * The `oci-customized-ssl-cipher-suite` Oracle reserved cipher suite name is not accepted as valid input for this field.
example: `example_cipher_suite`

Sample:
cipher_suite_name_example
   
protocols
list / elements=string
on success
A list of SSL protocols the load balancer must support for HTTPS or SSL connections.
The load balancer uses SSL protocols to establish a secure connection between a client and a server. A secure connection ensures that all data passed between the client and the server is private.
The Load Balancing service supports the following protocols:
* TLSv1 * TLSv1.1 * TLSv1.2
If this field is not specified, TLSv1.2 is the default.
**Warning:** All SSL listeners created on a given port must use the same set of SSL protocols.
**Notes:**
* The handshake to establish an SSL connection fails if the client supports none of the specified protocols. * You must ensure compatibility between the specified SSL protocols and the ciphers configured in the cipher suite. * For all existing load balancer listeners and backend sets that predate this feature, the `GET` operation displays a list of SSL protocols currently used by those resources.
example: `["TLSv1.1", "TLSv1.2"]`

   
server_order_preference
string
on success
When this attribute is set to ENABLED, the system gives preference to the server ciphers over the client ciphers.
**Note:** This configuration is applicable only when the load balancer is acting as an SSL/HTTPS server. This field is ignored when the `SSLConfiguration` object is associated with a backend set.

Sample:
ENABLED
   
trusted_certificate_authority_ids
list / elements=string
on success
Ids for OCI certificates service CA or CA bundles for the load balancer to trust.
Example: `[ocid1.cabundle.oc1.us-ashburn-1.amaaaaaaav3bgsaagl4zzyqdop5i2vuwoqewdvauuw34llqa74otq2jdsfyq]`

   
verify_depth
integer
on success
The maximum depth for peer certificate chain verification.
Example: `3`

Sample:
56
   
verify_peer_certificate
boolean
on success
Whether the load balancer listener should verify peer certificates.
Example: `true`

Sample:
True


Authors

  • Oracle (@oracle)