Hello guys,
I am loving the new meta-data service, it’s just working fast/easily… I am wondering if it would be possible to store custom data, maybe with:
PUT http://rancher-metadata/2015-07-25/data/toto/key -d {“hello” : “world”}
So it would be possible to share data easily accross all containers (such as secret password, API key, github access-token etc…).
Thanks you,
No, it’s a simple read-only server and the appropriate config is pushed down from the server to each Network Agent for the containers on that host.
We don’t currently publish it as a standalone image but I suppose if you really wanted we could, and then you could run your own copy with arbitrary answers. There are many other more standard distributed or centralized key-value stores you could use though.
It would be super cool if we could set our own custom values on the server (heck maybe even with the rancher GUI). It would eliminate the need to use an external key value store for environment configuration stuff since rancher already has a fully capable one!
@johnculviner you can add custom key/value pairs into metadata. See: http://docs.rancher.com/rancher/latest/en/rancher-services/metadata-service/#adding-user-metadata-to-a-service
Or did I misunderstand what you meant?
Sure that certainly works for one service (could just use environment variables on the docker-compose to accomplish something similar too I think).
If we could externalize these key/value pairs outside of rancher-compose or docker-compose then it could be used for global environment level configuration like: external API endpoints, databases etc. that may apply to all of your services. This allows me to avoid hardcoding “config stuff” in all my various services and rely on them being in one place for all containers/stacks in a given environment.
Thoughts?
for external endpoints, I tend to setup service aliases, and link to them from my services.
that way it is also easy to swap end-points without re-deploying.
Thats a good idea. Do you have an example you can share or a link to the concept?
I might end up going the Consul route or something it’s just too bad that rancher basically has this feature built in it’s just not exposed for editing on the server. Stuff like this has been called “environment variables” forever: how about letting us set official POSIX “environment variables” for a rancher environment in a global manner (or just let me get at the variables via the REST API from within my application?).
I think something like this would really seal the deal on rancher being an all-in-one comprehensive solution to “dockering” without bolting on a bunch of other stuff I really don’t want to have to manage which of course is the reason for going with Rancher in the first place (for me at least). Thoughts @vincent @cjellick or am I missing a feature?
Sorry for the long delay, missed your follow-up question.
Here’s some screen-grabs of part of our setup…
we have some “default” services (as aliases to other services, in rancher, or external) in a default “global” stack that we link to for unmet dependencies at deploy time:
then in a app stack, it may look like:
so we can change what rabbitmq and redis point to, for instance, without having to update or redeploy the services using them.
this is just the tip of the ice-berg, but should give you ideas for how we do it… (in addition to this, we do have quite a bit of external components for configuration and management to drive our CD pipeline, that is, we don’t deploy using the UI, or manually at all (except for service aliases, haven’t fixed that yet), we only setup what we want to deploy where, and tweak some configuration where needed and watch it spin up)…
