@CloudExpo Authors: Carmen Gonzalez, Yeshim Deniz, Zakia Bouachraoui, Chander Damodaran, Elizabeth White

Related Topics: @CloudExpo, Open Source Cloud, @DevOpsSummit

@CloudExpo: Blog Feed Post

Getting Started with @Pivotal Cloud Foundry & @AppDynamics | @CloudExpo [#Cloud]

The primary objective of a platform should be to provide a high-level of automation

Getting Started with Pivotal Cloud Foundry and AppDynamics
By Jamie O'Meara

The primary objective of a platform should be to provide a high-level of automation. This provides easy management of applications and services, while delivering consistent and error-free deployment of applications. While this high level automation provides a critical foundation, additional specialized services can be added to increase manageability of the applications deployed on the platform. To assist operators in this pursuit the Pivotal Cloud Foundry platform provides a number of integrated services out-of-the-box, including AppDynamics, New Relic, and CloudBees Jenkins. This blog will focus on the “out-of-the-box” integration between Pivotal Cloud Foundry and AppDynamics.

Pivotal Cloud Foundry Buildpacks and Agent Integration
A buildpack in Pivotal Cloud Foundry provides the framework and runtime support for your application. As applications are deployed or “pushed”, the platform detects the language and includes the appropriate versions of the runtime, as well as any additional application infrastructure. The buildpack also contains the AppDynamics agent, with numerous versions to support different deployments. To successfully deploy the agent we need to provide the proper configuration based on the environment during the deployment.

To create the proper configuration a User Provided Service (UPS) is created. A UPS is an external service created for an organization and space and is bound to an application in Pivotal Cloud Foundry. Once the service is bound to the application and the application is restaged, a process to prepare an application for deployment, the AppDynamics agent has the proper configuration to register with the AppDynamics controller and to transmit metrics to the designated endpoint.

A common practice in AppDynamics is to create a logical model representing different layers of an application. AppDynamics uses the application name, tier name and node name to align the deployed applications with the AppDynamics logical model. The Pivotal Cloud Foundry platform, specifically the buildpacks and UPS, provide the mechanism to align deployed applications to the logical model.

The diagram below depicts the Spring Trader application deployed on Pivotal Cloud Foundry. Spring Trader includes three Spring-based applications that are designed to represent a simple trading platform. The deployment artifacts include a web UI component written in Spring MVC, a RESTful API component that provides portfolio and trade data via a persistent store and RabbitMQ, and an asynchronous service for quote generation. Each of these applications are deployed into their own container, and each have their own UPS to define a tier within AppDynamics. This deployment aligns the applications to the AppDynamics logical model using the application and tier name.


To establish a deeper understanding let’s walk through the process and commands required to create the user-provided service and applications on Pivotal Cloud Foundry.

Configure and Push Applications onto Pivotal Cloud Foundry
Before we can “cf push” the application, we need to create a user-provided service in the organization and space where we deploy our applications. In the example below, we use the Cloud Foundry CLI to create the user-provided service providing the required information in name/value format. Notice the application and tier name are configured, and we have created three different user-provided services to represent different tiers in our application.

cf cups app-dynamics-ST-web -p '{"account-name":"myacct","account-access-key":"key","host-name":"myacct.saas.appdynamics.com ","port":"80","tier-name":"web","application-name":"SpringTrader"}'

cf cups app-dynamics-ST-rest -p '{"account-name":"myacct","account-access-key":"key","host-name":"myacct.saas.appdynamics.com ","port":"80","tier-name":"rest","application-name":"SpringTrader"}'

cf cups app-dynamics-ST-asynch -p '{"account-name":"myacct","account-access-key":"key","host-name":"myacct.saas.appdynamics.com ","port":"80","tier-name":"asynch","application-name":"SpringTrader"}'

With our services defined, let’s deploy the Spring Trader application. Using the command line, issue the following commands:

## Create required managed services for deployment
cf create-service p-rabbitmq standard tradermessaging
cf create-service p-mysql 100mb-dev tradersql

## Deploying Rest component, binding services and restaging application
### Note the -b option to use the latest Java buildpack from github.com/cloudfoundry/java-buildpack
cf push -p dist/spring-nanotrader-services-1.0.1.BUILD-SNAPSHOT.war -b https://github.com/cloudfoundry/java-buildpack.git --no-start stfront
### Binds Services
cf bind-service stfront tradersql
cf bind-service stfront tradermessaging
cf bind-service stfront app-dynamics-ST-rest
### Specify which JVM version to use in the Java Buildpack
cf set-env stfront JBP_CONFIG_OPEN_JDK_JRE '[version: 1.7.0_+]'
### Specify which AppDynamics agent to use in the Java Buildpack
cf set-env stfront JBP_CONFIG_APP_DYNAMICS_AGENT '[version: 4.0.1_+]'
cf restage stfront.

## Deploying Web UI component, binding services and restaging application.
cf push -p dist/spring-nanotrader-web-1.0.1.BUILD-SNAPSHOT.war -b https://github.com/cloudfoundry/java-buildpack.git --no-start stweb
### Bind services
cf bind-service stweb app-dynamics-ST-web
cf set-env stweb JBP_CONFIG_OPEN_JDK_JRE '[version: 1.7.0_+]'
cf restage stweb

## Deploying the asynch service component, binding services and restaging application.
cf push -p dist/spring-nanotrader-asynch-services-1.0.1.BUILD-SNAPSHOT.war -b https://github.com/cloudfoundry/java-buildpack.git --no-start stback
### Bind services
cf bind-service stback stsql
cf bind-service stback tradermessaging
cf bind-service stback app-dynamics-ST-asynch
cf set-env stback JBP_CONFIG_OPEN_JDK_JRE '[version: 1.7.0_+]'
cf restage stback

As the “cf restage” command is executed the output will show which pieces are required to create the application and prepare it for the container. In the example below, you’ll see the AppDynamics agent is added to the container along with OpenJDK and the Tomcat server. If the AppDynamics agent is not included, verify the user-provider service is properly configured and its bound to the application.


Once the commands are complete you should see the applications deployed in Pivotal Cloud Foundry Apps Manager. You should also see the user-provided services, with an application bound to each service. A number of applications can be bound to the user-provided service, but in our example its one per service.



We’ve successfully deployed our applications and bound AppDynamics services to each application instance. Let’s review the AppDynamics dashboard to understand how our application maps to the AppDynamics logical model.

The AppDynamics Model and Dashboards
In the home dashboard below you’ll notice the Spring Trader application. This application is made up of three independent applications in Pivotal Cloud Foundry.


If we click into the Spring Trader application, we’ll see the app servers and you’ll notice how each application instance uses the tier name to represent different layers of the Spring Trader application. In our example we have the web, rest and asynch tiers. If you expand each tier you’ll see the node names, in this case node name is “0” for the first instance of the application. Node names are configurable, but I prefer to use the default node names as they align with the Pivotal Cloud Foundry application instance sequence number. As we scale different tiers to support new workloads, the new application instances will register with the AppDynamics controller, each with a sequential node name.


By supporting the logical model in Pivotal Cloud Foundry, we can use the application dashboard to review transactions across the different applications.


Troubleshooting AppDynamics Agents in Pivotal Cloud Foundry
During my initial installation, I had misconfigured the user-provided service which prevented the agent from registering with the AppDynamics controller. As a result, I needed to troubleshoot the agent configuration and review its logs. The good news is Pivotal Cloud Foundry makes this extremely easy. To access the agent logs, or any other buildpack information, just issue a “cf files stfront” command similar to the image below replacing “stfront” with your application name.


The logs are located on app/.java-buildpack/app_dynamics_agent/ver4.0.1.0/logs and each instance of your application will have its own log. At the top of the agent log you can find AppDynamic JVM arguments used to configure the agent. If you configure application security groups in Pivotal Cloud Foundry you’ll need to modify the policy to allow egress traffic for the controller port. In the example below, you can see all logs available for review and each file can be output to the screen by issuing the “cf files” command with a full path to the file.

“cf files stfront app/.java-buildpack/app_dynamics_agent/ ver4.0.1.0/logs/agent.2015_03_31__14_26_55_0.log”


As we’ve shown,  Pivotal Cloud Foundry makes the delivery and management of applications extremely easy and error free. Working with our partners to create an ecosystem of integrated services for customers delivers tremendous value, and provides an elegant transition to the delivery of cloud native applications while preserving and integrating with existing solutions.

The post Getting Started with Pivotal Cloud Foundry and AppDynamics appeared first on Application Performance Monitoring Blog | AppDynamics.

Read the original blog entry...

More Stories By AppDynamics Blog

In high-production environments where release cycles are measured in hours or minutes — not days or weeks — there's little room for mistakes and no room for confusion. Everyone has to understand what's happening, in real time, and have the means to do whatever is necessary to keep applications up and running optimally.

DevOps is a high-stakes world, but done well, it delivers the agility and performance to significantly impact business competitiveness.

CloudEXPO Stories
Moving to Azure is the path to digital transformation, but not every journey is effective. Organizations that start with a cohesive, well-planned migration strategy can avoid common mistakes and stay a step ahead of the competition. Learn from Atmosera CEO, Jon Thomsen about the opportunities and challenges found in three pivotal phases of the journey to the cloud: Evaluation and Architecting, Migration and Management, and Optimization & Innovation. In each phase, there are distinct insights that can give a company the edge and make sure cloud adoption is closely aligned to core business goals. Keeping these in mind will make your migration to the Azure simpler and more effective.
CloudEXPO has been the M&A capital for Cloud companies for more than a decade with memorable acquisition news stories which came out of CloudEXPO expo floor. DevOpsSUMMIT New York faculty member Greg Bledsoe shared his views on IBM's Red Hat acquisition live from NASDAQ floor. Acquisition news was announced during CloudEXPO New York which took place November 12-13, 2019 in New York City. Our Silicon Valley 2019 schedule will showcase 200 keynotes, sessions, general sessions, power panels, and hands on tutorials presented by 150 rockstar speakers in 10 hottest conference tracks of 2019:
Cloud is the motor for innovation and digital transformation. CIOs will run 25% of total application workloads in the cloud by the end of 2018, based on recent Morgan Stanley report. Having the right enterprise cloud strategy in place, often in a multi cloud environment, also helps companies become a more intelligent business. Companies that master this path have something in common: they create a culture of continuous innovation. In his presentation, Dilipkumar Khandelwal outlined the latest research and steps companies can take to make innovation a daily work habit by using enterprise cloud computing. He shared examples from companies that have benefited from enterprise cloud computing and took a look into the future of how the cloud helps companies become a more intelligent business.
Data center, on-premise, public-cloud, private-cloud, multi-cloud, hybrid-cloud, IoT, AI, edge, SaaS, PaaS... it's an availability, security, performance and integration nightmare even for the best of the best IT experts. Organizations realize the tremendous benefits of everything the digital transformation has to offer. Cloud adoption rates are increasing significantly, and IT budgets are morphing to follow suit. But distributing applications and infrastructure around increases risk, introduces complexity and challenges availability at every turn. To embrace DX and to come out on top, there are four underlying principles that should guide you. Understanding these four essentials along with their relevance and impact will elevate you to DX Hero status now. Jonathan will provide a high-level overview of these principles and how some of his organization's clients have embraced them w...
DevOps has long focused on reinventing the SDLC (e.g. with CI/CD, ARA, pipeline automation etc.), while reinvention of IT Ops has lagged. However, new approaches like Site Reliability Engineering, Observability, Containerization, Operations Analytics, and ML/AI are driving a resurgence of IT Ops. In this session our expert panel will focus on how these new ideas are [putting the Ops back in DevOps orbringing modern IT Ops to DevOps].