Added remaining manifest properties md files
Also added hover test case for each manifest property.
This commit is contained in:
nsingh
@@ -0,0 +1,30 @@
|
||||
Some languages and frameworks require that you provide a custom command to start an application. Refer to the [buildpack](/buildpacks/) documentation to determine if you need to provide a custom start command.
|
||||
|
||||
You can provide the custom start command in your application manifest or on the command line.
|
||||
|
||||
To specify the custom start command in your application manifest, add it in the `command: START-COMMAND` format as the following example shows:
|
||||
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
command: bundle exec rake VERBOSE=true
|
||||
```
|
||||
|
||||
On the command line, use the `-c` option to specify the custom start command as the following example shows:
|
||||
|
||||
```
|
||||
$ cf push my-app -c "bundle exec rake VERBOSE=true"
|
||||
```
|
||||
|
||||
**Note**: The `-c` option with a value of ‘null’ forces `cf push` to use the buildpack start command. See [About Starting Applications](./app-startup.html) for more information.
|
||||
|
||||
If you override the start command for a Buildpack application, Linux uses `bash -c YOUR-COMMAND` to invoke your application. If you override the start command for a Docker application, Linux uses `sh -c YOUR-COMMAND` to invoke your application. Because of this, if you override a start command, you should prefix `exec` to the final command in your custom composite start command.
|
||||
|
||||
`exec` causes the last command to become the root process of your application. The [Cloud Foundry Updates and Your Application](./prepare-to-deploy.html#moving-apps) section of the _Considerations for Designing and Running an Application in the Cloud_ topic explains why your application should handle a `termination signal` during Cloud Foundry updates. Without an `exec` statement, the parent process remains as the implied bash process, and does not propagate signals to your application process.
|
||||
|
||||
For example, both of the following composite start commands run database migrations when the first instance of the app starts, then start the app to serve requests, but they behave differently on graceful shutdown.
|
||||
|
||||
* `bin/rake cf:on_first_instance db:migrate && bin/rails server -p $PORT -e $RAILS_ENV`: The process tree is `bash -> ruby`, so on graceful shutdown only the `bash` process receives the TERM signal, and not the `ruby` process.
|
||||
|
||||
* `bin/rake cf:on_first_instance db:migrate && exec bin/rails server -p $PORT -e $RAILS_ENV`: Because of the `exec` prefix on the final command, the `ruby` process invoked by `rails` takes over the `bash` process managing the execution of the composite command. The process tree is only `ruby`, so the ruby web server receives the TERM signal can shutdown gracefully for 10 seconds.
|
||||
@@ -0,0 +1,9 @@
|
||||
Use the `disk_quota` attribute to allocate the disk space for your app instance. This attribute requires a unit of measurement: `M`, `MB`, `G`, or `GB`, in upper case or lower case.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
disk_quota: 1024M
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-k`.
|
||||
@@ -0,0 +1,25 @@
|
||||
Every `cf push` deploys applications to one particular Cloud Foundry instance. Every Cloud Foundry instance may have a shared domain set by an admin. Unless you specify a domain, Cloud Foundry incorporates that shared domain in the route to your application.
|
||||
|
||||
You can use the `domain` attribute when you want your application to be served from a domain other than the default shared domain.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
domain: unique-example.com
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-d`.
|
||||
|
||||
### The domains attribute
|
||||
|
||||
Use the `domains` attribute to provide multiple domains. If you define both `domain` and `domains` attributes, Cloud Foundry creates routes for domains defined in both of these fields.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
domains:
|
||||
- domain-example1.com
|
||||
- domain-example2.org
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-d`.
|
||||
@@ -0,0 +1,11 @@
|
||||
Use the `domains` attribute to provide multiple domains. If you define both `domain` and `domains` attributes, Cloud Foundry creates routes for domains defined in both of these fields.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
domains:
|
||||
- domain-example1.com
|
||||
- domain-example2.org
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-d`.
|
||||
@@ -0,0 +1,24 @@
|
||||
The `env` block consists of a heading, then one or more environment variable/value pairs.
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
env:
|
||||
RAILS_ENV: production
|
||||
RACK_ENV: production
|
||||
```
|
||||
|
||||
`cf push` deploys the application to a container on the server. The variables belong to the container environment.
|
||||
|
||||
While the application is running, Cloud Foundry allows you to operate on environment variables.
|
||||
|
||||
* View all variables: `cf env my-app`
|
||||
* Set an individual variable: `cf set-env my-app my-variable_name my-variable_value`
|
||||
* Unset an individual variable: `cf unset-env my-app my-variable_name my-variable_value`
|
||||
|
||||
Environment variables interact with manifests in the following ways:
|
||||
|
||||
* When you deploy an application for the first time, Cloud Foundry reads the variables described in the environment block of the manifest, and adds them to the environment of the container where the application is deployed.
|
||||
* When you stop and then restart an application, its environment variables persist.
|
||||
@@ -0,0 +1,9 @@
|
||||
Use the `host` attribute to provide a hostname, or subdomain, in the form of a string. This segment of a route helps to ensure that the route is unique. If you do not provide a hostname, the URL for the app takes the form of `APP-NAME.DOMAIN`.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
host: my-app
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-n`.
|
||||
@@ -0,0 +1,11 @@
|
||||
Use the `hosts` attribute to provide multiple hostnames, or subdomains. Each hostname generates a unique route for the app. `hosts` can be used in conjunction with `host`. If you define both attributes, Cloud Foundry creates routes for hostnames defined in both `host` and `hosts`.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
hosts:
|
||||
- app_host1
|
||||
- app_host2
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-n`.
|
||||
@@ -0,0 +1,63 @@
|
||||
A single manifest can describe multiple applications. Another powerful technique is to create multiple manifests with inheritance. Here, manifests have parent-child relationships such that children inherit descriptions from a parent. Children can use inherited descriptions as-is, extend them, or override them.
|
||||
|
||||
Content in the child manifest overrides content in the parent manifest, if the two conflict.
|
||||
|
||||
This technique helps in these and other scenarios:
|
||||
|
||||
* An application has a set of different deployment modes, such as debug, local, and public. Each deployment mode is described in child manifests that extend the settings in a base parent manifest.
|
||||
|
||||
* An application is packaged with a basic configuration described by a parent manifest. Users can extend the basic configuration by creating child manifests that add new properties or override those in the parent manifest.
|
||||
|
||||
The benefits of multiple manifests with inheritance are similar to those of minimizing duplicated content within single manifests. With inheritance, though, we “promote” content by placing it in the parent manifest.
|
||||
|
||||
Every child manifest must contain an “inherit” line that points to the parent manifest. Place the inherit line immediately after the three dashes at the top of the child manifest. For example, every child of a parent manifest called `base-manifest.yml` begins like this:
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
inherit: base-manifest.yml
|
||||
```
|
||||
You do not need to add anything to the parent manifest.
|
||||
|
||||
In the simple example below, a parent manifest gives each application minimal resources, while a production child manifest scales them up.
|
||||
|
||||
**simple-base-manifest.yml**
|
||||
|
||||
```
|
||||
---
|
||||
path: .
|
||||
domain: shared-domain.com
|
||||
memory: 256M
|
||||
instances: 1
|
||||
services:
|
||||
- singular-backend
|
||||
|
||||
# app-specific configuration
|
||||
applications:
|
||||
- name: springtock
|
||||
host: 765shower
|
||||
path: ./april/build/libs/april-weather.war
|
||||
- name: wintertick
|
||||
host: 321flurry
|
||||
path: ./december/target/december-weather.war
|
||||
```
|
||||
|
||||
**simple-prod-manifest.yml**
|
||||
|
||||
```
|
||||
---
|
||||
inherit: simple-base-manifest.yml
|
||||
applications:
|
||||
- name:springstorm
|
||||
memory: 512M
|
||||
instances: 1
|
||||
host: 765deluge
|
||||
path: ./april/build/libs/april-weather.war
|
||||
- name: winterblast
|
||||
memory: 1G
|
||||
instances: 2
|
||||
host: 321blizzard
|
||||
path: ./december/target/december-weather.war
|
||||
```
|
||||
|
||||
**Note**: Inheritance can add an additional level of complexity to manifest creation and maintenance. Comments that precisely explain how the child manifest extends or overrides the descriptions in the parent manifest can alleviate this complexity.
|
||||
@@ -0,0 +1,11 @@
|
||||
Use the `instances` attribute to specify the number of app instances that you want to start upon push:
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
instances: 2
|
||||
```
|
||||
|
||||
We recommend that you run at least two instances of any apps for which fault tolerance matters.
|
||||
|
||||
The command line option that overrides this attribute is `-i`.
|
||||
@@ -0,0 +1,9 @@
|
||||
The `name` attribute is the only required attribute for an application in a manifest file.
|
||||
|
||||
This is an example of a minimal manifest:
|
||||
|
||||
```
|
||||
---
|
||||
applications:
|
||||
- name: nifty-gui
|
||||
```
|
||||
@@ -0,0 +1,9 @@
|
||||
By default, if you do not provide a hostname, the URL for the app takes the form of `APP-NAME.DOMAIN`. If you want to override this and map the root domain to this app then you can set no-hostname as true.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
no-hostname: true
|
||||
```
|
||||
|
||||
The command line option that corresponds to this attribute is `--no-hostname`.
|
||||
@@ -0,0 +1,16 @@
|
||||
By default, `cf push` assigns a route to every application. But some applications process data while running in the background, and should not be assigned routes.
|
||||
|
||||
You can use the `no-route` attribute with a value of `true` to prevent a route from being created for your application.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
no-route: true
|
||||
```
|
||||
|
||||
The command line option that corresponds to this attribute is `--no-route`.
|
||||
|
||||
If you find that an application which should not have a route does have one:
|
||||
|
||||
1. Remove the route using the `cf unmap-route` command.
|
||||
2. Push the app again with the `no-route: true` attribute in the manifest or the `--no-route` command line option.
|
||||
@@ -0,0 +1,9 @@
|
||||
You can use the `path` attribute to tell Cloud Foundry where to find your application. This is generally not necessary when you run `cf push` from the directory where an application is located.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
path: path_to_application_bits
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-p`.
|
||||
@@ -0,0 +1,9 @@
|
||||
Use the `random-route` attribute to create a URL that includes the app name and random words. Use this attribute to avoid URL collision when pushing the same app to multiple spaces, or to avoid managing app URLs.
|
||||
|
||||
The command line option that corresponds to this attribute is `--random-route`.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
random-route: true
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
Applications can bind to services such as databases, messaging, and key-value stores.
|
||||
|
||||
Applications are deployed into App Spaces. An application can only bind to services instances that exist in the target App Space before the application is deployed.
|
||||
|
||||
The `services` block consists of a heading, then one or more service instance names.
|
||||
|
||||
Whoever creates the service chooses the service instance names. These names can convey logical information, as in `backend_queue`, describe the nature of the service, as in `mysql_5.x`, or do neither, as in the example below.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
services:
|
||||
- instance_ABC
|
||||
- instance_XYZ
|
||||
```
|
||||
|
||||
Binding to a service instance is a special case of setting an environment variable, namely `VCAP_SERVICES`.
|
||||
@@ -0,0 +1,11 @@
|
||||
Use the `stack` attribute to specify which stack to deploy your application to.
|
||||
|
||||
To see a list of available stacks, run `cf stacks` from the cf cli.
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
stack: cflinuxfs2
|
||||
```
|
||||
|
||||
The command line option that overrides this attribute is `-s`.
|
||||
@@ -0,0 +1,15 @@
|
||||
The `timeout` attribute defines the number of seconds Cloud Foundry allocates for starting your application.
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
---
|
||||
...
|
||||
timeout: 80
|
||||
```
|
||||
|
||||
You can increase the timeout length for very large apps that require more time to start. The default timeout is 60 seconds with an upper bound of 180 seconds.
|
||||
|
||||
**Note**: Administrators can set the upper bound of the `maximum_health_check_timeout` property to any value. Any changes to Cloud Controller properties in the deployment manifest require running `bosh deploy`.
|
||||
|
||||
The command line option that overrides the timeout attribute for the shell is `-t`. Manifest values still apply to applications pushed to the deployment.
|
||||
@@ -11,12 +11,9 @@
|
||||
package org.springframework.ide.vscode.manifest.yaml;
|
||||
|
||||
import org.junit.Before;
|
||||
import org.junit.Ignore;
|
||||
import org.junit.Test;
|
||||
import org.springframework.ide.vscode.commons.languageserver.completion.VscodeCompletionEngineAdapter;
|
||||
import org.springframework.ide.vscode.languageserver.testharness.Editor;
|
||||
import org.springframework.ide.vscode.languageserver.testharness.LanguageServerHarness;
|
||||
import org.springframework.ide.vscode.manifest.yaml.ManifestYamlLanguageServer;
|
||||
|
||||
public class ManifestYamlEditorTest {
|
||||
|
||||
@@ -369,20 +366,75 @@ public class ManifestYamlEditorTest {
|
||||
public void hoverInfos() throws Exception {
|
||||
Editor editor = harness.newEditor(
|
||||
"memory: 1G\n" +
|
||||
"inherit: base-manifest.yml\n"+
|
||||
"applications:\n" +
|
||||
"- buildpack: zbuildpack\n" +
|
||||
" domain: zdomain\n" +
|
||||
" name: foo"
|
||||
" name: foo\n" +
|
||||
" command: java main.java\n" +
|
||||
" disk_quota: 1024M\n" +
|
||||
" domains:\n" +
|
||||
" - pivotal.io\n" +
|
||||
" - otherdomain.org\n" +
|
||||
" env:\n" +
|
||||
" RAILS_ENV: production\n" +
|
||||
" RACK_ENV: production\n" +
|
||||
" host: apppage\n" +
|
||||
" hosts:\n" +
|
||||
" - apppage2\n" +
|
||||
" - appage3\n" +
|
||||
" instances: 2\n" +
|
||||
" no-hostname: true\n" +
|
||||
" no-route: true\n" +
|
||||
" path: somepath/app.jar\n" +
|
||||
" random-route: true\n" +
|
||||
" services:\n" +
|
||||
" - instance_ABC\n" +
|
||||
" - instance_XYZ\n" +
|
||||
" stack: cflinuxfs2\n" +
|
||||
" timeout: 80\n"
|
||||
);
|
||||
editor.assertIsHoverRegion("memory");
|
||||
editor.assertIsHoverRegion("inherit");
|
||||
editor.assertIsHoverRegion("applications");
|
||||
editor.assertIsHoverRegion("buildpack");
|
||||
editor.assertIsHoverRegion("domain");
|
||||
editor.assertIsHoverRegion("name");
|
||||
editor.assertIsHoverRegion("command");
|
||||
editor.assertIsHoverRegion("disk_quota");
|
||||
editor.assertIsHoverRegion("domains");
|
||||
editor.assertIsHoverRegion("env");
|
||||
editor.assertIsHoverRegion("host");
|
||||
editor.assertIsHoverRegion("hosts");
|
||||
editor.assertIsHoverRegion("instances");
|
||||
editor.assertIsHoverRegion("no-hostname");
|
||||
editor.assertIsHoverRegion("no-route");
|
||||
editor.assertIsHoverRegion("path");
|
||||
editor.assertIsHoverRegion("random-route");
|
||||
editor.assertIsHoverRegion("services");
|
||||
editor.assertIsHoverRegion("stack");
|
||||
editor.assertIsHoverRegion("timeout");
|
||||
|
||||
editor.assertHoverContains("memory", "Use the `memory` attribute to specify the memory limit");
|
||||
editor.assertHoverContains("1G", "Use the `memory` attribute to specify the memory limit");
|
||||
editor.assertHoverContains("inherit", "For example, every child of a parent manifest called `base-manifest.yml` begins like this");
|
||||
editor.assertHoverContains("buildpack", "use the `buildpack` attribute to specify its URL or name");
|
||||
editor.assertHoverContains("name", "The `name` attribute is the only required attribute for an application in a manifest file");
|
||||
editor.assertHoverContains("command", "On the command line, use the `-c` option to specify the custom start command as the following example shows");
|
||||
editor.assertHoverContains("disk_quota", "Use the `disk_quota` attribute to allocate the disk space for your app instance");
|
||||
editor.assertHoverContains("domain", "You can use the `domain` attribute when you want your application to be served");
|
||||
editor.assertHoverContains("domains", "Use the `domains` attribute to provide multiple domains");
|
||||
editor.assertHoverContains("env", "The `env` block consists of a heading, then one or more environment variable/value pairs");
|
||||
editor.assertHoverContains("host", "Use the `host` attribute to provide a hostname, or subdomain, in the form of a string");
|
||||
editor.assertHoverContains("hosts", "Use the `hosts` attribute to provide multiple hostnames, or subdomains");
|
||||
editor.assertHoverContains("instances", "Use the `instances` attribute to specify the number of app instances that you want to start upon push");
|
||||
editor.assertHoverContains("no-hostname", "By default, if you do not provide a hostname, the URL for the app takes the form of `APP-NAME.DOMAIN`");
|
||||
editor.assertHoverContains("no-route", "You can use the `no-route` attribute with a value of `true` to prevent a route from being created for your application");
|
||||
editor.assertHoverContains("path", "You can use the `path` attribute to tell Cloud Foundry where to find your application");
|
||||
editor.assertHoverContains("random-route", "Use the `random-route` attribute to create a URL that includes the app name and random words");
|
||||
editor.assertHoverContains("services", "The `services` block consists of a heading, then one or more service instance names");
|
||||
editor.assertHoverContains("stack", "Use the `stack` attribute to specify which stack to deploy your application to.");
|
||||
editor.assertHoverContains("timeout", "The `timeout` attribute defines the number of seconds Cloud Foundry allocates for starting your application");
|
||||
}
|
||||
|
||||
//////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
@@ -2,4 +2,15 @@ applications:
|
||||
- name: foo
|
||||
foo: bar
|
||||
builpack: java
|
||||
buildpack: java_buildpack
|
||||
memory: 1G
|
||||
command: java main.java
|
||||
disk_quota: 1024M
|
||||
domain: pivotal.io
|
||||
domains:
|
||||
- pivotal.io
|
||||
- other.org
|
||||
env:
|
||||
RAILS_ENV: production
|
||||
RACK_ENV: production
|
||||
|
||||
|
||||
Reference in New Issue
Block a user