Installing Pivotal Platform Isolation Segment

This topic describes how to install the Pivotal Platform Isolation Segment tile, which allows operators to isolate deployment workloads into dedicated resource pools called isolation segments.

Installing the tile installs a single isolation segment. However, you can install multiple isolation segments using the Replicator tool documented in Step 4.

After installing the tile, you must follow the procedure in the Create an Isolation Segment section of the Managing Isolation Segments topic to create the isolation segment in the Cloud Controller database (CCDB). The topic also includes information about managing an isolation segment.

For more information about how isolation segments work, see the Isolation Segments section of the PAS Security topic.

Step 1: (Optional) Configure Routing

By default, the Pivotal Application Service (PAS) Gorouter handles traffic for your isolation segment. However, you can deploy a dedicated router for your isolation segment instead. For information about configuring and managing routing for isolation segments, see Routing for Isolation Segments.

To deploy a dedicated router:

  1. Add a load balancer in front of the PAS Gorouter. The steps to do this depend on your IaaS, but the setup of the load balancer should mirror the setup of the load balancer for the PAS Gorouter that you configured in the PAS tile.

  2. Create a wildcard DNS entry for traffic routed to any app in the isolation segment. For example, *.iso.example.com.

  3. Attach the wildcard DNS entry to the load balancer you created.

Step 2: Install the Tile

To install the Pivotal Platform Isolation Segment tile:

  1. Download the product file from Pivotal Network.

  2. Navigate to YOUR-OPS-MANAGER-FQDN in a browser to log in to the Ops Manager Installation Dashboard.

  3. Click Import a Product and select the downloaded product file.

  4. Under Pivotal Platform Isolation Segment in the left column, click the plus sign.

Step 3: Configure the Tile

Click the orange Pivotal Platform Isolation Segment tile to start the configuration process.

Assign AZs and Networks

In the Assign AZ and Networks pane, you assign jobs to your Availability Zones (AZs) and networks.

  1. Click Assign AZs and Networks.

  2. Select an availability zone for your singleton jobs, and one or more availability zones to balance other jobs in.

  3. Select a network. This network does not need to be the same network where you deployed PAS. For most deployments, operators should create unique networks in which to deploy the Isolation Segment tile. These networks should maintain network reach-ability with the Diego components so that the Diego Cells can reach the Diego Brain and Diego Database VMs.

  4. Click Save.

Networking

Perform the following steps to configure the Pivotal Platform Isolation Segment tile:

  1. Click Networking.

    Router ha ip

  2. (Optional): Under Router IPs, enter one or more static IP addresses for the routers that handle this isolation segment. These IP addresses must be within the subnet CIDR block that you defined in the Ops Manager network configuration for your Isolation Segment. If you have a load balancer, configure it to point to these IP addresses.

    Note: Entering the static IP addresses is not necessary for deployments running on a public IaaS such as AWS, GCP, or Azure because Pivotal Platform users specify the IaaS load balancer in the Resource Config section of the Pivotal Platform Isolation Segment tile.

  3. If you want to use HAProxy for this isolation segment, enter at least one address in the HAProxy IPs field. You should specify more than one IP address for high availability. Then configure your load balancer to forward requests for the domains you have set up for your deployment to these IP addresses. For more information, see Configuring SSL/TLS Termination at HAProxy.

    Note: If you rely on HAProxy for a feature in Pivotal Application Service (PAS) and you want isolated networking for this isolation segment, you may want to deploy the HAProxy provided by the Isolation Segment tile.

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

    Note: When providing custom certificates, enter them in the following order: wildcard, Intermediate, CA. For more information, see Creating a .pem File for SSL Certificate Installations in the DigiCert documentation.

    1. Click Add to add a name for the certificate chain and its private key pair. This certificate is the default used by Gorouter and HAProxy. You can either provide a certificate signed by a Certificate Authority (CA) or click on the Generate RSA Certificate link to generate a certificate generated by the Ops Manager CA. For the values to use, see Providing a Certificate for Your TLS Termination Point.

      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 the Gorouter, click Add 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 Providing a Certificate for Your TLS Termination Point.

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

  5. (Optional) When validating client requests using mutual TLS, the Gorouter trusts multiple certificate authorities (CAs) by default. To configure HAProxy to trust the same CAs as the Gorouter, 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.

  6. 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 the 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 the TLS Cipher Suite Support section of the Securing Traffic into Cloud Foundry topic.

  7. Configure Logging of client IPs in 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, select Disable logging of X-Forwarded-For header only.
    • If your load balancer exposes the source IP of the originating client, select Disable logging of both source IP and X-Forwarded-For header.

  8. Under TLS termination point, configure how Pivotal Platform handles x-forwarded-client-cert (XFCC) HTTP headers based on where TLS is terminated for the first time in your deployment.

    The following table indicates which option to choose based on your deployment configuration.

    Deployment Configuration TLS Option Additional Notes
    • The load balancer is terminating TLS, and
    • The load balancer is configured to put the client certificate from a mutual authentication TLS handshake into the X-Forwarded-Client-Cert HTTP header
    Infrastructure load balancer 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 through TCP to the instances of HAProxy, and
    • HAProxy instance count is > 0
    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 certificate validation field, you cannot select the Router does not request client certificates option.

    • The load balancer is configured to pass through the TLS handshake through TCP to instances of the Gorouter

    Router 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 certificate validation field, you cannot select the Router does not request client certificates option.


    For a description of the behavior of each configuration option, see the Forward Client Certificate to Apps section of the HTTP Routing topic.

  9. To configure HAProxy to handle client certificates, select one of the following options in the HAProxy behavior for client certificate validation field:

    • HAProxy does not request client certificates: This option requires mutual authentication, which makes it incompatible with TLS termination point option 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 and validates them when presented, but does not require them. This option is required if you want to enable mutual TLS app identity verification and TLS is terminated for the first time at HAProxy.

      Warning: Upon upgrade, PAS fails 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 or configure the HAProxy with the appropriate CA.

  10. To configure Gorouter behavior for handling client certificates, select one of the following options in the Router behavior for client certificate validation field:

    • Router does not request client certificates: Client certificates are not requested, so the client does not provide them and validation of client certificates does not occur. This option is incompatible with the TLS termination point options HAProxy and Router because these options require mutual authentication.
    • Router requests but does not require client certificates: The Gorouter requests client certificates in TLS handshakes and 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 fail upon upgrade if your load balancer is configured with client certificates and the Gorouter does not have the CA. To mitigate this issue, select Router does not request client certificates.

  11. In the TLS cipher suites for Router field, review the TLS cipher suites for TLS handshakes between the 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.

    To modify the default configuration, use an ordered, colon-separated 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 initiate TLS handshakes with the Gorouter. For a list of TLS ciphers supported by the Gorouter, see Securing Traffic into Cloud Foundry.

    Verify that every client participating in TLS handshakes with the Gorouter has at least one cipher suite in common with the Gorouter.

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

  12. In the TLS cipher suites for HAProxy field, review the TLS cipher suites for TLS handshakes between HAProxy and front end clients such as load balancers and the Gorouter. The default value for this field is:
    DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384

    To modify the default configuration, use an ordered, colon-separated 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 initiate TLS handshakes with 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.

  13. Under HAProxy forwards requests to Router over TLS, select Enable or Disable based on your deployment layout.

    • To enable communication between HAProxy and the Gorouter:
      1. Leave Enable selected.
      2. In the Certificate Authority for HAProxy back end field, provide the 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 the Gorouter and HAProxy have TLS cipher suites in common in the TLS cipher suites for Router and TLS cipher suites for HAProxy fields.

    For more information, see the Terminating TLS at the Load Balancer and Gorouter section of the Securing Traffic into Cloud Foundry topic, Providing a Certificate for Your TLS Termination Point, and Using the Ops Manager API.
    • To use non-encrypted communication between HAProxy and the Gorouter:
      1. Select Disable.
      2. If you are not using HAProxy, set the number of HAProxy job instances to 0 in the Resource Config pane. For more information, see Disable Unused Resources.
    For more information, see the Terminating TLS at the Gorouter Only and Terminating TLS at the Load Balancer Only sections of the Securing Traffic into Cloud Foundry topic.

  14. If you are not using SSL encryption or if you are using self-signed certificates, enable the Disable SSL certificate verification for this environment checkbox. Enabling 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, enable the Disable HTTP on HAProxy and Router checkbox. When selected, HAProxy and the Gorouter do not listen on port 80.

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

  17. (Optional) To disable the addition of Zipkin tracing headers on the Gorouter, disable 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 the HTTP Headers for Zipkin Tracing section of the HTTP Routing topic.

  18. (Optional) The Enable Router to write access logs locally checkbox is enabled by default. Pivotal recommends disabling this checkbox for high-traffic deployments, since logs may not be rotated fast enough and can fill up the disk.

  19. (Optional) By default, Gorouter support for the PROXY protocol is disabled. To enable the PROXY protocol, enable the Enable support for PROXY protocol in Router checkbox. 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 the Gorouter, see the About HTTP Header Forwarding sections in the Securing Traffic in Cloud Foundry topic.

  20. Bypass security checks for route service lookup has potential security concerns, but may be needed for backwards compatibility. See the Route Service Internal Lookup Considerations section of Route Services for details.

  21. (Optional) If you want to limit the number of app connections to the back end, enter a value in the Maximum connections per back end field. You can use this field to prevent a poorly behaving app from all the connections and impacting other apps. No value or a value of 0 sets no limit.
    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 Pivotal Platform Metrics, you can also obtain this peak concurrent connection information from the Network Metrics section of the Monitoring and Troubleshooting Apps with Pivotal Platform Metrics topic. The default value is 500.

  22. Under Keep-alive connections for Router, select Enable or Disable. Keep-alive connections are enabled by default. For more information, see the Keep-Alive Connections section in the HTTP Routing topic.

  23. (Optional) To accommodate larger uploads over connections with high latency, increase the number of seconds in the Router timeout to back ends field.

  24. (Optional) Increase the value of Load balancer unhealthy threshold to specify the amount of time, in seconds, that the Gorouter continues to accept connections before shutting down. During this period, healthchecks may report the Gorouter 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 Gorouter instance unhealthy, given repeated failed healthchecks.

  25. (Optional) Modify the value of Load balancer healthy threshold. This field specifies the amount of time, in seconds, to wait until declaring the Gorouter instance started. This allows an external load balancer time to register the Gorouter instance as healthy.

    Router lb thresholds

  26. (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 with a comma-separated list. For example, to support app developers that deploy Spring apps to Pivotal Platform, you can enter Spring-specific HTTP headers.

    Http Headers to Log

  27. If you expect requests larger than the default maximum of 16.384 KB, enter a new value in bytes for HAProxy request maximum buffer size. You may need to do this, for example, to support apps that embed a large cookie or query string values in headers. Requests larger than the maximum value result in a gateway error.

  28. If your Pivotal Platform deployment uses HAProxy and you want it to receive traffic only from specific sources, configure 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 HAProxy protected domains can send traffic to Pivotal Platform.

  29. 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

  30. The Enable Silk Policy Enforcement checkbox is enabled by default. To disable Silk network policy enforcement between apps, disable the checkbox. Disabling network policy enforcement allows all apps to send network traffic to all other apps in the foundation despite no policy specifically allowing it. Ist silk

  31. Select a sharding mode in the Router Sharding Mode field. The options are explained below. For more information, see Sharding Routers for Isolation Segments. Sharding options

    • Isolation Segment Only: The routers for the tile acknowledge requests only from apps deployed within the cells of the tile. All other requests fail.
    • No Isolation Segment: The routers for the tile reject requests for any isolation segment. Choose this option to add a group of routers for the PAS tile, such as when you want a private point of entry for the system domain.
  32. Click Save.

App Containers

In the App Containers pane, you enable microservice frameworks, private Docker registries, and other services that support your apps at the container level.

  1. Click App Containers.

  2. Choose the method the Gorouter uses to verify app identity under Router app identity verification. To enable the Gorouter to verify app identity using TLS, select Router uses TLS to verify app identity. To enable the Gorouter and your apps to verify each other’s identity using TLS, select Router and apps use mutual TLS to verify each other’s identity.

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

    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 the Preventing Misrouting section in the HTTP Routing topic.

    Note: To support mutual TLS app identity verification, you need v2.3 or later of both PAS and Pivotal Platform Isolation Segment (IST). The Gorouter and Diego Cell components in Pivotal Platform v2.2 and earlier do not support mTLS handshakes.

    Note: This feature does not work if the Disable SSL certificate verification for this environment checkbox is enabled in the Networking pane.

  3. (Optional) You can configure PAS to run app instances in Docker containers by provided a comma-separated list of their IP address ranges in the Private Docker insecure registry allow list field. For more information, see Using Docker Registries.

  4. Under Segment name, enter the name of your isolation segment. This name must be unique across your Pivotal Platform deployment. You use this name when performing the steps in the Create an Isolation Segment section of the Managing Isolation Segments topic to create the isolation segment in the Cloud Controller database (CCDB).

  5. Select your preference for Docker images disk cleanup scheduling on Diego Cell VMs. If you choose Clean up disk space once usage fills disk, enter a value in MB for Reserved disk space for other jobs. This is the amount of space the garbage collection algorithm should keep free for other jobs. For more information about the configuration options and how to configure a reserved amount, see Configuring Docker Images Disk Cleanup Scheduling.

  6. The Enable containerd delegation checkbox governs whether or not Garden delegates container create and destroy operations to the containerd tool. By default, this option is enabled and Garden uses containerd. Disable this option by disabling the checkbox. For more information about the containerd tool, see containerd.

  7. Under NFSv3 volume services, select Enable or Disable. NFS volume services allow app developers to bind existing NFS volumes to their apps for shared file access. For more information, see Enabling NFS Volume Services.

    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.

  8. (Optional) To configure LDAP for NFSv3 volume services:

    • 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 certificate, 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.

  9. Click Save.

System Logging

In the System Logging pane, 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. If you do not fill these fields, platform logs are not forwarded but remain available on the component VMs and for download through Ops Manager.

  1. Select System Logging.

  2. Select an option under Configure syslog for system components?. No is selected by default. This setting only affects Diego Cell, Gorouter, and HAProxy components within the isolation segment. This setting does not affect shared PAS system components.

  3. If you want to use syslog, select Yes.

  4. Enter the address of your external syslog aggregation service in the Address field. The address can be a hostname or IP address.

  5. Enter a port number in the Port field.

  6. Select a protocol from the Transport protocol menu. This is the protocol the system uses to transmit logs to syslog.

  7. (Optional) Select the Enable TLS checkbox if you want to transmit logs over TLS.

  8. Enter a Permitted peer.

  9. Paste the certificate for your TLS certificate authority (CA) in the TLS CA certificate field.

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

  11. (Optional) The Do not forward debug logs checkbox is enabled by default. To forward DEBUG syslog messages to an external service, disable the checkbox.

    Note: Some Pivotal Platform Isolation Segment components generate a high volume of DEBUG syslog messages.Enabling the Do not forward debug logs checkbox prevents PAS components from forwarding the DEBUG syslog messages to external services. However, Pivotal Platform Isolation Segment still writes the messages to the local disk.

  12. (Optional) To specify a custom syslog rule, enter it in the Custom rsyslog configuration field in RainerScript syntax. For more information about customizing syslog rules, see Customizing Syslog Rules.

  13. Select the Enable system metrics checkbox to emit system-level metrics about all VMs in the deployment. For a list of the VM metrics that the System Metric Agent emits, see VM Metrics in GitHub. When you enable this checkbox, ensure that you open port 9100 for the isolation segment. For more information, see the Configure Firewall Rules section of the Routing for Isolation Segments topic.

  14. Click Save.

Advanced Features

The Advanced Features pane 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 for how much, if any, memory or disk space to overcommit.

To enable overcommit:

  1. Select Advanced Features.

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

  3. Enter in MB the total desired amount of Diego cell disk capacity in the Cell disk capacity field. Refer to the Diego Cell row in the Resource Config tab for the current Diego 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.

Configure Router Resources

  1. Select Resource Config.

  2. If you are using a dedicated router for your isolation segment, follow the instructions below.

    Note: The configuration settings available in Resource Config vary depending on your IaaS.

    • If you have the Load Balancers column in your Resource Config:
      • Enter the wildcard DNS entry attached to your load balancer into the Router row under Load Balancers.
    • If you do not have the Load Balancers column in your Resource Config:
      • Navigate to the Networking section of the Pivotal Platform Isolation Segment tile.
      • Specify Router IPs.
      • Attach the IP addresses to your load balancer manually.
  3. If you are not using HAProxy for this isolation segment, set the number of Instances to 0.

After Tile Configuration

After you configure the Pivotal Platform Isolation Segment tile:

  1. Create the isolation segment in the Cloud Controller database (CCDB) by following the procedure in the Create an Isolation Segment section of the Managing Isolation Segments topic.

  2. Return to the Ops Manager Installation Dashboard.

  3. Click Review Pending Changes, then Apply Changes to deploy the tile.

After the tile finishes deploying, see Managing Isolation Segments for more information about managing an isolation segment.

(Optional) Step 4: Copy the Tile

If you want to create multiple isolation segments, perform the following steps to copy the Pivotal Platform Isolation Segment tile with the Replicator tool:

  1. Download the Replicator tool from the Pivotal Platform Isolation Segment section of Pivotal Network.

  2. Navigate to the directory where you downloaded the Replicator tool.

  3. Replicate the tile:

    ./replicator \
        --name "YOUR-NAME" \
        --path /PATH/TO/ORIGINAL.pivotal \
        --output /PATH/TO/COPY.pivotal
    

    Replace the values above with the following:

    • YOUR-NAME: Provide a unique name for the new Pivotal Platform Isolation Segment tile. The name must be ten characters or less and only contain alphanumeric characters, dashes, underscores, and spaces.
    • /PATH/TO/ORIGINAL: Provide the absolute path to the original Pivotal Platform Isolation Segment tile you downloaded from Pivotal Network.
    • /PATH/TO/COPY: Provide the absolute path for the copy that the Replicator tool produces.
  4. Follow the procedures in this topic using the new .pivotal file, starting with Step 1.

Upgrading Replicated Tiles

For information about upgrading replicated Isolation Segment tiles, see Upgrading Replicated Tiles.