Quantcast
Channel: All Things Cloud
Viewing all 142 articles
Browse latest View live
↧

Write sample Java apps using the User Authentication Authorization (UAA) API on Cloud Foundry

February 2, 2016, 9:45 pm
$
0
0

Do you want to use UAA as an OAuth2 authorization server (eg SSO, token creation / verification)? 

Take a look at github.com/pivo...ity-sample-apps for basic examples of integrating with Pivotal SSO which is UAA with subdomain multi-tenancy, and comes free with PCF 1.5, or look at github.com/will...ervice-security and spring.io/blog/...-cloud-security for a more involved example of using straight UAA to secure microservices.

For PCF customers and interested in using Pivotal SSO and Spring Cloud Services to manage a secure microservice architecture, github.com/will...ran/freddys-bbq is the the microservice-security example and goes the extra mile and integrates with all those products.

Do you want use UAA APIs to dynamically create OAuth2 clients and manage user roles?

There aren't many examples in the OSS world for that, but we do some of that in both Pivotal SSO and Spring Cloud Services. There are API docs however: github.com/clou...cs/UAA-APIs.rst

THANK YOU Will Tran
↧
Search

13 Factor apps for .NET - Cloud Foundry on Azure

February 3, 2016, 5:32 am
$
0
0

Why bother with Cloud Foundry on Azure ? 
Quick Answer: To optimize for the cloud programming model and build apps that can scale agnostically across cloud platforms. Microsoft haas published 13 recommended patterns from MS for cloud development in BuildingCloudAppsMsAzure. Cloud Foundry through it platform contracts, partner tiles and programming model constraints enables the best way to develop, design and code cloud apps on Azure.

• Automate everything
   • Use scripts to maximize efficiency and minimize errors in repetitive processes. aka Use Cloud Foundry

• Source control
   • Set up branching structures in source control to facilitate a DevOps workflow.
   • Example: add scripts to source control.
   • Example: keep sensitive data out of source control.
   • Example: use Git in Visual Studio.

• Continuous integration and delivery
   • Automate build and deployment with each source control check-in.

• Web development best practices
   • Keep web tier stateless
   • Example: scaling and autoscaling in Cloud Foundry.
   • Avoid session state.
   • Use a Content Delivery Network (CDN).
   • Use an asynchronous programming model.
   • Example: async in ASP.NET MVC and Entity Framework.

• Single sign-on
   • Introduction to Azure Active Directory.
   • Example: create an ASP.NET app that uses Azure Active Directory.

• Data storage options
   • Types of data stores.
   • How to choose the right data store.
   • Example: Azure SQL Database.

• Data partitioning strategies
   • Partition data vertically, horizontally, or both to facilitate scaling a relational database.

• Unstructured blob storage
   • Store files in the cloud by using the Blob service.
   • Example: using blob storage

• Design to survive failures
   • Types of failures.
   • Failure scope.
   • Understanding SLAs.

• Monitoring and telemetry
   • Why you should both buy a telemetry app and write your own code to instrument your app.
   • Example: New Relic for Azure
   • Example: logging code in the Fix It app.
   • Example: built-in logging support in Cloud Foundry.
   • Example: built-in Telemetry for websites and systems in Cloud Foundry

• Transient fault handling
   • Use smart retry/back-off logic to mitigate the effect of transient failures.
   • Example retry/back-off in Entity Framework 6.

• Distributed caching
   • Improve scalability and reduce database transaction costs by using distributed caching.
   • Example: Using Gemfire in ASP.NET app

• Queue-centric work pattern
   • Enable high availability and improve scalability by loosely coupling web and worker tiers.
   • Example: Using RabbitMQ 
↧
↧

Backup and Restore Pivotal Cloud Foundry

February 27, 2016, 6:22 pm
$
0
0

Customers often ask us "What is the proper way to backup and restore Pivotal Cloud Foundry ?"

I want to go over all the options you have to successfully and expediently backup and restore Pivotal Cloud Foundry. The advice here is generally applicable to open source cloud foundry as well to a certain extent.

First a bit of a background. Pivotal Cloud Foundry is comprised of a number of tiles which roughly map to a BOSH release in open source. Each of these tiles need to backed up and restored individually. The OpsManager Tile is special in that it provides the inception VM and is responsible for deploying the BOSH Director. 

Manual Backup and Restore:
This is the recommendation from the product team itself. See 
Backup => https://docs.pivotal.io/pivotalcf/customizing/backup-restore/backup-pcf.html and Restore => https://docs.pivotal.io/pivotalcf/customizing/backup-restore/restore-pcf.html.  So what exactly happens during a backup and restore is explained by the pictures below.

Backup
Restore
Automated Backup and Restore: 
Manually backing up a foundation every night is not practical. Therefore the Pivotal Cloud Foundry Solutions team has an open source tool that automates the manual process for taking a backup and restoring it. This tool is called cfops => https://github.com/pivotalservices/cfops
Documentation on how to run backup/restore with cfops* can be found Here http://www.cfops.io/docs/ The basic process here is  Backup all Tiles and place the backup on a reliable file system. During a restore, restore each tile, apply changes and rinse and repeat for all tiles. 

cfops as of today does not support backing up or restoring data service tiles like MySQL, RabbitMQ etc., The tile settings are restored; however the data is not imported. So you will need an independent backup/restore strategy for data stores. This is where a data backup a tool like Shield => https://github.com/starkandwayne/shield from Stark and Wayne looks attractive. The project is in its infancy. Another option for backing up  the data services is leveraging Concourse.

Concourse can express entire pipelines, integrating with arbitrary resources, or it can be used to execute one-off tasks, either locally or in another CI system. Concourse encourages practices that keep your project loosely coupled to the details of your continuous integration infrastructure.

If for some reason your BOSH Director disappears or the Director VM gets nuked you can bring it back using the procedure described here : https://blog.pivotal.io/pivotal-cloud-foundry/features/restoring-pivotal-cloud-foundry-after-disaster

Please note that the Backup and Restore process can be done with zero downtime if done right particularly because of the canary support provided by BOSH.

Canary instances are first instances updated within an instance group. Any update error in a canary instance causes the deployment to stop. Since only canaries are affected before an update stops, problem jobs and packages are prevented from taking over all instances.



At some point Pivotal Cloud Foundry will provide an official tool and automation strategy for backup & restore. Till then we can leverage cfops backup and restore function- automated with cron or in a CI pipeline with (Wercker/Concourse/Jenkins) to ensure that our sysadmins can sleep safe and sound.






* Please note cfops is not officially supported by the Pivotal Product Team; however we as Pivotal make our best effort to support this tool and keep it functioning across product upgrades.
↧

Deigo BBS, ETCD and Consul - 3 is a crowd

March 3, 2016, 7:00 am
$
0
0
PCF 1.6 has now been completely redesigned on the Diego runtime. In case you are wondering all this all works now checkout the picture below -



Diego internally uses a couple of registries to store internal state primarily Consul for NAT-less service registry and ETCD as an ephemeral data store for the Diego bulletin board service. Once there are corruption issues due to connectivity or disks, these distributed registries  start arguing. They cannot reconcile the state of the world with the CloudController due to quorum or issues with leader election or distributed key lockout. Basically the instances need to get the same key.  You can specify the key in the newer versions, but there is no enforcement of state in the case of corruption.

I am sure there is a proper technical reason why these distributed K,V stores behave they way they do in these situations; however my intent here is to teach you how to get out of this situation if somehow you end up here.

So in situations where Consul and Etcd and Diego Brain BBS jobs act like errant brothers and fight with another to reconstitute the state of the world from the Cloud Controller, leverage the following recipe to keep sanity in the house.

1. Restart all the VMs of the Consul, ETCD and Diego BBS nodes in that order.

2. Wipe out member DB files i.e. nuke the data dir. on the ETCD VMs. monit restart all services on the ETCD nodes.To delete the contents of the etcd data store see:
  1. Run bosh vms to identify the etcd nodes in your deployment.
  2. Run bosh ssh to open a secure shell into each etcd node.
  3. Run monit stop etcd on each etcd node.
  4. Delete or move the etcd storage directory, /var/vcap/store, on each etcd node.
  5. Run monit start etcd on each etcd node.
3. Reduce the number of Consul instances to 1 and  deploy the BOSH release again. If this fails, follow the same process for the other errant jobs. In the end you may end up with just one instance of these 3 jobs. Once you have a healthy deployment bump up the # of Job instances in the Resources page of the OpsManager.

4. Etcd may sometimes experience orphaned processes that leads to the Diego BBS job failing. This can be remedied by killall etcd on the Diego BBS VMs and subsequent redeployment.

5.  Nuke and Pave ... Take backup of your PCF deployment with cfops and do a brand new deployment followed by a restore.
↧

Supplying an external configuration to the Java Buildpack

March 3, 2016, 9:19 pm
$
0
0
I wanted to highlight a very important commit recently made to the Java Buildpack i.e.You can now configure the Java Buildpack with a custom server.xml via a repository.
Extension point for supplying an external Tomcat configuration
This allows a CF Platform Operator to provide a vetted server.xml that contains custom Tomcat configuration to the Java Buildpack without forking the buildpack. This feature is OFF by default. In order to enable it set the following env variable in the manifest:

Example in a manifest.yml
env: JBP_CONFIG_TOMCAT: "{ tomcat: { external_configuration_enabled: true }, external_configuration: { repository_root: \"http://repository...\" } }"

The artifacts that the repository provides must be in TAR format and must follow the Tomcat archive structure:
tomcat
|__conf
   |__context.xml
   |__server.xml
   |__web.xml
   |...
You can expect this feature to show up in the next release of the JavaBuildpack and its downstream clones like TomEE.
↧
↧

State of JavaEE

March 3, 2016, 6:20 am
$
0
0
There is a lot of chatter on the internet about Java EE being dead. As someone who spent a lot of time implementing some of the core specs like CDI and also helping customers adopt JavaEE I was interested in determining if this is true.

Unfortunately the anecdotal evidence points to JavaEE dying slowly. This is the evidence now points towards JavaEE being dead:

1. Many prominent Java EE evangelists - Folks who in some cases are friends and I admire deeply have left their respective Java EE shepherd companies. Reza Rahman from Oracle, Kenny Bastani from Oracle and Arun Gupta from Redhat to name just a few ...

2. Oracle, Redhat and IBM - the three most prominent supporters of JavaEE are now spending their money and developers innovating elsewhere. Oracle cloud,OpenShift and Bluemix respectively.

3. The advent of microservices has rendered the monolithic app-server dead. Gone are the days that you have the pack the kitchen sink in your app-server runtime. Nowadays developers ONLY want to use the runtime they want - case in point the rise of the micro-servers - Spring Boot, Dropwizard, Vert.x, Ratpack etc. The next evolution is the disappearance of these micro-servers and the move to serverless computing i.e. the developers are coding chained reactive lambda functions in the cloud. Not sure how I feel about that....

4. The pace of JavaEE specification implementation by vendors and the evolution of the specification itself has slowed to a glacial pace. Where is Java EE8 or Java EE9 ? Where is the Java EE equivalent of all the resiliency patterns like Circuit Breaker, Bulkhead and microservice patterns like service discovery, logging everything to stdout etc. CDI is the only major hope left for JavaEE. They need to rebase the entire platform on CDI and start innovating like crazy. Unfortunately this cannot be done by committee.

There is still a LOT of code running on application servers. WebSphere, WebLogic and JBOSS were the goto runtime and middleware OS in the 90s and early 2Ks.  I care about these apps and if you do too start decomposing them and running them on lightweight runtimes like Spring Boot, Jetty whatever blows your horn. Then move these services to the cloud using Docker or Buildpacks.  If the apps don't add any business value then move them to lighter runtimes within the JavaEE stack i.e. move to WebSphere Liberty or JBOSS Wildfly.

This should serve as a cautionary tale. I am sure a lot of people with disagree with what I have written. But hey this my opinion you should form one too ....

Au Revoir

Update: There is a new organization called Java EE Gaurdians https://dzone.com/articles/who-are-the-java-ee-guardians-and-why-you-should-c that seems to be JavaEEs best shot at survival.

↧

Debugging Node.js high CPU, crash and memory issues in Cloud Foundry - part 1

April 9, 2016, 6:49 pm
$
0
0
These are the scenarios that keep a Devops engineer awake in the night - an instance of the node.js app is running at 100% CPU in Cloud Foundry with NO logging or resiliency protection like circuit breakers. This is the third occurrence of the problem in the last month. Management is dragging you into these long drawn day long meetings where each side blames each other - the app is restarted - the problem goes away and the cycle repeats. 

With apps increasingly being wrapped in russian doll layers of abstraction  [baremetal => VM => Container => Node process] getting to the root cause has become increasingly difficult.

So if you are a Java guy that has no experience in debugging a production node.js app. After drinking an appropriate amount of coffee and fruity alcoholic drinks you have landed on http://techblog.netflix.com/2015/12/debugging-nodejs-in-production.html

The recommendations from Yunong Xiao in the presentation essentially boils down to:
1. Using node-restify as a REST framework in the node app to log and observe app performance
2. Use Linux Perf Events to statistically sample stack traces  to construct CPU flame-graphs. This technique can reliably find the proverbial needle in the haystack.
3. Take Coredumps to dump the app state for post-mortem debugging with the mdb debugger. Unfortunately the mdb debugger can only run on Solaris- therefore you have to transfer the coredump to a debug solaris VM instance [1] [2]. 

Unfortunately both options 1 and 2 are not possible. 1 because the app-dev team will need to get involved and they don't look upon kindly on a devops guy advising a REST framework. 2 because CF does not bake perf events into the OS stemcell. Yikes!!! Looks like good old gcore is the only way to go  ... 

ok so with the introduction of Diego, finding your way into the container should be as easy as doing a cf-ssh and then issuing the gcore command rite ? - NOPE Wrong - Once ssh'ed into the container there is no way to elevate the privilege and attach gdb to your node.js process. You will need to find another way to elevate privilege and take a core dump.

This other way is using BOSH and Veritas. The gist of the method is that you bosh ssh into the correct Diego cell by first examining the app metadata. Thereafter on the Diego cell install veritas the Garden explorer tool. Use Veritas to map from the app instance to the container instance. Thereafter ./wsh into the garden container. You can now elevate your privilege with a sudo su - and then issue a  gdb, gcore of the node.js server process.

Once the dump has been generated sftp it to a debug solaris instance and run diagnostics with mdb commands like jsstack etc ... see this video from Joyent that explains how to walk the dump.

Part 2 of the blog goes into the gory detail of discovery and  generation of the core dump.
↧

Debugging Node.js high CPU, crash and memory issues in Cloud Foundry - part 2

April 9, 2016, 7:26 pm
$
0
0
This blog post goes into step-by step run through of how to take a core dump of a specific application instance in cloud foundry. Please note you WILL need access to the PCF OpsManager. Typically the ability to target the BOSH director to your CF deployment is only possessed by sysadmins. So if you are reading this as a developer of Node.js apps in PCF, your best shot is to build the diagnostics into the app like so

  1. Use the restify observable REST framework
  2. Modify the node start command for your app like so node --abort_on_uncaught_exception --expose-gc
  3. Install heapdump with npm install heapdump and require it in server.js. Use chrome dev tools to analyze the heapdumps.
  4. Develop Debugging Techniques as explained here. 
Step 0: App Listing
cf app word-finder
     state     since                    cpu    memory         disk           details
#0   running   2016-04-09 02:13:26 AM   0.0%   107.4M of 1G   164.8M of 1G
#1   running   2016-04-09 10:31:47 PM   0.0%   96.2M of 1G    44.6M of 1G
#2   running   2016-04-09 10:31:47 PM   0.0%   95.4M of 1G    44.6M of 1G

Step 1: Determine app GUID
cf app word-finder --guid
5e46745d-9849-42c3-9549-be9ba5fe1e57

Step 2: Determine Host and Port of the app instance in question
Lets assume that it is instance #2 that is suffering the HIGH CPU.

export CF_TRACE=true
cf curl /v2/apps/5e46745d-9849-42c3-9549-be9ba5fe1e57/stats

  "2": {
      "state": "RUNNING",
      "stats": {
         "name": "word-finder",
         "uris": [
            "word-finder.cfapps.paas.pivotal.io"
         ],
         "host": "10.65.187.46",
         "port": 60540,
         "uptime": 560,
         "mem_quota": 1073741824,
         "disk_quota": 1073741824,
         "fds_quota": 16384,
         "usage": {
            "time": "2016-04-10T02:41:08.873469312Z",
            "cpu": 0.00019609362320671737,
            "mem": 103034880,
            "disk": 46796800
         }
      }
Step 3: bosh ssh into the Diego Cell VM 

ssh into the OpsManager VM and then target the BOSH director to the correct deployment

bosh deployment /var/tempest/workspaces/default/deployments/cf-cdcc8064df9477b983f3.yml

Issue a bosh vms command to determine the name of the Diego cell that houses the app instance container. Note the host-name should match from step-1.

ubuntu@pivotal-ops-manager:~$ bosh vms cf-cdcc8064df9477b983f3 --details
Acting as user 'director' on deployment 'cf-cdcc8064df9477b983f3' on 'p-bosh-1667ec8b8a5e1edbe71b'


| Job/index| State   | Resource Pool | IPs | CID | Agent ID | Resurrection |
|diego_cell-partition-e8ca738002f1f150c602/0 | running | diego_cell-partition-e8ca738002f1f150c602 | 10.65.187.46 | vm-b2f2b447-043b-41ec-bad8-9fd950e9f9d7 | f1ec0fc6-9942-4c18-a55e-b507014684e3 | active       |

ubuntu@pivotal-ops-manager:~$ bosh ssh diego_cell-partition-e8ca738002f1f150c602/0

Step 4: Locate the Garden container that contains the app instance # 2.

First start in the right directory
cd var/vcap/data

Install Veritas
wget https://github.com/pivotal-cf-experimental/veritas/releases/download/latest/veritas
chmod a+x veritas

Configure Veritas
chmod a+x veritas

bosh_4auu9hoye@f1ec0fc6-9942-4c18-a55e-b507014684e3:/var/vcap/data$ ./veritas autodetect
export VITALS_ADDRS=garden:0.0.0.0:17013,rep:0.0.0.0:17008
export GARDEN_ADDR=/var/vcap/data/garden/garden.sock

export GARDEN_NETWORK=unix

Derive a garden container mapping of the app instances. Now find the garden container based on the port exposed for that instance from step #2.

5e46745d-9849-42c3-9549-be9ba5fe1e57-773eaa66-667c-40b2-863e-51c3cd9570f8-bf91aa00-fabb-45a9-4311-1e326ad5998e - active @ /var/vcap/data/garden/depot/f8gqc8vnqfl
  Memory: 98.797 MB
  Disk: Total:802.640 MB 0 Inodes, Exclusive:44.629 MB 0 Inodes
  10.254.0.25=>5e46745d-9849-42c3-9549-be9ba5fe1e57-773eaa66-667c-40b2-863e-51c3cd9570f8-bf91aa00-fabb-45a9-4311-1e326ad5998e: 60542:8080,60543:2222
  Running: 2 processes
  Properties:
    executor:owner: executor

5e46745d-9849-42c3-9549-be9ba5fe1e57-773eaa66-667c-40b2-863e-51c3cd9570f8-fc296ea9-1e02-4f97-6c95-553388a3370c - active @ /var/vcap/data/garden/depot/f8gqc8vnqfm
  Memory: 98.297 MB
  Disk: Total:802.640 MB 0 Inodes, Exclusive:44.629 MB 0 Inodes
  10.254.0.29=>5e46745d-9849-42c3-9549-be9ba5fe1e57-773eaa66-667c-40b2-863e-51c3cd9570f8-fc296ea9-1e02-4f97-6c95-553388a3370c: 60540:8080,60541:2222
  Running: 2 processes
  Properties:
    executor:owner: executor

5e46745d-9849-42c3-9549-be9ba5fe1e57-773eaa66-667c-40b2-863e-51c3cd9570f8-8ce28a9f-a9ef-4aff-73a6-4e095822e0db - active @ /var/vcap/data/garden/depot/f8gqc8vnqbr
  Memory: 107.430 MB
  Disk: Total:922.765 MB 0 Inodes, Exclusive:164.754 MB 0 Inodes
  10.254.0.21=>5e46745d-9849-42c3-9549-be9ba5fe1e57-773eaa66-667c-40b2-863e-51c3cd9570f8-8ce28a9f-a9ef-4aff-73a6-4e095822e0db: 60538:8080,60539:2222
  Running: 2 processes
  Properties:
    executor:owner: executor

At this point you have nailed down the path to your specific garden container i.e. /var/vcap/data/garden/depot/f8gqc8vnqfm

Step 5: wsh into the container and issue the gcore command by attaching to the node.js process

Determine the PID of the node.js app process
root@f1ec0fc6-9942-4c18-a55e-b507014684e3:~# cd /var/vcap/data/garden/depot/f8gqc8vnqfm

garden/depot/f8gqc8vnqfm$ sudo su -

root@f1ec0fc6-9942-4c18-a55e-b507014684e3:/var/vcap/data/garden/depot/f8gqc8vnqfm# ./bin/wsh

# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 02:31 ?        00:00:00 initd -dropCapabilities=false -title="wshd: f8gqc8vnqfm"
vcap        14     1  0 02:31 ?        00:00:00 node server.js
vcap        17     1  0 02:31 ?        00:00:00 /tmp/lifecycle/diego-sshd -address=0.0.0.0:2222 -hostKey=-----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQCxtuDXcInp3mD2x9s8oI6c6Ca8wgEYvPoFwichBYOklyxJHMSy
root       330     1  0 03:07 pts/0    00:00:00 /bin/sh
root       332   330  0 03:08 pts/0    00:00:00 ps -ef

Attach a debugger to the process
# gdb --pid=14
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Attaching to process 14
Reading symbols from /home/vcap/app/.heroku/node/bin/node...done.
Reading symbols from /lib/x86_64-linux-gnu/libssl.so.1.0.0...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libssl.so.1.0.0
Reading symbols from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/librt.so.1
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /usr/lib/x86_64-linux-gnu/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/x86_64-linux-gnu/libstdc++.so.6
Reading symbols from /lib/x86_64-linux-gnu/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libm.so.6
Reading symbols from /lib/x86_64-linux-gnu/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libgcc_s.so.1
Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
[New LWP 25]
[New LWP 24]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007f8baa3c4859 in syscall () from /lib/x86_64-linux-gnu/libc.so.6


Generate a core dump
(gdb) gcore
warning: target file /proc/14/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7fff6e7d9000.
Saved corefile core.14
(gdb) exit
Undefined command: "exit".  Try "help".
(gdb) quit
A debugging session is active.

Inferior 1 [process 14] will be detached.

Quit anyway? (y or n) y
Detaching from program: /home/vcap/app/.heroku/node/bin/node, process 14

# ls
core.14  firstboot.sh
# ls -al
total 114044
drwx------  2 root root      4096 Apr 10 03:08 .
drwxr-xr-x 31 root root      4096 Apr 10 03:08 ..
-rw-r--r--  1 root root      3106 Feb 20  2014 .bashrc
-rw-r--r--  1 root root       140 Feb 20  2014 .profile
-rw-r--r--  1 root root 116764456 Apr 10 03:08 core.14
-rwxr-xr-x  1 root root       213 Feb 22 19:32 firstboot.sh
#

Step 6 - Transfer core-dump to a VM that has the mdb debugger installed. 
sch ... 
sftp ... 

Step 7 Load the Core dump on the Solaris VM
# mdb ./node-v4.2.2-linux/node-v4.2.2-linux-x64/bin/node ./core.14
> ::load ./mdb_v8_amd64.so
mdb_v8 version: 1.1.1 (release, from 28cedf2)
V8 version: 143.156.132.195
Autoconfigured V8 support from target
C++ symbol demangling enabled

Step 8 Issue mdb commands for introspecting the dump for stacktraces and data
❖ ::help <cmd>
❖ ::jsstack
❖ ::jsprint
❖ ::jssource
❖ ::jsconstructor
❖ ::findjsobjects
❖ ::jsfunctions

Step 9: Figure out the exact stack frame executing on the heap when the crash occurred or High CPU situation occurred.

Happy hunting ... 
↧
Search

Create WebSphere Liberty Server Offline Buildpack

May 1, 2016, 5:45 pm
$
0
0
A number times I get queries on how to create an offline version of the WebSphere Liberty Profile Buildpack. Here are the high level steps with some color added, where the instructions are not clear for creating an Offline version of the liberty buildpack. 

The instructions below assume access to the internet. Once the buildpack is created then you can push applications to it. The compile process of the buildpack will find all the dependencies within the buildpack.

The steps below should be automated in a CI pipeline. For an example of a CI pipeline that generates the liberty offline buildpack head over to travis.

## Instructions Loosely Followed:
If you have customization to WebSphere  and JRE binaries.
- [Forking The Buildpack](https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack/blob/master/docs/forking.md)

If you have NO customization to WebSphere and JRE binaries.
- [How to install the Buildpack into your Cloud Foundry release](https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack/blob/master/docs/installation.md)

## Download WAS and JRE Binaries
https://developer.ibm.com/assets/wasdev/#asset/runtimes-wlp-runtime wlp runtime jar and others needed needed to setup repository see below ...

https://www-01.ibm.com/marketing/iwm/iwm/web/preLogin.do?source=swg-sdk8&S_PKG=amd64_8.0.3.0&S_TACT=105AGX05&S_CMP=JDK
- IBM 64-bit SDK for Linux on AMD64/EM64T architecture, Java Technology Edition
  Version  8.0.3.0
- Simple unzip with license (InstallAnywhere root not required)
  ibm-java-jre-8.0-3.0-x86_64-archive.bin  (111 MB)


~/Downloads/liberty8559❯
-rw-r--r--@   1 kelapr  720748206  147038277 Apr 30 00:06 ibm-java-x86_64-sdk-8.0-3.0.bin
-rw-r--r--@   1 kelapr  720748206   62753431 Apr 30 00:00 wlp-runtime-8.5.5.9.jar

## Structure the binaries into a repository and create the appropriate index.yml files 

https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack/blob/master/docs/util-repositories.md#setting-up-your-web-server

Copy license files from
https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/downloads/wlp/8.5.5.9/lafiles/runtime/en.html
https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/downloads/jre/index.yml

Push these binaries to the cloud using the static file buildpack
Dir. Structure before push...

~/Downloads/liberty8559❯ tree -f .
.
├── ./Staticfile
└── ./buildpack
    ├── ./buildpack/jre
    │   ├── ./buildpack/jre/ibm-java-jre-8.0-3.0-x86_64-archive-License.html
    │   ├── ./buildpack/jre/ibm-java-jre-8.0-3.0-x86_64-archive.bin
    │   └── ./buildpack/jre/index.yml
    └── ./buildpack/wlp
        ├── ./buildpack/wlp/index.yml
        ├── ./buildpack/wlp/wlp-developers-runtime-8.5.5.9-License.html
        ├── ./buildpack/wlp/wlp-javaee7-8.5.5.9.zip
        ├── ./buildpack/wlp/wlp-kernel-8.5.5.9.zip
        ├── ./buildpack/wlp/wlp-runtime-8.5.5.9.jar
        └── ./buildpack/wlp/wlp-webProfile7-8.5.5.9.zip



Modify the index.yml files after pushing for the first time and then repush

~/Downloads/liberty8559❯ cf push liberty-repo
Updating app liberty-repo in org pivot-rkelapure / space development as rkelapure@pivotal.io...
OK

See http://liberty-repo.cfapps.pez.pivotal.io/ for a functioning repository and index.yml files for a minimal repo of customized liberty and jre.

Another way of creating a repository is to run the dependency-builder; however configuring and running the dependency builder takes time and is error prone. Your best chance of success is to handcraft the repository based on your custom websphere binaries. If you have NO access to the internet when running the package rake task THEN you will need to setup a repository with not only WAS and JRE binaries but also all the third party binaries that are used like dynatrace, appdynamics etc.,

Modify the code in ibm-websphere-liberty-buildpack/config/ibmjdk.yml to point to the pushed JRE.
Modify the code in ibm-websphere-liberty-buildpack/config/liberty.yml to point to pushed Liberty.

Create the offline buildpack
https://github.com/cloudfoundry/ibm-websphere-liberty-buildpack/blob/master/docs/installation.md
Create a licenses.yml based on the license files uploaded above

It is critical that the repository index.yml (specifically the wlp/index.yml)  are setup right otherwise you will see errors like these...

rake aborted!
undefined method `gsub' for nil:NilClass
/Users/kelapr/git/ibm-websphere-liberty-buildpack/resources/download_buildpack_cache.rb:155:in `filename'
/Users/kelapr/git/ibm-websphere-liberty-buildpack/resources/download_buildpack_cache.rb:64:in `block in download_cache'
/Users/kelapr/git/ibm-websphere-liberty-buildpack/resources/download_buildpack_cache.rb:47:in `each'
/Users/kelapr/git/ibm-websphere-liberty-buildpack/resources/download_buildpack_cache.rb:47:in `download_cache'
/Users/kelapr/git/ibm-websphere-liberty-buildpack/Rakefile:95:in `block (2 levels) in <top (required)>'
/Users/kelapr/git/ibm-websphere-liberty-buildpack/Rakefile:78:in `block in <top (required)>'
/Users/kelapr/.rvm/gems/ruby-1.9.3-p545/bin/ruby_executable_hooks:15:in `eval'
/Users/kelapr/.rvm/gems/ruby-1.9.3-p545/bin/ruby_executable_hooks:15:in `<main>'


## Generate the Buildpack

kelapr @ usxxkelaprm2 in ~/git/ibm-websphere-liberty-buildpack on git:master x [18:31:11]
$ bundle exec rake 'package[,*,]'

This will generate the offline IBM WebSphere Buildpack one dir. above
ibm-websphere-liberty-buildpack.zip

You can confirm the output location from the following line
/Users/kelapr/git/ibm-websphere-liberty-buildpack.zip as a buildpack zip output file

Once the buildpack is created. you will find all the cached dependencies inside

$ unzip -vl ibm-websphere-liberty-buildpack.zip

Archive:  ibm-websphere-liberty-buildpack.zip
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
       0  Stored        0   0%  05-01-16 18:26  00000000  admin_cache/
31318727  Defl:N 30838619   2%  05-01-16 18:24  7d5deee0  admin_cache/http%3A%2F%2Fdownloads.dynatracesaas.com%2F6.3%2Fdynatrace-agent-unix.jar.cached
      82  Defl:N       76   7%  05-01-16 18:24  edd887d4  admin_cache/http%3A%2F%2Fdownloads.dynatracesaas.com%2Fcloudfoundry%2Fbuildpack%2Fjava%2Findex.yml.cached
   71744  Defl:N    20247  72%  05-01-16 18:24  e514cbb9  admin_cache/http%3A%2F%2Fliberty-repo.cfapps.pez.pivotal.io%2Fbuildpack%2Fjre%2Fibm-java-jre-8.0-3.0-x86_64-archive-License.html.cached
115512196  Defl:N 114652626   1%  05-01-16 18:25  7b5cfed8  admin_cache/http%3A%2F%2Fliberty-repo.cfapps.pez.pivotal.io%2Fbuildpack%2Fjre%2Fibm-java-jre-8.0-3.0-x86_64-archive.bin.cached
     234  Defl:N      124  47%  05-01-16 18:24  f5c67578  admin_cache/http%3A%2F%2Fliberty-repo.cfapps.pez.pivotal.io%2Fbuildpack%2Fjre%2Findex.yml.cached
     596  Defl:N      171  71%  05-01-16 18:25  f94f0939  admin_cache/http%3A%2F%2Fliberty-repo.cfapps.pez.pivotal.io%2Fbuildpack%2Fwlp%2Findex.yml.cached
   60989  Defl:N    18625  70%  05-01-16 18:25  44573b38  admin_cache/http%3A%2F%2Fliberty-repo.cfapps.pez.pivotal.io%2Fbuildpack%2Fwlp%2Fwlp-developers-runtime-8.5.5.9-License.html.cached
67959662  Defl:N 67748071   0%  05-01-16 18:26  588faaec  admin_cache/http%3A%2F%2Fliberty-repo.cfapps.pez.pivotal.io%2Fbuildpack%2Fwlp%2Fwlp-webProfile7-8.5.5.9.zip.cached
    1487  Defl:N      183  88%  05-01-16 18:25  f74bed4e  admin_cache/https%3A%2F%2Fdl.zeroturnaround.com%2Fjrebel%2Findex.yml.cached
27633836  Defl:N 25152183   9%  05-01-16 18:25  04291789  admin_cache/https%3A%2F%2Fdl.zeroturnaround.com%2Fjrebel%2Freleases%2Fjrebel-6.4.3-nosetup.zip.cached
11656197  Defl:N 11640688   0%  05-01-16 18:24  a9417282  admin_cache/https%3A%2F%2Fdownload.run.pivotal.io%2Fapp-dynamics%2Fapp-dynamics-4.1.8_5.zip.cached

....

## Update PCF with Buildpack and push application with custom buildpack

# kelapr @ usxxkelaprm2 in ~/git [19:11:47]
$ cf create-buildpack  rliberty ./ibm-websphere-liberty-buildpack.zip 10 --enable

cf push spring-music -p build/libs/spring-music.war -b rliberty
↧
↧

Structuring orgs spaces in Cloud Foundry

May 5, 2016, 5:29 am
$
0
0

with inputs from various Pivotal Experts (Joe Fitzgerald, Stuart Radnidge)... 


Let’s firstly look at orgs and spaces. An organization, or an org, is a set of users grouped together for management purposes, and all members of an org share the same resource quota plan, services availability, and their custom domain. In an nutshell, organizations allow you to create a multi-tenant environment within your pivotal cloud foundry deployment.
​
Organizations can be defined any way that you like. Typically, they’re defined around things like line of businesses, or particular projects, or a specific division, or an initiative. There’s no sort of right way to do it. There’s the way that suits your organization, is really the way to do it. You don’t want to overdo the orgs, but orgs give you a level of abstraction that enables you to define who can do what in a particular environment.
​
Associated with these orgs are quota plans, and a quota will apply to all the activities within their particular organization, and in particular they provide limits and tracking around memory and disk use. Memory that is used by application instances; the services the consume, so how many services you can allocate to applications within that environment; and the number of routes, or ‘roots’, depending on where you come from, to applications that are allowed to be configured. These are custom or multiple domains that can be configured so you can control limits on all of those.
​
Within each organization, you can have multiple spaces. Each org will have at least one space, you have to have one, and every application and service is scoped to a space. Spaces are a very important additional level of abstraction for organizing applications and services. A space gives you access to a shared location for application development, deployment, and maintenance, and users will have specific space-related roles.
​
What do we normally organize our spaces into? The kind of canonical version is really having a development space, a test space, a staging space, and a production space. That’s one example. It’s not the only example, but it shows you how you can move an application through different spaces based upon your development pipeline, and have different roles and responsibilities allocated to that space, and different things happening in those particular spaces.

So our recommendation in  a nutshell is – Create an org for a business unit or line of business and then one space per logical environment like dev, test and performance. Start simple and then customize as dictated by requirements.  Org= sensible business unit – a space per environment.

Alternate Approach:All the people with access to an org get read access to everything in that org, which means service credentials for every app in the org,  if you map an org to a business unit, and have multiple apps. To prevent this kind of credential and access leakage across apps in an org, another way to structure apps is one org per app and a space per environment. If the inventory and chargeback model is around apps then it is easier to map orgs to apps for that too.

References
- Insight into setting quotas 
- Monitoring Application Instance Usage in PCF
- http://apidocs.cloudfoundry.org/230/organization_quota_definitions/creating_a_organization_quota_definition.html
 -http://apidocs.cloudfoundry.org/230/space_quota_definitions/creating_a_space_quota_definition.html
- https://docs.cloudfoundry.org/concepts/roles.html
↧

USEFUL CLOUD FOUNDRY BOSH Commands

May 5, 2016, 8:15 am
↧

Migrating JavaEE Apps To the Cloud

May 7, 2016, 11:52 am
$
0
0

Migrating JavaEE Applications To the Cloud

Java EE began with less than 10 individual specifications, but it has grown over time through subsequent updates and releases to encompass 34. Compared to microservices-based architectures, Java EE and its included specifications were originally designed for a different development and deployment model. Only one monolithic server runtime or cluster hosted many different applications packaged according to standards. Such a model runs opposite to the goal of microservices. The latest versions of Java EE added a ton of developer productivity to the platform alongside a streamlined package. [Modern JavaEE Design Patterns]
There are a lot of technologies from the Java EE specification that barely offer any advantages to microservices-based architectures, such as the Java Connector Architecture or the Batch Processing API. When building microservices architectures on top of Java EE, look at the asynchronous features and use the best available parts.
The document below details which Java EE specifications are a proper fit for implementing cloud native apps. Apps that leverage the JavaEE Web Profile make the best candidates to movet to the cloud. Please see the table below for a detailed treatement of Java EE spec. suitability in the cloud.

Deployment of Java EE Apps To Cloud Foundry

The restrictions imposed by the Cloud Foundry platform allow the platform to scale and provide qualities of service like app lifecycle management, dynamic routing, health management, monitoring, recovery, log aggregation and infrastructure orchestration. Cloud Foundry as a platform optimizes for stateless web apps with light footprint. Some of the recent features ofCloud Foundry like TCP Routing, Deigo container runtime and Docker support have reduced the constraints of the apps running on the cloud.
Cloud Foundry leverages buildpacks to create immutable app artifactions called droplets. A droplet represents a fundamental unit of scaling and immutable deployment in Cloud Foundry. Java apps in CF can be staged and run with the Java Buildpack, TomEE Buildpack, JBOSS Buildpack and Liberty Buildpack.
The capabilities of these buildpacks as they relate to running JavaEE apps are as follows:

Java Buildpack

Provisions a plain vanilla Tomcat servlet contatiner. This buildpack is ideal for spring apps, fat jar apps or apps that come with batteries included. JBP auto-configures data-source beans in the Spring Application context to connect to the appropriate services in the cloud.

WebSphere Liberty Buildpack

Buildpack uses IBM JRE 8 and enables Java EE 7 Web Profile features for WAR and EAR applications. Liberty Buildpack can be easily configured to switch to JavaEE6 or JRE7 using configuration override environment variables. This is the most natural target for moving apps from WebSphere Application Server Network Deployment or Websphere Application Sever Base apps. The following list of Liberty features will be enabled in the default configuration: beanValidation-1.1, cdi-1.2, ejbLite-3.2, el-3.0, jaxrs-2.0, jdbc-4.1, jndi-1.0, jpa-2.1, jsf-2.2, jsonp-1.0, jsp-2.3, managedBeans-1.0, servlet-3.1, websocket-1.1. The Liberty Buildpack accepts .ear. .war. .jar files and full server packages. [Upcoming Liberty buildpack changes]. The Liberty buildpack auto-configures the server based on managed services bound to the application.

TomEE Buildpack

The TomEE buildpack is the smallest delta on top of the Java Buildpack to support the Java EE specification. Apache TomEE is an all-Apache Java EE 6 Web Profile certified stack. Apache TomEE is assembled from a vanilla Apache Tomcat zip file. TomEE starts with Apache Tomcat, adds jars and zips up the rest to provide the Apache TomEE Web Profile i.e. Servlets, JSP, JSF, JTA, JPA, CDI, Bean Validation and EJB Lite .

JBOSS Buildpack

The JBOSS Buildpack provisions full and web profile implementations of Java EE. The buildpack only stages war files and has no support for ear files. JBOSS Buildpack function is currently being enhanced to autogenerate the standalone.xml configuration based on bound services.

Java EE Web Profile

SpecificationVersionsSuitabilityCloud Nativity
Servlet3.0, 3.1YesNon-blocking I/O, upgrade to WebSocket, security. The servlet specification also allows the use of asynchronous request processing. The parts that need to be implemented are thread pools(using the ExecutorService), AsyncContext, the runnable instanceof work, and a Filter to mark the complete processing chain asynchronous.
JSP, EL, JSTL, JSF2.2YesAlthough JSF 2.2 is a point release it contains a number of features important to the community.In general there are few issues using HTML 5 with JSF. HTML 5 features such as JavaScript, WebSocket, local storage, canvas and web workers can easily be used with JSF. The only identified issue thus far had been using newer HTML 5 markup with JSF components since JSF components do not recognize these markup elements out of the box. The solution in JSF 2.2 is to allow for freely mixing and matching HTML 5 markup with JSF via pass-through elements and attributes.The older and redundant managed bean model is now being deprecated in favor of the CDI programming model. This is part of the overall platform alignment with CDI. As part of this alignment the very useful view scope previously limited to JSF managed beans is now available to CDI beans.The flow scope is an extremely useful addition to JSF. It allows for beans that automatically live and die within a given boundary in the application (e.g. account management section, catalog section, search section).
JAX-RS1.1, 2.0Yes, JAX-RS is the primary building block of the Java EE microservice stackThe primary goal of JAX-RS 2 is improving portability by standardizing common non-standard features in JAX-RS implementations like Jersey, RESTEasy and Axis. One of the most significant changes is adding a client-side REST API. The Fluent API uses the builder pattern and is at the same time very simple but powerful.The addition of message filters and entity interceptors significantly improve the extensibility of JAX-RS. While message filters are conceptually similar to Servlet filters, entity interceptors are similar to CDI interceptors. While it is possible for end users to use message filters and entity interceptors the more likely users are framework and plug-in writers.Asynchronous processing can significantly improve scalability for the most demanding applications. JAX-RS 2 adds simple asynchronous processing capabilities both on the client and server sides.
WebSocket1.0Yes, WebSockets are supported by CFWebSocket is a key part of the HTML 5 family of standards. It allows for TCP like stateful, full-duplex, bi-directional, asynchronous communication over the web. Unlike stateless vanilla HTTP, WebSocket is useful for cases such as online multiplayer game-like applications, online chat-like applications or stock ticker-like applications.The Java API for WebSocket is a high level API similar to JAX-WS and JAX-RS. There is both a server-side and a client-side API for easily developing with WebSockets. Most of the time you will likely be writing Java server-side endpoints while the client side is written in JavaScript.There is both a declarative annotation centric API as well as an interface centric programmatic API. You will most often likely use the annotation-centric API. The programmatic API is useful for dynamically changing WebSocket endpoints at deployment time, perhaps very helpful for framework writers.
JSON-P1.0YesJSON is quickly becoming the de-facto data serialization protocol on the web, especially with HTML 5.The goal of the Java API for JSON Processing (JSON-P) in Java EE is to standardize JSON for Java, reduce dependence on party frameworks and reduce application complexity.Similar to the Java API for XML Processing (JAXP), JSON-P is a lower level API to handle JSON. It is not a higher level declarative binding API like the Java API for XML Binding (JAXB). Such an API is forthcoming in Java EE 8 and will be named the Java API for JSON Binding (JSON-B).
JPA2.0, 2.1Yes, As long as the database and the 2nd level cache is injected as a backing service.JPA 2.1 standardizes a bunch of non-standard features like schema generation and stored procedures. JPA 2nd level caches should be located outside the JVM and injected as a backing service. Unsynchronized persistence contexts and entity graphs are other optimization introduced.
CDI, Interceptors, Managed Beans, DI1.0, 1.1YesThe CDI specification has become the fundamental building block of the Java EE platform. Java EE7 and Java EE8 is completely being reworked on top of CDI. In addition to providing dependency injection CDI provides eventing, interceptors, decorators and other core application services.
EJB3.1, 3.2YesJava EE 6 EJBs run perfectly fine on Cloud Foundry as long as the remoting protocol is HTTP. Stateless session beans and singleton EJBs run unchanged on the platform as long as the EJB container. Stateful EJBs should not be passivated locally. Stateful EJB passivation will only work with an external distributed cache.
JTA1.1, 1.2NO2PC Transactional commit does not work across multiple distributed REST services. Prefer BASE(Basically Available, Soft state, Eventually consistent) over ACID(Atomicity, Consistency, Isolation & Durability). Transaction managers typical write transaction logs to local file system and rely on persistent server identity - both of these are not available by design in CF. The workaround here is using standalone transaction managers like Atomikos and Bitronix. Introduce eventual consistency patterns
Concurrency Utilities1.0YesThe concurrency utilities for Java EE provide a framework of high performance threading utilities and thus offer a standard way of accessing low-level asynchronous processing.

Java EE Full Profile

The JavaEE full profile has a numnber of management and security technologies that no longer apply in the cloud. Since the platform takes care of application lifecycle management, deployment, scaling , health management and monitoring of apps. Therefore specifications like J2EE Management, Javabeans managment framework are no longer relevant in the cloud. A small subset of specifications like JAXB, JDBC and JMX still apply in the cloud and will work as is in cloud foundry.
In terms of web technologies in the full profile most specifications work unchanged in the cloud; however specifications like JAXR and JAX-RPC are no longer relevant to modern microservices architectures. SOAP based JAXWS webservices will run unchanged in an app server- buildpack that supports the full profile.
Full profile Java apps in general poor candidates to migrate to the cloud.

Other Technology Constraints in moving to the cloud

In addition to the evaluating the suitability criteria from a Java EE perspective there are other views of suitability as well. It is critical to look at the app from multiple lens to determine app suitability. Some of these technology Barriers To Moving Apps and Services to Cloud Foundry are:
  • Language/Runtime Characteristics: CF only supports languages that have a buildpack that run on Linux. Cloud Foundry currently supports Ubuntu Trusty and CentOS 6.5 on vSphere, AWS, OpenStack, and vCloud infrastructures.
  • Degree of Statefulness - Runtime state includes caching and Sessions. Coordination of state across peer instances impacts performance. Any application that requires persistent heavy data processing. Apps that require large-scale stateful connections to external services. Use of frameworks that persist client state on the server side like JSF. Apps that keep a large amount of critical runtime state within the JVM i.e. stateful apps are bad candidates to the PaaS. Ideally all persistent state should reside outside the app in a HA data persistence tier.
  • File System - Cloud app instances are ephemeral. Local file system storage is short-lived. Instances of the same app do NOT share a local file system.Avoid writing state to the local file system. Does the app rely on a persistent local filesystem or storage ?
  • Configuration - Configuration should live external to the deployed app. Config must come from the Environment via environment variables via external configuration server. Apps that have embedded property files or one war/ear file per environment require the refactoring of configuration code before running on the PaaS. We recommend one code base tracked in revision control across multiple deploys. Can you deploy to multiple environments with single codebase.
  • Web Frameworks : Does the app leverage Java EE or Spring Frameworks and if so are the libraries bundled within the app or come with the app server. If there is strong dependence on an application server like WebSphere to provide dependencies or if proprietary application server APIs are used then that forces the app to use a particular buildpack or worse refactoring to start embedding the libraries within the app.
  • Startup/Shutdown Characteristics: Prefer apps that start cleanly without a lot of upfront initialization, coordination and shutdown without the need for comprehensive cleanup of state.
    Is a startup/shutdown sequence necessary for your app to run effectively. Avoid creating any process instances outside the staged runtime.
  • Scalability of the App - Does the app rely on X-axis(horizontal duplication, Scale by cloning), Y-axis (functional decomposition, scale by splitting different things) or Z-axis (data partitioning, scaling by splitting similar things) ?. Design app as one or more stateless processes enabling scale-out via process model.Which other dependent services needs to be scaled when the app is scaled ?
    Dependencies - How are external dependencies wired into the app ? Are dependencies isolated and explicitly declared.http://microservices.io/articles/scalecube.html
  • Inbound Protocols - Only a single inbound port is open to an application. Only protocol supported by CF is HTTP/HTTPs/WebSocket. No other protocols like RMI or JMX will work (unless tunneled over HTTP) on the inbound side. HTTPS is terminated at the load balancer. App that relies on transport security at the server will need to be modified. Apps that hold persistent long running socket connections to the server will not work, with apps using WebSocket being the only exception. Any sort of direct peer-to-peer messaging or custom protocol will not work since the warden containers are configured for ingress only over HTTP.
  • Logging - Are there multiple log streams ? Is there a strong requirement on local persistence of the logs ? Treat Logs of the app as event streams. Prefer console based logging to file based logging. Configure app server logging to log to the console (stdout/stderr) and thereafter drain to a long-term log analytics solution. Logs written to the local file system in CF are not persisted.
  • Rollback - Immutable code with instant rollback capability. Can the app tolerate multiple versions ? Can the app be reverted to a previous version with a single action ? Does deployment of the app require orchestration of multiple steps.
  • Security - Does the app rely on network centric or app centric security model ? We recommend relying on on application Layer 7 security rather than network security based on Firewall rules. How are application users authenticated and authorized. Is a Federated Identity and Authorization solution in place ? In CF, outbound egress from the app is controlled by application security groups applied to the warden container. You will need to configure whitelist rules for the services bound and protocols used for outbound communication.
  • Application Size - cf push times out for apps bigger than 250MB. Staging of apps that exceed a certain size becomes a big drain on resources for network marshalling/unmarshalling as well as runtime memory footprint. Keeping the droplet smaller results in faster deployment. client_max_body_size can be used to changed the max upload size on the Cloud Controller.
  • Performance & Monitoring - Can the app exhaust CPU under load? Are there any concurrency bottlenecks ? Can the app be instrumented for metrics ? Does the app provide a health check/actuator support in production. Does the app leverage app correlation IDs for distributed requests & responses. Does the underlying platform provide basic monitoring(CPU, Disk, Memory) and recovery (Spawning of exited instances) and instant(manual/automated) scaling. Can the logging and admin operations be enabled via runtime switches aka curl requests ?
  • Developer Experience - Does app architecture and web frameworks facilitate local development and cloud production. Does the app ruin on runtimes that run equally locally and in the cloud. Does the app use (Spring) profiles to encapsulate conditional app. configuration.
  • Cloud Native Architecture - Does the app compensate for the fallacies of distributed computing by leveraging framework libraries like Netflix OSS and/or SpringCloud OSS ? Does the app leverage zero downtime practices of forward and backward schema compatibility for REST microservices and databases. Can one service be deployed independently of other services. Is lockstep deployment of physical war’s needed to manifest a logical app ?
  • Data Tier Services/Databases - Any persistence employed by the app has to be synchronized across datacenters and availability zones. The data tier/ Stateful tier of the app has to be managed in lock-step with the stateless tier. Focus has to be put on live content and data migration along with CAP theorem issues. App code has to be forward and backward compatible with schema changes in the data tiers.

Summary

Java EE provides an excellent substrate for a next generation microservices development. As long as you stick to the more recent versions of Java EE (6,7,8) particularly the web profile applications can be implemented and scaled at web scale. It is critical that services follow good design principles of domain driven design, designing for failure, decentralized data management, asynchronous inter-service communication, discoverability and evolutionary design. Existing apps that run on WebSphere Application Sever Network Deployment today are natural candidates to move to the WebSphere Liberty Profile Buildpack. Use the JBOSS and TomEE buildpack for non-WebSphere apps that need a ligter weight more agile runtime in Cloud Foundry. A couple of other options that have not been explored are Dockerizing apps and running apps as fat-jars within Cloud Foundry. For a complete treatement of using Dockers and fat jars please see article and workflow below on migrating WebSphere apps to Cloud Foundry.
↧

Recovering from failure in Cloud Foundry Diego

May 13, 2016, 3:21 pm
$
0
0


Recovery from failures in running Diego processes or tasks involves a combination of the following steps

  1. Look at the current state of the Diego by running the veritas tool on the OpsManager or the Diego Cell VM (bosh ssh diego_cell/0). Run ./veritas autodetect, ./veritas dump-store, ./veritas garden-containers and ./veritas distribution to understand the current state of Diego Deployment.
  2. Look at the failing processes using BOSH with bosh instances --psWhat process is failing ?. Attempt to fix the failing processes with bosh cck or bosh restart Ensure that all the Diego processes like the BBS and BBS Brain and the Cells are running. Ensure that quorum is maintained between the Diego datastores - Etcd, Consul and BBS. 
  3. Pay close attention to the memory and disk quotas necessary for cf app pushes to work. Diego is very conservative in its calculations for the remaining memory and disk capacity for containers. Diego never overcommits if it cannot fit the app under existing quota constraints. For the task to be run by diego the min disk per Cell >= 6GB and min. memory per Cell >= 7GB. In PCF 1.7 we’ve introduced as an experimental feature in 1.7, the ability for you to over-provision / relax the diego insistence on hard commits of memory/disk from the underlying cells.
  4. Look at the PCF Accounting Report. The accounting report let’s you monitor instance usage. This is kind of handy just to see what’s been running, what’s been scaling, how much you’ve used, etc. gain, this is useful to see am I hitting the limits all the time, or am I traveling well under.
  5. Identify repeating errors in the log from LogInsight and Splunk. This will give insight into flapping apps and other zombie instances that could be chewing up the containers. 
  6. The rep.CapacityRemainingMemory metric shows the cell server with the least free memory. If this metric reaches or approaches 0, its a key indicator that your foundation may need more cell servers.bbs.LRPsRunning shows the total running Application Instances in your foundation. If this is a capacity issue, adding Cells and redeploying may fix the problem with the increased resources for staging and running apps.
Screenshot credit goes to the very excellent Mark Fynes.
↧
↧

12 Factor App Transformation

May 16, 2016, 10:54 am
$
0
0
Taking inspiration from the morning paper, today's blog post is a synopsis of the excellent work published In An Agile Approach to a Legacy System where Chris Stevenson and Andy Pols lay down the 12 the core principles to transform a monolith:

 1. Don't reproduce legacy

 2. Always ask the user what the problem is

 3. Refactor a legacy application by delivering business value

 4. Incrementally build trust - prove that you can do the hardest part of the problem

 5. Build a small, self-selected team

 6. Don't get hungup on process

 7. Involve the whole team with larger refactorings so the team can move on as quickly as possible

 8. Effective Teams need breakpoints

 9. Don't sat no, say later. Treat politics as a user requirement

 10. A System that connects to a legacy system must be tested using live feeds

 11. Engage users and they not only won't they turn it off, they will fight some of your battles for you

 12. Keep giving a good team motivated by giving them new hard problems - don't waste a good team
↧

Application Transformation - The Pivotal Way

May 16, 2016, 1:45 pm
$
0
0

Chapter One: Perspective

Monolithic apps aka legacy applications evolve into a mess of of spaghetti code and features that support production workloads that run from airline systems to nuclear reactors to angrybird servers.

With the evolution of the cloud and the death of traditional enterprise vendors there is a huge wave of transformation sweeping across the entire industry neutering all the traditional heavyweight enterprise vendors unhinging apps from their app servers and running them on lighter weight runtimes or even serverless platforms.   

This wave has unleashed a rethinking of application bundling, packaging and deployment constructs at the logical and physical level in terms of domain modeling and immutable deployments, all leading to microservices based architectures that provide the ability to rapidly innovate with people and code.

From a software perspective a monolith is a combination of business capabilities or bounded contexts all enmeshed with a core context. The process of transforming  an app to a microservices based architecture entails separation of each of these bounded contexts into their own contexts.


Chapter Two: Process of breaking apart a monolith:

1. Identify the seams of the application
2. Get started along a seam i.e. with a particular business capability. Ideally this should be something that must be isolated and adds business value.
3. Put fences around the existing feature function by writing tests and  exposing an API

API Fencing and Contracts
4. The API and the tests serve as the moat giving you the confidence to rewrite the existing business capability as a microservice.
5. Ensure that both old and new services are talking to the mothership. Validate that the microservice satisfies all the parent dependencies via canary testing. Optionally the Microservice communicates with the parent through an anti-corruption layer. An anti-corruption layer allows for the refactored microservice domain to remain pure. Think of it as a translator that speaks the languages of both the parent and the child.
6. Route traffic to both the monolith and the microservice with Blue/Green deployment.
7. Wrap the older feature code within the monolith with a feature flag disabled by default.
8. Once the microservice is functioning as expected then disable the same feature in the monolith.
9. Delete the Feature Flag  and the code associated with the feature in the monolith.
10. You have now successfully decomposed the business capability from the parent.
11. Scrub and repeat for all bounded contexts.
https://leanpub.com/Practicing-DDD
 Refactoring Legacy code with an Anti-Corruption Layer https://leanpub.com/Practicing-DDD 

Chapter Three: Identify the seams

One of the most difficult aspect of transformation of an app is figuring out where the seams lie.

The best way to do this is to talk to maintainers and users of the application. Users will describe difficulties in interacting with the application giving hints into which portions of the app need to be rewritten. The app maintainer has intimate details about the sections of code that are stable and those that change very frequently.

Static code analysis with code coverage tools will provide insight into code complexity, external dependencies and coupling. Runtime code analysis with logs and sequence diagrams will provide a map of data of event flows through the application.

Exercises like event storming will map out all the epics and user flows through the monolith. Event Storming is a useful way to do rapid "outside-in" domain modeling: starting with the events that occur in the domain rather than a static data model. Run as a facilitated workshop, it focuses on discovering key domain events, placing them along a timeline, identifying their triggers and then exploring their relationships. Event Storming provides a way to discover the big picture, with the goal of collectively understanding the domain in all of its complexity, before diving into solutions.

The onus is not to do a lot of upfront analysis; rather do just enough to get started. It is important to pick one and get started. Let the process of doing fuel the discovery. In many ways this is similar to hill climbing algorithms.

Chapter Four: People and Process Aspects of Transformation

It is critical NOT to ignore the softer side of app transformation.  The 12 tenets of lean app transformation as laid out in An Agile Approach To A Legacy System are
1. Don't reproduce legacy
2. Always ask the user what the problem is
3. Refactor a legacy application by delivering business value
4. Incrementally build trust - prove that you can do the hardest part of the problem
5. Build a small, self-selected team
6. Don't get hungup on process
7. Involve the whole team with larger refactorings so the team can move on as quickly as possible
8. Effective Teams need breakpoints
9. Don't sat no, say later. Treat politics as a user requirement
10. A System that connects to a legacy system must be tested using live feeds
11. Engage users and they not only won't they turn it off, they will fight some of your battles for you
12. Keep giving a good team motivated by giving them new hard problems - don't waste a good team

Summary

To be successful at application transformation, application decomposition, application replatforming and application refactoring it is critical that you get both the process and technology pieces right. One cannot succeed without the other. That is where a company like Pivotal that builds the PCF platform and runs Pivotal Labs an in house eXtreme Programming consultancy for customer success can help. We believe that the feedback cycle should be as short as possible. Automate everything you can with CI/CD. Build new skills through pairing and by doing. Failure is Productive. Experimentation Informs Strategy. Watch One > Do One > Teach One.
↧
Search

Creating Chaos in Cloud Foundry

June 8, 2016, 6:37 pm
$
0
0
One of the key tenets of operational readiness is to be prepared for every emergency. The best way to  institutionalize this discipline is by repeatedly creating chaos in your own production deployment and monitor the system recovery. The list below is a listing a tools from the PCF Solutions team @ pivotal and others to cause chaos at all levels in the stack in Cloud Foundry.

Tools, Presentations & Repos:
https://github.com/xchapter7x/chaospeddler
https://github.com/xchapter7x/cf-app-attack
https://github.com/strepsirrhini-army/chaos-lemur
https://github.com/FidelityInternational/chaos-galago
https://github.com/skibum55/chaos-as-a-service
Monkeys & Lemurs and Locusts Oh My - Anti-Fragile Platforms

Type of test/event/task



1. BOSH
* bosh target (director ip)
* bosh login (director username/password obtained from Ops Man)
* bosh download manifest cf-(hash) ~/cf.yml
* bosh deployment ~/cf.yml
* bosh vms/cck
* bosh ssh
* bosh logs
* bosh debug (gives you the job/task logs)
2. VM Recovery
* Terminate a VM by deleting it in vSphere, watch it come back up
3. App Recovery
* Terminate an app by using cf plugin, watch it come back up.
4. Correlate logs?
* Watch logs for steps above
5. Chaos Monkeys
* Execute Chaos Lemur and watch bosh/cf respond
6. Director
* Shut VM down/delete in vCenter
* When its down, what app still runs?
* Once VM is gone, how do you get it back/rebuild?
7. Network switch
8. Hypervisor
9. Credentials that expire:
* Certs that have expiration date
* System Accounts (internal CF system accounts)
* vCenter API Account that CF uses
10. Log Insight goes down
11. Kill container
12. Kill VM
13. Kill DEA
14. Kill Router
15. Kill Health Manager
16. Kill Binary Repository
* Then scale
17. Over-allocate Hardware (how do we do it?)
18. Execute and backout a change to CF
19. Bulid Pack Upgrade and Roll Back
20. Right Apps have right build pack
21. Licensing server scenario (for example, can't connect)
22. Double single components (for example, 2 BOSH's)
23. Kill internal message bus
24. DNS
25. Clock drift



Chaos Testing Procedure: 
Kil vms from vsphere; used bosh tasks —no-filter in a loop to watch resurrector bring them up
bosh ssh and sudo kill -9 -1 are also fun
bosh ssh’d into a dea and killed a container
↧

Replatforming .NET applications to Cloud Foundry - Migrating .NET apps to Cloud Foundry

June 9, 2016, 7:31 am
$
0
0

A lot of developers do not realize that Cloud Foundry can run a process from any runtime including .NET. Windows applications are managed side-by-side with Linux applications. .NET apps get support for key PCF features like scaling including autoscaling, monitoring, and high availability, logs and metrics, notifications, services including user-provided services and PCF set environment variables. BOSH and OpsManager now supports deployments on Microsoft Azure via pre-built ARM templates.This blog post provides details of the Windows support and provides guidance on migrating .NET apps to Cloud Foundry . This post build extensively on the work done by the Pivotal product engineering and the solutions team particularly Kevin Hoffman, Chris Umbel , Zach Brown, Sam Cooper and Aaron Fortener.

There are two ways to run ASP.NET  apps on Cloud Foundry

1. Windows 2012 R2 Stack
 • Support Introduced in Nov. 2015
 • Supports.NET 3.5-4.5+
 • Requires Diego-Windows, Garden-Windows
 • BOSH-Windows support currently underway
 • App is pre-compiled, no detect. Leverage binary_buildpack  to push app
 • cf push mydotNetApp -s windows2012R2 -b binary_buildpack
 • Runs on Garden-Windows container
 • Win 2k12 provides process isolation primitives similar to those found in the Linux kernel
 • IronFrame abstracts these primitives into an API utilized byGarden-Windows
 • Win 2k12’s low-level API ≈ Linux kernel’s API
 • Therefore Garden-Windows process isolation functionality ≈ Garden-Linux
 • Developer OS is Windows

2. Linux cflinuxfs2 Stack
 • ASP.NET Core CLR only
 • Runs on Diego or DEA
 • Standard CF Ubuntu Stack
 • Community ASP.NET 5 Buildpack
 • cf push mydotNetApp -s cflinuxfs2 -b <asp.net5 bp>
 • Garden-Linux is the backing container
 • Garden-Linux containers are based on LXC (Linux cgroups)
 • Developer OS is Win, Mac OSX and Linux

ASP.NET Core vs ASP.NET 4.6


 • ASP.NET Core
  • Web API
  • ASP.NET MVC
  • No Web Forms (yet)
  • No SignalR
• ASP.NET 4.6
  • Battle-tested, hardened
  • Many years of testing and improvement
  • MVC, Web Forms, SignalR, etc.

Migrating Existing Applications

• For Greenfield Applications Try “Core First” approach
• For Replatforming and migrating Existing Apps Probably ASP.NET 4.x
• Dependencies and framework requirements will likely dictate choice
• All versions of the .NET SDK supported by Windows Server 2012 R2 are supported on PCF including 3.5, 4.5, 4.5.1 and 4.6

Here are some of the details on how Garden-Windows secures applications


Non Cloud-Native stuff you will want to change

 • Reading/Writing to the Registry.
 • Reading/Writing to the local disk. File systems are ephemeral. Replace usage of the file system e.g. disk logging even temp files with a S3 compatible blob store or external file store.
 • Replace  Integrated Windows Auth. with ADFS/OAuth2 to leverage UAA and Pivotal SSO Tiles
 • In-Process Session State / Sticky Sessions. Replace InProc, StateServer with out-of-process data store e.g. Redis, SQL Server
 • Externalize  environment-specific config in web.config into VCAP environment variables. If value changes between environments, don’t get it from web.config. Don’t use externalization methods that only work in Azure. If app relies on machine.config or applicationHost.config, could have issues in PCF.
 • For MSI-Installed services or drivers, Bin deploy dependencies with app.
 • Nearly every app will need refactoring to use Console logging and tracing. Customers who mess with applicationHost.config can interfere with tracing, logging, etc.
 • 32 bit ASP-Net builds/References/Builds/apps depending on 32-bit libraries will not work.
 • WCF Self-hosted services  and SharePoint apps will not work in CF.
 • Apps requiring assemblies in Global Assembly Cache won't work in CF.
 • Backing Service Drivers requiring native installers / DLLs may not work in CF.
 • On Demand Apps and ones triggered by job controller will need to be refactored to run in CF to use CF one-off task support coming in the CC v3 API.
• MSMQ and tight integration with other MSFT server products via on-server dependencies will need to be refactored to use external backing services. .NET Core is now supported in the RabbitMQ .NET client.
• Routing to non-HTTP WCF endpoints and listeners for third party middleware will not work since only HTTP based inbound traffic is routed to the windows containers.

.NET Application Selection Criteria


References

• Running .Net Apps on Cloud Foundry: Windows vs. Core
• Deploying your first .NET app on Cloud Foundry http://engineering.pivotal.io/post/dotnet-quick-intro/
• Garden-Windows Deep-dive http://engineering.pivotal.io/post/windows-containerization-deep-dive/
• DiegoMVC Demo https://github.com/ruurdk/DiegoMVC
• ASP.NET Core Demo https://github.com/ritazh/aspnetcoreapp-cf
• ASP.NET 5 Buildpack https://github.com/cloudfoundry-community/asp.net5-buildpack
• Diego-Windows  https://github.com/cloudfoundry/diego-windows-release
• Garden-Windows https://github.com/cloudfoundry/garden-windows
• Steel Toe https://github.com/SteelToeOSS
• Contoso University: https://github.com/pivotalservices/contoso-university
↧
↧

Top 10 KPIs Cloud Foundry

June 9, 2016, 12:32 pm
$
0
0
The cloud foundry firehose and syslog streams generate tons of metrics and logs. What should a busy devops engineer look at ? My colleague Ford Donald put this awesome list of the top 10 KPIs of Cloud Foundry.

+----------------------------------+---------+--------------------+
| KPI                              | Description
+----------------------------------+---------+--------------------+
| rep.capacityRemainingMemory      | Available cell memory (sum for all cells)
| rep.capacityRemainingDisk        | Available cell disk (sum for all cells)
| bbs.LRPsRunning                  | Equivalent to # apps running
| bbs.RequestLatency               | CF of API is slow if this rises
| bbs.ConvergingLRPduration        | Apps or staging crashing if this rises
| stager.StagingRequestFailed      | Indicates bad app or buildpack pushes
| auctioneer.LRPauctionsFailed     | CF can’t place an app (out of container space)
| router.totalRoutes               | Size in routes of a PCF install (indicates uptake)
| router.requests                  | Tracks traffic flow thru a PCF
| bosh.healthmonitor.system.healthy| Indicates BOSH/VM health
+----------------------------------+---------+--------------------+





↧

Multi-line Java stack traces out of order in Logstash and Splunk

June 14, 2016, 3:12 pm
$
0
0
Do you have customers frustrated by getting multi-line Java stack traces out of order? We're working on a clean solution in our enhanced metrics work, but here is a workaround courtesy @DavidLaing .
With the Java Logback library you can do this by adding 

"%replace(%xException){'\n','\u2028'}%nopex" 

to your logging config [1] , and then use the following logstash conf.[2]
Replace the unicode newline character \u2028 with \n, which Kibana will display as a new line.


mutate {
  gsub => [ "[@message]", '\u2028', "
"]
^^^ Seems that passing a string with an actual newline in it is the only way to make gsub work
}



In Splunk you will need to configure the the event stream to recombine multine exceptions into one event. See http://docs.splunk.com/Documentation/Splunk/5.0/Data/Indexmulti-lineevents
↧

Wildcard DNS and CloudFoundry - A can of worms ? - or sensible hack to productivity

July 11, 2016, 7:54 am
↧
Viewing all 142 articles
Browse latest View live
Search