Today the mechanism for bundling pieces together is to write a template
(which is what that example uses) to help share configuration information
between components (eg name of the database service, username/password).

in the future we intend to have a mechanism to allow you to link things
together which will abstract some of that manual configuration.

but it will never be the case that everything in a project will be able to
just cross-communicate, depending what information needs to be shared.
They can access each other, and for example today the _SERVICE_HOST env
variable is automatically injected (though that is going to go away
upstream), but for an application to know *which* service it should use for
a DB, and what username/password to use, that will always require some
explicit indication provided.


On Mon, Feb 15, 2016 at 1:51 PM, Candide Kemmler <[email protected]>
wrote:

> Allright will do, thanks! One thing strikes me is that I have created
> deployment/build configs, services, persistent volume (claims) etc all
> separately in a project and hoped that all these objects would happily talk
> to each other. This examples starts with an `oc new-app` command that
> bundles all the pieces together. Could that be the thing I missed.
> Obviously, I'm not all clear on what an "app" means vs a "project"...
>
> On 15 Feb 2016, at 18:08, Ben Parees <[email protected]> wrote:
>
> Take a look at this sample ruby app which defines a mysql service and
> makes use of it (no route, just a service):
>
> https://github.com/openshift/ruby-hello-world
>
> the template to deploy it is here:
>
> https://github.com/openshift/origin/blob/master/examples/sample-app/application-template-stibuild.json
>
>
> On Mon, Feb 15, 2016 at 12:04 PM, Candide Kemmler <[email protected]
> > wrote:
>
>> I deployed a mysql service with the provided cartridge. It works and I
>> can connect to it  using the Terminal on the pod itself. However, it seems
>> to be inaccessible from other pods. I see that there is no route defined
>> for it; however I don't want to expose it to the outside world, only inside
>> my project.
>>
>> Also, AFAIK, mysql has its own settings on how it wants to allow outside
>> connections to it and I don't know what the defaults are...
>>
>> I have the same problems with a couchdb pod that I deployed in the same
>> project: perfectly running inside its own container but invisible from the
>> outside.
>>
>> Also, this documentation
>> <https://docs.openshift.org/latest/architecture/additional_concepts/networking.html>
>>  seems
>> to indicate that there is a .cluster.local domain available from within the
>> cluster, but all attempts to ping my services using the provided schemes
>> are failing.
>>
>> This means I am only able to contact my services using my
>> custom-configured wildcard domain (*.apps.example.com) but outside of
>> it, nothing is working like I would expect.
>>
>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
>


-- 
Ben Parees | OpenShift
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to