Transcription
ComplimentsofCloud FoundryThe Definitive GuideDEVELOP, DEPLOY, AND SCALECEEFRSRETPAHDuncan C. E. Winn
Full-stack monitoringfor Cloud FoundryGet full visibility into your microservicesResolve app and cluster problems quickly with AIAuto-monitor every user, every app, everywhereMonitoring redefined. AI powered, full stack, automated.Try Dynatrace for free: dynatrace.com/trial
Cloud Foundry:The Definitive GuideThis excerpt contains Chapters 1–3, 6, and 9 of the bookCloud Foundry: The Definitive Guide. The complete book isavailable at www.safaribooksonline.com and through otherretailers.Develop, Deploy, and ScaleDuncan C. E. WinnBeijingBoston Farnham SebastopolTokyo
Cloud Foundry: The Definitive Guideby Duncan C. E. WinnCopyright 2017 Duncan Winn. All rights reserved.Printed in the United States of America.Published by O’Reilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions arealso available for most titles (http://oreilly.com/safari). For more information, contact our corporate/insti‐tutional sales department: 800-998-9938 or corporate@oreilly.com.Editors: Brian Anderson and Virginia WilsonProduction Editor: Melanie YarbroughCopyeditor: Octal Publishing, Inc.Proofreader: Christina EdwardsIndexer: Judy McConvilleInterior Designer: David FutatoCover Designer: Karen MontgomeryIllustrator: Rebecca DemarestFirst EditionMay 2017:Revision History for the First Edition2017-05-22:First ReleaseThe O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Cloud Foundry: The Definitive Guide,the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.While the publisher and the author have used good faith efforts to ensure that the information andinstructions contained in this work are accurate, the publisher and the author disclaim all responsibilityfor errors or omissions, including without limitation responsibility for damages resulting from the use ofor reliance on this work. Use of the information and instructions contained in this work is at your ownrisk. If any code samples or other technology this work contains or describes is subject to open sourcelicenses or the intellectual property rights of others, it is your responsibility to ensure that your usethereof complies with such licenses and/or rights.978-1-491-93243-8[LSI]
Table of Contents1. The Cloud-Native Platform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Why You Need a Cloud-Native PlatformCloud-Native Platform ConceptsThe Structured PlatformThe Opinionated PlatformThe Open PlatformSummary1244552. Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Undifferentiated Heavy LiftingThe Cloud Operating SystemDo MoreThe Application as the Unit of DeploymentUsing cf push Command to DeployStagingSelf-Service Application Life CycleThe Twelve-Factor ContractRelease Engineering through BOSHBuilt-In Resilience and Fault ToleranceSelf-Healing ProcessesSelf-Healing VMsSelf-Healing Application Instance CountResiliency Through Availability ZonesAggregated Streaming of Logs and MetricsSecurityDistributed System SecurityEnvironmental Risk Factors for Advanced Persistent ThreatsChallenge of Minimal Change78910111112131415161616161719192020iii
The Three Rs of Enterprise SecurityUAA ManagementOrganizations and SpacesOrgsSpacesResource AllocationDomains Hosts and RoutesRouteDomainsContext Path–Based RoutingRolling Upgrades and Blue/Green DeploymentsSummary2123232424252525262626273. Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Component OverviewRouting via the Load Balancer and GoRouterUser Management and the UAAThe Cloud ControllerSystem StateThe Application Life-Cycle PolicyApplication ExecutionDiegoGarden and runCMetrics and LoggingMetron AgentLoggregatorMessagingAdditional ComponentsStacksA Marketplace of On-Demand ServicesBuildpacks and Docker ImagesInfrastructure and the Cloud Provider InterfaceThe Cloud Foundry GitHub 94040404. Diego. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Why Diego?A Brief Overview of How Diego WorksEssential Diego ConceptsAction AbstractionComposable ActionsLayered Architectureiv Table of Contents434647484951
Interacting with DiegoCAPIStaging WorkflowThe CC-BridgeLogging and Traffic RoutingDiego ComponentsThe BBSDiego Cell ComponentsThe Diego BrainThe Access VMThe Diego State Machine and Workload Life CyclesThe Application Life CycleTask Life CycleAdditional Components and ConceptsThe Route-EmitterConsulApplication Life-Cycle BinariesPutting It All 8815. Buildpacks and Docker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Why Buildpacks?Why Docker?Buildpacks ExplainedStagingDetectCompileReleaseBuildpack StructureModifying BuildpacksOverriding BuildpacksUsing Custom or Community BuildpacksForking BuildpacksRestagingPackaging and DependenciesBuildpack and Dependency ble of Contents v
CHAPTER 1The Cloud-Native PlatformCloud Foundry is a platform for running applications, tasks, and services. Its purposeis to change the way applications, tasks, and services are deployed and run by signifi‐cantly reducing the develop-to-deployment cycle time.As a cloud-native platform, Cloud Foundry directly uses cloud-based infrastructureso that applications running on the platform can be infrastructure unaware. CloudFoundry provides a contract between itself and your cloud-native apps to run thempredictably and reliably, even in the face of unreliable infrastructure.If you need a brief summary of the benefits of the Cloud Foundry platform, thischapter is for you. Otherwise, feel free to jump ahead to Chapter 2.Why You Need a Cloud-Native PlatformTo understand the business reasons for using Cloud Foundry, I suggest that youbegin by reading Cloud Foundry: The Cloud-Native Platform, which discusses thevalue of Cloud Foundry and explores its overall purpose from a business perspective.Cloud Foundry is an “opinionated” (more on this later in the chapter), structuredplatform that imposes a strict contract between the following: The infrastructure layer underpinning it The applications and services it supportsCloud-native platforms do far more than provide developers self-service resourcesthrough abstracting infrastructure. Chapter 2 discusses at length their inbuilt fea‐tures, such as resiliency, log aggregation, user management, and security. Figure 1-1shows a progression from traditional infrastructure to Infrastructure as a Service(IaaS) and on to cloud-native platforms. Through each phase of evolution, the value1
line rises due to increased abstraction. Your responsibility and requirement to config‐ure various pieces of the software, middleware, and infrastructure stack in support ofyour application code diminish as the value line rises. The key is that cloud-nativeplatforms are designed to do more for you so that you can focus on delivering appli‐cations with business value.Figure 1-1. Cloud-native platform evolutionCloud-Native Platform ConceptsIn the Preface, I pointed out that Cloud Foundry’s focus is not so much what a plat‐form is or what it does, but rather what it enables you to achieve. It has the potentialto make the software build, test, deploy, and scale cycle significantly faster. It removesmany of the hurdles involved in deploying software, making it possible for you torelease software at will.Specifically, here’s what the Cloud Foundry platform offers:2 Chapter 1: The Cloud-Native Platform
Services as a higher level of abstraction above infrastructureCloud Foundry provides a self-service mechanism for the on-demand deploy‐ment of applications bound to an array of provisioned middleware and routingservices. This benefit removes the management overhead of both the middlewareand infrastructure layer from the developer, significantly reducing thedevelopment-to-deployment time.ContainersCloud Foundry runs all deployed applications in containers. You can deployapplications as container images or as standalone apps containerized by CloudFoundry. This provides flexibility. Companies already established with Dockercan deploy existing Docker images to Cloud Foundry. However, containerizingapplications on the user’s behalf offers additional productivity and operationalbenefits because the resulting container image is built from known and vettedplatform components. This approach allows you to run your vulnerability scansagainst your trusted artifacts once per update. From this point, only the applica‐tion source code requires additional vulnerability scanning on a per deploymentbasis. Essentially, there is less to check on a per deployment basis because all ofyour supporting artifacts have already been vetted.Agile and automationYou can use Cloud Foundry as part of a CI/CD pipeline to provision environ‐ments and services on demand as the application moves through the pipeline to aproduction-ready state. This helps satisfy the key Agile requirement of gettingcode into the hands of end users when required.Cultural shift to DevOpsCross-cutting concerns is a well-understood concept by developers. AdoptingCloud Foundry is ideally accompanied by a cultural shift to DevOps, meaningthat you need to break down traditional walls, team silos, and ticket-based handoffs to get the most benefit from it.Microservices supportCloud Foundry supports microservices through providing mechanisms for inte‐grating and coordinating loosely coupled services. To realize the benefits ofmicroservices, a platform is required to provide additional supporting capabili‐ties; for example, Cloud Foundry provides applications with capabilities such asbuilt-in resilience, application authentication, and aggregated logging.Cloud-native application supportCloud Foundry provides a contract against which applications can be developed.This contract makes doing the right thing simple and will result in better applica‐tion performance, management, and resilience.Cloud-Native Platform Concepts 3
Not all cloud-native platforms are the same. Some are self-built and pieced togetherfrom various components; others are black-boxed and completely proprietary. TheCloud Foundry cloud-native platform has three defining characteristics: it is struc‐tured, opinionated, and open. I’ll examine each of these traits in the following sec‐tions.The Structured PlatformWithin the platform space, two distinct architectural patterns have emerged: struc‐tured and unstructured: Structured platforms provide built-in capabilities and integration points for keyconcerns such as enterprise-wide user management, security, and compliance.With these kinds of platforms, everything you need to run your applicationsshould be provided in a repeatable way, regardless of what infrastructure you runon. Cloud Foundry is a perfect example of a structured platform. Unstructured platforms have the flexibility to define a bespoke solution at agranular level. An example of an unstructured platform would involve a “buildyour own platform” approach with a mix of cloud-provided services and home‐grown tools, assembled for an individual company.Structured platforms focus on simplifying the overall operational model. Rather thanintegrating, operating, and maintaining numerous individual components, the plat‐form operator just deals with the one platform. Structured platforms remove all theundifferentiated heavy lifting: tasks that must be done—for example, service discov‐ery or application placement—but that are not directly related to revenue-generatingsoftware.Although structured platforms are often used for building new cloud-native applica‐tions, they also support legacy application integration where it makes sense to do so,allowing for a broader mix of workloads than traditionally anticipated. The struc‐tured approach provides a much faster “getting started” experience with lower overalleffort required to operate and maintain the environment.The Opinionated PlatformWhen you look at successful software, the greatest and most widely adopted technol‐ogies are incredibly opinionated. What this means is that they are built on, andadhere to, a set of well-defined principles employing best practices. They are provento work in a practical way and reflect how things can and should be done when notconstrained by the baggage of technical debt. Opinions produce contracts to ensureapplications are constrained to do the right thing.4 Chapter 1: The Cloud-Native Platform
Platforms are opinionated because they make specific assumptions and optimizationsto remove complexity and pain from the user. Opinionated platforms are designed tobe consistent across environments, with every feature working as designed out of thebox. For example, the Cloud Foundry platform provides the same user experiencewhen deployed over different IaaS layers and the same developer experience regard‐less of the application language. Opinionated platforms such as Cloud Foundry canstill be configurable and extended, but not to the extent that the nature of the plat‐form changes. Platforms should have opinions on how your software is deployed,run, and scaled, but not where an application is deployed; this means that, withrespect to infrastructure choice, applications should run anywhere.The Open PlatformCloud Foundry is an open platform. It is open on three axes: It allows a choice of IaaS layer to underpin it (Google Cloud Platform [GCP],Amazon Web Services [AWS], Microsoft Azure,
ties; for example, Cloud Foundry provides applications with capabilities such as built-in resilience, application authentication, and aggregated logging. Cloud-native application support Cloud Foundry provides a contract against which applications can be developed. This contract makes doing the right thing simple and will result in better applica‐
