├── .gitignore ├── LICENSE ├── NOTICE ├── README.md ├── _tasks_rec_alloc_oss.html.md.erb ├── capi └── client-libraries.html.md.erb ├── custom-per-route-options.html.md.erb ├── custom-ports.html.md.erb ├── deploy-apps ├── _c2c_oss_enable.html.md.erb ├── _c2c_oss_logging.html.md.erb ├── _c2c_oss_overlay.html.md.erb ├── _routing_conflict.html.md.erb ├── _v3-note.html.md.erb ├── app-lifecycle.html.md.erb ├── app-ssh-overview.html.md.erb ├── blue-green.html.md.erb ├── cf-networking.html.md.erb ├── cf-scale.html.md.erb ├── deploy-app.html.md.erb ├── environment-variable.html.md.erb ├── healthchecks.html.md.erb ├── index.html.md.erb ├── instance-identity.html.md.erb ├── large-app-deploy.html.md.erb ├── manifest-attributes.html.md.erb ├── manifest.html.md.erb ├── prepare-to-deploy.html.md.erb ├── push-docker.html.md.erb ├── rolling-deploy.html.md.erb ├── routes-domains.html.md.erb ├── ssh-apps.html.md.erb ├── ssh-services.html.md.erb ├── stacks.html.md.erb ├── start-restart-restage.html.md.erb ├── stop-delete.html.md.erb ├── streaming-logs.html.md.erb ├── troubleshoot-app-health.html.md.erb ├── trusted-system-certificates.html.md.erb └── windows-stacks.html.md.erb ├── egress-policies.html.md.erb ├── http2-protocol.html.md.erb ├── images ├── about-deploy │ └── app_push_flow_diagram.png ├── blue-green │ ├── blue-green.png │ ├── blue.png │ ├── green.png │ ├── map.png │ └── unmap.png ├── cloudflare │ ├── minimal_manifest.png │ ├── minimal_manifest_v6.png │ └── minimal_manifest_v6_edit1.png ├── orgs-and-spaces │ └── CF-Arch.png ├── route_ports.png ├── self-service.png ├── sidecar-diagram.png ├── ssh-app-access.png └── third-party-logs │ ├── logentries-02.png │ ├── logentries-03.png │ ├── logentries-04.png │ ├── logentries-05.png │ ├── logentries-08.png │ ├── logentries-09.png │ ├── papertrail-02.png │ ├── papertrail-03.png │ ├── papertrail-04.png │ ├── papertrail-05.png │ ├── papertrail-11.png │ ├── splunkstorm-02.png │ ├── splunkstorm-03.png │ ├── splunkstorm-04.png │ ├── splunkstorm-05.png │ ├── splunkstorm-06.png │ ├── splunkstorm-09.png │ ├── splunkstorm-10.png │ ├── sumologic-02.png │ ├── sumologic-03a.png │ ├── sumologic-03b.png │ ├── sumologic-04.png │ ├── sumologic-05.png │ ├── sumologic-06a.png │ ├── sumologic-09.png │ └── sumologic-10.png ├── index.html.md.erb ├── managing-apps-index.html.md.erb ├── multiple-processes.html.md.erb ├── push-sub-commands.html.md.erb ├── push.html.md.erb ├── revisions.html.md.erb ├── routing-index.html.md.erb ├── services-index.html.md.erb ├── services ├── _using-vol-services.html.md.erb ├── application-binding.html.md.erb ├── fluentd.html.md.erb ├── index.html.md.erb ├── integrate-splunk.html.md.erb ├── log-management-thirdparty-svc.html.md.erb ├── log-management.html.md.erb ├── managing-services.html.md.erb ├── metrics.html.md.erb ├── oms-nozzle.html.md.erb ├── play-service-bindings.html.md.erb ├── route-binding.html.md.erb ├── service-keys.html.md.erb ├── sharing-instances.html.md.erb ├── user-provided.html.md.erb └── using-vol-services.html.md.erb ├── sidecars.html.md.erb ├── ssh-index.html.md.erb ├── streaming-logs-index.html.md.erb └── using-tasks.html.md.erb /.gitignore: -------------------------------------------------------------------------------- 1 | output 2 | final_app 3 | .bundle 4 | Gemfile.lock 5 | final_app/* 6 | cached_shas.yml 7 | **/.sass-cache/* 8 | bin 9 | vendor 10 | [#]*[#] 11 | .DS_Store 12 | .ruby-version 13 | .vscode/ -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2015-Present CloudFoundry.org Foundation, Inc. All Rights Reserved. 2 | 3 | Copyright (c) 2023 VMware Inc. All Rights Reserved. 4 | 5 | Licensed under the Apache License, Version 2.0 (the "License"); 6 | you may not use this file except in compliance with the License. 7 | You may obtain a copy of the License at 8 | 9 | http://www.apache.org/licenses/LICENSE-2.0 10 | 11 | Unless required by applicable law or agreed to in writing, software 12 | distributed under the License is distributed on an "AS IS" BASIS, 13 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 14 | See the License for the specific language governing permissions and 15 | limitations under the License. 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Guide for Developers Pushing Apps to Cloud Foundry 2 | 3 | This is a guide for developers on deploying and troubleshooting apps running in Cloud Foundry. 4 | 5 | This is one of several repositories that go into a complete documentation set. 6 | 7 | The contents here are structured as a topic repository intended to be compiled 8 | into a larger document with 9 | [Bookbinder](http://github.com/cloudfoundry-incubator/bookbinder). 10 | 11 | See the [docs-book-cloudfoundry](http://github.com/cloudfoundry/docs-book-cloudfoundry) 12 | repository for the complete list of open source documentation repositories, as well as information about the publishing process. 13 | 14 | docs-dev-guide/deploy-apps subdirectory: 15 | Develop and Manage Apps 16 | Develop and run apps in the cloud. 17 | 18 | docs-dev-guide/capi subdirectory: 19 | Manage resources via the Cloud Foundry API 20 | 21 | docs-dev-guide/services subdirectory: 22 | Custom Services 23 | Create and publish free or metered services for Cloud Foundry apps. 24 | 25 | 26 | This repository used to contain the subdirectory docs-dev-guide/cf-cli, documenting the Cloud Foundry Command Line Interface (cf CLI). The content from this subdirectory has been moved to its own repository, [docs-cf-cli](http://github.com/cloudfoundry/docs-cf-cli). 27 | -------------------------------------------------------------------------------- /_tasks_rec_alloc_oss.html.md.erb: -------------------------------------------------------------------------------- 1 | In the BOSH Cloud Controller Worker job, the `cc.default_app_memory` and `cc.default_app_disk_in_mb` properties specify the default memory and disk 2 | allocations for tasks. 3 | 4 | The `cc.default_app_log_rate_limit_in_bytes_per_second` property specifies the default log rate limit. For more information about BOSH Cloud Controller Worker jobs, see 5 | [BOSH documentation](https://bosh.io/jobs/cloud_controller_worker?source=github.com/cloudfoundry/capi-release). 6 | -------------------------------------------------------------------------------- /capi/client-libraries.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Available Cloud Controller API client libraries 3 | owner: CAPI 4 | --- 5 | 6 | Here is a list of the client libraries you can use with the Cloud Foundry API (CAPI) 7 | <% if vars.platform_code == "CF" %> 8 | . 9 | <% else %> 10 | for <%= vars.app_runtime_first %>. 11 | <% end %> 12 | 13 | ## CAPI overview 14 | 15 | CAPI is the entry point for most operations within the <%= vars.app_runtime_abbr %> 16 | platform. You can use it to manage orgs, spaces, and apps, which includes user roles and permissions. You can also use CAPI to manage the services provided by your <%= vars.app_runtime_abbr %> deployment, including provisioning, creating, and binding them to apps. 17 | 18 | <%= vars.capi_link %> 19 | 20 | ## Client libraries 21 | 22 | While you can develop apps that use CAPI by calling it directly as in the API documentation, you might want to use an existing client library. See the following available client libraries. 23 | 24 | ### Supported 25 | 26 | <%= vars.app_runtime_abbr %> supports the following clients for CAPI: 27 | 28 | * [Java](https://github.com/cloudfoundry/cf-java-client) 29 | * [Scripting](http://cli.cloudfoundry.org/en-US/cf/curl.html) with the Cloud Foundry Command Line Interface (cf CLI) 30 | 31 | ### Experimental 32 | 33 | The following client is experimental and is a work in progress: 34 | 35 | * [Golang](https://github.com/cloudfoundry/go-cfclient) 36 | 37 | ### Unofficial 38 | 39 | <%= vars.app_runtime_abbr %> does not support the following clients, but might be supported by third parties: 40 | 41 | * Python: 42 | * [cloudfoundry-community/cf-python-client](https://github.com/cloudfoundry-community/cf-python-client) 43 | -------------------------------------------------------------------------------- /custom-per-route-options.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Configuring per-route options 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | By default, communication between Gorouter and backends is configured through the general settings at the platform level. 7 | 8 | This topic describes how to specify per-route Gorouter options scoped at the application level. 9 | This greater granularity lets developers tailor optimal routing behavior for applications' unique load profiles or other requirements. 10 | 11 | Gorouter supports the following per-route option, described in the section below: 12 | 13 | - `loadbalancing`: Configures the load balancing algorithm used by Gorouter for this particular route. <%= vars.per_route_lb_version %> 14 | - Settings: `round-robin`, `least-connection`. 15 | 16 | ## Configure Gorouter's Load Balancing Algorithm 17 | 18 | <%= vars.per_route_lb_version %> 19 | 20 | The per-route option `loadbalancing` allows configuring the load balancing algorithm, which defines how the load is distributed between Gorouters and backends. 21 | 22 | This option supports two settings for load balancing: 23 | 24 | - `round-robin` distributes the load evenly across all available backends 25 | - `least-connection` directs traffic to the backend with the fewest active connections at any given time, optimizing resource utilization 26 | 27 | 28 | ### Configure Load Balancing in an App Manifest 29 | 30 | To configure per-route load balancing for an application that has not yet been pushed: 31 | 32 | 1. In the application manifest, include a `route` definition with an `options: loadbalancing` attribute set to `round-robin` or `least-connection`. For example: 33 | 34 | ```yaml 35 | --- 36 | applications: 37 | - name: MY-APP 38 | routes: 39 | - route: MY-HOST.EXAMPLE.COM 40 | options: 41 | loadbalancing: least-connection 42 | ``` 43 | 44 | Where `MY-APP` is the name of your app and `MY-HOST.EXAMPLE.COM` is the route you want to map to your app. 45 | 46 | 1. Push the app with the manifest: 47 | 48 | ```console 49 | cf push -f manifest.yml 50 | ``` 51 | 52 | ### Change Load Balancing Algorithm of an Existing Route 53 | 54 | To change the per-route `loadbalancing` option of an existing route, you can use the cli command, `update-route`. 55 | 56 | For example, to change an app route's algorithm from `least-connection` to `round-robin`, you can run the `update-route` command: 57 | 58 | ```console 59 | cf update-route EXAMPLE.COM --hostname MY-HOST --option loadbalancing=round-robin 60 | ``` 61 | 62 | Alternatively, it is also possible to update the per-route load balancing option via the `/v3/routes` API. 63 | 64 | Run the `PATCH` request to the targeted API endpoint: 65 | 66 | ```console 67 | cf curl /v3/routes/GUID -X PATCH -H "Content-type: application/json" \ 68 | -d '{ 69 | "options": { 70 | "loadbalancing": "round-robin" 71 | } 72 | }' 73 | ``` 74 | Where `GUID` is the unique identifier for the route. 75 | 76 | ### Create a Route with a specific Load Balancing Algorithm 77 | 78 | To create a route with a per-route `loadbalancing` option, you can use the cli command `create-route`. 79 | For example: 80 | 81 | ```console 82 | cf create-route EXAMPLE.COM --hostname MY-HOST --option loadbalancing=round-robin 83 | ``` 84 | 85 | Alternatively, it is also possible to create a route with a per-route load balancing option via the `/v3/routes` API: 86 | 87 | ```console 88 | cf curl /v3/routes -X POST -H "Content-type: application/json" \ 89 | -d '{ 90 | "host": "MY-HOST", 91 | "path": "MY-PATH", 92 | ... 93 | "options": { 94 | "loadbalancing": "round-robin" 95 | } 96 | }' 97 | ``` 98 | 99 | ### Map a Route to an Existing App with specific Load Balancing Algorithm 100 | 101 | To create and map a new route to an existing application with the per-route `loadbalancing` option, you can use the cli command `map-route`. 102 | 103 | For example: 104 | 105 | ```console 106 | cf map-route MY-APP EXAMPLE.COM --hostname MY-HOST --option loadbalancing=round-robin 107 | ``` 108 | 109 |

110 | The command map-route supports the --option flag only for new routes. 111 | To update an existing route, the command update-route must be used as described before.

112 | 113 | ### Retrieve Route Options 114 | 115 | To read route options, you can query the route using the `route` command: 116 | 117 | ```console 118 | cf route EXAMPLE.COM --hostname MY-HOST 119 | ``` 120 | 121 | The response lists the chosen `loadbalancing` algorithm option, e.g. `least-connection`: 122 | 123 | ```console 124 | options: {loadbalancing=least-connection} 125 | ``` 126 | 127 | Alternatively, you can query the `routes` API endpoint for a route: 128 | 129 | ```console 130 | cf curl /v3/routes/?hosts=MY-HOST 131 | ``` 132 | 133 | Where `MY-HOST` is the host attribute of the route. The response lists the chosen `loadbalancing` algorithm option as well: 134 | 135 | ```console 136 | "options": {"loadbalancing": "least-connection"} 137 | ``` 138 | 139 | To retrieve all the routes with the corresponding options in a space of an organization, you can use the `routes` command. 140 | -------------------------------------------------------------------------------- /custom-ports.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Configuring Cloud Foundry to route traffic to apps on custom ports 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | <%# Reset page title based on platform type %> 7 | <% if vars.platform_code != 'CF' %> 8 | 9 | <% set_title("Configuring", vars.app_runtime_abbr, "to Route Traffic to Apps on Custom Ports") %> 10 | 11 | <% end %> 12 | 13 | 14 | By default, apps only receive requests on port `8080` for both HTTP and TCP routing. Configuring custom app ports allows developers to bring workloads onto 15 | <%= vars.app_runtime_abbr %> that receive requests on ports other than `8080`. Here are some example use cases: 16 | 17 | * Serving web client requests on one port, and stats and debugging on another 18 | 19 | * Using TCP protocols that require multiple ports 20 | 21 | * Running Docker images on <%= vars.app_runtime_abbr %> 22 | 23 | To use the `apps` and `route_mappings` Cloud Controller API endpoints to update the ports so the the app can receive requests, see [Procedure](#procedure). 24 | 25 | ## Flow of a request to an app 26 | 27 | The table describes the Network Address Translation that occurs in the data path of a client request: 28 | 29 | | Port Type | Description | Network Hop | 30 | | --------- | ----------- | ----------- | 31 | | Route port | The port to which a client sends a request | Client to load balancer, load balancer to Gorouter | 32 | | Back end port | The port on the VM where an application container is hosted, which is unique to the container | Gorouter to Diego Cell | 33 | | App port | The port on the container, which must match a port on which the app is configured to receive requests | Diego Cell to application container | 34 | 35 | The following diagram shows an example data path and Network Address Translation for TCP routing: 36 | 37 | ![Traffic flow-diagram for data path and Network Address Translation for TCP routing](./images/route_ports.png) 38 | 39 | For HTTP routing, the route port is always `80` or `443`. 40 | 41 | ## Prerequisites 42 | 43 | Before you follow the procedure to configure routing to your app on custom ports, you must have: 44 | 45 | * An app pushed to <%= vars.app_runtime_abbr %> that can receive requests on one or more custom ports. 46 | 47 | * Routes for which you want traffic forwarded to your app on custom ports, which are mapped to the app. 48 | 49 | If your app receives requests on two ports, and you want clients to be able to send requests to both of them, create two routes. These routes can be from HTTP or TCP domains. 50 | 51 | ## Procedure 52 | 53 | In the following procedure, use API endpoints to map the routes to your app on the ports it uses to receive requests. 54 | For more information about routes, see Routes and Domains.

55 | 56 | To configure your app to receive HTTP or TCP requests on custom ports: 57 | 58 | 1. Run: 59 | 60 | ```console 61 | cf app APP-NAME --guid 62 | ``` 63 | 64 | Where `APP-NAME` is the name of your app. 65 | 66 | 2. From the output, record: 67 | * Under `guid`, the global unique identifier (GUID) of your app. 68 | * Under `type`, the process type your app uses. 69 | 70 | 3. Retrieve the GUIDs of the routes for your app by running one of these commands, depending on whether your app uses HTTP or TCP routes: 71 | * For HTTP routes, run: 72 | 73 | ```console 74 | cf curl /v3/apps/APP-GUID/routes?hosts=ROUTE-HOSTNAME 75 | ``` 76 | 77 | Where: 78 | 82 | * For TCP routes, run: 83 | 84 | ```console 85 | cf curl /v3/apps/APP-GUID/routes?port=PORT 86 | ``` 87 | 88 | Where: 89 | 93 | 94 | 4. From the output, record the GUIDs of the routes for your app. 95 | 96 | 5. For each route, update the ports to which it sends requests by running: 97 | 98 | ```console 99 | cf curl -X PATCH /v3/routes/ROUTE-GUID/destinations -d '{ 100 | "destinations": [ 101 | { 102 | "app": { 103 | "guid": "APP-GUID", 104 | "process": { 105 | "type": "PROCESS-TYPE" 106 | } 107 | }, 108 | "port": PORT, 109 | "protocol": "PROTOCOL" 110 | } 111 | ] 112 | }' 113 | ``` 114 | 115 | Where: 116 | 123 | 124 |

125 | This API call removes all destinations for a route and replaces them with the destinations you provide in the API request.

126 | 127 | ## Additional resources 128 | 129 | * For more information about making requests to the Cloud Controller API (CAPI) `apps` endpoints, see the [CAPI V3 documentation](https://v3-apidocs.cloudfoundry.org/index.html#apps). 130 | -------------------------------------------------------------------------------- /deploy-apps/_c2c_oss_enable.html.md.erb: -------------------------------------------------------------------------------- 1 | ## Activate container-to-container networking 2 | 3 | Container networking is installed by default when you install Cloud Foundry using `cf-deployment`. 4 | 5 | For instructions for using `cf-deployment`, see the [Cloud Foundry documentation](https://docs.cloudfoundry.org/deploying/cf-deployment/index.html). 6 | 7 | Container networking has properties you can configure to change the default behavior. 8 | 9 | The following table has a list of properties and instructions for editing them. 10 | 11 | For more information about container networking configuration, see [Configuration Information for Operators](https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/06-c2c.md). 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 24 | 29 | 30 | 31 | 36 | 42 | 43 | 44 | 49 | 54 | 55 | 56 | 64 | 65 |
Container-to-container networking opsfilesDescription

20 |     - type: replace
21 |     path: /instance_groups/name=diego-cell/jobs/name=vxlan_policy_agent/properties/iptables_logging?
22 |     value: true
23 |
25 | The default value for iptables_logging is false. 26 |

27 | (Optional) Change the value to true to activate logging for Container-to-Container policy iptables rules. 28 | 

32 |     - type: replace
33 |     path: /instance_groups/name=diego-cell/jobs/name=cni/properties/iptables_logging?
34 |     value: true
35 |
37 | The default value for iptables_logging is false. 38 |

39 | (Optional) Change the value to true to activate 40 | logging for Application Security Group (ASG) iptables rules. 41 | 

45 |     - type: replace
46 |     path: /instance_groups/name=diego-api/jobs/name=silk-controller/properties/network?
47 |     value: REPLACE-WITH-OVERLAY-NETWORK-CIDR
48 |
50 | (Optional) Enter an IP range for the overlay network. The CIDR must specify an RFC 1918 range. If you do not set a custom range, the deployment uses 10.255.0.0/16. 51 |

52 | See App Instance Communication for more information. 53 | 

57 |     - type: replace
58 |     path: /instance_groups/name=diego-cell/jobs/name=cni/properties/mtu?
59 |     value: REPLACE-WITH-MTU
60 |
61 | 		62 | (Optional) You can manually configure the Maximum Transmission Unit (MTU) value to support additional encapsulation overhead. 63 |
66 | 67 | To see how container networking works with and without service discovery, see [Cats and Dogs with Service Discovery](https://github.com/cloudfoundry/cf-networking-examples/blob/master/docs/c2c-with-service-discovery.md) in GitHub. In this tutorial, you deploy two apps and create a Container-to-Container Networking policy that allows them to communicate directly with each other. 68 | -------------------------------------------------------------------------------- /deploy-apps/_c2c_oss_logging.html.md.erb: -------------------------------------------------------------------------------- 1 | ## Manage logging for container-to-container networking 2 | 3 | This section describes how to configure logging for container-to-container Networking events by making requests to the running virtual machines (VMs). 4 | You can also activate logging for iptables policy rules by editing the manifest in [Activate on an IaaS](#iaas). 5 | 6 | ### Change log level for debugging 7 | 8 | By default, the Policy Server logs events at the `INFO` level. 9 | You can get more information about events by increasing the log level to `DEBUG`. 10 | 11 | To change the log level, follow these steps: 12 | 13 | 1. SSH to either the Policy Server or the VXLAN Policy Agent. 14 | * **Policy Server**: SSH directly to the Policy Server VM. 15 | * **VXLAN Policy Agent**: SSH to the Diego Cell that runs the VXLAN Policy Agent. 16 | 17 | 2. To change the log level, run: 18 | 19 | 
20 |     curl -X POST -d 'LOG-LEVEL' localhost:PORT-NUMBER/log-level
21 |
22 | 23 | The `LOG-LEVEL` is `DEBUG` or `INFO`. The `PORT-NUMBER` is `22222` unless you specified a different number when you edited the stub file in [Activate on an IaaS](#iaas). 24 |

25 | 26 | To increase the log level to `DEBUG`, run: 27 | 
28 |     $ curl -X POST -d 'DEBUG' localhost:22222/log-level
29 |
30 | 31 | To decrease the log level to `INFO`, run: 32 | 
33 |     $ curl -X POST -d 'INFO' localhost:22222/log-level
34 |
35 | 36 | 3. The logs are available in: 37 | * **Policy Server**: `/var/vcap/sys/log/policy-server/policy-server.stdout.log` 38 | * **VXLAN Policy Agent**: `/var/vcap/sys/log/vxlan-policy-agent/vxlan-policy-agent.stdout.log` 39 | 40 | ### Activate logging for container-to-container networking policies 41 | 42 | By default, Cloud Foundry does not log iptables policy rules for Container-to-Container network traffic. You can activate logging for iptables policy rules in the manifest in [Activate on an IaaS](#iaas), or use following the steps: 43 | 44 | 1. SSH to the Diego Cell that runs the VXLAN Policy Agent. 45 | 46 | 2. To change the log level, run: 47 | 48 | 
49 |     curl -X PUT -d '{"enabled": BOOLEAN}' localhost:PORT-NUMBER/iptables-c2c-logging
50 |
51 | 52 | The `BOOLEAN` is `true` or `false`. The `PORT-NUMBER` is `22222` unless you specified a different number when you edited the stub file in [Activate on an IaaS](#iaas). 53 |

54 | 55 | To activate logging for iptables policy rules, run: 56 | 
57 |     $ curl -X PUT -d '{"enabled": true}' localhost:22222/iptables-c2c-logging
58 |
59 | 60 | To deactivate logging for iptables policy rules, run: 61 | 
62 |     $ curl -X PUT -d '{"enabled": false}' localhost:22222/iptables-c2c-logging
63 |
64 | 65 | 3. Find the logs in `/var/log/kern.log`. 66 | 67 | ### Use metrics to consume logs 68 | 69 | You can stream container-to-container networking component metrics with the [Loggregator Firehose](../../loggregator/architecture.html#firehose). 70 | 71 | Container-to-container networking logs use the following prefixes: 72 | 73 | * `netmon` 74 | * `vxlan_policy_agent` 75 | * `policy_server` 76 | -------------------------------------------------------------------------------- /deploy-apps/_c2c_oss_overlay.html.md.erb: -------------------------------------------------------------------------------- 1 | ## Configure the overlay network 2 | 3 | Container-to-container networking uses an overlay network to manage 4 | communication between app instances. By default, each Diego Cell in the overlay 5 | network is allocated a /24 range that supports 254 containers per cell, one 6 | container for each of the usable IP addresses, `.1` through `.254`. 7 | 8 | For more information about the overlay network, see [Overlay 9 | network](../../concepts/understand-cf-networking.html#overlay-network) in 10 | _Container-to-container networking_. 11 | 12 | ### Understanding the Overlay Network Properties using a Pie Metaphor 13 | 14 | There are two <%= vars.app_runtime_abbr %> properties concerning the overlay 15 | network. Before going into the details of the actual <%= vars.app_runtime_abbr 16 | %> properties, let's talk about them metaphorically. 17 | 18 | Imagine the entire overlay network is a group of pies. One <%= vars.app_runtime_abbr %> 19 | property defines these pies and their sizes. 20 | 21 | The purpose of these pies are to serve the hungry, hungry Diego Cells. Each Diego 22 | Cell is hungry and needs a slice of pie. Without a slice of pie the Diego Cell 23 | cannot start because it has no energy. This is an egalitarian kitchen, so each 24 | Diego Cell must get the same size pie slice. 25 | 26 | The second <%= vars.app_runtime_abbr %> property determines the size of the pie 27 | slice that each Diego Cell is given. The smaller the slice of pie that each Diego 28 | Cell gets, the less “energy” each Diego Cell has, and thus fewer apps can run on each 29 | Diego Cell. The larger the slice of pie is that each Diego Cell gets, the more 30 | “energy” the Diego Cell has, and thus more apps can run on each Diego Cell. 31 | 32 | If the pies and their sizes stay constant, smaller slices of pie means there can be 33 | more Diego Cells (which are fed less each) and larger slices means there is a 34 | smaller number of possible Diego Cells (which are fed more each). 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 52 | 53 | 54 | 55 | 56 | 57 | 61 | 62 |
Pie Metaphor PropertyActual Bosh PropertyDescriptionDefault
Group of pies and their sizesnetwork on the silk-controller jobAn list of CIDR address blocks for the overlay network provided as an 48 | array of strings. Subnets for each Diego Cell are allocated out of this 49 | network. The subnet_prefix_length property must be smaller than the 50 | smallest CIDR address block. 51 | ["10.255.0.0/16"]
Slice size for each Diego Cell"subnet_prefix_length" on the silk-controller jobThe CIDR mask for each Diego Cell's individual overlay network subnet. 58 | For a /24 subnet for each Diego Cell, enter 24 This subnet must be 59 | smaller than all individual IP ranges provided in the network property. 60 | 24
63 | 64 | 65 | ### Configuring Overlay Networking Properties 66 | 67 | Changing the two overlay network properties "network" and 68 | "subnet_prefix_length" affect how many Diego Cells can run in one deployment 69 | and how many apps can be run on each Diego Cell. 70 | 71 | Use the following algorithm to determine how many Diego Cells can run with a 72 | given configuration. 73 | 74 | ``` 75 | A = the total number of IPs in the "network" 76 | B = number of IPs per Diego Cell as defined by the "subnet_prefix_length" 77 | C = number of CIDRs in the "network" 78 | 79 | Max supported number of Diego Cells = (A/B) - C 80 | ``` 81 | 82 | Here is an example using the default values: 83 | ``` 84 | network = ["10.255.0.0/16"] 85 | subnet_prefix_length = 24 86 | 87 | A = /16 CIDR = 65,536 IPs 88 | B = /24 CIDR = 256 IPs 89 | C = 1 90 | 91 | Max supported number of Diego Cells = (65,536/256) - 1 = 255 92 | ``` 93 | 94 | Here is an example using other values: 95 | ``` 96 | network = ["10.255.0.0/20", "10.255.96.0/21"] 97 | subnet_prefix_length = 24 98 | 99 | A = /20 CIDR + /21 CIDR = 4,096 IPs + 2,048 IPs = 6,144 IPs 100 | B = /24 CIDR = 256 IPs 101 | C = 2 102 | 103 | Max supported number of Diego Cells = (6,144/256) - 2 = 22 104 | ``` 105 | 106 | All CIDRs provided in the "network" must have a larger prefix length 107 | than the "subnet_prefix_length." 108 | 109 | Here are some examples of invalid combinations of properties: 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 |
PropertyValue
network["10.255.0.0/20", "10.255.96.0/21", "10.255.200.0/23", "10.255.220.0/24"]
subnet_prefix_length24
Invalid reasonsubnet_prefix_length must be smaller than all CIDRs in the network. In this case it is the same size as 10.255.220.0/24.
129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 |
PropertyValue
network["10.255.0.0/20", "10.255.96.0/21", "10.255.200.0/23", "10.255.220.0/32"]
subnet_prefix_length24
Invalid reasonsubnet_prefix_length must be smaller than all CIDRs in the network. In this case it is larger than 10.255.220.0/32.
149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 |
PropertyValue
network["10.255.0.0/20", "10.255.0.0/16"]
subnet_prefix_length24
Invalid reasonnetwork must not have any overlapping IP ranges. In this case 10.255.0.0/20 is a subset of 10.255.0.0/16.
169 | 170 | ### Changing the Overlay Network 171 | 172 | Updating the "network" and "subnet_prefix_length" property is supported. However it will cause 173 | container-to-container networking downtime during the deploy while the network 174 | update is rolling out across Diego Cells. 175 | 176 |

The overlay network IP address ranges must not conflict with any other IP 177 | addresses in the network. If a conflict exists, Diego Cells cannot reach any 178 | endpoint that has a conflicting IP address.

179 | -------------------------------------------------------------------------------- /deploy-apps/_routing_conflict.html.md.erb: -------------------------------------------------------------------------------- 1 | <%=vars.product_short%> allows multiple apps, or versions of the same app, to be mapped to the same route. This feature activates blue-green deployment. For more information see [Using blue-green deployment to reduce downtime and risk](./blue-green.html). 2 | 3 | Routing multiple apps to the same route might cause undesirable behavior in some situations by routing incoming requests randomly to one of the apps on the shared route. -------------------------------------------------------------------------------- /deploy-apps/_v3-note.html.md.erb: -------------------------------------------------------------------------------- 1 |
2 | This attribute is available with CAPI V3 only. To push a manifest that uses this attribute, do one of the following: 3 |

4 |

9 |

10 |
11 | -------------------------------------------------------------------------------- /deploy-apps/app-lifecycle.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: The application container life cycle on the Diego architecture 3 | owner: Diego 4 | --- 5 | 6 | The life cycle stages of an application container for your <%= vars.app_runtime_first %> deployments running on the Diego architecture include deployment, failure events, evacuation, and shutdown. 7 | 8 | 9 | ## Deployment 10 | 11 | App deployment involves uploading, staging, and starting the app in a container. Your app must complete each of these phases within a certain time limit. The default time limits for the phases are: 12 | 13 | * Upload: 15 minutes 14 | * Stage: 15 minutes 15 | * Start: 60 seconds 16 | 17 | Your administrator can change these default settings. Check with your administrator for the actual time limits set for app deployment. 18 | 19 | Developers can change the time limit for starting apps through an app manifest or on the command line. For more information, see [Deploying with app manifests](manifest.html) and [Using app health checks](./healthchecks.html). 20 | 21 | 22 | ## Crash events 23 | 24 | If an app instance fails, <%= vars.app_runtime_abbr %> restarts it by rescheduling the instance on another container three times. After three failed restarts, <%= vars.app_runtime_abbr %> waits 30 seconds before attempting another restart. The wait time doubles each restart until the ninth restart, and remains at that duration until the 200th restart. After the 200th restart, <%= vars.app_runtime_abbr %> stops trying to restart the app instance. 25 | 26 | ## Evacuation 27 | 28 | Some actions require restarting VMs with containers hosting app instances. For example, you can update stemcells or install a new version of <%= vars.app_runtime_abbr %>. You must restart all the VMs in a deployment. 29 | 30 | <%= vars.app_runtime_abbr %> relocates the instances on VMs that are shutting down through a process called evacuation. <%= vars.app_runtime_abbr %> recreates the app instances on another VM, waits until they are healthy, and then shuts down the old instances. During an evacuation, you might see the app instances in a duplicated state for a brief time. 31 | 32 | During app duplication, singleton app instances might become temporarily unavailable if the replacement instance does not become healthy within the evacuation timeout of the Diego Cell (the default is ten minutes). App developers with a low tolerance for downtime might prefer to run several instances of their app. See [Run multiple instances to increase availability](prepare-to-deploy.html#increase-availability). 33 | 34 | 35 | ## Shutdown 36 | 37 | <%= vars.app_runtime_abbr %> requests a shutdown of your app instance when: 38 | 39 | * A user runs `cf scale`, `cf stop`, `cf push`, `cf delete`, or `cf restart-app-instance`. 40 | 41 | * A system event occurs, such as the replacement procedure during Diego Cell evacuation or when an app instance stops because of a failed health check probe. 42 | 43 | To stop the app, <%= vars.app_runtime_abbr %> sends the app process in the container a SIGTERM. By default, the process has ten seconds to shut down gracefully. If the process has not exited after ten seconds, <%= vars.app_runtime_abbr %> sends a SIGKILL. 44 | 45 | By default, apps must finish their in-flight jobs within ten seconds of receiving the SIGTERM before <%= vars.app_runtime_abbr %> stops the app with a SIGKILL. For example, a web app must finish processing existing requests and stop accepting new requests. 46 | <% if vars.platform_code == 'PCF' %> 47 | To change the timeout period on the <%= vars.app_runtime_abbr %> tile or IST tile, go to the Advanced Settings tab and edit the "app graceful shutdown period" property. 48 | <% else %> 49 | To change the timeout period, change the BOSH property containers.graceful_shutdown_interval_in_seconds on the replacement jobs. 50 | <% end %> 51 | This might increase the time it takes to drain Diego Cells, which causes increased deployment time. 52 | 53 | <%= vars.app_graceful_shutdown_config %> 54 | 55 |

56 | An exception to the cases previously mentioned is when monit restarts a Diego Cell replacement or Garden server that has failed. In this case, <%= vars.app_runtime_abbr %> immediately stops the apps that are still running using SIGKILL.

57 | -------------------------------------------------------------------------------- /deploy-apps/app-ssh-overview.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Configuring SSH access for your deployment 3 | owner: Diego 4 | --- 5 | 6 | If you need to troubleshoot an instance of an application, you can gain SSH access to the app using the SSH proxy and daemon. 7 | For example, one of the app instances might be unresponsive, or the log output from the app is inconsistent or incomplete. You can SSH into the individual VM to troubleshoot the problem instance. 8 | 9 | <%= vars.mutual_tls_ssh %> 10 | 11 | 12 | ## About SSH access 13 | 14 | The SSH system components include the SSH proxy and daemon, and the system also supports authentication and load balancing of incoming SSH traffic. For a conceptual overview, see [App SSH components and processes](../../concepts/diego/ssh-conceptual.html). 15 | 16 | 17 | ## SSH access control hierarchy 18 | 19 | Operators, space managers, and space developers can configure SSH access for <%= vars.app_runtime_abbr %>, 20 | for spaces, and for apps as described in the table: 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 |
User roleScope of SSH permissions controlHow they define SSH permissions
OperatorEntire deploymentConfigure the deployment to allow or prohibit SSH access (one-time). <%=vars.config_ssh_link%>
Space managerSpacecf CLI allow-space-ssh and disallow-space-ssh commands
Space developerAppcf CLI enable-ssh and disable-ssh commands
42 | 43 | An app is SSH-accessible only if operators, space managers, and space developers all grant SSH access at their respective levels. For example, the following image shows a deployment in whi: 44 | 45 | * An operator allowed SSH access at the deployment level. 46 | * A space manager allowed SSH access for apps running in spaces "A" and "B," but not "C". 47 | * A space developer activated SSH access for apps that include "Foo", "Bar," and "Baz". 48 | 49 | As a result, apps "Foo", "Bar," and "Baz" accept SSH requests. 50 | 51 | ![This diagram shows examples of successful and unsuccessful SSH Application Access Control in deployments.](../images/ssh-app-access.png) 52 | 53 | Space A has SSH Access Enabled, indicated by a green check mark, for apps "Foo" and "Bar," Space A does not have SSH Access allowed for the third app, indicated by a red X. 54 | 55 | Space B has has SSH Access Enabled, indicated by a green check mark, for app "Baz". Space B does not have SSH Access allowed for the other two apps, indicated by a red X. 56 | 57 | Space C does not have SSH Access allowed for all three apps, indicated by a red X. 58 | 59 | ## SSH access for apps and spaces 60 | 61 | Space managers and space developers can configure SSH access from the CLI. The Cloud Foundry Command Line Interface (cf CLI) also includes commands to return the value of the SSH access setting. To use and configure SSH at both the app level and the space level, see [Accessing apps with Diego SSH](./ssh-apps.html). 62 | 63 | 64 | ## Configuring SSH access for <%= vars.app_runtime_full %> 65 | 66 | <%= vars.platform_ssh_configuration %> 67 | -------------------------------------------------------------------------------- /deploy-apps/blue-green.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Using blue-green deployment to reduce downtime 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | 7 | Blue-green deployment is a technique that helps you reduce app downtime and risk by running 8 | two identical production environments: "Blue" and "Green." 9 | 10 | At any time, only one of the environments is live, with the live environment 11 | serving all production traffic. 12 | 13 | For the example discussed here, Blue is live and Green is idle. 14 | As you prepare a new version of your software, deployment and the final stage of 15 | testing takes place in the environment that is not live: in this example, Green. 16 | After deploy and fully tested the software in Green, you switch the 17 | router so that all incoming requests now go to Green instead of Blue. 18 | Green is now live, and Blue is idle. 19 | 20 | This technique can eliminate downtime due to app deployment. 21 | In addition, blue-green deployment reduces risk: if something unexpected happens 22 | with your new version on Green, you can immediately roll back to the last 23 | version by switching back to Blue. 24 | 25 | You can adjust the route mapping pattern to display a static maintenance page during a maintenance window for time-consuming tasks such as migrating a database. In this scenario, the router switches all incoming requests from Blue to Maintenance to Green. 26 | 27 |

28 | If your app uses a relational database, blue-green deployment can lead to discrepancies between your green and glue databases during an update. To maximize data integrity, configure a single database for backward and forward compatibility.

29 | 30 | 31 | ## Blue-green deployment with Cloud Foundry example 32 | 33 | For this example, consider a simple app: "demo-time." 34 | This app is a webpage that displays the words "Blue time" and the date/time on 35 | the server. 36 | 37 | ### Step 1: Push an app 38 | 39 | Use the Cloud Foundry Command Line Interface (cf CLI) to push the app. 40 | Name the app "Blue" with the subdomain "demo-time." 41 | 42 | 
 43 | $ cf create-route example.com --hostname demo-time
 44 | $ cf push Blue
 45 | $ cf map-route Blue example.com --hostname demo-time
 46 |
47 | 48 | As shown in the graphic: 49 | 50 | * Blue is now running on Cloud Foundry. 51 | * The Cloud Foundry Router sends all traffic for `demo-time.example.com` traffic to Blue. 52 | 53 | ![cf CLI pushing an app.](./images/../../images/blue-green/blue.png) 54 | 55 | ### Step 2: Update app and push 56 | 57 | Now make a change to the app. 58 | 1. Replace the word "Blue" on the webpage with "Green," then rebuild the source file for the app. 59 | 1. Run `cf push` again, but use the name "Green" for the app and provide a different subdomain to create a temporary route: 60 | 61 | 
 62 | $ cf create-route example.com --hostname demo-time-temp
 63 | $ cf push Green
 64 | $ cf map-route Green example.com --hostname demo-time-temp
 65 |
66 | 67 | After this push: 68 | 69 | * Two instances of the app are now running on Cloud Foundry: the original Blue and the updated Green. 70 | * The Cloud Foundry Router continues sending all traffic for `demo-time.example.com` to Blue. 71 | The router now also sends any traffic for `demo-time-temp.example.com` to Green. 72 | 73 | ![The CF Router directs traffic to both Blue and Green sides.](../images/blue-green/blue-green.png) 74 | 75 | ### Step 3: Map original route to Green 76 | 77 | Now that both apps are up and running, switch the router so all incoming 78 | requests go to both the Green app and the Blue app. 79 | Use the [cf map-route](http://cli.cloudfoundry.org/en-US/cf/map-route.html) command to map the original URL route (`demo-time.example.com`) to the Green app. 80 | 81 | 
 82 | $ cf map-route Green example.com -n demo-time
 83 | Binding demo-time.example.com to Green... OK
 84 |
85 | 86 | After the `cf map-route` command : 87 | 88 | * The Cloud Foundry Router continues sending traffic for `demo-time-temp.example.com` to Green. 89 | * Within a few seconds, the Cloud Foundry Router begins load balancing traffic for `demo-time.example.com` between Blue and Green. 90 | 91 | ![CF Router load balances traffic between the Blue and Green sides.](./images/../../images/blue-green/map.png) 92 | 93 | ### Step 4: Unmap route to Blue 94 | 95 | After you verify that Green is running as expected, stop routing requests to Blue 96 | using the [cf unmap-route](http://cli.cloudfoundry.org/en-US/cf/unmap-route.html) command: 97 | 98 | 
 99 | $ cf unmap-route Blue example.com -n demo-time
100 | Unbinding demo-time.example.com from blue... OK
101 |
102 | 103 | After the `cf unmap-route` command: 104 | 105 | * The Cloud Foundry Router stops sending traffic to Blue. 106 | 107 | Now all traffic for `demo-time.example.com` is sent to Green. 108 | 109 | ![CF Router now directs all traffic to the Green side.](./images/../../images/blue-green/unmap.png) 110 | 111 | ### Step 5: Remove temporary route to Green 112 | 113 | You can now use `cf unmap-route` to remove the route `demo-time-temp.example.com` from Green. You can delete the route using `cf delete-route` or reserved it for later use. You can also decommission Blue, or keep it in case you need to roll back your changes. 114 | 115 | ![After all traffic is routed to Green, the Blue side can be removed or replaced.](./images/../../images/blue-green/green.png) 116 | 117 | ## Implementation 118 | 119 | Cloud Foundry community members have written a plug-in to automate blue-green deployment: 120 | 121 | * [BlueGreenDeploy](https://github.com/bluemixgaragelondon/cf-blue-green-deploy): cf-blue-green-deploy is a plug-in, written in Go, for the Cloud Foundry Command Line Interface (cf CLI) that automates a few steps involved in zero-downtime deployments. 122 | -------------------------------------------------------------------------------- /deploy-apps/cf-networking.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Configuring container-to-container networking 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | 7 | The container-to-container networking feature, also known as CF Networking, allows direct network traffic between apps. For an overview of how container-to-container networking works, see [Container-to-container networking](../../concepts/understand-cf-networking.html). 8 | 9 |

10 | Container-to-container networking is not available for apps hosted on Microsoft Windows.

11 | 12 | <%= vars.app_traffic_logging %> 13 | 14 | <% if vars.platform_code == "CF" %> 15 | <%= partial 'c2c_oss_enable' %> 16 | <% end %> 17 | 18 | <% if vars.platform_code == "CF" %> 19 | <%= partial 'c2c_oss_overlay' %> 20 | <% else %> 21 | <%= partial "/pcf/core/c2c_overlay" %> 22 | <% end %> 23 | 24 | <% if vars.platform_code == "CF" %> 25 | <%= partial 'c2c_oss_logging' %> 26 | <% end %> 27 | 28 | 29 | ## Create and manage networking policies 30 | 31 | This section describes how to create and edit container-to-container networking policies using the Cloud Foundry Command Line Interface (cf CLI). 32 | 33 | <%= vars.app_man_network %> 34 | 35 | ### Prerequisites 36 | 37 | Ensure that you are using cf CLI v7 or later: 38 | 39 | 
 40 | $ cf version
 41 |
42 | 43 | For more information about updating the cf CLI, see [Installing the cf CLI](../../cf-cli/install-go-cli.html). 44 | 45 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 46 | 47 | ### Grant permissions 48 | 49 | Cloud Foundry admins use the following UAA scopes to grant specific users or groups permissions to configure network policies: 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 |
UAA ScopeSuitable for…Allows users to create policies…
network.adminoperatorsfor any apps in the Cloud Foundry deployment
network.writespace developersfor apps in spaces that they can access
68 | 69 | If you are a Cloud Foundry admin, you already have the `network.admin` scope. An admin can also grant the `network.admin` scope to a space developer. 70 | 71 | <%= vars.uaa_cli %> 72 | 73 | To grant all Space Developers permissions to configure network policies, <%= vars.grant_devs_c2c %>. 74 | 75 | By default, Space Developers can add a maximum of 150 network policies per 76 | source app. 77 | <% end %> 78 | <% if vars.platform_code == "PCF" %> 79 | Operators can increase this limit by changing the **Maximum number of network 80 | policies per app source** property in the **App Developer Controls** tab. 81 | <% end %> 82 | <% if vars.platform_code == "CF" %> 83 | Operators can change this limit by changing the `max_policies_per_app_source` property in the policy-server job in 84 | the Cloud Foundry deployment manifest. 85 | <% end %> 86 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 87 | This limit does not apply to users with the network.admin scope. 88 | 89 | <% end %> 90 | 91 | ### Add a network policy 92 | 93 | To add a policy that allows direct network traffic from one app to another, run: 94 | 95 | ``` 96 | cf add-network-policy SOURCE-APP DESTINATION-APP -s DESTINATION-SPACE-NAME -o DESTINATION-ORG-NAME --protocol (tcp | udp) --port RANGE 97 | ``` 98 | 99 | Where: 100 | 101 | * `SOURCE-APP` is the name of the app that sends traffic. 102 | * `DESTINATION-APP` is the name of the app that receives traffic. 103 | * `DESTINATION-SPACE-NAME` is the space of the destination app. The default is the targeted space. 104 | * `DESTINATION-ORG-NAME` is the org of the destination app. The default is the targeted org. 105 | * `PROTOCOL` is either: `tcp` or `udp`. 106 | * `RANGE` contains the ports at which to connect to the destination app. The allowed range is from `1` to `65535`. You can specify a single port, such as `8080`, or a range of ports, such as `8080-8090`. Port 61443 is used for TLS communication. 107 | 108 | Use the `add-network-policy` command to allows access from the `frontend` app to the `backend` app over TCP at port 8080. Here is an example: 109 | 110 | 
111 | $ cf add-network-policy frontend backend --protocol tcp --port 8080
112 | Adding network policy to app frontend in org my-org / space dev as admin...
113 | OK
114 |
115 | 116 | <%= vars.network_policy_quota %> 117 | This limit does not apply to users with the `network.admin` scope. 118 | 119 | <%= vars.network_policy_quota_config %> 120 | 121 | ### List policies 122 | 123 | You can list all the policies in your space, or just the policies for which a single app is the source: 124 | 125 | * To list the all the policies in your space, run `cf network-policies`. 126 | 127 | 
128 |     $ cf network-policies
129 |
130 | 131 | * To list the policies for an app, run `cf network-policies --source MY-APP`. Replace `MY-APP` with the name of your app. 132 | 133 | 
134 |     $ cf network-policies --source example-app
135 |
136 | 137 | The following example of the `network-policy` command lists policies for the app `frontend`: 138 | 139 | 
140 |     $ cf network-policies --source frontend
141 |     Listing network policies in org my-org / space dev as admin...
142 | 
143 |     source      destination   protocol   ports    destination space    destination org
144 |     frontend    backend       tcp        8080     example-space        example-org
145 |
146 | 147 | ### Remove a network policy 148 | 149 | To remove a policy that allows direct network traffic from an app, run: 150 | 151 | ``` 152 | cf remove-network-policy SOURCE-APP DESTINATION-APP -s DESTINATION-SPACE-NAME -o DESTINATION-ORG-NAME --protocol PROTOCOL --port RANGE 153 | ``` 154 | 155 | Where: 156 | 157 | * `SOURCE-APP` is the name of the app that sends traffic. 158 | * `DESTINATION-APP` is the name of the app that receives traffic. 159 | * `DESTINATION-SPACE-NAME` is the space of the destination app. The default is the targeted space. 160 | * `DESTINATION-ORG-NAME` is the org of the destination app. The default is the targeted org. 161 | * `PROTOCOL` is either `tcp` or `udp`. 162 | * `PORTS` are the ports connecting the apps. The allowed range is from `1` to `65535`. You can specify a single port, such as `8080`, or a range of ports, such as `8080-8090`. 163 | 164 | The `remove-network-policy` command deletes the policy that allows the `frontend` app to communicate with the `backend` app over TCP on port 8080. Here is an example: 165 | 166 | 
167 | $ cf remove-network-policy frontend backend --protocol tcp --port 8080
168 | Removing network policy to app frontend in org my-org / space dev as admin...
169 | OK
170 |
171 | 172 | ### Deactivate network policy enforcement 173 | 174 | You can deactivate Silk network policy enforcement between apps. Deactivating network policy enforcement allows all apps to send network traffic to all other apps in the foundation despite no policy specifically allowing it. 175 | 176 | To deactivate network policy enforcement between apps: 177 | 178 | <% if vars.platform_code == "CF" %> 179 | 180 | 1. To target your BOSH deployment, run: 181 | 
182 |    bosh target -e MY-ENV -d MY-DEPLOYMENT
183 |
184 | Where: 185 | - `MY-ENV` is the alias you set for your BOSH Director. 186 | - `MY-DEPLOYMENT` is your deployment name. You can see your deployment name by running `bosh -e MY-ENV deployments`. 187 | 188 | 2. To download and save the BOSH manifest, run: 189 | 
190 |    bosh -e MY-ENV -d MY-DEPLOYMENT manifest > MY-MANIFEST.yml
191 |
192 | Where `MY-MANIFEST.yml` is the name you choose for the saved manifest. 193 | 194 | 3. In your BOSH manifest, change the `disable_container_network_policy` value to `false`. 195 | 196 | 4. To redeploy BOSH using the edited BOSH manifest, run: 197 | 
198 |    bosh -e MY-ENV -d MY-DEPLOYMENT deploy MY-MANIFEST.yml
199 |
200 | 201 | <% else %> 202 | 203 | <%= partial "/pcf/core/disable_network_policy_enforcement" %> 204 | 205 | <% end %> 206 | 207 | 208 | ## App service discovery 209 | 210 | With app service discovery, apps pushed to <%= vars.app_runtime_abbr %> can establish container-to-container communications through a known route served by internal BOSH DNS. This allows front end apps to easily connect with back end apps. 211 | 212 | <%= vars.internal_domain_config %> 213 | 214 | To establish container-to-container communications between a front end and back end app, a developer: 215 | 216 | 1. Runs a back end app that publishes a local endpoint. 217 | 1. Maps a named route to the endpoint. 218 | 1. Creates a network policy that allows direct traffic from the front end to the back end app. 219 | 1. Run the front end app. 220 | 221 | See [Cats and Dogs with Service Discovery](https://github.com/cloudfoundry/cf-networking-examples/blob/master/docs/c2c-with-service-discovery.md) in GitHub for an example, written in Go, that demonstrates communication between front end and back end apps. 222 | 223 | To use TLS developer adds a network policy for port 61443. After that the front end app can reach the back end app using HTTPS, `https://backend-app.apps.internal:61443`, for example. 224 | 225 | <% if vars.platform_code == "CF" %> 226 | 227 | ### Activate app service discovery 228 | 229 | To activate app service discovery, <%= vars.enable_c2c_discovery %>. 230 | 231 | <% end %> 232 | -------------------------------------------------------------------------------- /deploy-apps/cf-scale.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Scaling an app using Cloud Foundry CLI (cf scale) 3 | owner: CAPI 4 | --- 5 | 6 | 7 | 8 | Factors such as user load, or the number and nature of tasks performed by an app, can change the disk space and memory the app uses. 9 | This topic describes how to scale an app using the Cloud Foundry Command Line Interface (cf CLI). 10 | For many apps, increasing the available disk space or memory can improve overall performance. 11 | Similarly, running additional instances of an app can allow the app to handle increases in user load and concurrent requests. 12 | These adjustments are called "scaling" an app. 13 | 14 | Use [cf scale](http://cli.cloudfoundry.org/en-US/cf/scale.html) to scale your app up or down to meet changes in traffic 15 | or demand. 16 | 17 | <%=vars.autoscaler_note_dev_guide%> 18 | 19 | ## Scaling horizontally 20 | 21 | Horizontally scaling an app creates or destroys instances of your app. 22 | 23 | Incoming requests to your app are automatically load balanced across all 24 | instances of your app, and each instance handles tasks in parallel with 25 | every other instance. 26 | Adding more instances allows your app to handle increased traffic and 27 | demand. 28 | 29 | Use `cf scale APP -i INSTANCES` to horizontally scale your app. 30 | Cloud Foundry increases or decreases the number of instances of your app to match `INSTANCES`. 31 | 32 | 
33 | $ cf scale myApp -i 5
34 |
35 | 36 |

37 | In cf CLI v7+, you can also use --process with cf scale to scale specific processes of your app.

38 | 39 | ## Scaling vertically 40 | 41 | Vertically scaling an app changes the disk space limit or memory limit 42 | that Cloud Foundry applies to all instances of the app. 43 | 44 | Use `cf scale APP -k DISK` to change the disk space limit applied to all 45 | instances of your app. 46 | `DISK` must be an integer followed by either an **M**, for megabytes, or **G**, 47 | for gigabytes. 48 | 49 | 
50 | $ cf scale myApp -k 512M
51 |
52 | 53 | Use `cf scale APP -m MEMORY` to change the memory limit applied to all instances 54 | of your app. 55 | `MEMORY` must be an integer followed by either an **M**, for megabytes, or 56 | **G**, for gigabytes. 57 | 58 | 
59 | $ cf scale myApp -m 1G
60 |
61 | -------------------------------------------------------------------------------- /deploy-apps/healthchecks.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Using Cloud Foundry health checks 3 | owner: 4 | - CAPI 5 | - CLI 6 | --- 7 | 8 | <%= vars.app_runtime_abbr %> provides support for liveness and readiness health checks. 9 | 10 | Liveness health checks are performed to validate that app instances are running. 11 | When liveness health checks fail, the app instance is marked as crashed and is 12 | restarted. Readiness health checks are performed to validate that app instances are 13 | ready to serve requests. When readiness health checks fail, the app instance is 14 | marked as not ready and removed from the route pool for the app. 15 | 16 | You can configure a liveness health check for an app using the Cloud Foundry 17 | Command Line Interface (cf CLI) or by specifying a combination of the 18 | `health-check-http-endpoint`, `health-check-type`, 19 | `health-check-invocation-timeout`, and `health-check-interval` fields in an 20 | [app manifest](manifest.html). 21 | 22 | Readiness health checks are only configurable through the [app manifest](manifest-attributes.html#optional-attributes). 23 | To use readiness health checks, you must have: 24 | 25 | * garden-runc-release 1.37.0 26 | * diego-release 2.81.0 27 | * capi-release 1.158.0 28 | 29 | To configure a health check using the cf CLI, see: 30 | 31 | * [Configure health checks when creating or updating](#setting-health-checks) 32 | 33 | * [Configure health checks for an existing app](#set-health-checks-exist). 34 | 35 | For more information about using an app manifest to configure a health check, see these sections in _Deploying with app manifests_. 36 | 37 | * [health-check-type](manifest-attributes.html#health-check-type) 38 | * [health-check-interval](manifest-attributes.html#health-check-interval) 39 | * [health-check-http-endpoint](manifest-attributes.html#health-check-http-ep) 40 | * [health-check-invocation-timeout](manifest-attributes.html#health-check-invoc-time) 41 | 42 | * [readiness-health-check-type](manifest-attributes.html#readiness-health-check-type) 43 | * [readiness-health-check-interval](manifest-attributes.html#readiness-health-check-interval) 44 | * [readiness-health-check-http-endpoint](manifest-attributes.html#readiness-health-check-http-ep) 45 | * [readiness-health-check-invocation-timeout](manifest-attributes.html#readiness-health-check-invoc-time) 46 | 47 | App health checks function as part of the app life cycle managed by Diego architecture. For more 48 | information, see [Diego components and architecture](../../concepts/diego/diego-architecture.html). 49 | 50 | 51 | ## Configure liveness health checks when creating or updating an app 52 | 53 | To configure a health check while creating or updating an app, run: 54 | 55 | ``` 56 | cf push APP-NAME --health-check-type LIVENESS-HEALTH-CHECK-TYPE --app-start-timeout LIVENESS-HEALTH-CHECK-TIMEOUT 57 | ``` 58 | 59 | Where: 60 | 61 | * `APP-NAME` is the name of your app. 62 | 63 | * `LIVENESS-HEALTH-CHECK-TYPE` is the type of liveness health check that you want to configure. Valid health check 64 | types are `port`, `process`, and `http`. For more information, see [Health check types](#types). 65 | 66 | * `LIVENESS-HEALTH-CHECK-TIMEOUT` is the amount of time allowed to elapse between starting an app and the 67 | first healthy response. For more information, see [Health check timeouts](#health_check_timeout). 68 | 69 | For more information about the `cf push` command, see 70 | [push](http://cli.cloudfoundry.org/en-US/cf/push.html) in the Cloud Foundry CLI Reference Guide. 71 | 72 |

73 | The health check configuration that you provide with 74 | cf push overrides any configuration in the app manifest.

75 | 76 | 77 | ## Configure liveness health checks for an existing app 78 | 79 | To configure a liveness health check for an existing app or to add a custom HTTP endpoint, run: 80 | 81 | ``` 82 | cf set-health-check APP-NAME LIVENESS-HEALTH-CHECK-TYPE --endpoint CUSTOM-HTTP-ENDPOINT 83 | ``` 84 | 85 | Where: 86 | 87 | * `APP-NAME` is the name of your app. 88 | 89 | * `LIVENESS-HEALTH-CHECK-TYPE` is the type of the liveness health check that you want to configure. Valid health check types are `port`, `process`, and `http`. For more information, see [Health check types](#types). 90 | 91 | * `CUSTOM-HTTP-ENDPOINT` is the custom HTTP endpoint that you want to add to the health check. By default, an `http` health check uses `/` as its endpoint unless you specify a custom endpoint. For more information, see [Health check HTTP endpoints](#health_check_uri). 92 | 93 | You can also change the health check invocation timeout for 94 | an app, use cf set-health-check. This option also requires restarting the app. For more information, see Apps in the Cloud Foundry CLI Reference Guide. 95 | 96 | For more information about the `cf set-health-check` command, see 97 | [set-health-check](http://cli.cloudfoundry.org/en-US/cf/set-health-check.html) in 98 | the Cloud Foundry CLI Reference Guide. 99 | 100 |

101 | After you set the health check configuration of a deployed 102 | app with the cf set-health-check command, you must restart the app for the change to 103 | take effect.

104 | 105 | 106 | ## Understanding health checks 107 | 108 | ### Health check life cycle 109 | 110 | The following table describes how app health checks work. 111 | 112 | | Stage | Description | 113 | | ----- | ----------- | 114 | | 1 | When deploying the app to <%= vars.app_runtime_abbr %>, the developer specifies a liveness and/or a readiness health check, and optionally, a startup timeout with the app manifest. | 115 | | 2 | Cloud Controller creates an LRP for Diego with the specified health check definitions. If no liveness health check is provided, Cloud Controller configures a `port` liveness health check type. If no readiness health check is provided, Cloud Controller configures a `process` readiness health check type. | 116 | | 3 | When Diego starts an app instance, a separate startup app health check runs every 2 seconds until a response indicates that the app instance is healthy or until the startup timeout elapses. The startup health check uses the same configuration (type, http endpoint, and invocation timeout) as the liveness health check, except for the non-configurable 2-second polling interval. | 117 | | 4 | After the startup health check succeeds, the app instance is marked as Running and Diego begins performing the liveness and readiness health checks. Liveness and readiness health checks are run according to their configured health check interval, with a default of 30 seconds. | 118 | | 5 | After the readiness health check succeeds, the app instance route is advertised. | 119 | | 6 | The app instance is alive, marked as Running, and is routable. The app instance is fully operational. | 120 | | 7 | If the readiness health check fails, then the route to the app instance is removed. | 121 | | 8 | If the liveness health check fails, Diego considers that particular instance to be unhealthy. Diego stops and deletes the app instance, then reschedules a new app instance. This process of stopping and deleting the app instance is reported back to the Cloud Controller as a crash event. | 122 | | 9 | When an app instance fails, Diego immediately attempts to restart the app instance. After three failed restarts, <%= vars.app_runtime_abbr %> waits 30 seconds before attempting another restart. The wait time doubles each restart until the ninth restart, and remains at that duration until the 200th restart. After the 200th restart, <%= vars.app_runtime_abbr %> stops trying to restart the app instance. | 123 | 124 | ### Health check types 125 | 126 | The following table describes the types of health checks available for apps and recommended 127 | circumstances in which to use them: 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 150 | 151 | 152 | 153 | 154 | 158 | 159 | 160 | 161 | 162 | 164 | 165 |
Health check typeRecommended use caseExplanation
httpThe app can provide an HTTP 200 response.The http health check performs a GET request to the configured HTTP endpoint 140 | on the app's default port. When the health check receives an HTTP 200 response, 141 | the app is declared healthy. <%= vars.company_name %> recommends that you use the 142 | http health check type whenever possible. A healthy HTTP response ensures that the 143 | web app is ready to serve HTTP requests. The configured endpoint must respond within one second 144 | to be considered healthy.
145 |

146 | To prevent false 147 | negatives, use a dedicated endpoint for health checks where response time and result do not 148 | depend on business logic.

149 |
portThe app can receive TCP connections, including HTTP web apps.A health check makes a TCP connection to the port or ports configured for the app. For apps 155 | with multiple ports, a health check monitors each port. If you do not specify a health 156 | check type for your app, then monitoring uses a port health 157 | check by default. The TCP connection must be established within one second to be considered healthy.
processThe app does not support TCP connections. An example of such an app is a worker.For a process health check, Diego ensures that any process declared for the 163 | app stays running. If the process and all its children exit, Diego stops and deletes the app instance.
166 | 167 | ### Health check timeouts 168 | 169 | The startup timeout value configured for the app process is the amount of time 170 | allowed to elapse between starting an app and the first healthy response from 171 | the app. If the health check does not receive a healthy response within the 172 | configured timeout, then the app is declared unhealthy. 173 | 174 | <%= vars.app_healthcheck_timeout %> 175 | 176 | ### Health check HTTP endpoints 177 | 178 | Only used by `http` type, the `--endpoint` flag of the `cf set-health-check` command specifies the 179 | path portion of a URI that must be served by the app and return `HTTP 200` when the app is healthy. 180 | 181 | This command only checks the health of the default port of the app. 182 | 183 |

184 | For HTTP apps, <%= vars.company_name %> recommends setting the health check type to http instead of a simple port check.

185 | -------------------------------------------------------------------------------- /deploy-apps/index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Deploying apps 3 | owner: CAPI 4 | --- 5 | 6 | 7 | 8 | For information about app deployment, see [cf push](../push.html). 9 | 10 | -------------------------------------------------------------------------------- /deploy-apps/instance-identity.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Using Instance Identity credentials 3 | owner: Diego 4 | --- 5 | 6 | 7 | 8 | The Instance Identity system provides each app instance with a unique PEM-encoded [X.509](https://tools.ietf.org/html/rfc5280) certificate and [PKCS#1](https://tools.ietf.org/html/rfc3447) RSA private keypair that encodes its identity in the Cloud Foundry deployment. 9 | 10 | The environment variable `CF_INSTANCE_CERT` contains the absolute path to the certificate. The environment variable `CF_INSTANCE_KEY` contains the absolute path to the key file. The provided certificate has the following properties: 11 | 12 | - The `Common Name` property is set to the instance GUID for the given app instance. 13 | - The certificate contains an IP SAN set to the container IP address for the given app instance. 14 | - The certificate contains a DNS SAN set to the instance GUID for the given app instance. 15 | - The `Organizational Unit` property in the certificate's Subject Distinguished Name contains the values `organization:ORG-GUID`, `space:SPACE-GUID`, and `app:APP-GUID`. The `ORG-GUID`, `SPACE-GUID`, and `APP-GUID` are set to the GUIDs for the organization, space, and app as assigned by Cloud Controller. 16 | 17 | By default, the certificate is valid for 24 hours after the container is created. The Cloud Foundry platform operator can decrease this duration to as little as 1 hour by setting the `diego.executor.instance_identity_validity_period_in_hours` BOSH property. 18 | 19 | The Diego Cell rep supplies a new certificate and private keypair to the app instance before the end of the validity period. The new pair of files replaces the existing pair at the same path locations, with each file replaced atomically. 20 | 21 | * If the validity period exceeds 4 hours, the pair regenerates between 1 hour and 20 minutes before the end of the validity period. 22 | * If the validity period is less than or equal to 4 hours, the pair regenerates between 1/4 and 1/12 of the time to the end of the period. 23 | 24 | For more information about enabling and configuring the Instance Identity system in Cloud Foundry, see [Enabling Instance Identity](https://docs.cloudfoundry.org/adminguide/instance-identity.html). 25 | -------------------------------------------------------------------------------- /deploy-apps/large-app-deploy.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Deploying large apps 3 | owner: CAPI 4 | --- 5 | 6 | When you deploy apps larger than 750 MB to <%= vars.app_runtime_first %>, you must observe additional constraints and recommended settings. 7 | 8 | 9 | ## Deployment considerations and limitations 10 | 11 | Deployment involves uploading, staging, and starting the app. For more information about the default time limits for uploading, staging, and starting an app, see [Deployment](app-lifecycle.html#deployment) in _Application container life cycle_. 12 | 13 | To deploy large apps to <%= vars.app_runtime_abbr %>, ensure that: 14 | 15 | * The total size of the files to upload for your app does not exceed <%= vars.max_app_size %>. 16 | 17 | * Your network connection speed is sufficient to upload your app within the 15-minute limit. The minimum recommended speed is 874 KB per second. <%= vars.app_runtime_abbr %> provides an authorization token that is valid for a minimum of 20 minutes. 18 | 19 | * You allocate enough memory for all instances of your app. Use either the `-m` flag with `cf push` or set an app memory value in your `manifest.yml` file. 20 | 21 | * You allocate enough disk space for all instances of your app. Use either the `-k` flag with `cf push` or set a disk space allocation value in your `manifest.yml` file. 22 | 23 | * You allocate enough log quota for all instances of your app. Use either the `-l` flag with `cf push` or set a log rate limit in your `manifest.yml` file. 24 | 25 | * If you use an app manifest file, `manifest.yml`, specify adequate values for your app for attributes such as app memory, app start timeout, and disk space allocation. For more information about using app manifests, see [Deploying with app manifests](manifest.html). 26 | 27 | * The size of each environment variable for your app does not exceed 130 KB. This includes <%= vars.app_runtime_abbr %> system environment variables such as `VCAP_SERVICES` and `VCAP_APPLICATION`. For more information, see [<%= vars.app_runtime_abbr %> environment variables](environment-variable.html). 28 | 29 | * If VCAP_SERVICES gets too large, either because of too many service bindings or too much data provided by the services, review the other two [Credential Delivery Methods](../services/application-binding.html#credential-delivery-methods); both of these have a limit of 1 MB. 30 | 31 | * You push only the files that are necessary for your app. To meet this requirement, push only the directory for your app, and remove unneeded files or use the `.cfignore` file to specify excluded files. For more information about specifying excluded files, see [Ignore unnecessary files when pushing](prepare-to-deploy.html#exclude) in _Considerations for Designing and Running an App in the Cloud_. 32 | 33 | * You configure Cloud Foundry Command Line Interface (cf CLI) staging, startup, and timeout settings to override settings in the manifest, as necessary: 34 | * `CF_STAGING_TIMEOUT`: The maximum time in minutes that the cf CLI waits for an app to stage after <%= vars.app_runtime_abbr %> uploads and 35 | packages the app. 36 | * `CF_STARTUP_TIMEOUT`: The maximum time in minutes that the cf CLI waits for an app to start 37 | * `cf push -t TIMEOUT`: The maximum time in seconds that <%= vars.app_runtime_abbr %> allows to elapse between starting an app and the first healthy response from the app. When you use this flag, the cf CLI ignores any app start timeout value set in the manifest. 38 | 39 | For more information about using the cf CLI to deploy apps, see [Push](../../cf-cli/getting-started.html#push) in _Getting Started with the cf CLI_. 40 | 41 |

42 | Changing the timeout setting for the cf CLI does not change the timeout limit for <%= vars.app_runtime_abbr %> 43 | server-side jobs such as staging or starting apps. You must change server-side timeouts in the manifest. Because of the differences between the 44 | <%= vars.app_runtime_abbr %> and cf CLI timeout values, your app might start even though the cf CLI reports App failed. To review the status of your app, run cf apps APP-NAME, where APP-NAME is the name of your app.

45 | 46 | 47 | ## Default settings and limitations summary 48 | 49 | The following table provides a summary of the constraints and default settings to consider when you deploy a large app to <%= vars.app_runtime_abbr %>: 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 69 | 70 | 71 | 72 | 75 | 76 | 77 | 78 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 |
SettingNote
App package sizeMaximum: <%= vars.max_app_size_table %>
Authorization token grace periodDefault: 20 minutes, minimum
CF_STAGING_TIMEOUTcf CLI environment variable 67 |
68 | Default: 15 minutes
CF_STARTUP_TIMEOUTcf CLI environment variable 73 |
74 | Default: 5 minutes
cf push -t TIMEOUTApp start timeout maximum 79 |
80 | Default: 60 seconds
Disk space allocationDefault: 1024 MB
Internet connection speedRecommended minimum: 874 KB per second
91 | -------------------------------------------------------------------------------- /deploy-apps/manifest.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Deploying with app manifests 3 | owner: 4 | - CAPI 5 | - CLI 6 | --- 7 | 8 | 9 | 10 | App manifests provide consistency and reproducibility, and can help you automate deploying apps. This topic provides basic procedures and guidance for deploying apps with a manifest file to <%= vars.app_runtime_first %>. 11 | Both manifests and command line options allow you to override the default attribute values of `cf push`. These attributes include the number of app instances, disk space limit, memory limit, and log rate limit. 12 | 13 | `cf push` follows rules of precedence when setting attribute values: 14 | 15 | * Manifests override most recent values, including defaults and values set by commands such as `cf scale`. 16 | 17 | * Command line options override manifests. 18 | 19 | * The manifest configuration is additive and will not modify any unspecified properties or remove any existing environment variables, routes, or services. 20 | 21 | For a full list of attributes you can specify in an app manifest, see [App manifest attribute reference](manifest-attributes.html). 22 | 23 | 24 | ## Deploy an app with a manifest 25 | 26 | To deploy an app with a manifest: 27 | 28 | 1. Create a `manifest.yml` file in the root directory of your app. By default, the cf push command uses the manifest.yml file in the app directory. To specify a different location for the manifest, pass its local path to the -f flag when you run cf push. 29 | 30 | 1. Add the following content to the file: 31 | 32 | ``` 33 | --- 34 | applications: 35 | - name: APP-NAME 36 | ``` 37 | Where `APP-NAME` is the name of your app. 38 | 39 | 2. Run: 40 | 41 | ``` 42 | cf push 43 | ``` 44 | If you specify any values with command-line flags, they override the values specified in the manifest. For more information, see [Deploy multiple apps with one manifest](#multi-apps). 45 | 46 | For more information about manifest format and attributes, see [App manifest attribute reference](manifest-attributes.html). 47 | 48 | 49 | ## Deploy multiple apps with one manifest 50 | 51 | This section describes how to deploy multiple apps with a minimal manifest. For more information about manifest format and attributes, see [App manifest attribute reference](manifest-attributes.html). 52 | 53 | ### General rules 54 | 55 | Follow these general rules when deploying multiple apps with one manifest: 56 | 57 | * Use a `no-route` line in the description of any app that provides background services to another app. 58 | 59 | * You cannot use any command line options with `cf push` except for `-f` and `--no-start`. 60 | * If your manifest is not named `manifest.yml` or not in the current working directory, use the `-f` command line option. 61 | 62 | * To push a single app rather than all of the apps described in the manifest, provide the app name by running `cf push APP-NAME`, where `APP-NAME` is the name of your app. 63 | 64 | * Each app must be in a subdirectory under the same parent directory. 65 | 66 | ### Procedure 67 | 68 | To deploy multiple apps with a manifest: 69 | 70 | 1. Create a `manifest.yml` file in the directory that contains the apps. 71 | 72 | 2. Add each app and its directory to the file. <%= vars.app_runtime_abbr %> pushes the apps in the order specified in the manifest. If you push multiple apps using a manifest and one fails to deploy, <%= vars.app_runtime_abbr %> does not attempt to push apps specified after the app that failed. 73 | 74 | ``` 75 | --- 76 | applications: 77 | - name: APP-ONE 78 | path: ./APP-ONE-DIRECTORY 79 | - name: APP-TWO 80 | path: ./APP-TWO-DIRECTORY 81 | ``` 82 | 83 | Where: 84 | 90 | 91 | 1. From the directory that contains the apps and the manifest, run: 92 | 93 | ``` 94 | cf push 95 | ``` 96 | -------------------------------------------------------------------------------- /deploy-apps/prepare-to-deploy.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Designing and running your app in the cloud 3 | owner: CAPI 4 | --- 5 | 6 | 7 | These are best practices for developing modern apps for cloud platforms. For more detailed reading about good app design for the cloud, see [The Twelve-Factor App](http://www.12factor.net). 8 | 9 | Following these guidelines facilitates app deployment to <%= vars.platform_name %> and other cloud platforms, and apps written in supported frameworks often run unmodified. 10 | 11 | For more information about the features of HTTP routing handled by the Gorouter in <%= vars.platform_name %>, 12 | see [HTTP routing](../../concepts/http-routing.html). 13 | For more information about the life cycle of application containers, see [Application container life cycle](app-lifecycle.html). 14 | 15 | ## Avoid writing to the local file system 16 | 17 | Apps running on <%= vars.platform_name %> must not write files to the local file system because: 18 | 19 | * **Local file system storage is short-lived.** When an app instance fails or stops, the resources assigned to that instance are reclaimed by the platform, including any local disk changes made since the app started. When the instance is restarted, the app starts with a new disk image. Although your app can write local files while it is running, the files disappear after the app restarts. 20 | 21 | * **Instances of the same app do not share a local file system.** Each app instance runs 22 | in its own isolated container. 23 | Therefore, a file written by one instance is not visible to other instances of the same app. 24 | If the files are temporary, this is not be a problem. 25 | However, if your app needs the data in the files to persist across app restarts, 26 | or the data must be shared across all running instances of the app, 27 | the local file system must not be used. <%= vars.company_name %> recommends 28 | using a shared data service like a database or blobstore for this purpose. 29 | 30 | For example, instead of using the local file system, you can use a <%= vars.platform_name %> service 31 | such as the MongoDB document database or a relational database like MySQL or PostgreSQL. 32 | Another option is to use cloud storage providers such as [Amazon S3](http://aws.amazon.com/s3/), 33 | [Google Cloud Storage](https://cloud.google.com/products/cloud-storage), 34 | [Dropbox](https://www.dropbox.com/developers), or [Box](http://developers.box.com/). 35 | If your app must communicate across different instances of itself, 36 | consider a cache like Redis or a messaging-based architecture with RabbitMQ. 37 | 38 | If you must use a file system for your app because, for example, your app interacts 39 | with other apps through a network attached file system or because your app is based on legacy code 40 | that you cannot rewrite, consider using volume services to bind a network attached file system to your app. 41 | For more information, see [Using an external file system (volume services)](../services/using-vol-services.html). 42 | 43 | ## Cookies accessible across apps 44 | 45 | In an environment with shared domains, cookies might be accessible across apps. 46 | 47 | Many tracking tools such as Google Analytics and Mixpanel use the highest available domain to set their cookies. 48 | For an app using a shared domain such as `example.com`, a cookie set to use the highest domain has a `Domain` attribute of `.example.com` in its HTTP response header. 49 | For example, an app at `my-app.<%= vars.app_domain %>` might be able to access the cookies for an app at `your-app.<%= vars.app_domain %>`. 50 | 51 | You must decide whether you want your apps or tools that use cookies to set and store the cookies at the highest available domain. 52 | 53 | ## Port considerations 54 | 55 | Clients connect to apps running on <%= vars.platform_name %> by making requests to URLs associated with the app. 56 | <%= vars.platform_name %> allows HTTP requests to apps on ports 80 and 443. 57 | For more information, see [Routes and domains](routes-domains.html). 58 | 59 | <%= vars.platform_name %> also supports WebSocket handshake requests over HTTP containing the `Upgrade` header. 60 | The <%= vars.platform_name %> router handles the upgrade and initiates a TCP connection 61 | to the app to form a WebSocket connection. 62 | 63 | <%= vars.port_limitations %> 64 | 65 | ## <%= vars.platform_name %> updates and your app 66 | 67 | For app management purposes, <%= vars.platform_name %> might need to stop and restart your app instances. 68 | If this occurs, <%= vars.platform_name %> performs the following steps: 69 | 70 | 1. <%= vars.platform_name %> sends a single `termination signal` to the root process 71 | that your start command runs. 72 | 73 | 1. <%= vars.platform_name %> waits 10 seconds to allow your app to cleanly shut down any child processes 74 | and handle any open connections. 75 | 76 | 1. After 10 seconds, <%= vars.platform_name %> shuts down your app. 77 | 78 | Your app must accept and handle the termination signal to ensure that it shuts down gracefully. To achieve this, the app is expected to do these steps when shutting down: 79 | 80 | 1. App receives termination signal 81 | 1. App closes listener so that it stops accepting new connections 82 | 1. App finishes serving in-flight requests 83 | 1. App closes existing connections as their requests complete 84 | 1. App is stopped or shut down 85 | 86 | For an implementation of the expected shutdown behavior in Golang, see the [Sample HTTP App](https://github.com/cloudfoundry/sample-http-app) repository on GitHub. 87 | 88 | 89 | ## Ignore unnecessary files when pushing 90 | 91 | By default, when you push an app, all files in the app's project directory tree are uploaded 92 | to your <%= vars.platform_name %> instance, except version control and configuration files 93 | or directories with these names: 94 | 95 | * `.cfignore` 96 | * `_darcs` 97 | * `.DS_Store` 98 | * `.git` 99 | * `.gitignore` 100 | * `.hg` 101 | * `manifest.yml` 102 | * `.svn` 103 | 104 | In addition to these, if API request diagnostics are directed to a log file and the file is within the project directory tree, it is excluded from the upload. You can direct these API request diagnostics to a log file using `cf config --trace` or the `CF_TRACE` environment variable. 105 | 106 | If the app directory contains other files, such as `temp` or `log` files, or complete subdirectories that are not required to build and run your app, you might want to add them to a `.cfignore` file to exclude them from upload. Especially with a large app, uploading unnecessary files can slow app deployment. 107 | 108 | To use a `.cfignore` file, create a text file named `.cfignore` in the root of your app directory structure. In this file, specify the files or file types you wish to exclude from upload. For example, these lines in a `.cfignore` file exclude the "tmp" and "log" directories. 109 | 110 | 
111 |     tmp
112 |     log
113 |
114 | 115 | The file types you might want to exclude vary, based on the app frameworks you use. For examples of commonly-used `.gitignore` files, see the [gitignore](https://github.com/github/gitignore) repository on GitHub. 116 | 117 | 118 | ## Run multiple instances to increase availability 119 | 120 | Singleton apps might become temporarily unavailable for reasons that include: 121 | 122 | * During an upgrade, <%= vars.platform_name %> gracefully shuts down the apps running on each Diego Cell 123 | and restarts them on another Diego Cell. Single app instances might become temporarily unavailable if the replacement instance does not become healthy within the Diego Cell's evacuation timeout. The default timeout is 10 minutes. 124 | 125 | * Unexpected faults in <%= vars.platform_name %> system components or underlying infrastructure, 126 | such as container-host VMs or IaaS availability zones, might cause lone app instances to disappear 127 | or become unroutable for a minute or two. 128 | 129 | To avoid the risk of an app becoming temporarily unavailable, developers can run more than one instance of the app. 130 | 131 | 132 | ## Using buildpacks 133 | 134 | A buildpack consists of bundles of detection and configuration scripts that provide framework 135 | and runtime support for your apps. 136 | When you deploy an app that requires a buildpack, <%= vars.platform_name %> installs the buildpack 137 | on the Diego Cell where the app runs. 138 | 139 | For more information, see [Buildpacks](../../buildpacks/index.html). 140 | -------------------------------------------------------------------------------- /deploy-apps/ssh-services.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Accessing services with SSH 3 | owner: Core Services 4 | --- 5 | 6 | 7 | 8 | You can gain direct command line access to your deployed service instance using SSH. This allows you to, for example, access your database to run raw SQL commands to edit the schema, import and export data, or debug app data issues. 9 | 10 | To establish direct command line access to a service, you deploy a host app and use its SSH and port forwarding features to communicate with the service instance through the application container. The technique described here works with TCP services such as MySQL or Redis. 11 | 12 | _This topic requires Cloud Foundry Command Line Interface (cf CLI) v6.15.0 or later, but at least v7 is recommended._ 13 | 14 | <%= vars.mutual_tls_ssh %> 15 | 16 |

17 | The procedure in this topic requires use of a service key, and not all services support service keys. Some services support credentials through app binding only.

18 | 19 | 20 | ## Create a service instance 21 | 22 | 1. In your terminal window, log in to your deployment with `cf login`. 23 | 24 | 1. <%= vars.ssh_marketplace_step %> 25 | 26 | 
 27 |     $ cf marketplace
 28 |     <%=vars.ssh_marketplace_output %>
 29 |
30 | 31 | 1. Create your service instance. As part of the [create-service](http://cli.cloudfoundry.org/en-US/cf/create-service.html) command, indicate the service name, the service plan, and the name you choose for your service instance. 32 | 33 | 
 34 |     $ cf create-service <%=vars.ssh_service %> <%=vars.ssh_service_plan %> MY-DB
 35 |
36 | 37 | ##Push your host app 38 | 39 | To push an app that acts as the host for the SSH tunnel, push any app that is deployed to <%= vars.app_runtime_full %>. 40 | Your app must be prepared before you push it. See Pushing an app for details about preparing apps for pushing. 41 | 42 | 1. Push your app: 43 | 44 | ```console 45 | cf push YOUR-HOST-APP 46 | ``` 47 | 48 | 2. Activate SSH for your app: 49 | 50 | ```console 51 | cf enable-ssh YOUR-HOST-APP 52 | ``` 53 | 54 | To activate SSH access to your app, SSH access must also be activated for both the space that contains the app and <%= vars.app_runtime_full %>. For more information, see App SSH Overview. 55 | 56 | ##Create your service key 57 | 58 | To establish SSH access to your service instance, you must create a service key that contains critical information for configuring your SSH tunnel. 59 | 60 | 1. Create a service key for your service instance using the [cf create-service-key](http://cli.cloudfoundry.org/en-US/cf/create-service-key.html) command. 61 | 62 | ```console 63 | cf create-service-key MY-DB EXTERNAL-ACCESS-KEY 64 | ``` 65 | 66 | 1. Retrieve your new service key using the [cf service-key](http://cli.cloudfoundry.org/en-US/cf/service-key.html) command. 67 | 68 | ```console 69 | cf service-key MY-DB EXTERNAL-ACCESS-KEY 70 | ``` 71 | 72 | For example: 73 | 74 | 
 75 |     $ cf service-key MY-DB EXTERNAL-ACCESS-KEY
 76 |     Getting key EXTERNAL-ACCESS-KEY for service instance MY-DB as user@example.com
 77 |     <%= vars.ssh_service_access_key %>
 78 |
79 | 80 | 81 | ## Configure your SSH tunnel 82 | 83 | Configure an SSH tunnel to your service instance using [cf ssh](http://cli.cloudfoundry.org/en-US/cf/ssh.html). Tailor the following example command with information from your service key. 84 | 
$ cf ssh -L 63306:<%= vars.ssh_service_host %>:3306 YOUR-HOST-APP
85 | 86 | * You can use any available local port for port forwarding; for example, `63306`. 87 | * `<%= vars.ssh_service_host %>` is the address provided under `hostname` in the service key retrieved earlier. 88 | * `3306` is the port provided under `port`. 89 | * `YOUR-HOST-APP` is the name of your host app. 90 | 91 | After you enter the command, open another terminal and follow the steps in [Access your service instance](#access-service). 92 | 93 | 94 | ## Access your service instance 95 | 96 | To establish direct command line access to your service instance, use the relevant command line tool for that service. This example uses the MySQL command line client to access the <%= vars.ssh_service %> service instance. 97 | 98 | 
 99 | $ mysql -u b5136e448be920 -h 0 -p -D ad_b2fca6t49704585d -P 63306
100 |
101 | 102 | * Replace `b5136e448be920` with the user name provided under `username` in your service key. 103 | * `-h 0` instructs `mysql` to connect to your local machine (use `-h 127.0.0.1` for Windows). 104 | * `-p` instructs `mysql` to prompt for a password. When prompted, use the password provided under `password` in your service key. 105 | * Replace `ad_b2fca6t49704585d` with the database name provided under `name` in your service key. 106 | * `-P 63306` instructs `mysql` to connect on port `63306`. 107 | -------------------------------------------------------------------------------- /deploy-apps/stacks.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Changing stacks 3 | owner: 4 | - Buildpacks & Stacks 5 | - Diego 6 | - Runtime OG 7 | --- 8 | 9 | 10 | 11 | You can restage apps on a new stack. Here is a description of stacks and lists of stacks that are supported on <%= vars.current_major_version ? "#{vars.app_runtime_full} v#{vars.current_major_version}" : vars.app_runtime_full %>. 12 | 13 | To restage a Windows app on a new Windows stack, see [Changing Windows stacks](./windows-stacks.html). 14 | 15 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 16 | You can also use the Stack Auditor plug-in for the Cloud Foundry Command Line Interface (cf CLI) when changing stacks. See [Using the Stack Auditor plug-in](../../adminguide/stack-auditor.html). 17 | <% else %> 18 | <% end %> 19 | 20 | ## Overview 21 | 22 | A stack is a prebuilt root file system (rootfs) that supports a specific operating system. For example, Linux-based systems need `/usr` and `/bin` directories at their root. The stack works in tandem with a buildpack to support apps running in compartments. Under Diego architecture, cell VMs can support multiple stacks. 23 | 24 |

25 | Docker apps do not use stacks.

26 | 27 | 28 | ## Available stacks 29 | 30 | <%= vars.product_short %> <%= vars.current_major_version ? "v#{vars.current_major_version}" : "" %> includes support for `cflinuxfs3`. The Linux `cflinuxfs3` stack is derived from Ubuntu Bionic 18.04. For more information about supported libraries, see the [GitHub stacks page](https://github.com/cloudfoundry/cflinuxfs3/blob/main/receipt.cflinuxfs3.x86_64). 31 | 32 | The latest versions of <%= vars.product_short %> include support for `cflinuxfs4` which is derived from Ubuntu 22.04 LTS (Jammy Jellyfish). For more information, see [GitHub cflinuxfs4 stack receipt](https://github.com/cloudfoundry/cflinuxfs4/blob/main/receipt.cflinuxfs4.x86_64). 33 | 34 | <%= vars.custom_stack %> 35 | 36 | 37 | ## Restaging apps on a new stack 38 | 39 | For security, stacks receive regular updates to address Common Vulnerabilities and Exposures ([CVEs](http://www.ubuntu.com/usn/)). Apps pick up on these stack changes through new releases of <%= vars.product_short %>. However, if your app links statically to a library provided in the rootfs, you might have to manually restage it to pick up the changes. 40 | 41 | It can be difficult to know what libraries an app statically links to, and it depends on the languages you are using. One example is an app that uses a Ruby or Python binary, and links out to part of the C standard library. If the C library requires an update, you might need to recompile the app and restage it. 42 | 43 | To restage an app on a new stack: 44 | 45 | 1. Use the `cf stacks` command to list the stacks available in a deployment. 46 | 47 | 
48 |     $ cf stacks
49 |     Getting stacks in org MY-ORG / space development as developer@example.com...
50 |     OK
51 | 
52 |     name         description
53 |     cflinuxfs3   Cloud Foundry Linux-based filesystem (Ubuntu 18.04)
54 |     cflinuxfs4   Cloud Foundry Linux-based filesystem (Ubuntu 22.04)
55 |
56 | 57 | 2. To change your stack and restage your app, run: 58 | 59 | ``` 60 | cf push MY-APP -s STACK-NAME 61 | ``` 62 | 63 | Where: 64 | - MY-APP is the name of the app. 65 | - STACK-NAME is the name of the new stack. 66 | 67 | For example, to restage your app on the stack `cflinuxfs4`, run `cf push MY-APP -s cflinuxfs4`: 68 | 
69 |         $ cf push MY-APP -s cflinuxfs4
70 |         Using stack cflinuxfs4...
71 |         OK
72 |         Creating app MY-APP in org MY-ORG / space development as developer@example.com...
73 |         OK
74 |         ...
75 |         requested state: started
76 |         instances: 1/1
77 |         usage: 1G x 1 instances
78 |         urls: MY-APP.cfapps.io
79 |         last uploaded: Wed 17 Jul 22:57:04 UTC 2024
80 |             state     since                  cpu    memory        disk           logging         cpu entitlement   details
81 |         \#0  running   2024-07-17T22:57:22Z   0.3%   49.5M of 1G   130.2M of 1G   0B/s of 16K/s   2.4%
82 |
83 | 84 | 85 | ## Stacks API 86 | 87 | For API information, see the _Stacks_ section of the [Cloud Foundry API Documentation](https://v3-apidocs.cloudfoundry.org/). 88 | -------------------------------------------------------------------------------- /deploy-apps/start-restart-restage.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Starting, restarting, and restaging your apps 3 | owner: CLI 4 | --- 5 | 6 | You can start, restart, and restage apps in Cloud Foundry, using the cf CLI or the app manifest (attributes in a YAML file). 7 | 8 | 9 | ##Start your app 10 | 11 | To start your app, run the following command from your app root directory: 12 | 13 | 
$ cf push YOUR-APP
14 | 15 | For more information about pushing apps, see [Pushing an app](deploy-app.html). 16 | 17 | Cloud Foundry determines the start command for your app from one of these three sources: 18 | 19 | * The `-c` command-line option in the Cloud Foundry Command Line Interface (cf CLI). For example: 20 | 21 | 
$ cf push YOUR-APP -c "node YOUR-APP.js"
22 | 23 | * The `command` attribute in the app manifest. For example: 24 | 25 | ```yaml 26 | command: node YOUR-APP.js 27 | ``` 28 | 29 | * The buildpack, which provides a start command appropriate for a particular type of app. 30 | 31 | The source that Cloud Foundry uses depends on factors that are explained in the next section. 32 | 33 | ###How Cloud Foundry determines its default start command 34 | 35 | The first time you deploy an app, `cf push` uses the buildpack start command by default. 36 | After that, `cf push` defaults to whatever start command was used for the previous push. 37 | 38 | To override these defaults, provide the `-c` option, or the command attribute in the manifest. 39 | When you provide start commands both at the command line and in the manifest, `cf push` ignores the command in the manifest. 40 | 41 | ###Forcing Cloud Foundry to use the buildpack start command 42 | 43 | To force Cloud Foundry to use the buildpack start command, specify a start command of `null`. 44 | 45 | You can specify a null start command in one of two ways. 46 | 47 | * Using the `-c` command-line option in the cf CLI: 48 | 49 | 
$ cf push YOUR-APP -c "null"
50 | 51 | * Using the `command` attribute in the app manifest: 52 | 53 | ```console 54 | command: null 55 | ``` 56 | 57 | This can be helpful after you have deployed while providing a start command at the command line or the manifest. 58 | Now a command that you provided, rather than the buildpack start command, has become the default start command. 59 | In this situation, if you decide to deploy using the buildpack start command, the `null` command simplifies that. 60 | 61 | ###Start commands when migrating a database 62 | 63 | Start commands are used in special ways when you migrate a database as part of an app deployment. For more information, see [Services overview](../../devguide/services/index.html#migrating). 64 | 65 | ##Restart your app 66 | 67 | To restart your app, run: 68 | 69 | 
$ cf restart YOUR-APP
70 | 71 | Restarting your app stops your app and restarts it with the already compiled droplet. A droplet is a tarball that includes: 72 | 73 | * stack 74 | * [buildpack](../../buildpacks/index.html) 75 | * app source code 76 | 77 | The Diego [cell](../../concepts/architecture/index.html#diego-cell) unpacks, compiles, and runs a droplet on a container. 78 | 79 | Restart your app to refresh the app's environment after actions such as binding a new service to the app or setting an environment variable that only the app consumes. However, if your environment variable is consumed by the buildpack in addition to the app, then you must [restage](#restage) the app for the change to take effect. 80 | 81 | ##Restage your app 82 | 83 | To restage your app, run: 84 | 85 | 
$ cf restage YOUR-APP
86 | 87 | Restaging your app stops your app and restages it, by compiling a new droplet and starting it. 88 | 89 | Restage your app if you have changed the environment in a way that affects your staging process, such as setting an environment variable that the buildpack consumes. Staging has access to environment variables, so the environment can affect the contents of the droplet. You must also restage your app whenever you edit any configuration settings, such as when you rename it, add metadata, or configure health checks. The new settings often do not take effect until you restage the app. 90 | 91 | Restaging your app compiles a new droplet from your app without updating your app source. If you must update your app source, re-push your app by following the steps in [Start your app](#start). 92 | -------------------------------------------------------------------------------- /deploy-apps/stop-delete.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Stopping and deleting your apps 3 | owner: CLI 4 | --- 5 | 6 | 7 | You can stop and delete your apps using Cloud Foundry CLI commands. 8 | 9 | To run the commands shown here, you must first install the Cloud Foundry Command Line Interface (cf CLI). See the [Cloud Foundry Command Line Interface](../../cf-cli/index.html) topics for more information. 10 | 11 | ## Stop and start an app 12 | 13 | You can stop an app for many reasons. For example, stopping an app frees the memory from your quota. 14 | 15 | To stop an app, run `cf stop APP-NAME`. Replace `APP-NAME` with the name of the app you want to stop. 16 | 17 | Example: 18 | 
$ cf stop my-example-app
19 | 20 | Running this commands stops the app, but databases and other provisioned services still run and consume resources. Users visiting the URL of a stopped app see a `404` error message like this one: 21 | 22 | `404 Not Found: Requested route ('my-example-app.example.com') does not exist.` 23 | 24 | To start an app, run `cf start APP-NAME`. Replace `APP-NAME` with the name of the app you want to stop. 25 | 26 | Example: 27 | 
$ cf start my-example-app
28 | 29 | ## Delete an app 30 | 31 |

32 | Deleting an app is irreversible. We recommend that you run cf target before you start to confirm you are deleting the app from the correct org and space.

33 | 34 | Many apps use services and routes. Deleting an app does not delete the services used by the app, and you must explicitly remove routes between your app and the Internet. 35 | 36 | ## Delete an app with services 37 | 38 | To delete an app with the services you provisioned for it, delete the services first. 39 | 40 | 1. Run `cf services` to view all active services in the current space. 41 | 42 | 1. Examine the list to verify which services are bound to your app. Record the name of the service instance bound to the app. If the list shows a service instance bound to any apps besides the app you want to delete, do not delete the service instance. If you delete a service instance bound to more than one app, you deletes the service instance from all of those apps. 43 | 44 | 1. Run `cf delete-service SERVICE-INSTANCE` to delete the service instance. Replace `SERVICE-INSTANCE` with the name of the service instance bound to your app. 45 | 46 | Example: 47 | 
$ cf delete-service my-example-service-instance
48 | 49 | ## Delete an app with no services 50 | 51 | To delete an app with no services, run `cf delete -r APP-NAME`. Replace `APP-NAME` with the name of the app. The `-r` option instructs the cf CLI to removes routes associated with the app. 52 | 53 | Example: 54 | 
$ cf delete -r my-example-app
55 | 56 |

57 | In cf CLI v7+, -r no longer deletes routes when the route is mapped to more than one app.

58 | 59 | If you delete an app without the `r` option, you can delete the route manually. 60 | 61 | Use the following steps to delete the route for an app manually. 62 | 63 | 1. Run `cf routes` to confirm the details of the orphaned route. The `cf routes` command returns a list of all active routes in the current space. This list includes the space, host name, domain, path, and any bound apps or services. 64 | 65 | 2. Find the orphaned route in the list. The orphaned route displays as a host name without an associated app. 66 | 67 | 3. Run `cf delete-route DOMAIN-NAME --hostname HOSTNAME` to delete the orphaned route. Replace `DOMAIN-NAME` and `HOSTNAME` with the domain and host name of the app you deleted. 68 | 69 | Example: 70 | 
$ cf delete-route my-domain.com --hostname my-example-app
71 | -------------------------------------------------------------------------------- /deploy-apps/trusted-system-certificates.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Trusted system certificates 3 | --- 4 | 5 | As a <%= vars.platform_name %> admin, you can deploy a set of trusted system certificates. These trusted certificates are available in Linux-based app instances running on the Diego back end. Such instances include buildpack-based apps using the `cflinuxfs[3|4]` stack and Docker image-based apps. 6 | 7 | If the admin configures these certificates, they are available inside the instance containers as files with extension `.crt` in the read-only `/etc/cf-system-certificates` directory. 8 | 9 | For `cflinuxfs[3|4]`-based apps, these certificates are also installed directly in the `/etc/ssl/certs` directory, and are available to libraries such as `openssl` that respect that trust store. If the administrator configure these certificates, the location of the certificates is provided in the environment variable `CF_SYSTEM_CERT_PATH` on the instance container. 10 | -------------------------------------------------------------------------------- /deploy-apps/windows-stacks.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Restaging your apps on a Windows stack 3 | owner: 4 | - Buildpacks 5 | - Windows 6 | --- 7 | 8 | 9 | This topic explains how you can restage apps on a new Windows stack. It also describes what stacks are and lists the supported Windows stacks on <%= vars.current_major_version ? "#{vars.windows_runtime_full} v#{vars.current_major_version}" : vars.windows_runtime_full %>. 10 | 11 | To restage a Windows app on a new Linux stack, see [Changing stacks](./stacks.html). 12 | 13 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 14 | You can also use the Stack Auditor plug-in for the Cloud Foundry Command Line Interface (cf CLI) when changing stacks. See [Using the Stack Auditor plug-in](../../adminguide/stack-auditor.html). 15 | <% else %> 16 | <% end %> 17 | 18 | ## Overview 19 | 20 | A stack is a prebuilt root file system (rootfs) that supports a specific operating system. For example, Linux-based systems need `/usr` and `/bin` directories at their root and Windows needs `/windows`. The stack works in tandem with a buildpack to support apps running in compartments. Under Diego architecture, cell VMs can support multiple stacks. 21 | 22 |

23 | Docker apps do not use stacks.

24 | 25 | ## Available stacks 26 | 27 | If you push your <%= vars.windows_runtime_abbr %> <%= vars.current_major_version ? "v#{vars.current_major_version}" : "" %> app to a Windows stack, you must use `windows`. 28 | The `windows2016` stack is not supported on <%= vars.windows_runtime_abbr %>. 29 | 30 | ## Restaging apps on a new stack 31 | 32 | For security, stacks receive regular updates to address Common Vulnerabilities and Exposures ([CVEs](http://www.ubuntu.com/usn/)). Apps pick up on these stack changes through new releases of <%= vars.windows_runtime_abbr %>. However, if your app links statically to a library provided in the rootfs, you have to manually restage it to pick up the changes. 33 | 34 | It can be difficult to know what libraries an app statically links to, and it depends on the languages you are using. One example is an app that uses a Ruby or Python binary, and links out to part of the C standard library. If the C library requires an update, you might need to recompile the app and restage it. 35 | 36 | To restage an app on a new stack: 37 | 38 | 1. Use the `cf stacks` command to list the stacks available in a deployment. 39 | 40 | 
41 |     $ cf stacks
42 |     Getting stacks in org MY-ORG / space development as developer@example.com...
43 |     OK
44 | 
45 |     name            description
46 |     windows2016     Windows Server 2016
47 |     windows         Windows Server
48 |
49 | 50 | 2. To change your stack and restage your app, run: 51 | 52 | ``` 53 | cf push MY-APP -s STACK-NAME 54 | ``` 55 | 56 | Where: 57 | - MY-APP is the name of the app. 58 | - STACK-NAME is the name of the new stack. 59 | 60 | For example, to restage your app on the `windows` stack, run `cf push MY-APP -s windows`: 61 | 
62 |     $ cf push MY-APP -s windows
63 |     Using stack windows...
64 |     OK
65 |     Creating app MY-APP in org MY-ORG / space development as developer@example.com...
66 |     OK
67 |     ...
68 |     requested state: started
69 |     instances: 1/1
70 |     usage: 1G x 1 instances
71 |     urls: MY-APP.cfapps.io
72 |     last uploaded: Wed 17 Jul 22:57:04 UTC 2024
73 |         state     since                  cpu    memory        disk           logging         cpu entitlement   details
74 |     \#0  running   2024-07-17T22:57:22Z   0.3%   49.5M of 1G   130.2M of 1G   0B/s of 16K/s   2.4%
75 |
76 | 77 | ## Stacks API 78 | 79 | For API information, see the "Stacks" section of the [Cloud Foundry API documentation](http://apidocs.cloudfoundry.org). 80 | -------------------------------------------------------------------------------- /egress-policies.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Topic does not exist 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | <% if vars.platform_code == "CF" %> 7 | 8 | The topic that you were looking for, titled _Administering Dynamic Egress Policies_, does not exist. 9 | 10 | The feature this topic covers is removed. 11 | 12 | <% else %> 13 | 14 | The topic that you were looking for does not exist in this version of the <%= vars.product_full %> documentation. 15 | The feature this topic covers is removed. 16 | 17 | The topic _Administering Dynamic Egress Policies_ is available in <%= vars.product_full %> v2.10. 18 | 19 | <% end %> 20 | -------------------------------------------------------------------------------- /http2-protocol.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Routing HTTP/2 and gRPC traffic to apps 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | Here are instructions for routing HTTP/2 and gRPC traffic to <%= vars.app_runtime_first %> apps. 7 | HTTP/2 is the second major version of the the HTTP protocol. 8 | <%= vars.http2_support_version %> 9 | 10 | For more information about the HTTP/2 protocol, see [RFC 7540](https://datatracker.ietf.org/doc/html/rfc7540). 11 | 12 | gRPC is a Remote Procedure Call (RPC) framework that uses HTTP/2 as its transport medium. 13 | It is especially useful for managing communication between apps in a microservices cluster. 14 | For apps to serve gRPC traffic, every network hop between the client and app must use HTTP/2. 15 | 16 | For more information, see [gRPC](https://grpc.io/). 17 | 18 | ## Performance 19 | 20 | HTTP/2 can provide performance improvements for apps that are built to: 21 | 22 | - Load many resources in parallel. For example, an HTML page that loads many images or JavaScript files. 23 | - Use large and repetitive headers. 24 | 25 | Other apps might see minimal or no performance increases. 26 | Experiment with your app to see how serving HTTP/2 affects its performance. 27 | 28 | For an example of an app that benefits from HTTP/2, see the [Cloud Foundry HTTP/2 Tile Demo App](https://github.com/Gerg/http2_tile_demo). 29 | 30 | ### Limitations 31 | 32 | HTTP/2 support in <%= vars.app_runtime_abbr %> has these limitations: 33 | 34 | - End-to-end HTTP/2 is not available for Windows Diego Cells. Routes with HTTP/2 mappings continue to send HTTP/1.1 traffic to apps that run on Windows Diego Cells. 35 | - Routes that have route services bound to them might not support end-to-end HTTP/2 depending on what protocols the bound service supports. For more information, see [Route services](../services/route-services.html). 36 | 37 | ## How pushing apps with HTTP/2 works 38 | 39 | If your <%= vars.app_runtime_abbr %> deployment is configured to support HTTP/2, 40 | then all traffic coming in to <%= vars.app_runtime_abbr %> supports HTTP/2. 41 | The traffic is forwarded as HTTP/1.1 before it reaches your app unless configured otherwise. 42 | 43 | <% if vars.platform_code != 'CF' %> 44 | For more information, see [Configuring HTTP/2 support](https://docs.vmware.com/en/VMware-Tanzu-Application-Service/<%= vars.current_major_version %>/tas-for-vms/supporting-http2.html). 45 | <% end %> 46 | 47 | To serve gRPC traffic, your app must use HTTP/2 for all network hops. 48 | Configure your route to send HTTP/2 traffic to your app. 49 | When configured, traffic that matches the route is always sent to your app over HTTP/2 regardless of the original ingress protocol. 50 | 51 | For example, external HTTP/1.1 requests are forwarded to your app over HTTP/2. 52 | Your app does not have the opportunity to negotiate what protocol it receives. 53 | 54 | If a client is familiar with the HTTP/2 specification, 55 | your app receives HTTP/2 with prior knowledge. 56 | For more information, see [Starting HTTP/2 with Prior Knowledge](https://datatracker.ietf.org/doc/html/rfc7540#section-3.4) in _RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2)_. 57 | 58 | 59 | ## Push apps with HTTP/2 support 60 | 61 | This section describes how to push <%= vars.app_runtime_abbr %> apps with support for HTTP/2. 62 | 63 | You do not need to make changes to existing apps to support HTTP/2. 64 | For information about pushing an HTTP/1.1 app that serves HTTP/2 traffic, see [Push an HTTP/1.1 App that Serves HTTP/2](#http1-app). 65 | 66 | There are multiple ways to push an app with end-to-end HTTP/2. 67 | You can push the app using either the app manifest or the Cloud Foundry Command Line Interface (cf CLI). 68 | You can also use either method to push an app that serves gRPC traffic. 69 | 70 | To push an app with end-to-end HTTP/2, see: 71 | 72 | - [Push an app with end-to-end HTTP/2 using the app manifest](#e2e-manifest) 73 | - [Push an app with end-to-end HTTP/2 using the cf CLI](#e2e-cli) 74 | - [Push a gRPC app](#grpc-app) 75 | 76 | ### Push an HTTP/1.1 app that serves HTTP/2 77 | 78 | To push an HTTP/1.1 app that can serve HTTP/2 traffic: 79 | 80 | 1. Push the HTTP/1.1 app by running: 81 | 82 | ```console 83 | cf push MY-APP 84 | ``` 85 | Where `MY-APP` is the name of your app. 86 | 87 | 1. Send an HTTP/2 request to the app by running: 88 | 89 | ``` 90 | curl MY-APP.EXAMPLE.COM --http2 -v 91 | ``` 92 | Where `MY-APP.EXAMPLE.COM` is the route mapped to your app.

93 | The request and response are both issued over HTTP/2. 94 | 95 |

96 | To issue this request, you must use a version of curl that supports HTTP/2.

97 | 98 | 1. Review the app logs by running: 99 | 100 | ``` 101 | cf logs MY-APP 102 | ``` 103 | The request to the app is issued over HTTP/1.1. 104 | 105 | ### Push an app with end-to-end HTTP/2 using the app manifest 106 | 107 | To push an app that serves HTTP/2 traffic using the app manifest: 108 | 109 | 1. Use an app that supports serving HTTP/2 traffic with prior knowledge. 110 | For example, you can use the HTTP/2 test app from [Cloud Foundry Acceptance Tests](https://github.com/cloudfoundry/cf-acceptance-tests/tree/main/assets/http2) on GitHub. 111 | 112 | 1. Create an app manifest named `manifest.yml` with a route mapped to the app with HTTP/2: 113 | 114 | ```yaml 115 | --- 116 | applications: 117 | - name: MY-APP 118 | routes: 119 | - route: MY-APP.EXAMPLE.COM 120 | protocol: http2 121 | ``` 122 | Where `MY-APP` is the name of your app and `MY-APP.EXAMPLE.COM` is the route you want to map to your app. 123 | 124 | 1. Push the app with the manifest by running: 125 | 126 | ``` 127 | cf push -f manifest.yml 128 | ``` 129 | 130 | 1. Send an HTTP/2 request to the app by running: 131 | 132 | ``` 133 | curl MY-APP.EXAMPLE.COM --http2 -v 134 | ``` 135 | The request and response are both sent over HTTP/2. The response from the test app includes the protocol.

For example: 136 | 137 | ``` 138 | Hello, /, TLS: false, Protocol: HTTP/2.0 139 | ``` 140 | The response shows that the request was received over HTTP/2. 141 | 142 | ### Push an app with end-to-end HTTP/2 using the cf CLI 143 | 144 | The recommended way to do this is using the `routes` attribute in the manifest YAML file. 145 | 146 |

147 | The following procedure is supported only for cf CLI v6. The --hostname flag is deprecated in cf CLI v7, and must be specified in the manifest.

148 | 149 | To push an app that serves HTTP/2 traffic using the cf CLI (v6 only): 150 | 151 | 1. Use an app that supports serving HTTP/2 traffic with prior knowledge. 152 | For example, you can use the HTTP/2 test app from [Cloud Foundry Acceptance Tests](https://github.com/cloudfoundry/cf-acceptance-tests/tree/main/assets/http2) on GitHub. 153 | 154 | 1. Push the app without a default route by running with the `--no-route` flag. Note that this flag is no longer unbinds all existing routes associated with the app. 155 | 156 | ```console 157 | cf push --no-route 158 | ``` 159 | 160 | 2. You can map a route by running: 161 | 162 | ``` 163 | cf map-route MY-APP EXAMPLE.COM --hostname host 164 | ``` 165 | Where `MY-APP` is the name of your app and `EXAMPLE.COM` is the route you want to map to your app. 166 | 167 | 3. Send an HTTP/2 request to the app by running: 168 | 169 | ``` 170 | curl HOST.EXAMPLE.COM --http2 -v 171 | ``` 172 | The request and response are both sent over HTTP/2. The response from the test app includes the protocol.

For example: 173 | 174 | ``` 175 | Hello, /, TLS: false, Protocol: HTTP/2.0 176 | ``` 177 | The response shows that the request was received over HTTP/2. 178 | 179 | ### Push a gRPC app 180 | 181 | To push an app that serves gRPC traffic: 182 | 183 | 1. Use an app that supports serving gRPC traffic. 184 | For example, you can use the gRPC test app from [Cloud Foundry Acceptance Tests](https://github.com/cloudfoundry/cf-acceptance-tests/tree/main/assets/grpc) on GitHub. 185 | 186 | 1. Push the app with HTTP/2 activated using either the app manifest or the cf CLI. 187 | See [Push an app with end-to-end HTTP/2 using the app manifest](#e2e-manifest) or [Push an app with end-to-end HTTP/2 using the cf CLI](#e2e-cli). 188 | 189 | 1. Send a gRPC request to the app using `grpcurl` by running the following command. For more information, see [grpcurl](https://github.com/fullstorydev/grpcurl). 190 | 191 | ``` 192 | grpcurl -vv -import-path ./test/ -proto test.proto MY-APP.EXAMPLE.COM:443 test.Test.Run 193 | ``` 194 | Where `MY-APP.EXAMPLE.COM` is the route to your app.

195 | A successful response looks like this: 196 | 197 | ``` 198 | Response contents: 199 | { 200 | "body": "Hello" 201 | } 202 | ``` 203 | 204 | ## Sample applications 205 | 206 | Here are some sample HTTP/2 and gRPC applications from the community. You can 207 | use them to experiment with HTTP/2 and provide code examples for different 208 | languages and frameworks. 209 | 210 | - [ASP.NET Core HTTP/2 App](https://github.com/Gerg/dotnet_http2) 211 | - [Golang CATs gRPC App](https://github.com/grpc/grpc-go) 212 | - [Golang CATs HTTP/2 App](https://github.com/cloudfoundry/cf-acceptance-tests/tree/main/assets/http2) 213 | - [Golang HTTP/2 Tile App](https://github.com/Gerg/http2_tile_demo) 214 | - [Golang SAP gRPC App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/go-grpc) 215 | - [Golang SAP HTTP/2 App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/go-http2) 216 | - [Java SAP gRPC App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/java-grpc) 217 | - [Java SAP HTTP/2 App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/java-http2) 218 | - [Node SAP gRPC App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/node-grpc) 219 | - [Node SAP HTTP/2 App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/node-http2) 220 | - [Python SAP gRPC App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/python-grpc) 221 | - [Python SAP HTTP/2 App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/python-http2) 222 | - [Ruby SAP gRPC App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/ruby-grpc) 223 | - [Ruby SAP HTTP/2 App](https://github.com/SAP-samples/cf-routing-samples/tree/main/http2/ruby-http2) 224 | -------------------------------------------------------------------------------- /images/about-deploy/app_push_flow_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/about-deploy/app_push_flow_diagram.png -------------------------------------------------------------------------------- /images/blue-green/blue-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/blue-green/blue-green.png -------------------------------------------------------------------------------- /images/blue-green/blue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/blue-green/blue.png -------------------------------------------------------------------------------- /images/blue-green/green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/blue-green/green.png -------------------------------------------------------------------------------- /images/blue-green/map.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/blue-green/map.png -------------------------------------------------------------------------------- /images/blue-green/unmap.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/blue-green/unmap.png -------------------------------------------------------------------------------- /images/cloudflare/minimal_manifest.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/cloudflare/minimal_manifest.png -------------------------------------------------------------------------------- /images/cloudflare/minimal_manifest_v6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/cloudflare/minimal_manifest_v6.png -------------------------------------------------------------------------------- /images/cloudflare/minimal_manifest_v6_edit1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/cloudflare/minimal_manifest_v6_edit1.png -------------------------------------------------------------------------------- /images/orgs-and-spaces/CF-Arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/orgs-and-spaces/CF-Arch.png -------------------------------------------------------------------------------- /images/route_ports.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/route_ports.png -------------------------------------------------------------------------------- /images/self-service.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/self-service.png -------------------------------------------------------------------------------- /images/sidecar-diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/sidecar-diagram.png -------------------------------------------------------------------------------- /images/ssh-app-access.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/ssh-app-access.png -------------------------------------------------------------------------------- /images/third-party-logs/logentries-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/logentries-02.png -------------------------------------------------------------------------------- /images/third-party-logs/logentries-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/logentries-03.png -------------------------------------------------------------------------------- /images/third-party-logs/logentries-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/logentries-04.png -------------------------------------------------------------------------------- /images/third-party-logs/logentries-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/logentries-05.png -------------------------------------------------------------------------------- /images/third-party-logs/logentries-08.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/logentries-08.png -------------------------------------------------------------------------------- /images/third-party-logs/logentries-09.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/logentries-09.png -------------------------------------------------------------------------------- /images/third-party-logs/papertrail-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/papertrail-02.png -------------------------------------------------------------------------------- /images/third-party-logs/papertrail-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/papertrail-03.png -------------------------------------------------------------------------------- /images/third-party-logs/papertrail-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/papertrail-04.png -------------------------------------------------------------------------------- /images/third-party-logs/papertrail-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/papertrail-05.png -------------------------------------------------------------------------------- /images/third-party-logs/papertrail-11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/papertrail-11.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-02.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-03.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-03.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-04.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-05.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-06.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-06.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-09.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-09.png -------------------------------------------------------------------------------- /images/third-party-logs/splunkstorm-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/splunkstorm-10.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-02.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-02.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-03a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-03a.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-03b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-03b.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-04.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-04.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-05.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-05.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-06a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-06a.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-09.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-09.png -------------------------------------------------------------------------------- /images/third-party-logs/sumologic-10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-dev-guide/25334084d0e74d047c3b1871f00cec3d8f97224f/images/third-party-logs/sumologic-10.png -------------------------------------------------------------------------------- /index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: App developer guide 3 | --- 4 | 5 | This guide provides instructions for deploying, running, and managing apps and services with <%= vars.app_runtime_first %>. 6 | 7 | <%= vars.gsg_app_video_link %> 8 | 9 | 10 | ## Overview 11 | 12 | Developing, running, and managing apps on <%= vars.app_runtime_abbr %> might include: 13 | 14 | * Deploying and scaling apps with diverse languages, frameworks, and dependencies 15 | * Finding software services in the services Marketplace, such as databases, email, or message servers 16 | * Creating your own <%= vars.app_runtime_abbr %> service based on an external server 17 | * Creating service instances and binding them to your apps 18 | * Streaming app logs to an external log management service 19 | * Troubleshooting app deployment and health 20 | 21 | If you do these things, you are a <%= vars.app_runtime_abbr %> **developer**, and the contents of this guide are for you. 22 | 23 | ## Contents 24 | 25 | * [Considerations for designing and running an app in the cloud](deploy-apps/prepare-to-deploy.html) 26 | 27 | * **cf push:** How to use `cf push` and troubleshoot when running `cf push`. 28 | * [Pushing your app using Cloud Foundry CLI (cf push)](deploy-apps/deploy-app.html) 29 | * [Deploying with app manifests](deploy-apps/manifest.html) 30 | * [App manifest attribute reference](deploy-apps/manifest-attributes.html) 31 | * [Deploying your app with Docker](deploy-apps/push-docker.html) 32 | * [Deploying your large apps](deploy-apps/large-app-deploy.html) 33 | * [Starting, restarting, and restaging apps](deploy-apps/start-restart-restage.html) 34 | * [Pushing an app with multiple processes](multiple-processes.html) 35 | * [Running cf push sub-step commands](push-sub-commands.html) 36 | * [Configuring app deployments](deploy-apps/rolling-deploy.html) 37 | * [Pushing apps with sidecar processes](sidecars.html) 38 | * [Using blue-green deployment to reduce downtime and risk](deploy-apps/blue-green.html) 39 | * [Troubleshooting app deployment and health](deploy-apps/troubleshoot-app-health.html) 40 | 41 | * **Routes and Domains:** How to configure routes and domains. 42 | * [Configuring routes and domains](deploy-apps/routes-domains.html) 43 | * [Configuring per-route options](custom-per-route-options.html) 44 | * [Configuring <%= vars.app_runtime_abbr %> to route traffic to apps on custom ports](custom-ports.html) 45 | * [Routing HTTP/2 and gRPC traffic to apps](http2-protocol.html) 46 | 47 | * **Managing Apps with the cf CLI:** How to manage apps through the Cloud Foundry Command Line Interface (cf CLI). 48 | * [Running tasks in your apps](using-tasks.html) 49 | * [Scaling an app Using cf scale](deploy-apps/cf-scale.html) 50 | * [Using app health checks](deploy-apps/healthchecks.html) 51 | * [Cloud Foundry API app revisions](revisions.html) 52 | * [Configuring container-to-container networking](deploy-apps/cf-networking.html) 53 | 54 | * **Managing Services:** How to use software services from your apps. 55 | * [Services overview](services/index.html) 56 | * [Managing service instances with the cf CLI](services/managing-services.html) 57 | * [Sharing service instances](services/sharing-instances.html) 58 | * [Delivering service credentials to an app](services/application-binding.html) 59 | * [Managing service keys](services/service-keys.html) 60 | * [Managing app requests with route services](services/route-binding.html) 61 | * [Configuring Play Framework service connections](services/play-service-bindings.html) 62 | * [Using an external file system (volume services)](services/using-vol-services.html) 63 | * [User-provided service instances](services/user-provided.html) 64 | 65 | * **Streaming App Logs:** How to stream app logs to third-party log management services. 66 | * [Streaming app logs to log management services](services/log-management.html) 67 | * [Service-specific instructions for streaming app logs](services/log-management-thirdparty-svc.html) 68 | * [Streaming app logs to Splunk](services/integrate-splunk.html) 69 | * [Streaming app logs with Fluentd](services/fluentd.html) 70 | * [Streaming app logs to Azure OMS Log Analytics](services/oms-nozzle.html) 71 | 72 | * **SSH for Apps and Services:** How to configure and use SSH access to apps and services. 73 | * [App SSH overview](deploy-apps/app-ssh-overview.html) 74 | * [Accessing apps with SSH](deploy-apps/ssh-apps.html) 75 | * [Accessing services with SSH](deploy-apps/ssh-services.html) 76 | 77 | * [<%= vars.app_runtime_abbr %> environment variables](deploy-apps/environment-variable.html): The environment variables that the <%= vars.app_runtime_abbr %> runtime and buildpacks set for a deployed app. 78 | 79 | * [Cloud Controller API client libraries](capi/client-libraries.html): Libraries for calling the Cloud Controller, the executive component of <%= vars.app_runtime_abbr %>, programmatically. 80 | -------------------------------------------------------------------------------- /managing-apps-index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Managing Apps with the cf CLI 3 | owner: 4 | --- 5 | 6 | These topics contain information about managing apps with the Cloud Foundry Command Line Interface (cf CLI): 7 | 8 |