This post will explore two new workflows enabled by the recently launched V3 API.
- Processes and their management via a Procfile: run your web, scheduler, and worker in the same app.
- Granular control over application deployments: build your own cf-push.
These new APIs are accessible to application developers via new cli commands that are currently available as experimental. The underlying features and apps that are enabled by the new commands are considered stable, so please make use of them. However, the cli command interface may change, so hold off on using them in scripts until a GA announcement has been made.
To get started, make sure you are on at least CF API version 2.92.0 and grab cf cli version v6.32.0.
$ cf target api endpoint: https://api.my-cf.com api version: 2.92.0
1. Processes and Procfiles
Let’s take a look at the first new workflow discussed above: Processes and managing them via Procfile.
What is a Process?
Process is a new resource that supports applications that need to run in multiple modes using the same codebase. The canonical example for this is a web application that has a web UI process and a separate worker process.
How did we survive before Processes?
Today this can be accomplished on Cloud Foundry by pushing the code to two separate applications, where each app has a different start command.
$ cf push myapp-web -c ‘bundle exec rackup config.ru -p $PORT’ $ cf push myapp-worker -c ‘bundle exec rake worker:start’
Let’s use a Procfile
Using Processes, we can achieve the same result with only a single push and a `Procfile`. A `Procfile` defines the processes for an app and the start command for each process. For the above example, we can define a `Procfile` like this:
web: bundle exec rackup config.ru -p $PORT worker: bundle exec rake worker:start
Now place that `Procfile` at the root of the application directory and push using the experimental cli command `v3-push`.
$ cf v3-push myapp
With that, the app is pushed to Cloud Foundry. By default, Cloud Foundry will assign a route to the `web` process (if it is available) and scale it to one instance.
Scaling your processes
For additional processes, we can scale them as needed after the deployment.
$ cf v3-scale myapp --process worker -i 2
If we take a look at our app now, we can see both a web and worker process, and they are scaled independently of each other.
$ cf v3-app myapp Showing health and status for app myapp in org test / space test as admin... name: myapp requested state: started processes: web:1/1, worker:2/2 memory usage: 256M x 1, 256M x 2 routes: myapp.cloudfoundry.example.com stack: cflinuxfs2 buildpacks: ruby web:1/1 state since cpu memory disk #0 running 2017-09-25 15:43:26 PM 0.2% 18.9M of 256M 84.4M of 1G worker:2/2 state since cpu memory disk #0 running 2017-09-25 15:49:46 PM 0.1% 5M of 256M 73M of 1G #1 running 2017-09-25 15:49:46 PM 0.1% 5M of 256M 73M of 1G
2. Granular deployments
Next, let’s take a look at the second new workflow: Granular control over application deployments
What do you mean by “granular”?
If you have used the `cf push` command, then you understand the power of a platform. With one command, your application is uploaded, compiled using a language-specific buildpack (the staging process), given a url, and then executed and health managed. That’s a lot! In many cases, this is exactly what a developer wants; however, sometimes a developer may only want to perform some of those steps or perform specific actions in between those steps. This is where granular deployments come into play.
What new resources can I interact with?
To support custom deployment workflows, we divided apps into smaller building blocks.
App – The top level resource that represents your application and its configuration.
Package – The source code that makes up an application.
Build – The staging process. Creating a build combines a Package with a Buildpack and builds it into a resource that can be executed on the platform
Droplet – A runnable resource that results from a Build.
How do I use these new resources?
As always, the cf cli is how we interact with our applications. To see a full list of experimental commands available, grab the latest cf cli and run `cf help -a | grep v3`
Building your own push
We can use our more granular commands to push an application. For example, we might use these granular commands if we want to update a third party system before we stage.
First let’s create the app.
$ cf v3-create-app myapp This command is in EXPERIMENTAL stage and may change without notice Creating V3 app myapp in org test / space test as admin... OK Next, we need to upload our source code. Change into the application directory and create a package for our app. $ cf v3-create-package myapp This command is in EXPERIMENTAL stage and may change without notice Uploading and creating bits package for app myapp in org test / space test as admin... package guid: 0dfca85a-8ed4-4f00-90d0-3ab08852dba8 OK
Now we can stage our package. Note, the previous command gave us a Package GUID. We’ll use that to tell our staging process which package to use.
$ cf v3-stage myapp --package-guid 0dfca85a-8ed4-4f00-90d0-3ab08852dba8 Staging package for myapp in org test / space test as admin... ... Package staged droplet guid: f60d3464-415a-4202-9d40-26a70373a487 state: staged created: Mon 25 Sep 16:37:45 PDT 2017
Next, we want to assign our droplet to the app. This tells the application which droplet to execute. Note the Droplet GUID we got in the previous command — we’ll use that here.
$ cf v3-set-droplet myapp -d f60d3464-415a-4202-9d40-26a70373a487 Setting app myapp to droplet f60d3464-415a-4202-9d40-26a70373a487 in org test / space test as admin... OK
Finally we can fire up our app!
$ cf v3-start myapp
But I’m already happy with push, what else can I do?
It’s entirely possible you don’t need to build your own push. Fortunately, there are other things we can do with the new granular commands. Imagine you have just pushed an update to your application, and it has a bug that is bringing your site down. All we need to do is switch back to the previous droplet we were using.
First we’ll find the previous droplet
$ cf v3-droplets myapp This command is in EXPERIMENTAL stage and may change without notice Listing droplets of app myapp in org test / space test as admin... guid state created 66524145-5502-40e6-b782-47fe68e13c49 staged Mon 25 Sep 16:37:34 PDT 2017 0677ad93-9f77-4aaa-9a6b-44da022dcd58 staged Mon 25 Sep 16:44:55 PDT 2017
Grab the second to last GUID in this list by datetime. In this case: `66524145-5502-40e6-b782-47fe68e13c49`. Set the app to use the desired droplet’s GUID and you’re good to go.
$ cf v3-stop myapp $ cf v3-set-droplet myapp -d 66524145-5502-40e6-b782-47fe68e13c49 $ cf v3-start myapp
Wrap up
The key take-away is that there are more building blocks available to enable developers to build workflows that fit their needs. The process building blocks can be used to simplify micro service deployments from many apps to a single push. The granular push commands enable customization of the deployment workflow, from retrying failed stagings without incurring downtime, to calling external services to report audit data during deployment steps.
Questions or feedback? See us on slack. Happy cf-pushing!
