From Pivotal Cloud Foundry (PCF) to TAS

Previously known as Pivotal Cloud Foundry (PCF), Tanzu Application Service (TAS) is an open-source, scalable platform as a service (PaaS) cloud application that allows users to manage Kubernetes-backed container services. TAS is designed to manage containers, Kubernetes, and microservices. An advantage of using this with a government client is that there seems to be a solid push to adopt this technology as a standard for Kubernetes-backed services. Allowing TAS to manage infrastructure lets users not worry about building configuration files for Kubernetes. This allows more time spent on developing the product for the customer.

What Are the Prerequisites?

• The application that wants to be hosted by TAS needs to be “cloud-ready.”
  • There are specific buildpacks that TAS has built into it
  • More URL-backed buildpacks can be used if the one needed is not built into TAS.
• TAS supports the application technology.
• Credentials to the TAS service.
• Application services (PostgreSQL, Redis, etc.) are available if the application needs to utilize them.
• Access to the Organization and Space that your administrator set up.
• Install the latest version of Cloud Foundry-Command Line Interface (cf-cli) on the machines that push apps to TAS. You can utilize many commands to maintain and push your applications to TAS. This article uses a few key commands to get started.

If desired, the Cloud Foundry Docs: https://docs.cloudfoundry.org/cf-cli/

How Do I Log into TAS?

Utilizing cf-cli, you can log into the organization and space you or your administrator set up. The `cf login -a api-url ` command handles this and will prompt for credentials, org, and space if they are required. Alternatively, flags can be passed in the command to provide credentials, the org you belong to, and the space where you would like your code pushed. The -a flag of the cf login command is to specify the URL where TAS is located. If required, your administrator may have set up two-factor authentication. Once the proper login command is entered, a message will display a URL to get a code to supply to the command line to finish logging in. Once you have finished logging in, you are ready to push your first application.

Install and Manage Your Applications in TAS

• TAS applications can be managed in two different ways: with the Apps Manager user interface (if enabled by your administrator) or using cf-cli. Utilizing the command line is the most versatile way of managing your application after it is set up. This must be installed on the machine used to push the applications to TAS. If your administrator allows, Spaces and Orgs can be created by you using cf-cli or through the web user interface. The structure for what is needed for an application to run in TAS is as follows:
• Access to the TAS API (credentials and/or 2FA).
• cf-cli installed on the machines that will be performing maintenance and installations.
• Access to a company Organization (Org) in TAS.
• Access to the Space in the Org.
• Ability to bind Services to the application that you are installing.
• Utilizing the built-in buildpacks or adding your own that is not built-in.

After logging into the org and space in the TAS instance you have access to, you can utilize cf-cli to push your app package to the space.

In this example, we are pushing a Spring Boot application to TAS. We need a manifest.yml file to exist in the root of the project files.

This manifest file is an application deployment file that contains the information needed to deploy the application to the TAZ instance. This file always starts with three dashes (—) at the start of the file. Critical attributes are explicitly used in the manifest to describe deployment needs. We use a select few here, but the rest can be found in the App Manifest Attribute Reference (https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html).

• The applications attribute describes the application(s) you want to deploy to TAS.
• The name attribute is the name of your app to be deployed.
• The path is the target of your build package for your app.
• The memory attribute specifies how much memory to allocate for your app when running.
• The disk_quota attribute specifies how much disk space to allocate for your app when running.
• The instance attribute specifies how many instances should be running for your app. This can be scaled via the user interface or through cf-cli after the app is deployed.
• The buildpacks attribute specifies which build pack to use when deploying your app. In this instance, we are building a Spring Boot application. We have selected to use the java buildpack.
• The env attribute specifies any environment variables that are needed for build or run time.

Once your manifest.yml file is created, use the -f flag in the push command to specify where the manifest is located. Then, you are ready to push your app. The `cf push` command will pick up the manifest.yml file you specified and push it to the org and space you are logged into. If you do not want to allow the app to start right after pushing the app, use the `–no-start flag in the command. You may not want the app to auto-start after the push if you need to bind a service to the app before it runs. That can be achieved via the TAS UI or via the command line. The docs will provide more information as to how you bind services. After set up is complete and pushed, you can now run your app with `cf start your-app-name.

After logging into the Apps Manager for your Org, your spaces will be displayed.

Under one of those spaces will be your app you have pushed via cf-cli. The right-most column displays the route that was created for your app. Below is the published URL for your application where your users will have access.

Once you are into the app, you have pushed in the Apps Manager user interface. All the info about your running app will be displayed. From here, you can manage your application.

Let’s Wrap Up

With TAS, you can migrate any running applications into a cloud platform that can run and scale at any given time. It provides the back-end clustering capabilities that many applications use in a cloud environment without the user having to set it up. Its open-source code enables companies to offer their own ‘in-house’ service for their engineers to utilize for their customers.