Cloud DevOps Admin Guide

Local Kubernetes Development with kind

 kind is a tool built for running local Kubernetes clusters using Docker containers as nodes. kind was primarily designed for testing Kubernetes itself, but it is actually quite useful for creating a Kubernetes environment for local development, QA, or CI/CD. This blog post shows you how to setup a kind-based environment for local development that can mimic a production Kubernetes environment.

A fully functioning environment using kind includes a few different components. For our purposes, we will install the following list of software.

1. Docker.
2. The kubectl tool.
3. A local Docker registry.
4. kind.
5. An Ingress controller.

We can use these steps to create a repeatable script to setup a local Kubernetes cluster whenever you need it.

Docker

The kind project stands for “Kubernetes in Docker”. As such, you will need to install Docker to get started. This is typically environment specific, and you may need to consult the Docker documentation if you get stuck. The following should get you started:

macOS

The easiest way to install Docker for macOS is using Docker Desktop by going to the download page and grabbing the image. Click-to-install and you should be ready to go.

Linux (Ubuntu)

Older versions of Docker were called docker, docker.io, or docker-engine. If these are installed you should start by getting rid of them:

1

$ sudo apt-get remove docker docker-engine docker.io containerd runc

Once done, you can add the Docker apt repository to support future installations over apt. To do so, we need to first install packages necessary for installing from apt over HTTPS.

1
2
3
4
5
6

$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Then, we can add the Docker apt repository by adding Docker’s GPG key and followed by adding the apt repository.

1
2
3
4
5

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

Lastly, update the apt repository given the new Docker source, and install Docker.

1
2

$ sudo apt-get update
$ sudo apt-get install docker-ce docker-ce-cli containerd.io

Windows with WSL2

Newer versions of Windows include the Windows Subsystem for Linux 2 (WSL2) that provides excellent integration with Docker. To get started you first need to install WSL2 using the instructions here. Once this is done, you can install Docker Desktop.

After Docker Desktop is installed, open the Docker dashboard and make sure that WSL2 integration is enabled. This involves checking a few boxes: one for enabling WSL2 as the Docker engine backend, and a second for enabling WSL2 for the particular Linux images you are using.

Kubectl

kind does not strictly require kubectl, but because we are aiming to setup a fully functioning development environment we are going to install kubectl to be able to do some basic Kubernetes functions on our cluster.

If you get stuck at any point, refer to the official kubectl installation instructions.

macOS

On macOS, kubectl is available through Homebrew

1

$ brew install kubectl

Linux (Ubuntu)

Linux users (and Windows users using WSL2) can fetch kubectl through the Google apt repository:

1
2
3
4

$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update
$ sudo apt-get install -y kubectl

kind

Now we can finally install kind. Kind publishes binaries to Github. These can be installed through Homebrew on a Mac, or by downloading the release for Linux distributions.

macOS

1

$ brew install kind

Linux (Ubuntu)

1
2
3

$ curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.9.0/kind-linux-amd64
$ chmod +x ./kind
$ mv ./kind /usr/local/bin

Creating Kubernetes clusteres using kind

kind is a tool for running local Kubernetes clusters using Docker containers as Kubernetes Nodes. To see how this work, let’s create a cluster with the default settings:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

$ kind create cluster
Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.18.2) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Thanks for using kind! 😊

By default, this will create a single Kubernetes node running as a docker container named kind-control-plane and configures kubectl to use this cluster. You can view the Docker container running your cluster through the docker ps command:

1
2
3

$ docker ps
CONTAINER ID        IMAGE                  COMMAND                  CREATED              STATUS              PORTS                       NAMES
be5e7eec765b        kindest/node:v1.18.2   "/usr/local/bin/entr…"   About a minute ago   Up 57 seconds       127.0.0.1:43937->6443/tcp   kind-control-plane

Or through your newly configured kubectl.

1
2
3

$ kubectl get nodes
NAME                 STATUS   ROLES    AGE     VERSION
kind-control-plane   Ready    master   5m29s   v1.18.2

You can delete your cluster at any time using the kind delete cluster command:

1
2

$ kind delete cluster
Deleting cluster "kind" ...

You can also run a specific version of Kubernetes using the --image flag. For example, to create a Kubernetes cluster using version 1.14.10 of Kubernetes you would use the following command:

1

$ kind create cluster --image kindest/node:v1.14.10

Adding more nodes to your cluster

By default, kind creates a cluster with a single node. You can add additional nodes using a yaml-based configuration file that follows Kubernetes conventions. A minimum viable configuration just specifies the type of resource to create (Cluster), and the apiVersion to use:

1
2

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4

By saving this configuration to a file, you can create a cluster using it through the --config flag.

1

$ kind create cluster --config kind-config.yaml

You can add more nodes to your cluster by altering this configuration. This creates a more “realistic” Kubernetes environment, but is really not necessary unless you are testing specific features like rolling updates.

1
2
3
4
5
6

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker

We can create a cluster using this configuration using the create cluster command.

1

$ kind create cluster --config kind-3nodes.yaml

And view the three running nodes with kubectl.

1
2
3
4
5

$ kubectl get nodes
NAME                 STATUS   ROLES    AGE   VERSION
kind-control-plane   Ready    master   79s   v1.18.2
kind-worker          Ready    <none>   41s   v1.18.2
kind-worker2         Ready    <none>   40s   v1.18.2

Go ahead and delete this cluster before continuing on.

1

$ kind delete cluster

Creating a local Docker registry

One of the challenges in using Kubernetes for local development is getting local Docker containers you create during development to your Kubernetes cluster. Configuring this correctly allows Kubernetes to access any Docker images you create locally when deploying your Pods and Services to the cluster you created using kind. There are a few ways to solve this problem, but the one I prefer is to create a local Docker registry that your Kubernetes cluster can access. This version most closely matches a production deployment of Kubernetes.

The following example creates a Docker registry called kind-registry running locally on port 5000. This script first inspects the current environment to check if we already have a local registry running, and if we do not, then we start a new registry. The registry itself is simply an instance of the registry Docker image available on Docker Hub. We use the docker run command to start the registry.

1
2
3
4
5
6
7
8
9

#!/bin/sh
reg_name='kind-registry'
reg_port='5000'
running="$(docker inspect -f '{{.State.Running}}' "${reg_name}" 2>/dev/null || true)"
if [ "${running}" != 'true' ]; then
  docker run \
    -d --restart=always -p "${reg_port}:5000" --name "${reg_name}" \
    registry:2
fi

Now that we have a registry created, we can configure kind to use this registry for pulling container images during deployments. We do this using the configuration below. In this example, we run a single node Kubernetes cluster add some configuration to the containerd interface to allow pulling images from a local Docker registry.

1
2
3
4
5
6

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
    endpoint = ["http://kind-registry:5000"]  

We can save this file as local-registry.yaml and then create the cluster using kind:

1

$ kind create cluster --config local-registry.yaml

The last step we have is to connect the kind cluster’s network with the local Docker registry’s network:

1

$ docker network connect "kind" "kind-registry"

Deploying an application to your cluster

Now that we have kind deployed and a local registry enabled, we can test the cluster by deploying a new service. For this demonstration, I’ve created a simple Python server using Flask, and a corresponding Dockerfile to package it for deployment to our Kubernetes cluster.

Here is our simple Python server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import os

import flask
from flask import request, jsonify

app = flask.Flask(__name__)

@app.route("/")
def hello_world():
    return "Hello, world!"

app.run(host='0.0.0.0', port=8080)

And the corresponding Docker file:

1
2
3
4
5
6
7
8

FROM python:3.8-slim-buster
COPY . /app
WORKDIR /app
RUN pip install --upgrade pip
RUN pip install flask flask_cors dapr
ENTRYPOINT ["python"]
EXPOSE 8080
CMD ["app.py"]

You can build this application as a Docker container using the docker build command. The following line tags the build using the -t flag and specifies the local repository we created earlier.

1

$ docker build -t localhost:5000/pyserver:0.1 .

At this point, we have a Docker container built and tagged. Next we can push it to our local repository with the docker push command.

1

$ docker push localhost:5000/pyserver:0.1

You can check that this application is working by running the newly built Docker container and navigating to localhost:8080:

1

$ docker run -p 8080:8080 localhost:5000/pyserver:0.1

Ingress into kind

Since a typical service needs to be accessed by the Internet, we will also run an Ingress controller to broker connections between our local environment and the Kubernetes cluster. We do this by adding a few extra directives to the configuration of our cluster and then deploying the nginx Ingress controller.

We start by create a kind cluster with extraPortMappings and node-labels directives.

• extraPortMappings allows localhost to make requests to the Ingress controller over ports 80/443. This is similar to Docker’s -p flag.
• node-labels restricts the Ingress controller to run on a specific set of nodes matching the label selector.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
    endpoint = ["http://kind-registry:5000"]  
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"    
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP

You can save this yaml file as kind-ingress.yaml and create the cluster using the kind create cluster command:

1

$ kind create cluster --config kind-ingress.yaml --image kindest/node:v1.18.8

Our cluster is now capable of supporting Ingress controllers, so we can deploy one of the available options. In this tutorial I will use Nginx ingress which provides a deployment we can leverage through Github:

1

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml

Deploying our service

Finally we get to the good part: deploying our service into our local Kubernetes cluster! For this, we reference typically Kubernetes behaviour of creating a Service and an Ingress. The following yaml file references the Docker image for our service that we deployed to our local Docker registry:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

kind: Pod
apiVersion: v1
metadata:
  name: pyserver
  labels:
    app: pyserver
spec:
  containers:
  - name: pyserver
    image: localhost:5000/pyserver:0.1
---
kind: Service
apiVersion: v1
metadata:
  name: pyserver
spec:
  selector:
    app: pyserver
  ports:
  # Port used by the Docker image
  - port: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: pyserver-ingress
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: pyserver
          servicePort: 8080
---

By saving this yaml file as service.yaml, we can deploy this to our cluster using kubectl:

1

$ kubectl apply -f service.yaml

And verify that requests to localhost reach our server through the Ingress controller using curl:

1
2

$ curl localhost
Hello, World

Putting Everything Together

This post has covered a lot of ground. Thankfully, each of these steps can be automated so we don’t have to start from scratch each time. You can use the following Bash script to create a Kubernetes cluster with Ingress any time. Use this for local development, QA, or continuous integration!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

#!/bin/sh
set -o errexit

reg_name='kind-registry'
reg_port='5000'
k8s_version='1.18.8'

# Start a local Docker registry (unless it already exists)
running="$(docker inspect -f '{{.State.Running}}' "${reg_name}" 2>/dev/null || true)"
if [ "${running}" != 'true' ]; then
  docker run \
    -d --restart=always -p "${reg_port}:5000" --name "${reg_name}" \
    registry:2
fi

# Create a kind cluster
# - Configures containerd to use the local Docker registry
# - Enables Ingress on ports 80 and 443
cat <<EOF | kind create cluster --image kindest/node:v${k8s_version} --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:${reg_port}"]
    endpoint = ["http://${reg_name}:${reg_port}"]
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
EOF

# Connect the local Docker registry with the kind network
docker network connect "kind" "${reg_name}" > /dev/null 2>&1 &

# Deploy the nginx Ingress controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml

By Sreekanth Thummala No comments:

How to start your career in DevOps and Cloud ?

By Sreekanth Thummala No comments:

Introduction to kubernetes - k8s

Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines over 15 years of Google's experience running production workloads at scale with best-of-breed ideas and practices from the community.

Kubernetes Cluster

A Kubernetes cluster has two components:

1. master nodes which run the Kubernetes related daemons (Kube API, Kube proxy, Kube DNS, Kube dashboard,)
2. Cluster nodes belonging to one or more node pools which serve as the underlying physical resources for all the containers.

Node pools

A homogenous set of physical resources that provide the underlying resources for the cluster. A cluster can have one or more instance groups with labels to provide information to the Kubernetes scheduler on what can be run on the provided hardware.

Containers

A container is a resource running a single image (generally a docker image) containing all executable packages, runtime, operating system, system libraries. This is analogous to docker containers used by other orchestration tools.

Pod

Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. A pod is a set of one or more containers deployed and run together, sharing the same local network space. The recommendation is to run one container on a pod so that you can atomically control a process at a Kubernetes level but multi-container pods are not uncommon.

ReplicaSet

A ReplicaSet ensures that a specified number of pod replicas are running at any time. In other words, a ReplicaSet makes sure that a pod or a homogeneous set of pods is always up and available.

Deployment

A Deployment controller provides a declarative wrapper on top of replica sets defining the templates used to build the homogenous pods and the replication number. Even if you need to just run one container instance of a particular service, it is recommended to create a deployment for it with a configuration of 1 replica.

Horizontal Pod Scaler

With Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods in a replication controller, deployment, or replica set based on observed CPU utilization (or, with custom metrics support, on some other application-provided metrics).

Daemonset

A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created.

Some typical uses of a DaemonSet are:

1. running a cluster storage daemon, such as glusterd, ceph, on each node.
2. running a logs collection daemon on every node, such as fluentd or logstash.

StatefulSets

1. Used to manage stateful applications.
2. Provides guarantees about the ordering and uniqueness of these Pods
3. StatefulSet maintains a sticky identity for each of their Pods
4. Used typically for cases where predictability of deletion and creation order is important.

Service

A Service is an abstraction that defines a logical set of Pods and a policy by which to access them — sometimes called a micro-service. So if a deployment from the previous step exposed a web service through a port, then a service is how you would expose the deployment.

A service can be exposed outside using a load balancer or a cluster IP that is reachable from within the K8s cluster. The load balancer is a cloud-native LB like ELB in AWS. The cluster IP is a virtually routable IP.

Additionally, Kubernetes also gives each service a routable A record of the form $service-name.$namespace.svc.cluster.local

Configmap

Every K8s cluster can have one or more config maps. A configmap is a key-value store that is that can be made available to each container as part of the environment variables.

Network Topology

Every Kubernetes cluster satisfies the following requirements

1. all pods can communicate with all other pods without NAT
2. all nodes can communicate with all pods (and vice-versa) without NAT
3. the IP that a pod sees itself as is the same IP that others see it as

By Sreekanth Thummala No comments:

Running Commands as Another User via sudo

You want one user to run commands as another, without sharing passwords.
Suppose you want user smith to be able to run a given command as user jones. 

               /etc/sudoers:
smith  ALL = (jones) /usr/local/bin/mycommand

User smith runs:

smith$ sudo -u jones /usr/local/bin/mycommand
smith$ sudo -u jones mycommand                     If /usr/local/bin is in $PATH

User smith will be prompted for his own password, not jones’s.
The ALL keyword, which matches anything, in this case specifies that the line is valid on any host.
sudo exists for this very reason!
To authorize root privileges for smith, replace “jones” with “root” in the above example.

By Sreekanth Thummala No comments:

Kubectl commands - Kubernetes

Kubectl is a command line interface for running commands against Kubernetes clusters. This overview covers kubectl syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the kubectl reference documentation.

List all services

kubectl get services 
kubectl get svc

List everything

kubectl get all --all-namespaces

Describe service <name>

kubectl describe svc <name>

Get services sorted by name

kubectl get services –sort-by=.metadata.name

List all pods

kubectl get pods

Watch nodes continuously

kubectl get pods -w

Get version information

kubectl get version

Get cluster information

kubectl get cluster-info

Get the configuration

kubectl config view

Output information about a node

kubectl describe node <node-name>

List the replication controllers

kubectl get rc

List the replication controllers in specific <namespace>

kubectl get rc -n <namespace-name>

Describe replication controller <name>

kubectl describe rc <name>

Delete pod <name>

kubectl delete pod <name>

Delete replication controller <name>

kubectl delete rc <name>

Delete service <name>

kubectl delete svc <name>

Remove <node> from the cluster

kubectl delete node <name>

Show metrics for nodes

kubectl top nodes

Show metrics for pods

kubectl top pods

Watch the Kublet logs

watch -n 2 cat /var/log/kublet.log

Get logs from service <name>, optionally  selecting container <$container>

kubectl logs -f <name> [-c <$container>] 

execute <command> on <service>, optionally  selecting container <$container>

kubectl exec <service> <command> [-c <$container>]

Initialize your master node

kubeadm init

Join a node to your Kubernetes cluster

kubeadm join --token <token> <master-ip>:<master-port>

Create namespace <name>

kubectl create namespace <namespace>

Allow Kubernetes master nodes to run pods

kubectl taint nodes --all node-role.kubernetes.io/master

Reset current state

kubeadm reset

List all secrets

kubectl get secrets

Launch a pod called <name> ,using image <image-name>

kubectl run <name> --image=<image-name>

Create a service described in <manifest.yaml> file

kubectl create -f <manifest.yaml>

Validate yaml file with dry run

kubectl create --dry-run --validate -f sysaix.yaml

Scale replication controller

kubectl scale rc <name> --replicas=<count>

Stop all pods on specific pods

kubectl drain <n> --delete-local-data --force --ignore-deamonsets

Explain resource

kubectl explain pods
kubectl explain svc

Open a bash terminal in a pod

kubectl exec -it sysa'xpod sh

Check pod environment variables

kubectl exec sysaixpod env

Filter pods by label

kubectl get pods -l owner=emre

List statefulset

kubectl get sts

Scale statefulset

kubectl scale sts <stateful_set_name> --replicas=5

Delete statefulset only (not pods)

kubectl delete sts <stateful_set_name> --cascade=false

View all events

kubectl get events --all-namespaces

By Sreekanth Thummala No comments:

How to enable Accelerated Networking on an existing VM - AZURE

First, not all VM size support Accelerated Network, the supported OS and VM size can be found here:

https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-cli

https://docs.microsoft.com/en-us/azure/virtual-network/create-vm-accelerated-networking-powershell

so I’ve deallocate the VM and change the size to DS3 v2, that’s a supported VM size.



Then run the following PowerShell Commands

$nic = Get-AzureRmNetworkInterface -ResourceGroupName "bigvnetgroup" -Name "server2016344"

$nic.EnableAcceleratedNetworking = $true

$nic | Set-AzureRmNetworkInterface

By Sreekanth Thummala No comments:

Zabbix JMX monitoring setup for Linux server

JMX monitoring can be used to monitor JMX counters of a Java application.

JMX monitoring has native support in Zabbix in the form of a Zabbix daemon called “Zabbix Java gateway”, introduced since Zabbix 2.0.

To retrieve the value of a particular JMX counter on a host, Zabbix server queries the Zabbix Java gateway, which in turn uses the JMX management API to query the application of interest remotely.

What is Java and JMX monitoring?

JMX monitoring can be used to measure all JMX counters of a Java application. Java Management Extensions (JMX) is a Java Community Process (JSR-3) specification for managing and monitoring Java applications. Via a so-called Java gateway, the Zabbix server can address the JMX monitoring services, read data from a Java application and save and process it as an item.

A typical use case is the monitoring of the memory consumption of a Java application or of the Java runtime environment in which the application is operated.

Java Gateway and Java Pollers

Zabbix Java gateway

The so-called Zabbix Java Gateway is a special bollard process that can retrieve data via JMX. Unlike the previously mentioned boll processes, this is not an "internal" process within the Zabbix server. The Java Gateway is a stand-alone daemon that provides data to the Zabbix server through a TCP port. The Java Gateway is Java software that requires a JRE.

Enable Java Gateway

To use JMX monitoring, you must install the Zabbix Java Gateway, which is typically not included in the default installation. If you are using Zabbix LLC DEB or RPM packages , install the Java Gateway as follows. The Java Gateway requires no configuration and can be started immediately.

apt-get install zabbix-java-gateway # Debian/Ubuntu 

/etc/init.d/zabbix-java-gateway start # Debian/Ubuntu

yum install zabbix-java-gateway # Red Hat/CentOS 

 service zabbix-java-gateway start # Red Hat/CentOS 

 systemctl enable zabbix-java-gateway # Red Hat/CentOS


You should now find startup and shutdown scripts in the /opt/zabbix-java-gateway/sbin/zabbix_java folder .

cd /opt/zabbix-java-gateway/sbin/zabbix_java

 ./startup.sh


Test if the Java Gateway is running.

# ps -ef| grep -i java

Java Gateway as data provider for the Zabbix server

Now that Java gateway is running, you have to tell Zabbix server where to find Zabbix Java gateway. This is done by specifying JavaGateway and JavaGatewayPort parameters in server configuration file.

If the host on which JMX application is running is monitored by Zabbix proxy, then you specify the connection parameters in proxy configuration file instead.
JavaGateway=<Client IP Address> JavaGatewayPort=10052

By default, server does not start any processes related to JMX monitoring. If you wish to use it, however, you have to specify the number of pre-forked instances of Java pollers. You do this in the same way you specify regular pollers and trappers.
StartJavaPollers=5

Do not forget to restart server or proxy, once you are done with configuring them.

Enter the Java Gateway in the file /etc/zabbix/zabbix_server.conf . In the Zabbix server, activate at least one Java bollard, which "requests" the item data from the Java gateway and forwards the server process. After you make the changes, restart the Zabbix server.

NOTE: This is a one time setup in the zabbix server and need NOT be modified again for every new server that we add to the Zabbix WebUI.

Enabling remote JMX monitoring for Java application

A Java application does not need any additional software installed, but it needs to be started with the command-line options specified below to have support for remote JMX monitoring.

As a bare minimum, if you just wish to get started by monitoring a simple Java application on a local host with no security enforced, start it with these options:

export CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=10052 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=ClientIP -Djava.net.preferIPv4Stack=true"

NOTE: Communication between Java gateway and the monitored JMX application should not be firewalled.

So disable the server level internal firewall in the linux client using the below command.

systemctl disable firewalld

Configuring JMX interfaces and items in Zabbix frontend

With Java gateway running, server knowing where to find it and a Java application started with support for remote JMX monitoring, it is time to configure the interfaces and items in Zabbix GUI.

Before retrieving data from the JMX interface, you must specify for each host on which IP address and on which TCP port the JMX interface of the Java program listens. Navigate to the host configuration and add a JMX interface. If you want to monitor several Java programs via JMX on a host, you must use different TCP ports.

Apply the appropriate JMX template to the server in the zabbix webUI like JMX generic template and you can see that the JMX turns green and is enabled.

By Sreekanth Thummala No comments:

Modern way of /etc/motd - FireMotd for linux

While developing, playing or working on Linux systems, a dynamic MotD generator script can quickly give you an overview of all used components of your Linux systems.

FireMotD can show you this information in a sanitized and colorful way while you log in with SSH or console.
Depending of the chosen theme FireMotD will output all information defined in the theme on your server.
We need EPEL repository to be installed and enabled in the server to install the dependency packages.

Install Dependencies

You need to install the required dependencies as shown below.

yum install bc sysstat jq moreutils

After installing the dependencies, clone/download or copy the FireMotd to the root directory as shown.

git clone https://github.com/OutsideIT/FireMotD.git

Change to the FireMotd directory and run the below commands

You need to have make installed on the system, if you want to use the Makefile.

To install to /usr/local/bin/FireMotD

sudo make install

With this you can probably run FireMotD from anywhere in your system. If not, you need to add /usr/local/bin to your $PATH variable. To adjust the installation path, change the var IDIR=/usr/local/bin in the Makefile to the path you want.

To install bash autocompletion support

sudo make bash_completion

With this you can use TAB to autocomplete parameters and options with FireMotD. Does not require the sudo make install above (system install), but requires the bash-completion package to be installed and working. Then you should logout-login or source the bash completion file, eg. $ . /etc/bash_completion.d/FireMotD

If you don't have root access, just install everything on your user's folder and source the file from your user's .profile file

Crontab to get system information

Root privilege is required for this operation. Only /etc/crontab and the files in /etc/cron.d/ have a username field.

The recommended way to generate /var/tmp/FireMotD.json is by creating a separate cron file for firemotd like this:

sudo vim /etc/cron.d/firemotd 

# FireMotD system updates check (randomly execute between 0:00:00 and 5:59:59) 0 0 

* * * root perl -e 'sleep int(rand(21600))' && /usr/local/bin/FireMotD -S &>/dev/null

But you can also put it in root's crontab (without the user field):

sudo crontab -e 

# FireMotD system updates check (randomly execute between 0:00:00 and 5:59:59) 0 0 

* * * perl -e 'sleep int(rand(21600))' && /usr/local/bin/FireMotD -S &>/dev/null

Adding FireMotD to run on login

Choosing where to run your script is kind of situational. Some files will only run on remote logins, other local logins, or even both. You should find out what suits best your needs on each case.

To add FireMotD to a single user

Edit the user's ~/.profile file, ~/.bash_profile file, or the ~/.bashrc file
nano ~/.profile

Add the FireMotD call at the end of the file (choose your theme)

/usr/local/bin/FireMotD -t blue

To add FireMotD to all users

You may call FireMotD from a few different locations for running globally.
Eg./etc/bash.bashrc, /etc/profile.

we use /etc/profile, so add the line to this file.

Color outputs :

Blue

Red

Gray

By Sreekanth Thummala No comments: