Beyond Application Security Groups: Avoid App Restarts with Dynamic Egress Policies in PCF 2.4.

EMC logo


Do you wish you could apply a simple egress network policy on an app in Cloud Foundry, without requiring an app restart? Want greater control over how the apps in a given Space access an external service? Now you can, with a new beta feature in Pivotal Cloud Foundry 2.4: dynamic egress policies.

Before we dive into the new feature, let’s take a step back and define what the heck an egress policy is, and how it’s managed in Pivotal Cloud Foundry (PCF). Note that we are only focusing on egress traffic in this blog since ingress traffic is typically controlled outside the platform.

Egress Policies in Pivotal Cloud Foundry

Egress policies control how traffic flows from your apps to off-platform services. Platform operators manage these policies using Application Security Groups (ASGs). ASGs are a collection of rules that specify the protocols, ports, and IP address ranges where application or task instances send traffic. ASGs are a tried-and-true model for controlling access to applications. They work well for many scenarios.

However, operators have bumped up against the limits of ASGs in recent times. In particular, PCF customers are looking for ways around these limitations of ASGs:

  • Permissions are too coarse. You have to create a policy at the space level even if only a few apps in the space require access to the external service.

  • App restarts are required. You have to restart your apps when applying these policies, which causes downtime.

This brings us to the news of the day!

Say Hello to Dynamic Egress Policies, Now a Beta Feature

You now have a better way to set and manage egress policies with Dynamic Egress Policy Configuration, a beta capability in PCF 2.4. (This feature was released as part of open source Cloud Foundry v2.19.0.) Note that ASGs will be supported in PCF for the near future, while we continue to enhance dynamic egress policies. In the meantime, policies created by both mechanisms will apply to your environment.

Before we dive too deep into how dynamic egress policies work, there are a couple of prerequisites to using this feature:

  1. This feature is disabled by default. To enable this feature, you must select Enable Beta Dynamic Egress Enforcement in the PAS Networking pane. Additionally, you must have Silk selected as your Container Network Interface Plugin.

  2. To administer dynamic egress policies, you must have the network.admin UAA scope. If you are a CF admin, you already have the network.admin scope. An admin can also grant the network.admin scope to a space developer.

With these requirements met, you can proceed to create dynamic egress policies to allow your apps to communicate with external services, such as a MySQL database. The workflow is as follows:

  1. Create a destination object with details about the external service that your application or space needs to access.

cf curl -X POST /networking/v1/external/destinations -d '{

 "destinations": [

  {

     "name": "MySQL",

      "description": "Demo",

      "ips": [{"start": "23.96.35.235", "end": "23.96.35.235"}],

      "ports": [{"start": 80, "end": 80}],

       "protocol":"tcp"

  }

]

}'

  1. Fetch the id of the new destination object.

  cf curl /networking/v1/external/destinations | jq .

{

 "total_destinations": 1,

 "destinations": [

   {

     "id": "e8a85db3-5189-48d8-566b-086c886d819e",

     "name": "MySQL",

     "description": "Demo",

     "protocol": "tcp",

     "ports": [

       {

         "start": 80,

         "end": 80

       }

     ],

     "ips": [

       {

         "start": "23.96.35.235",

         "end": "23.96.35.235"

       }

     ]

   }

 ]

}

  1. Fetch the GUID of the app/space that need access to the external service.

cf app backend --guid

887757be-5eda-48ce-b427-79dcc0705e91

  1. Create an egress policy from the application or space to the destination object.

cf curl -X POST /networking/v1/external/egress_policies -d '{

"egress_policies": [

  {

     "source": {

       "type": "app",

       "id": "887757be-5eda-48ce-b427-79dcc0705e91"

     },

     "destination": {

       "id": "e8a85db3-5189-48d8-566b-086c886d819e"

     }

   }

 ]

}'

And voila! Your app now has access to the external service with no app restart required.

Also, note that you can now fine-tune permissions to suit your requirements. In other words, access at the space level is not enabled by default. But you can still specify the source type as “space”, if you so choose. Just use the space guid in the source object to allow all apps in a space access the external service. Check out our Github page for API instructions.

ASGs and Dynamic Egress Policies: A Closer Look

Let us look at some scenarios and compare the workflows between ASGs and the new dynamic egress policy configuration. You’ll notice the new dynamic policies eliminate the restart step.

Scenario 1: Space A has 2 apps – Frontend and Backend. Backend application must access an external MySQL DB at 23.96.35.235 to retrieve data and send to the Frontend app.

ASG Workflow

Dynamic Egress Policy Workflow

App developer pushes the Backend app

App developer pushes the Backend app

App developer requests the security team to allow access from the Backend App to the external MySQL DB at 23.96.35.235

App developer requests the security team to allow access from the Backend App to the external MySQL DB at 23.96.35.235

Security team reviews the request and approves

Security team reviews the request and approves

Platform Operator creates an ASG for the MySQL DB and binds it to Space A

Platform Operator creates a destination object for the MySQL DB and creates an egress policy from the Backend application to the destination object

App developer restarts apps in Space A

           
A conceptual look at Scenario 1.

Now let’s make things a little more interesting with another common use case.

Scenario 2: Space A has 2 apps – Frontend and Backend. Backend application has an egress policy to access an external MySQL DB at 23.96.35.235 to fetch data. The DB is moved to a different data center and the new IP address is 216.58.195.78

ASG Workflow

Dynamic Egress Policy Workflow

App developer requests the security team to allow access from the Backend application to the new IP address 216.58.195.78 for the MySQL DB

App developer requests the security team to allow access from the Backend application to the new IP address 216.58.195.78 for the MySQL DB

Security team reviews the request and approves

Security team reviews the request and approves

Platform Operator creates a new ASG for the new IP address and binds it to Space A

Platform Operator updates the existing destination object that the Backend application has an egress policy to, with the new IP address of the MySQL DB

Platform Operator unbinds the old ASG with the old IP address from Space A and also deletes the ASG

App developer restarts apps in Space A

 You might be thinking, “Why didn’t you just improve ASGs?”

It’s fair question. For starters, the new dynamic egress feature uses the same policy server that defines container-to-container networking policies. So why do this instead of updating the ASG implementation?

There are two reasons:

  1. The policy server was originally created with a vision to encompass more than just container to container communication.

  2. Having two sources of truth for policies is confusing. The new implementation alleviates this risk.

What’s Next with Dynamic Egress Policies

We’re excited to launch dynamic egress policies. Now you have a solution to the application restart issue with ASGs, as well as a way to control egress policies at both the space and application levels. However, we’re still early in the development of this feature.

We have a few roadmap ideas in mind, and would love to hear your feedback:

  • The eventual deprecation of ASGs.

  • Explore FQDN-based egress policy enforcement.

  • Automate egress policy configuration during service binding.

  • Allow policy enforcement via the application manifest.

We’re also following the work being done by the Kubernetes community, in particular the Network Policy model based on labels and selectors.

Want to tell us what we should do next? You can do so via the comments here, or with a Github issue/feature request. We also invite you to join us on the Cloud Foundry #container-networking Slack channel!


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

  • No Related Posts

Create Customer Value Like FAANG: Continuous Delivery via Spinnaker

EMC logo


If you haven’t heard of FAANG, then you might know them by their household names: Facebook, Apple, Amazon, Netflix and Google. Together, they make up the collection of companies that routinely outpace the S&P 500. What is the secret to the excellent market performance of these companies?

In a September 17, 2018, blog from Forrester titled “Stay Ahead Of Your Customers With Continuous Delivery,” James Staten and Jeffrey Hammond (Vice Presidents and Principal Analysts at Forrester) correlate the success of Amazon, Netflix, and Google, in particular, to their ability to rapidly create customer value through continuous delivery:

“Continuous delivery means being prepared for fast incremental delivery of your conclusions about what new values and innovations will work best for your customers. And you must be prepared to be wrong and respond fast with incremental iterations to improve the alignment based on customer feedback.”

But I’m Not Like Netflix, You Say

Reaching the development and delivery models of a Netflix or Google might seem impossible for many enterprises today. After all, a Netflix doesn’t have the same concerns and level of risk as a bank, right?

But the reality we’ve seen at Pivotal is that large enterprise companies, including those in heavily regulated industries like finance and healthcare, are transforming their application development and delivery leveraging cloud-native approaches. For example, Cerner, an electronic medical records (EMR) company, transformed its infrastructure and application delivery to be more competitive using Pivotal Cloud Foundry (PCF) and Concourse.

Before the introduction of PCF, Cerner had already made strides to modernize its development processes, but it was “still stuck delivering new software to production once or twice a year. New features reached code completion, but then just sat in a staging environment until the next release.” It’s not uncommon for companies to adopt agile development practices but still lack the infrastructure, processes or tools to overcome the inertia of traditional release practices. That ability to continuously deliver value to your customers is still one of the larger transformation hurdles for enterprises today.

Don’t Let the Value of Your Code Depreciate

Continuous delivery was born as an extension to agile methods. After all, if you can’t get your code changes to your customers fast enough to provide value and get timely feedback, then why be agile in the first place? As one of Pivotal’s customers, CSAA Insurance, stated in a presentation at Cloud Foundry Summit: “Un-deployed code is at best a depreciating asset.

For every minute that you delay getting your code to production, the value of that asset decreases. And the risk of deploying to production actually increases at the same time. In fact, deploying small, constant changes to production reduces your risk and makes it easier to find issues if something does go wrong.

What does the ideal continuous delivery process look like then? It kicks off with code commit and continuous integration (CI) to get code built and tested. CI is typically a first area of automation that companies tackle on their path to continuous delivery—you could even say it’s a required first step.

At this stage, developers make sure their code is always at a quality level that is safe for release. By leveraging a development environment that is at parity with your production environment, you reduce the variability in application behavior as it progresses through the pipeline.

An automated hand-off from the CI process initiates a continuous delivery workflow. Here, speed must work hand and hand with safety and stability to deliver your applications to a production environment. This workflow may trigger jobs like security and compliance checks, or any other testing, before moving to production, where you’ll leverage automated deployment strategies like blue/green and canary deployments to reduce risk.

 

But that’s not the end for continuous delivery. It continues with the operation of the application in production where you can monitor for issues, remediate security vulnerabilities, and test your apps for resiliency. Basically, you are extending the feedback loops through production, which enables continuous improvement of your application.

Mastering Continuous Delivery with Spinnaker

If you’re ready to tackle the challenges of continuous delivery, why not build on the discoveries of the masters? Netflix invented Spinnaker to help it extend and enhance cloud deployments for its high-performance organization. These days, Spinnaker is a powerful open source, multi-cloud continuous delivery solution that helps teams release software changes with high velocity and confidence. It works with all major cloud platforms and enjoys broad support from the open source community:

 

 

The Spinnaker community is vibrant and growing, ensuring that key learnings from these organizations continue to be shared through tool enhancements.

5 Reasons to Use Spinnaker for Cloud Deployments

Spinnaker can become a key part of any modern engineering team by extending your CI processes into automated, opinionated continuous delivery pipelines optimized for the cloud.

 

Continuous delivery pipeline where CI hands off an artifact for Spinnaker to deploy, executing integration tests and other custom actions, and providing an up-to-date view of all applications in production.

Here are five reasons that Spinnaker is useful for high-performance teams for cloud deployments:

  1. Optimization for multi-cloud infrastructure. Spinnaker enables you to decouple the release pipeline from target cloud providers so that you can deploy the same application in the same way to multiple clouds and platform instances. This simplifies and standardizes deployments across multiple stages, teams and applications. Spinnaker also leverages the immutable infrastructure of the cloud to deploy in new environments every time an application change happens.

  2. Zero downtime deployments. Spinnaker automates sophisticated deployment strategies out of the box that help to reduce risk at production, like blue/green and canary deployments with easy rollbacks if issues occur. It can also manage progressive deployments (e.g., by time zones).

  3. Application inventory. Spinnaker maintains inventory of where applications and their instances are deployed across multiple environments, IaaS and runtimes—enabling continued feedback in production. It is built by querying cloud providers and is even available for applications not deployed by Spinnaker. This level of oversight shows the health of applications and allows you to take corrective actions, such as restarting a failing application or rolling it back. The inventory can also be used by other tools, like for finding security vulnerabilities in deployed code or troubleshooting issues in production.

  4. Pipeline compliance and auditability: Spinnaker keeps an audit trail of all changes to applications and infrastructure—basically answering who, what, when and why for developers, operators, and auditors. It also supports role-based access control, providing multiple authentication and authorization options, including OAuth, SAML, LDAP, X.509 certs, GitHub teams, Azure groups or Google Groups. You can even track manual intervention and approval gates.

  5. Extensibility with integrations. Spinnaker supports a broad ecosystem of modern tools, which enables an automated CD pipeline and advanced functions. You can extend your existing CI investments (e.g., Jenkins, Travis CI, Wercker, Concourse) to add advanced deployment strategies. You can send notifications through Slack, HipChat, email, and so on. You can enhance your application monitoring through integrations with Datadog, Prometheus, Stackdriver, etc. Plus, Spinnaker is cloud-provider-agnostic. The upshot is that Spinnaker can work with your current and future tech stack.
     

While the FAANG group may stand out as masters of continuous delivery to the cloud, it’s a capability that any team in any industry can adapt for their environments.

 

First, take the infrastructure out of the delivery risk equation with a cloud platform like PCF, making it dead simple for developers to deliver value-add code on stable, secure clouds. Then, a tool like Spinnaker can help teams manage continuous delivery in a safe, scalable way. It’s not about navigating oppressive change management processes on a long path to production. Rather, it’s about leveraging a fully automated, standard, stable delivery pipeline built for the cloud and designed to optimize the cycle time for getting feedback.
 

Want to learn more and see Spinnaker in action? Check out our webcast: Continuous Delivery to the Cloud: Automate Thru Production with CI + Spinnaker.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

  • No Related Posts

The First Open, Multi-cloud Serverless Platform for the Enterprise Is Here. Try out Pivotal Function Service Today!

EMC logo


I get a LOT of notifications. Everything from text messages with two-factor authentication codes, to Slack alerts from my team, to every mobile app telling me something I don’t actually need to know. But it’s indicative of a larger, positive trend in technology: event-driven systems. In such systems, something happens, and actions take place. These systems are always thriving with activity and responding to events in real-time by updating databases, training machine learning models, and yes, sending me notifications.

A function-as-a-service (FaaS) runtime—often referred to as a “serverless” system—is an ideal host for these event-driven systems. Deploy functions quickly with no infrastructure configuration. Define triggers that initiate an autoscaled function. And shut down functions when their work is complete.

Today, each public cloud offers powerful, albeit non-uniform, experiences for functions. But not everything is going to run in a single cloud. We hear that every day from the biggest companies in the world. So what’s your smartest path forward? Wait to use FaaS until you decide, if ever, to move all your critical workloads to a single cloud? That doesn’t sound like a great outcome for your developers or customers.

No, what you’re after is a consistent functions experience for your event-driven workloads on any IaaS with very little operational effort. That’s Pivotal Function Service, and it’s available as an alpha release today.

What is Pivotal Function Service?

Pivotal Function Service is a Kubernetes-based, multi-cloud function service. It’s part of the broader Pivotal vision of offering you a single platform for all your workloads on any cloud. Databases, batch jobs, web APIs, legacy apps, and event-driven functions, you name it. You deploy and operate these workloads the same way everywhere, thanks to the Pivotal Cloud Foundry (PCF) platform, comprised of Pivotal Application Service (PAS), Pivotal Container Service (PKS), and now, Pivotal Function Service (PFS).

Why does PFS matter? It’s open and gives you the same developer and operator experience on every cloud, public or private. It’s event-oriented with built-in components that make it easy to architect loosely coupled, streaming systems. It’s developer-centric with buildpacks that simplify packaging, and operator-friendly with a secure, low-touch experience running atop Kubernetes. And it’s from Pivotal, a company laser-focused on customer outcomes and helping you become amazing at designing, building, deploying, and operating software that your customers love.

West Corp runs in every cloud, including our own private cloud. That’s strategic to our business. Our developers build great software for our customers and I think the serverless paradigm opens up even more options for us, especially when available on-premises. I’m excited about Pivotal Function Service because it runs wherever we have infrastructure, and offers a consistent way for developers and operators to use event-driven computing.

– Thomas Squeo, CTO of West Corporation

PFS is Enterprise-Ready Knative

PFS is the first multi-cloud packaging of the Knative project, an initiative led by Google, Pivotal, and others. Knative forms the foundation of Project riff, a Pivotal-led open source project that extends Knative with developer and operator tooling. Riff simplifies the Knative installation experience, and adds key user experience components. The Knative team (including Pivotal) has been hard at work improving and hardening Knative since it was announced in July of 2018, and we’ve been keeping Project riff in lockstep.

“In July we introduced Knative, an open-source serverless platform based on Kubernetes that provides critical building blocks for modern serverless applications. Throughout the four months we have  seen tremendous enthusiasm from contributing companies, many of whom are furthering Knative as the serverless standard for hybrid and multi-cloud users,” said Eric Brewer, VP of Infrastructure and Google Fellow. “Pivotal has been a leading contributor to Knative since its founding. We are pleased to support the announcement of PFS leveraging Knative components as an outcome of our open- source collaboration.”

Knative and riff are now ready for you to try in the form of the PFS alpha release. So what does PFS include?

  • An environment for running, scaling, and updating functions. PFS takes function source code and deploys it. If a previous version of the function exists, the new version supersedes it, while PFS keeps the previous version available in case of rollback. The software-defined-networking layer handles all the route adjustments with no disruption. Functions scale down to zero instances when inactive, and scale up based on traffic. None of these activities require manual intervention, so this feels truly serverless to the developer.

  • Native eventing components that enable composable, reactive systems. Functions respond to events. Those events may come from outside in the form of HTTP(S) requests. Or, the completed work of one function may be the event that triggers another function. Consider the case when one function cleans up a customer’s submitted mailing address by fixing the postal code. Another function that stores the mailing address in your database waits for an event telling it that the address is properly formatted. These sorts of loosely coupled relationships are the hallmark of a dynamic architecture.

  • Easy installation on any Kubernetes environment. Install with a single pfs system install command. We’ve got installation docs today for PKS, GKE, and even a local Minikube. Even more Kubernetes targets (such as Azure Kubernetes Service and VMware Cloud PKS) are on the way!

  • Buildpacks that consistently and securely package functions. Developers just want to write their business logic, and not get stuck with a complex function packaging routine. With PFS, we’ve baked in Cloud Native Buildpacks which detect dependencies and automatically build your functions into runnable artifacts. The developers never interact with buildpacks; they simply issue a pfs function create command that points at their source code. But buildpacks are a game-changer for security-conscious operators. Because of the layered approach applied by buildpacks, you can transparently patch images without impacting the function itself.

Request access to the PFS alpha, today. Read the docs. Check out our booth at Kubecon for a live demo. And stay tuned for our soon-to-be-released O’Reilly book about Knative and serverless systems.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

  • No Related Posts

You’re Investing In .NET, and so Are We. Pivotal Is Now a Corporate Sponsor of The .NET Foundation.

EMC logo


.NET means a lot to me. It’s the first real programming framework I learned, nearly 20 years ago. And I still use it regularly to this day. Heck, I just wrote a book about it! So what was I thinking 2 ½ years ago when I joined a company that’s deeply invested in the leading Java framework, Spring? There’s no doubt that Pivotal makes Java development great, and designed Pivotal Cloud Foundry (PCF) to be the ideal place to run it. But back when I joined the company, there were already efforts underway to bring cloud-native practices to Windows and .NET. That’s only expanded since then. We’ve taken another major step forward today by becoming a corporate sponsor of the .NET Foundation.

The .NET Foundation is an independent, non-profit org that shepherds open-source .NET technologies and the broader .NET ecosystem. Today, the Foundation announced an open membership model, and Pivotal jumped at the chance to invest in the future of .NET. As a corporate sponsor, we’re going to sit on the advisory council, collaborate more closely with the .NET engineering team, and help grow the .NET community.

We’re not casual bystanders to the .NET ecosystem. Pivotal created Steeltoe, a popular library for bringing microservices patterns to .NET apps. This open-source project (donated to the .NET Foundation in 2017) applies to new or modernized .NET apps, either .NET Framework or .NET Core. Many large companies are running Steeltoe-powered apps in production, and we’ve got an exciting roadmap.

You can’t invest in .NET without also investing in Windows. While .NET Core on Linux is the future, .NET Framework on Windows is the present. Pivotal brought the infrastructure-as-code and immutable infrastructure patterns to Windows Server through Pivotal Cloud Foundry (PCF). PCF customers are deploying, managing, and updating fleets of Windows Servers almost entirely through automation.  On every cloud, public and private.

All this Windows Server automation is in service of accelerating software development. Developers push .NET apps with a single command and leverage buildpacks to create the package deployed to native Windows Containers in PCF. We’ve built buildpacks for both .NET Framework and .NET Core apps. That saves developers time, while standardizing the deployment process.

Our Windows and .NET engineers teams are some of our fastest growing units at Pivotal. They’re innovating and improving the experience for operators and developers. We recently spun up a .NET Developer Experience team whose sole purpose is making .NET apps great on PCF. They’ve already done some powerful work around mounting file shares, and remote debugging.

All this great .NET technology goes to waste if you’re not sure how to use it in your environment! Our App Transformation team has a .NET group which works with clients to scope their portfolios, figure out modernization strategies, and document the recipes that help you apply modern practices to your .NET apps. This team is full of .NET experts who understand how to bring new distributed systems concepts to your apps while getting these apps onto continuous delivery pipelines.

.NET has a bright future, and Pivotal is thrilled to play a bigger role in its success. Try out PCF today and discover the new way for .NET apps to thrive. You can use our hosted version for free and try out .NET Core apps, or deploy a full PCF which includes the Windows Server environment. Then check out my new book on modernizing .NET apps, or our many whitepapers that offer practical guidance on creating and maintaining .NET apps.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

  • No Related Posts

Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 4: Updating Ops Manager

Welcome to Part 4 of the Pivotal Cloud Foundry on AzureStack / ASDK tutorial.

Today I will cover the automated update of the opsmanager instance.

Make sure you have at least done Part 1 and Part 2 from:

Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 1: Deploy OpsManager

Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 2: Configure and Deploy BOSH Director using OpsManager

Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 3: Configure and Deploy PAS Tile using OpsManager

Once a new release of OpsManager is released, one may want to update the existing installation to get the latest Bosh Director.

The official Guide to upgrade the Operations amanger can be found here: https://docs.pivotal.io/pivotalcf/2-2/customizing/azure-om-upgrade.html

using my deploy-pcf .ps1 script and the deployment template that is provided in the Azurestack-Kickstart, that process is automated.

I created sort of a blue-green deploy, where you are always able to deploy 2 instances to flip between

To update the existing standard green deployment follow these steps:

1. update kickstart to latest release

using git, update to the latest release of kickstart. this will download the latest templates and release information

git pull

2. run the deployment script again with switch -OpsmanUpdate

run the same deployment script from Part 1, but add the -OpsmanUpdate switch.

if you used any customizations for ressourcegroup, storageaccounts or networks, pass that information as well

.pcfdeploy_pcf-opsman.ps1 -downloadpath e: -OPSMAN_SSHKEY $OPSMAN_SSHKEY -OpsmanUpdate -deploymentcolor blue

This will download the latest Version of the Opsman Image and start the deployment.

One may also want to specify a specific version using the -opsman_uri parameter.

Once the Deployment has finished, a second opsmanager instance with a new fqdn and public ip is deployed:

opsmanblue.png

3. Backup configuration from pcfopsmangreen

Sign in to your green opsmanager at https://pcfopsmangreen.local.cloudapp.azurestack.external/

In the top right, click on [accountname] –> Settings

settings.png

This will open the Setting Page

Go to the Export Settings tab and click on Export Installation Settings

export_settings.png

This will Download an Installation.Zip Package

4. Import Configuration on blue opsman

Open https://pcfopsmanblue.local.cloudapp.azurestack.external/ in your Browser

A new vanilla opsman will open.

vanilla.png

Click on Import existing Installation

Provide the installation.zip as well as the Passphrase given on initial installation, and click import

import.png

it will take a few moments and once the tempest-web has been restarted, you will have your opsman Configuration loaded to the blue operations manager.

auth_restart.png

once the log in screen is ready, use your known credentials to sign into opsmanager

sign in.png

you are now ready to apply the new configuration to the Bosh Director. Simply click on apply changes

newopsman.png

once the changes are applied and Bosh Director works correctly, you can delete your old [green] install from the management portal / cli

delete green.png

Related:

Getting started with Pivotal PCF on AzureStack ASDK Part 3: Configure and Deploy PAS Tile using OpsManager

In this part 3 of my Pivotal Cloud Foundry on Azure Stack series.

It is expected to complete Part1 and Part2 before continuing.

The Description assumes that the Cloud Config has been created with the ARM template in step 1 to create all required Loadbalancers and DNS Zones, as they will now be used in the PAS Config

Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 1: Deploy OpsManager

Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 2: Configure and Deploy BOSH Director using OpsManager

Download the PAS Image from the Pivotal Network

Browse to https://network.pivotal.io/products/elastic-runtime to download the latest version of Pivotal Application Service.

users of my pivposh Powershell Module can just use the command:

$token = Get-PIVaccesstoken -refresh_token <your refresh-token>Get-PIVSlug 'Pivotal Application Service (formerly Elastic Runtime)' | Get-PIVRelease | Select-Object -First 1 | Get-PIVFileReleaseId | where name -eq 'Pivotal Application Service' | Get-PIVFilebyReleaseObject -access_token $token

once the image is downloaded, open your OpsManager instance https://pcfopsmangreen.local.cloudapp.azurestack.external/ an click on Import a Product

upload_stemcell.png

Browse to the download location of the downloaded cf-2.x.y-build-z.pivotal file, adn selct the file.

The upload might take a few moments.

Once the Product Upload has finished, click on the ‘+’ Sign to add the Product Tile

add_pcf.png

Once the Tile has Added, click on the Pivotal Application Service Tile to configure the settings for PAS

configure_tile.png

We will now go through all required Settings Adjustment´s for an ASDK with the minimum Availability during Updates.

1. Assign Networks

Select the Management Network

Click Save

assign networks.png

2. Domains

For the System Domain, enter

system.pcfdemo.local.azurestack.external

For the Apps Domain, enter

apps.pcfdemo.local.azurestack.external

click save

domains.png

3. Networking

for Certificate Authorities Trusted by Router and HAProxy, click add on the right

networkking.png

enter a cert name and click on generate ssh certificate

generate RSA.png

copy in below domains and click generate

*.pcfdemo.local.azurestack.external,*.system.pcfdemo.local.azurestack.external,*.apps.pcfdemo.local.azurestack.external,*.uaa.system.pcfdemo.local.azurestack.external,*.login.system.pcfdemo.local.azurestack.external

generate.png

configure x-forwarded-client-cert header to be terminated at the router

xforwardat router.png

click Disable SSL certificate verification for this environment

disable_ssl.png

save

4. Application Security Groups

just confirm here with an ‘X’

click save

Application_control.png

5. UAA

Under SAML Service Provider Credentials, click on Generate RSA Certificate

SAML_Service_provider.png

In the Domain Field, enter your system login domain. Default for Kickstart is:

*.login.system.pcfdemo.local.azurestack.external

uaa_cert.png

Click generate and then save.

6. Configure the CredHub Server

Under Encryption Keys, Click “ADD”

encryption_keys.png

Enter a Key name, e.g. primary,

Enter a min. 20char long Key and mark as primary.

click save

encryption_keys_2.png

7. Internal MySQL

Just enter an e-mail address here.

We will configure the Loadbalancer in the Resource Config

mysql.png

Click save.

8. Errands

On the Errands Config, disable all Smoke tests:

– Smoke Test Errand

– App Autoscaler Smoke Test Errand

errands.png

9. Resource Config

The below table is a minimum configuration that allows for “HA” and blue/green deployments or Services / Resources

feel free to customize to your needs.

However make sure to enter the correct loadbalancer to Job assignments:

mysql-lb to MySQL Proxy Job

pcf-lb to Router Job

diegossh-lb to Diego Cell Job

Also, if you want to use CredHub Service Broker Tile, specify 2 CredHub Job´s

resource config.png

Click save and go back to the Installation Dashboard

10. Applying Changes

Click on Apply Changes.

apply_changes.png

The Installation of the PAS VM´s will start. this may take several Hours.

Be patient and Monitor the Job´s.

At this time you also might want to watch the Jobs directly from the Opsman Director vm using bosh commands.

Sign In to the opsman vm:

ssh -i opsman ubuntu@pcfopsmangreen.local.cloudapp.azurestack.external

With the Environment created in Getting started with Pivotal Cloud Foundry on AzureStack ASDK Part 2: Configure and Deploy BOSH Director using OpsManager, login to the bosh director

bosh -e asdk login

View the running tasks with

bosh -e asdk tasks

The first task running will be the bosh director stemcell deployment update.

stemcell.png

now try to get details on tasks. test the –cpi or –debug switches, an also view history tasks ..

or continue viewing the Web Output

tasks.png

Once the Uploading Releases Task and Credential Migration has finished, the Installation of the PAS Service will start.

First the Deployment will be created, named cf-[guid]

You can view the Deployment now using

bosh -e asdk deployments

deployments.png

This is the point where the CPI will start to deploy all the VM´s and availability Sets to your Environment.

You can now monitor your Resource Group from the AzureStack Portal to see created resources.

11. Logging in to the AppsManager

After the PAS Tile has deployed successfully, you can log in to the AppsManager.

Therefor, you need to get the Credentials of the admin from the OpsManager Dashboard.

Click on the PAS Tile

PAS_TILE.png

Click on the Credentials TAB

credentials.png

Search for UAA and retrieve the Admin Credentials from the link

uaa_creds.png

Now it is time to Log Into your PCF System using:

https://apps.system.pcfdemo.local.azurestack.external/

pas login.png

after signing in you should be connected to the system org

system_org.png

Related:

Portfolio Optimization by the Numbers

EMC logo


In the fall of 2017, Microsoft, Pivotal and Dell EMC began a collaboration focused around enabling digital transformation through rapid adoption of Pivotal Cloud Foundry for the large enterprise. This collaboration brings together Pivotal’s Cloud Foundry (PCF) with Microsoft Azure and Azure Stack and Dell EMC’s consulting services. PCF is an effective platform as a service for modern application development and containerization. Microsoft’s Azure services, complimented by Azure Stack for on premises cloud computing, provides rapid scalability and seamless portability. Dell EMC Consulting Services wraps the solution with experience and know-how to scale PCF adoption across an enterprise, adopt DevOps practices, enable CI/CD pipelines and drive transformation globally on cloud platforms.

Reduce Costs and Optimize Your Portfolio

Through our collaboration we’ve been able to share priorities, benefits and challenges faced and discuss how, together, we can offer customers a more complete and efficient approach to adoption and transformation across the enterprise.

At Dell Technologies World, on Wednesday May 2nd at noon (Pacific), representatives from each of the companies will join a panel discussion titled “Enterprise Digital Transformation: By The Numbers” facilitated by Kaushik Arunagiri, VP Americas Consulting Services, Dell EMC that will discuss the potential value of large scale transformational savings and entertain questions from the audience.

Panelists

Chip Kalfaian, Principal Consultant and Global Discipline Lead Application Portfolio Optimization, Dell EMC Consulting

Chip has led the global Application Portfolio Optimization team at Dell EMC for three years. During this time a lot has changed. Whereas three years ago it was sufficient to recommend public versus private cloud, today CIO’s are faced with a robust range of options for their future app dev and infrastructure needs. Chip is responsible for providing his customers with expert services enabled through diagnostic and analytical tools to help answer these questions and build financial models to support them. Chip is responsible for the global harmonization of application profiling services across Dell EMC and helps drive innovation of new solutions like the Application Modernization Strategy and Roadmap solution released this past February.

Claude Lorenson, Global Cloud Platform Channel Marketing, Microsoft

Claude Lorenson is a Senior Product Marketing Manager in the Azure Hybrid Marketing team as part of the Cloud + Enterprise group at Microsoft. Lorenson’ s current function is around the development of the IHVs and System Integrator partner eco-system to drive integration of the Microsoft Cloud Platform with new, innovative hardware solutions such as Azure Stack.

Lorenson holds a Ph.D. in Solid State Physics from The Ohio State University and a Technology Management MBA from the University of Washington.

Michael Wood, Director Alliances, Pivotal

Starting out in the US Army, Michael jumped into a career focused on business and market changes through the proper leverage of technology, and, more specifically, software as a competitive differentiator. For the better part of 18 years, he has partnered with companies of all shapes and sizes as they have matured through generations of technical and organizational change. As a founding member of Pivotal, Michael has become immersed in not only the latest technical approaches to solve company challenges, but also the organizational and psychological incentives that drive innovation and success for the companies that he serves.


Join Kaushik Arunagri (Dell EMC, VP Americas Consulting Services) at Dell Technologies World on Wednesday, May 2 at 12 p.m. for the session Enterprise Digital Transformation: By The Numbers,” to learn why Enterprise adoption of Pivotal Cloud Foundry requires aggressive re-platforming of legacy applications and new thinking, behavior, tools and processes for your green field. Come meet our panel comprising of Dell, Microsoft, and Pivotal as we discuss how, through our alliance, we help bring significant ROI to large enterprise customers.

The post Portfolio Optimization by the Numbers appeared first on InFocus Blog | Dell EMC Services.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

Tapping the Power of the Cloud: Lessons from our VMware-based Hybrid Cloud Deployment

EMC logo


In a key next step in its historic merger of Dell and EMC (which created Dell Technologies), Dell IT is in the process of integrating its infrastructure in the cloud to modernize, automate and transform its IT operations.

Six months ago, Dell IT took on the challenge of integrating and modernizing the hundreds of legacy applications from both Dell and EMC still running on traditional infrastructure in existing data centers.

The result is a new hybrid cloud solution that combines Dell EMC hardware platform and VMware software platform to create a modern, software-defined data center that lets Dell IT cut costs and deliver infrastructure on demand. Our cloud model allows us to leverage both on-premises and off-premises IT assets in an agile way to ramp up self-service delivery and accelerate digital innovation.

Shaping Our New Cloud       

Like most organizations pursuing a digital agenda, we realize that today’s IT will not succeed if we don’t change the way we do business to become an on-demand service provider with the automation, agility, and flexibility to give our users what they want; when they want it.

That requires a cloud strategy to transform our more than 3,000 applications and leverage modern data center technologies such as software-defined storage, networking and security, automation, and self-service capabilities.

To define and execute our cloud strategy, we brought together all the aspects of our data centers, infrastructure and platforms under a single team, Cloud Infrastructure Services. Since Dell and EMC each had a somewhat different cloud strategy, our team decided to build a brand new, legacy-agnostic hybrid cloud rather than trying to retrofit existing cloud infrastructure.

Our cloud is built on Dell EMC Converged and Hyper-Converged Infrastructure that leverages the VMware Validated Design for Software-Defined Data Center.

On top of this hardware and software platform, we are offering two key services to provide application owners and developers with a choice of how to add cloud capabilities to their apps: Platform as a Service (PaaS) and Infrastructure as a Service (IaaS and IaaS+).

PaaS is built on Pivotal Cloud Foundry (PCF), an application development platform designed to simplify writing and deploying modern cloud native apps. This service is for developers who want to write new apps or rewrite existing apps in a way that conforms to cloud-native design standards that maximize the use of cloud features. Using the cloud native framework results in a micro services-based lighter-weight app that can be readily moved on or off premises.

IaaS+ is for existing apps whose owners are not ready to rewrite them to meet the requirements of PCF but who still want to deploy them in a more cloud-enabled format to take advantage of cloud features such as software-defined storage and software defined network. The bulk of our apps fall into this category.

Our IaaS+ is built on VMware’s vRealize Automation, a cloud automation tool. At its core, using IaaS+ means an app is still deployed as a virtual machine (VM) but it sits on top of a software defined data center layer. It is therefore fully automated and leverages the software defined abstraction that separates it from the hardware layer, enabling faster provisioning, more efficient data center space utilization and seamless hardware upgrades.

A Measured Migration and a New Role

Over time, we want to migrate our entire application footprint from our legacy environments to one of these two new environments. However, accomplishing such a transition needs to be a gradual process. We are on track to deploy 25 percent of our infrastructure to the cloud by the end of this year and replace our entire current infrastructure with the software-defined platform within four years.

Central to our approach is tying application modernization to our end-of-service-life initiative. As components serving a particular app—the operating system or compute or storage— reach the end of operating service, our goal is to use that to drive the move of that app to one of these two cloud platforms – PaaS and IaaS+.

Leaving it up to app developers to determine which cloud service they choose is part of our effort to become more of a platform agnostic, competitive service provider. The idea is not to tell our users what they can and cannot do. The message we want to drive is around standardization: “These are the services we provide; have a nice day. We are not the IT police; you pay for it, you get it.”

In fact, at the end of our migration to the cloud, we want the users to be able to log into a portal (service catalog) and choose the services they need without IT even being involved. Our IT effort will instead be refocused on enabling automation, writing code for new services, and monitoring and managing capacity. With a software defined model, we can also better control capacity by leveraging third-party cloud providers as needed to handle demand surges and be more planned and prescriptive.

Lessons Learned In the Cloud

Here are some insights that might help your organization with its journey to the cloud:

  1. Don’t try to force-fit legacy infrastructure into new frameworks. As you modernize, build in flexible options that work toward software defined features.
  2. Automation is key. Standardize everywhere to drive that goal.
  3. Shifting from reactive to proactive IT is one of the biggest pieces of digital transformation.
  4. Breaking down silos and learning to work collectively is crucial in your cloud journey.
  5. Change needs to go beyond infrastructure to include more agile processes, self service delivery approach and flexible capacity.
  6. Consumers will also need to think differently, adapting to prepackaged offerings rather than high-touch customized services of the past.

Summary

Our journey to a new hybrid cloud is critical to our infrastructure integration as we continue our IT evolution as a combined Dell EMC IT organization. Across the IT industry, modernizing, automating and transforming IT to enable digital transformation and deliver self-service capabilities is essential for our survival in an increasingly automated, consumer-driven cloud services landscape.


Join Paul DiVittorio and Wissam Halabi at Dell Technologies World on Monday, April 30 at 3:00 p.m. and Wednesday, May 2nd at 12:00 p.m. for the session Dell IT’s Journey: Lessons from Our VMware-based Hybrid Cloud Deployment to hear the story of how Dell IT realized its Hybrid Cloud vision to help accelerate Digital innovation.

The post Tapping the Power of the Cloud: Lessons from our VMware-based Hybrid Cloud Deployment appeared first on InFocus Blog | Dell EMC Services.


Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

2018 – a Cloudy Forecast With a Strong Chance of Success

EMC logo


The biggest source of climate uncertainty is white and fluffy. How clouds will respond to global warming is the largest source of uncertainty in climate change predictions. In the past, discussion about cloud forecasts were only about the weather, and today there is strong chance that it could be about Cloud computing and business agility.

Up in the clouds, we go. A whole new meaning of ‘The Cloud’ has entered our language. When most of us wake up in the morning, we check our mobile phones (normally next to our beds) for the weather forecast, and we see what our friends are up to on Facebook or Twitter. If you’ve ever wondered where those pictures uploaded to on Facebook or Twitter, the answer leads us to a relatively new direction—the Cloud. From a business perspective, the reality is that if you’re not in the Cloud, you’re in for stormy weather, so there is wisdom in getting your head out of the clouds and putting some of your business into it.

Dell Technologies’ recent Digital Transformation Index found that more than half (52%) of the 4,000 business leaders surveyed have already experienced significant disruption to their organizations because of digital technologies. Strikingly, nearly the same amount (48%) can’t predict what their industry will look like in just three years’ time. The pressure is clearly on for organizations to become more efficient and readily adopt and carve competitive advantages from emerging technologies. To improve performance and capitalize on digital innovations, they need to adopt more agile, cloud operating models. It’s my belief that 2018 will be a tipping point for how organizations choose and apply cloud technologies, and these are my top predictions.

Cloud Frameworks Incorporating Multi-Cloud and Hybrid Cloud Will Become the New Standard

I’m no meteorologist, but in 2018, I predict more balanced clouds. More organizations will become multi-cloud and many will adopt hybrid clouds, enabling them to opportunistically place workloads in the right environment based on cost, performance, and governance policy.  Looking at their mix of public and private cloud options, IT leaders will need to develop a decision framework and policies for when to use which cloud. These policies should not only factor the technical merits and limitations of the cloud platforms, but also the requirements and costs of each workload.  For example, an overall cloud policy might specify that long-running production workloads will remain in an on-premises private cloud, along with workloads tied to data sets located on-premises in a non-cloud environment.  Conversely, transient workloads (workloads with significant outbound traffic) or workloads requiring geographic dispersion could be targeted for public cloud.  The choice of which public cloud is then defined in a multi-cloud policy. To further delineate, on-premises cloud instances may be paired with off-premises counterparts, such as a VMware Ready System paired with VMware Cloud on AWS, or Dell EMC Cloud for Microsoft Azure Stack paired with Microsoft Azure. Certain high-value workloads, like SAP, may target a purpose-built cloud like Virtustream. One thing is for sure, organizations will need to consider cloud decision frameworks to maximize efficiency and cost.

Virtual Machines and Containers Will Both Be Essential

I see organizations driving toward digital transformation by embracing both virtual machines and containers.  In past years, many organizations that developed their own software stack to running them on virtual machines, based on their well-understood usage and implementation. Now that concepts such as 12-factor applications and micro-services have become mainstream, containers are a natural fit for developing and running these applications.  Sure, they may still be run inside of virtual machines, but the benefits of a container-based environment generally outweigh the challenges of building out an environment.  Pivotal Cloud Foundry (PCF) is an example of a Platform-as-a-Service product that simplifies the development and deployment of modern, cloud-native applications. PCF enables organizations to consume container technologies simply while addressing complex lifecycle management tasks. Solutions like the Dell EMC Pivotal Ready System make it easy to get this up and running and include guidance for complex design considerations, like high availability, disaster recovery, networking and security.

Software-Defined Will Be the Preferred Technology for On-Premises Private Cloud

This 2018 forecast should not come as a surprise. The software-defined data center (SDDC) has been a generally accepted concept for years, made up of several software-based technologies, such as virtualization, software-defined networking, and software-defined storage. Despite this, the technology is still considered new. IT professionals have built their careers on well-known products and technologies, and anytime a new technology is introduced to the market, it takes time for it to be accepted. It first needs to be proven as a viable option for production workloads before professionals are willing to bet their career – and their livelihood – on what could benefit their organization. Though just as virtualization became the obvious choice for most workloads previously hosted on dedicated bare-metal servers, IT professionals have come to realize that software-defined networking and storage can also be adopted as modern alternatives to their traditional counterparts.

This year, I expect software-defined will take the lead as the preferred technology for on-premises production private cloud. Purpose-built storage arrays will still have a place in the data center, being used primarily for high-value workloads, those with very large data sets, and in places where software-defined storage doesn’t make sense.  Software-defined networking can’t replace the physical switch in the data center, but it can certainly make life easier for IT admins with simplified routing, network micro-segmentation, and integration with cloud management software. The objection of complexity to implement and maintain the SDDC will be overcome by turnkey private cloud solutions like Dell EMC’s VMware Ready System. Built on Dell EMC VxRack SDDC hyper-converged infrastructure, it leverages the capabilities of VMware’s Cloud Foundation to maintain the lifecycle of the software-defined components using automation and simplifying adoption of these technologies in an on-premises private cloud.  Simplified lifecycle management, coupled with delivery on pre-built infrastructure in a fully validated and tested solution, eliminates the challenges of realizing a private cloud built on a fully software-defined infrastructure.

Cloud-Driven Digital Transformation

With a multi-cloud operating model in place, organizations are well equipped to realize cost synergies, improve performance, and accomplish their digital business initiatives. Of course, in order to achieve digital transformation, companies must evolve more than just their technology. Establishing an organizational culture that’s conducive to and embraces innovation is the first step. Expanding across clouds necessitates the destruction of silos and heightened levels of collaboration to derive actionable data insights. No matter where you are on your multi-cloud or digital journey, Dell EMC is here to help to simplify the process.

The speed of technological innovation today is unprecedented—and only increasing. Regardless of industry, those who embrace it are best positioned to be digital leaders and change the world for the better!

Read more about Dell Technologies’ 2018 predictions for the next era of technology here.



ENCLOSURE:https://blog.dellemc.com/uploads/2018/01/Kash_FY18_Predictions_Direct2DellEMC_1000x500.jpg

Update your feed preferences


   

   


   


   

submit to reddit
   

Related:

Can container be configured to ping Cloud Foundry app or IBM intranet address?

I’m an IBM employee and created a Kubenetes cluster via IBM Cloud. I deploy a container in this cluster which I want to connect with a web app which is already deployed in Cloud Foundry. My container is able to ping internet like google or salesforce but it cannot ping this web app. This web app is reachable within IBM office network so I think the problem is essentially how to configure container to ping IBM intranet?

Any help would be appreciated.

Related: