I'm planning to design a distributed hardware monitoring and controlling like provisioning user Environments,decommission, push updates etc. i herd puppet supports these features. Please let me know if there is a better freeware out there ? . or a good puppet reference.
Related
Is there a way I can get comeplete user information using puppet code.
Like group id, id, password expiration details, etc.
May be using facter.
You can run any command using facter and centralize it using Puppet, so technically is possible, but is not advised (as correctly stated by boxdog)
If you do that, the fact collected will be huge (as .json) and Puppet will have to store that in the DB and your performance is going to be slow down.
Think of Puppet's facter as the temperature for your AC. You need the temperature fact to be collected by the configuration management tool so that you can drive decision in order to turn on or off the heating. The reason you collect facts is to drive configuration decisions. In order to monitor your infrastructure you need a System Monitoring tool and not a Configuration Management tool.
If you want to collect this information one time, Puppet has support for:
Bolt
MCollective (deprecated for newer versions, available on <= 2018.1)
As DataStax will discontinue the OpsCenter (http://docs.datastax.com/en/opscenter/5.2/opsc/opscPolicyChanges.html), which was rather okay for monitoring purposes and the daily management tasks,
I'm searching for a valid alternative. The list of tools under http://www.planetcassandra.org/related-projects/ does not really look attractive.
Is there a meaningful or even better way? OpsCenter already had very limited functionality for OSS. Any recommendations?
Cassandra exposes own metrics via JMX, so you can use any tool that is able to collect JMX data.
On production environment we are using Zabbix for monitoring purposes.
Also we looked at Graphite but we chose Zabbix because it is our "corporate standard"
We are a mixed linux/windows shop that successfully adopted Puppet for Config Mgmt a while ago. We'd like to drop ansible in as our deployment orchestration tool (research suggests that puppet doesn't do this very well) but have questions about how to integrate the two products.
Today, puppet is the source of truth with respect to environment info (which nodes belong to which groups etc). I want to avoid duplicating this information in ansible. Are there any best practices with regards to sharing environment information between the two products?
One way to reduce the amount of duplicated state between the systems is to use Ansible's "Dynamic Inventory" support. Instead of defining your hosts/groups in a text file, you use a script that pulls the same data from somewhere else. This could be PuppetDB, Foreman, etc and is going to depend on your environment.
Writing a new script is also pretty simple, it just needs to be any executable (bash/python/ruby/etc) that returns json in a specific format.
Lastly, it is possible to roll out new releases with puppet, but it is easier with a "microservice" like release process. Ensuring apps/services/databases remain backwards compatible across versions can make pushing out releases trivial with puppet and your favorite package manager.
Using Puppet and Mcollective should be the way to go if you are looking for a solution from puppetlabs
https://puppetlabs.com/mcollective
One of the top-level projects on nixos.org is Disnix, "a distributed deployment extension for Nix". Another project is NixOps, "a tool for deploying NixOS machines in a network or cloud".
The feature sets sound very similar. Are they competitors, or is one a successor to the other, or are they solving different problems? If they are "competitors", as they seem to be, then what are the differences, and which should I be using?
EDIT: if it's any indication, NixOps appears to be under active development, but I can't see when Disnix was last worked on.
NixOps is a tool for "spinning up" nixos machines. Think: ec2 API.
Disnix is a toolset for managing the services running on a network of machines. Think: Chef/Puppet for multiple hosts.
Using DisnixOS (see the latest builds) the two can work together well, delegating to NixOps for instantiation of servers and delegating to Disnix to configure all your services on those servers.
If you are just deploying to a single server or the relationships between your services are simple, then NixOps can probably do everything you need. If you have multiple machines, running multiple services that are all subtly inter-related... then you will want Disnix/DisnixOS.
Sander van der Burg (the author of Disnix) has a rather detailed blog post explaining the relation/differences.
The short answer is: while both tools perform distributed deployment
tasks and use the Nix package manager as underlying (local) deployment
technology, they are designed for different purposes and address
different concerns. Furthermore, they can also be effectively used
together to automate deployment processes for certain kinds of
systems.
[...]
[Nixops] does infrastructure deployment, while [Disnix] does service
deployment. Infrastructure deployment is a prerequisite of doing
service deployment and both tools can actually be combined to automate
both concerns.
Service deployment is particularly useful for distributed systems that
can be decomposed into "distributable units" (such as service-oriented
systems), but not all kinds of distributed systems.
Moreover, NixOps is a tool that has been specifically designed to
deploy NixOS configurations, while Disnix can deploy services to
machines running any operating system capable of running the Nix
package manager.
Can anybody tell me application domain of "go" language ?
Which applications were built using "Go" language ?
For what kind of applications it is best suited for ?
From the FAQ:
What is the purpose of the project?
[...]
By its design, Go proposes an approach for the construction of system software on multicore machines.
Is Google using Go internally?
The Go project was conceived to make it easier to write the kind of servers and other software Google uses internally, but the implementation isn't quite mature enough yet for large-scale production use. While we continue development we are also doing experiments with the language as a candidate server environment. It's getting there. For instance, the server behind http://golang.org is a Go program; in fact it's just the godoc document server running in a production configuration.
So the intended domain is systems and server development for current multicore machines.