We have an IT ivnentory app, where all our machines are registered. We want
to chef get info from that app via API getting json files and use that json
files as attributes.
Is there any way to do this “right”, i.e: Caching that results in order to
not overload the inventory web app with queries on each node…
thanks!
–
Si necesitas una máquina para hacer algo y no la compras al final te darás
cuenta de que has pagado lo mismo y no tienes la máquina.–Henry Ford
We have an IT ivnentory app, where all our machines are registered. We
want to chef get info from that app via API getting json files and use that
json files as attributes.
Is there any way to do this "right", i.e: Caching that results in order to
not overload the inventory web app with queries on each node...
thanks!
--
Si necesitas una máquina para hacer algo y no la compras al final te darás
cuenta de que has pagado lo mismo y no tienes la máquina.--Henry Ford
the amount of data requested from the inventory server per node
the number of nodes in your chef infrastructure
the frequency of converging
the reliability of the inventory app
Initially we had a similar situation except that we merged data in
from N different external sources. Today we only have one sources of
configuration data - chef data bags. What we tend to do now is
synchronise data from the external applications into the chef server
as data bag items. The advantage of this that the chef runs no longer
rely on external services that may or may not meet reliability or
performance requirements. It does add a bit more effort to synchronize
data in but it is well worth it. About the only painful thing is that
we have to take special care to ensure that the data appears in the
search index before kicking of a chef run if it is part of an
orchestration workflow
We have an IT ivnentory app, where all our machines are registered. We
want to chef get info from that app via API getting json files and use that
json files as attributes.
Is there any way to do this "right", i.e: Caching that results in order to
not overload the inventory web app with queries on each node...
thanks!
--
Si necesitas una máquina para hacer algo y no la compras al final te darás
cuenta de que has pagado lo mismo y no tienes la máquina.--Henry Ford
Looks like a comon sense way, was my first thougth but then i started to
think about keeping data sync, cron schedules to write those databags and
updating the data bags on the chef-server..
the amount of data requested from the inventory server per node
the number of nodes in your chef infrastructure
the frequency of converging
the reliability of the inventory app
Initially we had a similar situation except that we merged data in
from N different external sources. Today we only have one sources of
configuration data - chef data bags. What we tend to do now is
synchronise data from the external applications into the chef server
as data bag items. The advantage of this that the chef runs no longer
rely on external services that may or may not meet reliability or
performance requirements. It does add a bit more effort to synchronize
data in but it is well worth it. About the only painful thing is that
we have to take special care to ensure that the data appears in the
search index before kicking of a chef run if it is part of an
orchestration workflow
We have an IT ivnentory app, where all our machines are registered. We
want to chef get info from that app via API getting json files and use
that
json files as attributes.
Is there any way to do this "right", i.e: Caching that results in order
to
not overload the inventory web app with queries on each node...
thanks!
--
Si necesitas una máquina para hacer algo y no la compras al final te
darás
cuenta de que has pagado lo mismo y no tienes la máquina.--Henry Ford
On both ways, there are a question mark: How often commit that changes on
databags to the chef-repo? each update? each XX minutes? manually?
We ended up to doing it on a case by case basis - ultimately it
depends on the volatility of the external configuration data and how
important it is to align with the chef infrastructure. For example our
"release" process basically updates version in external system which
triggers a synchronize to chef which triggers an orchestration flow
(which may trigger a rollback to previous version in the external
system if the flow fails). While some of our user data is synchronized
once per night.