Posts Tagged ‘cloud foundry’

TCP Routing and SSL: A Walkthrough Using Spring Boot An incredible guest blog by Ben Dalby, Advisory Consultant at DellEMC

An incredible guest blog by Ben Dalby, Advisory Consultant at DellEMC

Walkthrough: Cloud Foundry TCP Routing and SSL

Guest Blog by Ben Dalby, Advisory Consultant (Applications and Big Data) at DellEMC

Use Cloud Foundry’s TCP routing feature to terminate SSL directly in your application

Introduction

A common security requirement for customers in regulated industries such as banking and healthcare is that all traffic should be secured end-to-end with SSL.

Prior to Pivotal Cloud Foundry 1.8, inbound SSL connections would always terminate on the Gorouter, and further encryption could only be achieved between the Gorouter and running applications by installing Pivotal’s IPsec Add-on

With the introduction in version 1.8 of TCP routing, it is now possible to terminate SSL right at your application – and this article will walk you through a working example of a Spring Boot application that is secured with SSL in this way.

Prerequisites

PCF Dev version 0.23.0 or later
JDK 1.8 or later
Gradle 2.3+ or Maven 3.0+
git (tested on 2.10.1)
A Linux-like environment (you will need to change the file paths for the directory commands to work on Windows)

How to do it

Step 1 – Create a Spring Boot application

We’re going to be lazy here, and simply make a couple of small modifications to the Spring Boot Getting Started application:

$ git clone https://github.com/spring-guides/gs-spring-boot.git

Step 2 – Create an SSL certificate

$ cd [GITHUB HOME]/gs-spring-boot/intial/src/main/resources
$ keytool -genkey -alias tomcat -storetype PKCS12 -keyalg RSA -keysize 2048 \
-keystore keystore.p12 -validity 3650 -keypass CHANGEME -storepass CHANGEME \
-dname "C=GB,ST=Greater London,L=London,O=Dell EMC,OU=Apps and Data,CN=abd.dell.com"  

Step 3 – Configure Spring Boot to use SSL and the new certificate

(You can also retrieve the application.properties shown below from here)

$ cd [GITHUB HOME]/gs-spring-boot/intial/src/main/resources
$ cat <<EOT >> application.properties  
server.port: 8080
server.ssl.key-store: classpath:keystore.p12
server.ssl.key-store-password: CHANGEME
server.ssl.keyStoreType: PKCS12
server.ssl.keyAlias: tomcat
EOT  

Step 4 – Package the application

$ cd [GITHUB HOME]/gs-spring-boot/intial  
$ mvn clean package  

Step 5 – Push the application to PCF Dev (use default org and space)

$ cd [GITHUB HOME]/gs-spring-boot/intial
$ cf target -o pcfdev-org -s pcfdev-space
$ cf push gs-spring-boot -p target/gs-spring-boot-0.1.0.jar  

Step 6 – Create a TCP route and map it to your application

$ cf create-route pcfdev-space tcp.local.pcfdev.io --random-port
Creating route tcp.local.pcfdev.io for org pcfdev-org / space pcfdev-space as admin...
OK
Route tcp.local.pcfdev.io:61015 has been created
$ cf map-route gs-spring tcp.local.pcfdev.io --port 61015

Step 7 – Verify you can now connect directly to your application over SSL

Browse to https://tcp.local.pcfdev.io:61015/ (substitute your own port after the colon):

View details of the certificate to verify it is the one you just generated (note the procedure has just changed if you are using Chrome):

Further Reading

Enabling TCP Routing
http://docs.pivotal.io/pivotalcf/1-9/adminguide/enabling-tcp-routing.html

How to tell application containers (running Java apps) to trust self-signed certs or a private/internal CA https://discuss.pivotal.io/hc/en-us/articles/223454928-How-to-tell-application-containers-running-Java-apps-to-trust-self-signed-certs-or-a-private-internal-CA

Enable HTTPS in Spring Boot
https://drissamri.be/blog/java/enable-https-in-spring-boot/

Do You Hear That? It’s the sound of Keyboards! Call for Papers | Cloud Foundry Summit Silicon Valley 2017 is quickly approaching!

Call for Papers | Cloud Foundry Summit Silicon Valley 2017 is quickly approaching!

Our brains are on fire, our keyboards are hot, and the joke in the office the past few days has been over our extreme excitement for the eventual need to buy sunscreen since our Boston winter leaves us Vitamin D deprived. Why is this the case, you may or may not be asking? Well, I plan on telling you anyway because it is just too exciting not to share!

Our team is preparing for CLOUD FOUNDRY SUMMIT SILICON VALLEY! We felt a social duty to let all of those we care about and want to be there with us for what’s sure to be the summit of the summer (how can it not be when it is being held in June in Santa Clara?!), that the last call for papers is quickly approaching (no seriously, it’s this Friday, February 17th).

Just as a refresher for those on the fence, Cloud Foundry Summit is the premier event for enterprise app developers. This year the Foundation, through market research and feedback, found that interest and industry need is engrained in the focus on innovation and the streamlining of development pipelines. For this reason, Summit 2017 is majorly honing in on microservices and continuous delivery in developers’ language and framework of choice. That is why the session tracks available will be Use Cases, Core Project Updates, Experiments, Extension Projects, and Cloud Native Java. Each session that is chosen for the conference is enabled (1) primary speaker and (1) co-speaker. The primary speaker receives a complimentary conference pass while the co-speaker receives a discounted conference pass. So what’s stopping us from getting involved? Absolutely NOTHING!

As a sneak peak to a few of the topics our team have submitted for approval, see below:

  • Adopting DevOps and Building a Cloud Foundry Dojo (Lessons Learned)
  • Lift & Shift Your Legacy Apps to Cloud Foundry
  • How to Develop Scalable Cloud Native Application with Cloud Foundry
  • Enabling GPU-as-a-Service in Cloud Foundry
  • Blockchain as a Service
  • Avoiding pitfalls while migrating BOSH deployments
  • Spring Content: Cloud-Native Content Services for Spring

 

So, now what’s stopping YOU from getting involved? Submit papers here: https://www.cloudfoundry.org/cfp-2017/ and/or register here: https://www.regonline.com/registration/Checkin.aspx?EventID=1908081&utm_source=flash&utm_campaign=summit_2017_sv&utm_medium=landing&utm_term=cloud%20foundry%20summit&_ga=1.199163247.1732851993.1460056335

Last but definitely not least, let us know if you plan on coming—we are more than happy to share sunscreen 🙂 We cannot wait to see you there!

Bringing Cloud Foundry to You… Exciting Upcoming Events that the Cool Kids are Attending

Exciting Upcoming Events that the Cool Kids are Attending

For those of you who follow us on Twitter (@DellEMCDojo for those that don’t) or via this blog, I would guess it is pretty evident that we just love Cloud Foundry. We take pride in being a member of the foundation mostly because it is with this platform that we feel we are delivering and practicing what we preach; living out a true DevOps culture most conducive to productivity and quality product and delivery.

We are lucky enough to just be returning from Cloud Foundry Summit where upwards of 800 developers and other market adopters joined in Frankfurt, Germany to learn from other community members and to be a part of the PaaS’s business direction. With the Native Hybrid Cloud team, we at the Dojo spent our days representing DellEMC through presentations and booth shifts. We left feeling even more confident in our daily choice to use Cloud Foundry and to further evangelize the PaaS for the betterment of the larger technical OS community.

It is because of this that we are excited to announce that we will be hosting and supporting three Cloud Foundry Days here in the near future. Cloud Foundry Days are new, one-day educational events aimed at developers and operators who want to connect with businesses, learn about the platform, and share knowledge. The first that we will be hosting with the support of TIBCO, Pivotal, Telstra, Stark & Wayne, among others, is going to be taking place on October 18th in Sydney, Australia. If you have any interest in attending or know of others who may be, please find the registration link here: https://www.eventbrite.com.au/e/cloud-foundry-day-sydney-australia-tickets-27935602138. The second of these events will be taking place on October 20th in Melbourne, Australia and will also be supported by TIBCO, Pivotal, Telstra, Stark & Wayne, among others. The registration link for this event can be found here: https://www.eventbrite.com.au/e/cloud-foundry-day-melbourne-australia-tickets-27985249635. Last, but definitely not least, is the CF Day in Shanghai, China on October 25th where we will be supporting GE (Registration information to be available within the next day or two. Please contact us via twitter if you are interested).

We truly hope that these events will be fruitful in their reach and effectiveness, and help our technical community discern the best option for themselves and the businesses they affect. Teamwork makes the dream work!

NFS app support in under 5 minutes with CloudFoundry, Wahooo!

Peter Blum

Developers want quick and easy access to storage! They don’t care how they get it, they just want it now. Let me show you how a developer can go from 0 to 100 with persistence in CloudFoundry, starting with Dell EMC Isilon.

Cloud Foundry. Open Source. The Way. Dell EMC [⛩] Dojo.

Creating a Cloud Foundry Service Broker

Megan Murawski

Megan Murawski

Megan Murawski

Latest posts by Megan Murawski (see all)

12-factor apps are cool and Cloud Foundry is cool but, we don’t just have to worry about 12 factor apps.  We have legacy apps that we also need to pay attention to.  We believe there should be a way for all of your apps to enjoy the benefits of Cloud Foundry.  We have enabled this by implementing a Service Broker that binds an external storage service.  Before we talk about the creation of the Service Broker we will describe the role of a Service Broker in Cloud Foundry.

Services are integrated with Cloud Foundry by implementing a documented API for which the cloud controller is the client; we call this the Service Broker API.  Service brokers advertise a catalog of service offerings and service plans, as well as interpreting calls for provision (create), bind, unbind, and deprovision (delete).  By externalizing the backend services from the application in a PaaS provides a clear separation that can improve application development. Dev only needs to be able to connect to an external service to consume its APIs. In Cloud Foundry, this interface is “brokered” by the Service Broker.  Some examples of services which are essential to the 12 Factor app are: MySql, Redis, RabbitMQ, and now ScaleIO!

Screen Shot 2016-05-23 at 1.28.26 PM

A service broker sits in between the Cloud Foundry Runtime and the service itself. To create a service broker, you only need to implement the 5 Service Broker APIs: catalog, provision, deprovision, bind and unbind. The service broker essentially translates between the Cloud Controller API and the service’s own API to orchestrate creating a service instance (maybe provisioning a new database or creating a new user), providing the credentials to connect to the service, and disconnecting and deleting the service instance.

The APIs

Catalog is used to fetch the service catalog. This describes the service plans that are available with the backend and any cost.

Provision is used to create the service in the backend. Based on a chosen service plan, this call will actually create the service. In the case of persistence, this is provisioning storage to be used by your applications.

Bind will provide Cloud Foundry runtime with the credentials and configuration to access the service. This allows the application to connect to the service.

Unbind will remove the access credentials from the application’s environment.

Deprovision is used to delete the service on the backend. This could remove an account, delete a database, or in the case of persistence, delete the volume created on provision.

 

Creating the Broker

To create the ScaleIO service broker, we made use of the EMC open source tool Libstorage for communicating with the ScaleIO backend. Libstorage is capable of managing many different storage backends including ScaleIO, XtremIO, Isilon and VMAX in a client/server model.  By adding an API layer on top of Libstorage, we were able to quickly translate between Cloud Foundry API calls and storage APIs on the backend to provide persistence as a service within CF. Like much of the work we do at the EMC Dojo we have open sourced the Service Broker.  If you’d like to download it or get involved, check it out on github!

How to Deploy Diego in a Hybrid Environment Deploying Cloud Foundry Diego in a Virtual and Bare Metal Environment

Deploying Cloud Foundry Diego in a Virtual and Bare Metal Environment

In my last post “Deploying Cloud Foundry in a Hybrid Environment“, I showed you how to deploy DEA runners in a bare-metal environment. However, Cloud Foundry now has new and exciting Diego runtime! So now I will guide you through how to deploy Diego Cells on bare metal machines. When we’re all done, your environment will look like this:

Diagram7

(more…)

Creating Cloud Foundry Applications with Persistence Traditional & Cloud Native Applications with Persistence

Traditional & Cloud Native Applications with Persistence

Cloud Foundry and 12-Factor applications are great to create Cloud Native Applications and has become the standard. But you and I don’t just have to worry about our new 12 Factor apps, we also have legacy applications in our family.  Our position is that your traditional apps and your new cool 12-Factor apps should be able to experience the benefits of running on Cloud Foundry.  So, we have worked to create a world where your legacy apps and new apps can live together.

cf-logo

In the past, Cloud Foundry applications cannot use any filesystem or block storage. That totally makes sense, given that Cloud Foundry apps are executed in elastic containers, which can go away at any time. And if that happens, any data written to the local filesystem of the containers will be wiped.

If we can externalize persistent storage to be a service – and bind and unbind those services to Cloud Foundry applications – a lot more apps can run in Cloud Foundry. For example, heavy data access apps, like databases and video editing software, can now access extremely fast storage AND at the same time experience the scalability and reliability provided by Cloud Foundry.

Allowing Cloud Foundry applications to have direct persistence access opens a lot of doors for developers. Traditional applications that require persistence can migrate to Cloud Foundry a lot easier. Big Data Analytics applications can now use persistence to perform indexing and calculation.

Traditionally, a lot of data services consumed by Cloud Foundry applications, such as MySQL, Cassandra, etc, need to be deployed by Bosh as Virtual Machines. With Persistence, we can start looking bringing these services to run in Cloud Foundry or create the next generation of Cloud Native data services.

What can Developers Expect?

When developers come to the Cloud Foundry marketplace by using cf marketplace, they will see services that can offer their applications persistence:

Screen Shot 2016-05-20 at 10.37.37 AM

The details of the service plan can be seen by cf marketplace -s ScaleIO

Screen Shot 2016-05-20 at 10.57.04 AM

This is a plan that would offer 2GB of storage for your Cloud Foundry applications. Let’s sign up for it by running cf create-service scaleio small my-scaleio-service1

Screen Shot 2016-05-20 at 11.02.26 AM

By creating a service instance, the ScaleIO Service Broker goes into ScaleIO and creates a volume of 2GB. We are now ready to bind this new service to our app. To demonstrate the functionality, we have created a very simple application that will write and read to the filesystem:

Screen Shot 2016-05-20 at 11.09.51 AM

After a cf bind-service call, the storage will be mounted as a directory and the path will indicate an environment variable inside the service. For example:

Screen Shot 2016-05-20 at 11.35.07 AM

Based on the container_path variable, the application can read and write as if it’s a local filesystem.

 

UniK: Build and Run Unikernels with Ease UniK, Unikernels, Cloud Foundry, Docker, Kubernetes, Raspberry Pi, IoT

UniK, Unikernels, Cloud Foundry, Docker, Kubernetes, Raspberry Pi, IoT

Idit Levine

Idit Levine (@Idit_Levine), Office of the CTO & CTO of Cloud Platform Team, EMC

Unikernels are lightweight, immutable operating systems compiled specifically to run a single application. Unikernel compilation combines source code with the specific device drivers and operating system libraries necessary to support the needs of the application. The result is a machine image that can run directly on a hypervisor or bare metal, eliminating the need for a host operating system (like Linux). The unikernel represents the smallest subset of code required to run the application, giving us portable applications with smaller footprints, less overhead, smaller attack surfaces, and faster boot times than traditional operating systems. Together, I believe unikernels have the potential to change the cloud-computing ecosystem as well as to dominate the emerging IoT market.

However, compiling a unikernel is a challenging assignment. It requires rare expertise often absent in application developer’s toolkit. The difficulty of compiling Unikernels may significantly hamper their widespread adoption. I believe that the community will benefit from a straightforward way to build and manage unikernels.

This is why UniK was developed.

unik-logo

UniK (pronounced you-neek) is a tool for compiling application sources into unikernels — lightweight bootable disk images — rather than binaries. UniK runs and manages instances of compiled images across a variety of cloud providers as well as locally on Virtualbox. UniK utilizes a simple docker-like command line interface, making building unikernels as easy as building containers. UniK is built to be easily extensible, allowing – and encouraging – adding support for unikernel compilers and cloud providers.

UniK is fully controllable through a REST API to allow for seamless integration between UniK and orchestration tools such as Kubernetes or Cloud Foundry.

Docker Integration: Recognizing the open source community’s popular adoption of the Docker API, we extend UniK’s REST API to serve some of the same endpoints as Docker, allowing some Docker commands such as docker run, docker rm, and docker ps to control UniK, which we hope will make UniK easier to adopt for those already familiar with Docker.

Kubernetes Integration: To demonstrate the value of cluster management of unikernels, we implemented a UniK runtime for Kubernetes, making Kubernetes the first cluster manager to support unikernels. This integration allows UniK to take advantage of core Kubernetes features like horizontal scaling, automated rollouts and rollbacks, storage orchestration, self-healing, service discovery, load balancing and batch execution.

Cloud Foundry Integration: To provide the user with a seamless PaaS experience, we added UniK as a backend to the Cloud Foundry runtime, positioning Cloud Foundry as the first platform to run applications as unikernels. This adds the lightweight scalability of unikernels with the security and sophistication of vms (lightweight, immutable, performant), persistent storage, and the ability to run on bare metal.

ARM Integration: We believe the quintessential use case for unikernels is the advantage they give to smart devices in the Internet of Things. Their airtight security, immutable infrastructure, high performance and light footprint make them the ideal solution for deploying software on embedded devices. To demonstrate this vision for the future of unikernels, we implemented ARM processor support into UniK to run unikernels on the architecture used in most embedded devices such as the Raspberry Pi.

Today, we are thrilled to share the open source UniK under the Apache 2.0 license. We hope that the community will join us in making the Unikernel a first class citizen in the future cloud ecosystem and emerging market of IoT devices. Please visit our repository at https://github.com/emc-advanced-dev and try our Getting Started with UniK Tutorial https://github.com/emc-advanced-dev/unik/blob/master/docs/getting_started.md

Vegas Baby! EMC Dojo at EMC World 2016 EMC Dojo at EMC World 2016

EMC Dojo at EMC World 2016

EMC Dojo is at EMC World!

Come check out our sessions and play #Dojosnake! Scroll to see more!

What’s up at our Booth?

Come to booth #1051# to see what the EMC Dojo is up to! Learn more about persistence on Diego, UniK unikernel support for Cloud Foundry + Docker, RackHD CPI, & our other OSS Cloud Foundry projects!

Want to try pair programming? Give it a try at our booth! See how easy it is to $CF push apps to Cloud Foundry & pair with us on #Dojosnake! Won’t be able to make it to Vegas this year? Then see if you can beat the high score and play #Dojosnake! Make sure you tweet and follow @EMCdojo to get on the leaderboard 🙂

Screen Shot 2016-05-02 at 9.01.16 AM

If you will be in Vegas, come to one (or more!) of our sessions listed below.  Hope to see you there! (more…)

How to Deploy Cloud Foundry in a Virtual & Bare Metal Hybrid Environment Deploying Cloud Foundry on VSphere and Bare Metal

Deploying Cloud Foundry on VSphere and Bare Metal

This is a guide for setting up Cloud Foundry in a hybrid environment with virtualization and bare-metal infrastructure. Cloud Foundry is made up of many components. It makes sense to run most of them in a virtual environment for resource sharing and separation reasons. And these pieces might not require the resources for an entire physical machine all to itself.

Computing components, such as DEA Runner or Diego Cells, should run on Bare-Metal to fully make use of the computing power, without spending resources for your virtualization tier.

This tutorial will guide you step by step, to set up Cloud Foundry components on vSphere and DEA Runner on Bare-Metal machines. When you finish, your environment will look like this:

Diagram1

(more…)

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.