OpenStack, Cloud Foundry and a turnkey app environment
On November 17, Mirantis’ Kamesh Pemmaraju and John Jainschigg and Pivotal’s Ryan Pei got together to provide a joint webinar explaining how Pivotal Cloud Foundry and OpenStack can come together to provide a turnkey application environment. We had some great questions, so we wanted to answer them here in the blog.
Q: What do you mean by “not locked in”? How portable is a Cloud Foundry application?
Ryan: Seamlessly portable 🙂 Cloud Foundry works on many IaaSs and the way you create and deploy your apps does not change from one IaaS to another.
Q: What are the application dependencies on Cloud Foundry? For example, how easy/hard is to move away from an app done in the Cloud Foundry environment?
Ryan: It’s not difficult at all. For instance, with a Java app, if you wanted to port the app off of Cloud Foundry, you would just need to ensure that the dependencies in the Cloud Foundry buildpacks are provided in the new environment, such as a JVM. There shouldn’t be any configuration changes required.
Q: Can I do the same with Ops Manager or Apps Manager ?
John: Ops Manager is basically a configuration and deployment tool that manages interactions with BOSH (the actual deployment engine) — it’s an easy way for users to configure and deploy Pivotal Cloud Foundry and related products on an IaaS, without having to deal directly with the YAML files that BOSH consumes. Apps Manager is a management UI for an installed PCF environment that provides a web UI to (for admins) manage user accounts, create organizations, spaces and other ‘tenant-like’ permission/resource subdivisions, etc., and (for admins and end user developers) to manage orgs, spaces and apps they own. (So, yes.)
Q: How do you segregate your workloads (security, network, traffic management)? Do you build multiple PaaS (for Dev, for Prod, etc.) or you have a single large PaaS that is segmented for the various uses?
Ryan: Cloud Foundry is inherently a very secure environment, because it limits network traffic to a very small number of entrypoints (the customer-provided load balancer upstream from the CF router, plus VMs used to manage the PCF cluster). PCF deploys apps on secure containers with their own strict memory allocations and private read/write file systems. It uses Application Security Groups, role-based authentication and other abstractions to let operators configure portable security and access policy on an app-by-app basis. The software (buildpacks, service APIs and components) against which applications run impose security on ‘operating system’ calls. And since all these components can be updated non-disruptively, it should be relatively easy to keep pace with patches. This includes VM stemcells providing the guest OS underlying major PCF components, which can be rolled back and out with BOSH. Underneath Cloud Foundry, there are all sorts of ways of segregating and securing VM workloads and tenant networks on OpenStack, including stuff like using Availability Zones, affinity/anti-affinity groups, Intel TXT, etc., to direct VM workloads (e.g., Cloud Foundry components) by tenant and other characteristics to particular compute and storage resources, and stuff like NetScaler and Contrail to build any-to-any high-capacity mesh networks and isolate different traffic types and tenant-by-tenant/app-by-app traffic on VLANs or tunnels. Finally, the extraordinary speed and ease of deploying Mirantis OpenStack and Pivotal Cloud Foundry makes brute-force ‘air-gap’ strategies operationally efficient — you can have, not just separate PaaSs in separate tenants, but separate PaaSs on separate clouds for Dev/Test and Production.
Q: Patching/Ownership; Application Framework (spring)/Runtime /Infra Auto(bosh), etc. Who’s owns the patching of these?
Ryan: The Cloud Foundry Foundation is patching and supporting these components on behalf of the community at large, and Pivotal is doing the same on behalf of its customers across all the Pivotal Cloud Foundry products, including Ops Manager, Apps Manager, Spring Cloud Services, etc.
Q: Hi, I would like to know whether we can install JBoss as Application catalog in Mirantis OpenStack ?
A: Mirantis has published a Murano app that deploys JBoss in a Docker image. You can find it at https://github.com/openstack/murano-apps/tree/master/Docker/Applications/JBoss/package.
Q: Can we use OpenStack’s Trove to provide Databases as a Service?
John: It’s not immediately clear what advantage one might gain from this, since PCF provides DBaaS to many flavors of database already. However, in principle, if you were, for example, using PCF to build an app that provided authorized users (e.g., operators) with a tool to set up databases and provide DB credentials on the underlying OpenStack, it should be possible to use the CF service broker API to create a service broker to Trove.
Q: Hi, can any of this deploy behind a corporate internet proxy?
A: Yes, many people do this.
Q: What’s is the core difference of using ops manager to install CF versus using CF community via the Murano package?
John: There are many differences. Pivotal Cloud Foundry, installed with Ops Manager, includes a distribution of Community Cloud Foundry, plus additional components from Pivotal. If you would prefer to work with Community Cloud Foundry, at this point, we recommend installing a recent version using the community-provided BOSH installer. Alternatively, the Murano app, which deploys version 1.4 of community Cloud Foundry in a small, PoC configuration, may suffice for initial evaluations.
Q: Will you be covering the differences between using a buildpack (e.g. python/django) vs. using docker, particularly in the case where a buildpack exists for your dev environment? What are the pros and cons of using one vs. the other and what different CF “features” set these two uses apart (i.e. docker vs. app buildpack)?
Ryan: Buildpacks come with good guidelines on how to create your applications for a specific language and/or framework. Docker is very open-ended in terms of what you can add to Docker containers, so that gives you a lot of freedom but then you must be careful that this freedom is not abused. It may not be as easy, for instance, to restage every app in your system with a security or maintenance patch if not everyone is using standardized filesystems.
Q: In the Infra as Code “spirit” how are the configurations (tenants, admin, credentials, etc.) kept so that if someone were to mess up the setup of CF it can be recreated from “code”? Is backing up the way to achieve such redundancy or is there a concept of “coding” that setup (checking in to source control)?
Ryan: PCF Ops Manager has a feature that allows you to “Export settings”, or download a zip file that contains all of your deployment settings. We suggest downloading this package regularly and whenever changes are being made.
Q: When auto-scaling down your app instances, how does the platform determine which instance should be shut down?
Ryan: The platform shuts down instances starting with the highest index values in Cloud Controller.
Q: What are the key points to port a legacy app to a CF compatible version ?
Ryan: Any app can be seamlessly ported over to CF, but if you do have time to refactor, we would recommend following the Twelve Factor principles when designing your application. Some more specifics are available here in the CF docs http://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html as well.
Q: Hi. Where can I read about CF – Integrated logging and about multi-cloud – what it means to have a VM evacuation?
Ryan: You can find out more about Cloud Foundry at http://docs.cloudfoundry.org.
Q: As of now, CF Buildpacks does not support Dynatrace for monitoring. Will it be possible in the near future? I could see New Relic has been added as an extension.
Ryan: Custom buildpacks are always an option. New Relic actually released a service for Pivotal Cloud Foundry earlier this year, and we’re evaluating whether this is a good solution for the long-term.
Q: Can end users deploy microservices as well, just like pushing apps?
John: Microservices are essentially just very simple, single-process applications. You can take full advantage of this architecture by using a framework to wire together these microservices into a cohesive app. This is where a tool like Spring Cloud Services can help you to compose something really great with Java Spring microservices.
Q: How much programming skill is required to create custom PCF services? Is this a task for Dev or Ops?
Ryan: It’s easy to do; check out http://docs.cloudfoundry.org/services. Either Dev or Ops can create them for their own use.
