I am running minishift locally and want to install metrics on the same. I learned that metrics are removed from minishift and there is a way to enable them through ansible-playbooks.
I am not very familiar with ansible-playbooks and would like to understand how to run the following.
ansible-playbook [-i </path/to/inventory>] <OPENSHIFT_ANSIBLE_DIR>/playbooks/openshift-metrics/config.yml \
-e openshift_metrics_install_metrics=True \
-e openshift_metrics_hawkular_hostname=hawkular-metrics.example.com \
-e openshift_metrics_cassandra_storage_type=pv
My questions are
From where do I run this? Should I run this inside the Openshift VM or from my host machine?
Where is OPENSHIFT_ANSIBLE_DIR located?
Is the path to inventory a mandatory option to be passed, if so what is to be passed?
I have managed to install ansible but I searched a lot but couldn't find anything related to the playbooks to be run.
Related
I follow the first steps to install Flink.
I can start the cluster without any problem
$ start-cluster.sh
Starting cluster.
Starting standalonesession daemon on host DESKTOP-....
Starting taskexecutor daemon on host DESKTOP-....
But I don't get any status from
$ ps aux | grep flink
I can also not access the dashboard via localhost:8081.
There is an older post having these issues, but the solution didn't work for me, since the described conf files do no longer exist, apparently.
My JAVA_HOME is set as C:\Progra~1\Java\jdk1.8.0_311 to avoid issues with the space in Program Files.
Can you check the logs in the /logs folder? I'm suspecting that C:\Program Files\ could still cause issues because of the space there.
go to download Flink folder and try bash command
$./bin/start-cluster.sh --daemon bootstrap-server localhost:8081
and run code one more
$ ./bin/flink run examples/streaming/WordCount.jar
if you finished run above code which not issue, go to localhost:8081
This still seems to be problematic. I tried to run from Windows Subsystem for Linux (WSL).
I have the following versions: java 11.0.16 and flink 1.15.2.
sudo apt-get update
sudo apt install openjdk-11-jre-headless
export FLINK_HOME=/mnt/c/Projects/Apache/flink-1.15.2
I set the following in flink-conf.yaml
rest.port: 8081
rest.address: localhost
rest.bind-adress: 0.0.0.0
Whereby I changed the bind address for localhost to 0.0.0.0 this seems to have fixed the problem.
$FLINK_HOME/bin/start-cluster.sh
Now I can access the Flink Web Dashboard.
I have a set up that needs to be bootstrapped off the values of some files in another VM.
Here is the run command I am using to invoke the run run command:
BOOT_VM="${VM_NAME}1"
BOOT_ENODE=$(az vm run-command invoke --name ${BOOT_VM} \
--command-id RunShellScript \
--resource-group ${RSC_GRP_NAME} \
--query "value[].message" \
--output tsv \
--scripts "cat /etc/parity/enode.pub")
echo ${BOOT_ENODE}
The result I get is :
Enable succeeded: [stdout] [stderr]
As far as I know, this could mean 2 things:
There is no file there
I am handling the response wrongly.
Really hoping it isnt 1 and would like advice on how to approach this.
For your issue, there is also a reason that the agent in the vm is not at work or something not good happens to it. The Azure VM agent manages interactions between an Azure VM and the Azure fabric controller. So you should check if it works well.
Update
You can check the agent in the portal:
Also, you can check the agent inside the vm:
For example, I want to get the config of vim in the vm and the vm os is Red Hat 7.2. Then the result of the command az vm run-command invoke will like below:
I have a system with no internet access where I want to install some Nagios monitoring services/plugins. I installed NRPE (Nagios Remote Plugin Executor), and I can see commands defined in it, like check_users, check_load, check_zombie_procs, etc.
command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20
...
I am able to run the commands like so:
/usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -c check_load
This produces an output like:
OK - load average: 0.01, 0.13, 0.12|load1=0.010;15.000;30.000;0; load5=0.130;10.000;25.000;0; load15=0.120;5.000;20.000;0;
or
WARNING – load average per CPU: 0.06, 0.07, 0.07|load1=0.059;0.150;0.300;0; load5=0.069;0.100;0.250;0; load15=0.073;0.050;0.200;0;
Now, I want to define/configure/install some more services to monitor. I found a collection of services here. So, say, I want to use the service defined here called check_hadoop_namenode.pl. How do I get it to work with NRPE?
I tried copying the file check_hadoop_namenode.pl into the same directory where other NRPE services are stored, i.e., /usr/lib/nagios/plugins. But it doesn't work:
$ /usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -c check_hadoop_namenode.pl
I figured this might be obvious because all other services in that directory are binaries, so I need a binary for check_hadoop_namenode.pl file as well. How do I make the binary for it?
I tried installing the plugins according to the description in the link. But it just tries to install some package dependencies, and throws error as it cannot access the internet (my system has no internet access, like I stated before). This error persists even when I install these dependencies manually in another system and copy them to the target system.
$ <In another system with internet access>
mkdir ~/repos
git clone https://github.com/harisekhon/nagios-plugins
cd nagios-plugins
sudo nano Makefile
# replace 'yum install' with 'yumdownloader --resolv --destdir ~/repos/'
# replace 'pip install' with 'pip download -d ~/repos/'
This downloaded 43 dependencies (and dependencies of dependencies, and so on) required to install the plugins.
How do I get it to work?
check_users, check_load or check_zombie_procs are defined on the client side in nrpe.cfg file. Default location are /usr/local/nagios/etc/nrpe.cfg or /etc/nagios/nrpe.cfg. As I read, you already found that file, so you can move to next step.
Put something like this to your nrpe.cfg:
command[check_hadoop_namenode]=/path/to/your/custom/script/check_hadoop_namenode.pl -optional -arguments
Then you need restart NRPE deamon service on client. Something like service nrpe restart.
Just for you information, these custom script doesn't must to be binaries, you can even use simple bash script.
And finally after that, you can call the check_hadoop_namenode command from Nagios server or via local NRPE deamon:
/usr/local/nagios/libexec/check_nrpe -H 127.0.0.1 -c check_hadoop_namenode
Ansible unlike chef and puppet uses agent less run .
I would like to know is there any ansible remote client so that we can connect to fleet of ansible control machines to execute ansible playbooks on their respective targets .
I am looking for a command line cliient similar to following
ansible-execute hostname_of_control_machine username_of_control_machine password_of_control_machine inventory_file playbook_name
Please suggest if any ?
There is nothing preventing you from using Ansible to run Ansible on other machines. The Python API might be a good place to start, as you can get programmatic control over the initial Ansible runner.
You can do this with SSH
ssh username#controlmachine 'ansible-playbook yourPlaybook.yml
I am using puppet to read a fact from facter, and based on that I apply a different configuration to my modules.
Problem:
the puppet agent isn't seeing this fact. Running puppet agent --test interactively works as expected. Even running it non-interactively from a script seems to work fine. Only the agent itself is screwing up.
Process:
I am deploying an Ubuntu-based app stack on EC2. Using userdata (#cloud-config), I set an environment variable in /etc/environment:
export FACTER_tl_role=development
then immediately in #cloud-config, i source /etc/environment.
only THEN i apt-get install puppet (i moved away from using package: puppet to eliminate ambiguity in the sequence of #cloud-config steps)
Once the instance boots, I confirm that the fact is available: running facter tl_role returns "development". I then check /var/log/syslog, and apparently the puppet agent is not seeing this fact - I know this because it's unable to compile the catalog, and there's nothing (blank) where I'm supposed to be seeing the value of the variable set depending on this fact.
However, running puppet agent --test interactively compiles and runs the catalog just fine.
even running this from the #cloud-config script (immediately after installing puppet) also works just fine.
How do I make this fact available to the puppet agent? Restarting the agent service makes no difference, it remains unaware of the custom fact. Rebooting the instance also makes no difference.
here's some code:
EC2 userdata:
#cloud-config
puppet:
conf:
agent:
server: "puppet.foo.bar"
certname: "%i.%f"
report: "true"
runcmd:
- sleep 20
- echo 'export FACTER_tl_role=development' >> /etc/environment
- . /etc/environment
- apt-get install puppet
- puppet agent --test
Main puppet manifest:
# /etc/puppet/manifests/site.pp
node default {
case $tl_role {
'development': { $sitedomain = "dev.foo.bar"}
'production': { $sitedomain = "new.foo.bar"}
}
class {"code" : sitedomain => $sitedomain}
class {"apache::site" : sitedomain => $sitedomain}
class {"nodejs::grunt-daemon" : sitedomain => $sitedomain}
And then I see failures where $sitedomain is supposed to be, so $tl_role appears to be not set.
Any ideas? This is exploding my brain....
Another easy option would be to drop a fact into an external fact.
Dropping a file into /etc/facter/facts.d/* is fairly easy, and you can use a text file, yaml json or an executable to do it.
http://docs.puppetlabs.com/guides/custom_facts.html#external-facts
*that's on Open source puppet, on unix-y machines. See the link for the full docs.
Thank you, #christopher. This may be a good solution, I will test it and possibly move to it from my current horrible hack.
The answer I got in the Puppet Users Google Group was that I should not assume that the Puppet agent process will have an environment of a login shell, and that Facter will also have this environment when it is run by the Puppet agent.
Here is the way I solved it (admittedly, by brute force):
runcmd:
- echo 'export FACTER_tl_role=development' >> /etc/environment
- . /etc/environment
- apt-get install puppet
- service puppet stop
- sed -i '/init-functions/a\. \/etc\/environment' /etc/init.d/puppet
- puppet agent --test
- service puppet start
As you can see, after installing Puppet, I stop the agent, and add a line to /etc/init.d/puppet to source /etc/environment. Then I start the agent. NOT ideal... but it works!
I don't think . /etc/environment is going to work properly the way cloud-init executes runcmd. Two possible solutions:
Export the variable with the puppet agent command:
export FACTER_tl_role=development && puppet agent --test
If that doesn't work:
Just drop the commands into a user-data script and wire them together as a "multipart input" (described in the cloud-init docs).
The second solution executes the commands as a proper shell script, and would likely fix the problem. If the first works, though, it's easier to do with what you have.