|
Re: SSH access to CF app instances on Diego
Benjamin Black
matt,
could you elaborate a bit on what you believe ssh access to instances is for? b On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote: My concern is the default behavior. |
|
|
|
Re: SSH access to CF app instances on Diego
James Bayer
thanks for sharing your view matt. i happen to disagree. i've talked to
many more conservative enterprise operations people and they really don't want to enable snowflakes by default. since we plan to have both global and per-space/per-app configuration options, administrators can make the choice for each installation if they want to enable writable containers without tainted container recycling. each vendor that distributes cloud foundry could have their own opinionated default. i'd love to hear from others in the oss community what the default should be in cf-release. i can tell you that the vast majority of customers and people i've spoken with feel it should be "recycle tainted containers by default" and only able to be turned off with an exception to the rule from an administrator. On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote: My concern is the default behavior. -- Thank you, James Bayer |
|
|
|
Re: service discovery
James Bayer
i would encourage you to consider a circuit breaker pattern like hystrix
which will have graceful degradation if a remote endpoint is unavailable because it has not started yet, has too many failures, is network segmented, etc.. On Thu, Jun 25, 2015 at 9:02 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote: No. My endpoints don't change. I envision having a number of 12 factor -- Thank you, James Bayer |
|
|
|
Re: SSH access to CF app instances on Diego
Matthew Sykes <matthew.sykes@...>
My concern is the default behavior.
toggle quoted message
Show quoted text
When I first prototyped this support in February, I never expected that merely accessing a container would cause it to be terminated. As we can see from Jan's response, it's completely unexpected; many others have the same reaction. I do not believe that this behavior should be part of the default configuration and I do believe the control needs to be at the space level. I have have already expressed this opinion during Diego retros and at the runtime PMC meeting. I honestly believe that if we were talking about applying this behavior to `bosh ssh` and `bosh scp`, few would even consider running in a 'kill on taint mode' because of how useful it is. We should learn from that. If this behavior becomes the default, I think our platform will be seen as moving from opinionated to parochial. That would be unfortunate. On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:
you can turn the "restart tainted containers" feature off with --
Matthew Sykes matthew.sykes(a)gmail.com |
|
|
|
Re: Soliciting feedback on a UX change for route services
I was about to suggest a similar UX for expressing a list of route
toggle quoted message
Show quoted text
services, by relying on params ordering cf update-route DOMAIN [-n HOST] (-s 'service instance' )* cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting Besides, If the MVP does not include support for multiple route services, route service implementers might be able to experiment with supporting arbitrary params as a way for users to specify fine grain options, possibly ordered cf create-service large-grain-route-service -p '{ "caching": true, "ssl_only": true, "rate_limit": 3 }' +1 for Mike's suggestions to allow for some route services to be implemented in an upfront LB such as no router. This might address the latency and availability concerns in the initial MVP ("route services to forward requests back through the LB and GoRouter") Lastly, it seems important that route services be able to output logs that end up being associated with the app that receive the associated traffic (e.g. cache hit or cache miss for a specific incoming request). With route services being associated to routes (and not being bound to app instances anymore), I'd like to re-iterate the suggestion I made in the design document (on Feb 17) to have the gorouter include the app_id in the headers of the signed request it sends to route service(s). This will allow for a route service with log_emiter scope to add entries to the proper app through loggregator/doppler. Of course, this also means that when a route is associated to multiple apps, the load balancing decision among app is made prior to sending traffic to route service(s). I'd imagine the app_id could be propagated in the signed request headers when going through route services and finally reaching the gorouter before hitting the app (as to preserve the stateless nature of gorouter). Guillaume. On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
This is great. Thank you, Mike. _______________________________________________This is interesting. Could you flesh this out for me? What use cases doI would imagine you could bind a service to a route any time you want to |
|
|
|
Re: service discovery
Sumanth Yamala
No. My endpoints don't change. I envision having a number of 12 factor stateless applications getting deployed using CF push (java buildpacks). Some of these stateless apps need to talk to each other and so the need for service discovery.
Currently we use Consul - i.e. each 12 factor app registers itself with Consul and apps needs to re-discover another app. We feed in the Consul end point to all the apps as an environment variable. Using environment variables has a dependency issue that certain applications that have not been started yet, would not be visible to applications that have already started...but a HashMap of apps and its route could itself serve as a repository to discover other applications as long as the app can get access to the hash map or we persist this hash map as a KV store in Consul. Thanks all for your inputs. Sumanth ________________________________ From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of James Bayer <jbayer(a)pivotal.io> Sent: Thursday, June 25, 2015 11:42 PM To: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-dev] service discovery can you describe the architecture of your applications? do the endpoints change often after some mircoservices have been started? your app needs some way to look up other network endpoints it needs. there are several ways to do this. * use environment variables - which is provided just-in-time when the container starts - this might be a URL for example, that routes to the CF router that might be bound to several different apps, but all the source app needs to know is the destination route represented by a FQDN and optional context path * use a service - either user a service broker or provided service that provides information to the apps that bind to it, might be a URL and authentication information, this information is also put in the apps env variables * use something like the spring cloud config service that can distribute information to clients dynamically post container start [1] * use something like the spring cloud eureka service from netflix oss that can provide dynamic information to clients using netflix ribbon, also takes in updates post container start [2] [3] [1] https://www.youtube.com/watch?v=bJvReWt2jLc [2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html [3] http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote: micro-service architecture. Yes - would like for applications to discover the URL of other applications deployed in CF . Consul is what I use right now - was wondering if CloudFoundry had something in this space. Service brokers I thought are only for stateful components like a database, Consul..can it be used for stateless components as well? Thanks, Sumanth ________________________________ From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> <cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>> on behalf of John Wong <gokoproject(a)gmail.com<mailto:gokoproject(a)gmail.com>> Sent: Thursday, June 25, 2015 10:35 PM To: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-dev] service discovery What's the requirement that your application need to discover other application? Did you mean somethibg like say microservice architecture and you want to know the url available and any metadat / property of some service / app you depend on? One way is via service broker. You can use also use consul and token to do ACL based resource retrieval/discovery and I have seen this apptoach (actually today at a local tech talk). On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote: Hi, In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach. Thanks in advance. Thanks, Sumanth -- Sent from Jeff Dean's printf() mobile console _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev -- Thank you, James Bayer |
|
|
|
Re: service discovery
James Bayer
can you describe the architecture of your applications? do the endpoints
change often after some mircoservices have been started? your app needs some way to look up other network endpoints it needs. there are several ways to do this. * use environment variables - which is provided just-in-time when the container starts - this might be a URL for example, that routes to the CF router that might be bound to several different apps, but all the source app needs to know is the destination route represented by a FQDN and optional context path * use a service - either user a service broker or provided service that provides information to the apps that bind to it, might be a URL and authentication information, this information is also put in the apps env variables * use something like the spring cloud config service that can distribute information to clients dynamically post container start [1] * use something like the spring cloud eureka service from netflix oss that can provide dynamic information to clients using netflix ribbon, also takes in updates post container start [2] [3] [1] https://www.youtube.com/watch?v=bJvReWt2jLc [2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html [3] http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote: micro-service architecture. -- Thank you, James Bayer |
|
|
|
Re: service discovery
John Wong
Service brokers I thought are only for stateful components like adatabase, Consul..can it be used for stateless components as well? Well here is a way to look at it. You can have consul to discover a bunch of cassandra nodes in a cluster, and you can remove a node from ever being contacted by your application if said node is not responsive. Another example is nginx behind ha proxy or a bunch of apps behind ha proxy, and you can remove app/webservers went down from ha proxy config dynamically with some consul engineering. So what exactly makes something stateless in your case? I think if you can provide us a concrete use case that'd be very helpful (because you can do stateless with like DNS load balancing / behind ELB / HA Proxy etc). John On Thu, Jun 25, 2015 at 10:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote: micro-service architecture. |
|
|
|
Re: Document for service broker api version 2.5
James Bayer
looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html 2.5 should only have been incremental changes and should be backward compatible with other 2.x versions. when you say it doesn't work, do you have details of an interaction that shows the problem? On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <nguyenhongchau(a)gmail.com> wrote: Hi all, -- Thank you, James Bayer |
|
|
|
Re: Java Buildpack v3.1
Christopher B Ferris <chrisfer@...>
+1
toggle quoted message
Show quoted text
Cheers, Christopher Ferris IBM Distinguished Engineer, CTO Open Cloud IBM Software Group, Open Technologies email: chrisfer(a)us.ibm.com twitter: @christo4ferris blog: http://thoughtsoncloud.com/index.php/author/cferris/ phone: +1 508 667 0402 On Jun 25, 2015, at 4:46 PM, James Bayer <jbayer(a)pivotal.io> wrote: |
|
|
|
Re: service discovery
Sumanth Yamala
micro-service architecture.
Yes - would like for applications to discover the URL of other applications deployed in CF . Consul is what I use right now - was wondering if CloudFoundry had something in this space. Service brokers I thought are only for stateful components like a database, Consul..can it be used for stateless components as well? ? Thanks, Sumanth ________________________________ From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of John Wong <gokoproject(a)gmail.com> Sent: Thursday, June 25, 2015 10:35 PM To: Discussions about Cloud Foundry projects and the system overall. Subject: Re: [cf-dev] service discovery What's the requirement that your application need to discover other application? Did you mean somethibg like say microservice architecture and you want to know the url available and any metadat / property of some service / app you depend on? One way is via service broker. You can use also use consul and token to do ACL based resource retrieval/discovery and I have seen this apptoach (actually today at a local tech talk). On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote: Hi, In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach. Thanks in advance. Thanks, Sumanth -- Sent from Jeff Dean's printf() mobile console |
|
|
|
Document for service broker api version 2.5
NGUYEN Hong Chau <nguyenhongchau@...>
Hi all,
I'm trying to implement a service broker for cf-release v210. I implemented my service broker in cf-release v207 based on this service broker project <https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>. Now cf-release v210 using api version 2.5 for broker and my code doesn't work. I'm looking up docs for api version 2.5 but find no document available yet. Does anyone implement a service broker for api version 2.5? And could you explain me the modifications I must do for the new broker version? Thanks in advance. -- Nguyen Hong-Chau |
|
|
|
Re: service discovery
John Wong
What's the requirement that your application need to discover other
toggle quoted message
Show quoted text
application? Did you mean somethibg like say microservice architecture and you want to know the url available and any metadat / property of some service / app you depend on? One way is via service broker. You can use also use consul and token to do ACL based resource retrieval/discovery and I have seen this apptoach (actually today at a local tech talk). On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote:
Hi, --
Sent from Jeff Dean's printf() mobile console |
|
|
|
service discovery
Sumanth Yamala
Hi,
In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach. Thanks in advance. Thanks, Sumanth |
|
|
|
Re: How to get files from crash apps
Jack Cai
I shared one simple technique in this slide [1], see Page 20. Basically you
toggle quoted message
Show quoted text
can add ";sleep 1d" to the start command of your application, to keep the container around for one day. You can remove the "--no-route" option if your application listens on the HTTP port in time during start up. Jack [1] https://www.slideshare.net/greensight/10-common-errors-when-pushing-apps-to-cloud-foundry On Thu, Jun 25, 2015 at 2:58 AM, James Bayer <jbayer(a)pivotal.io> wrote:
i'm not sure if this is the right property or not, maybe dieu knows: |
|
|
|
Re: SSH access to CF app instances on Diego
James Bayer
you can turn the "restart tainted containers" feature off with
toggle quoted message
Show quoted text
configuration if you are authorized to do so. then using scp to write files into a container would be persisted for the lifetime of the container even after the ssh session ends. On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com> wrote:
On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:after executing a command, concluding anwill --
Thank you, James Bayer |
|
|
|
Re: SSH access to CF app instances on Diego
Jan Dubois <jand@...>
On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:
after executing a command, concluding anWhat is the purpose of being able to copy a file into an instance if the instance is restarted as soon as the file has been received? Cheers, -Jan |
|
|
|
SSH access to CF app instances on Diego
Eric Malm <emalm@...>
Dear CF community,
I'm pleased to announce that the Diego team is nearing completion of our initial track of work to enable SSH access to app instances running on Diego. We've recently published some preliminary versions of the Diego-SSH CLI plugin at https://github.com/cloudfoundry-incubator/diego-ssh/releases, and I've posted some instructions for developers and operators in the Diego Design Notes, at https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/ssh-access-and-policy.md . For a CF+Diego deployment with SSH already enabled and publicly routable, accessing a CF app instance over SSH is as simple as running cf ssh <app-name> after installing the CLI plugin. The plugin also supports a -i option to target other instance indices and a -L option to forward local ports, and we expect to add a cf scp command soon as well for bidirectional file transfer. It's also possible to use the built-in ssh and scp clients on Linux and OS X to access instances. For more details on how to use those clients, please see the design notes linked above or the more extensive documentation for the CF and Diego authenticators on the Diego-SSH repository: https://github.com/cloudfoundry-incubator/diego-ssh. If you're using the steps in the diego-release README <https://github.com/cloudfoundry-incubator/diego-release/blob/develop/README.md> to deploy it and CF to BOSH-Lite, this SSH functionality should all just work for you automatically. If you're operating on a different infrastructure, you will have a few values to configure in your BOSH deployment manifests, and, depending on your environment, a load balancer to provision in front of Diego's SSH proxies. Again, the design notes cover the basic manifest properties and infrastructure setup required to give access to CF app instances. Version 0.1.2 of the Diego-SSH plugin also provides commands for adjusting the SSH policy on CF apps and spaces through Cloud Controller. In particular, users can employ those commands to enable and disable SSH both on an individual app and on an entire space. Operators can separately choose whether to allow SSH access via a BOSH-configurable parameter in Cloud Controller's configuration. Finally, we realize that unfettered SSH access to instances is something of a double-edged sword: while it enables interactive inspection and experimentation inside an app instance, it also makes it possible to build 'snowflake' instances that will melt whenever the platform restarts them. To prevent the creation of such snowflakes, we propose to implement a restart policy for CF app instances: after executing a command, concluding an interactive session, or copying a file into an instance, that instance will be restarted. Forwarding ports and copying files out will not trigger a restart, though. Cloud Controller admins will be able to opt individual spaces out of this restart behavior, to allow developers greater inspection of and experimentation on their apps in those spaces. We haven't yet introduced this behavior, but it's among the last pieces of work we intend to do before we consider this initial batch of SSH work complete. If you're interested in the progress of the remaining stories we currently have planned for SSH access, please look for them in the Diego tracker <https://www.pivotaltracker.com/n/projects/1003146> with the 'ssh' label. Thanks, Eric Malm, CF Runtime Diego PM |
|
|
|
Re: Soliciting feedback on a UX change for route services
Mike Youngstrom <youngm@...>
Thanks Shannon,
toggle quoted message
Show quoted text
Though James' suggestion would work if the the service bound to a route doesn't use a proxy then the order become irrelevant. It would be inconvenient to have to list all of the services bound to a route every time I wanted to add or remove a route service. I would propose something along the lines of the way buildpack position is managed. #Bind Route Service cf bind-route-service DOMAIN SERVICE [-n HOST] [-i POSITION] #List route services and their current order cf route-services DOMAIN [-n HOST] Then the user can specify a position if it is important to them but use the default if they don't care. Mike On Thu, Jun 25, 2015 at 4:04 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
This is great. Thank you, Mike. |
|
|
|
Re: Soliciting feedback on a UX change for route services
Shannon Coen
This is great. Thank you, Mike.
toggle quoted message
Show quoted text
FWIW, James had the following suggestion update-route could be used to associate multiple routes, and express their chain order. We're not fixed on this UX. We'll consider this more carefully when we get closer to the CF CLI work. cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances'] Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
This is interesting. Could you flesh this out for me? What use cases doI would imagine you could bind a service to a route any time you want to |
|
|