Architectures:
Deployment Time:
Centralized Logging:
Centralized Logging Capability
uuid from end to end.
Run Time:
Architectures;
Showing posts with label Cloud Foundry. Show all posts
Showing posts with label Cloud Foundry. Show all posts
Friday, May 13, 2016
Thursday, August 6, 2015
Research about Docker Support in Pivotal Cloud Foundry
Knowledge Sharing:
1. Diego builds out the new runtime architecture for Cloud Foundry, replacing the DEAs and Health Manager.
2. Diego also helps bring a cleaner container abstraction with Warden, the container technology developed originally for Cloud Foundry.
3. Diego does not run Docker containers. It has an interface to run compatible images in Warden containers. For the end user, there is very little difference. You can push a Docker image into Warden. Diego is designed to run different backends.
4. The droplet execution manager (DEA), health manager and some of the cloud controller are now taken care of by Diego, Whelan said
5. Docker is important for the future of PaaS. Every new PaaS has a strong connection to Docker. To ignore Docker containers ina PaaS would be suicidal.
6. Diego does that (admittedly with more specificity) and a lot more: containerization, log aggregation, routing, health-management, etc
7. Each App Lifecycle provides a set of binaries that manage an application lifecycle that specific to Cloud Foundry.
8. One of the selling points of Diego, is that you support various container backends, such as Windows or Docker.
Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
References:
http://htmlpreview.github.io/?https://raw.githubusercontent.com/cloudfoundry-incubator/diego-design-notes/master/clickable-diego-overview/clickable-diego-overview.html
http://thenewstack.io/docker-on-diego-cloud-foundrys-new-elastic-runtime/
http://i1.wp.com/blog.cloudfoundry.com/wp-content/uploads/2013/02/fa2_fig021.jpg
http://blog.pivotal.io/pivotal-cloud-foundry/features/cloud-foundry-container-technology-a-garden-overview
http://www.activestate.com/blog/2014/09/cloud-foundry-diego-explained-onsi-fakhouri
1. Diego builds out the new runtime architecture for Cloud Foundry, replacing the DEAs and Health Manager.
2. Diego also helps bring a cleaner container abstraction with Warden, the container technology developed originally for Cloud Foundry.
3. Diego does not run Docker containers. It has an interface to run compatible images in Warden containers. For the end user, there is very little difference. You can push a Docker image into Warden. Diego is designed to run different backends.
4. The droplet execution manager (DEA), health manager and some of the cloud controller are now taken care of by Diego, Whelan said
5. Docker is important for the future of PaaS. Every new PaaS has a strong connection to Docker. To ignore Docker containers ina PaaS would be suicidal.
6. Diego does that (admittedly with more specificity) and a lot more: containerization, log aggregation, routing, health-management, etc
7. Each App Lifecycle provides a set of binaries that manage an application lifecycle that specific to Cloud Foundry.
8. One of the selling points of Diego, is that you support various container backends, such as Windows or Docker.
Functionality is being added to enable end-users to push Docker images directly into a Cloud Foundry cluster running Diego.
References:
http://htmlpreview.github.io/?https://raw.githubusercontent.com/cloudfoundry-incubator/diego-design-notes/master/clickable-diego-overview/clickable-diego-overview.html
http://thenewstack.io/docker-on-diego-cloud-foundrys-new-elastic-runtime/
http://i1.wp.com/blog.cloudfoundry.com/wp-content/uploads/2013/02/fa2_fig021.jpg
http://blog.pivotal.io/pivotal-cloud-foundry/features/cloud-foundry-container-technology-a-garden-overview
http://www.activestate.com/blog/2014/09/cloud-foundry-diego-explained-onsi-fakhouri
Wednesday, August 5, 2015
Research about installing Pivotal Cloud Foundry
Knowledge Sharing:
1. PCF Installation Virtual Appliance is known as Ops Manager
2. Binding a service instance to your application triggers credentials to be provisioned for the service instance and delivered to the application runtime in the VCAP_SERVICES environment variable.
3. Managed Services are defined as having been integrated with Cloud Foundry via APIs and enable end users to provision reserved resources and credentials on demand.
4. For local development we recommend using Bosh Lite to deploy your own local instance of Cloud Foundry.
5. A stemcell is a VM template with an embedded BOSH Agent.
6. “Cloud Foundry v2” they are referring to the version of the cloud controller API. The services API is versioned independently of the cloud controller API.
7. How a service is implemented is up to the service provider/developer. Cloud Foundry only requires that the service provider implement the service broker API. A broker can be implemented as a separate application, or by adding the required http endpoints to an existing service.
8. Pivotal Web Services was born as a place agile teams could rapidly update and scale applications across multiple environments and let Cloud Foundry maintain their applications’ health in production.
9. PWS is Pivotal’s public Platform-as-a-Service offering. PaaS systems let you host apps by pushing them to a service rather than having to configure and maintain separate installations of web servers, load balancers and so on. PWS is a hosted installation of the open-source Cloud Foundry project, to which Pivotal is a primary contributor.
10. bosh-lite uses Vagrant and a Warden BOSH CPI to deploy Cloud Foundry in a VM. A single VM is created using Vagrant, then each Cloud Foundry component is deployed in its own Warden container using BOSH. bosh-lite supports VMware Fusion, Virtualbox, and AWS
11. In the previous release of Cloud Foundry, Micro Cloud Foundry was a useful tool for Cloud Foundry developers or anyone with a need to run a local instance of Cloud Foundry. Micro Cloud Foundry has not been upgraded for Cloud Foundry v2.
References:
http://docs.pivotal.io/pivotalcf/getstarted/#system
https://upload.wikimedia.org/wikipedia/commons/9/96/VMware_vSphere_in_the_Enterprise_diagram_v1.0.gif
http://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.install.doc/GUID-78933728-7F02-43AF-ABD8-0BDCE10418A6.html
http://stackshare.io/stackups/heroku-vs-pivotal-web-services
http://yourstory.com/2012/07/tutorial-getting-started-with-cloud-foundry-part-13/
Local Instance of Cloud Foundry:
https://github.com/cloudfoundry/bosh-lite
https://github.com/cloudfoundry/warden
http://yourstory.com/2012/07/tutorial-getting-started-with-cloud-foundry-part-13/
Docker vs Warden:
http://jamie-wang.iteye.com/blog/2175918
https://gist.github.com/syslxg/5a2ef3cb54f77d6c6572
Challenges:
1. Service Instances
2. Bind Service Instances
3.
Buildpacks:
https://spring.io/blog/2015/04/27/binding-to-data-services-with-spring-boot-in-cloud-foundry
http://blog.altoros.com/creating-a-custom-cloud-foundry-buildpack-from-scratch-whats-under-the-hood.html
Research about deploying application in Pivotal Cloud Foundry
Research Results:
1. Org – Use this to name a cluster of applications that are logically grouped together.
2. Space – Use each space as a separate environment for your application. An Org has multiple spaces, which serves as a convenient way to manage different environments for your applications.
My Cloud Foundry account has an Org called all-apps with a space called staging.
3. Each space role applies only to a particular space.
4. With auto-reconfiguration, Cloud Foundry creates the database or connection factory bean itself, using its own values for properties such as host, port, username and so on. For example, if you have a single javax.sql.DataSource bean in your application context that Cloud Foundry auto-reconfigures and binds to its own database service, Cloud Foundry does not use the username, password and driver URL you originally specified. Instead, it uses its own internal values. This is transparent to the application, which really only cares about having a relational database to which it can write data but does not really care what the specific properties are that created the database. Also note that if you have customized the configuration of a service, such as the pool size or connection properties, Cloud Foundry auto-reconfiguration ignores the customizations.
5. At Cloud Foundry, apps are hosted in spaces, and a space belongs to an org.
6. Every app in Cloud Foundry will have a unique name. Names are made of alphanumeric characters without any space.
Samples:
https://docs.cloudfoundry.org/buildpacks/ruby/sample-ror.html
https://spring.io/guides/gs/sts-cloud-foundry-deployment/
References:
http://pivotallabs.com/deploying-jruby-rails-application-cloud-foundry/
http://docs.pivotal.io/pivotalcf/concepts/roles.html
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html
https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html
https://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html#cloud-profiles-java
http://theblasfrompas.blogspot.com/2014/06/pivotal-cloud-foundry-installed-lets.html
http://naturalprogrammer.com/2015/02/06/pivotal-cloud-foundry-spring-boot-web-applications/
http://www.cloudworkshop.org/cloudfoundry/quickstartguide_20150423.pdf
https://blog.appdynamics.com/java/monitoring-apps-on-the-cloud-foundry-paas/
http://www.eclipse.org/community/eclipse_newsletter/2015/april/article3.php
http://support.run.pivotal.io/entries/30758809-not-able-to-push-the-application-
1. Org – Use this to name a cluster of applications that are logically grouped together.
2. Space – Use each space as a separate environment for your application. An Org has multiple spaces, which serves as a convenient way to manage different environments for your applications.
My Cloud Foundry account has an Org called all-apps with a space called staging.
3. Each space role applies only to a particular space.
4. With auto-reconfiguration, Cloud Foundry creates the database or connection factory bean itself, using its own values for properties such as host, port, username and so on. For example, if you have a single javax.sql.DataSource bean in your application context that Cloud Foundry auto-reconfigures and binds to its own database service, Cloud Foundry does not use the username, password and driver URL you originally specified. Instead, it uses its own internal values. This is transparent to the application, which really only cares about having a relational database to which it can write data but does not really care what the specific properties are that created the database. Also note that if you have customized the configuration of a service, such as the pool size or connection properties, Cloud Foundry auto-reconfiguration ignores the customizations.
5. At Cloud Foundry, apps are hosted in spaces, and a space belongs to an org.
6. Every app in Cloud Foundry will have a unique name. Names are made of alphanumeric characters without any space.
Samples:
https://docs.cloudfoundry.org/buildpacks/ruby/sample-ror.html
https://spring.io/guides/gs/sts-cloud-foundry-deployment/
References:
http://pivotallabs.com/deploying-jruby-rails-application-cloud-foundry/
http://docs.pivotal.io/pivotalcf/concepts/roles.html
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html
https://docs.cloudfoundry.org/devguide/deploy-apps/deploy-app.html
https://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html#cloud-profiles-java
http://theblasfrompas.blogspot.com/2014/06/pivotal-cloud-foundry-installed-lets.html
http://naturalprogrammer.com/2015/02/06/pivotal-cloud-foundry-spring-boot-web-applications/
http://www.cloudworkshop.org/cloudfoundry/quickstartguide_20150423.pdf
https://blog.appdynamics.com/java/monitoring-apps-on-the-cloud-foundry-paas/
http://www.eclipse.org/community/eclipse_newsletter/2015/april/article3.php
http://support.run.pivotal.io/entries/30758809-not-able-to-push-the-application-
Subscribe to:
Posts (Atom)







