文章目录
1. Chapter Overview
2. Source Paths: Overview
2.1 Using the Current Directory
2.2 Specifying a Path
2.3 Specifying a ZIP File
2.4 Tidy Up
3. Manifests Overview
3.1 Creating Manifests via the CLI
3.2 Testing the Manifest
3.3 CLI vs Manifest Precedence
3.4 Variables in Manifests
4. Buildpack Basics: Overview
4.1 Available Buildpacks
4.2 Git Buildpacks
5. Environment Variables: Overview
5.1 Preparation
5.2 Setting Environment Variables
5.3 Inspecting Environment Variables
5.4 Updating Environment Variables
5.5 Adding Environment Variables to the Manifest
5.6 Unsetting Environment Variables
5.7 Platform Environment Variables
5.8 Environment Variable Groups
6. Metadata: Overview
6.1 Labels
6.2 Annotations
7. scale
7.1 Horizontal Scaling
7.2 Vertical Scaling
7.3 A Quick Word on the App Autoscaler
8. Logs: Overview
8.1 Following Logs in Real-Time
8.2 Inspecting Recent Logs
8.3 Log Drains
8.4 Events
9. Resiliency: Overview
9.1 Killing an App Instance
9.2 Pretty Cool. So What Happened?
10. Quotas: Review
10.1 Org Quotas
10.2 Space Quotas
11. Application Security Groups: Overview
11.1 Staging and Running ASGs
11.2 Space-scoped ASGs
1. Chapter Overview
In this module, we take you through the basics of deploying and managing applications in Cloud Foundry:
Source paths are mechanism for specifying the location of application content when pushing applications.
Manifests provide declarative configuration for an application. This section discusses how to make a manifest, and why they’re a good approach when combined with version control.
Buildpacks are used to containerize applications. In this section, we briefly look at how buildpacks work in Cloud Foundry.
Examine the method for passing environment variables to applications.
Metadata allows you to provide additional information to resources with labels and annotations.
Apps can be scaled both horizontally and vertically in Cloud Foundry. This section describes the procedure for both.
Log output contains lots of useful information about an application,and is essential for troubleshooting.
Cloud Foundry is ensuring the correct number of app instances are running. This section demonstrates one of the resiliency features built into the platform.
Quotas are named sets of memory, service, and instance usage limits that apply to an org or space. As a Cloud Foundry developer, it’s important to understand what quotas are applied to the space you’re working in.
Application security groups can be used to restrict egress from both staging and running apps.
2. Source Paths: Overview
Source paths let you specify a path to the application when running cf push. It is important to understand what you are pushing to Cloud Foundry.
2.1 Using the Current Directory
When you cf push without specifying a path, the contents of the current directory you ran the push command from are pushed up. This is what we did in the first-push exercise. However, you should be careful with this, as it can result in unexpected behavior when you are not in the directory you expect. Therefore, it is always safer to explicitly specify a path.
2.2 Specifying a Path
You can use the --path (or -p) flag to give the location of the directory containing the application content. The path can also point to a specific application artifact like a .jar or .zip file.
You can also specify the path in the manifest file:
--- ... path: /path/to/app/bits
A quick word on manifests vs the CLI: Broadly, you can think of the CLI commands you run against an app as experimental. Any declarations made via the CLI can, and should be, reflected in the manifest if you’d like them to persist. Manifests live in version control and are shared among developers in a way that CLI commands cannot. Throughout the course, we will use a combination of CLI commands and manifests.
If you declare the -p parameter, this will take precedence over a path declared in the manifest.
If you push without specifying a path in the manifest or a -p parameter, the CLI will push the contents of your current working directory (we did this when we pushed our first-push app earlier in the course). It’s a bad idea to get into this habit, as unexpected things can happen (like accidentally pushing a folder of your home movies). Therefore, you should always specify a source path.
2.3 Specifying a ZIP File
Cloud Foundry supports pushing .zip files containing your app code. An app packaged as a .zip file exists in the zip-file directory of the course materials. Let’s push it, being sure to specify the path to the .zip file.
This app doesn’t have a manifest with it, so we’ll need to specify some parameters via the CLI.
cf push zip-with-src-path -p app.zip -b staticfile_buildpack -m 32M -k 64M --random-route
If you access the app in a browser, you should see the Cloud Foundry logo.
While specifying a path is best practice for all app deployments, when pushing .zip files, it is mandatory. If you don’t pass a path to a .zip file, Cloud Foundry won’t unzip the file before deploying it. The implications of this vary depending on the buildpack you’re using. Our goal is to avoid any unexpected behavior.
Let’s test this out ourselves with the staticfile buildpack and see what happens. Be sure you are in the zip-file directory before pushing.
cf push zip-no-src-path -b staticfile_buildpack -m 32M -k 64M --random-route
If you access this app in a browser, you should see a 403 error. If you access the app’s URL and append it with /app.zip, the app package will be downloaded to your local machine. When we omitted the path, Cloud Foundry didn’t unzip the files. The staticfile buildpack assumed you wanted to pass the entire directory contents during staging, even though it only contains a single file.
Again, make sure you always provide a path when pushing.
2.4 Tidy Up
Before we move on, let’s clean up a little. Delete the zip-no-src-path app, as we won’t need it anymore.
cf delete -r zip-no-src-path
Rather than deleting the zip-with-src-path app, let’s rename it to something more sensible, so that we can use it in later sections:
cf rename zip-with-src-path static-app
3. Manifests Overview
Manifests have been mentioned a handful of times already in this course. In the Source Paths section, the static-app was deployed and configured entirely via command-line arguments. And while this worked fine for our first deployment, if we wanted to deploy it again in another space or share the configuration with a colleague, we’d need to recall the CLI arguments we used. Sharing CLI commands isn’t a very reliable way to deploy our app, especially if something changes in our configuration.
Instead, we use a manifest file to specify values for all configurable parameters. Using a manifest file is a good practice because it can be kept in version control. A version-controlled manifest is consistent and can be shared between developers. It also allows manifest updates to be rolled out to multiple deployments quickly and efficiently, especially when integrated as part of a CI/CD pipeline.
3.1 Creating Manifests via the CLI
You can write a manifest from scratch manually by following the Cloud Foundry documentation. But that requires a fair amount of YAML wrangling. Instead, Cloud Foundry can create a manifest for you based on the current state of a deployed application. Use the CLI to generate a manifest for the static-app:
cf create-app-manifest static-app
The CLI will generate a manifest file in your current directory.
Note: the name of the file is static-app_manifest.yml, not manifest.yml, as it’s named after the app. To use this manifest on a push, you need to supply the -f flag and the path to the manifest (or rename the file to manifest.yml, which is the default that the CLI will look for in the current directory).
Looking at the app manifest, you’ll notice it includes the stack property. You didn’t specify this when you pushed the app, so Cloud Foundry used its default value.
3.2 Testing the Manifest
Let’s test our new manifest. Start by deleting the static-app, then re-pushing it with the manifest.
cf delete -f -r static-app cf push -f static-app_manifest.yml
Try running cf delete --help to see what the flags in the command above do.
If you used the exact commands above, the app will not deploy correctly. When you open the app route in a browser, you will see a 403 error. This is the same error you saw in the Source Paths section. Open the manifest and see if you can figure out what’s wrong.
Cloud Foundry can only include the config elements in the generated manifest that it knows about. The path to the app.zip file is missing from the generated manifest. Cloud Foundry doesn’t know the path you used on your local filesystem. Fix this by adding the path to the manifest, or by pushing with the -p parameter. How you choose to fix this will depend on your use case. For now, let’s push with the -p parameter:
cf push -f static-app_manifest.yml -p app.zip
The app should now correctly display the Cloud Foundry logo again.
3.3 CLI vs Manifest Precedence
When working with manifests, you can override their values on the command line. You can test this out by re-pushing, but specifying a different disk allocation.
cf push -f static-app_manifest.yml -p app.zip -k 128M
If you want to make this change permanent, you should add it to the manifest. Otherwise, the next time you push the manifest without the -k 128M parameter, the current value is overridden.
This reiterates the point made earlier in this section; passing parameters to the CLI is good for experimenting, but permanent changes should be reflected in a manifest that lives in version control.
You can also explicitly ignore the manifest when pushing using the --no-manifest flag.
3.4 Variables in Manifests
Manifests support the parameterization of values. For example, you likely want to use a different route for the development version of your app than for the production version. You could parameterize the route value and have it set on push. This allows you to use the same manifest for dev and production.
Variables are declared inside double parenthesis: i.e. ((my-variable)). To demonstrate, let’s parameterize the number of instances in our manifest by editing the file:
--- applications: - name: training-app instances: ((instances)) memory: 64M buildpacks: - go_buildpack
We can then push with:
cf push -f static-app_manifest.yml -p app.zip --var instances=1
While this looks similar to cf push -i 1, variables are required to be passed in during push.
It is good practice to define a vars file for each environment (development, staging, prod, etc) rather than relying on variables on the command line. In this way, we would be declaring (in files in source control) all of the deployment configuration for each environment. We could therefore define a file static-app_dev.yml:
instances: 1
And then push with:
cf push -f static-app_manifest.yml -p app.zip --vars-file=static-app_dev.yml
4. Buildpack Basics: Overview
Before we continue, let’s briefly discuss this “buildpack” thing we have referenced a few times. Buildpacks are responsible for containerizing your application. Essentially, they provide the runtime environment your application needs. The Python buildpack knows how to construct runtimes for Python apps, the Java buildpack for Java, and Go buildpack for Go-lang, etc. The staticfile buildpack we have used so far uses nginx to serve static content.
Buildpacks construct runtimes during the “staging” phase of an application (more on this later).
4.1 Available Buildpacks
So far, we’ve been using the staticfile_buildpack in our push commands. But there are many others.
To view the available buildpacks in your Cloud Foundry instance run:
cf buildpacks
The listed buildpacks are configured by your Cloud Foundry operator. These available buildpacks are referred to as “system” buildpacks, as they are available in the system for all users.
4.2 Git Buildpacks
In addition to the system buildpacks, many Cloud Foundry instances allow you to specify the URL of a specific version of a buildpack in a git repository. In this case, Cloud Foundry will download the specific version of the buildpack and use it to stage the application.
Note the use of git buildpacks can be disabled by Cloud Foundry administrators.
If enabled, you could deploy the training-app using a specific version of a git buildpack with:
cf push -b https://github.com/cloudfoundry/staticfile-buildpack.git#v1.5.21
Of course, you would want to add this value to your manifest if you planned to use it. We’ll look more at buildpacks later in this course.
5. Environment Variables: Overview
Environment variables inject configuration values into applications. As the 12-factor app principles state, we should “store config in the environment”. In this section, we’ll test out passing environment variables to a training-app.
5.1 Preparation
The golang application used in this section will display some basic information about the app itself, including its environment variables.
Firstly, let’s deploy the training-app using the supplied manifest. The application and manifest are in the training-app directory in the course resources:
cf push training-app -f manifest.yml -p training-app.zip --random-route
Access the app in a browser and make sure you see can see the interface. You will notice that at this point the application UI is not displaying any environment variables.
5.2 Setting Environment Variables
This app will display any environment variable that starts with TRAINING_. Set some environment variables (but don’t restart or restage yet):
cf set-env training-app TRAINING_KEY_1 training-value-1 cf set-env training-app TRAINING_KEY_2 training-value-2 cf set-env training-app TRAINING_KEY_3 training-value-3
Notice the CLI provides a tip: TIP: Use ‘cf restage training-app’ to ensure your env variable changes take effect. If you access your app in a browser before restarting/restaging, you will see why; the app does not see the new environment variables yet.
Now restart the app and view it in a browser (we will discuss restart versus restage in a later section). You should see the three environment variables you set above.
cf restart training-app
5.3 Inspecting Environment Variables
Most apps do not (and should not) show environment variables in their publicly accessible UI. However, you can use cf env to inspect their environment variables and values.
cf env training-app
Be sure you have restaged or restarted your app so that the app sees the same values you see when using cf env.
Before you restage or restart after changing environment variables, cf env will show the latest values, while the app will only see and display the older values in its UI.
5.4 Updating Environment Variables
You can change an environment variable value by using cf set-env and providing a new value:
cf set-env training-app TRAINING_KEY_3 training-value-3_1
Remember to restart the app to see the change.
5.5 Adding Environment Variables to the Manifest
To ensure the environment variables are configured correctly on every push, be sure to add them to the manifest. If you take a look at the training-app manifest, you’ll see that the app already has one environment variable set called GOPACKAGENAME.
Update your local copy of the manifest to include the three TRAINING_KEY_* values previously set manually via cf set-env.
Delete the existing training-app and re-deploy using the updated manifest, and check that the environment variables are correct.NOTE: You should avoid putting secrets directly in the manifest. Instead, use variables in the manifest and store secrets outside of
source control.
5.6 Unsetting Environment Variables
To remove an environment variable, you use cf unset-env. Because you can set variables via the CLI or a manifest, simply removing a value from a manifest and re-pushing will not work. You must unset the value via the CLI and remove it from the manifest.
cf unset-env training-app TRAINING_KEY_1
5.7 Platform Environment Variables
When you read the environment variables for an app with cf env, you will have noticed that there were more than the user-provided values you set. Cloud Foundry also injects configuration for your application via environment variables. Two common variables are VCAP_APPLICATION, which provides configuration and information about the application instance, and VCAP_SERVICES, which provides configuration for accessing service instances. Applications can decide to use these environment variables if necessary (the sample application is reading and displaying some of these values). A complete list of platform environment variables is provided in the Cloud Foundry documentation.
5.8 Environment Variable Groups
Environment variable groups are system-wide variables that Cloud Foundry operators can apply to all running apps and all staging apps. Environment variable groups are typically used to provide generally applicable, albeit optional, configuration values for a specific Cloud Foundry instance. Each group consists of a single hash of case-sensitive name-value pairs that are inserted into an app container at either runtime or staging. These values can contain information such as HTTP proxy information.
When creating environment variable groups, only the CF operator can set the value for each group, but authenticated users can view the environment variables assigned to their app. In the event you set an environment variable of the same name, the user-defined value(s) you provide will take precedence over environment variables provided by these groups. So they can effectively be overwritten on an app-by-app basis.
Platform operators configure environmental variable groups. As a developer, you will not be configuring these values. However, you can view any existing environment variable groups with the following commands:
cf running-environment-variable-group cf staging-environment-variable-group
These commands will retrieve the contents of any running and staging variable groups.
修改环境变量
