Early usage questions

Hi there,

Thanks for setting this up. From a bit of a play, I had a few questions:

It's unclear with a docker application what port is bound via EXPOSE, and if that expects HTTP or HTTPs: (  https://docs.cloudfoundry.org/devguide/deploy-apps/push-docker.html#port_config )

It seems like it's undocumented how to set a custom argument for running a container: ( https://docs.cloudfoundry.org/devguide/deploy-apps/push-docker.html#start_command )

There isn't nfs or other storage volume support in the cf instance

There seems to be no way to check out an applications configuration? After I did the docker cf push I can't ... get out the parameters or manifest to edit them?

It's unclear how during scaling each instance of the container will have environment variables, or volumes allocated, especially for a server that internally manages it's replication process (rather than relying on say external postgres etc).

How do you make a service that would be suitable for the marketplace, IE an LDAP server or IDM system that people could then use, and has proper autoscaling (Especially an active-active system like LDAP with it's own replication).

Anyway, thanks for your time!

Comments

  • Hi,

    glad to hear you've been having fun - that's what it's all about at the end of the day ;-)

    I haven't been able to check on running Docker containers in cf yet so I'll have to let someone else chime in on that.

    We currently don't have persistent storage in the sandbox. Can you tell us a little more about what drives this need for you? We'll be happy to consider if that's something we can include as things evolve.

    I have no experience how attached volumes would work during scaling, but the environment (at least as far as "normal" variables go - the ones set by CF are in some cases a different story) is shared across all instances. I.e. if you set a variable and then add another instance, that instance will see the variable too. I'm currently doing some experiments with variables that are set by the application at runtime but I assume that's the same.

    A note on apps that handle scaling themselves: this is a somewhat problematic use case since CF is kind of built around the idea that the platform would take care of auto-scaling the app. If you want to use some built-in autoscaling functionality instead, you'll either have to ensure the app has a sufficiently large "resource envelope" defined in the manifest so that it has the room to scale, or you would have to build some functionality for handling the CF API from the app to drive the scale-out. This is a good example of a situation where it may be necessary to adapt an app so that it can fully benefit from running on a platform. Imagine you could just get rid of the code parts that handle the scaling and write the entire app as if it was a single instance always.

    Creating a service that can be offered in the Marketplace requires an implementation of the Open Service Broker API. It may be possible to hook up an LDAP server with the Universal Service Broker (see https://github.com/SUSE/cf-usb) but I haven't investigated this in detail.

    All in all you're raising a couple of fairly interesting points, let me know if you want to dig in more and I'm happy to tag along.

Sign In or Register to comment.