Deploying PAS on AWS

Page last updated:

This topic describes how to configure Pivotal Application Service (PAS) components as part of deploying Pivotal Cloud Foundry (PCF) on Amazon Web Services (AWS).

Before beginning this procedure, ensure that you have successfully completed all steps in the Installing PCF on AWS Manually and Configuring BOSH Director on AWS.

Note: If you plan to install the PCF IPsec add-on, you must do so before installing any other tiles. Pivotal recommends installing IPsec immediately after Ops Manager, and before installing the PAS Runtime tile.

Step 1: Add PAS to Ops Manager

  1. If you have not already downloaded PAS, log in to Pivotal Network, and click on PAS.

  2. From the Releases dropdown, select the release to install and choose one of the following:

    1. Click PAS download the PAS .pivotal file.
    2. Click PCF Small Footprint Runtime to download the Small Footprint Runtime .pivotal file. For more information, see Getting Started with Small Footprint Runtime.
  3. Navigate to the Pivotal Cloud Foundry Operations Manager Installation Dashboard.

  4. Click Import a Product to add your tile to Ops Manager. For more information, refer to the Adding and Deleting Products topic.

  5. Click the PAS tile in the Installation Dashboard.

    Er tile

Step 2: Assign Availability Zones and Networks

  1. Select Assign AZs and Networks. These are the Availability Zones that you create when configuring BOSH Director.
    AZs

  2. Select an Availability Zone under Place singleton jobs. Ops Manager runs any job with a single instance in this Availability Zone.

  3. Select all Availability Zones under Balance other jobs. Ops Manager balances instances of jobs with more than one instance across the Availability Zones that you specify.

    Note: Pivotal recommends at least three Availability Zones for a highly available installation of PAS.

  4. For Network, select the pas network that you created in the Step 5: Create Networks Page section of the Configuring BOSH Director on AWS topic.

  5. Click Save.

Step 3: Configure Domains

  1. Select Domains.

    Domains

  2. Enter the system and application domains.

    • The System Domain defines your target when you push apps to PAS. This the system.YOUR-SYSTEM-DOMAIN.com domain that you created in Installing PCF on AWS Manually.
    • The Apps Domain defines where PAS should serve your apps. This the apps.YOUR-SYSTEM-DOMAIN.com domain that you created in Installing PCF on AWS Manually.
  3. Click Save.

Step 4: Configure Networking

  1. Select Networking.

  2. Leave the Router IPs, SSH Proxy IPs, HAProxy IPs, and TCP Router IPs fields blank. You do not need to complete these fields when deploying PCF to AWS with Elastic Load Balancers (ELBs).

    Note: You specify load balancers in the Resource Config section of Pivotal Application Service (PAS) later in the installation process. See the Configure Router to Elastic Load Balancer section of this topic for more information.

  3. Under Certificates and Private Key for HAProxy and Router, you must provide at least one Certificate and Private Key name and certificate key pair for HAProxy and Gorouter. The HAProxy and Gorouter are enabled to receive TLS communication by default. You can configure multiple certificates for HAProxy and Gorouter.

    1. Click the Add button to add a name for the certificate chain and its private key pair. This certificate is the default used by Gorouter and HAProxy. Networking haproxy router cert config You can either provide a certificate signed by a Certificate Authority (CA) or click on the Generate RSA Certificate link to generate a certificate in Ops Manager.

      Note: If you configured Ops Manager Front End without a certificate, you can use this new certificate to complete Ops Manager configuration. To configure your Ops Manager Front End certificate, see Configure Front End in Preparing to Deploy Ops Manager on GCP Manually.

    2. If you want to configure multiple certificates for HAProxy and Gorouter, click the Add button and fill in the appropriate fields for each additional certificate key pair. For details about generating certificates in Ops Manager for your wildcard system domains, see the Providing a Certificate for Your SSL/TLS Termination Point topic.

      Note: Ensure that you add any certificates that you generate in this pane to your infrastructure load balancer.

  4. (Optional) When validating client requests using mutual TLS, the Gorouter trusts multiple certificate authorities (CAs) by default. If you want to configure the Gorouter and HAProxy to trust additional CAs, enter your CA certificates under Certificate Authorities Trusted by Router and HAProxy. All CA certificates should be appended together into a single collection of PEM-encoded entries. Networking router haproxy ca

  5. In the Minimum version of TLS supported by HAProxy and Router field, select the minimum version of TLS to use in HAProxy and Gorouter communications. HAProxy and Gorouter use TLS v1.2 by default. If you need to accommodate clients that use an older version of TLS, select a lower minimum version. For a list of TLS ciphers supported by the Gorouter, see Securing Traffic into Cloud Foundry. Networking min tls version

  6. Configure Logging of Client IPs in CF Router. The Log client IPs option is set by default. To comply with the General Data Protection Regulation (GDPR), select one of the following options to disable logging of client IP addresses:

    • If your load balancer exposes its own source IP address, disable logging of the X-Forwarded-For HTTP header only.
    • If your load balancer exposes the source IP of the originating client, disable logging of both the source IP address and the X-Forwarded-For HTTP header.
    • Router ip logging

  7. Under Configure support for the X-Forwarded-Client-Cert header, configure PCF handles x-forwarded-client-cert (XFCC) HTTP headers based on where TLS is terminated for the first time in your deployment. Networking xforwarded client cert xfcc The following table indicates which option to choose based on your deployment layout.

    If your deployment is configured as follows: Then select the following option: Additional notes:
    • The Load Balancer is terminating TLS, and
    • Load balancer is configured to put the client certificate from a mutual authentication TLS handshake into the X-Forwarded-Client-Cert HTTP header
    TLS terminated for the first time at infrastructure load balancer (default). Both HAProxy and the Gorouter forward the XFCC header when included in the request.
    • The Load Balancer is configured to pass through the TLS handshake via TCP to the instances of HAProxy, and
    • HAProxy instance count is > 0
    TLS terminated for the first time at HAProxy. HAProxy sets the XFCC header with the client certificate received in the TLS handshake. The Gorouter forwards the header.

    Breaking Change: In the Router behavior for Client Certificates field, you cannot select the Router does not request client certificates option.

    • The Load Balancer is configured to pass through the TLS handshake via TCP to instances of the Gorouter

    TLS terminated for the first time at the Gorouter. The Gorouter strips the XFCC header if it is included in the request and forwards the client certificate received in the TLS handshake in a new XFCC header.

    If you have deployed instances of HAProxy, app traffic bypasses those instances in this configuration. If you have also configured your load balancer to route requests for ssh directly to the Diego Brain, consider reducing HAProxy instances to 0.

    Breaking Change: In the Router behavior for Client Certificates field, you cannot select the Router does not request client certificates option.


    For a description of the behavior of each configuration option, see Forward Client Certificate to Applications.

  8. To configure HAProxy to handle client certificates, select one of the following options in the HAProxy behavior for Client Certificate Validation field. Networking haproxy client cert validate

    • HAProxy does not request client certificates. This option requires mutual authentication, which makes it incompatible with XFCC option TLS terminated for the first time at HAProxy. HAProxy does not request client certificates, so the client does not provide them and no validation occurs. This is the default configuration.
    • HAProxy requests but does not require client certificates. The HAProxy requests client certificates in TLS handshakes, validates them when presented, but does not require them.

    WARNING: Upon upgrade, PAS will fail to receive requests if your load balancer is configured to present a client certificate in the TLS handshake with HAProxy but HAProxy has not been configured with the certificate authority used to sign it. To mitigate this issue, select HAProxy does not request client certificates in the Networking pane or configure the HAProxy with the appropriate CA.

  9. To configure Gorouter behavior for handling client certificates, select one of the following options in the Router behavior for Client Certificate Validation field. Networking router client cert validate

    • Router does not request client certificates. This option is incompatible with the XFCC configuration options TLS terminated for the first time at HAProxy and TLS terminated for the first time at the Router in PAS because these options require mutual authentication. As client certificates are not requested, client will not provide them, and thus validation of client certificates will not occur.
    • Router requests but does not require client certificates. The Gorouter requests client certificates in TLS handshakes, validates them when presented, but does not require them. This is the default configuration.
    • Router requires client certificates. The Gorouter validates that the client certificate is signed by a Certificate Authority that the Gorouter trusts. If the Gorouter cannot validate the client certificate, the TLS handshake fails.

    WARNING: Requests to the platform will fail upon upgrade if your load balancer is configured with client certificates and the Gorouter does not have the certificate authority. To mitigate this issue, select Router does not request client certificates for Router behavior for Client Certificate Validation in the Networking pane.

  10. In the TLS Cipher Suites for Router field, review the TLS cipher suites for TLS handshakes between Gorouter and front-end clients such as load balancers or HAProxy. The default value for this field is ECDHE-RSA-AES128-GCM-SHA256:TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384.

    Note: AWS Classic Load Balancers do not support PCF’s default cipher suites. See TLS Cipher Suite Support by AWS Load Balancers for information about configuring your AWS load balancers and Gorouter.

    If you want to modify the default configuration, use an ordered, colon-delimited list of Golang-supported TLS cipher suites in the OpenSSL format.
    Operators should verify that the ciphers are supported by any clients or front-end components that will initiate TLS handshakes with Gorouter. For a list of TLS ciphers supported by Gorouter, see Securing Traffic into Cloud Foundry. Networking tls router Verify that every client participating in TLS handshakes with Gorouter has at least one cipher suite in common with Gorouter.

    Note: Specify cipher suites that are supported by the versions configured in the Minimum version of TLS supported by HAProxy and Router field.

  11. In the TLS Cipher Suites for HAProxy field, review the TLS cipher suites for TLS handshakes between HAProxy and its clients such as load balancers and Gorouter. The default value for this field is the following:
    DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384 If you want to modify the default configuration, use an ordered, colon-delimited list of TLS cipher suites in the OpenSSL format.
    Operators should verify that the ciphers are supported by any clients or front-end components that will initiate TLS handshakes with HAProxy. Networking tls haproxy Verify that every client participating in TLS handshakes with HAProxy has at least one cipher suite in common with HAProxy.

    Note: Specify cipher suites that are supported by the versions configured in the Minimum version of TLS supported by HAProxy and Router field.

  12. Under HAProxy forwards requests to Router over TLS, select Enable or Disable based on your deployment layout. Networking haproxy router tls forward

    • Enable HAProxy forwarding of requests to Router over TLS
    If you want to: Encrypt communication between HAProxy and the Gorouter
    Then configure the following:
    1. Leave Enable selected.
    2. In the Certificate Authority for HAProxy Backend field, specify the Certificate Authority (CA) that signed the certificate you configured in the Certificate and Private Key for HAProxy and Router field.

      Note: If you used the Generate RSA Certificate link to generate a certificate, then the CA to specify is the Ops Manager CA, which you can locate at the /api/v0/certificate_authorities endpoint in the Ops Manager API.

    3. Make sure that Gorouter and HAProxy have TLS cipher suites in common in the TLS Cipher Suites for Router and TLS Cipher Suites for HAProxy fields.
    See also:
    • Disable HAProxy forwarding of requests to Router over TLS
    If you want to: Use non-encrypted communication between HAProxy and Gorouter, or you are not using HAProxy
    Then configure the following:
    1. Select Disable.
    2. If you are not using HAProxy, set the number of HAProxy job instances to 0 on the Resource Config page. See Disable Unused Resources.
    See also:

  13. If you want to force browsers to use HTTPS when making requests to HAProxy, select Enable in the HAProxy support for HSTS field, and complete the following optional configuration steps: This image depicts the HSTS configuration fields for HAProxy. Explanations of these fields follow.

    1. (Optional) Enter a Max Age in Seconds for the HSTS request. By default, the age is set to one year. HAProxy will force HTTPS requests from browsers for the duration of this setting.
    2. (Optional) Select the Include Subdomains checkbox to force browsers to use HTTPS requests for all component subdomains.
    3. (Optional) Select the Enable Preload checkbox to force instances of Google Chrome, Firefox, and Safari that access your HAProxy to refer to their built-in lists of known hosts that require HTTPS, of which HAProxy is one. This ensures that the first contact a browser has with your HAProxy is an HTTPS request, even if the browser has not yet received an HSTS header from HAProxy.

  14. If you are not using SSL encryption or if you are using self-signed certificates, select Disable SSL certificate verification for this environment. Selecting this checkbox also disables SSL verification for route services and disables mutual TLS app identity verification.

    Note: For production deployments, Pivotal does not recommend disabling SSL certificate verification.

  15. (Optional) If you want HAProxy or the Gorouter to reject any HTTP (non-encrypted) traffic, select the Disable HTTP on HAProxy and Gorouter checkbox. When selected, HAProxy and Gorouter will not listen on port 80.
    Networking disable http haproxy gorouter

  16. (Optional) Select the Disable insecure cookies on the Router checkbox to set the secure flag for cookies generated by the router.

  17. (Optional) To disable the addition of Zipkin tracing headers on the Gorouter, deselect the Enable Zipkin tracing headers on the router checkbox. Zipkin tracing headers are enabled by default. For more information about using Zipkin trace logging headers, see Zipkin Tracing in HTTP Headers.

  18. (Optional) To stop the Router from writing access logs to local disk, deselect the Enable Router to write access logs locally checkbox. You should consider disabling this checkbox for high traffic deployments since logs may not be rotated fast enough and can fill up the disk.

  19. By default, the PAS routers handle traffic for applications deployed to an isolation segment created by the PCF Isolation Segment tile. To configure the PAS routers to reject requests for applications within isolation segments, select the Routers reject requests for Isolation Segments checkbox. Isolate network Do not enable this option without deploying routers for each isolation segment. See the following topics for more information:

  20. (Optional) By default, Gorouter support for the PROXY protocol is disabled. To enable the PROXY protocol, select Enable support for PROXY protocol in CF Router. When enabled, client-side load balancers that terminate TLS but do not support HTTP can pass along information from the originating client. Enabling this option may impact Gorouter performance. For more information about enabling the PROXY protocol in Gorouter, see the HTTP Header Forwarding sections in the Securing Traffic in Cloud Foundry topic.

  21. In the Choose whether to enable route services section, choose either Enable route services or Disable route services. Route services are a class of marketplace services that perform filtering or content transformation on application requests and responses. See the Route Services topic for details.

    1. If you enabled route services, you can also configure the Bypass security checks for route service lookup field. Pivotal recommends that you do not enable this field because it has potential security concerns. However, you may need to enable it if your load balancer requires mutual TLS from clients. For more information, see Configuring Route Service Lookup.

  22. (Optional) If you want to limit the number of app connections to the backend, enter a value in the Max Connections Per Backend field. You can use this field to prevent a poorly behaving app from all the connections and impacting other apps.

    To choose a value for this field, review the peak concurrent connections received by instances of the most popular apps in your deployment. You can determine the number of concurrent connections for an app from the httpStartStop event metrics emitted for each app request.

    If your deployment uses PCF Metrics, you can also obtain this peak concurrent connection information from Network Metrics. The default value is 500. Networking max connections backend

  23. Under Enable Keepalive Connections for Router, select Enable or Disable. Keep-alive connections are enabled by default. For more information, see Keepalive Connections in HTTP Routing.
    Keepalive connections

  24. (Optional) To accommodate larger uploads over connections with high latency, increase the number of seconds in the Router Timeout to Backends field.

  25. (Optional) Use the Frontend Idle Timeout for Gorouter and HAProxy field to help prevent connections from your load balancer to Gorouter or HAProxy from being closed prematurely. The value you enter sets the duration, in seconds, that Gorouter or HAProxy maintains an idle open connection from a load balancer that supports keep-alive.

    In general, set the value higher than your load balancer’s backend idle timeout to avoid the race condition where the load balancer sends a request before it discovers that Gorouter or HAProxy has closed the connection.

    See the following table for specific guidance and exceptions to this rule:

    IaaS Guidance
    AWS AWS ELB has a default timeout of 60 seconds, so Pivotal recommends a value greater than 60.
    Azure By default, Azure load balancer times out at 240 seconds without sending a TCP RST to clients, so as an exception, Pivotal recommends a value lower than 240 to force the load balancer to send the TCP RST.
    GCP GCP has a default timeout of 600 seconds. For GCP HTTP load balancers, Pivotal recommends a value greater than 600. For GCP TCP load balancers, pivotal recommends a value less than 600 to force the load balancer to send a TCP RST.
    Other Set the timeout value to be greater than that of the load balancer’s backend idle timeout.

    Note: Do not set a frontend idle timeout lower than six seconds.

  26. (Optional) Increase the value of Load Balancer Unhealthy Threshold to specify the amount of time, in seconds, that the router continues to accept connections before shutting down. During this period, healthchecks may report the router as unhealthy, which causes load balancers to failover to other routers. Set this value to an amount greater than or equal to the maximum time it takes your load balancer to consider a router instance unhealthy, given contiguous failed healthchecks.

  27. (Optional) Modify the value of Load Balancer Healthy Threshold. This field specifies the amount of time, in seconds, to wait until declaring the Router instance started. This allows an external load balancer time to register the Router instance as healthy.

    LB Healthy Threshold Field

  28. (Optional) If app developers in your organization want certain HTTP headers to appear in their app logs with information from the Gorouter, specify them in the HTTP Headers to Log field. For example, to support app developers that deploy Spring apps to PCF, you can enter Spring-specific HTTP headers.

    Http Headers to Log

  29. If you expect requests larger than the default maximum of 16 Kbytes, enter a new value (in bytes) for HAProxy Request Max Buffer Size. You may need to do this, for example, to support apps that embed a large cookie or query string values in headers.

  30. If your PCF deployment uses HAProxy and you want it to receive traffic only from specific sources, use the following fields:

    • HAProxy Protected Domains: Enter a comma-separated list of domains to protect from unknown source requests.
    • HAProxy Trusted CIDRs: Optionally, enter a space-separated list of CIDRs to limit which IP addresses from the Protected Domains can send traffic to PCF.
    Protected domains

  31. The Loggregator Port defaults to 443 if left blank. For AWS environments that are not using an Application Load Balancer, enter 4443.

  32. For Container Network Interface Plugin, ensure Silk is selected and review the following fields: Cni silk

    Note: The External option exists to support NSX-T integration for vSphere deployments.

    1. (Optional) You can change the value in the Applications Network Maximum Transmission Unit (MTU) field. Pivotal recommends setting the MTU value for your application network to 1454. Some configurations, such as networks that use GRE tunnels, may require a smaller MTU value.

    2. (Optional) Enter an IP range for the overlay network in the Overlay Subnet box. If you do not set a custom range, Ops Manager uses 10.255.0.0/16.

      WARNING: The overlay network IP range must not conflict with any other IP addresses in your network.

    3. Enter a UDP port number in the VXLAN Tunnel Endpoint Port box. If you do not set a custom port, Ops Manager uses 4789.

    4. For Denied logging interval, set the per-second rate limit for packets blocked by either a container-specific networking policy or by Application Security Group rules applied across the space, org, or deployment. This field defaults to 1.
    5. For UDP logging interval, set the per-second rate limit for UDP packets sent and received. This field defaults to 100.
    6. To enable logging for app traffic, select Log traffic for all accepted/denied application packets. See Manage Logging for Container-to-Container Networking for more information.

  33. For DNS Search Domains, enter DNS search domains as a comma-separated list. Your containers append these search domains to hostnames to resolve them into full domain names. Dns search domains

  34. For Database Connection Timeout, set the connection timeout for clients of the policy server and silk databases. The default value is 120. You may need to increase this value if your deployment experiences timeout issues related to Container-to-Container Networking.

  35. (Optional) TCP Routing is disabled by default. You should enable this feature if your DNS sends TCP traffic through a load balancer rather than directly to a TCP router. To enable TCP routing:

    1. Select Enable TCP Routing
    2. For TCP Routing Ports, enter a single port or a range of ports for the load balancer to forward to. If you configured AWS for PCF manually, enter 1024-1123 which corresponds to the rules you created for pcf-tcp-elb.
      • To support multiple TCP routes, Pivotal recommends allocating multiple ports.
      • To allocate a list of ports rather than a range:
        1. Enter a single port in the TCP Routing Ports field.
        2. After deploying PAS, follow the directions in Configuring a List of TCP Routing Ports to add TCP routing ports using the cf CLI.
    3. For AWS, you also need to specify the name of a TCP ELB in the LOAD BALANCER column of TCP Router job of the Resource Config screen. You configure this later on in PAS. For more information, see the Configure Router to Elastic Load Balancer topic.

    Ert tcp routing enable

  36. (Optional) To disable TCP routing, click Select this option if you prefer to enable TCP Routing at a later time. For more information, see the Configuring TCP Routing in PAS topic.

  37. (Optional) To enable the creation of dynamic egress policies that allow apps to reach external services, select Enable Beta Dynamic Egress Enforcement. For more information about this feature, see Administering Dynamic Egress Policies (Beta).

  38. (Optional) For additional security, enter headers that you want the router to remove from app responses in Remove Specified HTTP Response Headers.

  39. Click Save.

Step 5: Configure Application Containers

  1. Select Application Containers.

    Docker registry ert

  2. The Enable Custom Buildpacks checkbox governs the ability to pass a custom buildpack URL to the -b option of the cf push command. By default, this ability is enabled, letting developers use custom buildpacks when deploying apps. Disable this option by disabling the checkbox. For more information about custom buildpacks, refer to the buildpacks section of the PCF documentation.

  3. The Allow SSH access to app containers checkbox controls SSH access to application instances. Enable the checkbox to permit SSH access across your deployment, and disable it to prevent all SSH access. See the Application SSH Overview topic for information about SSH access permissions at the space and app scope.

  4. If you want to enable SSH access for new apps by default in spaces that allow SSH, select Enable SSH when an app is created. If you deselect the checkbox, developers can still enable SSH after pushing their apps by running cf enable-ssh APP-NAME.

  5. To enable the Gorouter to verify app identity using TLS, click Router uses TLS to verify application identity. To enable the Gorouter and your apps to verify each other’s identity using TLS, click Router and applications use mutual TLS to verify each other’s identity.

    Verifying app identity using TLS or mutual TLS enables encryption between router and app containers and guards against misrouting during control plane failures. For more information about Gorouter route consistency modes, see Preventing Misrouting in HTTP Routing.

    Warning: TLS routing requires an additional 32 MB of RAM capacity on Diego cells per app instance. It also requires additional CPU capacity on Diego cells. If the total amount of Diego cell memory available is less than 32 MB times the number of running app instances, scale your Diego cells before configuring the Gorouter with TLS. For more information, see Configure Gorouter with TLS in Upgrade Preparation Checklist for PCF v2.4.

    Warning: You may see an increase of memory and CPU usage for your Gorouters after enabling TLS routing. If the total amount of memory and CPU usage of the Gorouters in your environment are close to the size limit, scale your Gorouters before enabling TLS routing. For more information, see Configure Gorouter with TLS in Upgrade Preparation Checklist for PCF v2.4.

    Note: Mutual TLS app identity verification does not work for Windows containers.

    Note: This feature does not work if the Disable SSL certificate verification for this environment checkbox is selected.

  6. You can configure Pivotal Application Service (PAS) to run app instances in Docker containers by supplying their IP address ranges in the Private Docker Insecure Registry Whitelist textbox. See the Using Docker Registries topic for more information.

  7. Select your preference for Docker Images Disk-Cleanup Scheduling on Cell VMs. If you choose Clean up disk-space once usage fills disk, enter a Reserved amount of disk space for other jobs in megabytes. For more information about the configuration options and how to configure a reserved amount, see Configuring Docker Images Disk-Cleanup Scheduling.

  8. Enter a number in the Max Inflight Container Starts textbox. This number configures the maximum number of started instances across the Diego cells in your deployment. For more information about this feature, see Setting a Maximum Number of Started Containers.

  9. Under Enabling NFSv3 volume services, select Enable or Disable. NFS volume services allow application developers to bind existing NFS volumes to their applications for shared file access. For more information, see the Enabling NFS Volume Services topic.

    Note: In a fresh install, NFSv3 volume services is enabled by default. In an upgrade, NFSv3 volume services is set to the same setting as it was in the previous deployment.

  10. (Optional) To configure LDAP for NFSv3 volume services, do the following: Er config app vol svc

    • For LDAP Service Account User, enter the username of the service account in LDAP that will manage volume services.
    • For LDAP Service Account Password, enter the password for the service account.
    • For LDAP Server Host, enter the hostname or IP address of the LDAP server.
    • For LDAP Server Port, enter the LDAP server port number. If you do not specify a port number, Ops Manager uses 389.
    • For LDAP User Search Base, enter the location in the LDAP directory tree from which any LDAP User search begins. The typical LDAP Search Base matches your domain name.
      For example, a domain named cloud.example.com typically uses the following LDAP User Search Base: ou=Users,dc=example,dc=com.
    • For LDAP Server CA Cert, you can optionally enter a certificate if your LDAP server supports TLS and you want to enable TLS connections from the NFS driver to your LDAP server. Paste in the root certificate from your CA certificate or your self-signed certificate.

      Note: UAA can only parse one certificate entered into this field. If you enter multiple certificates, UAA only uses the first one you entered and ignores the rest. You only need to include one root certificate or self-signed certificate.

  11. Select the Format of timestamps in Diego logs, either RFC3339 timestamps or Seconds since the Unix epoch. Fresh PAS v2.2 installations default to RFC3339 timestamps, while upgrades to PAS v2.2 from previous versions default to Seconds since the Unix epoch.

  12. You can optionally modify the Default health check timeout. The value configured for this field is the amount of time allowed to elapse between starting up an app and the first healthy response from the app. If the health check does not receive a healthy response within the configured timeout, then the app is declared unhealthy. The default timeout is 60 seconds and the maximum configurable timeout is 600 seconds.

  13. Click Save.

Step 6: Configure Application Developer Controls

  1. Select Application Developer Controls.

    App dev controls

  2. Enter the Maximum File Upload Size (MB). This is the maximum size of an application upload.

  3. Enter the Default App Memory (MB). This is the amount of RAM allocated by default to a newly pushed application if no value is specified with the cf CLI.

  4. Enter the Default App Memory Quota per Org. This is the default memory limit for all applications in an org. The specified limit only applies to the first installation of PAS. After the initial installation, operators can use the cf CLI to change the default value.

  5. Enter the Maximum Disk Quota per App (MB). This is the maximum amount of disk allowed per application.

    Note: If you allow developers to push large applications, PAS may have trouble placing them on Cells. Additionally, in the event of a system upgrade or an outage that causes a rolling deploy, larger applications may not successfully re-deploy if there is insufficient disk capacity. Monitor your deployment to ensure your Cells have sufficient disk to run your applications.

  6. Enter the Default Disk Quota per App (MB). This is the amount of disk allocated by default to a newly pushed application if no value is specified with the cf CLI.

  7. Enter the Default Service Instances Quota per Org. The specified limit only applies to the first installation of PAS. After the initial installation, operators can use the cf CLI to change the default value .

  8. Enter the Staging Timeout (Seconds). When you stage an application droplet with the Cloud Controller, the server times out after the number of seconds you specify in this field.

  9. For Internal Domain, enter a domain that apps use for internal DNS service discovery. If you specify this domain using cf push -d, other PAS apps can reach the pushed app at APP-NAME.INTERNAL-DOMAIN. This value defaults to apps.internal.

  10. Select the Allow Space Developers to manage network policies checkbox to permit developers to manage their own network policies for their applications.

  11. Click Save.

Step 7: Review Application Security Groups

Setting appropriate Application Security Groups is critical for a secure deployment. Type X in the box to acknowledge that once the Pivotal Application Service (PAS) deployment completes, you will review and set the appropriate application security groups. See Restricting App Access to Internal PCF Components for instructions.

Asg

Step 8: Configure Authentication and Enterprise SSO

  1. Select Authentication and Enterprise SSO.

    Er config auth enterprise sso uaa

  2. To authenticate user sign-ons, your deployment can use one of three types of user database: the UAA server’s internal user store, an external SAML identity provider, or an external LDAP server.

    • To use the internal UAA, select the Internal option and follow the instructions in the Configuring UAA Password Policy topic to configure your password policy.
    • To connect to an external identity provider through SAML, scroll down to select the SAML Identity Provider option and follow the instructions in the Configuring PCF for SAML section of the Configuring Authentication and Enterprise SSO for Pivotal Application Service (PAS) topic.
    • To connect to an external LDAP server, scroll down to select the LDAP Server option and follow the instructions in the Configuring LDAP section of the Configuring Authentication and Enterprise SSO for PAS topic.
  3. Click Save.

Step 9: Configure UAA

  1. Select UAA.

  2. Under Choose the location of your UAA database select one of the following:

    • PAS database (configured on the Databases pane): Use the same database server that other PAS components use. This system database is configured in the Databases pane, and it can be either internal or external.
    • Other external database - Use a separate, dedicated database server for UAA.

    Warning: Protect whichever database you use in your deployment with a password.

  3. (Optional) If you selected Other external database, complete the fields as follows:
    Ert uaa external

    • For Hostname, enter the hostname of the database server.
    • For TCP Port, enter the port of the database server.
    • For Username, specify a unique username that can access this specific database on the database server.
    • For Password, specify a password for the provided username.
    • For CA Certificate, enter a certificate to use for encrypting traffic to and from the database.

      Note: The CA Certificate field only works if your external database hostname matches a name specified in the certificate. This is not true with GCP CloudSQL.

  4. (Optional) Under JWT Issuer URI, enter the URI that UAA uses as the issuer when generating tokens.

    Ert uaa jwt uri

  5. Under SAML Service Provider Credentials, enter a certificate and private key to be used by UAA as a SAML Service Provider for signing outgoing SAML authentication requests. You can provide an existing certificate and private key from your trusted Certificate Authority or generate a certificate. The following domain must be associated with the certificate: *.login.YOUR-SYSTEM-DOMAIN.

    Note: The Pivotal Single Sign-On Service and Pivotal Spring Cloud Services tiles require the *.login.YOUR-SYSTEM-DOMAIN.

  6. If the private key specified under Service Provider Credentials is password-protected, enter the password under SAML Service Provider Key Password. Service provider

  7. (Optional) To override the default value, enter a custom SAML Entity ID in the SAML Entity ID Override field. By default, the SAML Entity ID is http://login.YOUR-SYSTEM-DOMAIN where YOUR-SYSTEM-DOMAIN is set in the Domains > System Domain field.

  8. For Signature Algorithm, choose an algorithm from the dropdown to use for signed requests and assertions. The default value is SHA256.

  9. (Optional) In the Apps Manager Access Token Lifetime, Apps Manager Refresh Token Lifetime, Cloud Foundry CLI Access Token Lifetime, and Cloud Foundry CLI Refresh Token Lifetime fields, change the lifetimes of tokens granted for Apps Manager and Cloud Foundry Command Line Interface (cf CLI) login access and refresh. Most deployments use the defaults.

    Authsso uaa bottom

  10. (Optional) In the Global Login Session Max Timeout and Global Login Session Idle Timeout fields, change the maximum number of seconds before a global login times out. These fields apply to the following:

    • Default zone sessions: Sessions in Apps Manager, PCF Metrics, and other web UIs that use the UAA default zones
    • Identity zone sessions: Sessions in apps that use a UAA identity zone, such as a Single Sign-On service plan
  11. (Optional) Customize the text prompts used for username and password from the cf CLI and Apps Manager login popup by entering values for Customize Username Label (on login page) and Customize Password Label (on login page).

  12. (Optional) The Proxy IPs Regular Expression field contains a pipe-delimited set of regular expressions that UAA considers to be reverse proxy IP addresses. UAA respects the x-forwarded-for and x-forwarded-proto headers coming from IP addresses that match these regular expressions. To configure UAA to respond properly to Gorouter or HAProxy requests coming from a public IP address, append a regular expression or regular expressions to match the public IP address.

  13. Click Save.

Step 10: Configure CredHub

Note: Enabling CredHub is not required. However, you cannot leave the fields under Encryption Keys blank. If you do not intend to use CredHub, enter any text in the Name and Key fields as placeholder values.

  1. Select CredHub.
  2. Choose the location of your CredHub database. PAS includes this CredHub database for services to store their service instance credentials.

    Credhub db
    If you chose PAS database (configured on the Databases pane), CredHub uses the same database as other PAS components, whether the database is internal or external.

    If you chose Other external database, enter the following:

    • Hostname. This is the IP address of your database server.
    • TCP Port. This is the port of your database server, such as 3306.
    • Username. This is a unique username that can access your CredHub database on the database server.
    • Password. This is the password for the provided username.
    • Database CA Certificate. This certificate is used when encrypting traffic to and from the database.
  3. Under Encryption Keys, specify one or more keys to use for encrypting and decrypting the values stored in the CredHub database. Encryption keys

    • Name. This is the name of the encryption key.
      • If you plan to use internal encryption, enter any key name.
      • If you plan to use an HSM as your encryption provider, enter a key name that already exists on your HSM or a new key name. For each new key name, CredHub generates a key in HSM Provider Partition that you configure below.
    • Provider. This is the provider of the encryption key. If you plan to configure an HSM provider and HSM servers below, select HSM. Otherwise, select Internal.
    • Key. If you select internal encryption, this key is used for encrypting all data. The key must be at least 20 characters long.
      • If you selected Internal above, enter a randomly generated value under Key.
      • If you selected HSM above, enter a placeholder value under Key. CredHub does not use this key for encryption. However, you cannot leave the Key field blank.
    • Primary. This checkbox is used for marking the key you specified above as the primary encryption key. You must mark one key as Primary. Do not mark more than one key as Primary.

      Note: For information about using additional keys for key rotation, see the Rotating Runtime CredHub Encryption Keys topic.

  4. (Optional) To configure CredHub to use an HSM, complete the following fields:

    • HSM Provider Partition. This is the name of the HSM provider partition.
    • HSM Provider Partition Password. This password is used to access the HSM provider partition.
    • HSM Provider Client Certificate. This is the client certificate for the HSM. For more information, see Create and Register HSM Clients in the Preparing CredHub HSMs for Configuration topic. Hsm provider
    • In the HSM Provider Servers section, click Add to add an HSM server. You can add multiple HSM servers. For each HSM server, complete the following fields:
      • Host Address. This is the host name or IP address of the HSM server.
      • Port. This is the port of the HSM server. If you do not know your port address, enter 1792.
      • Partition Serial Number. This is the serial number of the HSM partition.
      • HSM Certificate. This is the certificate for the HSM server. The HSM presents this certificate to CredHub to establish a two-way TLS connection.
  5. If your deployment uses any PCF services that support storing service instance credentials in CredHub and you want to enable this feature, select the Secure Service Instance Credentials checkbox.

  6. Click Save.

  7. Select the Resource Config pane.

  8. Under the Job column of the CredHub row, ensure that the number of instances is set to 2. This is the minimum instance count required for high availability.

  9. Click Save.

For more information about using CredHub for securing service instance credentials, see Securing Service Instance Credentials with Runtime CredHub.

Step 11: Configure System Databases

You can configure PAS to use an internal MySQL database provided with PCF, or you can configure an external database provider for the databases required by PAS.

Note: If you are performing an upgrade, do not modify your existing internal database configuration or you may lose data. You must migrate your existing data first before changing the configuration. See Upgrading Pivotal Cloud Foundry for additional upgrade information.

Internal Database Configuration

If you want to use internal databases for your deployment, do the following:

  1. Select Databases.

  2. Select Internal Databases - MySQL - Percona XtraDB Cluster.

  3. Click Save.

Then proceed to Step 12: (Optional) Configure Internal MySQL to configure high availability for your internal MySQL databases.

Create External System Databases

WARNING: Protect whichever database you use in your deployment with a password.

To create your Pivotal Application Service (PAS) databases, do the following:

Note: Exact configurations depend on your database provider. The following procedure uses AWS RDS as an example.

  1. Add the ubuntu account key pair from your IaaS deployment to your local SSH profile so you can access the Ops Manager VM. For example, in AWS, you add a key pair created in AWS:

    $ ssh-add aws-keypair.pem
  2. SSH in to your Ops Manager using the Ops Manager FQDN and the username ubuntu:

    $ ssh ubuntu@OPS-MANAGER-FQDN
  3. Log in to your MySQL database instance using the appropriate hostname and user login values configured in your IaaS account. For example, to log in to your AWS RDS instance, run the following MySQL command:

    $ mysql --host=RDSHOSTNAME --user=RDSUSERNAME --password=RDSPASSWORD

  4. Run the following MySQL commands to create databases for the eleven PAS components that require a relational database:

    CREATE database ccdb;
    CREATE database notifications;
    CREATE database autoscale;
    CREATE database app_usage_service;
    CREATE database routing;
    CREATE database diego;
    CREATE database account;
    CREATE database nfsvolume;
    CREATE database networkpolicyserver;
    CREATE database silk;
    CREATE database locket;
    CREATE database uaa;
    CREATE database credhub;
    

  5. Type exit to quit the MySQL client, and exit again to close your connection to the Ops Manager VM.

  6. In PAS, select Databases.

  7. Select the External Databases option.

    Note: If you configure external databases, you cannot configure an internal database in the UAA pane.

  8. For Hostname, enter the hostname of the database server.

  9. For TCP Port, enter the port of the database server.

  10. Each component that requires a relational database has two corresponding fields: one for the database username and one for the database password. For each set of fields, specify a unique username that can access this specific database on the database server and a password for the provided username.

    Note: Ensure that the networkpolicyserver database user has the ALL PRIVILEGES permission.

  11. (Optional) If you want to enable TLS for your external databases, paste your Certificate Authority (CA) certificate in the Database CA Certificate field.

  12. Click Save.

Step 12: (Optional) Configure Internal MySQL

Note: You only need to configure this section if you have selected one of the Internal Databases - MySQL options in the Databases section.

  1. Select Internal MySQL.

  2. In the Replication canary time period field, leave the default of 30 seconds or modify the value based on the needs of your deployment. Lower numbers cause the canary to run more frequently, which means that the canary reacts more quickly to replication failure but adds load to the database.

  3. In the Replication canary read delay field, leave the default of 20 seconds or modify the value based on the needs of your deployment. This field configures how long the canary waits, in seconds, before verifying that data is replicating across each MySQL node. Clusters under heavy load can experience a small replication lag as write-sets are committed across the nodes.

  4. (Required): In the E-mail address field, enter the email address where the MySQL service sends alerts when the cluster experiences a replication issue or when a node is not allowed to auto-rejoin the cluster.

  5. To prohibit the creation of command line history files on the MySQL nodes, disable the Allow Command History checkbox.

  6. To allow the admin and roadmin to connect from any remote host, enable the Allow Remote Admin Access checkbox. When the checkbox is disabled, admins must bosh ssh into each MySQL VM to connect as the MySQL super user.

    Note: Network configuration and Application Security Groups restrictions may still limit a client’s ability to establish a connection with the databases.

  7. For Cluster Probe Timeout, enter the maximum amount of time, in seconds, that a new node will search for existing cluster nodes. If left blank, the default value is 10 seconds.

    Mysql replication canary

  8. For Max Connections, enter the maximum number of connections allowed to the database. If left blank, the default value is 1500.

  9. If you want to log audit events for internal MySQL, select Enable server activity logging under Server Activity Logging.

    1. For the Event types field, you can enter the events you want the MySQL service to log. By default, this field includes connect and query, which tracks who connects to the system and what queries are processed.

      Server Activity Logging, Load Balancer Thresholds

  10. Enter values for the following fields:

    • Load Balancer Healthy Threshold: Specifies the amount of time, in seconds, to wait until declaring the MySQL Proxy instance started. This allows an external load balancer time to register the instance as healthy.
    • Load Balancer Unhealthy Threshold: Specifies the amount of time, in seconds, that the MySQL Proxy continues to accept connections before shutting down. During this period, the Healthcheck reports as unhealthy to cause load balancers to fail over to other proxies. You must enter a value greater than or equal to the maximum time it takes your load balancer to consider a proxy instance unhealthy, given repeated failed healthchecks.
  11. If you want to enable the MySQL interruptor feature, select the checkbox to Prevent node auto re-join. This feature stops all writes to the MySQL database if it notices an inconsistency in the dataset between the nodes. For more information, see the Interruptor section in the MySQL for PCF documentation.

  12. Click Save.

For more information on how to monitor the node health of your MySQL Proxy instances, see Using the MySQL Proxy.

Step 13: Configure File Storage

  1. In the PAS tile, select File Storage.
  2. For Max Valid Packages per App, Pivotal recommends leaving the default value of 5. However, you may want to lower the value if you have strict storage requirements and want to use less disk space.
  3. For Max Staged Droplets per App, Pivotal recommends leaving the default value of 5. However, you may want to lower the value if you have strict storage requirements and want to use less disk space.
  4. For Configure your Cloud Controller’s filesystem, see Select File Storage Location.

Select File Storage Location

Note: If you followed the instructions in Installing PCF on AWS Manually, you created the necessary resources for external S3-compatible file storage.

To minimize system downtime, Pivotal recommends using highly resilient and redundant external filestores for your Pivotal Application Service (PAS) file storage.

When configuring file storage for the Cloud Controller in PAS, you can select one of the following:

  • Internal WebDAV filestore
  • External S3-compatible or Ceph-compatible filestore
  • External Google Cloud Storage with Access Key and Secret Key
  • External Google Cloud Storage with Service Account
  • External Azure Cloud Storage

For production-level PCF deployments on AWS, Pivotal recommends selecting the External S3-Compatible File Store. For more information about production-level PCF deployments on AWS, see the Reference Architecture for Pivotal Cloud Foundry on AWS.

For more factors to consider when selecting file storage, see the Considerations for Selecting File Storage in Pivotal Cloud Foundry topic.

Internal Filestore

Internal file storage is only appropriate for small, non-production deployments.

To use the PCF internal filestore, select Internal WebDAV, and click Save.

External S3 or Ceph Filestore

To use an external S3-compatible filestore for PAS file storage, perform the following steps:

  1. Select the External S3-Compatible Filestore option and complete the following fields:

    • Enter the https:// URL Endpoint for your region.
      For example, in the us-west-2 region, enter https://s3-us-west-2.amazonaws.com/.
    • If you use an AWS instance profile to manage role information for your filestore, select the S3 AWS with Instance Profile checkbox. For more information, see AWS Identity and Access Management in the AWS documentation. External s3 filestore instance profile
    • Alternatively, enter the Access Key and Secret Key of the pcf-user you created when configuring AWS for PCF. If you select the S3 AWS with Instance Profile checkbox and also enter an Access Key and Secret Key, the instance profile will overrule the Access Key and Secret Key.
    • From the S3 Signature Version dropdown, select V4 Signature. For more information about S4 signatures, see Signing AWS API Requests in the AWS documentation.
    • For Region, enter the region in which your S3 buckets are located. us-west-2 is an example of an acceptable value for this field.
    • Select Server-side Encryption to encrypt the contents of your S3 filestore. This option is only available for AWS S3.
    • (Optional) If you selected Server-side Encryption, you can also specify a KMS Key ID. PAS uses the KMS key to encrypt files uploaded to the blobstore. If you do not provide a KMS Key ID, PAS uses the default AWS key. For more information, see Protecting Data Using Server-Side Encryption with AWS KMS–Managed Keys (SSE-KMS).
    • Enter names for your S3 buckets:

      Ops Manager Field Value Description
      Buildpacks Bucket Name pcf-buildpacks-bucket
      This S3 bucket stores app buildpacks.
      Droplets Bucket Name pcf-droplets-bucket This S3 bucket stores app droplets. Pivotal recommends that you use a unique bucket name for droplets, but you can also use the same name as above.
      Packages Bucket Name pcf-packages-bucket This S3 bucket stores app packages. Pivotal recommends that you use a unique bucket name for packages, but you can also use the same name as above.
      Resources Bucket Name pcf-resources-bucket This S3 bucket stores app resources. Pivotal recommends that you use a unique bucket name for app resources, but you can also use the same name as above.
    • Configure the following depending on whether your S3 buckets have versioning enabled:

      • Versioned S3 buckets: Enable the Use versioning for backup and restore checkbox to archive each bucket to a version.
      • Unversioned S3 buckets: Disable the Use versioning for backup and restore checkbox, and enter a backup bucket name for each active bucket. The backup bucket name must be different from the name of the active bucket it backs up. Backup buckets For more information about setting up external S3 blobstores, see the Backup and Restore with External Blobstores topic in the Cloud Foundry documentation.
  2. Click Save.

Note: For more information regarding AWS S3 Signatures, see the Authenticating Requests topic in the AWS documentation.

Other IaaS Storage Options

Google Cloud Storage and Azure Storage are also available as file storage options, but are not recommended for typical PCF on AWS installations.

Step 14: (Optional) Configure System Logging

You can configure system logging in PAS to forward log messages from PAS component VMs to an external service. Pivotal recommends forwarding logs to an external service for use in troubleshooting.

Note: The following instructions explain how to configure system logging for PAS component VMs. To forward logs from PCF tiles to an external service, you must also configure system logging in each tile. See the documentation for the given tiles for information about configuring system logging.

To configure system logging in PAS, do the following:

  1. In the PAS Settings tab, select the System Logging pane. The following image shows the System Logging pane. There is a heading at the top of the System Logging page that begins with the text, Optionally configure rsyslog. There are several fields on the System Logging page. The first three fields are Address, Port, and Transport Protocol. There is a Save button at the bottom of the page.

  2. For Address, enter the IP address of the syslog server.

  3. For Port, enter the port of the syslog server. The default port for a syslog server is 514.

    Note: The host must be reachable from the PAS network and accept UDP or TCP connections. Ensure the syslog server listens on external interfaces.

  4. For Transport Protocol, select a transport protocol for log forwarding.

  5. For Encrypt syslog using TLS?, select Yes to use TLS encryption when forwarding logs to a remote server.

    1. For Permitted Peer, enter either the name or SHA1 fingerprint of the remote peer.
    2. For TLS CA Certificate, enter the TLS CA certificate for the remote server.
  6. For Syslog Drain Buffer Size, enter the number of messages from the Loggregator Agent that the Doppler server can store before it begins to drop messages. See the Loggregator Guide for Cloud Foundry Operators topic for more details.

  7. Disable the Include container metrics in Syslog Drains checkbox to prevent the CF Drain CLI plugin from including app container metrics in syslog drains. This feature is enabled by default.

  8. Enable the Enable Cloud Controller security event logging checkbox to include security events in the log stream. This feature logs all API requests, including the endpoint, user, source IP address, and request result, in the Common Event Format (CEF).

  9. Enable the Use TCP for file forwarding local transport checkbox to transmit logs over TCP. This prevents log truncation, but may cause performance issues.

  10. Disable the Don’t Forward Debug Logs checkbox to forward DEBUG syslog messages to an external service. This checkbox is enabled by default.

    Note: Some PAS components generate a high volume of DEBUG syslog messages. Enabling the Don’t Forward Debug Logs checkbox prevents PAS components from forwarding the DEBUG syslog messages to external services. However, PAS still writes the messages to the local disk.

  11. For Custom rsyslog Configuration, enter a custom syslog rule. For more information about adding custom syslog rules, see Customizing Syslog Rules.

  12. Click Save.

To configure Ops Manager for system logging, see the Settings section in the Using the Ops Manager Interface topic.

Step 15: (Optional) Customize Apps

This section describes how to configure Custom Branding and Apps Manager to customize the appearance and functionality of Apps Manager. For more information about the Custom Branding configuration settings, see Custom Branding Apps Manager.

  1. Select Custom Branding. Use this section to configure the text, colors, and images of the interface that developers see when they log in, create an account, reset their password, or use Apps Manager. Custombranding

  2. Click Save to save your settings in this section.

  3. Select Apps Manager. Config apps man

  4. Select Enable Invitations to enable invitations in Apps Manager. Space Managers can invite new users for a given space, Org Managers can invite new users for a given org, and Admins can invite new users across all orgs and spaces. See the Inviting New Users section of the Managing User Roles with Apps Manager topic for more information.

  5. Select Display Marketplace Service Plan Prices to display the prices for your services plans in the Marketplace.

  6. Enter the Supported currencies as JSON to appear in the Marketplace. Use the format { "CURRENCY-CODE": "SYMBOL" }. This defaults to { "usd": "$", "eur": "€" }.

  7. Use Product Name, Marketplace Name, and Customize Sidebar Links to configure page names and sidebar links in the Apps Manager and Marketplace pages.

  8. The Apps Manager Memory Usage (MB) field sets the memory limit with which to deploy the Apps Manager app. Use this field to increase the memory limit if the app fails to start with an out of memory error.

  9. The Invitations Memory Usage (MB) field sets the memory limit with which to deploy the Invitations app. Use this field to increase the memory limit if the app fails to start with an out of memory error.

  10. The Apps Manager Polling Interval field provides a temporary fix if Apps Manager usage degrades Cloud Controller response times. In this case, you can use this field to reduce the load on the Cloud Controller and ensure Apps Manager remains available while you troubleshoot the Cloud Controller. Pivotal recommends that you do not keep this field modified as a long term fix because it can degrade Apps Manager performance. You can optionally do the following:

    • Increase the polling interval above the default of 30 seconds.

      Note: If you enter a value between 0 and 30, the field is automatically set to 30.

    • Disable polling by entering 0. This stops Apps Manager from refreshing data automatically, but users can update displayed data by reloading Apps Manager manually.
  11. The App Details Polling Interval field provides an additional way to reduce the load on the Cloud Controller when the Apps Manager Polling Interval field is not sufficient. This field controls the rate at which Apps Manager polls for data when a user views the Overview page of an app. Pivotal recommends that you do not keep this field modified as a long term fix because it can degrade Apps Manager performance. You can optionally do the following:

    • Increase the polling interval above the default of 10 seconds.

      Note: If you enter a value between 0 and 30, the field is automatically set to 10.

    • Disable polling by entering 0. This stops Apps Manager from refreshing data automatically, but users can update displayed data by reloading Apps Manager manually.
  12. Click Save to save your settings in this section.

Step 16: (Optional) Configure Email Notifications

PAS uses SMTP to send invitations and confirmations to Apps Manager users. You must complete the Email Notifications page if you want to enable end-user self-registration.

  1. Select Email Notifications.

    Smtp

  2. Enter your reply-to and SMTP email information.

    Note: For GCP, you must use port 2525. Ports 25 and 587 are not allowed on GCP Compute Engine.

  3. Verify your authentication requirements with your email administrator and use the SMTP Authentication Mechanism dropdown to select None, Plain, or CRAMMD5. If you have no SMTP authentication requirements, select None.

  4. If you selected CRAMMD5 as your authentication mechanism, enter a secret in the SMTP CRAMMD5 secret field.

  5. Click Save.

Note: If you do not configure the SMTP settings using this form, the administrator must create orgs and users using the cf CLI. See Creating and Managing Users with the cf CLI for more information.

Step 17: (Optional) Configure App Autoscaler

To use App Autoscaler, you must create an instance of the service and bind it to an app. To create an instance of App Autoscaler and bind it to an app, see Set Up App Autoscaler in the Scaling an Application Using App Autoscaler topic.

  1. Click App Autoscaler.

    App autoscaler

  2. Review the following settings:

    • Autoscaler Instance Count: How many instances of the App Autoscaler service you want to deploy. The default value is 3. For high availability, set this number to 3 or higher. You should set the instance count to an odd number to avoid split-brain scenarios during leadership elections. Larger environments may require more instances than the default number.
    • Autoscaler API Instance Count: How many instances of the App Autoscaler API you want to deploy. The default value is 1. Larger environments may require more instances than the default number.
    • Metric Collection Interval: How many seconds of data collection you want App Autoscaler to evaluate when making scaling decisions. The minimum interval is 60 seconds, and the maximum interval is 3600 seconds. The default value is 120. Increase this number if the metrics you use in your scaling rules are emitted less frequently than the existing Metric Collection Interval.
    • Scaling Interval: How frequently App Autoscaler evaluates an app for scaling. The minimum interval is 15 seconds, and the maximum interval is 120 seconds. The default value is 35.
    • Verbose Logging (checkbox): Enables verbose logging for App Autoscaler. Verbose logging is disabled by default. Select this checkbox to see more detailed logs. Verbose logs show specific reasons why App Autoscaler scaled the app, including information about minimum and maximum instance limits, App Autoscaler’s status. For more information about App Autoscaler logs, see App Autoscaler Events and Notifications.
    • Disable API Connection Pooling: If you select this option, the Autoscaler API does not reuse HTTP connections. This may be necessary if your Frontend Idle Timeout for Gorouter is set to a low value, such as 1 second.
  3. Click Save.

Step 18: Configure Cloud Controller

  1. Click Cloud Controller.

    Config cc

  2. Enter your Cloud Controller DB Encryption Key if all of the following are true:

    • You deployed Pivotal Application Service (PAS) previously.
    • You then stopped PAS or it crashed.
    • You are re-deploying PAS with a backup of your Cloud Controller database.

      See Backing Up Pivotal Cloud Foundry for more information.
  3. CF API Rate Limiting prevents API consumers from overwhelming the platform API servers. Limits are imposed on a per-user or per-client basis and reset on an hourly interval.

    To disable CF API Rate Limiting, select Disable under Enable CF API Rate Limiting. To enable CF API Rate Limiting, perform the following steps:

    1. Under Enable CF API Rate Limiting, select Enable.
    2. For General Limit, enter the number of requests a user or client is allowed to make over an hour interval for all endpoints that do not have a custom limit. The default value is 2000.
    3. For Unauthenticated Limit, enter the number of requests an unauthenticated client is allowed to make over an hour interval. The default value is 100.
  4. (Optional) Enter in seconds your Database Connection Validation Timeout. By default, the setting is 3600 seconds or 60 minutes. You can enter -1 to cause Cloud Controller to make an additional query to the database whenever connections are checked out from the pool. Choosing -1 has performance implications.

  5. (Optional) Enter in seconds your Database Read Timeout. By default, the setting is 3600 seconds or 60 minutes.

  6. (Optional) Select your default Linux stack. Apps pushed to Linux cells run on this stack unless you specify otherwise with the cf push -s STACKNAME option. Existing apps continue to use their current stack when you change the default stack. For more information, see Restaging Applications on a New Stack. For a brief description of each option, see the following:

    • Platform default (currently cflinuxfs3): Use the default stack for the current PCF version and migrate on upgrade if there is a new default stack.
    • cflinuxfs3: Use cflinuxfs3 and do not change on upgrade.
    • cflinuxfs2: Use cflinuxfs2 and do not change on upgrade.
  7. Click Save.

Step 19: Configure Smoke Tests

The Smoke Tests errand runs basic functionality tests against your Pivotal Application Service (PAS) deployment after an installation or update. In this section, choose where to run smoke tests. In the Errands section, you can choose whether or not to run the Smoke Tests errand.

  1. Select Smoke Tests.

  2. If you have a shared apps domain, select Temporary space within the system organization, which creates a temporary space within the system organization for running smoke tests and deletes the space afterwards. Otherwise, select Specified org and space and complete the fields to specify where you want to run smoke tests.

    Smoke test er config

  3. Click Save.

Step 20: (Optional) Enable Advanced Features

The Advanced Features section of Pivotal Application Service (PAS) includes new functionality that may have certain constraints. Although these features are fully supported, Pivotal recommends caution when using them in production environments.

Diego Cell Memory and Disk Overcommit

If your apps do not use the full allocation of disk space and memory set in the Resource Config tab, you might want use this feature. These fields control the amount to overcommit disk and memory resources to each Diego Cell VM.

For example, you might want to use the overcommit if your apps use a small amount of disk and memory capacity compared to the amounts set in the Resource Config settings for Diego Cell.

Note: Due to the risk of app failure and the deployment-specific nature of disk and memory use, Pivotal has no recommendation about how much, if any, memory or disk space to overcommit.

To enable overcommit, do the following:

  1. Select Advanced Features.

    Disk memory overcommit

  2. Enter the total desired amount of Diego cell memory value in the Cell Memory Capacity (MB) field. Refer to the Diego Cell row in the Resource Config tab for the current Cell memory capacity settings that this field overrides.

  3. Enter the total desired amount of Diego cell disk capacity value in the Cell Disk Capacity (MB) field. Refer to the Diego Cell row in the Resource Config tab for the current Cell disk capacity settings that this field overrides.

  4. Click Save.

Note: Entries made to each of these two fields set the total amount of resources allocated, not the overage.

Whitelist for Non-RFC-1918 Private Networks

Some private networks require extra configuration so that internal file storage (WebDAV) can communicate with other PCF processes.

The Whitelist for non-RFC-1918 Private Networks field is provided for deployments that use a non-RFC 1918 private network. This is typically a private network other than 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16.

Most PCF deployments do not require any modifications to this field.

To add your private network to the whitelist, do the following:

  1. Select Advanced Features.

  2. Append a new allow rule to the existing contents of the Whitelist for non-RFC-1918 Private Networks field. Nonrfc whitelist Include the word allow, the network CIDR range to allow, and a semi-colon (;) at the end. For example: allow 172.99.0.0/24;

  3. Click Save.

CF CLI Connection Timeout

The CF CLI Connection Timeout field allows you to override the default five second timeout of the Cloud Foundry Command Line Interface (cf CLI) used within your PCF deployment. This timeout affects the cf CLI command used to push PAS errand apps such as Notifications, Autoscaler, and Apps Manager.

Set the value of this field to a higher value, in seconds, if you are experiencing domain name resolution timeouts when pushing errands in PAS.

To modify the value of the CF CLI Connection Timeout, perform the following steps:

  1. Select Advanced Features.

  2. Add a value, in seconds, to the CF CLI Connection Timeout field. Cf cli connection timeout

  3. Click Save.

Metrics Deployment Name

For the value of deployment, metrics use cf-GUID, which corresponds to the BOSH deployment name of your PAS tile. In PAS v2.3 and earlier, this value was cf only and not uniquely identified by tile.

If you have scripts that rely on the cf value, you can re-enable the value. Pivotal does not recommend re-enabling the cf value as a permanent solution. If you can resolve script dependencies, resolve them and leave the default setting.

To re-enable the cf value, do the following:

  1. Select Use “cf” as deployment name in emitted metrics instead of unique name.

  2. Click Save.

  3. If you have PCF Healthwatch installed, enable the PCF Healthwatch Push Monitoring Components Errand to ensure correct PCF Healthwatch configuration.

SMB Volume Services

You can optionally enable SMB volume services so developers can bind existing SMB shares to their apps. For more information, see the Enabling Volume Services topic.

To enable SMB volume services, do the following:

  1. Select Enable SMB volume services.

  2. Click Save.

  3. In the Errands pane, set the SMB Broker Errand to On.

  4. Click Save.

Enable TLS for Internal System Database

To enable TLS for clients of the internal system database, do the following:

  1. Select BETA: Enable TLS for internal system database.

  2. Click Save.

Database Connection Limits

You can configure the maximum number of concurrent database connections that diego and container networking components can have. Use the field beginning with Maximum number of open connections… for a given component. The placeholder values for each field are the default values.

When there are not enough connections available, such as during a time of heavy load, components may experience degraded performance and sometimes failure. To resolve or prevent this, you can increase and fine-tune database connection limits for the component.

WARNING: Decreasing the value of this field for a component may affect the amount of time it takes for it to respond to requests.

Rolling App Deployments

You can optionally disable rolling app deployments. For more information, see the Rolling App Deployments (Beta) topic.

To disable rolling app deployments, do the following:

  1. Select Disable Zero Downtime App Deployments.

  2. Click Save.

Step 20: (Optional) Metric Registrar

The PAS tile includes a Metric Registrar configuration pane. You can configure the Metric Registrar from this pane in the following ways:

  • Enable
  • Edit default scraping interval
  • Add blacklisted tags

Enable the Metric Registrar

The PAS tile does not deploy the Metric Registrar by default.

To enable the Metric Registrar, do the following:

  1. In the PAS tile, click Metric Registrar.

  2. Select the Enable Metric Registrar checkbox.

Edit Default Scraping Interval

The scraping interval defines how often the Metric Registrar polls custom metric endpoints. The default is 35 seconds.

To edit the Metric Registrar scraping interval, do the following:

  1. In the PAS tile, click Metric Registrar.

  2. Edit the Endpoint Scraping Interval field.

Add Blacklisted Tags

To prevent the Metric Registrar from consuming the value of a metric or event tag, you can add the tag to the Blacklisted Tags field. For example, if you tag your metrics with a customer_id, you may want to add customer_id to the list of blacklisted tags. The field accepts a comma-separated list.

By default, the following tags are blacklisted to prevent interference with other products like PCF Metrics that use and rely on such tags.

  • deployment
  • job
  • index
  • id

To prevent the Metric Registrar from consuming the value of a metric or event tag, do the following:

  1. In the PAS tile, click Metric Registrar.

  2. Add the desired tag to the Blacklisted Tags field.

Step 21: Configure Errands

Errands are scripts that Ops Manager runs automatically when it installs or uninstalls a product, such as a new version of Pivotal Application Service (PAS). There are two types of errands: post-deploy errands run after the product is installed, and pre-delete errands run before the product in uninstalled.

By default, Ops Manager always runs all errands.

The PAS tile Errands pane lets you change these run rules. For each errand, you can select On to run it always or Off to never run it.

For more information about how Ops Manager manages errands, see the Managing Errands in Ops Manager topic.

Note: Several errands, such as App Autoscaler and Notifications, deploy apps that provide services for your deployment. When one of these apps is running, selecting Off for the corresponding errand on a subsequent installation does not stop the app.

  • Smoke Test Errand verifies that your deployment can do the following:

    • Push, scale, and delete apps
    • Create and delete orgs and spaces
  • Usage Service Errand deploys the Pivotal Usage Service application, which Apps Manager depends on.

  • Apps Manager Errand deploys Apps Manager, a dashboard for managing apps, services, orgs, users, and spaces. Until you deploy Apps Manager, you must perform these functions through the cf CLI. After Apps Manager has been deployed, Pivotal recommends setting this errand to Off for subsequent PAS deployments. For more information about Apps Manager, see the Getting Started with the Apps Manager topic.

  • Notifications Errand deploys an API for sending email notifications to your PCF platform users.

    Note: The Notifications app requires that you configure SMTP with a username and password, even if you set the value of SMTP Authentication Mechanism to none.

  • Notifications UI Errand deploys a dashboard for users to manage notification subscriptions.

  • App Autoscaler Errand pushes the App Autoscaler app, which enables you to configure your apps to automatically scale in response to changes in their usage load. See the Scaling an Application Using Autoscaler topic for more information.

  • NFS Broker Errand pushes the NFS Broker app, which supports NFS Volume Services for PAS. For more information, see Enabling NFS Volume Services.

  • Metric Registrar Smoke Test Errand verifies the Metric Registrar can access custom metrics emitted by an app and convert them into Loggregator metrics.

    Note: The Metric Registrar Smoke Test errand runs only if the Metric Registrar is enabled. For more information about enabling and configuring the Metric Registrar, see Configuring the Metric Registrar.

  • SMB Broker Application Errand pushes the SMB Broker app, which supports SMB Volume Services for PAS. For more information, see Enabling SMB Volume Services.

Step 22: (Optional) Disable Unused Resources

Note: The Resource Config pane has fewer VMs if you are installing the Small Footprint Runtime.

Note: The Small Footprint Runtime does not default to a highly available configuration. It defaults to the minimum configuration. If you want to make the Small Footprint Runtime highly available, scale the Compute, Router, and Database VMs to 3 instances and scale the Control VM to 2 instances.

Pivotal Application Service (PAS) defaults to a highly available resource configuration. However, you may need to perform additional procedures to make your deployment highly available. See the Zero Downtime Deployment and Scaling in CF and the Scaling Instances in PAS topics for more information.

If you do not want a highly available resource configuration, you must scale down your instances manually by navigating to the Resource Config section and using the dropdowns under Instances for each job.

By default, PAS also uses an internal filestore and internal databases. If you configure PAS to use external resources, you can disable the corresponding system-provided resources in Ops Manager to reduce costs and administrative overhead.

To disable specific VMs in Ops Manager, do the following:

  1. Click Resource Config.

  2. If you configured PAS to use an external S3-compatible filestore, enter 0 in Instances in the File Storage field.

  3. If you selected External when configuring the UAA, System, and CredHub databases, edit the following fields:

    • MySQL Proxy: Enter 0 in Instances.
    • MySQL Server: Enter 0 in Instances.
    • MySQL Monitor: Enter 0 in Instances.
  4. If you disabled TCP routing, enter 0 Instances in the TCP Router field.

  5. If you are not using HAProxy, enter 0 Instances in the HAProxy field.

  6. Click Save.

Step 23: Configure Router to Elastic Load Balancers

  1. Record the names of your ELBs. If you followed the procedures in the Installing PCF on AWS Manually topic, you created the following:

    • pcf-ssh-elb: A SSH load balancer. This is a Classic Load Balancer.
    • pcf-tcp-elb: A TCP load balancer. This is a Classic Load Balancer.
    • pcf-web-elb: A web load balancer. This is an Application Load Balancer.
    • pcf-web-elb-target-group: a target group for the web load balancer
  2. In the PAS tile, click Resource Config. Resource config

  3. Enter the name of your SSH load balancer depending on which release you are using.

    • PAS: In the Load Balancers field of the Diego Brain row, enter the name of your SSH load balancer: pcf-ssh-elb.
    • Small Footprint Runtime: In the Load Balancers field of the Control row, enter the name of your SSH load balancer: pcf-ssh-elb.
  4. In the Load Balancers field of the Router row, enter the value determined by the type of load balancer you are using:

    • Application Load Balancer: Enter the name of the target group of your web load balancer, prefixed with alb:: alb:pcf-web-elb-target-group. The prefix indicates to Ops Manager that you entered the name of a target group, and is required for AWS Application Load Balancers or Network Load Balancers.
    • Clasic Load Balancer: Enter the name of the load balancer: pcf-web-elb.

      Note: If you are using HAProxy in your deployment, then put the name of the load balancers in the Load Balancers field of the HAProxy row instead of the Router row. For a high availability configuration, scale up the HAProxy job to more than one instance.

  5. In the Load Balancers field of the TCP Router row, enter the name of your TCP load balancer if you enabled TCP routing: pcf-tcp-elb.

Step 24: Download Stemcell

This step is only required if your Ops Manager does not already have the stemcell version required by PAS. For more information about importing stemcells, see Importing and Managing Stemcells.

  1. Open the Stemcell product page in the Pivotal Network. Note, you may have to log in.

  2. Download the appropriate stemcell version targeted for your IaaS.

  3. Navigate to Stemcell Library in the Installation Dashboard.

  4. Click Import Stemcell to import the downloaded stemcell .tgz file.

  5. When prompted, enable the Ops Manager product checkbox to stage your stemcell.

  6. Click Apply Stemcell to Products.

Step 25: Complete the PAS Installation

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

  2. Click Review Pending Changes, then Apply Changes to begin your installation of PAS.

    The install process generally requires a minimum of 90 minutes to complete. The image shows the Changes Applied window that displays when the installation process successfully completes.

    Vpc step16

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