Configuring BOSH Director on Azure Using Terraform

This topic describes how to configure the BOSH Director tile within Ops Manager on Azure after Deploying Ops Manager to Azure.

Note: You can also perform the procedures in this topic using the Ops Manager API. For more information, see the Using the Ops Manager API topic.

Prerequisite

To complete the procedures in this topic, you must have access to the output generated when you ran terraform apply to create resources for this deployment. To view this output, run terraform output in the directory where you ran terraform apply. You use tidhe values in this output to configure the BOSH Director tile.

Step 1: Access Ops Manager

  1. In a web browser, navigate to the fully qualified domain name (FQDN) of the BOSH Director. Use the ops_manager_dns value from running terraform output.

  2. When Ops Manager starts for the first time, you must choose one of the following:

    • Internal Authentication: If you use Internal Authentication, Ops Manager maintains your user database.
    • SAML Identity Provider: If you use a SAML Identity Provider (IdP), an external identity server maintains your user database.
    • LDAP Server: If you use a LDAP Server, an external identity server maintains your user database.

Internal Authentication

  1. When redirected to the Internal Authentication page, you must complete the following steps:

    • Enter a Username, Password, and Password confirmation to create an Admin user.
    • Enter a Decryption passphrase and the Decryption passphrase confirmation. This passphrase encrypts the Ops Manager datastore, and is not recoverable.
    • If you are using an HTTP proxy or HTTPS proxy, follow the instructions in the Configuring Proxy Settings for the BOSH CPI topic.
    • Read the End User License Agreement, and select the checkbox to accept the terms.
    • Click Setup Authentication.
  2. Log in to Ops Manager with the Admin username and password you created in the previous step.

SAML Identity Provider

  1. Log in to your IdP console and download the IdP metadata XML. Optionally, if your IdP supports metadata URL, you can copy the metadata URL instead of the XML.

  2. Copy the IdP metadata XML or URL to the Ops Manager SAML Identity Provider login page.

    Note: The same IdP metadata URL or XML is applied for the BOSH Director. If you use a separate IdP for BOSH, copy the metadata XML or URL from that IdP and enter it into the BOSH IdP Metadata text box in the Ops Manager login page.

  3. Enter values for the fields listed below. Failure to provide values in these fields results in a 500 error.

    • SAML admin group: Enter the name of the SAML group that contains all Ops Manager administrators. This field is case-sensitive.
    • SAML groups attribute: Enter the groups attribute tag name with which you configured the SAML server. This field is case-sensitive.
  4. Enter your Decryption passphrase. Read the End User License Agreement, and select the checkbox to accept the terms.

  5. Your Ops Manager login page appears. Enter your username and password. Click Login.

  6. Download your SAML Service Provider metadata (SAML Relying Party metadata) by navigating to the following URLs:

    • 6a. Ops Manager SAML service provider metadata: https://OPS-MAN-FQDN:443/uaa/saml/metadata
    • 6b. BOSH Director SAML service provider metadata: https://BOSH-IP-ADDRESS:8443/saml/metadata

      Note: To retrieve your BOSH-IP-ADDRESS, navigate to the Status tab in the BOSH Director tile. Record the BOSH Director IP address.

  7. Configure your IdP with your SAML Service Provider metadata. Import the Ops Manager SAML provider metadata from Step 6a above to your IdP. If your IdP does not support importing, provide the values below.

    • Single sign on URL: https://OPS-MAN-FQDN:443/uaa/saml/SSO/alias/OPS-MAN-FQDN
    • Audience URI (SP Entity ID): https://OP-MAN-FQDN:443/uaa
    • Name ID: Email Address
    • SAML authentication requests are always signed
  8. Import the BOSH Director SAML provider metadata from Step 6b to your IdP. If the IdP does not support an import, provide the values below.

    • Single sign on URL: https://BOSH-IP:8443/saml/SSO/alias/BOSH-IP
    • Audience URI (SP Entity ID): https://BOSH-IP:8443
    • Name ID: Email Address
    • SAML authentication requests are always signed
  9. Return to the BOSH Director tile, and continue with the configuration steps below.

LDAP Server

  • For Server URL, enter the URL that points to your LDAP server. With multiple LDAP servers, separate their URLs with spaces. Each URL must include one of the following protocols:

    • ldap://: This specifies that the LDAP server uses an unencrypted connection.
    • ldaps://: This specifies that the LDAP server uses SSL for an encrypted connection and requires that the LDAP server holds a trusted certificate or that you import a trusted certificate to the JVM truststore.
  • For LDAP Username and LDAP Password, enter the LDAP Distinguished Name (DN) and the password for binding to the LDAP Server. Example DN: cn=administrator,ou=Users,dc=example,dc=com

    Note: Pivotal recommends that you provide LDAP credentials that grant read-only permissions on the LDAP Search Base and the LDAP Group Search Base. In addition to this, if the bind user belongs to a different search base, you must use the full DN.

    WARNING: Pivotal recommends against reusing LDAP service accounts across environments. LDAP service accounts should not be subject to manual lockouts, such as lockouts that result from users utilizing the same account. Also, LDAP service accounts should not be subject to automated deletions, since disruption to these service accounts could prevent user logins.

  • For User Search Base, enter the location in the LDAP directory tree fromwhich any LDAP User search begins. The typical LDAP Search Base matches yourdomain name.

    For example, a domain named “cloud.example.com” typically uses the following LDAP User Search Base: ou=Users,dc=example,dc=com

  • For User Search Filter, enter a string that defines LDAP User search criteria. These search criteria allow LDAP to perform more effective and efficient searches. For example, the standard LDAP search filter cn=Smith returns all objects with a common name equal to Smith.

    In the LDAP search filter string that you use to configure your runtime, use {0} instead of the username. For example, use cn={0} to return all LDAP objects with the same common name as the username.

    In addition to cn, other attributes commonly searched for and returned are mail, uid and, in the case of Active Directory, sAMAccountName.

    Note: For instructions for testing and troubleshooting your LDAP search filters, see Configuring LDAP Integration with Pivotal Cloud Foundry in the Pivotal Support Knowledge Base.

  • For Group Search Base, enter the location in the LDAP directory tree from which the LDAP Group search begins.

    For example, a domain named “cloud.example.com” typically uses the following LDAP Group Search Base: ou=Groups,dc=example,dc=com

  • For Group Search Filter, enter a string that defines LDAP Group search criteria. The standard value is member={0}.

  • For Email Attribute, enter the attribute name in your LDAP directory that corresponds to the email address in each user record, for example mail.

  • For LDAP RBAC Admin Group Name, enter the DN of the LDAP group you want to have admin permissions in Ops Manager.

  • From the dropdown, select how the UAA handles LDAP server referrals out to other external user stores. The UAA can:

    • Automatically follow any referrals.
    • Ignore referrals and return partial result.
    • Throw exception for each referral and abort.
  • For Server SSL Cert, paste in the root certificate from your CA certificate or your self-signed certificate.

  • Enter a Decryption passphrase and the Decryption passphrase confirmation. This passphrase encrypts the Ops Manager datastore, and is not recoverable.

  • If you are using an HTTP proxy or HTTPS proxy, follow the instructions in Configuring Proxy Settings for the BOSH CPI.

  • Read the End User License Agreement, and select the checkbox to accept the terms.

  • Select Provision an admin client in the BOSH UAA. You can use this to enable BOSH automation with scripts and tooling. For more information, see Provision Admin Client in Creating UAA Clients for BOSH Director.

  • Click Setup Authentication.

  • Return to the BOSH Director tile, and continue with the configuration steps below.

Step 2: Azure Config Page

  1. Click the BOSH Director tile.

  2. Select Azure Config.

    At the top of the image is the header 'BOSH Director for Azure', below which are three tabs in a horizontal row labeled 'Settings', 'Status', and 'Credentials'. The Settings tab is highlighted in light gray to show that it is selected, while the others are dark gray. Below the Settings tab is a list of panes on the left labeled, from top to bottom: 'Azure Config', 'Director Config', 'Create Networks', 'Assign AZs and Networks', 'Security', 'BOSH DNS Config', 'Syslog', and 'Resource Config'. Each pane has a green circle with a checkmark inside to the left of its label. Azure Config is highlighted in dark gray to show that it is selected. To the right of the image is the header 'Azure Config', below which are text fields labeled, from top to bottom: 'Subscription ID', 'Tenant ID', 'Application ID', 'Client Secret', 'Resource Group Name', and 'BOSH Storage Account Name'. All of these fields are marked with red asterisks to denote that they are mandatory fields. The 'Client Secret' field contains eight asterisks, while the word 'Change' in blue letters is underneath the text field. Below 'BOSH Storage Account Name' are the words 'Cloud Storage Type' with two options underneath: a selected radio button labeled 'Use Managed Disks', below which is a dropdown labeled 'Storage Account Type' with 'Premium_LRS' selected; and a radio button labeled 'Use Storage Accounts', below which is a grayed-out text field labeled 'Deployments Storage Account Name'. Below this are more text fields, labeled 'Default Security Group' and 'SSH Public Key', the latter of which has a red asterisk. Next is a text area labeled 'SSH Private Key' with a red asterisk. Below the text area are the words 'Availability Mode' with two options underneath: a radio button labeled 'Availability Sets' and a selected radio button labeled 'Availability Zones'. Below these are the words 'Azure Environment' with five options underneath: a selected radio button labeled 'Azure Commercial Cloud', and four more radio buttons labeled, from top to bottom, 'Azure US Gov Cloud', 'Azure Germany Cloud', 'Azure China Cloud', and 'Azure Stack'. Below 'Azure Stack' are several grayed-out text fields and one text area, labeled, from top to bottom: 'Tenant Management Resource Endpoint', 'Domain', 'Authentication', 'Azure Stack Endpoint Prefix', and 'Azure Stack CA Certificate'. All of these have red asterisks to denote they are mandatory fields when the 'Azure Stack' option is selected. Below the 'Azure Stack CA Certificate' text area is a blue, rectangular button labeled 'Save'.

  3. Complete the following fields with information you obtained in the Preparing to Deploy Ops Manager on Azure Using Terraform topic.

    • Subscription ID: Enter the ID of your Azure subscription.
    • Tenant ID: Enter your TENANT_ID.
    • Application ID: Enter the APPLICATION_ID that you created in the Step 3: Create an AAD Application step of the Preparing to Deploy Ops Manager on Azure Using Terraform topic.
    • Client Secret: Enter your CLIENT_SECRET.
  4. Complete the following fields:

    • Resource Group Name: Enter the name of your resource group, which is exported from Terraform as the output pcf_resource_group_name.
    • BOSH Storage Account Name: Enter the name of your storage account, which is exported from Terraform as the output bosh_root_storage_account.
  5. For Cloud Storage Type, select Use Managed Disks. For Storage Account Type, select Premium_LRS which corresponds to SSD-based storage. See Azure Managed Disks Overview in the Microsoft documentation for more information. The words 'Cloud Storage Type' with two options underneath. The first option is a selected radio button labeled 'Use Managed Disks', below which is a dropdown labeled 'Storage Account Type' with 'Premium_LRS' selected. To the right of the dropdown is the help text 'Storage Account Type to use with managed disks'. The second option is a radio button labeled 'Use Storage Accounts', below which is a grayed-out text field labeled 'Deployments Storage Account Name'.

    Warning: You can update your deployment from using storage accounts to using managed disks. However, after you select Use Managed Disks and deploy Ops Manager, you cannot change your deployment back to use storage accounts.

  6. For Default Security Group, enter the bosh_deployed_vms_security_group_name output from Terraform.

  7. For SSH Public Key, enter the ops_manager_ssh_public_key output from Terraform.

  8. For SSH Private Key, enter the ops_manager_ssh_private_key output from Terraform.

  9. For Availability Mode, choose whether to use Availability Sets or Availability Zones. You can further configure this option in the Assign AZs and Networks Page.

    • For new installations of Ops Manager: Availability Zones are selected by default, but you can choose Availability Sets.
    • If you are upgrading from v2.4: You must use Availability Sets.

      Note: You can only choose between Availability Zones and Availability Sets in a staged BOSH Director tile that has not yet deployed. After you click Apply Changes and the BOSH Director deploys successfully, you cannot switch between Availability Zones and Availability Sets.

  10. For Azure Environment, select Azure Commercial Cloud.

  11. Click Save.

Step 3: Director Config Page

  1. In Ops Manager, select Director Config.

    At the top of the image is the header 'Director Config' with a horizonal line underneath. Below the line are three text fields labeled, from top to bottom, 'NTP Servers (comma delimited)', and 'Bosh HM Forwarder IP Address'. The NTP Servers (comma delimited) field has a red asterisk, to denote that it is a required field. Below these text fields are five checkboxes. The first checkbox is labeled 'Enable VM Resurrector Plugin'. The second checkbox is labeled 'Enable Post Deploy Scripts'. The third checkbox is labeled 'Recreate All VMs', underneath which is the text 'This will force BOSH to recreate all VMs on the next deploy. Persistent disk will be preserved'. The fourth checkbox is labeled 'Recreate All Persistent Disks', underneath which is the text 'Checking this box will recreate all Persistent Disks for the Director and all other Tiles'. The fifth checkbox is labeled 'Enable bosh deploy retries', underneath which is the text 'This will attempt to re-deploy a failed deployment up to 5 times.'

  2. In the NTP Servers (comma delimited) field, enter a comma-separated list of valid NTP servers.

    Note: The NTP server configuration only updates after VM recreation. Ensure that you select the Recreate all VMs checkbox if you modify the value of this field.

  3. Leave the Bosh HM Forwarder IP Address field blank.

    Note: Starting in PAS v2.0, BOSH-reported component metrics are available in the Loggregator Firehose by default. If you continue to use the BOSH HM Forwarder to consume these component metrics, you may receive duplicate data. To prevent this, leave the Bosh HM Forwarder IP Address field blank.

  4. Select the Enable VM Resurrector Plugin checkbox to enable the BOSH Resurrector functionality and increase your runtime availability.

  5. Select Enable Post Deploy Scripts to run a post-deploy script after deployment. This script allows the job to execute additional commands against a deployment.

    Note: If you intend to install PKS, you must enable post-deploy scripts.

  6. Select Recreate all VMs to force BOSH to recreate all VMs on the next deploy. This process does not destroy any persistent disk data.

  7. Select Recreate All Persistent Disks to force BOSH to migrate and recreate persistent disks for the BOSH Director and all tiles. This process does not destroy any persistent disk data.

  8. Select Enable bosh deploy retries to instruct Ops Manager to retry failed BOSH operations up to five times.

  9. Select Skip Director Drain Lifecycle to prevent drain scripts from running when the BOSH Director is recreated.

  10. Select Store BOSH Job Credentials on tmpfs (beta) to store credentials for BOSH jobs on temporary file storage (tmpfs) memory, rather than on disk. You must recreate all VMs for this setting to take effect.

  11. Select Keep Unreachable Director VMs if you want to preserve BOSH Director VMs after a failed deployment for troubleshooting purposes.

  12. Select HM Pager Duty Plugin to enable Health Monitor integration with PagerDuty.
    At the top of the image is a selected checkbox labeled 'HM Pager Duty Plugin'. Below this checkbox are two text fields labeled, from top to bottom, 'Service Key' and 'HTTP Proxy'. The Service Key field has a red asterisk to denote that it is a required field, and contains the text 'YOUR-PAGERDUTY-SERVICE-KEY'. The HTTP Proxy field contains the text 'YOUR-HTTP-PROXY'.

    • Service Key: Enter your API service key from PagerDuty.
    • HTTP Proxy: Enter an HTTP proxy for use with PagerDuty.
  13. Select HM Email Plugin to enable Health Monitor integration with email.

    At the top of the image is a selected checkbox labeled 'HM Email Plugin'. Below this checkbox are seven text fields labeled, from top to bottom, 'Host', 'Port', 'Domain', 'From', 'Recipients', 'Username', and 'Password'. The Host field has a red asterisk and contains the text 'smtp.example.com'. The Port field has a red asterisk and contains the text '25'. The Domain field has a red asterisk and contains the text 'cloudfoundry.example.com'. The From field has a red asterisk and contains the text 'user2@example.com'. The Recipients field has a red asterisk and contains the text 'user@example.com, user1@example.com'. The Username field contains the text 'user'. The Password field contains eight asterisks. At the bottom of the image is a selected checkbox labeled 'Enable TLS'.

    • Host: Enter your email hostname.
    • Port: Enter your email port number.
    • Domain: Enter your domain.
    • From: Enter the address for the sender.
    • Recipients: Enter comma-separated addresses of intended recipients.
    • Username: Enter the username for your email server.
    • Password: Enter the password for your email server.
    • Enable TLS: Select this checkbox to enable Transport Layer Security to the email host.
  14. For CredHub Encryption Provider, you can choose whether BOSH CredHub stores its encryption key internally on the BOSH Director and CredHub VM, or in an external hardware security module (HSM). The HSM option is more secure.

    Before configuring an HSM encryption provider in the Director Config pane, you must follow the procedures and collect information described in Preparing CredHub HSMs for Configuration.

    Note: After you deploy Ops Manager with an HSM encryption provider, you cannot change BOSH CredHub to store encryption keys internally.

    At the top of the image are the words 'CredHub Encryption Provider' with two options underneath: a selected radio button labeled 'Internal', and a radio button labeled 'Luna HSM'. Below these radio buttons are three text fields, two text areas, three more text fields, and one more text area, all grayed-out and labeled with red asterisks to denote that they are required fields when 'Luna HSM' is selected. They are labeled, from top to bottom: 'Encryption Key Name', 'Provider Partition', 'Provider Partition Password', 'Provider Client Certificate', 'Provider Client Certificate Private Key', 'HSM Host Address', 'HSM Port Address', 'Partition Serial Number', and 'HSM Certificate'.

    • Internal: Select this option for internal CredHub key storage. This option is selected by default and requires no additional configuration.
    • Luna HSM: Select this option to use a SafeNet Luna HSM as your permanent CredHub encryption provider, and fill in the following fields:
      1. Encryption Key Name: Any name to identify the key that the HSM uses to encrypt and decrypt the CredHub data. Changing this key name after you deploy Ops Manager can cause service downtime.
      2. Provider Partition: The partition that stores your encryption key. Changing this partition after you deploy Ops Manager could cause service downtime. For this value and the ones below, use values gathered in Preparing CredHub HSMs for Configuration.
      3. Provider Partition Password
      4. Provider Client Certificate: The certificate that validates the identity of the HSM when CredHub connects as a client.
      5. Provider Client Certificate Private Key
      6. HSM Host Address
      7. HSM Port Address: If you do not know your port address, enter 1792.
      8. Partition Serial Number
      9. HSM Certificate: The certificate that the HSM presents to CredHub to establish a two-way mTLS connection.

  15. Select a Blobstore Location to either configure the blobstore as an internal server or an external endpoint. Because the internal server is unscalable and less secure, Pivotal recommends that you configure an external blobstore.

    Note: After you deploy Ops Manager, you cannot change the blobstore location.

    • Internal: Select this option to use an internal blobstore. Ops Manager creates a new VM for blob storage. No additional configuration is required.
      • Enable TLS: Select this checkbox to enable TLS to the blobstore.

        Note: If you are using PASW 2016, make sure you have downloaded Windows stemcell v1709.10 or higher before enabling TLS.

    • S3 Compatible Blobstore: Select this option to use an external S3-compatible endpoint. At the top of the image are the words 'Blobstore Location', with a selected radio button underneath labeled 'Internal'. Below this radio button is a selected checkbox labeled 'Enable TLS'. Below this checkbox is a radio button labeled 'S3 Compatible Blobstore'. Below this radio button are four text fields labeled, from top to bottom, 'S3 Endpoint', 'Bucket Name', 'Access Key', and 'Secret Key'. The S3 Endpoint and Bucket Name fields have red asterisks, to denote that they are required fields when 'S3 Compatible Blobstore' is selected. The Access Key and Secret Key fields have red asterisks, to denote that they are required fields. Below the Secret Key field is a control group labeled 'S3 Signature Version.' The group contains two radio buttons labeled 'V2 Signature' and 'V4 Signature', and a text field labeled 'Region' with a red asterisk. Below the 'S3 Signature Version' group is another control group labeled 'S3 Backup Strategy with three radio button options: 'No Backups', 'Use a versioned bucket', and 'Copy into an additional bucket'. The additional bucket option has two text fields underneath, 'Backup Bucket Region' and 'Backup Button Name'.
      Follow the procedures in Sign up for Amazon S3 and Creating a Bucket in the AWS documentation. When you have created an S3 bucket, complete the following steps:
      1. S3 Endpoint: Navigate to the Regions and Endpoints topic in the AWS documentation.
        1. Locate the endpoint for your region in the Amazon Simple Storage Service (S3) table and construct a URL using your region’s endpoint. For example, if you are using the us-west-2 region, the URL you create would be https://s3-us-west-2.amazonaws.com. Enter this URL into the S3 Endpoint field.
        2. On a command line, run ssh ubuntu@OPS-MANAGER-FQDN to SSH into the Ops Manager VM. Replace OPS-MANAGER-FQDN with the fully qualified domain name of Ops Manager.
        3. Copy the custom public CA certificate you used to sign the S3 endpoint into /etc/ssl/certs on the Ops Manager VM.
        4. On the Ops Manager VM, run sudo update-ca-certificates -f -v to import the custom CA certificate into the Ops Manager VM truststore.

          Note: You must also add this custom CA certificate into the Trusted Certificates field in the Security page. See Security Page for instructions.

      2. Bucket Name: Enter the name of the S3 bucket.
      3. Access Key and Secret Key: Enter the keys you generated when creating your S3 bucket.
      4. Select V2 Signature or V4 Signature. If you select V4 Signature, enter your Region.

        Note: AWS recommends using Signature Version 4. For more information about AWS S3 Signatures, see Authenticating Requests in the AWS documentation.

      5. S3 Backup Strategy: Select one of the following to configure whether and how to back up the BOSH Director’s S3 blobstore:
        • No backups
        • Use a versioned bucket: This option uses blobstore bucket versioning to save backups. It requires an S3 blobstore that supports versioning.
        • Copy into an additional bucket: This option saves blobstore backups to a separate bucket, which is useful with blobstores that do not support versioning. The option requires you to fill in Backup Bucket Region and Backup Bucket Name.
    • GCS Blobstore: Select this option to use an external Google Cloud Storage (GCS) endpoint. At the top of the image, the 'GCP Blobstore' radio button is selected. Below this radio button is a text field labeled 'Bucket Name' with a red asterisk. Below this text field is a dropdown labeled 'Storage Class' with a red asterisk and the 'Regional' option selected. Below this dropdown is a text area labeled 'Service Account Key' with a red asterisk.
      Follow the procedures in Creating Storage Buckets in the GCS documentation to create a GCS bucket. To create a GCS bucket, you must have a GCS account. When you have created a GCS bucket, complete the following steps:
      1. Bucket Name: Enter the name of your GCS bucket.
      2. Storage Class: Select the storage class for your GCS bucket. See Storage Classes in the GCP documentation for more information.
      3. Service Account Key: Follow the steps in the Set up IAM Service Accounts section of Preparing to Deploy Ops Manager on GCP Manually to download a JSON file with a private key. Enter the contents of the JSON file into the field.

  16. For Database Location, select Internal.

  17. (Optional) Modify the Director Workers value, which sets the number of workers available to execute Director tasks. This field defaults to 5.

  18. (Optional) Max Threads sets the maximum number of threads that the BOSH Director can run simultaneously. Pivotal recommends that you leave the field blank to use the default value, unless doing so results in rate limiting or errors on your IaaS.

  19. (Optional) To add a custom URL for your BOSH Director, enter a valid hostname in Director Hostname. You can also use this field to configure a load balancer in front of your BOSH Director. For more information, see How to Set Up a Load Balancer in Front of Operations Manager Director in the Pivotal Support Knowlege Base.

    Three text fields labeled 'Director Workers', 'Max Threads', and 'Director Hostname'. The Director Workers field contains the text '5'. The Director Hostname field contains the text 'opsdirector.example.com'.

  20. (Optional) To set a custom banner that users see when logging in to the Director using SSH, enter text in the Custom SSH Banner field.

  21. (Optional) Enter your comma-separated custom Identification Tags. For example, iaas:foundation1, hello:world. You can use the tags to identify your foundation when viewing VMs or disks from your IaaS.

    Note: Azure has limited space for identification tags. Pivotal recommends entering no more than five tags.

  22. Click Save.

Step 4: Create Networks Page

Select Create Networks and follow the procedures in this section to add the network configuration that you created for your VPC.

Create Network for PAS

Create the following three networks:

Note: The Azure portal sometimes displays the names of resources with incorrect capitalization. Always use the Azure CLI to retrieve the correctly capitalized name of a resource.

PAS Infrastructure Network

To create the infrastructure network, do the following:

  1. (Optional) Select Enable ICMP checks to enable ICMP on your networks. Ops Manager uses ICMP checks to confirm that components within your network are reachable.

  2. Click Add Network.

  3. For Name, enter infrastructure.

  4. Under Subnets, create a subnet using the information in the following table:

    Network Name infrastructure
    Azure Network Name Enter NETWORK-NAME/SUBNET-NAME, where:
    • NETWORK-NAME is the network_name output from Terraform
    • SUBNET-NAME is the infrastructure_subnet_name output from Terraform
    CIDR Enter the CIDR listed under infrastructure_subnet_cidrs output from Terraform. For example, 10.0.8.0/26.
    Reserved IP Ranges Enter the first nine IP addresses of the subnet. For example, 10.0.8.1-10.0.8.9.
    DNS Enter 168.63.129.16.
    Gateway Enter the first IP address of the subnet. For example, 10.0.8.1.

    At the top of the image is the header 'Create Networks' with a horizontal line underneath. Below the line are the words 'Warning: Pivotal recommends keeping the IP settings throughout the life of your installation. Ops Manager may prevent you from changing them in the future. Contact Pivotal support for help completing such a change.' Below this text is the header 'Verification Settings', below which is a checkbox labeled 'Enable ICMP checks'. After this checkbox is the header 'Networks', across from which is a gray, rectangular button labeled 'Add Network'. Below 'Networks' are the words 'One or many IP ranges upon which your products will be deployed'. Below this is a gray, rectangular button labeled 'infrastructure' with a small, downward-pointing triangle to the left of it, indicating an expandable area. The image of a gray trashcan is directly across from the 'infrastructure' button. Below the 'infrastructure' button is a text field labeled 'Name' with a red asterisk to denote that it is a mandatory field, filled with the text 'infrastructure'. Below this text field is subheader 'Subnets', across from which is a gray, rectangular button labeled 'Add Subnet'. Below the Subnets subheader are text fields labeled, from top to bottom, 'Azure Network Name' with a red asterisk, 'CIDR' with a red asterisk, 'Reserved IP Ranges', 'DNS' with a red asterisk, and 'Gateway' with a red asterisk. The Azure Network Name field contains the text 'pcf-virtual-network/pcf-infrastructure-subnet'. The CIDR field contains the text '10.0.4.0/26'. The Reserved IP Ranges field contains the text '10.0.4.1-10.0.4.9'. The DNS field contains the text '168.63.129.16'. The Gateway field contains the text '10.0.4.1'.

  5. Click Save.

    Note: After you deploy Ops Manager, you add subnets with overlapping Availability Zones to expand your network. For more information about configuring additional subnets, see Expanding Your Network with Additional Subnets.

PAS Runtime Network

  1. Click Add Network.

  2. For Name, enter pas.

  3. Under Subnets, create a subnet using the information in the following table:

    Network Name pas
    Azure Network Name Enter NETWORK-NAME/SUBNET-NAME, where:
    • NETWORK-NAME is the network_name output from Terraform
    • SUBNET-NAME is the pas_subnet_name output from Terraform
    CIDR Enter the CIDR listed under pas_subnet_cidrs output from Terraform. For example, 10.0.0.0/22.
    Reserved IP Ranges Enter the first nine IP addresses of the subnet. For example, 10.0.0.1-10.0.0.9.
    DNS Enter 168.63.129.16.
    Gateway Enter the first IP address of the subnet. For example, 10.0.0.1.

    At the top of the image is a gray, rectangular button labeled 'pas' with a small, downward-pointing triangle to the left of it, indicating an expandable area. The image of a gray trashcan is directly across from the 'pas' button. Below the 'pas' button is a text field labeled 'Name' with a red asterisk to denote that it is a mandatory field, filled with the text 'pas'. Below this text field is the subheader 'Subnets', across from which is a gray, rectangular button labeled 'Add Subnet'. Below the Subnets subheader are text fields labeled, from top to bottom, 'Azure Network Name' with a red asterisk, 'CIDR' with a red asterisk, 'Reserved IP Ranges', 'DNS' with a red asterisk, and 'Gateway' with a red asterisk. The Azure Network Name field contains the text 'pcf-virtual-network/pcf-pas-subnet'. The CIDR field contains the text '10.0.12.0/22'. The Reserved IP Ranges field contains the text '10.0.12.1-10.0.12.9'. The DNS field contains the text '168.63.129.16'. The Gateway field contains the text '10.0.12.1'.

  4. Click Save.

PAS Services Network

  1. Click Add Network.

  2. For Name, enter services.

  3. Under Subnets, create a subnet using the information in the following table:

    Network Name services
    Azure Network Name Enter NETWORK-NAME/SUBNET-NAME, where:
    • NETWORK-NAME is the network_name output from Terraform
    • SUBNET-NAME is the services_subnet_name output from Terraform
    CIDR Enter the CIDR listed under services_subnet_cidrs output from Terraform. For example, 10.0.4.0/22.
    Reserved IP Ranges Enter the first nine IP addresses of the subnet. For example, 10.0.4.1-10.0.4.9.
    DNS Enter 168.63.129.16.
    Gateway Enter the first IP address of the subnet. For example, 10.0.4.1.

    At the top of the image is a gray, rectangular button labeled 'services' with a small, downward-pointing triangle to the left of it, indicating an expandable area. The image of a gray trashcan is directly across from the 'services' button. Below the 'services' button is a text field labeled 'Name' with a red asterisk to denote that it is a mandatory field, filled with the text 'services'. Below this text field is the subheader 'Subnets', across from which is a gray, rectangular button labeled 'Add Subnet'. Below the Subnets subheader are text fields labeled, from top to bottom, 'Azure Network Name' with a red asterisk, 'CIDR' with a red asterisk, 'Reserved IP Ranges', 'DNS' with a red asterisk, and 'Gateway' with a red asterisk. The Azure Network Name field contains the text 'pcf-virtual-network/pcf-services-subnet'. The CIDR field contains the text '10.0.8.0/22'. The Reserved IP Ranges field contains the text '10.0.8.1-10.0.8.9'. The DNS field contains the text '168.63.129.16'. The Gateway field contains the text '10.0.8.1'.

  4. Click Save. If Enable ICMP checks is not selected, you may see red warnings. You can ignore these warnings.

If you complete this step for PAS, proceed to Assign AZs and Networks Page.

Create Network for PKS

Create the following three networks:

Note: The Azure portal sometimes displays the names of resources with incorrect capitalization. Always use the Azure CLI to retrieve the correctly capitalized name of a resource.

PKS Infrastructure Network

To create the infrastructure network, do the following:

  1. (Optional) Select Enable ICMP checks to enable ICMP on your networks. Ops Manager uses ICMP checks to confirm that components within your network are reachable.

  2. Click Add Network.

  3. For Name, enter infrastructure.

  4. Under Subnets, create a subnet using the information in the following table:

    Network Name infrastructure
    Azure Network Name Enter NETWORK-NAME/SUBNET-NAME, where:
    • NETWORK-NAME is the network_name output from Terraform
    • SUBNET-NAME is the infrastructure_subnet_name output from Terraform
    CIDR Enter the CIDR listed under infrastructure_subnet_cidrs output from Terraform. For example, 10.0.8.0/26.
    Reserved IP Ranges Enter the first nine IP addresses of the subnet. For example, 10.0.8.1-10.0.8.9.
    DNS Enter 168.63.129.16.
    Gateway Enter the first IP address of the subnet. For example, 10.0.8.1.
  5. Click Save.

PKS Runtime Network

  1. Click Add Network.

  2. For Name, enter pks.

  3. Under Subnets, create a subnet using the information in the following table:

    Network Name pks
    Azure Network Name Enter NETWORK-NAME/SUBNET-NAME, where:
    • NETWORK-NAME is the network_name output from Terraform
    • SUBNET-NAME is the pks_subnet_name output from Terraform
    CIDR Enter the CIDR listed under pks_subnet_cidrs output from Terraform. For example, 10.0.12.0/22.
    Reserved IP Ranges Enter the first nine IP addresses of the subnet. For example, 10.0.12.1-10.0.12.9.
    DNS Enter 168.63.129.16.
    Gateway Enter the IP address listed under pks_subnet_gateway output from Terraform. This should be the first IP address of the subnet. For example, 10.0.12.1.
  4. Click Save.

PKS Services Network

  1. Click Add Network.

  2. For Name, enter services.

  3. Under Subnets, create a subnet using the information in the following table:

    Network Name services
    Azure Network Name Enter NETWORK-NAME/SUBNET-NAME, where:
    • NETWORK-NAME is the network_name output from Terraform
    • SUBNET-NAME is the services_subnet_name output from Terraform
    CIDR Enter the CIDR listed under services_subnet_cidrs output from Terraform. For example, 10.0.16.0/22.
    Reserved IP Ranges Enter the first nine IP addresses of the subnet. For example, 10.0.16.1-10.0.16.9.
    DNS Enter 168.63.129.16.
    Gateway Enter the IP address listed under services_subnet_gateway output from Terraform. This should be the first IP address of the subnet. For example, 10.0.16.1.
  4. Click Save. If Enable ICMP checks is not selected, you may see red warnings. You can ignore these warnings.

Step 5: Assign AZs and Networks Page

  1. Select Assign AZs and Networks.

    Note: The appearance of this page changes based on whether you are using Availability Zones or Availability Sets. For more information, see Step 2: Azure Config Page.

    • If you use Availability Zones, select one of the three available zones from the Singleton Availability Zone dropdown, then select a network from the Networks dropdown. The networks that appear in this list are networks that you created earlier in this procedure.
    • If you use Availability Sets, choose a network from the Networks dropdown. The networks that appear in this list are networks you created earlier in this procedure.
  2. Click Save.

Step 6: Security Page

  1. Select Security. At the top of the image is the header 'Security' with a horizontal line underneath. Below the line is a text area labeled 'Trusted Certificates', below which is the text 'These certificates enable BOSH-deployed components to trust a custom root certificate.' Below this text is a selected checkbox labeled 'Include OpsManager Root CA in Trusted Certs', underneath which is the text 'Checking this box will place the OpsManager Root CA into the trusted certificate field. The Bosh Director will then place this CA into the trust store of every VM that it deploys.' Below this text are the words 'Generate VM passwords or use single password for all VMs', below which are two options: one selected radio button labeled 'Generate passwords', and one radio button labeled 'Use default BOSH password'. At the bottom of the image is a blue, rectangular button labeled 'Save'.

  2. In Trusted Certificates, enter your custom certificate authority (CA) certificates to insert into your organization’s certificate trust chain. This feature enables all BOSH-deployed components in your deployment to trust custom root certificates.

    To enter multiple certificates, paste your certificates one after the other. For example, format your certificates like the following:

    -----BEGIN CERTIFICATE-----
    ABCDEFGH12345678ABCDEFGH12345678ABCDEFGH12345678AB
    EFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABCDEF
    GH12345678ABCDEFGH12345678ABCDEFGH12345678...
    ------END CERTIFICATE------
    -----BEGIN CERTIFICATE-----
    BCDEFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABB
    EFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABCDEF
    GH12345678ABCDEFGH12345678ABCDEFGH12345678...
    ------END CERTIFICATE------
    -----BEGIN CERTIFICATE-----
    CDEFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABBB
    EFGH12345678ABCDEFGH12345678ABCDEFGH12345678ABCDEF
    GH12345678ABCDEFGH12345678ABCDEFGH12345678...
    ------END CERTIFICATE------

    Note: If you want to use Docker registries to run PAS app instances in Docker containers, enter the certificate for your private Docker registry in this field. See Using Docker Registries for more information about running app instances in PAS using Docker registries.

  3. (Optional) Select the Include OpsManager Root CA in Trusted Certs checkbox to include the Ops Manager root CA in the Trusted Certificates field. BOSH Director includes this CA in the trust store of every VM that it deploys.

  4. Choose Generate passwords or Use default BOSH password. Pivotal recommends that you use the Generate passwords option for greater security.

  5. Click Save. To view your saved Director password, click the Credentials tab.

Step 7: BOSH DNS Config Page

The BOSH DNS Config pane allows you to configure DNS for BOSH Director by adding excluded recursors, a recursor timeout, and handlers.

The following describes the fields on the BOSH DNS Config pane:

  • Excluded Recursors: Exclude recursor addresses, which are URL redirects, so that they are not contacted by the BOSH DNS server. For more information about how the BOSH DNS release selects recursors, see Recursors in the BOSH documentation.
  • Recursor Timeout: Specify a timeout for the BOSH DNS server to contact any connected recursor addresses. The time limit includes dialing, writing, and reading from the recursor. If any of these actions exceeds the time limit, the action fails.
  • Handlers: Specify recursor addresses that apply to specific domains. For example, you can use handlers to forward all requests to a domain to a private DNS for resolution. For more information about using handlers, see Additional Handlers in the BOSH documentation.

To add excluded recursors, a recursor timeout, or handlers to the BOSH DNS release, do the following:

  1. Select BOSH DNS Config. At the top of the image is the header 'BOSH DNS Config', underneath which is a horizontal line. Below the line are two text fields labeled, from top to bottom, 'Excluded Recursors' and 'Recursor Timeout'. Below these fields is a text area labeled 'Handlers', containing the text '[]'. To the right of this text area is the help text 'Enter a JSON-formatted list of optional custom domain handlers'. At the bottom of the image is a blue, rectangular button labeled 'Save'.
  2. (Optional) In Excluded Recursors, enter a list of prohibited recursor addresses.
  3. (Optional) In Recursor Timeout, enter a time limit for contacting the connected recursors.

    Note: This time limit must include one of the Go parse duration time units. For example, entering 5s sets the timeout limit to five seconds. For more information about supported time units, see func ParseDuration in the Go Programming Language documentation.

  4. (Optional) In Handlers, enter an array of custom domain handlers in JSON format. For example:
        "dns_configuration": {
            "recursor_timeout": "2s",
            "handlers": [
              {
                "cache": {
                  "enabled": true
                },
                "domain": "example.com",
                "source": {
                  "type": "http",
                  "url": "http://example.endpoint.local"
                }
              }
            ]
        },
        
  5. Click Save.

Step 8: Syslog Page

  1. Select Syslog. At the top of the image is the header 'Settings' to the right of an image of a dark gray lock. Below this header is a list of panes on the far left of the image, labeled, from top to bottom: 'Change Decryption Passphrase', 'SAML Settings', 'LDAP Settings', 'SSL Certificate', 'Pivotal Network Settings', 'Proxy Settings', 'Custom Banner', 'Export Installation Settings', 'Syslog', and 'Advanced Options'. The Syslog pane is highlighted in dark gray to show that it is selected. To the right of this list and underneath the Settings header is the header 'Syslog' with a horizontal line underneath. Below the line is the text 'Syslog settings may take up to 1 min to take effect.' Below this text is the larger-font text 'Do you want to configure Syslog for OpsManager'? Below this text are two options: one radio button labeled 'No', and one selected radio button labeled 'Yes'. Below these are two text fields labeled, from top to bottom, 'Address' and 'Port'. Both fields have red asterisks, to denote that they are required. To the right of the Address field is the help text 'The address or host for the syslog server'. Below the Port field is a dropdown labeled 'Transport Protocol', with a red asterisk and the 'TCP' option selected. Below this dropdown is a selected checkbox labeled 'Enable TLS'. Below this checkbox is a text field labeled 'Permitted Peer' with a red asterisk. Below this field is a text area labeled 'SSL Certificate' with a red asterisk. Below this text area is a text field labeled 'Queue Size', containing the grayed-out example text '100000'. Below this text field is a checkbox labeled 'Forward Debug Logs'. Below this checkbox is a text area labeled 'Custom rsyslog Configuration'. At the bottom of the image is a blue, rectangular button labeled 'Save Syslog Settings'.

  2. (Optional) Select Yes to send BOSH Director system logs to a remote server.

  3. Enter the IP address or DNS name for the remote server in Address.

  4. Enter the port number that the remote server listens on in Port.

  5. Select TCP or UDP from the Transport Protocol dropdown. This selection determines which transport protocol is used to send the logs to the remote server.

  6. (Optional) Select the Enable TLS checkbox to send encrypted logs to remote server with TLS. After you select the checkbox, do the following:

    1. Enter either the name or SHA1 fingerprint of the remote peer in Permitted Peer.
    2. Enter the SSL certificate for the remote server in SSL Certificate.

      Note: Pivotal strongly recommends that you enable TLS encryption when you are forwarding logs. Logs can contain sensitive information, such as cloud provider credentials.

  7. (Optional) Enter an integer in Queue Size. This value specifies the number of log messages held in the buffer. The default value is 100,000.

  8. (Optional) Select the checkbox to Forward Debug Logs to an external source. This option is deselected by default. If you select it, you may generate a large amount of log data.

  9. (Optional) Enter configuration details for rsyslog in the Custom rsyslog Configuration field. This field requires the rainerscript syntax.

  10. Click Save Syslog Settings.

Step 9: Resource Config Page

  1. Select Resource Config. At the top of the image is the header 'Resource Config' with a horizontal line underneath. Below the line are six columns labeled, from left to right, 'Job', 'Instances', 'Persistent Disk Type', 'VM Type', 'Load Balancers', and 'Internet Connected'. Under 'Job' are rows labeled with the names of two VMs, 'Ops Manager Director' and 'Master Compilation Job'. Under 'Instances' are two dropdowns, with 'Automatic: 1' for Ops Manager Director and 'Automatic: 4' for Master Compilation Job selected. Under 'Persistent Disk Type' is one dropdown with 'Automatic: 50 GB' selected for Ops Manager Director and the word 'None' for Master Compilation Job. Under 'VM Type' are two dropdowns, with 'Automatic: Standard_DS2_v2 (cpu: 2, ram: ...' selected for Ops Manager Director and 'Automatic: Standard_F4s (cpu: 4, ram: 8 GB ...' selected for Master Compilation Job. Under 'Load Balancers' are two blank fields. Under 'Internet Connected' are two checkboxes. At the bottom of the image is a blue, rectangular button labeled 'Save'.

  2. Adjust any values as necessary for your deployment. Under the Instances, Persistent Disk Type, and VM Type fields, choose Automatic from the dropdown to allocate the recommended resources for the job. If the Persistent Disk Type field reads None, the job does not require persistent disk space.

    Note: Pivotal recommends provisioning a BOSH Director VM with at least 8 GB memory.

    Note: If you set a field to Automatic and the recommended resource allocation changes in a future version, Ops Manager automatically uses the new recommended allocation.

    Note: If you install PAS for Windows, provision your Master Compilation Job with at least 100 GB of disk space.

  3. (Optional) For Load Balancers, enter your Azure application gateway name for each associated job. To create an application gateway, follow the procedures in Create an application gateway with SSL termination using Azure PowerShell from the Azure documentation. When you create the application gateway, associate the gateway’s IP with your system domain.

  4. Click Save.

Step 10: (Optional) Add Custom VM Extensions

Use the Ops Manager API to add custom properties to your VMs such as associated security groups and load balancers. For more information, see Managing Custom VM Extensions.

Step 11: Complete the BOSH Director Installation

  1. Click the Installation Dashboard link to return to the Installation Dashboard.

  2. Click Review Pending Changes, then Apply Changes. If the following ICMP error message appears, click Ignore errors and start the install.

    At the top of the image is the rectangular, dark green Ops Manager page header, with a teal square containing a capital P on the far left, the words 'PCF Ops Manager' to the right of the square, and the words 'pivotal-cf' beside a downward-pointing carat on the far right. Below the header is an error message with a red background. To the left on the error message is a red triangle containing an exclamation point beside the words 'Please review the errors below'. Below 'Please review the errors below' is a bullet list with two items: 'Cannot reach gateway with IP 10.0.16.1 (ignorable if ICMP is disabled)' and 'Cannot reach DNS with IP 10.0.0.2 (ignorable if ICMP is disabled)'. To the right of this list are two buttons: a white, rectangular button labeled 'Ignore errors and start the install' in red letters on the left, and a red, rectangular button labeled 'Stop and fix errors' in white letters on the right.

  3. BOSH Director installs. This may take a few moments. When the installation process successfully completes, the Changes Applied window appears.

    A pop-up window with a round, gray X button in the upper-right corner and the words 'Changed Applied' next to a round, green circle containing a checkmark. Below 'Changed Applied' are the words 'Ops Manager Director was successfully installed. We recommend that you export a backup of this installation from the actions menu.' Below this text and to the right of the pop-up window are a gray, rectangular button labeled 'Close' next to a blue, rectangular button labeled 'Return to Installation Dashboard'.

Next Steps

After you complete this procedure, do one of the following:

Create a pull request or raise an issue on the source for this page in GitHub