├── .DS_Store ├── LICENSE ├── NOTICE ├── README.md ├── _config_manifest.html.md.erb ├── _default_asg_oss.html.md.erb ├── _max_in_flight_text.html.md.erb ├── _oss_roles_table.html.md.erb ├── _oss_scale_table.html.md.erb ├── _oss_xfcc_loadbalancer.html.md.erb ├── _oss_xfcc_router.html.md.erb ├── _overview_model.html.md.erb ├── _suspended_org_roles_table.html.md.erb ├── apps-index.html.md.erb ├── architecture ├── .DS_Store ├── _cc_communications.html.md.erb ├── _old_collector.html.md.erb ├── cloud-controller.html.md.erb ├── garden.html.md.erb ├── index.html.md.erb └── uaa.html.md.erb ├── asg.html.md.erb ├── cc-blobstore.html.md.erb ├── cf-routing-architecture.html.md.erb ├── container-security.html.md.erb ├── contribute.html.md.erb ├── diego ├── diego-architecture.html.md.erb ├── diego-auction.html.md.erb └── ssh-conceptual.html.md.erb ├── glossary.html.md.erb ├── grootfs-disk.html.md.erb ├── ha-index.html.md.erb ├── high-availability.html.md.erb ├── how-applications-are-staged.html.md.erb ├── http-routing.html.md.erb ├── images ├── .DS_Store ├── BG_CF.jpg ├── CF-Arch.png ├── Pipe_NavBar.png ├── Pipe_gBar.png ├── about-deploy │ └── app_push_flow_diagram.png ├── add-website.png ├── app_push_flow_diagram-2.png ├── app_push_flow_diagram.png ├── app_push_flow_diagram_diego.png ├── bg-plain-x.jpg ├── bg-plain.jpg ├── bg_social_footer.png ├── c2c-arch.png ├── cc-blobstore-staging.png ├── cc-communications-map.png ├── cf-icons.png ├── cf-routing-architecture.png ├── cf_architecture.graffle ├── cf_architecture.png ├── cf_architecture_block.graffle ├── cf_architecture_block.png ├── cf_architecture_block_dea.graffle ├── cf_architecture_block_dea.png ├── cloudflare-register.png ├── cloudflare │ ├── add-website.png │ ├── cloudflare-register.png │ ├── complete.png │ ├── config-dns.png │ ├── confirm-ssl.png │ ├── my-websites.png │ ├── scan-complete.png │ └── settings.png ├── comparison.png ├── complete.png ├── config-dns.png ├── confirm-selected-features.png ├── confirm-ssl.png ├── cta_create_account.png ├── dea_placement_algorithm │ ├── dea_az_select.png │ ├── dea_criteria_filter.png │ ├── dea_select_instance_count.png │ └── dea_top_half_memory.png ├── diego │ ├── .DS_Store │ ├── app-monitor-sync-diego.graffle │ ├── app-monitor-sync-diego.png │ ├── auctioneer-job-list.png │ ├── diego-LRP-stack.png │ ├── diego-auction-process.old.png │ ├── diego-auction-process.png │ ├── diego-auction-results.png │ ├── diego-auction-stack.png │ ├── diego-flow-other.png │ ├── diego-flow.png │ └── diego-overview.png ├── director-components.png ├── director-deployment-manager.png ├── director-instance_manager_1.png ├── director-release-manager.png ├── director-stemcell-manager.png ├── director-task-manager.png ├── director-vm-state-manager.png ├── docker_push_flow_diagram_diego.png ├── envoy-proxy.png ├── external-client-call-app.png ├── facebook_large.png ├── favicon.ico ├── fig1.png ├── fig2.png ├── g+_large.png ├── hr-horizontal-dark.png ├── hr-vertical.png ├── ico-cancel-x.png ├── ico-search.png ├── istio_boxes_lines.jpg ├── istio_c2c_boxes_lines.jpg ├── istio_ingress_boxes_lines.jpg ├── logo-cf-clean.png ├── logo-cloudfoundry-pivotal.png ├── logo-cloudfoundry.png ├── logo-pivotal.png ├── logo_cloudfoundry.png ├── logo_org.png ├── mapping_foundations.png ├── mapping_foundations2.png ├── mapping_organizations.png ├── mapping_organizations2.png ├── mapping_spaces.png ├── mapping_spaces2.png ├── minimal_manifest.png ├── my-websites.png ├── nuclear2.jpg ├── orgs-and-spaces │ └── CF-Arch.png ├── oss-diego-architecture-1.png ├── oss-diego-architecture-2.png ├── oss-diego-architecture-3.png ├── oss-diego-architecture-4.png ├── oss-diego-architecture-5.png ├── oss-diego-architecture-6.png ├── pivotal-logo.png ├── post-c2c.png ├── power-of-platform.png ├── pre-c2c.png ├── ribbon_forkme.png ├── scale_cf.graffle ├── scale_cf.png ├── scaling-ert.png ├── scan-complete.png ├── security │ ├── isolation-segments.graffle │ ├── isolation-segments.png │ ├── norm-sequence.graffle │ ├── sysbound1.png │ └── sysbound2.png ├── settings.png ├── signup.png ├── signup_freetrial.png ├── sts │ ├── add-cloud-url.png │ ├── application-details.png │ ├── cloud-foundry-account.png │ ├── confirm-selected-features.png │ ├── define-new-server.png │ ├── eclipse-marketplace.png │ ├── extensions.png │ ├── file-contents.png │ ├── install-details.png │ ├── install.png │ ├── launch-deployment.png │ ├── manage-cloud-urls.png │ ├── manage-uris-configuration.png │ ├── new-server.png │ ├── orgs-and-spaces.png │ ├── restart-sts.png │ ├── service-configuration.png │ ├── services-selection.png │ ├── software-updates.png │ ├── ui-apps-services-tab.png │ └── ui-overview-tab.png ├── twitter_large.png ├── uaa-architecture.png ├── v1services.png ├── v2services.png ├── vcenter-disk-path.png ├── vcenter-folders.png ├── vcloud_catalog.png ├── vcloud_private_network.png ├── vcloud_source_nat.png └── youtube_large.png ├── index.html.md.erb ├── maintaining-high-availability.html.md.erb ├── orgs-and-spaces.html.md.erb ├── overview.html.md.erb ├── roles.html.md.erb ├── security-index.html.md.erb ├── security.html.md.erb └── understand-cf-networking.html.md.erb /.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/.DS_Store -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2015-Present CloudFoundry.org Foundation, Inc. All Rights Reserved. 2 | 3 | Copyright (c) 2012-2015 Pivotal Software, 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 | # Cloud Foundry Concepts Guide 2 | 3 | This repository contains the Cloud Foundry concepts guide, designed to help users and others understand how Cloud Foundry works. 4 | 5 | The contents here are structured as a topic repository intended to be 6 | compiled into a larger document with 7 | [Bookbinder](http://github.com/cloudfoundry-incubator/bookbinder). 8 | 9 | See the [docs-book-cloudfoundry](http://github.com/cloudfoundry/docs-book-cloudfoundry) 10 | repository for the complete list of open source documentation repositories, as well as 11 | information about the publishing process. 12 | 13 | ## Container-to-Container Networking Diagrams 14 | 15 | If you are a contributor to this documentation and would like to modify or propose a modification to the diagrams used in the _Container-to-Container Networking_ topic, see the source Google Drawings below: 16 | 17 | * Architecture: https://docs.google.com/drawings/d/1oc2kr5hmltsD2wCEAm5_KTNErf0KOfFwXjYLoXS6geM/edit 18 | * Before c2c: https://docs.google.com/drawings/d/1RIZ6NzpwvN0TINTY2XwNox0ctOzP56IBTHpDkg0n-Kc/edit 19 | * After c2c: https://docs.google.com/drawings/d/1PaquEmZCsHUBq2ACjrKKWMqlM1QMwKOxN_iMLsoTYd0/edit 20 | -------------------------------------------------------------------------------- /_config_manifest.html.md.erb: -------------------------------------------------------------------------------- 1 | Although all application instances and staging tasks now run by default in unprivileged containers, 2 | operators can override these defaults by customizing their Diego deployment manifest and redeploying. 3 | 4 | * To enable privileged containers for buildpack-based apps, set the `capi.nsync.diego_privileged_containers` property 5 | to `true` in the Diego manifest. 6 | * To enable privileged containers for staging tasks, set the `capi.stager.diego_privileged_containers` property 7 | to `true` in the Diego manifest. 8 | -------------------------------------------------------------------------------- /_default_asg_oss.html.md.erb: -------------------------------------------------------------------------------- 1 | Cloud Foundry preconfigures two ASGs: `public_networks` and `dns`. 2 | 3 | Unless you modify these before your initial deployment, these ASGs are applied by default to all containers in your deployment. 4 | 5 | * `public_networks`: This group allows access to public networks, and blocks access to private networks and link local addresses. Cloud 6 | Foundry blocks outgoing traffic to the following IP address ranges by specifically allowing traffic to all other addresses: 7 | * 10.0.0.0 - 10.255.255.255 8 | * 169.254.0.0 - 169.254.255.255 9 | * 172.16.0.0 - 172.31.255.255 10 | * 192.168.0.0 - 192.168.255.255 11 | 12 | * `dns`: This group allows access to DNS on port 53 for any IP address. The default ASGs are defined in the `cf-deployment.yml` file as follows: 13 | 14 | ``` 15 | security_group_definitions: 16 | - name: public_networks 17 | rules: 18 | - destination: 0.0.0.0-9.255.255.255 19 | protocol: all 20 | - destination: 11.0.0.0-169.253.255.255 21 | protocol: all 22 | - destination: 169.255.0.0-172.15.255.255 23 | protocol: all 24 | - destination: 172.32.0.0-192.167.255.255 25 | protocol: all 26 | - destination: 192.169.0.0-255.255.255.255 27 | protocol: all 28 | - name: dns 29 | rules: 30 | - destination: 0.0.0.0/0 31 | ports: '53' 32 | protocol: tcp 33 | - destination: 0.0.0.0/0 34 | ports: '53' 35 | protocol: udp 36 | ``` 37 | Modify the default ASGs to block outbound traffic as necessary for your installation. To see how the ASGs are defined by 38 | default, see the [cf-deployment.yml](https://github.com/cloudfoundry/cf-deployment/blob/main/cf-deployment.yml#L604-L627) file on GitHub. 39 | -------------------------------------------------------------------------------- /_max_in_flight_text.html.md.erb: -------------------------------------------------------------------------------- 1 | For each component, the variable `max_in_flight` limits how many instances of that component are restarted simultaneously during updates or upgrades. You set `max_in_flight` in the manifest as a system-wide value, plus any component-specific overrides. Values for `max_in_flight` can be any integer between 1 and 100. 2 | 3 | To ensure zero downtime during updates, set `max_in_flight` for each component to a number low enough to prevent overburdening the component instances left running. Here are some guidelines: 4 | 5 | - For host VMs, the closer their resource usage is to 100%, the lower you set `max_in_flight`, allows non migrating cells to pick up the work of cells stopping and restarting for migration. If resource usage is already close to 100%, scale up your host VMs before any updates. 6 | - For quorum-based components like etcd and Diego BBS, set `max_in_flight` to `1`. 7 | - For other components, set `max_in_flight` to the number of instances that you can afford to have down at any one time. This depends on 8 | your capacity planning. With higher redundancy, you can make the number high so that updates run faster. But if your components are at 9 | high utilization, you must keep the number low. 10 | 11 | Never set `max_in_flight` to a value greater than or equal to the number of instances you have running for a component. 12 | -------------------------------------------------------------------------------- /_oss_roles_table.html.md.erb: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 | 298 | 299 | 300 | 301 | 302 | 303 | 304 | 305 | 306 | 307 | 308 | 309 | 310 | 311 | 312 | 313 | 314 | 315 | 316 | 317 | 318 | 319 | 320 | 321 | 322 | 323 | 324 | 325 | 326 | 327 | 328 | 329 | 330 | 331 | 332 | 333 | 334 | 335 | 336 | 337 | 338 | 339 | 340 | 341 | 342 | 343 | 344 | 345 | 346 | 347 | 348 | 349 | 350 | 351 | 352 | 353 | 354 | 355 | 356 | 357 | 358 | 359 | 360 | 361 | 362 | 363 | 364 | 365 | 366 | 367 | 368 | 369 | 370 | 371 | 372 | 373 | 374 | 375 | 376 | 377 | 378 | 379 | 380 | 381 | 382 | 383 | 384 | 385 | 386 | 387 | 388 | 389 | 390 | 391 | 392 | 393 | 394 | 395 | 396 | 397 | 398 | 399 | 400 | 401 | 402 | 403 | 404 | 405 | 406 | 407 | 408 | 409 | 410 | 411 | 412 | 413 | 414 | 415 | 416 | 417 | 418 | 419 | 420 | 421 | 422 | 423 | 424 | 425 | 426 | 427 | 428 | 429 | 430 | 431 | 432 | 433 | 434 | 435 | 436 | 437 | 438 | 439 | 440 | 441 | 442 | 443 | 444 | 445 | 446 | 447 | 448 | 449 | 450 | 451 | 452 | 453 | 454 | 455 | 456 | 457 | 458 | 459 | 460 | 461 | 462 | 463 | 464 | 465 | 466 | 467 | 468 | 469 | 470 | 471 | 472 | 473 | 474 | 475 | 476 | 477 | 478 | 479 | 480 | 481 | 482 | 483 | 484 | 485 | 486 | 487 | 488 | 489 | 490 | 491 | 492 | 493 | 494 | 495 | 496 | 497 | 498 | 499 | 500 | 501 | 502 | 503 | 504 | 505 | 506 | 507 | 508 | 509 | 510 | 511 | 512 | 513 | 514 | 515 | 516 | 517 | 518 | 519 | 520 | 521 | 522 | 523 | 524 | 525 | 526 | 527 | 528 | 529 | 530 | 531 | 532 | 533 | 534 | 535 | 536 | 537 | 538 | 539 | 540 | 541 | 542 | 543 | 544 | 545 | 546 | 547 | 548 | 549 | 550 | 551 | 552 | 553 | 554 | 555 | 556 | 557 | 558 | 559 | 560 | 561 | 562 | 563 | 564 | 565 | 566 | 567 | 568 | 569 | 570 | 571 | 572 | 573 | 574 | 575 | 576 | 577 | 578 | 579 | 580 | 581 | 582 | 583 | 584 | 585 | 586 | 587 | 588 | 589 | 590 | 591 | 592 | 593 | 594 |
ActivityAdminAdmin Read-OnlyGlobal AuditorOrg ManagerOrg AuditorOrg Billing ManagerOrg UserSpace ManagerSpace DeveloperSpace AuditorSpace Supporter
Scope of operationOrgOrgOrgOrgOrgOrgOrgSpaceSpaceSpaceSpace
Assign user rolesYesYesYes
View users and rolesYesYesYesYesYesYesYesYesYesYesYes
Create and assign org quota plansYes
View org quota plansYesYesYesYesYesYesYesYesYesYesYes
Create orgsYes11111111
View all orgsYesYesYes
View orgs where user is memberYes2Yes2Yes2YesYesYesYesYesYesYesYes
Edit, rename, and delete orgsYesYes3
Suspend or activate an orgYes
Create and assign space quota plansYesYes
Create spacesYesYes
View spacesYesYesYesYesYesYesYesYes
Edit spacesYesYesYes
Delete spacesYesYes
Rename spacesYesYesYes
View the status, number of instances, service bindings, and resource use of appsYesYesYesYesYesYesYesYes
Add private domains4YesYes
Share private domains with other orgsYesYes5
Deploy, run, and manage appsYesYesLimited9
View app logsYesYesYesYesYesYesYesYes
Use app SSH6YesYes
Instantiate servicesYesYes
Bind services to appsYesYesYes
Manage global service brokersYes
Manage space-scoped service brokersYesYes
Associate routes4, modify resource allocation of appsYesYesYes
Rename appsYesYes
Create and manage Application Security GroupsYes
Manage Application Security Groups for all spaces in an orgYesYes
Manage Application Security Groups for an individual spaceYesYes
Create, update, and delete an isolation segmentYes
List all isolation segments for an orgYesYesYes7Yes7Yes7Yes7Yes7Yes7Yes7Yes7Yes7
Entitle or revoke an isolation segmentYes
List all orgs entitled to an isolation segmentYesYesYes7Yes7Yes7Yes7Yes7Yes7Yes7Yes7Yes7
Assign a default isolation segment to an orgYesYes
List and manage isolation segments for spacesYesYes
List entitled isolation segments for a spaceYesYesYesYesYesYesYesYes
List the isolation segment on which an app runsYesYesYesYesYesYesYesYes
List app and service usage eventsYesYesYesYesYesYes
Create, delete, and list container-to-container networking policiesYesYes8
595 | 596 | 1Not by default, unless feature flag `user_org_creation` is set to `true`. 597 | 598 | 2Admin, admin read-only, and global auditor roles do not need to be added as members of orgs or spaces to view resources. 599 | 600 | 3Org Managers can rename their orgs and edit some fields. They cannot delete orgs. 601 | 602 | 4Unless deactivated by feature flags. 603 | 604 | 5The user attempting to share must have permissions in both the source and target orgs. 605 | 606 | 6This assumes that SSH is enabled for the platform, space, and app. For more information, see [SSH Access Control Hierarchy](../devguide/deploy-apps/app-ssh-overview.html#ssh-access-control-hierarchy) in _App SSH Overview_. 607 | 608 | 7Applies only to orgs they belong to. 609 | 610 | 8Space Developers can optionally be granted these permissions. For more information, see [Grant Permissions](../devguide/deploy-apps/cf-networking.html#-grant-permissions) in _Configuring Container-to-Container Networking_. 611 | 612 | 9Cannot create packages or delete resources. For more information, see the [Cloud Controller V3 Documentation](https://v3-apidocs.cloudfoundry.org/). 613 | -------------------------------------------------------------------------------- /_oss_scale_table.html.md.erb: -------------------------------------------------------------------------------- 1 | The following table provides recommended instance counts for a high-availability deployment. You can 2 | decrease the footprint of your deployment by specifying fewer instances and combining multiple components onto a 3 | single VM. 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 |
ComponentTotal InstancesNotes
Diego Cell≥ 2The optimal balance between CPU/memory sizing and instance count depends on the performance characteristics of the apps that run on Diego cells. Scaling vertically with larger Diego cells makes for larger points of failure, and more apps go down when a cell fails. On the other hand, scaling horizontally decreases the speed at which the system rebalances apps. Rebalancing 100 cells takes longer and demands more processing overhead than rebalancing 20 cells.
Diego Brain≥ 2One per AZ, or two if only one AZ.
Diego BBS≥ 2One per AZ, or two if only one AZ.
PostgreSQL Server0 or 10 if Postgres database is external.
MySQL Proxy≥ 2
NATS Server≥ 2You might run a single NATS instance if you lack the resources to deploy two stable NATS servers. Components using NATS are resilient to message failures and the BOSH resurrector recovers the NATS VM quickly if it becomes non-responsive. NATS includes metrics as well as route registration and deregistration messages. <%= vars.recommended_by %> recommends scaling NATS VMs to 2 or more CPU.
Cloud Controller API≥ 2Scale the Cloud Controller to accommodate the number of requests to the API and the number of apps in the system.
Cloud Controller Worker≥ 2Scale the Cloud Controller to accommodate the number of asynchronous requests to the API and background jobs.
Router≥ 2Scale the router to accommodate the number of incoming requests. Additional instances increase available bandwidth. In general, this load is much less than the load on host VMs.
UAA≥ 2
Doppler Server≥ 2Deploying additional Doppler servers splits traffic across them. For high availability, use at least two per Availability Zone (AZ).
Loggregator TC≥ 2Deploying additional Loggregator Traffic Controllers allows you to direct traffic to them in a round-robin manner. For high availability, use at least two per AZ.
Log Cache≥ 1Deploying additional Log Cache instances increases the total storage, sharding data by app ID. If app logs and metrics are sharded to an unavailable instance, they are unavailable when the designated instance is unavailable regardless of the number of instances or AZs.
84 | -------------------------------------------------------------------------------- /_oss_xfcc_loadbalancer.html.md.erb: -------------------------------------------------------------------------------- 1 | #### Terminating TLS for the First Time at the Load Balancer 2 | 3 | By default, <%= vars.platform_name %> forwards arbitrary headers that are not otherwise mentioned in the documentation. You can configure a load balancer to put the certificate of the originating client, received during the mutual TLS handshake, into an HTTP header that the load balancer forwards upstream. <%= vars.company_name %> recommends the header XFCC for this use case, because this header is used in the other following configuration modes. The value of the header must be the base64-encoded bytes of the certificate, which is equivalent to a PEM file with newlines, headers, and footers removed. 4 | 5 | This mode is activated when `router.forwarded_client_cert` is set to `always_forward`. 6 | 7 | Alternatively, you can configure the Gorouter to forward the XFCC header set by the load balancer only when the connection with the load balancer is mutual TLS. The client certificate received by the Gorouter in the mutual TLS handshake is not forwarded in the header. 8 | 9 | This mode is activated when `router.forwarded_client_cert` is set to `forward`. 10 | -------------------------------------------------------------------------------- /_oss_xfcc_router.html.md.erb: -------------------------------------------------------------------------------- 1 | #### Terminating TLS for the First Time at the Gorouter 2 | 3 | If the Gorouter is the first component to stop TLS, such that it receives the certificate of the originating client in the mutual TLS handshake, you must configure the Gorouter to strip any instances of the XFCC header from client requests, set the value of the header to the base64-encoded bytes of the client certificate received in the mutual handshake, and forward the header upstream to the application. 4 | 5 | This mode is activated when router.forwarded\_client\_cert: sanitize\_set. 6 | 7 | If TLS stops for the first time at Gorouter, the Gorouter must be configured to trust the root certificate authority used to sign the Diego intermediate certificate authority, which in turn is used to sign certificates generated for each Diego container. This trust activates mutual authentication between applications that are running on Cloud Foundry. You must configure the router.ca_certs property for the Gorouter job with the root certificate authority in their BOSH deployment manifest. 8 | 9 | 
10 | 	jobs:
11 | 	  properties:
12 | 	    router:
13 | 	      ca_certs:
14 | 	        -----BEGIN CERTIFICATE-----
15 | 	        (contents of certificate)
16 | 	        -----END CERTIFICATE-----
17 |
18 | 19 | The router.ca_certs property is a string of concatenated certificate authorities in PEM format. 20 | 21 | 22 | -------------------------------------------------------------------------------- /_overview_model.html.md.erb: -------------------------------------------------------------------------------- 1 | 2 | [//]: # (Comment: This partial intentionally left blank. For private/commercial ) 3 | [//]: # ( books, this partial is stored in a private repository and contains commercial ) 4 | [//]: # ( content. ) 5 | -------------------------------------------------------------------------------- /_suspended_org_roles_table.html.md.erb: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 | 200 | 201 | 202 | 203 | 204 | 205 | 206 | 207 | 208 | 209 | 210 | 211 | 212 | 213 | 214 | 215 | 216 | 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 229 | 230 | 231 | 232 | 233 | 234 | 235 | 236 | 237 | 238 | 239 | 240 | 241 | 242 | 243 | 244 | 245 | 246 | 247 | 248 | 249 | 250 | 251 | 252 | 253 | 254 | 255 | 256 | 257 | 258 | 259 | 260 | 261 | 262 | 263 | 264 | 265 | 266 | 267 | 268 | 269 | 270 | 271 | 272 | 273 | 274 | 275 | 276 | 277 | 278 | 279 | 280 | 281 | 282 | 283 | 284 | 285 | 286 | 287 | 288 | 289 | 290 | 291 | 292 | 293 | 294 | 295 | 296 | 297 |
User RoleAdminAdmin Read-OnlyGlobal AuditorOrg ManagerOrg AuditorOrg Billing ManagerOrg UserSpace ManagerSpace DeveloperSpace Auditor
Scope of operationOrgOrgOrgOrgOrgOrgOrgSpaceSpaceSpace
Assign user rolesYes
View users and rolesYesYesYesYesYesYesYesYesYesYes
Create and assign org quota plansYes
View org quota plansYesYesYesYesYesYesYesYesYesYes
Create orgsYes
View all orgsYesYesYes
View orgs where user is a memberYes**Yes**Yes**YesYesYesYesYesYesYes
Edit, rename, and delete orgsYes
Suspend or activate an orgYes
Create and assign space quota plansYes
Create spacesYes
View spacesYesYesYesYesYesYesYes
Edit spacesYes
Delete spacesYes
Rename spacesYes
View the status, number of instances, service bindings, and resource use of appsYesYesYesYesYesYesYes
Add private domains†Yes
Deploy, run, and manage appsYes
Instantiate and bind services to appsYes
Associate routes†, modify resource allocation of appsYes
Rename appsYes
Create and manage Application Security GroupsYes
298 | 299 | †Unless disabled by feature flags. 300 | 301 | **Admin, admin read-only, and global auditor roles do not need to be added as members of orgs or spaces to view resources. 302 | -------------------------------------------------------------------------------- /apps-index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: How Cloud Foundry manages apps 3 | owner: Docs 4 | --- 5 | 6 | <%# Reset page title based on platform type %> 7 | <% if vars.platform_code != 'CF' %> 8 | 9 | <% set_title("How", vars.app_runtime_abbr, "Manages Apps") %> 10 | 11 | <% end %> 12 | 13 | The following topics provide information about how <%= vars.app_runtime_first %> manages apps: 14 | 15 | * [How Apps are Staged](how-applications-are-staged.html). 16 | * [App Container Lifecycle](../devguide/deploy-apps/app-lifecycle.html). 17 | * [How the Diego Auction Allocates Jobs](./diego/diego-auction.html). 18 | -------------------------------------------------------------------------------- /architecture/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/architecture/.DS_Store -------------------------------------------------------------------------------- /architecture/_cc_communications.html.md.erb: -------------------------------------------------------------------------------- 1 | Refer to the following diagram for information about internal and external communications of the Cloud Controller. 2 | 3 | ![Internal and external Cloud Controller communications](../images/cc-communications-map.png) 4 | 5 | View a [larger version](../images/cc-communications-map.png) of this image. 6 | -------------------------------------------------------------------------------- /architecture/_old_collector.html.md.erb: -------------------------------------------------------------------------------- 1 | ### Metrics Collector 2 | 3 | The metrics collector gathers metrics and statistics from the components. 4 | Operators can use this information to monitor a Cloud Foundry deployment. 5 | -------------------------------------------------------------------------------- /architecture/cloud-controller.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Controller 3 | owner: CAPI 4 | --- 5 | 6 | Cloud Controller in <%= vars.app_runtime_first %> provides you with REST API endpoints to access the 7 | system. 8 | Cloud Controller maintains a database with tables for orgs, spaces, 9 | services, user roles, and more. 10 | 11 | <% if vars.platform_code == 'CF' %> 12 | <%= partial 'cc_communications' %> 13 | <% else %> 14 | <% end %> 15 | 16 | ##Diego Auction 17 | 18 | The Cloud Controller uses the [Diego Auction](../diego/diego-auction.html) to balance application 19 | processes over the [Diego Cells](index.html#diego-cell) in a <%= vars.app_runtime_abbr %> installation. 20 | 21 | ##Database (CC_DB) 22 | 23 | <% if vars.platform_code == 'CF' %> 24 | The Cloud Controller database has been tested with Postgres and MySQL. 25 | <% else %> 26 | The Cloud Controller database has been tested with MySQL. 27 | <% end %> 28 | 29 | ##Blobstore 30 | 31 | To stage and run apps, <%= vars.app_runtime_abbr %> manages and stores app source code and other files in an S3-compatible blobstore. 32 | 33 | Please see [Cloud Controller blobstore](../cc-blobstore.html) for information. 34 | 35 | ##Testing 36 | 37 | <% if vars.platform_code == 'CF' %> 38 | 39 | By default `rspec` runs a test suite with the SQLite in-memory database. 40 | Specify a connection string using the `DB_CONNECTION` environment variable to 41 | test against Postgres and MySQL. For example: 42 | 43 | ~~~ 44 | DB_CONNECTION="postgres://postgres@localhost:5432/ccng" rspec 45 | DB_CONNECTION="mysql2://root:password@localhost:3306/ccng" rspec 46 | ~~~ 47 | 48 | Travis currently runs two build jobs against Postgres and MySQL. 49 | 50 | <% else %> 51 | 52 | By default `rspec` runs a test suite with the SQLite in-memory database. 53 | Specify a connection string using the `DB_CONNECTION` environment variable to 54 | test against MySQL. For example: 55 | 56 | ~~~ 57 | DB_CONNECTION="mysql2://root:password@localhost:3306/ccng" rspec 58 | ~~~ 59 | 60 | <% end %> 61 | 62 | <%= vars.cloud_controller_logging %> 63 | -------------------------------------------------------------------------------- /architecture/garden.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Garden component 3 | owner: Diego 4 | --- 5 | 6 | You can use Garden, the component that <%= vars.app_runtime_first %> uses to create and manage isolated environments 7 | called containers. Each instance of an app deployed to <%= vars.app_runtime_abbr %> runs within a container. 8 | 9 | For more information about how containers work, see [Container Mechanics](../container-security.html#mechanics) in _Container Security_. 10 | 11 | 12 | ## Plug-in back ends 13 | 14 | Garden has plug-in back ends for different platforms and runtimes. It 15 | specifies a set of interfaces that each platform specific back end must implement. 16 | 17 | These interfaces contain methods to perform the following actions: 18 | 19 | * Create and delete containers. 20 | * Apply resource limits to containers. 21 | * Open and attach network ports to containers. 22 | * Copy files into and out of containers. 23 | * Run processes within containers. 24 | * Stream `STDOUT` and `STDERR` data out of containers. 25 | * Annotate containers with arbitrary metadata. 26 | * Snapshot containers for redeploys without downtime. 27 | 28 | For more information, see the [Garden](https://github.com/cloudfoundry/garden) repository on GitHub. 29 | 30 | 31 | ## Garden-runC back end 32 | 33 | <%= vars.app_runtime_abbr %> currently uses the Garden-runC back end, a Linux-specific implementation of the Garden interface using the [Open Container Interface](https://github.com/opencontainers/runtime-spec) (OCI) standard. Previous versions of <%= vars.app_runtime_abbr %> used the Garden-Linux back end. For more information, see the [Garden-Linux](https://github.com/cloudfoundry-attic/garden-linux) repository on GitHub. 34 | 35 | <%= vars.garden_runc %> 36 | 37 | Garden-runC has the following features: 38 | 39 | * Uses the same OCI low-level container execution code as Docker and Kubernetes, so container images run identically across all three platforms 40 | 41 | * [AppArmor](https://wiki.ubuntu.com/AppArmor) is configured and enforced by default for all unprivileged containers 42 | 43 | * Seccomp allowlisting restricts the set of system calls a container can access, reducing the risk of container breakout 44 | 45 | * Allows plug-in networking and rootfs management 46 | 47 | For more information, see the [Garden-runC](https://github.com/cloudfoundry/garden-runc-release) repository on GitHub. 48 | 49 | ## Garden RootFS plug-in 50 | 51 | Garden manages container file systems through a plug-in interface. <%= vars.app_runtime_abbr %> uses the Garden RootFS (GrootFS) plug-in for this task. 52 | GrootFS is a Linux-specific implementation of the Garden volume plug-in interface. 53 | 54 | GrootFS performs the following actions: 55 | 56 | * Creates container file systems based on buildpacks and droplets. 57 | * Creates container file systems based on remote docker images. 58 | * Authenticates with remote registries when using remote images. 59 | * Properly maps UID/GID for all files inside an image. 60 | * Runs garbage collection to remove unused volumes. 61 | * Applies per container disk quotas. 62 | * Provides per container disk usage stats. 63 | 64 | For more information, see [GrootFS Disk Usage](../grootfs-disk.html) and the [GrootFS repository](https://github.com/cloudfoundry/grootfs) on GitHub. 65 | -------------------------------------------------------------------------------- /architecture/index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Runtime components 3 | --- 4 | 5 | <%# Reset page title based on product title %> 6 | <% if vars.platform_code != 'CF' %> 7 | <% set_title(vars.app_runtime_abbr, "Components") %> 8 | <% end %> 9 | 10 | This topic tells you about the <%= vars.app_runtime_first %> runtime components. 11 | 12 | <%= vars.app_runtime_abbr %> components include a self-service application execution engine, an automation engine for application deployment, and lifecycle management, and a scriptable command line interface (CLI). Also, an integration with development tools to ease deployment processes. 13 | <%= vars.app_runtime_abbr %> has an open architecture that includes a buildpack mechanism for adding frameworks, an application services interface, and a cloud provider interface. 14 | 15 | See the following descriptions for more information about <%= vars.app_runtime_abbr %> components. Some descriptions include links to more detailed documentation. 16 | 17 | ![Architecture components](./images/../../images/cf_architecture_block.png) 18 | 19 | ## Routing 20 | 21 | ### Router 22 | 23 | The router routes incoming traffic to the appropriate component, either a Cloud Controller component or a hosted application running on a Diego Cell. 24 | 25 | The router periodically queries the Diego Bulletin Board System (BBS) to determine which cells and containers each application currently runs on. Using this information, the router recomputes new routing tables based on the IP address of each cell virtual machine (VM) and the host-side port numbers for the cell's containers. 26 | 27 | For more information about the routing tier, including the router, see [<%= vars.app_runtime_abbr %> Routing Architecture](../cf-routing-architecture.html). 28 | 29 | ## Authentication 30 | 31 | ### OAuth2 Server (UAA) and Login Server 32 | 33 | The OAuth2 server (the [UAA](./uaa.html)) and Login Server work together to provide identity management. 34 | 35 | 36 | ## App Lifecycle 37 | 38 | ### Cloud Controller and Diego Brain 39 | 40 | The [Cloud Controller](./cloud-controller.html) (CC) directs the deployment of applications. To push an app to <%= vars.app_runtime_abbr %>, you target the Cloud Controller. The Cloud Controller then directs the Diego Brain through the CC-Bridge components to coordinate individual [Diego cells](#diego-cell) to stage and run applications. 41 | 42 | The Cloud Controller also maintain records of [orgs, spaces, user roles](../roles.html), services, and more. 43 | 44 | ### nsync, BBS, and Cell Reps 45 | 46 | To keep applications available, cloud deployments must constantly monitor their states and reconcile them with their expected states, starting and stopping processes as required. 47 | 48 | ![<%= vars.app_runtime_abbr %> Architecture](../images/diego/app-monitor-sync-diego.png) 49 | 50 | The nsync, BBS, and Cell Rep components work together along a chain to keep apps running. At one end is the user. At the other end are the instances of applications running on widely-distributed VMs, which might crash or become unavailable. 51 | 52 | Here is how the components work together: 53 | 54 | * **nsync** receives a message from the Cloud Controller when the user scales an app. It writes the number of instances into a `DesiredLRP` structure in the Diego BBS database. 55 | * **BBS** uses its convergence process to monitor the `DesiredLRP` and `ActualLRP` values. It runs or stops application instances as appropriate to ensure the `ActualLRP` count matches the `DesiredLRP` count. 56 | * **Cell Rep** monitors the containers and provides the `ActualLRP` value. 57 | 58 | 59 | ## App Storage and Execution 60 | 61 | ### Blobstore 62 | 63 | The blobstore is a repository for large binary files, which Github cannot easily manage because GitHub is designed for code. The blobstore contains the following: 64 | 65 | * Application code packages 66 | * Buildpacks 67 | * Droplets 68 | 69 | You can configure the blobstore as either an internal server or an external S3 or S3-compatible endpoint. <%= vars.blobstore_kb %> 70 | 71 | ### Diego Cell 72 | 73 | Application instances, application tasks, and staging tasks all run as [Garden](garden.html) containers on the Diego Cell VMs. The Diego cell rep component manages the lifecycle of those containers and the processes running in them, reports their status to the Diego BBS, and emits their logs and metrics to [Loggregator](#metrics-logging). 74 | 75 | 76 | ## Services 77 | 78 | ### Service Brokers 79 | 80 | Applications typically depend on <%= vars.services %> such as databases or third-party SaaS providers. When a developer provisions and binds a service to an application, the service broker for that service is responsible for providing the service instance. 81 | 82 | 83 | ## Messaging 84 | 85 | ### Internal HTTPS and BBS 86 | 87 | The component VMs of <%= vars.app_runtime_abbr %> communicate with each other internally through HTTP and HTTPS protocols, sharing temporary messages and data stored in Diego's [Bulletin Board System (BBS)](../diego/diego-architecture.html#bbs). 88 | 89 | * BOSH Director colocates a [BOSH DNS](https://bosh.io/docs/dns/) server on every deployed VM. All VMs keep up-to-date DNS records for all the other VMs in the same foundation, enabling service discovery between VMs. BOSH DNS also provides client-side load-balancing by randomly selecting a healthy VM when multiple VMs are available. 90 | 91 | * Diego's [Bulletin Board System](../diego/diego-architecture.html#bbs) (BBS) stores more frequently updated and disposable data such as cell and app status, unallocated work, and heartbeat messages, as well as longer-lived distributed locks. The BBS stores data in MySQL, using the [Go MySQL Driver](https://github.com/go-sql-driver/mysql). 92 | 93 | The route emitter component uses the NATS protocol to broadcast the latest routing tables to the routers. 94 | 95 | 96 | ## Metrics and Logging 97 | 98 | ### Loggregator 99 | 100 | The Loggregator (log aggregator) system streams application logs to developers. 101 | 102 | <% if vars.platform_code == "CF" %> 103 | 104 | For more information about the Loggregator, see Loggregator Architecture. 105 | 106 | <%= partial 'old_collector' %> 107 | 108 | <% else %> 109 | 110 | For more information about the Loggregator architecture, see Loggregator Architecture. 111 | 112 | <% end %> 113 | -------------------------------------------------------------------------------- /architecture/uaa.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: User account and Authentication server 3 | owner: Identity 4 | --- 5 | 6 | This topic tells you about the User Account and Authentication (UAA) Server, the identity management service for <%= vars.app_runtime_first %>. 7 | 8 | The primary role of UAA is as an OAuth2 provider, that issues tokens for client apps to use 9 | when they act on behalf of <%= vars.app_runtime_abbr %> users. 10 | In collaboration with the login server, UAA can authenticate users with their <%= vars.app_runtime_abbr %> credentials, and can act as an SSO service using those, or other, credentials. 11 | 12 | UAA has endpoints for managing user accounts, registering OAuth2 clients, and various 13 | other management functions. 14 | 15 | Different runtimes and services use separate UAA instances. <%= vars.app_runtime_abbr %> has two UAA instances by default: one for BOSH Director, used to bootstrap the rest of the <%= vars.app_runtime_abbr %> deployment; and one for the BOSH deployment, used as a shared resource by all apps that require user authentication. This is the minimum number of UAA instances <%= vars.app_runtime_abbr %> must have. Other runtimes and services also have UAA instances. These instances are separate from each other. If you log into one runtime or service, you are not also logged into other runtimes and services that authenticate using UAA. 16 | You must log in to each runtime or service separately. 17 | 18 | You can deploy UAA locally or to <%= vars.app_runtime_abbr %>. 19 | See also [Deploy UAA](/uaa/uaa-deploy.html). 20 | 21 | ## UAA architecture 22 | 23 | The following diagram illustrates the architecture of UAA: 24 | 25 | ![UAA architecture](../images/uaa-architecture.png) 26 | 27 | The following table describes the protocols UAA can use: 28 | 29 | | Protocol | Purpose | Profiles | 30 | | -------- | ------- | -------- | 31 | | OAuth 2.0 | Authorizes apps and APIs | Authorization Server, Relying Party | 32 | | OpenID Connect 1.0 | Federates to external identity providers (IDPs) and acts as an IDP for SSO | Identity Provider, Relying Party | 33 | | SAML 2.0 | Federates to external IDPs | Service Provider | 34 | | LDAP | Authenticates users in external user store | LDAP Client | 35 | | SCIM 1.0 | Manages users and groups | Identity Provisioning | 36 | 37 | 38 | ## Client-side tools and libraries 39 | 40 | The following table describes the client-side tools and libraries UAA uses: 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 |
NameLanguage
UAAC
52 | CF-UAA-LIB		Ruby
Spring Security OAuthJava
CF Java ClientJava
UAA Javascript SDK (Singular)JS
69 | -------------------------------------------------------------------------------- /cc-blobstore.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Controller blobstore 3 | owner: CAPI 4 | --- 5 | 6 | To stage and run apps, <%= vars.app_runtime_abbr %> manages and stores the following types of 7 | binary large object (blob) files: 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 |
Blob TypeDescriptionLocation in Blobstore
App PackagesFull contents of app directories, including source code and resource files, zipped into single blob files./cc-packages
BuildpacksBuildpack directories, which Diego cells download to compile and stage apps with./cc-buildpacks
Resource CacheLarge files from app packages that the Cloud Controller stores with a SHA for later re-use. To save bandwidth, the <%= vars.app_runtime_abbr %> Command Line Interface (cf CLI) only uploads large application files that the Cloud Controller has not already stored in the resource cache./cc-resources
Buildpack CacheLarge files that buildpacks generate during staging, stored for later re-use. This cache lets buildpacks run more quickly when staging apps that have been staged previously.cc-droplets/buildpack_cache
DropletsStaged apps packaged with everything needed to run in a container./cc-droplets
41 | 42 | <%= vars.app_runtime_abbr %> blobstores use the [Fog](http://fog.io/) Ruby gem to store blobs in 43 | services like Amazon S3, WebDAV, or the NFS filesystem. The file system location of an internal blobstore is `/var/vcap/store/shared`. 44 | 45 | A single blobstore typically stores all five types of blobs, but you can configure the Cloud Controller to use separate blobstores for each type. 46 | This topic references staging and treats all blobstores as generic object stores. 47 | 48 | For more information about staging, see [How Apps Are Staged](../concepts/how-applications-are-staged.html). 49 | 50 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 51 | 52 | For more information about how specific third-party blobstores can be configured, see <%= vars.blobstore_link %>. 53 | <% end %> 54 | 55 | ## Staging using the blobstore 56 | 57 | This section describes how staging buildpack apps uses the blobstore. 58 | 59 | The following diagram illustrates how the staging process uses the blobstore. 60 | To walk through the same diagram in an app staging context, see [How Diego Stages Buildpack Apps](./how-applications-are-staged.html). 61 | The staging process for buildpack apps includes a developer and the following components: CF Command Line, Cloud Controller (CCNG), Blobstore, cc-uploader, Diego Cell (Staging), and Diego Cell (Running). 62 | 63 | * Step 1: cf push from Developer to CF CLI. 64 | * Step 2: Checksum source files from Developer to CF CLI. 65 | * Step 3: Resource Match from CF CLI to the CCNG. 66 | * Step 4: Check file existence from the CCNG to Blobstore. 67 | * Step 5: Upload unmatched files from CF CLI to CCNG. 68 | * Step 6: Download cached files from Blobstore to CCNG. 69 | * Step 7: Upload complete package from CCNG to Blobstore. 70 | * Step 8: Download package and buildpack from Blobstore to Diego Cell (Staging). 71 | * Step 9: Upload droplet from Diego Cell (Staging) through cc-uploader, then CCNG, to the Blobstore. 72 | * Step 10: Download droplet from Blobstore to CCNG. 73 | 74 | ![Full description of this diagram is in the text.](./images/cc-blobstore-staging.png) 75 | 76 | [//]: https://docs.google.com/drawings/d/1LbM5mRjJMOfQXVvJXmDb-csfV61kHaPJaCJy20WVqMI/edit?usp=sharing 77 | 78 | The process in which the staging process uses the blobstore is as follows: 79 | 80 | 1. **cf push:** A developer runs `cf push`. 81 | 82 | 1. **Create app:** The Cloud Foundry Command Line Interface (cf CLI) gathers local source code files and computes a checksum of each. 83 | 84 | 1. **Store app metadata:** The cf CLI makes a `resource_matches` request, which matches resources to Cloud Controller. The request lists file names and their checksums. For more information and an example API request, see [Resource Matches](http://v3-apidocs.cloudfoundry.org/version/3.74.0/index.html#resource-matches) in the <%= vars.app_runtime_abbr %> API documentation. 85 | 86 | 1. **Check file existence** includes the following: 87 |
    88 |
  1. The Cloud Controller makes a series of `HEAD` requests to the blobstore to find out which files it has cached.
    2. 89 |
  2. Cloud Controller content-addresses its cached files so that changes to a file result in it being stored as a different object.
    3. 90 |
  3. Cloud Controller computes which files it has and which it needs the cf CLI to upload. This process can take a long time. 91 |
  4. In response to the resource match request, Cloud Controller lists the files the cf CLI needs to upload.
    5. 92 |
93 | 94 | 1. **Upload unmatched files:** The cf CLI compresses and uploads the unmatched files to Cloud Controller. 95 | 96 | 1. **Download cached files:** Cloud Controller downloads, to its local disk, the matched files that are cached in the blobstore. 97 | 98 | 1. **Upload complete package** includes the following: 99 |
    100 |
  1. Cloud Controller compresses the newly uploaded files with the downloaded cached files in a ZIP file.
    2. 101 |
  2. Cloud Controller uploads the complete package to the blobstore.
    3. 102 |
103 | 104 | 1. **Download package & buildpack(s):** A Diego Cell downloads the package and its buildpacks into a container and stages the app. 105 | 106 | 1. **Upload droplet** includes the following: 107 |
    108 |
  1. After the app has been staged, the Diego Cell uploads the complete droplet to `cc-uploader`.
    2. 109 |
  2. `cc-uploader` makes a multi-part upload request to upload the droplet to Cloud Controller.
    3. 110 |
  3. Cloud Controller enqueues an asynchronous job to upload to the blobstore.
    4. 111 |
112 | 113 | 1. **Download droplet** includes the following: 114 |
    115 |
  1. A Diego Cell attempts to download the droplet from Cloud Controller into the app container.
    2. 116 |
  2. Cloud Controller asks the blobstore for a signed URL.
    3. 117 |
  3. Cloud Controller redirects the Diego Cell droplet download request to the blobstore.
    4. 118 |
  4. A Diego Cell downloads the app droplet from the blobstore and runs it.
    5. 119 |
120 | 121 | ## Blobstore Cleanup 122 | 123 | ### How Cloud Controller reaps expired packages, droplets, and buildpacks 124 | 125 | As new droplets and packages are created, the oldest ones associated with an app are marked as `EXPIRED` if they exceed the configured limits for packages and droplets stored per app. 126 | 127 | Each night, starting at midnight, Cloud Controller runs a series of jobs to delete the data associated with expired packages, droplets, and buildpacks. 128 | 129 | Enabling the native versioning feature on your blobstore increases the number of resources stored and costs. For more information, see [Using Versioning](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) in the AWS documentation. 130 | 131 | ### Automatic Orphaned Blob Cleanup 132 | 133 | Orphaned Blobs are blobs that are stored in the blobstore, but Cloud Controller does not list in its database. These are distinct from [Expired Blobs](#blobstore-expiry), which Cloud Controller can still link to a particular package, droplet, or buildpack. 134 | 135 | Orphaned Blobs are typically created after a blob deletion fails silently or something else goes wrong. 136 | 137 | Cloud Controller detects and removes Orphaned Blobs by scanning part of the blobstore daily and checking for any blobs that its database does not account for. The process scans through the entire blobstore every week, and only removes blobs that show as orphans for three consecutive days. 138 | 139 | Cloud Controller performs this automatic cleanup when the `cloud_controller_worker` job property `cc.perform_blob_cleanup` is set to `true`. 140 | 141 |

142 | Two instances of Cloud Foundry should not use the same blobstore buckets, as the uploaded blobs will be marked as 'orphaned' by the other Cloud Foundry instance and deleted.

143 | 144 | ### Manual blob cleanup 145 | 146 | Cloud Controller does not track resource cache and buildpack cache blob-types in its database, so it does not [reap them automatically](#blobstore-expiry) as it does with app package, buildpack, and droplet type blobs. 147 | 148 | To clean up the buildpack cache, admin users can run `cf curl -X DELETE /v2/blobstores/buildpack_cache`. This empties the buildpack cache completely, which is a safe operation. 149 | 150 | To clean up the resource cache, delete it as follows: 151 | 152 | * **Internal blobstore**: Run `bosh ssh` to connect to the blobstore VM (NFS or WebDav) and `rm *` the contents of the `/var/vcap/store/shared/cc-resources` directory. 153 | * **External blobstore**: Use the file store's API to delete the contents of the `resources` bucket. 154 | 155 | Do not manually delete app package, buildpack, or droplet blobs from the blobstore. To free up resources from those locations, run `cf delete-buildpack` for buildpacks or `cf delete` for app packages and droplets. 156 | 157 | ## Blobstore load 158 | 159 | The load that Cloud Controller generates on its blobstore is unique due to resource matching. 160 | Many blobstores that perform well under normal read, write, and delete loada are overwhelmed by 161 | Cloud Controller's heavy use of HEAD requests during resource matching. 162 | 163 | Pushing an app with large number of files causes Cloud Controller to check the blobstore for the existence of each file. 164 | 165 | Parallel BOSH deployments of Diego Cells can also generate significant read load on the Cloud Controller blobstore as the cells perform evacuation. For more information, see the [Evacuation](https://docs.cloudfoundry.org/devguide/deploy-apps/app-lifecycle.html#evacuation) section of the _App Container Lifecycle_ topic. 166 | 167 | ## Blobstore interaction timeouts 168 | 169 | Cloud Controller inherits default blobstore operation timeouts from Excon. 170 | Excon defaults to 60 second read, write, and connect timeouts. 171 | 172 | For more information, see the [excon](https://github.com/excon/excon) repository on GitHub. 173 | -------------------------------------------------------------------------------- /cf-routing-architecture.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Foundry routing architecture 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | <%# Reset page title based on product title %> 7 | <% if vars.platform_code != 'CF' %> 8 | 9 | <% set_title(vars.app_runtime_abbr, "Routing Architecture") %> 10 | 11 | <% end %> 12 | 13 | This topic tells you about the routing architecture and flow in <%= vars.app_runtime_first %>. 14 | 15 | ## Routing architecture components 16 | 17 | The following summarizes the roles and responsibilities of various components 18 | depicted in the <%= vars.app_runtime_abbr %> routing architecture diagrams. 19 | These summaries are limited to the roles and responsibilities these components have pertaining to routing. For more complete descriptions of these components, see [<%= vars.app_runtime_abbr %> Concepts](https://docs.cloudfoundry.org/concepts/), [<%= vars.app_runtime_abbr %> Components](https://docs.cloudfoundry.org/concepts/architecture/), and [Diego Components and Architecture](https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html). 20 | 21 | | Component Name | Summary | 22 | |----------------|---------| 23 | | BOSH manifest | Used to configure route registrar with route(s) for system components such as UAA and Loggregator. | 24 | | Cloud Controller | Contains route metadata, including whether they are HTTP or TCP. | 25 | | Diego BBS | Contains IP and port metadata as well as route metadata from Cloud Controller, which route emitter discovers. | 26 | | Diego cell | Manages app instances and tasks and long-running processes related to them. A route emitter runs on each cell. | 27 | | Gorouter | Routes HTTP traffic coming into <%= vars.app_runtime_abbr %> to the appropriate component. Receives route updates through NATS. Routes that have not been updated in two minutes are pruned from the Gorouter's database. | 28 | | NATS | Receives routing configuration from route emitter and provides same to Gorouter. | 29 | | Route registrar | Sends routing metadata described in BOSH manifest for system components such as UAA and Loggregator to NATS. This is because the Diego cell does not have information about system components, only about user spaces. | 30 | | Route emitter | Periodically emits route, IP, and port metadata to NATS or Routing API as registration and unregistration messages. Does not know about app instances on Diego cell, but knows what cell it belongs to and learns about what app instances are running on its cell by asking Diego BBS for information about app instances on the same cell. | 31 | | Routing API | Receives routing configuration from route emitter and other internal clients, and provides routing configuration for TCP router. | 32 | | Routing database | Saves some routing data from Routing API. If the Gorouter misses a message about an unmapped route from NATS, it does not get it again, so TCP router and Routing API can consult routing database for current state of routes. | 33 | | TCP router | Routes TCP traffic coming into <%= vars.app_runtime_abbr %> to the appropriate component. Receives route updates through the routing API. | 34 | | HealthChecker | An executable designed to perform TCP/HTTP-based health checks of processes managed by monit in BOSH releases. Because the version of monit included in BOSH does not support specific TCP/HTTP health checks, this utility is designed to perform health checking, and restart processes if they become unreachable. | 35 | 36 | ## Making a request to external client 37 | 38 | The following process tells you about how an external client makes a request to an 39 | app running on <%= vars.app_runtime_abbr %>: 40 | 41 | 1. The external client sends its request. 42 | 43 | 1. Your DNS service sends the request to the HTTP or TCP load balancer based on the prefix of the DNS name in the client request, such as `http` in `http.example.com`. 44 | 45 | 1. The load balancer sends the request to the load balancer's corresponding router. 46 | 47 | 1. The router sends the request to the app. 48 | 49 | ![External client request flow. The External Client sends out two data flows, one to the HTTP Load Balancer (http.cf-apps.com) and one to the TCP Load Balancer (tcp.cf-apps.com). HTTP Load Balancer sends data through Gorouter to the HTTP Application. TCP Load Balancer sends data through TCP Router to the TCP Application. Gorouter, TCP Router, HTTP Application, and TCP Application are co-located in in a box labelled Cloud Foundry.](./images/external-client-call-app.png) 50 | 51 | ## Maintaining updated routing tables 52 | 53 | Because each app can have many instances, one app route can go to multiple containers. 54 | As Diego moves and scales app instances, the route emitter on each cell sends messages to NATS or 55 | the Routing API to register and deregister routes to the cell's app instances. 56 | 57 | The route emitter periodically emits the routes it discovers from Diego BBS to NATS and the Routing API as registration and unregistration messages every twenty seconds. The Gorouter and TCP router use TLS to verify app identity and confirm that its routes are up-to-date. For more information about how <%= vars.app_runtime_abbr %> maintains route consistency, see [Preventing Misrouting](http-routing.html#consistency) in _HTTP Routing_. 58 | 59 | The following process describes how a router obtains information about routes for an app running on <%= vars.app_runtime_abbr %>: 60 | 61 | 1. Cloud Controller component sends app route information to Diego BBS. For HTTP routing, route information includes the host and path of an external URL, as shown in the format of the [`router.register` message](https://github.com/cloudfoundry/gorouter#registering-routes-via-nats) in the Gorouter documentation on GitHub. For TCP routing, route information includes the route port on which the TCP connection was received; for more information, see the [Routing API documentation on GitHub](https://github.com/cloudfoundry/routing-api/blob/main/docs/02-api-docs.md#create-tcp-routes). 62 | 63 | 1. Diego BBS coordinates the back end IP address and port where each instance of the app runs. When queried by the route emitter, the BBS sends this information along with the Cloud Controller app route information to the route emitter on the Diego cell where instances of the app are located. 64 | 65 | 1. If a route is HTTP, the route emitter on the Diego cells sends app route, IP, and port information to NATS, which then sends it to the Gorouter. If a route is TCP, the route emitter sends that information to the Routing API, which then sends it to the TCP router. 66 | 67 | 1. Gorouter and TCP router use the route, IP, and port information from the route emitter to map incoming app requests to back end app instance locations. 68 | 69 | ![Routing architecture](./images/cf-routing-architecture.png) 70 | 71 | ### Routing table recovery after component failure 72 | 73 | Cloud Controller and Diego BBS have their own databases, while NATS and the Gorouter only store 74 | their data in memory. If NATS or the Gorouter are restarted, they lose all of their data and must 75 | wait for the route emitter to send data to them again. If Diego BBS is restarted, it can retrieve its data from Cloud Controller. 76 | 77 | If Cloud Controller is restarted, you must retrieve its data from a backup. 78 | -------------------------------------------------------------------------------- /contribute.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Contribute to Cloud Foundry documentation 3 | owner: Docs 4 | --- 5 | 6 | You can contribute to <%= vars.platform_name %> documentation. 7 | 8 | The <%= vars.platform_name %> documentation relies on contributions from the community to remain accurate, complete, and consumable. 9 | 10 | Reasons to contribute to the <%= vars.platform_name %> documentation are: 11 | 12 | * You noticed that a topic is incorrect or incomplete. 13 | * You are developing a new <%= vars.platform_name %> feature and want to tell users know how to use it. 14 | * You want to help your fellow humans. 15 | * You do not like the idea of someone else having to go through what you just went through to figure something out. Such a waste; so inefficient. 16 | 17 | 18 | ## How can you contribute? 19 | 20 | The source files for all <%= vars.platform_name %> documentation are hosted on [GitHub](http://github.com), and each documentation page has a link to its GitHub source file at the bottom. The source files are in Markdown/HTML/embedded Ruby (`html.md.erb`) format. 21 | 22 | If you use GitHub, the most direct and effective way to contribute to the documentation is to submit a pull request (PR) or raise an issue in the GitHub repository containing the documentation that you want to change. For more information, see [Submit a GitHub Pull Request](#github-pr) and [Raise a GitHub Issue](#github-issue). 23 | 24 | If you do not already use GitHub, you can contribute to the <%= vars.platform_name %> documentation in other ways. For more information, see [Contribute Without GitHub](#non-github). 25 | 26 | Whichever way you contribute, please follow the guidelines in [Advice for Contributors](#advice). 27 | 28 | ### Submitting a GitHub pull request 29 | 30 | If you have identified a problem with the documentation and know the required content change, the fastest way to make the change is by submitting a PR. 31 | 32 | The <%= vars.platform_name %> documentation team typically accepts PRs within a day, but might need to ask follow up questions. 33 | 34 | Before your PRs can be accepted, you must have a signed Contributor License Agreement (CLA) on file. If you do not, you are prompted to sign a CLA once you have opened your first PR. 35 | 36 | To submit a pull request: 37 | 38 | 1. Go to the topic that you want to modify. 39 | 40 | 1. To locate the GitHub source file that contains the content for the topic, scroll to the bottom of the page and click **Create a pull request or raise an issue on the source for this page in GitHub.** 41 | 42 | 1. Click the pencil icon to edit the file in GitHub. 43 | 44 | 1. Make your desired changes. 45 | 46 | 1. Under **Commit changes** at the bottom of the page, enter a description of your change and click **Propose file change**. 47 | 48 | 1. Click **Create pull request**. 49 | 50 | ### Raising a GitHub issue 51 | 52 | If you do not have specific edits to make, but want start a discussion or make a general suggestion, you can raise a GitHub issue. 53 | 54 | GitHub issues take longer to resolve than pull requests. But, if you describe the issue with helpful background information, and have specific and actionable instructions, the <%= vars.platform_name %> documentation team can quickly address it. 55 | 56 | Vague or partially-baked GitHub issues might remain unaddressed for some time. 57 | 58 | To raise an issue on a GitHub repository: 59 | 60 | 1. Go to the topic that you want to modify. 61 | 62 | 1. To locate the GitHub source file that contains the content for the topic: 63 | 1. Scroll to the bottom of the page. 64 | 1. Click **Create a pull request or raise an issue on the source for this page in GitHub.** 65 | 66 | 1. Click the name of the repository where the topic is located. For example, `docs-dev-guide`. 67 | 68 | 1. Click the **Issues** tab. 69 | 70 | 1. Click **New issue**. 71 | 72 | 1. Enter a title for your issue, and in the text box, describe the issue and provide links to the relevant topics. 73 | 74 | 1. Click **Submit new issue**. 75 | 76 | ### Contributing without GitHub 77 | 78 | To contribute to the <%= vars.platform_name %> docs without using GitHub, you can use one of these methods: 79 | 80 | * **Send Feedback** link (TAS for VMs) or **Create a pull request or raise an issue on the source for this page in GitHub** (Cloud Foundry) on any page of the documentation. 81 | 82 | * **Slack** the <%= vars.platform_name %> docs team through the [#cf-docs](https://cloudfoundry.slack.com/messages/C03B0T0D5/") channel in <%= vars.platform_name %> Slack. 83 | 84 | 85 | ## Contributor advice 86 | 87 | The <%= vars.platform_name %> documentation team reviews and revises all contributions, so you can **focus on providing correct and complete information, and not worry about style and structure**. 88 | 89 | Keep in mind: 90 | 91 | * If your contribution is larger than a small correction, put yourselves in the shoes of a novice and read through it. Revise the text to answer any questions that might occur to a less experienced user. 92 | 93 | * Who needs this information? Are they a developer or a platform operator? 94 | 95 | * What are the specifics that a user needs to know in order to understand and perform the task? Instead of "the instance" or "the cluster," explain the instance or cluster of what. Instead of "revise the code to...", explain where to revise the code. 96 | 97 | * If you are giving instructions, include why you would want to do what you are describing. What is your specific situation, and what result do you seek? 98 | 99 | For further guidance, contact the <%= vars.platform_name %> documentation team on our `#cf-docs` channel on the [<%= vars.platform_name %> Slack](https://cloudfoundry.slack.com). 100 | 101 | 102 | ## Previewing documentation changes 103 | 104 | The <%= vars.platform_name %> documentation team uses the tool [Bookbinder](https://github.com/pivotal-cf/bookbinder) to publish the <%= vars.platform_name %> documentation. 105 | 106 | The following instructions explain how to use Bookbinder to preview your documentation changes locally. But you do not have to install or use Bookbinder in order to contribute to the <%= vars.platform_name %> documentation. 107 | 108 | To preview documentation changes with Bookbinder: 109 | 110 | 1. If you do not already have a workspace directory within your home directory, create one by running: 111 | 112 | ``` 113 | mkdir ~/workspace 114 | ``` 115 | 116 | 1. Identify the content repository where your documentation is located. For example, `https://github.com/cloudfoundry/docs-cloudfoundry-concepts`. 117 | 118 | 1. Clone the content repository. For example, to clone the `docs-cloudfoundry-concepts` repository, run: 119 | 120 | ``` 121 | git clone git@=github.com:cloudfoundry/docs-cloudfoundry-concepts.git 122 | ``` 123 | 124 | 1. Return to your workspace directory and clone the <%= vars.platform_name %> book by running: 125 | 126 | ``` 127 | git clone git@=github.com:cloudfoundry/docs-book-cloudfoundry.git 128 | ``` 129 | 130 | 1. Change directory into the <%= vars.platform_name %> book by running: 131 | 132 | ``` 133 | cd docs-book-cloudfoundry 134 | ``` 135 | 136 | 1. To install the necessary gems, including Bookbinder, run: 137 | 138 | ``` 139 | bundle install 140 | ``` 141 | 142 | 1. To use Bookbinder to create a live version of your docs, run: 143 | 144 | ``` 145 | bundle exec bookbinder watch 146 | ``` 147 | 148 | 1. Start a browser and go to `http://localhost:4567` to where your docs are published. For instance, `http://localhost:4567/cf-cli/install-go-cli.html`. 149 |

150 | Bookbinder automatically updates the live version of the documentation whenever you make a change to the content repository. 151 | -------------------------------------------------------------------------------- /diego/diego-auction.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: How Diego balances app processes in Cloud Foundry 3 | owner: Diego 4 | --- 5 | 6 | Diego balances app processes over the virtual machines (VMs) in a <%= vars.app_runtime_abbr %> installation 7 | using the Diego Auction. When new processes need to be allocated to VMs, 8 | the Diego Auction determines which ones must run on which physical machines. The auction algorithm balances the load on VMs and optimizes app availability and resilience. This topic explains how the Diego Auction works. 9 | 10 | For more information, see [Diego Components and Architecture](./diego-architecture.html) and the [Auction](https://github.com/cloudfoundry-incubator/auction) repository on GitHub. 11 | 12 | 13 | ## Tasks and long running processes 14 | 15 | Diego Auction distinguishes between two types of jobs: **Tasks** and **Long-Running Processes** (LRPs). 16 | 17 | * **Tasks** run once, for a finite amount of time. A common example is a staging task that compiles an app's dependencies, to form a self-contained droplet that makes the app portable and runnable on multiple VMs. Other examples of tasks include making a database schema change, bulk importing data to initialize a database, and setting up a connected service. 18 | 19 | * **Long-Running Processes** run continuously, for an indefinite amount of time. LRPs terminate only if they crash or are stopped. Examples include web servers, asynchronous background workers, and other applications and services that continuously accept and process input. To make high-demand LRPs more available, Diego might allocate multiple instances of the same application to run simultaneously on different VMs, often spread across Availability Zones that serve users in different geographic regions. 20 | 21 | Diego Auction process is repeated whenever new jobs need to be allocated to VMs. 22 | Each auction distributes a current **batch** of work, Tasks and LRPs, that can include newly created jobs, jobs left unallocated in the previous auction, and jobs left orphaned by failed VMs. Diego does not redistribute jobs that are already running on VMs. Only one auction can take place at a time, which prevents placement collisions. 23 | 24 | 25 | ## Ordering the auction batch 26 | 27 | Diego Auction algorithm allocates jobs to VMs to fulfill the following outcomes, in decreasing **priority** order: 28 | 29 | 1. Keep at least one instance of each LRP running. 30 | 31 | 1. Run all of the Tasks in the current batch. 32 | 33 | 1. Distribute as much of the total desired LRP load as possible over the remaining available VMs, by spreading multiple LRP instances broadly across VMs and their Availability Zones. 34 | 35 | To achieve these outcomes, each auction begins with the Diego Auctioneer component 36 | arranging the batch jobs into a priority order. Some of these jobs might be 37 | duplicate instances of the same process that Diego needs to allocate for high-traffic LRPs to meet demand. 38 | The Auctioneer creates a list of multiple LRP instances based on the 39 | desired instance count configured for each process. 40 | 41 | For more information, see the [Step 2: Passing a request to the auctioneer process](./diego-architecture.html#step-2) section of the _Diego Components and Architecture_ topic. 42 | 43 | For example, if the process LRP-A has a desired instance count of 3 and a memory load of 2, and process LRP-B has 2 desired instances and a load of 5, the Auctioneer creates a list of jobs for each process as follows: 44 | 45 | ![For process LRP-A, the Auctioneer lists jobs LRP-A.1, LRP-A.2, and LRP-A.3. For process LRP-B, the Auctioneer lists jobs LRP-B.1 and LRP-B.2.](../images/diego/auctioneer-job-list.png) 46 | 47 | The Auctioneer then builds an ordered sequence of LRP instances by cycling through the list of LRPs in decreasing order of load. With each cycle, it adds another instance of each LRP to the sequence, until all desired instances of the LRP have been added. With the example above, the Auctioneer would order the LRPs like this: 48 | 49 | ![LRP sequence](../images/diego/diego-LRP-stack.png) 50 | 51 | The Auctioneer then builds an ordered sequence for all jobs, both LRPs and Tasks. Reflecting the auction batch priority order, the first instances of LRPs are first priority. Tasks are next, in decreasing order of load. Duplicate LRP jobs come last. 52 | 53 | Adding one-time Task-C (load = 4) and Task-D (load = 3) to the above example, the priority order becomes: 54 | 55 | ![Auction sequence](../images/diego/diego-auction-stack.png) 56 | 57 | The previous diagram shows the following content: 58 | 59 | - Title: Auction Sequence 60 | 61 | - Priority Group 1 62 | 63 | - LRP-B.1 (wide box) 64 | 65 | - LRP-A.1 (narrow box) 66 | 67 | - Priority Group 2 68 | 69 | - Task-C (medium-wide box) 70 | 71 | - Task-D (narrower box) 72 | 73 | - Priority Group 3 74 | 75 | - LRP-B.2 (wide box) 76 | 77 | - LRP-A.2 (narrow box) 78 | 79 | - LRP-A.3 (narrow box) 80 | 81 | 82 | ## Auctioning the batch to the Diego Cells 83 | 84 | With all jobs sorted in priority order, the Auctioneer allocates each in turn to one of the VMs. The process resembles an auction, where VMs "bid" with their suitability to run each job. Facilitating this process, each app VM has a resident Diego Cell that monitors and allocates the machine's operation. The Diego Cell participates in the auction on behalf of the virtual machine that it runs on. For more information, see the [Diego Components](./diego-architecture.html#components) section of the _Diego Components and Architecture_ topic. 85 | 86 | Starting with the highest priority job in the ordered sequence, the Auctioneer polls all the Diego Cells on their fitness to run the currently-auctioned job. 87 | 88 | Diego Cells "bid" to host each job according to the following priorities, in decreasing order: 89 | 90 | 1. Allocate all jobs only to Diego Cells that have the correct software stack to host them, and sufficient resources given their allocation so far during this auction. 91 | 92 | 1. Allocate LRP instances into Availability Zones that are not already hosting other instances of the same LRP. 93 | 94 | 1. Within each Availability Zone, allocate LRP instances to run on Diego Cells that are not already hosting other instances of the same LRP. 95 | 96 | 1. Allocate any job to the Diego Cell that has lightest load, from both the current auction and jobs it has been running already. In other words, distribute the total load evenly across all Diego Cells. 97 | 98 | This example auction sequence has seven jobs: five LRP instances and two Tasks. 99 | 100 | The following diagram shows how the Auctioneer might distribute this work across four Diego Cells running in two Availability Zones: 101 | 102 | ![Auctioneer work distribution](../images/diego/diego-auction-process.png) 103 | 104 | If the Auctioneer reaches the end of its sequence of jobs, having distributed all jobs to the Diego Cells, it submits requests to the Diego Cells to run their allotted work. If the Diego Cells run out of capacity to handle all jobs in the sequence, the Auctioneer carries the unallocated jobs over and merges them into the next auction batch, to be allocated in the next auction. 105 | 106 | ## Triggering another auction 107 | 108 | The Diego Auction process repeats to adapt a <%= vars.app_runtime_abbr %> deployment to its changing workload. For example, the BBS initiates a new auction when it detects that the actual number of running instances of LRPs does not match the number desired. Diego's BBS component monitors the number of instances of each LRP that are currently running. The BBS component periodically compares this number with the desired number of LRP instances, as configured by the user. If the actual number falls short of what is desired, the BBS triggers a new auction. In the case of a surplus of app instances, the BBS stops the extra instances and initiates another auction. 109 | 110 | Cloud Controller also starts an auction whenever a Diego Cell fails. After any auction, if a Diego Cell responds to its work request with a message that it cannot perform the work after all, the Auctioneer carries the unallocated work over into the next batch. But if the Diego Cell fails to respond entirely, for example if its connection times out, the unresponsive Diego Cell might still be running its' work. In this case, the Auctioneer does not automatically carry the Diego Cell's work over to the next batch. Instead, the Auctioneer defers to the BBS to continue monitoring the states of the Diego Cells, and to reassign unassigned work later if needed. 111 | -------------------------------------------------------------------------------- /diego/ssh-conceptual.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Foundry app SSH components and processes 3 | owner: Diego 4 | --- 5 | 6 | This topic tells you about the <%= vars.app_runtime_first %> SSH components that are used for access 7 | to deployed app instances. <%= vars.app_runtime_abbr %> supports native SSH access to apps and load balancing of SSH sessions with the load balancer for your <%= vars.app_runtime_abbr %> deployment. 8 | 9 | For procedural and configuration information about app SSH access, see [SSH Overview](../../devguide/deploy-apps/app-ssh-overview.html). 10 | 11 | 12 | ## SSH components 13 | 14 | <%= vars.app_runtime_abbr %> SSH includes two central components: an implementation of an SSH proxy server and a lightweight SSH daemon. If these components are deployed and configured correctly, they provide a 15 | simple and scalable way to access containers apps and other long-running processes (LRPs). 16 | 17 | ### SSH daemon 18 | 19 | SSH daemon is a lightweight implementation that is built around the Go SSH library. It supports command execution, interactive shells, local port forwarding, and secure copy. The daemon is self-contained and has no dependencies on the container root file system. 20 | 21 | The daemon is focused on delivering basic access to app instances in <%= vars.app_runtime_abbr %>. It is intended to run as an unprivileged process, and interactive shells and commands run as the daemon user. The daemon 22 | only supports one authorized key, and it is not intended to support multiple users. 23 | 24 | The daemon is available on a file server and Diego LRPs that want to use it can include a 25 | download action to acquire the binary and a run action to start it. 26 | <%= vars.app_runtime_abbr %> apps download the daemon as part of the lifecycle bundle. 27 | 28 | ### SSH proxy authentication 29 | 30 | The SSH proxy hosts the user accessible SSH endpoint and is responsible for authentication, 31 | policy enforcement, and access controls in the context of <%= vars.app_runtime_abbr %>. 32 | After you successfully authenticate with the proxy, the proxy attempts to locate 33 | the target container and create an SSH session to a daemon running inside the container. 34 | After both sessions have been established, the proxy manages the communication between your SSH client 35 | and the container SSH Daemon. 36 | -------------------------------------------------------------------------------- /glossary.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Foundry component glossary 3 | --- 4 | 5 | <%# Reset page title based on product title %> 6 | <% if vars.platform_code != 'CF' %> 7 | 8 | <% set_title(vars.app_runtime_abbr, "Component Glossary") %> 9 | 10 | <% end %> 11 | 12 | This topic tells you about <%= vars.app_runtime_first %> terms and definitions. 13 | 14 | 15 | | Term | Definition | 16 | | ------------- | ------------ | 17 | | API | Application Programming Interface | 18 | | Availability Zone (AZ) | An independent network infrastructure segment used to increase availability and fault tolerance. An AZ is often correlated with a geographical region. A cloud operator can select or assign AZs on platforms such as AWS and vSphere. | 19 | | BOSH | An open framework for managing the full development and deployment life cycle of large-scale distributed software applications. | 20 | | CLI | Command Line Interface | 21 | | Domains | A domain name like `<%= vars.app_domain %>`. Domains can also be multi level and contain sub-domains like the "myapp" in `myapp.<%= vars.app_domain %>`. Domain objects belong to an org and are not directly bound to apps. | 22 | | Droplet | An archive within <%= vars.app_runtime_abbr %> that contains the app ready to run on Diego. A droplet is the result of the application staging process. | 23 | | Managed Services | Services provided by third parties that are integrated into <%= vars.app_runtime_abbr %> through APIs so that <%= vars.app_runtime_abbr %> users can provision reserved resources and credentials on demand. Also called Custom Services. | 24 | | Management | You can manage spaces and orgs with the Cloud Foundry Command Line Interface (cf CLI), the Cloud Controller API (CAPI), and the Cloud Foundry Eclipse Plug-in. | 25 | | Org | An org is the top-most meta object within the <%= vars.app_runtime_abbr %> infrastructure. Only an account with administrative privileges on a <%= vars.app_runtime_abbr %> instance can manage its orgs. | 26 | | Routes | A route, based on a domain with an optional host as a prefix, can be associated with one or more apps. For example, `myapp` is the host and `<%= vars.app_domain %>` is the domain when using the route `myapp.<%= vars.app_domain %>`. You can have a route that represents `<%= vars.app_domain %>` without a host. Routes are children of domains and are directly bound to apps. | 27 | | Service | A "factory" which produces service instances. | 28 | | Service Instance | A reserved resource provisioned by a service. The provisioned resource differs by service. For example, the resource might be a database or an account on a multi tenant app. | 29 | | Spaces | An org can contain multiple spaces. You can map a domain to multiple spaces, but you can map a route to only one space. | 30 | | Staging | The process in <%= vars.app_runtime_abbr %> by which the raw bits of an application are transformed into a droplet that is ready to be run. | 31 | | UAA | User Account and Authentication Service, which provides the technological basis for Dashboard Single Sign-On. This is available to <%= vars.app_runtime_abbr %> users when accessing pertinent Managed Services. | 32 | | Warden | The mechanism for containerization on Diego that makes sure apps that are running on <%= vars.app_runtime_abbr %> have a fair share of computing resources and cannot access either the system code or other apps running on Diego. | 33 | -------------------------------------------------------------------------------- /grootfs-disk.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: GrootFS disk usage in Cloud Foundry 3 | owner: Garden 4 | --- 5 | 6 | This topic tells you about the concepts related to 7 | GrootFS disk space management in <%= vars.app_runtime_first %>. 8 | 9 | ## GrootFS stores 10 | 11 | GrootFS is the container root filesystem management component for Garden. 12 | A container root filesystem or _rootfs_ is often referred to as an **image**. 13 | 14 | A **GrootFS store** is the directory in which rootfs layers and container images are cached. 15 | This directory is configured by GrootFS and mounted on an XFS-formatted volume by the Garden job during BOSH VM creation. 16 | 17 | Individual container root filesystems are provided via OverlayFS mounts. 18 | 19 | Supplying GrootFS with an already formatted XFS volume for its' store is not yet supported for BOSH-controlled deployments. 20 | 21 | ### Garbage collection behavior in GrootFS stores 22 | 23 | GrootFS stores are initialized to use the entirety of `/var/vcap/data`. If the `reserved_space_for_other_jobs_in_mb` is not set high enough, 24 | or if there are many images with few shared volumes, the store can use up all available space. 25 | 26 | The thresholder component calculates and sets a value so that GrootFS's garbage collector can attempt to ensure 27 | that a small reserved space is kept free for other jobs. 28 | GrootFS only tries to garbage collect when that threshold is reached. 29 | However, if all the rootfs layers are actively in use by images, then garbage collection cannot occur and that space is used up. 30 | 31 | ## Volumes 32 | 33 | Underlying layers in rootfs images are known as `volumes` in GrootFS. 34 | They are read-only and their changesets are layered together through an **OverlayFS** mount 35 | to create the root filesystems for containers. 36 | 37 | When GrootFS writes each filesystem volume to disk, it also stores the number of bytes written 38 | to a file in a `meta` directory. 39 | The size of an individual volume is available in its corresponding metadata file. 40 | GrootFS also stores the SHA of each underlying volume used by an image in the `meta` folder. 41 | 42 | For each container, GrootFS mounts the underlying `volumes` using overlay to a point in the `images` directory. 43 | This mount point is the rootfs for the container and is read write. 44 | 45 | On disk, the read-write layer for each container can be found at `/var/vcap/data/grootfs/store/unprivileged/images/CONTAINER-ID/diff` (or `/var/vcap/data/grootfs/store/privileged/images/CONTAINER-ID/diff` for privileged containers.) 46 | 47 | When GrootFS calls on the built-in XFS quota tooling to get disk usage for a container, 48 | it takes into account data written to those `diff` directories and not the data in the read-only volumes. 49 | 50 | ### Volume Cleanup Example 51 | 52 | When `clean` is called in GrootFS, any layers that are not being used by an existing rootfs are deleted from the store. 53 | The cleanup only takes into account the `volumes` folders in the store. 54 | 55 | For example, imagine that there are two rootfs images from different base images, Image A and Image B: 56 | 57 | ``` 58 | - Image A 59 | Layers: 60 | - layer-1 61 | - layer-2 62 | - layer-3 63 | 64 | - Image B 65 | Layers: 66 | - layer-1 67 | - layer-4 68 | - layer-5 69 | ``` 70 | 71 | They have a layer in common, layer-1. And after deleting Image B, layer-4 and layer-5 can be collected by clean, 72 | but not layer-1 because Image A still uses that layer. 73 | 74 | <%= vars.grootfs_disk_usage_link %> 75 | 76 | ## Additional information 77 | 78 | For more information, see the following sections of `garden-runc-release`: 79 | 80 | * [overlay-xfs-setup](https://github.com/cloudfoundry/garden-runc-release/blob/b4a44c5cabb1570eaeb25b158823cfbd97ae530c/jobs/garden/templates/bin/overlay-xfs-setup#L23-L46) 81 | * [grootfs-utils](https://github.com/cloudfoundry/garden-runc-release/blob/b4a44c5cabb1570eaeb25b158823cfbd97ae530c/jobs/garden/templates/bin/grootfs-utils.erb#L31) 82 | * [thresholder](https://github.com/cloudfoundry/garden-runc-release/blob/b4a44c5cabb1570eaeb25b158823cfbd97ae530c/src/thresholder/main.go) 83 | -------------------------------------------------------------------------------- /ha-index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: High availability 3 | owner: Docs 4 | --- 5 | 6 | The following topics provide you with information about high availability: 7 | 8 | * [High Availability in <%= vars.app_runtime_abbr %>](high-availability.html). 9 | * [How <%= vars.app_runtime_abbr %> Maintains High Availability](maintaining-high-availability.html). 10 | -------------------------------------------------------------------------------- /high-availability.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: High Availability in Cloud Foundry 3 | owner: Release Integration 4 | --- 5 | 6 | <%# Reset page title based on product title %> 7 | <% if vars.platform_code != 'CF' %> 8 | 9 | <% set_title("High Availability in", vars.app_runtime_abbr) %> 10 | 11 | <% end %> 12 | 13 | This topic tells you about the components used to ensure high availability in <%= vars.app_runtime_first %>, vertical and horizontal scaling, and the infrastructure 14 | required to support scaling component VMs for high availability. 15 | 16 | A system with high availability provides higher than typical uptime through redundancy of apps and component VMs. You can create the redundancy required for 17 | high availability in several ways, such as running VMs in multiple availability zones and using external blob storage solutions. 18 | 19 | This topic provides you guidance on configuring 20 | your <%= vars.app_runtime_abbr %> deployment for high availability. 21 | 22 | 23 | ## Components of high availability deployments 24 | 25 | You can use availability zones, external load balancers, and 26 | external blob storage to ensure high availability for your deployment. 27 | 28 | ### Availability zones 29 | 30 | Availability Zones (AZs) are locations where public cloud services offer data centers. 31 | 32 | You can assign and scale components in multiple AZs to help maintain high availability through redundancy. To configure sufficient redundancy, deploy 33 | <%= vars.app_runtime_abbr %> across three or more AZs and assign multiple component instances to different AZs. 34 | 35 | Always use an odd number of AZs. This ensures that your deployment remains available as long as greater than half of the AZs are available. 36 | 37 | For example, a deployment with three AZs stays available when one AZ is unavailable. A deployment with five AZs stays available when two AZs are unavailable. 38 | 39 | ### External load balancers 40 | 41 | External load balancers distribute traffic coming from the internet to your internal network. 42 | 43 | To ensure high availability for production environments, use a highly available customer provided external load balancing solution that does the following: 44 | 45 | * Provides load balancing to each of the <%= vars.app_runtime_abbr %> router IP addresses. 46 | 47 | * Supports SSL termination with wildcard DNS location. 48 | 49 | * Adds appropriate `x-forwarded-for` and `x-forwarded-proto HTTP` headers to incoming requests. 50 | 51 | * (Optional) Supports WebSockets. 52 | 53 | <%= vars.external_lb %> 54 | 55 | ### External blob storage 56 | 57 | Blobs are large binary files, such as PDFs or images. To store blobs for high availability, use external storage such as Amazon S3 or an S3-compatible 58 | service. 59 | 60 | You can also store blobs internally using WebDAV or NFS. These components run as single instances and you cannot scale them. For these deployments, use the 61 | high availability features of your IaaS to immediately recover your WebDAV or NFS server VM if it fails. 62 | 63 | If you need assistance, 64 | contact Support. 65 | 66 | <%= vars.collector_singleton %> 67 | 68 | ## Scaling platform capacity 69 | 70 | You can scale platform capacity in the following ways: 71 | 72 | * **Vertical scaling:** Add memory and disk to each VM. 73 | 74 | * **Horizontal scaling:** Add more VMs that run instances of <%= vars.app_runtime_abbr %> components. 75 | 76 | The type of apps you host on <%= vars.app_runtime_abbr %> determines whether you scale vertically or horizontally. 77 | 78 | For more information about scaling apps and maintaining app uptime, see [Scaling an app using cf scale](../devguide/deploy-apps/cf-scale.html) and [Using 79 | Blue-Green Deployment to Reduce Downtime and Risk](../devguide/deploy-apps/blue-green.html) 80 | 81 | ### Scaling vertically 82 | 83 | Scaling vertically means adding memory and disk to your component VMs. 84 | 85 | To scale vertically, allocate and maintain the following: 86 | 87 | * Free space on host Diego Cell VMs so that apps expected to deploy can successfully be staged and run. 88 | 89 | * Disk space and memory in your deployment so that if one host VM is down, all instances of apps can be placed on the remaining host VMs. 90 | 91 | * Free space to handle one AZ going down if deploying in multiple AZs. 92 | 93 | ### Scaling horizontally 94 | 95 | Scaling horizontally means increasing the number of instances of VMs that run a functional component of a system. 96 | 97 | You can horizontally scale most <%= vars.app_runtime_abbr %> component VMs to multiple instances for high availability. 98 | 99 | You must also distribute the instances of components across different AZs to minimize downtime during ongoing operation, product updates, and platform 100 | upgrades. For more information about using AZs, see [Availability Zones](#azs). 101 | 102 | 103 | ## Recommended instance counts for high availability 104 | 105 | <%= vars.scaling_ert %> 106 | 107 | <% if vars.platform_code == 'CF' %> 108 | <%= partial 'oss_scale_table' %> 109 | <% else %> 110 | <%= partial "/pcf/core/pcf_scale_table" %> 111 | <% end %> 112 | 113 | ## Infrastructure for component scaling 114 | 115 | The ability to scale component VMs is important for high availability. To scale component VMs, you must make sure that the surrounding infrastructure of your 116 | deployment supports VM scaling. 117 | 118 | Learn about the infrastructure required to support scaling component VMs for high availability. 119 | 120 | <% if vars.platform_code == 'CF' %> 121 | <%= vars.max_in_flight_header %> 122 | <%= partial 'max_in_flight_text' %> 123 | <% end %> 124 | 125 | <%= vars.om_resurrector_header %> 126 | 127 | <%= vars.om_resurrector_text %> 128 | 129 | ### Resource pools 130 | 131 | Each IaaS has different ways of limiting resource consumption for scaling VMs. Consult with your IaaS administrator to ensure additional VMs and related 132 | resources, like IPs and storage, are available to scale. 133 | 134 | For more information about configuring your resource pools according to the requirements of your deployment, see <%= vars.pools_link %> 135 | 136 | <%= vars.pcf_pools %> 137 | 138 | ### Databases 139 | 140 | For database services deployed outside <%= vars.app_runtime_abbr %>, use the high availability features included with your infrastructure. Also, configure 141 | backup and restore where possible. <%= vars.scaling_ert_db %> 142 | 143 | Data services might have single points of failure depending on their configuration. 144 | 145 | <% if vars.platform_code != 'CF' %> 146 | If you need assistance, contact Support. 147 | 148 | <% else %> 149 | <% end %> 150 | -------------------------------------------------------------------------------- /how-applications-are-staged.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Staging your apps in Cloud Foundry 3 | owner: 4 | - Diego 5 | - CAPI 6 | --- 7 | 8 | This topic tells you how Diego stages buildpack apps and Docker images 9 | in <%= vars.app_runtime_first %>. 10 | 11 | <%= vars.app_runtime_abbr %> uses Diego to manage app containers. It is a self-healing system that attempts to keep the correct number of instances running in Diego Cells to avoid network failures and crashes. For more information about Diego, see [Diego Components and Architecture](../concepts/diego/diego-architecture.html). 12 | 13 | Learn about tasks and long-running processes (LRPs). 14 | 15 | For more information about these, see the [Tasks and Long-Running Processes](diego/diego-auction.html#processes) section of the _How Diego Balances App Processes_ topic. 16 | 17 | To better understand the flow and caching of source bits during staging, see the [How Staging Uses the Blobstore](../concepts/cc-blobstore.html#stage-blobstore) section of the _Cloud Controller blobstore_ topic. 18 | 19 | 20 | ## How Diego stages buildpack apps 21 | 22 | Learn how Diego stages buildpack apps. 23 | 24 | The following diagram illustrates the steps and components involved in the process of staging a buildpack app. 25 | The staging process for buildpack apps includes a developer and the following components: CF Command Line, Cloud Controller (CCNG), CCNG Blobstore, CCDB, Diego Cell (Staging), and Diego Cell (Running). 26 | 27 | * Step 1: cf push from Developer to CF Command Line. 28 | * Step 2: Create App from CF Command Line to Cloud Controller (CCNG). 29 | * Step 3: Stores App Metadata from CCNG to the CCDB. 30 | * Step 4: Upload App Files from the CF Command Line to CCNG. 31 | * Step 5: Store App Files from CCNG to CCNG Blobstore. 32 | * Step 6: App Start from CF Command Line to CCNG. 33 | * Step 7: Stage App from CCNG to Diego Cell (Staging). 34 | * Step 8: Stream Staging Output from Diego Cell (Staging) to the Developer. 35 | * Step 9: Store App Droplet from Diego Cell (Staging) to CCNG Blobstore. 36 | * Step 10: Report Staging Complete from Diego Cell (Staging) to CCNG. 37 | * Step 11: Start Staged App from CCNG to Diego Cell (Running). 38 | * Step 12: Report App Status from Diego Cell (Running) to CCNG. 39 | 40 | ![Full description of this diagram is in the text.](./images/app_push_flow_diagram_diego.png) 41 | 42 | [//]: https://docs.google.com/drawings/d/1F4vIuCLCtl4hwhMZbeDNcSGImSpaTXFnul4-xpgXOgs/edit?usp=sharing 43 | 44 | The following steps describe the process of staging a buildpack app: 45 | 46 | 1. A developer runs `cf push`. 47 | 48 | 2. Cloud Foundry Command Line Interface (cf CLI) tells the Cloud Controller to create a record for the app. For more information about the Cloud Controller, see [Cloud Controller](../concepts/architecture/cloud-controller.html). 49 | 50 | 3. Cloud Controller stores the app metadata. App metadata can include the app name, number of instances, buildpack, and other information about the app. 51 | 52 | 4. This step includes: 53 |
    54 |
  1. The cf CLI requests a resource match from the Cloud Controller.
    2. 55 |
  2. The cf CLI uploads the app source files, omitting any app files that already exist in the resource cache.
    3. 56 |
  3. The Cloud Controller combines the uploaded app files with files from the resource cache to create the app package.
    4. 57 |
58 | 59 | 5. Cloud Controller stores the app package in the blobstore. For more information, see the [Blobstore](../concepts/architecture/index.html#blob) section of the _<%= vars.app_runtime_abbr %> Components_ topic. 60 | 61 | 6. The cf CLI issues a request to start the app. 62 | 63 | 7. This step includes: 64 |
    65 |
  1. The Cloud Controller issues a staging request to Diego.
    2. 66 |
  2. Diego schedules a Diego Cell to run the staging task.
    3. 67 |
  3. The task downloads buildpacks and the app buildpack cache, if present.
    4. 68 |
  4. The task uses the buildpack to compile and stage the app.
    5. 69 |
70 | 71 | 8. Diego Cell streams the output of the staging process. You might need to view the output to troubleshoot staging problems. 72 | 73 | 9. This step includes: 74 |
    75 |
  1. The task creates a tarball, or droplet, with the compiled and staged app.
    2. 76 |
  2. The Diego Cell stores the droplet in the blobstore.
    3. 77 |
  3. The task uploads the buildpack cache to the blobstore for use the next time the app is staged.
    4. 78 |
79 | 80 | 10. Diego Bulletin Board System (BBS) reports to the Cloud Controller that staging is complete. If staging does not complete within 15 minutes, it fails. 81 | 82 | 11. Diego schedules the app as a LRP on one or more Diego Cells. 83 | 84 | 12. Diego Cells report the status of the app to the Cloud Controller. 85 | 86 | 87 | ## How Diego stages Docker images 88 | 89 | This section describes how Diego stages Docker images. 90 | 91 | The following diagram illustrates the steps and components involved in the process of staging a Docker image. 92 | The staging process for Docker images includes a developer and the following components: CF Command Line, Cloud Controller (CCNG), CCDB, Diego Cell (Staging), and Diego Cell (Running). 93 | 94 | * Step 1: CF Push from Developer to CF Command Line. 95 | * Step 2: Create Record from CF Command Line to CCNG. 96 | * Step 3: Stage Image from CCNG to CCDB. 97 | * Step 4: Stream Staging Output from Diego Cell (Staging) to Developer. 98 | * Step 5: Fetch Metadata from Diego Cell (Staging) to CCNG. 99 | * Step 6: Store Metadata from CCNG to CCDB. 100 | * Step 7: Submit LRP an Run Start Command from CCNG to Diego Cell (Running). 101 | 102 | ![Full description of this diagram is in the text.](./images/docker_push_flow_diagram_diego.png) 103 | 104 | [//]: https://docs.google.com/drawings/d/1ckWGbgTWhyc3LxP4QcVD1IgwnHu1w2XNvT28-r51Z3M/edit?usp=sharing 105 | 106 | The following describe each step in the process of staging a Docker image: 107 | 108 | 1. A developer runs `cf push` and includes the name of a Docker image in an accessible Docker Registry. 109 | 110 | 1. The cf CLI tells the Cloud Controller to create a record for the Docker image. 111 | 112 | 1. This step includes: 113 |
    114 |
  1. The Cloud Controller issues a staging request to Diego.
    2. 115 |
  2. Diego schedules a Diego Cell to run the task.
    3. 116 |
117 | 118 | 1. Diego Cell streams the output of the staging process. You might need to view the output to troubleshoot staging problems. 119 | 120 | 1. The task fetches the metadata associated with the Docker image and returns a portion of it to the Cloud Controller. 121 | 122 | 1. Cloud Controller stores the metadata in the Cloud Controller database. 123 | 124 | 1. This step includes: 125 |
    126 |
  1. Cloud Controller uses the Docker image metadata to construct a LRP that runs the start command specified in the Dockerfile.
    2. 127 |
  2. Cloud Controller submits the LRP to Diego.
    3. 128 |
  3. Diego schedules the LRP on one or more Diego Cells.
    4. 129 |
  4. Cloud Controller instructs Diego and the Gorouter to route traffic to the Docker image.
    5. 130 |
131 |

Cloud Controller takes into account any user-specified overrides specified in the Dockerfile, such as 132 | environment variables.

133 | -------------------------------------------------------------------------------- /images/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/.DS_Store -------------------------------------------------------------------------------- /images/BG_CF.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/BG_CF.jpg -------------------------------------------------------------------------------- /images/CF-Arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/CF-Arch.png -------------------------------------------------------------------------------- /images/Pipe_NavBar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/Pipe_NavBar.png -------------------------------------------------------------------------------- /images/Pipe_gBar.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/Pipe_gBar.png -------------------------------------------------------------------------------- /images/about-deploy/app_push_flow_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/about-deploy/app_push_flow_diagram.png -------------------------------------------------------------------------------- /images/add-website.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/add-website.png -------------------------------------------------------------------------------- /images/app_push_flow_diagram-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/app_push_flow_diagram-2.png -------------------------------------------------------------------------------- /images/app_push_flow_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/app_push_flow_diagram.png -------------------------------------------------------------------------------- /images/app_push_flow_diagram_diego.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/app_push_flow_diagram_diego.png -------------------------------------------------------------------------------- /images/bg-plain-x.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/bg-plain-x.jpg -------------------------------------------------------------------------------- /images/bg-plain.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/bg-plain.jpg -------------------------------------------------------------------------------- /images/bg_social_footer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/bg_social_footer.png -------------------------------------------------------------------------------- /images/c2c-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/c2c-arch.png -------------------------------------------------------------------------------- /images/cc-blobstore-staging.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cc-blobstore-staging.png -------------------------------------------------------------------------------- /images/cc-communications-map.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cc-communications-map.png -------------------------------------------------------------------------------- /images/cf-icons.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf-icons.png -------------------------------------------------------------------------------- /images/cf-routing-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf-routing-architecture.png -------------------------------------------------------------------------------- /images/cf_architecture.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf_architecture.graffle -------------------------------------------------------------------------------- /images/cf_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf_architecture.png -------------------------------------------------------------------------------- /images/cf_architecture_block.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf_architecture_block.graffle -------------------------------------------------------------------------------- /images/cf_architecture_block.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf_architecture_block.png -------------------------------------------------------------------------------- /images/cf_architecture_block_dea.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf_architecture_block_dea.graffle -------------------------------------------------------------------------------- /images/cf_architecture_block_dea.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cf_architecture_block_dea.png -------------------------------------------------------------------------------- /images/cloudflare-register.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare-register.png -------------------------------------------------------------------------------- /images/cloudflare/add-website.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/add-website.png -------------------------------------------------------------------------------- /images/cloudflare/cloudflare-register.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/cloudflare-register.png -------------------------------------------------------------------------------- /images/cloudflare/complete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/complete.png -------------------------------------------------------------------------------- /images/cloudflare/config-dns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/config-dns.png -------------------------------------------------------------------------------- /images/cloudflare/confirm-ssl.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/confirm-ssl.png -------------------------------------------------------------------------------- /images/cloudflare/my-websites.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/my-websites.png -------------------------------------------------------------------------------- /images/cloudflare/scan-complete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/scan-complete.png -------------------------------------------------------------------------------- /images/cloudflare/settings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cloudflare/settings.png -------------------------------------------------------------------------------- /images/comparison.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/comparison.png -------------------------------------------------------------------------------- /images/complete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/complete.png -------------------------------------------------------------------------------- /images/config-dns.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/config-dns.png -------------------------------------------------------------------------------- /images/confirm-selected-features.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/confirm-selected-features.png -------------------------------------------------------------------------------- /images/confirm-ssl.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/confirm-ssl.png -------------------------------------------------------------------------------- /images/cta_create_account.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/cta_create_account.png -------------------------------------------------------------------------------- /images/dea_placement_algorithm/dea_az_select.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/dea_placement_algorithm/dea_az_select.png -------------------------------------------------------------------------------- /images/dea_placement_algorithm/dea_criteria_filter.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/dea_placement_algorithm/dea_criteria_filter.png -------------------------------------------------------------------------------- /images/dea_placement_algorithm/dea_select_instance_count.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/dea_placement_algorithm/dea_select_instance_count.png -------------------------------------------------------------------------------- /images/dea_placement_algorithm/dea_top_half_memory.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/dea_placement_algorithm/dea_top_half_memory.png -------------------------------------------------------------------------------- /images/diego/.DS_Store: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/.DS_Store -------------------------------------------------------------------------------- /images/diego/app-monitor-sync-diego.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/app-monitor-sync-diego.graffle -------------------------------------------------------------------------------- /images/diego/app-monitor-sync-diego.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/app-monitor-sync-diego.png -------------------------------------------------------------------------------- /images/diego/auctioneer-job-list.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/auctioneer-job-list.png -------------------------------------------------------------------------------- /images/diego/diego-LRP-stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-LRP-stack.png -------------------------------------------------------------------------------- /images/diego/diego-auction-process.old.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-auction-process.old.png -------------------------------------------------------------------------------- /images/diego/diego-auction-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-auction-process.png -------------------------------------------------------------------------------- /images/diego/diego-auction-results.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-auction-results.png -------------------------------------------------------------------------------- /images/diego/diego-auction-stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-auction-stack.png -------------------------------------------------------------------------------- /images/diego/diego-flow-other.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-flow-other.png -------------------------------------------------------------------------------- /images/diego/diego-flow.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-flow.png -------------------------------------------------------------------------------- /images/diego/diego-overview.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/diego/diego-overview.png -------------------------------------------------------------------------------- /images/director-components.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-components.png -------------------------------------------------------------------------------- /images/director-deployment-manager.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-deployment-manager.png -------------------------------------------------------------------------------- /images/director-instance_manager_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-instance_manager_1.png -------------------------------------------------------------------------------- /images/director-release-manager.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-release-manager.png -------------------------------------------------------------------------------- /images/director-stemcell-manager.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-stemcell-manager.png -------------------------------------------------------------------------------- /images/director-task-manager.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-task-manager.png -------------------------------------------------------------------------------- /images/director-vm-state-manager.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/director-vm-state-manager.png -------------------------------------------------------------------------------- /images/docker_push_flow_diagram_diego.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/docker_push_flow_diagram_diego.png -------------------------------------------------------------------------------- /images/envoy-proxy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/envoy-proxy.png -------------------------------------------------------------------------------- /images/external-client-call-app.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/external-client-call-app.png -------------------------------------------------------------------------------- /images/facebook_large.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/facebook_large.png -------------------------------------------------------------------------------- /images/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/favicon.ico -------------------------------------------------------------------------------- /images/fig1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/fig1.png -------------------------------------------------------------------------------- /images/fig2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/fig2.png -------------------------------------------------------------------------------- /images/g+_large.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/g+_large.png -------------------------------------------------------------------------------- /images/hr-horizontal-dark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/hr-horizontal-dark.png -------------------------------------------------------------------------------- /images/hr-vertical.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/hr-vertical.png -------------------------------------------------------------------------------- /images/ico-cancel-x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/ico-cancel-x.png -------------------------------------------------------------------------------- /images/ico-search.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/ico-search.png -------------------------------------------------------------------------------- /images/istio_boxes_lines.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/istio_boxes_lines.jpg -------------------------------------------------------------------------------- /images/istio_c2c_boxes_lines.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/istio_c2c_boxes_lines.jpg -------------------------------------------------------------------------------- /images/istio_ingress_boxes_lines.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/istio_ingress_boxes_lines.jpg -------------------------------------------------------------------------------- /images/logo-cf-clean.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/logo-cf-clean.png -------------------------------------------------------------------------------- /images/logo-cloudfoundry-pivotal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/logo-cloudfoundry-pivotal.png -------------------------------------------------------------------------------- /images/logo-cloudfoundry.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/logo-cloudfoundry.png -------------------------------------------------------------------------------- /images/logo-pivotal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/logo-pivotal.png -------------------------------------------------------------------------------- /images/logo_cloudfoundry.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/logo_cloudfoundry.png -------------------------------------------------------------------------------- /images/logo_org.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/logo_org.png -------------------------------------------------------------------------------- /images/mapping_foundations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/mapping_foundations.png -------------------------------------------------------------------------------- /images/mapping_foundations2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/mapping_foundations2.png -------------------------------------------------------------------------------- /images/mapping_organizations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/mapping_organizations.png -------------------------------------------------------------------------------- /images/mapping_organizations2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/mapping_organizations2.png -------------------------------------------------------------------------------- /images/mapping_spaces.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/mapping_spaces.png -------------------------------------------------------------------------------- /images/mapping_spaces2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/mapping_spaces2.png -------------------------------------------------------------------------------- /images/minimal_manifest.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/minimal_manifest.png -------------------------------------------------------------------------------- /images/my-websites.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/my-websites.png -------------------------------------------------------------------------------- /images/nuclear2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/nuclear2.jpg -------------------------------------------------------------------------------- /images/orgs-and-spaces/CF-Arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/orgs-and-spaces/CF-Arch.png -------------------------------------------------------------------------------- /images/oss-diego-architecture-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/oss-diego-architecture-1.png -------------------------------------------------------------------------------- /images/oss-diego-architecture-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/oss-diego-architecture-2.png -------------------------------------------------------------------------------- /images/oss-diego-architecture-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/oss-diego-architecture-3.png -------------------------------------------------------------------------------- /images/oss-diego-architecture-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/oss-diego-architecture-4.png -------------------------------------------------------------------------------- /images/oss-diego-architecture-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/oss-diego-architecture-5.png -------------------------------------------------------------------------------- /images/oss-diego-architecture-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/oss-diego-architecture-6.png -------------------------------------------------------------------------------- /images/pivotal-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/pivotal-logo.png -------------------------------------------------------------------------------- /images/post-c2c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/post-c2c.png -------------------------------------------------------------------------------- /images/power-of-platform.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/power-of-platform.png -------------------------------------------------------------------------------- /images/pre-c2c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/pre-c2c.png -------------------------------------------------------------------------------- /images/ribbon_forkme.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/ribbon_forkme.png -------------------------------------------------------------------------------- /images/scale_cf.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/scale_cf.graffle -------------------------------------------------------------------------------- /images/scale_cf.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/scale_cf.png -------------------------------------------------------------------------------- /images/scaling-ert.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/scaling-ert.png -------------------------------------------------------------------------------- /images/scan-complete.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/scan-complete.png -------------------------------------------------------------------------------- /images/security/isolation-segments.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/security/isolation-segments.graffle -------------------------------------------------------------------------------- /images/security/isolation-segments.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/security/isolation-segments.png -------------------------------------------------------------------------------- /images/security/norm-sequence.graffle: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/security/norm-sequence.graffle -------------------------------------------------------------------------------- /images/security/sysbound1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/security/sysbound1.png -------------------------------------------------------------------------------- /images/security/sysbound2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/security/sysbound2.png -------------------------------------------------------------------------------- /images/settings.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/settings.png -------------------------------------------------------------------------------- /images/signup.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/signup.png -------------------------------------------------------------------------------- /images/signup_freetrial.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/signup_freetrial.png -------------------------------------------------------------------------------- /images/sts/add-cloud-url.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/add-cloud-url.png -------------------------------------------------------------------------------- /images/sts/application-details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/application-details.png -------------------------------------------------------------------------------- /images/sts/cloud-foundry-account.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/cloud-foundry-account.png -------------------------------------------------------------------------------- /images/sts/confirm-selected-features.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/confirm-selected-features.png -------------------------------------------------------------------------------- /images/sts/define-new-server.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/define-new-server.png -------------------------------------------------------------------------------- /images/sts/eclipse-marketplace.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/eclipse-marketplace.png -------------------------------------------------------------------------------- /images/sts/extensions.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/extensions.png -------------------------------------------------------------------------------- /images/sts/file-contents.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/file-contents.png -------------------------------------------------------------------------------- /images/sts/install-details.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/install-details.png -------------------------------------------------------------------------------- /images/sts/install.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/install.png -------------------------------------------------------------------------------- /images/sts/launch-deployment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/launch-deployment.png -------------------------------------------------------------------------------- /images/sts/manage-cloud-urls.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/manage-cloud-urls.png -------------------------------------------------------------------------------- /images/sts/manage-uris-configuration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/manage-uris-configuration.png -------------------------------------------------------------------------------- /images/sts/new-server.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/new-server.png -------------------------------------------------------------------------------- /images/sts/orgs-and-spaces.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/orgs-and-spaces.png -------------------------------------------------------------------------------- /images/sts/restart-sts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/restart-sts.png -------------------------------------------------------------------------------- /images/sts/service-configuration.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/service-configuration.png -------------------------------------------------------------------------------- /images/sts/services-selection.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/services-selection.png -------------------------------------------------------------------------------- /images/sts/software-updates.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/software-updates.png -------------------------------------------------------------------------------- /images/sts/ui-apps-services-tab.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/ui-apps-services-tab.png -------------------------------------------------------------------------------- /images/sts/ui-overview-tab.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/sts/ui-overview-tab.png -------------------------------------------------------------------------------- /images/twitter_large.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/twitter_large.png -------------------------------------------------------------------------------- /images/uaa-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/uaa-architecture.png -------------------------------------------------------------------------------- /images/v1services.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/v1services.png -------------------------------------------------------------------------------- /images/v2services.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/v2services.png -------------------------------------------------------------------------------- /images/vcenter-disk-path.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/vcenter-disk-path.png -------------------------------------------------------------------------------- /images/vcenter-folders.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/vcenter-folders.png -------------------------------------------------------------------------------- /images/vcloud_catalog.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/vcloud_catalog.png -------------------------------------------------------------------------------- /images/vcloud_private_network.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/vcloud_private_network.png -------------------------------------------------------------------------------- /images/vcloud_source_nat.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/vcloud_source_nat.png -------------------------------------------------------------------------------- /images/youtube_large.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cloudfoundry/docs-cloudfoundry-concepts/5a4b763fcf17ab7d03fe76e28dca572c0aac6fe4/images/youtube_large.png -------------------------------------------------------------------------------- /index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Foundry concepts 3 | --- 4 | 5 | <%# Reset page title based on product title %> 6 | <% if vars.platform_code != 'CF' %> 7 | 8 | <% set_title(vars.app_runtime_abbr, "Concepts") %> 9 | 10 | <% end %> 11 | 12 | <% if vars.platform_code == 'CF' %> 13 | <%= vars.app_runtime_first %> is an open-source cloud app platform, providing a choice of clouds, developer 14 | frameworks, and app services. Cloud Foundry makes it faster and easier to build, test, deploy, and scale apps. It is an open-source project and is available through a variety of private cloud distributions and public cloud instances. For more information, see [Cloud Foundry](https://github.com/cloudfoundry) on GitHub. 15 | <% else %> 16 | <%= vars.app_runtime_first %> is based on Cloud Foundry, which is an open-source cloud app platform, providing a choice of clouds, developer frameworks, and app 17 | services. <%= vars.app_runtime_abbr %> makes it faster and easier to build, test, deploy, and scale apps. It is an open-source project and is available through a variety of private cloud distributions and public cloud instances. For more information, see [Cloud Foundry](https://github.com/cloudfoundry) on GitHub. 18 | <% end %> 19 | 20 | This documentation presents an overview of 21 | how <%= vars.app_runtime_abbr %> works and a discussion of key concepts. 22 | 23 | To learn more about <%= vars.app_runtime_abbr %> fundamentals, see the following topics: 24 | 25 | * [<%= vars.app_runtime_abbr %> Overview](overview.html) 26 | 27 | * [Security and Networking](security-index.html) 28 | 29 | * [High Availability](ha-index.html) 30 | 31 | * [How <%= vars.app_runtime_abbr %> Manages Apps](apps-index.html) 32 | 33 | <% if vars.platform_code == 'CF' %> 34 | * [Runtime Components](architecture/index.html) 35 | <% else %> 36 | * [<%= vars.app_runtime_abbr %> Components](architecture/index.html) 37 | <% end %> 38 | -------------------------------------------------------------------------------- /maintaining-high-availability.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: How Cloud Foundry maintains high availability 3 | owner: Release Integration 4 | --- 5 | 6 | <%# Reset page title based on product title %> 7 | <% if vars.platform_code != 'CF' %> 8 | 9 | <% set_title("How", vars.app_runtime_abbr, "Maintains High Availability") %> 10 | 11 | <% end %> 12 | 13 | <%= vars.app_runtime_first %> deployments make up several layers of high availability to keep your apps running during system failure. 14 | These layers include AZs, app health management, process monitoring, and VM resurrection. 15 | 16 | 17 | ## Availability zones 18 | 19 | <%= vars.platform_name %> supports deploying apps instances across multiple AZs. This level of high availability requires that you define AZs in your IaaS. <%= vars.platform_name %> balances the apps you deploy across the AZs you defined. If an AZ goes down, you still have app instances running in another. 20 | 21 | <%= vars.azs %> 22 | 23 | 24 | ## Health management for app instances 25 | 26 | If you lose app instances for any reason, such as a bug in the app or an AZ going down, <%= vars.platform_name %> restarts new instances to maintain capacity. Under Diego architecture, the nsync, BBS, and Cell Rep components track the number of instances of each app that are running across all of the Diego cells. When these components detect a discrepancy between the actual state of the app instances in the cloud and the desired state as known by the Cloud Controller, they advise the Cloud Controller of the difference and the Cloud Controller initiates the deployment of new app instances. 27 | 28 | For more information about the nsync, BBS, and Cell Rep components, see the [nsync, BBS, and Cell Rep](./architecture/index.html#nsync-bbs) section of the _<%= vars.app_runtime_abbr %> Components_ topic. 29 | 30 | 31 | ## Process monitoring 32 | 33 | <%= vars.platform_name %> uses a BOSH agent, monit, to monitor the processes on the component VMs that work together to keep your apps running, such as nsync, BBS, and Cell Rep. If monit detects a failure, it restarts the process and notifies the BOSH agent on the VM. The BOSH agent notifies the BOSH Health Monitor, which starts the responders through plug-ins. For example, email notifications or paging. 34 | 35 | 36 | ## Resurrector VMs 37 | 38 | BOSH detects if a VM is present by listening for heartbeat messages that 39 | are sent from the BOSH agent every 60 seconds. The BOSH Health Monitor listens for 40 | those heartbeats. When the Health Monitor finds that a VM is not responding, it passes an alert 41 | to the Resurrector component. If the Resurrector is enabled, 42 | it sends the IaaS a request to create a new VM instance to replace the one that failed. 43 | 44 | <%= vars.resurrector %> 45 | -------------------------------------------------------------------------------- /orgs-and-spaces.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Planning orgs and spaces in Cloud Foundry 3 | owner: CAPI 4 | --- 5 | 6 | 7 | <%# Reset page title based on product title %> 8 | <% if vars.platform_code != 'CF' %> 9 | 10 | <% set_title("Planning", vars.app_runtime_abbr, "orgs and spaces") %> 11 | 12 | <% end %> 13 | 14 | 15 | This topic tells you about the considerations for effectively planning foundations, orgs, and spaces. You can plan your orgs and spaces to make the best use of the 16 | authorization features in <%= vars.app_runtime_first %>. 17 | 18 | An installation of <%= vars.app_runtime_abbr %> is referred to as a _foundation_. 19 | Each foundation has _orgs_ and _spaces_. For more information, see [Orgs, Spaces, Roles, and Permissions](./roles.html). 20 | 21 | The <%= vars.app_runtime_abbr %> roles described in _Orgs, Spaces, Roles, and Permissions_ use the principle of least privilege. Each role exists for a purpose and features in <%= vars.app_runtime_abbr %> enable these purposes. 22 | 23 | Consider these roles when planning your foundations, orgs, and spaces. This allows for full use of the features and assumptions of <%= vars.app_runtime_abbr %>. 24 | 25 | 26 | ## How <%= vars.app_runtime_abbr %> layers relate to your company 27 | 28 | The following sections describe what <%= vars.app_runtime_abbr %> layers are and how they relate to your company structure. 29 | 30 | ### Overview of <%= vars.app_runtime_abbr %> layers 31 | 32 | For an overview of each of the structural <%= vars.app_runtime_abbr %> layers, see the following table: 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 |
<%= vars.app_runtime_abbr %> LayerChallenge to MaintainContainsDescriptionRoles
FoundationsHardestOrgsFor shared components: domains, service tiles, and the physical infrastructureAdmin, Admin Read-Only, Global Auditor
OrgsAverageSpacesA group of users who share a resource quota plan, apps, services availability, and custom domainsOrg Manager, Org Auditor, Org Billing Manager
SpacesEasiestAppsA shared location for app development, deployment, and maintenanceSpace Manager, Space Developer, Space Auditor
68 | 69 | ### Foundations 70 | 71 | Foundations roughly map to a company and environments. For an illustration, see the following diagram: 72 | 73 | ![Foundations roughly map to a company and to an environment](./images/mapping_foundations.png) 74 | 75 | ### Orgs 76 | 77 | Orgs often map to a business unit in a particular foundation. To understand how you can map your company 78 | structure to a <%= vars.app_runtime_abbr %> org, see the following diagram: 79 | 80 | ![Orgs can encompass Business Units, environments, teams, or products](./images/mapping_organizations.png) 81 | 82 | 83 | ### Spaces 84 | 85 | 86 | Spaces can encompass teams, products, and specific deployables. To understand how you can map your company structure to a <%= vars.app_runtime_abbr %> space, see the following diagram: 87 | 88 | ![Spaces can encompass Teams, Products and specific deployables](./images/mapping_spaces.png) 89 | 90 | 91 | ## Mapping considerations 92 | 93 | The following sections describe considerations you can make when mapping foundations, orgs, and spaces. 94 | 95 | 96 | ### Planning for your environment 97 | 98 | To effectively plan your environments, you must decide at what <%= vars.app_runtime_abbr %> layer they belong. 99 | 100 | Broad environments, such as production environments, are commonly mapped to a foundation. More specific environments are mapped to an org or space. 101 | 102 | Because of the large human cost to maintaining a foundation, you might see foundations mapped to production and staging environments separately. 103 | 104 | For examples of environments and how they map to <%= vars.app_runtime_abbr %> layers, see the following table: 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | 113 | 114 | 115 | 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 |
<%= vars.app_runtime_abbr %> LayerExamples of Environments
FoundationsProduction, Non-production, Sandbox
Orgs and SpacesDevelopment, UAT, QA
124 | 125 | ### Questions to consider about each <%= vars.app_runtime_abbr %> layer 126 | 127 | For guiding questions to help you make decisions about planning your <%= vars.app_runtime_abbr %> structure, see the following table: 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | 137 | 138 | 139 | 146 | 147 | 148 | 149 | 156 | 157 | 158 | 159 | 169 | 170 | 171 |
<%= vars.app_runtime_abbr %> LayerQuestions to Consider
Foundation 140 |
    141 |
  • How many foundations can your platform team create, update, and monitor?
    • 142 |
  • How much isolation does your organization require?
    • 143 |
  • Do you need foundations local to a particular cloud or IaaS environment?
    • 144 |
145 |
Org 150 |
    151 |
  • How do you plan for capacity needs and changes?
    • 152 |
  • What groups need to self-organize together?
    • 153 |
  • How do you measure cost and perform billing and chargeback?
    • 154 |
155 |
Space 160 |
    161 |
  • Are teams building single apps or constellations of microservices?
    • 162 |
  • Are teams building a portfolio of apps or standalone apps?
    • 163 |
  • When a new space can be created or destroyed?
    • 164 |
  • What developer processes require the sandboxed isolation?
    • 165 |
  • Do all apps need public routes?
    • 166 |
  • What apps need to share the same service instance?
    • 167 |
168 |
172 | 173 | ### Mapping larger and smaller subsets 174 | 175 | _Subsets_ are the company divisions you decide to map to <%= vars.app_runtime_abbr %>. When creating your subsets, consider that the lower the <%= vars.app_runtime_abbr %> layer, the more specific you want to map your subsets. Conversely, the higher the <%= vars.app_runtime_abbr %> layer, the broader you want to make your subsets. 176 | 177 | For more information about mapping larger subsets for each <%= vars.app_runtime_abbr %> layer, see the following table: 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 193 | 194 | 195 | 196 | 203 | 204 | 205 | 206 | 213 | 214 |
<%= vars.app_runtime_abbr %> LayerThe impact of mapping larger subsets of your company
Foundations 187 |
    188 |
  • Less maintenance
    • 189 |
  • Less isolation
    • 190 |
  • Better use of shared platform components
    • 191 |
192 |
Orgs 197 |
    198 |
  • Less quota micromanagement
    • 199 |
  • Ability to delegate user onboarding
    • 200 |
  • More likely there are people with divergent needs
    • 201 |
  • BU must be platform trained and manage potentially many spaces
    • 202 |
Spaces 207 |
    208 |
  • More likelihood of accidental changes to someone else’s app or service
    • 209 |
  • Easier integration between apps
    • 210 |
  • More apps can use non-public routes
    • 211 |
212 |
215 | 216 | For more information about mapping smaller subsets for each <%= vars.app_runtime_abbr %> layer, see the following table: 217 | 218 | 219 | 220 | 221 | 222 | 223 | 224 | 225 | 226 | 227 | 228 | 235 | 236 | 237 | 238 | 244 | 245 | 246 | 247 | 254 | 255 | 256 |
<%= vars.app_runtime_abbr %> LayerThe impact of mapping smaller subsets of your company
Foundations 229 |
    230 |
  • More maintenance, which could be offset with platform automation
    • 231 |
  • Higher likelihood of foundations being different
    • 232 |
  • More isolation
    • 233 |
234 |
Orgs 239 |
    240 |
  • More quota management from platform team
    • 241 |
  • More freedom to create spaces as needed
    • 242 |
243 |
Spaces 248 |
    249 |
  • More app isolation
    • 250 |
  • Security with more specific ASGs
    • 251 |
  • More reliant on external services or service instance sharing
    • 252 |
253 |
257 | -------------------------------------------------------------------------------- /overview.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Foundry overview 3 | --- 4 | 5 | <%# Reset page title based on product title %> 6 | <% if vars.platform_code != 'CF' %> 7 | 8 | <% set_title(vars.app_runtime_abbr, "Overview") %> 9 | 10 | <% end %> 11 | 12 | <% if vars.platform_code == 'CF' %> 13 | 14 | This topic tells you about Cloud Foundry and how it works. 15 | 16 | <% else %> 17 | 18 | This topic tells you about <%= vars.app_runtime_first %> and how it works with <%= vars.ops_manager %>. 19 | 20 | <% end %> 21 | 22 | ## Introduction to Cloud Platforms 23 | 24 | Cloud platforms enable rapid deployment of applications and services, making them globally accessible within minutes. When application requests increase, cloud infrastructure can automatically scale to meet higher demand, eliminating traditional build-outs and migrations. This approach allows developers to focus on applications and data without the need to manage underlying infrastructure. 25 | 26 | The following diagram illustrates the layers of a typical technology stack, comparing the traditional IT model with an IaaS stack and a PaaS stack, showing which layers are managed by users vs. providers. 27 | 28 | * **Traditional IT Stack:** All layers are managed in-house, including applications, data, runtime, middleware, OS, virtualization, servers, storage, and networking. 29 | 30 | * **IaaS Stack:** The provider manages the servers, storage, networking, and virtualization, while the user manages applications, data, runtime, middleware, and OS. 31 | 32 | * **PaaS Stack:** The provider manages all layers except for applications and data, which remain the user’s responsibility. 33 | 34 | ![Diagram comparing three technology stacks: Traditional IT, IaaS, and PaaS, showing which layers are managed by users vs. providers.](./images/comparison.png) 35 | 36 | [View a larger version of this diagram](https://github.com/cloudfoundry/docs-cloudfoundry-concepts/blob/master/images/comparison.png?raw=true). 37 | 38 | ## About <%= vars.app_runtime_abbr %> 39 | 40 | This section describes why <%= vars.app_runtime_abbr %> is an industry-standard cloud platform. 41 | 42 | Not all cloud platforms are created equal. Some have limited language and framework support, lack key app services, or restrict deployment to a single cloud. 43 | 44 | As an industry-standard cloud platform, <%= vars.app_runtime_abbr %> offers the following: 45 | 46 | * **Open source code**: The platform's openness and extensibility prevent its users from being locked into a single framework, set of app services, or cloud. For more information, see the [Cloud Foundry](https://github.com/cloudfoundry) project on GitHub. 47 | 48 | * **Deployment automation**: Developers can deploy their apps to <%= vars.app_runtime_abbr %> using their existing tools and with zero modification to their code. 49 | 50 | * **Flexible infrastructure**: You can deploy <%= vars.app_runtime_abbr %> to run your apps on your own computing infrastructure, or deploy on an IaaS like vSphere, AWS, Azure, GCP, or OpenStack. 51 | 52 | * **Commercial options**: You can also use a PaaS deployed by a commercial <%= vars.app_runtime_abbr %> cloud provider. For more information, see [Cloud Foundry Certified Platforms](https://www.cloudfoundry.org/certified-platforms/). 53 | 54 | * **Community support**: A broad community contributes to and supports <%= vars.app_runtime_abbr %>. See [Welcome to the Cloud Foundry Community](https://www.cloudfoundry.org/community/). 55 | 56 | <%= vars.app_runtime_abbr %> is ideal for anyone interested in removing the cost and complexity of configuring infrastructure for their apps. 57 | 58 | 59 | ## How <%= vars.app_runtime_abbr %> Works 60 | 61 | To flexibly serve and scale apps online, <%= vars.app_runtime_abbr %> has subsystems that perform specialized functions. The following sections describe how some of these main subsystems work. 62 | 63 | ### Load balancing 64 | 65 | This section describes how <%= vars.app_runtime_abbr %> handles load balancing. 66 | 67 | Clouds balance their processing loads over multiple machines, optimizing for efficiency and resilience against point failure. A <%= vars.app_runtime_abbr %> installation accomplishes this using the following components: 68 | 69 | - **BOSH** creates and deploys VMs on top of a physical computing infrastructure, and deploys and runs <%= vars.app_runtime_abbr %> on top of this cloud. To configure the deployment, BOSH follows a manifest document. For more information, see the [BOSH documentation](http://bosh.io). 70 | 71 | - **Cloud Controller** runs the apps and other processes on the cloud's VMs, balancing demand and managing app lifecycles. For more information, see [Cloud Controller](./architecture/cloud-controller.html). 72 | 73 | - The **Gorouter** routes incoming traffic from the world to the VMs that are running the apps that the traffic demands, usually working with a customer-provided load balancer. For more information, see [<%= vars.app_runtime_abbr %> Routing Architecture](./cf-routing-architecture.html). 74 | 75 | ### Running apps 76 | 77 | This section describes the VMs that run your apps in <%= vars.app_runtime_abbr %> and how the platform packages your apps to run on these VMs. 78 | 79 | #### VMs in <%= vars.app_runtime_abbr %> 80 | 81 | <%= vars.app_runtime_abbr %> designates the following types of VMs: 82 | 83 | - **Component VMs** make up the platform's infrastructure. 84 | - **Host VMs** host your apps for the outside world. 85 | 86 | Within <%= vars.app_runtime_abbr %>, the Diego system distributes the hosted app load over all of the host VMs, and keeps it running and balanced through demand surges, outages, or other changes. Diego accomplishes this through an auction algorithm. 87 | 88 | For more information, see [Diego Components and Architecture](./diego/diego-architecture.html). 89 | 90 | #### Distributing apps 91 | 92 | To meet demand, multiple host VMs run duplicate instances of the same app. This means that apps must be portable. <%= vars.app_runtime_abbr %> distributes app source code to VMs with everything the VMs need to compile and run the apps locally. 93 | 94 | <%= vars.app_runtime_abbr %> includes the following with your app's source code: 95 | 96 | - **Stack**: the operating system the app runs on. 97 | - **Buildpack**: contains all languages, libraries, and services that the app uses. 98 | 99 | Before sending an app to a VM, the Cloud Controller stages it for delivery by combining the stack, buildpack, and source code into a droplet that the VM can unpack, compile, and run. For simple, standalone apps with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries. 100 | 101 | For more information, see: 102 | 103 | - [Changing Stacks](../devguide/deploy-apps/stacks.html) 104 | - [Buildpacks](../buildpacks/index.html) 105 | - [How Apps Are Staged](./how-applications-are-staged.html) 106 | 107 | ### Organizing users and workspaces 108 | 109 | This section describes how <%= vars.app_runtime_abbr %> organizes users and workspaces. 110 | 111 | <%= vars.app_runtime_abbr %> manages user accounts through two User Account and Authentication (UAA) servers, which support access control as OAuth2 services and can store user information internally, or connect to external user stores through LDAP or SAML. 112 | 113 | For more information, see [User Account and Authentication (UAA) Server](./architecture/uaa.html). 114 | 115 | The following table describes what the two UAA servers do: 116 | 117 | 118 | 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | 130 |
ServerPurpose
First UAA server
  • Grants access to BOSH
  • Holds accounts for <%= vars.ops_manager %> operators who deploy runtimes, services, and other software onto the BOSH layer directly
Second UAA server
  • Controls access to the Cloud Controller
  • Defines user roles, such as admin, developer, or auditor, and grants them different sets of privileges to run <%= vars.app_runtime_abbr %> commands
  • Scopes the roles to separate, compartmentalized orgs and spaces within an installation to manage and track use
131 | 132 | For more information, see [Orgs, Spaces, Roles, and Permissions](./roles.html). 133 | 134 | ### Storing resources 135 | 136 | The following table describes where <%= vars.app_runtime_abbr %> stores resources: 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 |
ResourceStorage Location
  • Source code
  • Buildpacks
  • Documentation
  • Custom configurations
  • Other platform resources
GitHub
  • Large binary files
  • Droplets
Internal or external blobstore
  • Internal component states
  • Other temporary information
MySQL
156 | 157 | ### Communicating with components 158 | 159 | This section describes how <%= vars.app_runtime_abbr %> components communicate with one another. 160 | 161 | <%= vars.app_runtime_abbr %> components communicate in the following ways: 162 | 163 | * By sending messages internally using HTTP and HTTPS protocols 164 | * By sending NATS messages to each other directly 165 | 166 | BOSH Director co-locates a BOSH DNS server on every deployed VM. All VMs keep up-to-date DNS records for all the other VMs in the same foundation. This enables service discovery between VMs. 167 | 168 | BOSH DNS allows deployments to continue communicating with VMs even when the VMs' IP addresses change. It also provides client-side load balancing by randomly selecting a healthy VM when multiple VMs are available. 169 | 170 | For more information about BOSH DNS, see [Native DNS Support](https://bosh.io/docs/dns/) in the BOSH documentation. 171 | 172 | ### Monitoring and Analyzing 173 | 174 | This section describes logging in <%= vars.app_runtime_abbr %>. 175 | 176 | <%= vars.app_runtime_abbr %> generates system logs from <%= vars.app_runtime_abbr %> components and app logs from hosted apps. As <%= vars.app_runtime_abbr %> runs, its component and host VMs generate logs and metrics. <%= vars.app_runtime_abbr %> apps also typically generate logs. 177 | 178 | The following table describes where <%= vars.app_runtime_abbr %> sends logs: 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 |
Log TypeDestination
<%= vars.app_runtime_abbr %> component logsRsyslog agents
<%= vars.app_runtime_abbr %> component metricsLoggregator
App logsLoggregator
198 | 199 | Component logs stream from rsyslog agents, and the cloud operator can configure them to stream out to a syslog drain. 200 | 201 | The Loggregator system aggregates the component metrics and app logs into a structured, usable form, the Firehose. You can use all of the output of the Firehose, or direct the output to specific uses, such as monitoring system internals, triggering alerts, or analyzing user behavior, by applying nozzles. 202 | 203 | <% if vars.platform_code == "CF" %> 204 | 205 | For more information, see Loggregator Architecture. 206 | 207 | <% else %> 208 | 209 | For more information, see Loggregator Architecture. 210 | 211 | <% end %> 212 | 213 | ### Using services 214 | 215 | This section describes how you can use services with your apps on <%= vars.app_runtime_abbr %>. 216 | 217 | Typical apps depend on free or metered services such as databases or third-party APIs. To incorporate these into an app: 218 | 219 | 1. **Write a Service Broker**: This component manages the life cycle of the service. The Service Broker uses the Service Broker API to advertise a catalog of service offerings to <%= vars.app_runtime_abbr %> apps. 220 | 221 | 1. **Provision the Service Instance**: Create an instance of the service offering by sending a provision request to the Service Broker API. 222 | 223 | 1. **Enable apps to access the Service Instance**: Configure the <%= vars.app_runtime_abbr %> app to make calls to the Service Instance using the Service Broker API. 224 | 225 | For more information, see [Services](../services/index.html). 226 | 227 | <%= vars.concepts_sf_vs_full_header %> 228 | 229 | <% if vars.platform_code == 'PCF' %> 230 | <%= partial "/pcf/core/small_footprint_overview" %> 231 | <% else %> 232 | <% end %> 233 | 234 | <%= vars.small_footprint_comparison %> 235 | 236 | [//]: # (Comment: Below calls vars concept_product_* in book repository template_vars.yml.) 237 | [//]: # ( The vars *_text and *_image hold locations of partial and image files. ) 238 | [//]: # ( For private/commercial books, the partial and image files come from a ) 239 | [//]: # ( private repository rather than cloudfoundry.org/docs-cloudfoundry-concepts. ) 240 | <%= vars.concepts_product_model_header %> 241 | 242 | <%# partials for vars.concepts_product_model_text %> 243 | <% if vars.platform_code == 'CF' %> 244 | <%= partial 'overview_model' %> 245 | <% else %> 246 | <%= partial "/pcf/core/pcf_overview_model" %> 247 | <% end %> 248 | 249 | <%= vars.concepts_product_model_image %> 250 | -------------------------------------------------------------------------------- /roles.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Orgs, spaces, roles, and permissions in Cloud Foundry 3 | owners: CAPI, Identity 4 | --- 5 | 6 | This topic tells you about orgs and spaces in <%= vars.app_runtime_first %> foundations. It also describes the default permissions for user roles in <%= vars.app_runtime_abbr %>. 7 | 8 | <%= vars.app_runtime_abbr %> uses a role-based access control (RBAC) system to grant appropriate permissions to <%= vars.app_runtime_abbr %> users. 9 | 10 | Admins, Org Managers, and Space Managers can assign user roles using the Cloud Foundry Command Line Interface (cf CLI). For more information, see [Users and Roles](../cf-cli/getting-started.html#user-roles) in _Getting Started with the cf CLI_<%= vars.or_apps_man %>. 11 | 12 | 13 | ## Orgs 14 | 15 | An org is a development account that an individual or multiple collaborators can own and use. All collaborators access an org with user accounts, which have roles such as Org Manager, Org Auditor, and Org Billing Manager. Collaborators in an org share a resource quota plan, apps, services availability, and custom domains. 16 | 17 | By default, an org has the status of _active_. An admin can set the status of an org to _suspended_ for various reasons such as failure to provide payment or misuse. When an org is suspended, users cannot perform certain activities within the org, such as push apps, modify spaces, or bind services. 18 | 19 | For more information about the actions that each role can perform, see [User Roles](#roles) and [User Role Permissions](#permissions). 20 | 21 | For details on what activities are allowed for suspended orgs, see [Roles and Permissions for Suspended Orgs](#suspendedroles). 22 | 23 | 24 | ## Spaces 25 | 26 | A space provides users with access to a shared location for app development, deployment, and maintenance. An org can contain multiple spaces. Every app, service, and route is scoped to a space. Roles provide access control for these resources and each space role applies only to a particular space. 27 | 28 | Org managers can set quotas on the following for a space: 29 | 30 | * Usage of paid services 31 | * Number of app instances 32 | * Number of service keys 33 | * Number of routes 34 | * Number of reserved route ports 35 | * Memory used across the space 36 | * Memory used by a single app instance 37 | * Log volume per second used across the space 38 | 39 | 40 | ## User roles 41 | 42 | A user account represents an individual person within the context of a <%= vars.app_runtime_abbr %> foundation. A user can have one or more roles. These roles define the user's permissions in orgs and spaces. 43 | 44 | Roles can be assigned different scopes of User Account and Authentication (UAA) privileges. For more information about UAA scopes, see [Scopes](./architecture/uaa.html#scopes) in _User Account and Authentication (UAA) Server_. 45 | 46 | The following describes each type of user role in <%= vars.app_runtime_abbr %>: 47 | 48 | <%= vars.admin_role %> 49 | <%= vars.admin_read_only_role %> 50 | <%= vars.global_auditor_role %> 51 | 52 | * **Org Managers**: Administer the org. 53 | 54 | * **Org Auditors**: Read-only access to user information and org quota usage 55 | information. 56 | 57 | <%= vars.billing_manager_role %> 58 | <%= vars.billing_manager_role_note %> 59 | 60 | * **Org Users**: Read-only access to the list of other org users and their roles. In the v2 Cloud Controller API, when an Org Manager gives a person an Org or Space role, that person automatically receives Org User status in that org. This is no longer the case in the V3 Cloud Controller API. 61 | 62 | * **Space Managers**: Manage a space within an org. 63 | 64 | * **Space Developers**: Manage apps, services, and space-scoped service brokers in a space. 65 | 66 | * **Space Auditors**: Read only access to a space. 67 | 68 | * **Space Supporters**: Troubleshoot and debug apps and service bindings in a space. 69 | 70 |

The Space Supporter role is only available for the Cloud Controller V3 API. If a user with this role tries 71 | to access a V2 endpoint, the API returns a 403.

72 | 73 | For non-admin users, the `cloud_controller.read` scope is required to view resources, and the `cloud_controller.write` scope is required to create, update, and delete resources. 74 | 75 | Before you assign a space role to a user, you must assign an org role to the user. The error message `Server error, error code: 1002, message: cannot set space role because user is not part of the org` occurs when you try to set a space role before setting an org role for the user. 76 | 77 | 78 | ## User role permissions 79 | 80 | Each user role includes different permissions in a <%= vars.app_runtime_abbr %> foundation. The following sections describe the permissions associated with each user role in both active and suspended orgs in <%= vars.app_runtime_abbr %>. 81 | 82 | ### Roles and permissions for active orgs 83 | 84 | The following table describes the default permissions for various <%= vars.app_runtime_abbr %> roles in active orgs. 85 | 86 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 87 | 88 | You can use feature flags to edit some of the default permissions in the following table. 89 | For more information, see Using Feature Flags. 90 | <% end %> 91 | 92 | <% if vars.platform_code == "CF" %> 93 | <%= partial 'oss_roles_table' %> 94 | <% else %> 95 | <%= partial "/pcf/core/pcf_roles_table" %> 96 | <% end %> 97 | 98 | ### Roles and permissions for suspended orgs 99 | 100 | The following table describes roles and permissions applied after an operator sets the status of an org to _suspended_. 101 | 102 | <% if vars.platform_code == "CF" %> 103 | <%= partial 'suspended_org_roles_table' %> 104 | <% else %> 105 | <%= partial "/pcf/core/pcf_suspended_roles_table" %> 106 | <% end %> 107 | -------------------------------------------------------------------------------- /security-index.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Security and networking 3 | owner: Docs 4 | --- 5 | 6 | The following topics provide information about security and networking: 7 | 8 | * [<%= vars.app_runtime_abbr %> Security](security.html). 9 | * [Container Security](container-security.html). 10 | * [Container-to-Container Networking](understand-cf-networking.html). 11 | * [Orgs, Spaces, Roles, and Permissions](roles.html). 12 | * [App Security Groups](asg.html). 13 | * [App SSH Components and Processes](./diego/ssh-conceptual.html). -------------------------------------------------------------------------------- /security.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Cloud Foundry security 3 | owner: Security 4 | --- 5 | 6 | <%# Reset page title based on product title %> 7 | <% if vars.platform_code != 'CF' %> 8 | 9 | <% set_title(vars.app_runtime_abbr, "Security") %> 10 | 11 | <% end %> 12 | 13 | This topic provides you with an overview of <%= vars.app_runtime_first %> security. 14 | For an overview of container security, see [Container Security](container-security.html). 15 | 16 | <%= vars.app_runtime_abbr %> implements the following measures to mitigate against security threats: 17 | 18 | * Minimizes network surface area. 19 | * Isolates customer apps and data in containers. 20 | * Encrypts connections. 21 | * Uses role-based access controls, applying and enforcing roles and permissions to ensure that users can only 22 | view and affect the spaces for which they have been granted access. 23 | * Ensures security of app bits in a multi-tenant environment. 24 | * Prevents possible denial of service attacks through resource starvation. 25 | 26 | 27 | ## System boundaries and access 28 | 29 | In a typical deployment of <%= vars.app_runtime_abbr %>, the components run on virtual machines (VMs) that exist within a VLAN. 30 | 31 | In this configuration, the only access points visible on a public network are a load balancer that maps to one or more <%= vars.app_runtime_abbr %> routers and, optionally, a NAT VM and a jumpbox. Because of the limited number of contact points with the public internet, the surface area for possible security vulnerabilities is minimized. 32 | 33 | As the following diagram shows the architecture of a typical deployment of <%= vars.app_runtime_abbr %>: 34 | 35 |

36 | <%= vars.company_name %> recommends that you also install a NAT VM for outbound requests and a 37 | jumpbox to access the BOSH Director, though these access points are optional depending on your network 38 | configuration.

39 | 40 | ![Full description of this diagram is in the text.](./images/security/sysbound1.png) 41 | 42 | The diagram shows the following components: 43 | 44 | - DMZ 45 | - Customer Load Balancers with SSL Termination 46 | - Outbound NAT 47 | - Jumpbox 48 | - Private vLANs 49 | - Cloud Foundry vLAN 50 | - Three Go Routers 51 | - OAuth2 Server (UAA) 52 | - Login Server 53 | - Cloud Controller 54 | - nsync 55 | - Diego Brain 56 | - Cell Reps 57 | - Blob Store 58 | - App Execution (Diego Cells) with Garden Containers 59 | - Service Brokers 60 | - BBS (HTTP/S) 61 | - Consul 62 | - NATS Message Bus 63 | - Metrics Collector 64 | - App Log Aggregator 65 | - BOSH vLAN 66 | - BOSH Director 67 | - Resurrector 68 | - Workers 69 | -Message Bus (NATS) 70 | - Services vLAN 71 | - Brokers 72 | - Services Nodes 73 | - IaaS 74 | - Hypervisor 75 | 76 | The preceding diagram shows the following communications: 77 | 78 | - Customer Load Balancers send communication to the three Go Routers. 79 | 80 | - Outbound NAT communicates with Hypervisor. 81 | 82 | - BOSH Director communicates with the App Execution (Diego Cells). 83 | 84 | - Service Brokers in Cloud Foundry vLAN communicates with Brokers in Services vLAN. 85 | 86 | 87 | ### Protocols 88 | 89 | All traffic from the public internet to the Cloud Controller and UAA happens over HTTPS. Inside the boundary of the system, components communicate over a publish-subscribe (pub-sub) message bus NATS, HTTP, and SSL/TLS. 90 | 91 | ### BOSH 92 | 93 | Operators deploy <%= vars.app_runtime_abbr %> with BOSH. The BOSH Director is the core orchestrating component in BOSH: it controls VM creation and deployment, as well as other software and service lifecycle events. You use HTTPS to ensure secure communication to the BOSH Director. 94 | 95 | <%= vars.company_name %> recommends that you deploy the BOSH Director on a subnet that is not 96 | publicly accessible, and access the BOSH Director from a jumpbox on the subnet or through VPN. 97 | 98 | BOSH includes the following capability for security: 99 | 100 | * Communicates with the VMs it runs through NATS. Because NATS cannot be accessed from outside <%= vars.app_runtime_abbr %>, this ensures that published messages can only originate from a component within your deployment. 101 | 102 | * Provides an audit trail through the `bosh tasks --all` and `bosh tasks --recent=VALUE` commands. `bosh tasks --all` returns a table that shows all BOSH actions taken by an operator or other running processes. `bosh tasks --recent=VALUE` returns a table of recent tasks, with `VALUE` being the number of recent tasks you want to view. 103 | 104 | * Allows you to set up individual login accounts for each operator. BOSH operators have root access. 105 | 106 |

107 | BOSH does not encrypt data stored on BOSH VMs. Your IaaS might encrypt this data.

108 | 109 | ## Isolation segments 110 | 111 | Isolation segments provide dedicated pools of resources to which apps can be deployed to isolate workloads. Using isolation segments separates app resources as completely as if they were in different <%= vars.app_runtime_abbr %> deployments but avoids redundant management components and unneeded network complexity. 112 | 113 | You can designate isolation segments for exclusive use by orgs and spaces within <%= vars.app_runtime_abbr %>. This guarantees that apps within the org or space use resources that are not also used by other orgs or spaces. For more information, see [Orgs, Spaces, Roles, and Permissions](./roles.html). 114 | 115 | Customers can use isolation segments for different reasons, including: 116 | 117 | * To follow regulatory restrictions that require separation between different types of apps. For example, a health care company might not be able to host medical records and billing systems on the same machines. 118 | 119 | * To dedicate specific hardware to different isolation segments. For example, to ensure that high-priority apps run on a cluster of high-performance hosts. 120 | 121 | * To separate data on multiple clients, to strengthen a security story, or offer different hosting tiers. 122 | 123 | In <%= vars.app_runtime_abbr %>, the Cloud Controller database (CCDB) identifies isolation segments by name and GUID, for example `30dd879c-ee2f-11db-8314-0800200c9a66`. The isolation segment object has no internal structure beyond these two properties at the <%= vars.app_runtime_abbr %> level, but BOSH associates the name of the isolation segment with Diego Cells, through their `placement_tag` property. 124 | 125 | This diagram shows how isolation segments keep apps running on different pools of Diego Cells, and how the Diego Cells communicate with each other and with the management components: 126 | ![Description is in the text.](./images/security/isolation-segments.png) 127 | 128 | <%= vars.manage_iso_seg_link %> 129 | 130 | For API commands related to isolation segments, see [Isolation Segments](http://v3-apidocs.cloudfoundry.org/version/3.0.0/index.html#isolation-segments) in the Cloud Controller API (CAPI) Reference. 131 | 132 | 133 | ## Authentication and authorization 134 | 135 | [User Account and Authentication](./architecture/uaa.html) (UAA) is the central identity management service for <%= vars.app_runtime_abbr %> and its various components. 136 | 137 | UAA acts as an [OAuth2](https://oauth.net/2/) Authorization Server and issues access tokens for apps that request platform resources. 138 | The tokens are based on the [JSON Web Token](http://jwt.io/) and are digitally signed by UAA. 139 | 140 | Operators can configure the identity store in UAA. If users register an account with the <%= vars.app_runtime_abbr %> platform, UAA acts as the user store and stores user passwords in the UAA database using [bcrypt](http://en.wikipedia.org/wiki/Bcrypt). UAA also supports connecting to external user stores through LDAP and SAML. Once an operator has configured the external user store, such as a corporate Microsoft Active Directory, users can use their LDAP credentials to gain access to the <%= vars.app_runtime_abbr %> platform instead of registering a separate account. Alternatively, operators can use SAML to connect to an external user store and enable single sign-on for users into the <%= vars.app_runtime_abbr %> platform. 141 | 142 | Standard <%= vars.app_runtime_abbr %> deployments based on [cf-deployment](https://github.com/cloudfoundry/cf-deployment) provide a UAA client `cf` that can be used to create OAuth 2 tokens using the Password Grant Flow for <%= vars.app_runtime_abbr %> users that are needed to access the CF API. This UAA client is also used by the CF CLI. The UAA client `cf` doesn't require a `client_secret`. 143 | 144 | ### Managing user access with Role-Based Access Control 145 | 146 | Apps that users deploy to <%= vars.app_runtime_abbr %> exist within a space. Spaces exist within orgs. To view and access an org or a space, a user must be a member of it. <%= vars.app_runtime_abbr %> uses role-based access control (RBAC), with each role granted permissions to either an org or a specified space. For more information about roles and permissions, see [Orgs, Spaces, Roles, and Permissions](roles.html). 147 | 148 | <%= vars.console_links %> 149 | 150 | 151 | ## Security for service broker integration 152 | 153 | The Cloud Controller authenticates every request with the Service Broker API using HTTP or HTTPS, depending on which protocol that you specify during broker registration. The Cloud Controller rejects any broker registration that does not contain a username and password. 154 | 155 | Service instances bound to an app contain credential data. Users specify the binding credentials for user-provided service instances, while third-party brokers specify the binding credentials for managed service instances. The VCAP_SERVICES environment variable contains credential information for any service bound to an app. <%= vars.app_runtime_abbr %> constructs this value from encrypted data that it stores in the CCDB. For more information about user-provided service instances, see [User-Provided Service Instances](../devguide/services/user-provided.html). 156 | 157 | The selected third-party broker controls how securely to communicate managed service credentials. 158 | 159 | A third-party broker might offer a dashboard client in its catalog. Dashboard clients require a text string defined as a `client_secret`. <%= vars.app_runtime_abbr %> does not store this secret in the CCDB. Instead, <%= vars.app_runtime_abbr %> passes the secret to the UAA component for verification using HTTP or HTTPS. 160 | 161 | 162 | ## Managing software vulnerabilities 163 | 164 | <%= vars.app_runtime_abbr %> manages software vulnerability using releases and BOSH stemcells. New <%= vars.app_runtime_abbr %> releases are created with updates to address code issues, while new stemcells are created with patches for the latest security fixes to address any underlying operating system issues. 165 | 166 | 167 | ## Ensuring security for app artifacts 168 | 169 | <%= vars.app_runtime_abbr %> secures both the code and the configuration of an app using the following functions: 170 | 171 | * App developers push their code using the <%= vars.app_runtime_abbr %> API. <%= vars.app_runtime_abbr %> secures each call to the <%= vars.app_runtime_abbr %> API using the [UAA](#auth) and SSL. 172 | 173 | * The Cloud Controller uses [RBAC](#rbac) to ensure that only authorized users can access a particular app. 174 | 175 | * The Cloud Controller stores the configuration for an app in an encrypted database table. This configuration data includes user-specified environment variables and service credentials for any services bound to the app. 176 | 177 | * <%= vars.app_runtime_abbr %> runs the app inside a secure container. For more information, see [Container Security](./container-security.html). 178 | 179 | * <%= vars.app_runtime_abbr %> operators can configure network traffic rules to control inbound communication to and outbound communication from an app. For more information, see the [Network Traffic Rules](./container-security.html#config-traffic) section of the _Container Security_ topic. 180 | 181 | 182 | ## Security event logging and auditing 183 | 184 | For operators, <%= vars.app_runtime_abbr %> provides an audit trail through the `bosh tasks` command. This command shows all actions that an operator has taken with the platform. Additionally, operators can redirect <%= vars.app_runtime_abbr %> component logs to a standard syslog server using the `syslog_daemon_config` [property](http://docs.cloudfoundry.org/running/managing-cf/logging.html) in the `metron_agent` job of `cf-release`. 185 | 186 | For users, <%= vars.app_runtime_abbr %> records an audit trail of all relevant API invocations of an app. The Cloud Foundry Command Line Interface (cf CLI) command `cf events` returns this information. 187 | 188 | 189 | ## Recommendations for running a secure deployment 190 | 191 | To help run a secure deployment, <%= vars.company_name %> recommends: 192 | 193 | * Configure UAA clients and users using a BOSH manifest. Limit and manage these clients and users as you would any other kind of privileged account. 194 | 195 | * Deploy within a VLAN that limits network traffic to individual VMs. This reduces the possibility of unauthorized access to the VMs within your BOSH-managed cloud. 196 | 197 | * Enable HTTPS for apps and SSL database connections to protect sensitive data transmitted to and from apps. 198 | 199 | * Ensure that the jumpbox is secure, along with the load balancer and NAT VM. 200 | 201 | * Encrypt stored files and data within databases to meet your data security requirements. Deploy using industry standard encryption and the best practices for your language or framework. 202 | 203 | * Prohibit promiscuous network interfaces on the trusted network. 204 | 205 | * Review and monitor data sharing and security practices with third party services that you use to provide additional function to your app. 206 | 207 | * Store SSH keys securely to prevent disclosure, and promptly replace lost or compromised keys. 208 | 209 | * Use <%= vars.app_runtime_abbr %>'s RBAC model to restrict your users' access to only what is necessary to complete their tasks. 210 | 211 | * Use a strong passphrase for both your <%= vars.app_runtime_abbr %> user account and SSH keys. 212 | 213 | <%= vars.ipsec_note %> 214 | 215 | <%= vars.compliance_links %> 216 | 217 | 218 | ## Security for apps and services 219 | 220 | This section links to topics that describe how <%= vars.app_runtime_abbr %> and <%= vars.app_runtime_abbr %> users manage security for apps and service instances. 221 | 222 | * [App Security Groups](../concepts/asg.html): Describes how App Security Groups (ASGs) work and how to manage them in <%= vars.app_runtime_abbr %>. 223 | 224 | <%= vars.app_svc_links %> 225 | 226 | * [Trusted System Certificates](../devguide/deploy-apps/trusted-system-certificates.html): Explains where apps can find trusted system certificates. 227 | 228 | * [Managing Access to Service Plans](../services/access-control.html): Describes how to activate or deactivate access to service plans for a subset of users. 229 | 230 | * [Delivering Service Credentials to an App](../devguide/services/application-binding.html): Describes how to bind apps to service instances, which generate the credentials that enable the apps to use the service. 231 | 232 | * [Managing Service Keys](../devguide/services/service-keys.html): Explains how to create and manage service keys that allow apps to use service instances. 233 | -------------------------------------------------------------------------------- /understand-cf-networking.html.md.erb: -------------------------------------------------------------------------------- 1 | --- 2 | title: Container-to-container networking 3 | owner: CF for VMs Networking 4 | --- 5 | 6 | This topic provides you with an overview of how container-to-container networking works in <%= vars.app_runtime_first %>. 7 | 8 | Container-to-container networking is not available for apps hosted on Microsoft Windows. 9 | 10 | The container-to-container networking feature enables app instances to communicate with each other directly. 11 | <%= vars.cf_networking %> 12 | 13 | 14 | ## Architecture 15 | 16 | Container-to-container networking integrates with [Garden-runC] in a Diego deployment. The CF Networking Release includes several core components, as well as swappable components. For more information about Garden-runC, see [Garden-runC](./architecture/garden.html#garden-runc) in _Garden_. For more information about Diego, see [Diego Components and Architecture](./diego/diego-architecture.html). For more information about the CF Networking release, see [CF Networking Release](https://github.com/cloudfoundry-incubator/cf-networking-release) on GitHub. 17 | 18 | To understand the components and how they work, see the following diagram and tables. 19 | The diagram highlights <%= vars.app_runtime_abbr %> components in blue and green. The diagram also highlights swappable components in red. 20 | 21 | ![The c2c architecture diagram](./images/c2c-arch.png) 22 | 23 | ### Core components 24 | 25 | The container-to-container networking BOSH release has the following core components: 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 43 | 44 | 45 | 46 | 54 | 55 | 56 |
PartFunction
Policy ServerA central management node that: 38 |
    39 |
  • Maintains a database of policies for traffic between apps. The cf CLI calls an API to create or update a record in the policy database whenever you create or remove a policy.
    • 40 |
  • Exposes a JSON REST API used by the cf CLI. This API serves traffic using TLS.
    • 41 |
42 |
Garden External Networker 47 | A Garden-runC add-on deployed to every Diego Cell that: 48 |
    49 |
  • Runs the CNI plug-in component to set up the network for each app.
    • 50 |
  • Forwards ports to support incoming connections from the Gorouter, TCP Router, and Diego SSH Proxy. This keeps apps externally reachable.
    • 51 |
  • Installs outbound allow list rules to support Application Security Groups (ASGs).
    • 52 |
53 |
57 | 58 | ### Swappable components 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 76 | 77 | 78 | 79 | 86 | 87 | 88 |
PartFunction
Silk CNI plug-in
A plug-in that provides IP address management and network connectivity to app instances as follows: 71 |
    72 |
  • Uses a shared VXLAN overlay network to assign each container a unique IP address.
    • 73 |
  • Installs network interface in container using the Silk VXLAN back end. This is a shared, flat L3 network.
    • 74 |
75 |
VXLAN Policy Agent
Enforces network policy for traffic between apps as follows: 80 |
    81 |
  • Discovers network policies from the Policy Server Internal API.
    • 82 |
  • Updates iptables rules on the Diego Cell to allow approved inbound traffic.
    • 83 |
  • Tags outbound traffic with the unique identifier of the source app using the VXLAN Group-Based Policy (GBP) header.
    • 84 |
85 |
89 | 90 | 91 | ## App instance communication 92 | 93 | The following diagram illustrates how app instances communicate in a deployment with container-to-container networking enabled. In this example, the operator creates two policies to regulate the flow of traffic between **App A**, **App B**, and **App C**. 94 | 95 | * Allow traffic from **App A** to **App B** 96 | * Allow traffic from **App A** to **App C** 97 | 98 | If traffic and its direction is not explicitly allowed, it is denied. For example, **App B** cannot send traffic to **App C**. 99 | 100 | ![Post Container-to-Container Networking](./images/post-c2c.png) 101 | 102 | 103 | ### Overlay network 104 | 105 | Container-to-container networking uses an overlay network to manage communication between app instances. 106 | 107 | Overlay networks are not externally routable, and traffic sent between containers does not exit the overlay. You can use the same overlay network range for different <%= vars.app_runtime_abbr %> deployments in your environment. 108 | 109 | In older versions of <%= vars.app_runtime_abbr %>, the overlay network had to be one contiguous address range expressed as a single CIDR, for example `"10.255.0.0/18"`. 110 | Current versions also support setting the overlay network to a comma-separated list of multiple CIDR ranges, for example `["10.255.0.0/20", "10.255.96.0/21"]`, in addition to single CIDRs. 111 | 112 | The overlay network defaults to `"10.255.0.0/16"`. You can modify the setting to include any [RFC 1918](https://tools.ietf.org/html/rfc1918) range or ranges that meet the following requirements: 113 | 114 | * The ranges are not used by services that app containers access. 115 | * The ranges are not used by the underlying <%= vars.app_runtime_abbr %> infrastructure. 116 | * The ranges do not overlap with each other. 117 | 118 | All Diego Cells in your <%= vars.app_runtime_abbr %> deployment share this overlay network. By default, each Diego Cell is allocated a /24 range that supports 254 containers per Diego Cell, one container for each of the usable IP addresses, `.1` through `.254`. To modify the number of Diego Cells your overlay network supports, see [Overlay Network](../devguide/deploy-apps/cf-networking.html#overlay) in _Configuring Container-to-Container Networking_. 119 | 120 | <%= vars.app_runtime_abbr %> container networking is currently supported only on Linux. 121 | 122 |

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

126 | 127 |

128 | Updating the overlay network causes container-to-container networking 129 | downtime during the deploy while the network update is rolling out across Diego 130 | Cells. 131 |

132 | 133 | Traffic to app containers from the Gorouter or from app containers to external services uses 134 | Diego Cell IP addresses and NAT, not the overlay network. 135 | 136 | ### Policies 137 | 138 | Enabling container-to-container networking for your deployment allows you to create policies for communication between app instances. The container-to-container networking feature also provides a unique IP address to each app container and provides direct IP reachability between app instances. 139 | 140 | The policies you create specify a source app, destination app, protocol, and port so that app instances can communicate directly without going through the Gorouter, a load balancer, or a firewall. Container-to-container networking supports UDP and TCP, and you can configure policies for multiple ports. These policies apply immediately without having to restart the app. 141 | 142 | Additionally, policies use and and track the GUIDs of the apps. The policies continue to work when apps redeploy, or if they crash and Diego places them in a new container. Pushing a brand new app requires a new policy, but not updates to an existing app because an app always retains its GUID. 143 | 144 | <% if vars.platform_code == "CF" || vars.platform_code == "PCF" %> 145 | 146 | ## App service discovery 147 | 148 | The <%= vars.app_runtime_abbr %> platform supports DNS-based service discovery that lets apps find each other's internal addresses. For example, a front end app instance can use the service discovery mechanism to establish communications with a back end app instance. To set up and use app service discovery, see [App service discovery](../devguide/deploy-apps/cf-networking.html#discovery) in _Configuring container-to-container networking_. 149 | 150 | Container-to-container app service discovery does not provide client-side load balancing or circuit-breaking, and it does not apply to `cf marketplace` services or require app binding. It just lets apps publish service endpoints to each other, unbrokered and unmediated. 151 | 152 | <% end %> 153 | 154 | 155 | ## Alternative network stacks 156 | 157 | The BOSH release that contains the container-to-container networking feature that is composed of a plug-in network stack. Advanced users or third party vendors can integrate a different network stack. For more information about third party plug-ins, see [3rd Party Plug-in Development for Container Networking](https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/11-3rd-party.md) in the CF Networking Release repository on GitHub. 158 | 159 | 160 | ## Container-to-container networking versus ASGs 161 | 162 | Both app security groups (ASGs) and container-to-container networking policies affect traffic from app instances. The following table highlights differences between ASGs and container-to-container networking policies. 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | 180 | 181 | 182 | 183 | 184 | 185 | 186 | 187 | 188 | 189 | 190 | 191 | 192 | 193 | 194 | 195 | 196 | 197 | 198 | 199 |
ASGsContainer-to-Container Networking Policies
Policy granularityFrom a space to an IP address rangeFrom a source app to a destination app
ScopeFor a space, org, or deploymentFor app to app only
Traffic directionOutbound controlPolicies apply for incoming packets from other app instances
Source appIs not knownIs identified because of direct addressability
Policies take affectImmediatelyImmediately
200 | 201 | ## Securing container-to-container traffic 202 | 203 | The platform provides a TLS encapsulation for container-to-container network traffic. 204 | 205 | To utilize TLS capabilities, the client application can connect to port 61443 on the destination application over HTTPS. Traffic to application 206 | container port 61443 is proxied to application port 8080 inside of the container. In this case: 207 | 208 | - The platform provides certificates for each app. 209 | - The platform makes sure that TLS ends within the destination container and passes cleartext traffic to the app. 210 | - The destination app does not need special configuration. 211 | 212 | Additionally, applications can implement TLS termination in their destination applications. Use this option if your application needs to use more TLS capabilities, like verifying client certificates and rejecting service for those that are not permitted, or if your application needs TLS termination on a different port than the default port, 8080. 213 | 214 | Specific Cloud Foundry vendors might provide additional methods for securing container-to-container traffic. 215 | 216 |

For information about how the platform can encrypt public traffic to apps, see 217 | TLS to Apps and Other Back End Services in 218 | HTTP Routing. 219 |

220 | --------------------------------------------------------------------------------