Hello my folks, welcome to the fascinating world of Gitlab. Nowadays, this has become a real use of every programmer/developer. You know every programmer needs some space to situate their projects and code which have been made by them. Today, in this Gitlab mainstream, we are going to elaborate on the SSH key in this you will learn about the fact of how can you create, manage with the SSH key.

What is an SSH key?

Let’s get started with SSH. SSH stands for secured shell and now, comes to the place of uses what is the use? This is used for authentication, by setting SSH you can connect to the Gitlab server without using a username and password each time. Once, you will set the SSH key so, you may skip using your username and password each time to connect your Gitlab server.

How to set up an SSH key in Gitlab?

Let see, what will have to do here?

Step 1: Run command SSH- keygen

You will have to run this command. If you are on MacBook, you can put terminal and will run the command SSH-keygen. You may enter the location or file where you have to save the key and press the enter key. So, you will have your ssh key created. This was on mac.

On mac. – run command on terminal

On windows – use putty or Git bash

If you are on windows then you can use an application or a client called putty, it is ssh client that you can use on windows or you can also use Git bash to run the command. If you will have installed it before, you will go to your windows system and search for Git bash. And you will adjust fonts if you will need them. So, you will run $ ssh-keygen then it will ask you to enter the file do you want to save it then again, you will press the enter so, it will have been created. You will go to your folder from local disk to .ssh in that two files will be created in the id_rsa and id_rsa.pub

Now, step no.2 will be

Step 2: log in to Gitlab account

                        Go to an account >> Settings >> SSH keys

So, you will go to your Gitlab and log in. you will sign in to your account if you will go to your account or profile at the top right. You would find settings there and if you will go in that. So, you will find an option for SSH key then you will click on that. You would add the content of your file id_rsa.pub. If you will go to the file and open it with any text editor like notepad and notepad++, you can copy the entire thing from there. And you will paste it to the SSH key. Suppose, you want to give a name to your key then you can add that name in the title option and switch to add key. So, you will see that everything would be edited there. There would be a key that you can use to authenticate and log in to the Gitlab server.

Now, here step no.3 is

Step 3: copy contents of id_rsa.pub and add key

Step 4: verify SSh key is added

 You have been seen. This is how you can add an SSH key to your Gitlab. I wish this all will be very useful for you.

Related video:

“Virtual hosting is a method for hosting multiple domain names (with separate handling of each name) on a single server (or pool of servers).”

How Does Apache Know Which Site to Serve?

The short answer to your specific case: apache will serve the FIRST overlapping virtual host. Since 000-default is before fc.localhost in the alphabet the first virtualhost is loaded and served.

To answer what i assume is the follow up question: You can host many sites on the same IP:PORT using named VirtualHosts

The host field in the http request header identifies which site (virtual
host) to serve:

Matched against the containers in the configuration file

A More Complete Virtual Host Definition

You can put (almost) any directive inside a virtual host container For example, it’s common to write separate logs for each site

Name Resolution

1. In the “real world” our East and West sites would each have an entry in DNS (Domain Name Service)
2. Our demonstration system uses only /etc/hosts for name resolution:

Apache Installation

Apache gives its functionality and the components to individual units which can be customized and configured independently. The basic unit that describes a site or a domain is called a virtual host.

This allows the administrator to use one server to host multiple domains or sites with a single interface or IP address by using a mechanism.

$ sudo apt-get update
$ sudo apt-get install apache2

Create the Directory Structure

A directory structure shall hold the site information and data which will be served to visitors. By default, the top-level directory for apache is /var/www and we will be setting them to the individual directories under the /var/www directory for each site/domain.

$ sudo mkdir -p /var/www/firstSite.com
$ sudo mkdir -p /var/www/secondSite.com

Grant Permissions

Our directory’s owned by our root user. If we want our normal user to be able to modify files in our web directories, then we have to change the ownership to others normal users.

$ sudo chown -R $USER:$USER /var/www/firstSite.com
$ sudo chown -R $USER:$USER /var/www/secondSite.com
$ sudo chmod -R 755 /var/www

Create Demo Pages for for both sites.

To create a file we use touch command, The touch command is a standard command used in UNIX/Linux operating system which is used to create, change and modify timestamps of a file.

$ touch /var/www/webserver1.com/index.html

Then put some lines of html.

<!DOCTYPE html>
<html>
<head>
<title>Site one</title>
</head>
<body>

<h1>Site one heading</h1>
<p>My first paragraph.</p>

</body>
</html>

We’ll copy and past the same page for second server and modify it accordingly

$ cp /var/www/firstSite.com/index.html /var/www/secondSite.com/index.html

$ nano /var/www/webserver2.com/index.html
<html>
   <head>
      <title>Welcome to secondSite.com!</title>
   </head>
   <body>
      <h1>Success!</h1>
   </body>
</html>

Create New Virtual Host Files

$ sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/firstSite.conf
$ sudo nano /etc/apache2/sites-available/firstSite.com.conf

<VirtualHost *:80>
   ServerAdmin admin@firstSite.com
   ServerName firstSite.com
   ServerAlias www.firstSite.com
   DocumentRoot /var/www/firstSite.com/
   ErrorLog ${APACHE_LOG_DIR}/error.log
   CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Copy First Virtual Host file and customize for Second Domain webserver2.com

$ sudo cp /etc/apache2/sites-available/firstSite.com.conf /etc/apache2/sites-available/secondSite.com.conf
$ sudo nano /etc/apache2/sites-available/secondSite.com.conf

Do the same thing for secondSite VH

<VirtualHost *:80>
   ServerAdmin admin@secondSite.com
   ServerName secondSite.com
   ServerAlias www.secondSite.com
   DocumentRoot /var/www/secondSite.com/
   ErrorLog ${APACHE_LOG_DIR}/error.log
   CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Enable the New Virtual Host Files

$ sudo a2ensite webserver1.com.conf
$ sudo a2ensite webserver2.com.conf

We needed to restart Apache server

$ sudo service apache2 restart

Testing the Websites

$ sudo /etc/hosts

192.168.1.84 website1.com
192.168.1.84 website1.com

Full-text search can be both scary and exciting. Some popular databases such as MySql and Postgres are an amazing solution for storing data… but when it comes to full-text search performances, there’s no competition with ElasticSearch.

For those who don’t know, ElasticSearch is a search engine server built on top of Lucene with an amazing distributed-architecture support. According to db-engines.com, it is currently the most used search engine out there.

In this post, we are going to build a simple REST application called The Quotes Database which will allow us to store and search as many quotes as we want.

I’ve prepared a JSON file containing 5000+ quotes with their authors, we’ll be using it as our starting data for populating ElasticSearch.

Setting up Docker

First of all, we don’t want to install ElasticSearch on our machine. We’ll be using Docker for orchestrating both the Node.js server and the ES instance on a container, which will allow us to deploy a production-ready application with all the dependencies that it needs.

Let’s create a Dockerfile inside our project root folder:

FROM node:10.15.3-alpine

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install
RUN npm install -g pm2

COPY . ./

EXPOSE 3000
EXPOSE 9200

CMD npm run start

As you can see, we’re telling Docker that we’ll run a Node.js 10.15.3-alpine runtime. We’ll also create a new working directory under /usr/src/app, where we’ll copy both the package.json and the package-lock.json files. That way, Docker will be able to run npm install inside our WORKDIR, installing our needed dependencies.

We’ll also install PM2 by running RUN npm install -g pm2. The Node.js runtime is single-threaded, so if a process crashes, the entire app needs to be restarted… PM2 checks the Node.js process status and restarts it when the app goes down for any reason.

After installing PM2, we’ll copy our codebase inside our WORKDIR (COPY . ./), and we tell Docker to expose two ports, 3000, which will expose our RESTful service, and 9200, which exposes the ElasticSearch service (EXPOSE 3000 and EXPOSE 9200).

Last but not least, we tell Docker which command will start the Node.js app with npm run start.

Setting up docker-compose

Now you may be saying, ‘Great, I get it! But how do I handle the ElasticSearch instance inside Docker? I can’t find it in my Dockerfile!’… you’re right! That’s where docker-compose becomes useful. It allows us to orchestrate multiple Docker containers and to create a connection between them. So, let’s write down the docker-compose.yml file, which will be stored inside our project root directory:

version: '3.6'
services:
  api:
    image: node:10.15.3-alpine
    container_name: tqd-node
    build: .
    ports:
      - 3000:3000
    environment:
     - NODE_ENV=local
     - ES_HOST=elasticsearch
     - NODE_PORT=3000
     - ELASTIC_URL=http://elasticsearch:9200
    volumes:
      - .:/usr/src/app/quotes
    command: npm run start
    links:
        - elasticsearch
    depends_on:
        - elasticsearch
    networks: 
      - esnet
  elasticsearch:
    container_name: tqd-elasticsearch
    image: docker.elastic.co/elasticsearch/elasticsearch:7.0.1
    volumes:
      - esdata:/usr/share/elasticsearch/data
    environment:
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      - discovery.type=single-node
    logging:
      driver: none
    ports:
      - 9300:9300
      - 9200:9200
    networks: 
      - esnet
volumes:
  esdata:
networks:
  esnet:

This is a bit more complex than our Dockerfile, but let’s analyze it:

• We declare which version of docker-compose.yml file we’re using (3.6)
• We declare our services:
  • api, which is our Node.js app. Just like in our Dockerfile, it requires the node:10.15.3-alpine image. We also assign a name to this container tqd-node, and here we call the previously created Dockerfile using the build . command.
  • We need to expose the 3000 port so we write these statements as follows 3000:3000. It means that we’re mapping from the port 3000 (inside our container) to the port 3000 (accessible from our machine). Then we’ll set some environment variables. The value elasticsearch is a variable which refers to the elasticsearch service inside our docker-compose.yml file.
  • We also want to mount a volume /usr/src/app/quotes. That way, once we restart our container we’ll maintain our data without losing it.
  • Once more, we tell Docker which command we need to execute once the container starts up, then we set a link to the elasticsearch service. We also tell Docker to start the api service after the elasticsearch service has booted (using the depends_on directive).
  • Last but not least, we tell Docker to connect the api service under the esnet network. That’s because every container has its own network. That way, we say that api and elasticsearch services shares the same network so they will be able to call each other with the same ports.
  • elasticsearch, which is (as you may have guessed) our ES service. It’s configuration is pretty similar to the api service. We’ll just cut off its verbose logs setting the logging directive to driver: none .
• We also declare our volumes, where we store the ES data.
• And we declare our network, esnet.

Bootstrapping the Node.js app

Now we need to create our Node.js application, so let’s get started setting up our package.json file:

npm init -y

Now we need to install some dependencies:

npm i -s @elastic/elasticsearch body-parser cors dotenv express

Great! Our package.json file should look like this:

{
  "name": "nodejselastic",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "@elastic/elasticsearch": "^7.3.0",
    "body-parser": "^1.19.0",
    "cors": "^2.8.5",
    "dotenv": "^8.0.0",
    "express": "^4.17.1"
  }
}

Let’s implement our ElasticSearch connector in Node.js. First, we need to create a new /src/elastic.js file:

const { Client } = require("@elastic/elasticsearch");
                   require("dotenv").config();

const elasticUrl = process.env.ELASTIC_URL || "http://localhost:9200";
const esclient   = new Client({ node: elasticUrl });
const index      = "quotes";
const type       = "quotes";

As you can see, here we set some constants that will be incredibly useful. First of all, we create a new connection to ElasticSearch using its official Node.js SDK, then we define an index ("quotes") and an index type("quotes" again, we’ll see later what they mean).

Now we need to create an index on ElasticSearch. You can think of “indexes” as a SQL “database” equivalent. ElasticSearch is a NoSQL database, which means that it has no tables — it just stores JSON documents. An index is a logical namespace which maps to one or more primary shards and can have zero or more replica shards. You can read more about ElasticSearch indexes here.

Let’s now define a function that will create our index:

async function createIndex(index) { 
  try {
    await esclient.indices.create({ index });
    console.log(`Created index ${index}`);
  } catch (err) {
    console.error(`An error occurred while creating the index ${index}:`);
    console.error(err);
  }
}

Now we need another function that creates the mapping for our quotes. The mapping defines the schema and types of our document:

async function setQuotesMapping () {
  try {
    const schema = {
      quote: {
        type: "text" 
      },
      author: {
        type: "text"
      }
    };

    await esclient.indices.putMapping({ 
      index, 
      type,
      include_type_name: true,
      body: { 
        properties: schema 
      } 
    })

    console.log("Quotes mapping created successfully");
  } catch (err) {
    console.error("An error occurred while setting the quotes mapping:");
    console.error(err);
  }
}

As you can see, we’re defining the schema for our documents, and we’re inserting it inside our index.

Now let’s consider that ElasticSearch is a huge system and can take some seconds to boot up. We can’t connect to ES until it is ready, so we need a function that checks when the ES server is ready:

function checkConnection() {
  return new Promise(async (resolve) => {
    console.log("Checking connection to ElasticSearch...");
    let isConnected = false;
    while (!isConnected) {
      try {
        await esclient.cluster.health({});
        console.log("Successfully connected to ElasticSearch");
        isConnected = true;
      // eslint-disable-next-line no-empty
      } catch (_) {
      }
    }
    resolve(true);
  });
}

As you can see, we’re returning a promise. That’s because by using async/await we’re able to stop the entire Node.js process until this promise resolves, and it won’t do it until it connects to ES. That way, we force our Node.js to wait for ES before booting up.

We’re done with ElasticSearch! Now let’s export our functions:

module.exports = {
  esclient,
  setQuotesMapping,
  checkConnection,
  createIndex,
  index,
  type
};

Great! Let’s see the entire elastic.js file:

const { Client } = require("@elastic/elasticsearch");
                   require("dotenv").config();
const elasticUrl = process.env.ELASTIC_URL || "http://localhost:9200";
const esclient   = new Client({ node: elasticUrl });
const index      = "quotes";
const type       = "quotes";
/**
 * @function createIndex
 * @returns {void}
 * @description Creates an index in ElasticSearch.
 */
async function createIndex(index) {
  try {
    await esclient.indices.create({ index });
    console.log(`Created index ${index}`);
  } catch (err) {
    console.error(`An error occurred while creating the index ${index}:`);
    console.error(err);
  }
}
/**
 * @function setQuotesMapping,
 * @returns {void}
 * @description Sets the quotes mapping to the database.
 */
async function setQuotesMapping () {
  try {
    const schema = {
      quote: {
        type: "text" 
      },
      author: {
        type: "text"
      }
    };
  
    await esclient.indices.putMapping({ 
      index, 
      type,
      include_type_name: true,
      body: { 
        properties: schema 
      } 
    })
    
    console.log("Quotes mapping created successfully");
  
  } catch (err) {
    console.error("An error occurred while setting the quotes mapping:");
    console.error(err);
  }
}
/**
 * @function checkConnection
 * @returns {Promise<Boolean>}
 * @description Checks if the client is connected to ElasticSearch
 */
function checkConnection() {
  return new Promise(async (resolve) => {
    console.log("Checking connection to ElasticSearch...");
    let isConnected = false;
    while (!isConnected) {
      try {
        await esclient.cluster.health({});
        console.log("Successfully connected to ElasticSearch");
        isConnected = true;
      // eslint-disable-next-line no-empty
      } catch (_) {
      }
    }
    resolve(true);
  });
}
module.exports = {
  esclient,
  setQuotesMapping,
  checkConnection,
  createIndex,
  index,
  type
};

Populating ElasticSearch with quotes

Now we need to populate our ES instance with our quotes. This may sound easy, but believe me, it can be tricky.

Let’s create a new file in /src/data/index.js:

const elastic = require("../elastic");
const quotes  = require("./quotes.json");

const esAction = {
  index: {
    _index: elastic.index,
    _type: elastic.type
  }
};

As you can see, we’re importing the elastic module we just created and our quotes from a JSON file stored in /src/data/quotes.json. We’re also creating an object called esAction, which will tell ES how to index a document once we insert it.

Now we need a script to populate our database. We also need to create an array of Object with the following structure:

[
  {
    index: {
      _index: elastic.index,
      _type:  elastic.type
    }
  },
  {
    author: "quote author",
    quote:  "quote"
  },
  ...
]

As you can see, for each quote we’re gonna insert, we need to set its mapping to ElasticSearch. So that’s what we’ll do:

async function populateDatabase() {
  const docs = [];
  for (const quote of quotes) {
    docs.push(esAction);
    docs.push(quote);
  }
  return elastic.esclient.bulk({ body: docs });
}

Great! Now let’s create our main file in /src/main.js and see how we’ll structure everything we’ve written so far:

const elastic = require("./elastic");
const data    = require("./data");
                require("dotenv").config();

(async function main() {

  const isElasticReady = await elastic.checkConnection();
  if (isElasticReady) {
    const elasticIndex = await elastic.esclient.indices.exists({index: elastic.index});

    if (!elasticIndex.body) {
      await elastic.createIndex(elastic.index);
      await elastic.setQuotesMapping();
      await data.populateDatabase()
    }
  }

})();

Let’s analyze the code above. We create a self-executing main function which will check for the ES connection. The code execution won’t proceed until ES is connected. When ES is ready, we’ll check if the quotes index exists. If it doesn’t, we’ll create it, we’ll set its mapping and will populate the database. Obviously, we’ll do so only the first time we start up our server!

Creating a RESTful API

Now we need to create our RESTful server. We’ll be using Express.js, which is the most popular Node.js framework out there for building servers.

We’ll start with the /src/server/index.js file:

const express      = require("express");
const cors         = require("cors");
const bodyParser   = require("body-parser");
const routes       = require("./routes");
                     require("dotenv").config();

const app  = express();
const port = process.env.NODE_PORT || 3000;

function start() {
  return  app.use(cors())
             .use(bodyParser.urlencoded({ extended: false }))
             .use(bodyParser.json())
             .use("/quotes",routes)
             .use((_req, res) => res.status(404).json({ success: false,error: "Route not found" }))
             .listen(port, () => console.log(`Server ready on port ${port}`));
}

module.exports = {
  start
};

As you can see, it is just a standard Express.js server, we won’t spend much time on that.

Let’s see our /src/server/routes/index.js file:

const express    = require("express");
const controller = require("../controllers");
const routes     = express.Router();

routes.route("/").get(controller.getQuotes);
routes.route("/new").post(controller.addQuote);

module.exports = routes;

We just create two endpoints:

1. GET /, will return a list of quotes matching our query string parameters.
2. POST /new/, will allow us to post a new quote storing it inside ElasticSearch.

So now let’s see our /src/server/controllers/index.js file:

const model = require("../models");

async function getQuotes(req, res) {
  const query  = req.query;
  if (!query.text) {
    res.status(422).json({
      error: true,
      data: "Missing required parameter: text"
    });
    return;
  }
  try {
    const result = await model.getQuotes(req.query);
    res.json({ success: true, data: result });
  } catch (err) {
    res.status(500).json({ success: false, error: "Unknown error."});
  }
}

async function addQuote(req, res) {
  const body = req.body;
  if (!body.quote || !body.author) {
    res.status(422).json({
      error: true,
      data: "Missing required parameter(s): 'body' or 'author'"
    });
    return;
  }
  try {
    const result = await model.insertNewQuote(body.quote, body.author);
    res.json({ 
      success: true, 
      data: {
        id:     result.body._id,
        author: body.author,
        quote:  body.quote
      } 
    });
  } catch (err) {
    res.status(500).json({ success: false, error: "Unknown error."});
  }
}
module.exports = {
  getQuotes,
  addQuote
};

Here we’re basically defining two functions:

1. getQuotes, which requires at least one querystring parameter – text
2. addQuote, which require two parameters – author and quote

The ElasticSearch interface is delegated to our /src/server/models/index.js. This structure helps us maintain a MVC-ish architecture.

Let’s see our model:

const { esclient, index, type } = require("../../elastic");

async function getQuotes(req) {
  const query = {
    query: {
      match: {
        quote: {
          query: req.text,
          operator: "and",
          fuzziness: "auto"
        }
      }
    }
  }

  const { body: { hits } } = await esclient.search({
    from:  req.page  || 0,
    size:  req.limit || 100,
    index: index, 
    type:  type,
    body:  query
  });

  const results = hits.total.value;
  const values  = hits.hits.map((hit) => {
    return {
      id:     hit._id,
      quote:  hit._source.quote,
      author: hit._source.author,
      score:  hit._score
    }
  });

  return {
    results,
    values
  }
}

As you can see, we’re composing our ElasticSearch query by selecting every quote that includes a given word or phrase.

Then, we spawn the query, setting both page and limit values we can pass them in a query string, for instance http://localhost:3000/quotes?text=love&page=1&limit=100. If these values are not passed via querystring, we’ll fall back to their default values.

ElasticSearch returns an incredibly big amount of data, but we just need four things:

1. Quote ID
2. The quote itself
3. Quote author
4. Score

The score represents how close the quote is to our search term. Once we have these values, we return them with the total results number, which may be useful when paginating the results on the front end.

Now we need to create the last function for our model insertNewQuote:

async function insertNewQuote(quote, author) {
  return esclient.index({
    index,
    type,
    body: {
      quote,
      author
    }
  })
}

This function is really simple, we just post the quote and the author to our index and return the query result back to the controller.

Now the complete /src/server/models/index.js file should look like this:

const { esclient, index, type } = require("../../elastic");

async function getQuotes(req) {
  const query = {
    query: {
      match: {
        quote: {
          query: req.text,
          operator: "and",
          fuzziness: "auto"
        }
      }
    }
  }

  const { body: { hits } } = await esclient.search({
    from:  req.page  || 0,
    size:  req.limit || 100,
    index: index, 
    type:  type,
    body:  query
  });

  const results = hits.total.value;

  const values  = hits.hits.map((hit) => {
    return {
      id:     hit._id,
      quote:  hit._source.quote,
      author: hit._source.author,
      score:  hit._score
    }
  });

  return {
    results,
    values
  }
}

async function insertNewQuote(quote, author) {
  return esclient.index({
    index,
    type,
    body: {
      quote,
      author
    }
  })
}

module.exports = {
  getQuotes,
  insertNewQuote
}

And we’re done! We just need to setup our start script inside out package.json file and we’re ready to go:

"scripts": {
  "start": "pm2-runtime start ./src/main.js --name node_app",
  "stop": "pm2-runtime stop node_app "
}

We also need to update our /src/main.js script in order to start up our Express.js server once ElasticSearch has been connected:

const elastic = require("./elastic");
const server  = require("./server");
const data    = require("./data");
                require("dotenv").config();

(async function main() {
  const isElasticReady = await elastic.checkConnection();

  if (isElasticReady) {
    const elasticIndex = await elastic.esclient.indices.exists({index: elastic.index});

    if (!elasticIndex.body) {
      await elastic.createIndex(elastic.index);
      await elastic.setQuotesMapping();
      await data.populateDatabase()
    }

    server.start();
  }
})();

Launching the application

We’re now ready to start our application using docker-compose!

Just run the following command:

docker-compose up

You’ll need to wait until Docker downloads both the ElasticSearch and Node.js images, then it will boot up your server and you’ll be ready to query against your REST endpoints!

Let’s test with a couple of cURL calls:

curl localhost:3000/quotes?text=love&limit=3

{
  "success": true,
  "data": {
    "results": 716,
    "values": [
      {
        "id": "JDE3kGwBuLHMiUvv1itT",
        "quote": "There is only one happiness in life, to love and be loved.",
        "author": "George Sand",
        "score": 6.7102118
      },
      {
        "id": "JjE3kGwBuLHMiUvv1itT",
        "quote": "Live through feeling and you will live through love. For feeling is the language of the soul, and feeling is truth.",
        "author": "Matt Zotti",
        "score": 6.2868223
      },
      {
        "id": "NTE3kGwBuLHMiUvv1iFO",
        "quote": "Genuine love should first be directed at oneself if we do not love ourselves, how can we love others?",
        "author": "Dalai Lama",
        "score": 5.236455
      }
    ]
  }
}

So as you can see, we decided to limit our results to 3, but there are over 713 quotes!

We can easily get the next three quotes by calling:

curl localhost:3000/quotes?text=love&limit=3&page=2

{
  "success": true,
  "data": {
    "results": 716,
    "values": [
      {
        "id": "SsyHkGwBrOFNsaVmePwE",
        "quote": "Forgiveness is choosing to love. It is the first skill of self-giving love.",
        "author": "Mohandas Gandhi",
        "score": 4.93597
      },
      {
        "id": "rDE3kGwBuLHMiUvv1idS",
        "quote": "Neither a lofty degree of intelligence nor imagination nor both together go to the making of genius. Love, love, love, that is the soul of genius.",
        "author": "Wolfgang Amadeus Mozart",
        "score": 4.7821507
      },
      {
        "id": "TjE3kGwBuLHMiUvv1h9K",
        "quote": "Speak low, if you speak love.",
        "author": "William Shakespeare",
        "score": 4.6697206
      }
    ]
  }
}

And what if you need to insert a new quote? Just call the /quotes/new endpoint!

curl --request POST \
     --url http://localhost:3000/quotes/new \
     --header 'content-type: application/json' \
     --data '{
        "author": "Michele Riva",
        "quote": "Using Docker and ElasticSearch is challenging, but totally worth it."
}'

and the response will be:

{
  "success": true,
  "data": {
    "id": "is2QkGwBrOFNsaVmFAi8",
    "author": "Michele Riva",
    "quote": "Using Docker and ElasticSearch is challenging, but totally worth it."
  }
}

Conclusion

Docker makes it incredibly easy to manage our dependencies and their deployment. From that point, we could host our application on Heroku, AWS ECS, Google Cloud Container or any other Docker-based service with ease, without struggling to setup our server with their super-complex configurations.

Next steps?

• Learn how to use Kubernetes in order to scale your container and orchestrate more ElasticSearch Instances!
• Create a new endpoint that will allow you to update an existing quote. Mistakes can happen!
• And what about deleting a quote? How would you implement that endpoint?
• It would be great to save your quotes with tags (for instances, quotes about love, health, art)… try to update your quotes index!

Software development is fun. With Docker, Node, and ElasticSearch it’s even better!

Plug: LogRocket, a DVR for web apps

LogRocket is a frontend logging tool that lets you replay problems as if they happened in your own browser. Instead of guessing why errors happen, or asking users for screenshots and log dumps, LogRocket lets you replay the session to quickly understand what went wrong. It works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store.

In addition to logging Redux actions and state, LogRocket records console logs, JavaScript errors, stacktraces, network requests/responses with headers + bodies, browser metadata, and custom logs. It also instruments the DOM to record the HTML and CSS on the page, recreating pixel-perfect videos of even the most complex single-page apps.

What Is Server Management Software?

Server management software is a category of IT operations tooling that enables administrators to monitor, configure, automate, and maintain physical and virtual servers across on-premises data centres and cloud environments. Core capabilities typically include performance monitoring, patch management, alerting, capacity planning, remote access, and log aggregation. As infrastructure scales and hybrid cloud adoption grows, demand for unified server management platforms has increased significantly across enterprise and mid-market segments.

Market Landscape and Leading Vendors

The global server management software market is served by a mix of large platform vendors, specialist monitoring tools, and managed-service-oriented products. The research report in question highlights the following key players:

• Datadog – Cloud-scale infrastructure and application monitoring with deep integrations across public cloud providers.
• SolarWinds MSP – Remote monitoring and management (RMM) platform targeted at managed service providers.
• ManageEngine (Zoho Corp) – Broad IT management suite including OpManager for network and server monitoring.
• Microsoft – System Center suite and Azure Monitor for hybrid Windows and Linux server management.
• BMC Software – Enterprise-grade IT operations management including TrueSight and Helix platforms.
• Central Solutions – Targeted server administration and patch management tooling.
• Server Density – SaaS-based server and website monitoring (later acquired by StackPath).
• Percona – Open-source database and server management, particularly for MySQL and MongoDB environments.
• Infrascale – Backup and disaster recovery with server management integration.
• Adaxes (Softerra) – Active Directory and Windows Server administration automation.

The competitive landscape is characterised by significant R&D investment from both private vendors and, in some regions, government-backed technology initiatives aimed at modernising public-sector infrastructure management.

Market Segmentation

By Deployment Type

• On-premises – Traditional deployment within a customer’s own data centre, favoured in regulated industries.
• Cloud / SaaS – Vendor-hosted platforms offering faster deployment, elastic scaling, and lower upfront cost.
• Hybrid – A combination of local agents and cloud-based dashboards, increasingly common in enterprise environments.

By Access Terminal

• PC / Web Terminal – Browser-based or desktop consoles used by operations teams for day-to-day server administration.
• Mobile Terminal – Native mobile apps and responsive dashboards enabling on-call engineers to respond to alerts remotely.

By End-User Application

• Large enterprises requiring centralised visibility across thousands of nodes.
• Small and medium-sized businesses (SMBs) leveraging managed service providers for outsourced server operations.
• Managed service providers (MSPs) needing multi-tenant, white-label management platforms.
• Public sector and government organisations with strict compliance and audit requirements.

Regional Market Breakdown

The report analyses market size and growth across five key regions:

• North America – The largest regional market, driven by high cloud adoption, mature IT operations practices, and a dense concentration of software vendors.
• Europe – Steady growth supported by GDPR-driven infrastructure visibility requirements and increasing hybrid cloud deployments.
• Asia Pacific – The fastest-growing region, with large-scale digital transformation programmes in China, India, Japan, South Korea, and Southeast Asia.
• Middle East & Africa – Emerging growth, with government-led smart-city and e-government initiatives driving data centre investment.
• South America – Gradual adoption, led by Brazil and other economies investing in cloud and colocation infrastructure.

Key Growth Drivers

• Hybrid and multi-cloud adoption – As workloads span on-premises and multiple cloud providers, unified management tools become essential.
• Infrastructure complexity – Growing virtualisation and containerisation (Kubernetes, Docker) require more sophisticated server orchestration and monitoring.
• Security and compliance requirements – Regulatory frameworks such as GDPR, HIPAA, and PCI-DSS demand detailed audit trails and patch compliance reporting.
• Rise of MSPs – The managed services model shifts server management responsibility to specialist providers, creating sustained demand for RMM platforms.
• Automation and AIOps – AI-driven anomaly detection and automated remediation reduce mean time to resolution (MTTR) and lower operational overhead.
• Remote workforce – Distributed teams require robust remote server access and monitoring capabilities available from any device.

Market Challenges and Restraints

• Vendor lock-in concerns – Organisations are cautious about deep integration with proprietary platforms that are difficult to migrate away from.
• Integration complexity – Heterogeneous environments (mixed OS, legacy hardware, multi-cloud) complicate unified tooling.
• Cost of enterprise licences – High licensing fees for full-featured platforms can be prohibitive for SMBs.
• Skills shortage – A global shortage of qualified DevOps and systems administration professionals limits effective tool adoption.

Report Structure: Chapter Summary

The underlying market research report is structured across 15 chapters covering the full scope of the market analysis:

1. Chapters 1–2: Market definitions, product classifications, manufacturing cost structures, and supply chain overview.
2. Chapter 3: Technical data, manufacturing plant analysis, R&D status, and raw material sourcing.
3. Chapter 4: Overall market capacity, sales analysis, and pricing by company segment.
4. Chapters 5–6: Regional market breakdown including the United States, China, Europe, Japan, South Korea, and Taiwan; segmentation by product type.
5. Chapters 7–8: Segmentation by application; major manufacturer profiles.
6. Chapter 9: Market trend analysis by product type and access terminal (PC vs. mobile).
7. Chapter 10: Regional marketing strategies, international trade analysis, supply chain structure.
8. Chapter 11: Consumer analysis — buyer personas, purchasing patterns, and decision criteria.
9. Chapter 12: Research findings, conclusions, methodology, and data sources.
10. Chapters 13–15: Sales channel analysis, distributor and dealer networks, final conclusions, and appendix.

Why Server Management Software Matters for DevOps Teams

For DevOps practitioners, choosing the right server management platform directly affects deployment velocity, system reliability, and incident response time. When evaluating vendors, engineering teams should consider:

• API and automation depth – Does the platform expose APIs that integrate with CI/CD pipelines, Infrastructure as Code tooling (Terraform, Ansible), and incident management platforms (PagerDuty, Opsgenie)?
• Agent footprint – Lightweight, low-overhead agents are critical for high-density environments.
• Alerting granularity – Threshold-based and anomaly-based alerting with suppression and correlation capabilities reduce alert fatigue.
• Scalability and pricing model – Ensure pricing scales predictably as infrastructure grows; per-host models can become expensive at scale.
• Compliance reporting – Built-in audit and compliance reporting reduces manual work for regulated workloads.

The server management software market continues to consolidate, with larger observability and AIOps platforms absorbing point solutions. Engineering leaders tracking this space should monitor acquisition activity and open-source alternatives (such as Prometheus, Nagios, and Zabbix) alongside commercial offerings.

Original report summary sourced from bunburymail.com, August 2019. Market data and forecasts reflect the state of the market at the time of publication.

What Is Azure Dedicated Host?

Microsoft announced Azure Dedicated Host, a service that provisions single-tenant physical servers inside Azure data centers. Unlike standard virtual machines, which run on shared physical hardware alongside other customers’ workloads, an Azure Dedicated Host gives your organization exclusive use of the underlying physical machine. You then deploy your Azure VMs onto that dedicated hardware just as you would on any other Azure compute resource.

This is a meaningful architectural shift for enterprises that need hardware-level isolation rather than the logical isolation that ordinary virtual machines provide.

Why Hardware Isolation Matters

Standard multi-tenant cloud infrastructure is cost-effective, but it is not always appropriate. Common drivers for dedicated hardware include:

• Regulatory compliance – Industries such as finance, healthcare, and government often require demonstrable hardware-level isolation to satisfy auditors and regulators.
• Bring-your-own-license (BYOL) – Certain software vendors (notably Microsoft itself for Windows Server and SQL Server) allow existing on-premises per-core or per-socket licenses to be reused only on dedicated hardware.
• Security posture – Eliminating shared physical hardware removes a class of side-channel attack vectors (such as speculative-execution exploits) that are difficult to fully mitigate in multi-tenant environments.
• Controlled maintenance windows – On dedicated hosts, Azure exposes maintenance control options that let teams schedule host-level updates rather than accepting platform-driven restarts.

Supported Workloads and Operating Systems

Azure Dedicated Host supports virtual machines running Windows Server, Linux, and SQL Server. Hosts are available in different SKU families (for example, general-purpose, compute-optimized, or memory-optimized) that map to the underlying physical server specifications. The VM sizes you can deploy on a given host are determined by the host SKU you select.

Pricing Model

Azure Dedicated Host is billed per physical host, not per individual virtual machine. This means you pay for the entire host regardless of how many VMs are running on it. The practical implication is that the service becomes more cost-efficient the more densely you pack VMs onto the host. Pricing varies by host SKU and Azure region. Microsoft also offers Reserved Instances for Dedicated Hosts to reduce costs when committing to one- or three-year terms.

Host Groups: Organizing Dedicated Infrastructure

Azure allows you to create Host Groups, logical containers for multiple Dedicated Hosts. Host Groups operate within a single Azure region and can span multiple Availability Zones. This lets teams:

• Distribute workloads across hosts for fault tolerance.
• Manage related hosts as a single administrative unit.
• Optionally enable automatic VM placement so Azure selects the best available host within the group.

How Azure Dedicated Host Compares to Isolated VM Sizes

Azure already offered isolated VM sizes (such as the Standard_M128ms or certain Lsv2 sizes) that guarantee a VM occupies an entire physical host by virtue of consuming all available resources. Azure Dedicated Host is a different mechanism: you explicitly provision and manage the host, choose which VM sizes to run on it, and retain visibility into the physical layer. Isolated VM sizes are simpler but offer less control; Dedicated Host trades simplicity for greater flexibility and licensing transparency.

Competitive Landscape

Azure Dedicated Host entered a market where dedicated single-tenant hardware was already available from major cloud providers:

• Amazon Web Services offers EC2 Dedicated Hosts and Dedicated Instances, with similar per-host billing and BYOL support.
• Google Cloud provides Sole-Tenant Nodes, which operate on the same principle of exclusive physical server access within GCP’s infrastructure.

Microsoft’s entry strengthens Azure’s credibility with enterprise customers who have strict compliance requirements and had previously viewed the dedicated-hardware option as a reason to favor AWS.

Security and Compliance Considerations

Microsoft positions Dedicated Host as part of its broader enterprise compliance story. Because your organization controls which VMs run on the host, you can demonstrate to auditors that no other customer’s workloads co-reside on the same physical hardware. Azure’s standard security controls — including disk encryption, network security groups, Azure Defender, and Azure Policy — all apply to VMs running on Dedicated Hosts.

Key Takeaways for DevOps and Platform Teams

• Azure Dedicated Host is appropriate when compliance mandates, software licensing, or security policy require physical isolation — not simply logical isolation.
• Cost modelling should account for the per-host billing model; under-utilized hosts are expensive.
• Host Groups and Availability Zone support make it feasible to build resilient architectures on dedicated hardware.
• Existing Azure tooling (ARM templates, Terraform’s AzureRM provider, Bicep) supports Dedicated Host provisioning, so it integrates into standard IaC workflows.
• Evaluate BYOL eligibility carefully with your licensing team; the savings can be significant for SQL Server and Windows Server workloads at scale.

Can Ansible Manage Windows Systems?

Ansible is a widely used configuration management and automation tool with deep roots in the Linux ecosystem. However, it can also target Windows hosts for configuration, provisioning, and application lifecycle management. The catch: the setup process is noticeably more complex than it is on Linux, and there are meaningful constraints on how Windows machines can participate in an Ansible environment.

How Ansible Communicates with Windows Hosts

On Linux, Ansible uses SSH to communicate with managed nodes. Because SSH is available by default on most Linux distributions, getting Ansible to control a Linux host is relatively straightforward.

Windows is different. Rather than SSH, Ansible communicates with Windows hosts over WinRM (Windows Remote Management) using PowerShell. To prepare a Windows host for Ansible management, the following minimum requirements must be met on the managed node:

• PowerShell 3.0 or higher
• .NET Framework 4.0 or higher
• WinRM configured and enabled

Ansible’s official documentation includes a ConfigureRemotingForAnsible.ps1 script that automates much of the WinRM setup on Windows managed nodes. Running this script is typically one of the first steps when onboarding a Windows host.

Where the Ansible Control Node Must Run

A critical architectural point: the Ansible control node—including Ansible Tower (now AWX/Red Hat Ansible Automation Platform)—must run on Linux. Ansible itself cannot natively execute on a Windows host as the control machine.

If your only available machine is a Windows server, you have two realistic options:

• Run a Linux virtual machine on the Windows host and use that VM as the Ansible control node.
• Use Windows Subsystem for Linux (WSL)—a Microsoft feature available since Windows 10 that allows native Linux command-line tools to run on Windows. WSL can be installed from the Microsoft Store.

It is important to note that Ansible does not officially support WSL for production use. WSL may be suitable for development, testing, or learning purposes, but relying on it in a production environment is not recommended based on Ansible’s own guidance.

What Windows Can and Cannot Do in an Ansible Environment

Understanding the role Windows can play helps set accurate expectations:

Because Python modules cannot run directly on Windows managed nodes, teams that rely heavily on Python-based Ansible modules need to account for this. A common workaround is to run those modules on the Ansible controller itself using the delegate_to: localhost directive in a playbook task.

Setting Up Ansible to Manage a Windows Host: Key Steps

Unlike Linux, where a single apt-get install ansible or dnf install ansible command gets you most of the way there, managing Windows with Ansible requires several configuration steps across both the control node and the managed Windows host.

On the Windows Managed Node

1. Verify PowerShell 3.0+ and .NET 4.0+ are installed.
2. Enable and configure WinRM (use the Ansible-provided setup script for convenience).
3. Configure firewall rules to allow WinRM traffic (typically TCP 5985 for HTTP, 5986 for HTTPS).
4. Set up an appropriate authentication method (Basic, NTLM, Kerberos, or CredSSP depending on your environment).

On the Ansible Control Node (Linux)

1. Install Ansible on your Linux control node.
2. Install the pywinrm Python library, which Ansible requires to communicate with Windows hosts over WinRM: pip install pywinrm
3. Define Windows hosts in your inventory file with the correct connection variables:

[windows]
win-server-01 ansible_host=192.168.1.10

[windows:vars]
ansible_user=Administrator
ansible_password=YourPassword
ansible_connection=winrm
ansible_winrm_transport=ntlm
ansible_winrm_server_cert_validation=ignore

Always store credentials securely using Ansible Vault rather than plaintext in inventory files.

Why Windows Teams Should Still Consider Ansible

Despite the added complexity, Ansible offers real value for organizations running Windows infrastructure:

• Unified tooling: A single configuration management platform can manage both Linux and Windows infrastructure, reducing the number of tools teams need to learn and maintain.
• Agentless architecture: Like Linux, Windows managed nodes do not require an Ansible agent installed—only WinRM must be configured.
• Rich Windows module library: Ansible ships with many Windows-specific modules covering tasks such as managing IIS, Active Directory, Windows features, registry keys, services, and software packages.
• DevOps and automation adoption: Teams can use the same playbook-based workflows for Windows application lifecycle management as they do for Linux workloads.

Summary

Ansible can absolutely be used to manage Windows systems—but Windows is strictly a managed node, not a control node. The Ansible controller must run on Linux (directly, via VM, or via WSL for non-production use). Windows managed nodes communicate via WinRM and PowerShell rather than SSH. The setup involves more steps than a typical Linux Ansible deployment, but the payoff is a unified automation platform capable of managing your entire infrastructure regardless of operating system.

What Happened

In May 2019, security researchers at UpGuard discovered that Attunity — an Israeli data management, warehousing, and replication company — had left three AWS S3 buckets publicly accessible without authentication. The buckets were discovered on May 13, 2019, and were secured approximately three days later.

Attunity counts many of the world’s largest enterprises among its customers. The exposed buckets contained not only Attunity’s own internal data but also sensitive information belonging to prominent Fortune 100 clients, including Ford, Netflix, and TD Bank.

What Data Was Exposed

According to the UpGuard research team, the exposed S3 buckets contained a wide range of highly sensitive data. The categories of leaked information included:

• Backups of employee OneDrive accounts
• Internal email correspondence
• System passwords and private keys for production systems
• Sales and marketing contact information
• Project specifications and technical documentation
• Employee personal data
• Credentials for internal applications belonging to Attunity and at least one named client, Netflix
• Job account passwords and credentials related to manufacturing systems at unnamed client companies

UpGuard researchers noted that the 1 TB sample they downloaded was likely only a fraction of the total data stored in the exposed buckets. The actual volume of exposed data was almost certainly larger.

Why This Incident Was Especially Serious

Beyond the sheer volume and sensitivity of the exposed records, the incident carried significant lateral risk. Because the leaked data included private keys, system passwords, and credentials for internal applications, a malicious actor who found these buckets before researchers did could potentially have used them as a launchpad to access Attunity’s own internal network — and from there, potentially pivot into the networks of its enterprise clients.

This is a textbook example of supply-chain risk: a third-party vendor’s misconfiguration creating a potential entry point into the systems of the world’s largest companies.

Root Cause: Misconfigured S3 Bucket Permissions

The underlying cause was a misconfigured AWS S3 bucket access policy. By default, S3 buckets created today are private, but historically it was straightforward to accidentally set a bucket’s ACL (Access Control List) or bucket policy to allow public reads. Organizations that store sensitive data in S3 must explicitly audit bucket permissions to ensure no buckets are inadvertently world-readable.

Common reasons S3 buckets end up publicly exposed include:

• Developers setting permissive ACLs for testing and never reverting them
• Misconfigured bucket policies that grant s3:GetObject to * (all principals)
• Lack of automated scanning and alerting on bucket permission changes
• No enforcement of an AWS Organizations Service Control Policy (SCP) that blocks public bucket access account-wide

How to Prevent S3 Data Exposure: Practical Steps for DevOps Teams

The Attunity incident is far from unique — misconfigured S3 buckets have been responsible for numerous high-profile breaches. The following controls are considered baseline hygiene for any AWS environment that stores sensitive data.

1. Enable S3 Block Public Access at the Account Level

AWS provides a Block Public Access setting that can be enforced at both the individual bucket level and the AWS account level. Enabling all four Block Public Access options at the account level prevents any bucket in the account from being made public, regardless of bucket policy or ACL settings. This is the single most effective safeguard against accidental public exposure.

2. Apply Least-Privilege Bucket Policies

Every S3 bucket policy should grant only the minimum permissions required. Avoid wildcard principals ("Principal": "*") in bucket policies unless you specifically intend public access. Scope policies to specific IAM roles or AWS account IDs.

3. Use AWS Config Rules or Security Hub to Detect Drift

AWS Config includes managed rules such as s3-bucket-public-read-prohibited and s3-bucket-public-write-prohibited that continuously evaluate your buckets and alert you when a bucket becomes publicly accessible. AWS Security Hub aggregates these findings for centralized visibility.

4. Enable Server-Side Encryption and Enforce It via Policy

Encryption at rest does not prevent public exposure, but it does protect data if physical storage media is compromised. Use a bucket policy Condition that denies any PutObject request that does not include server-side encryption headers (aws:SecureTransport and s3:x-amz-server-side-encryption).

5. Enable S3 Access Logging and CloudTrail Data Events

S3 server access logs and CloudTrail data events record every request made to a bucket. This provides an audit trail that can reveal whether a bucket was accessed by unauthorized parties before a misconfiguration was corrected.

6. Audit Third-Party Vendor Cloud Posture

The Attunity breach underscores that your security posture is only as strong as the vendors who handle your data. Include cloud security configuration requirements in vendor contracts and assess vendor posture as part of third-party risk management programs.

Key Takeaways

• Three misconfigured, unauthenticated AWS S3 buckets exposed Attunity’s internal data and data belonging to major Fortune 100 clients including Ford, Netflix, and TD Bank.
• The exposure included passwords, private keys, and credentials that could have enabled further network intrusion.
• UpGuard researchers found the buckets on May 13, 2019; they were secured within three days.
• Enabling AWS S3 Block Public Access at the account level is the most effective single control to prevent this class of incident.
• Continuous compliance monitoring (AWS Config, Security Hub) and robust third-party vendor assessments are essential components of a mature cloud security program.

DevOps and cloud engineering teams should treat S3 bucket permission audits as a recurring operational task, not a one-time setup step. Permission drift is a real and well-documented risk.

What Is Server Management Software?

Server management software encompasses tools that allow IT operations and DevOps teams to monitor, configure, maintain, and secure physical and virtual servers from a centralized interface. These platforms typically combine real-time performance monitoring, alerting, patch management, remote access, log aggregation, and capacity planning into a single pane of glass.

As infrastructure grows in complexity — spanning on-premises hardware, cloud VMs, containers, and hybrid environments — server management software has become a foundational layer of any mature operations practice. The market has expanded significantly alongside the adoption of DevOps, site reliability engineering (SRE), and cloud-native architectures.

Leading Platforms in the Server Management Software Space

Several well-established vendors and open-source projects compete in this space. The following platforms are widely used by enterprise and mid-market operations teams:

• Datadog — A cloud-native monitoring and observability platform supporting infrastructure metrics, APM, log management, and synthetic monitoring across hybrid environments.
• SolarWinds — Offers a broad portfolio including Server & Application Monitor (SAM), providing deep Windows and Linux server visibility, alerting, and capacity forecasting.
• ManageEngine OpManager — A network and server monitoring tool from Zoho’s ManageEngine division, widely adopted in mid-market and enterprise IT departments.
• LogicMonitor — A SaaS-based infrastructure monitoring platform with agentless collection via collectors, strong for MSPs and distributed enterprise environments.
• Kaseya VSA — A remote monitoring and management (RMM) platform popular with managed service providers (MSPs) for endpoint and server management.
• ConnectWise Automate — Another RMM platform targeting MSPs, offering scripting, patch management, and remote control capabilities.
• Netwrix — Focuses on auditing, change tracking, and compliance reporting across Windows Server, Active Directory, and file systems.
• TeamViewer — Primarily known for remote access and support, with server monitoring features available in its business-tier offerings.
• Scalyr (now Dataset by Sentinels) — A high-performance log management and observability platform designed for large-scale operational data ingestion.
• MMSOFT Design (Pulseway) — A mobile-first server and network monitoring tool with a strong emphasis on real-time alerting and remote management from mobile devices.

Each platform occupies a different niche. The right choice depends on team size, existing toolchain, budget, and whether the environment is primarily on-premises, cloud, or hybrid.

Regional Adoption Patterns

Demand for server management software is global, but adoption patterns differ by region due to regulatory environments, infrastructure maturity, and cloud penetration rates:

• United States — The largest market, driven by a mature enterprise IT sector, high cloud adoption, and strong regulatory requirements (HIPAA, SOC 2, PCI-DSS) that make audit and compliance features critical.
• European Union — GDPR compliance requirements have increased demand for tools with strong data residency controls, audit logging, and access management.
• China — Rapid infrastructure buildout and local sovereignty requirements have spurred domestic platform development alongside adoption of international tools.
• Japan — A conservative enterprise IT market with high demand for stability, vendor support SLAs, and on-premises deployment options.
• India — A fast-growing market driven by IT services outsourcing, a large MSP ecosystem, and increasing cloud adoption.
• Southeast Asia — Emerging adoption, particularly in financial services and telecommunications, with growing interest in cloud-native monitoring platforms.

Core Capabilities to Evaluate

When assessing server management platforms, operations teams should evaluate the following functional areas:

1. Performance Monitoring and Alerting

Real-time visibility into CPU, memory, disk I/O, and network throughput is table stakes. Look for configurable alert thresholds, anomaly detection, and integrations with incident management tools like PagerDuty or Opsgenie.

2. Patch Management

Automated patching workflows reduce the manual burden of keeping servers current. Evaluate scheduling flexibility, rollback capabilities, and support for both Windows and Linux distributions.

3. Remote Access and Control

Secure remote shell access, file transfer, and session recording are essential for distributed teams. Ensure the solution supports MFA and maintains audit logs of all remote sessions.

4. Log Management and Audit Trails

Centralized log aggregation enables faster troubleshooting and supports compliance requirements. Evaluate retention periods, search performance at scale, and integration with SIEM platforms.

5. Asset Inventory and Configuration Management

Automatic discovery and inventory of servers, installed software, and hardware specifications provides the foundation for capacity planning and configuration drift detection.

6. Scalability and Multi-Tenancy

MSPs and large enterprises need platforms that support multiple tenants or organizational units with role-based access control (RBAC) and isolated dashboards.

Deployment Models: SaaS vs. On-Premises vs. Hybrid

Most modern server management platforms are available as SaaS offerings, which reduces operational overhead but may introduce data sovereignty concerns for regulated industries. On-premises deployments remain common in government, healthcare, and financial services. Many vendors now offer hybrid models where agents send data to either a cloud-hosted or self-hosted collector, giving teams flexibility over where data resides.

Integration with the Broader DevOps Toolchain

Server management software does not operate in isolation. The most effective implementations integrate with:

• CI/CD pipelines — Triggering deployment health checks post-release
• Configuration management tools — Ansible, Puppet, Chef, or SaltStack for enforcing desired state
• Cloud provider APIs — AWS CloudWatch, Azure Monitor, and GCP Cloud Monitoring for hybrid visibility
• Ticketing systems — Jira, ServiceNow, or Freshservice for automated incident creation
• Communication platforms — Slack or Microsoft Teams for alert notifications

Key Takeaways for DevOps and IT Operations Teams

• The server management software market includes both broad observability platforms (Datadog, SolarWinds) and specialized tools focused on MSP workflows (Kaseya, ConnectWise) or compliance (Netwrix).
• Evaluate platforms against your specific environment: OS mix, cloud footprint, team size, and compliance requirements.
• SaaS-based platforms generally offer faster time-to-value, while on-premises options provide greater data control.
• Integration depth with your existing DevOps toolchain is often a stronger differentiator than raw feature lists.
• Regional regulatory requirements — particularly GDPR in the EU and sector-specific mandates in the US — should influence your data residency and audit logging requirements.

Attribution: This article is based on content originally published by Opsview (opsview.com). Product claims reflect Opsview’s own documentation and marketing materials as of the original publish date (April 2017) and may not reflect the current product. Readers should verify current feature availability directly with the vendor.

Why Nagios Core Has Limits for Complex Environments

Nagios Core is free, flexible, and has a vast plugin ecosystem—but those strengths come with trade-offs. Configuration is entirely file-based, and a single syntax error can halt all monitoring activity. There is no built-in graphical configuration interface, no native SNMP trap handling, and no out-of-the-box SLA reporting. For a small, relatively static environment managed by an experienced Nagios administrator, these gaps are manageable. For larger, fast-changing environments with multiple teams and stakeholders, they become significant operational burdens.

The sections below cover the key capabilities that organisations typically need once they move beyond a basic Nagios deployment.

Usable Configuration Interface

One of the most immediate pain points with Nagios Core is its configuration model. Hosts, services, contacts, and escalation rules are all defined in flat text files. There is no validation layer beyond what Nagios checks at startup, and a misconfiguration silently breaks monitoring until it is fixed and the daemon is restarted.

Platforms built on top of Nagios—such as Opsview, Icinga, or Naemon—typically provide a web-based configuration UI that abstracts away the raw config files. This lowers the barrier to entry, reduces the risk of configuration errors, and allows non-expert team members to manage monitoring without needing to understand Nagios internals.

Role-Based Dashboards

Nagios Core’s default web interface presents a unified view of host and service states that is functional but not tailored to different audiences. In practice, a Windows systems administrator, a Linux administrator, a network engineer, and a business manager all need different views of monitoring data.

Enterprise monitoring platforms address this with role-based, customisable dashboards. Common capabilities include:

• Drag-and-drop dashboard builders that let administrators compose views from widgets such as service summary panels, performance graphs, and gauges.
• Role assignment so that a user logging in sees only the dashboards and data relevant to their responsibilities.
• Business service grouping that maps low-level host and service checks to higher-level business outcomes, often visualised with simple traffic-light status indicators.
• Read-only dashboard sharing for non-technical stakeholders such as executives or external clients who need visibility into service health without access to configuration.

Managed service providers (MSPs) can use role-based dashboards to give individual clients a view of their own SLA data without exposing other tenants’ information.

Auto-Discovery

In Nagios Core, every host and service must be defined manually in configuration files. In dynamic environments—where virtual machines are spun up and torn down regularly, or cloud workloads scale in and out—keeping configuration in sync with reality is a significant maintenance task.

Auto-discovery features scan networks, query cloud provider APIs, or inspect virtualisation platforms to detect new hosts and services automatically, then import them into the monitoring configuration. This is particularly valuable for:

• Initial onboarding of large existing environments.
• Keeping monitoring current in environments with frequent infrastructure changes.
• Reducing the manual effort of configuring monitoring for cloud or virtualised workloads.

Distributed Monitoring

When infrastructure spans multiple data centres, office locations, or cloud regions, a single central Nagios server may not be able to reach all monitored endpoints, and network latency can distort check results. Distributed monitoring architectures address this by placing monitoring nodes (variously called pollers, collectors, or slave servers) close to the resources they monitor.

While Nagios Core can participate in distributed setups using passive checks and NSCA, the configuration and maintenance of this is complex. More capable platforms provide managed distributed architectures where:

• Remote collector nodes are configured and managed centrally.
• Results are aggregated at a master server without requiring administrators to manually manage NSCA pipelines.
• The architecture can scale by adding additional collector nodes without restructuring the entire monitoring setup.

High Availability: Slave and Master Server Clustering

A standalone Nagios instance is a single point of failure. If the monitoring server goes down, you lose visibility across your entire infrastructure—exactly when you may most need it.

Enterprise platforms typically offer two layers of high availability:

• Collector/slave clustering: Multiple collector nodes can be grouped so that monitoring load is automatically balanced across them. If one collector fails, its checks are redistributed to remaining nodes without manual intervention.
• Master server clustering: The central management and reporting server can itself be clustered for redundancy, ensuring that configuration management and dashboards remain available even if a master node fails.

Agentless Windows Monitoring

Monitoring Windows hosts with Nagios Core typically requires installing an agent such as NSClient++ on each Windows machine. This is workable but introduces agent lifecycle management overhead—agents must be deployed, kept up to date, and monitored themselves.

Agentless Windows monitoring uses WMI (Windows Management Instrumentation) to query Windows hosts remotely without any software installed on the target machine. The practical advantages are:

• No agent deployment or maintenance overhead on Windows hosts.
• Easier onboarding of Windows machines in environments where software installation approval processes are slow.
• Flexibility to run agent-based monitoring where higher-frequency or more detailed checks are needed, and agentless monitoring everywhere else.

Flexible Host and Service Grouping

Nagios Core supports hostgroups and servicegroups for organising monitored resources, but these are static groupings defined in configuration files. In complex environments you often need to slice and filter monitored resources in multiple dimensions—by location, by business criticality, by application, by team ownership.

Tagging or keyword systems (as Opsview calls them) allow free-form labels to be applied to hosts and services. A host can carry multiple tags simultaneously, and operators can filter the monitoring view to show only hosts and services matching a particular tag or combination of tags. This provides flexibility that static group membership cannot easily replicate.

Host Attributes for Templated Service Configuration

When you need to monitor the same type of resource across many hosts—for example, a specific disk partition name that differs between servers—Nagios requires either separate service definitions for each host or complex use of custom variables. Host attribute features in more capable platforms let you define a set of variable parameters at the host level and then create service check templates that reference those parameters. The result is that a single service template can generate correctly configured checks across many hosts with different attribute values, dramatically reducing configuration duplication.

Distributed Alerting

In a distributed monitoring architecture, notification reliability matters. If the link between a remote collector and the central master server is lost, you still need alerts to be generated for issues detected at the remote site.

Distributed alerting allows remote collector nodes to send notifications autonomously when they cannot reach the master, ensuring that on-call engineers receive alerts regardless of WAN connectivity issues between monitoring tiers.

Network Mapping and Visualisation

Understanding parent-child relationships between network devices helps engineers quickly determine whether a downstream failure is caused by a genuine problem with that device or is a consequence of a parent device being unreachable. Nagios Core supports parent-child host relationships in its configuration, but visualisation is limited.

Network mapping features in enterprise platforms render these relationships graphically, showing device topology alongside real-time status. This makes it much faster to perform root cause analysis during an incident, particularly in complex multi-tier network environments.

SNMP Trap Processing

Nagios Core is a poll-based monitoring system: it initiates checks against targets on a schedule. It does not natively receive or process SNMP traps, which are unsolicited notifications sent by network devices when specific events occur (such as a link going down or a threshold being crossed).

For environments with significant network infrastructure—routers, switches, UPS units, and other SNMP-capable devices—trap processing is important because it provides near-real-time event notification that poll-based checking cannot match. Platforms with integrated SNMP engines can receive traps, parse them against MIB definitions, apply filtering rules, and translate them into monitoring alerts through the same interface used for all other checks.

Configuration Cloning

When adding hosts or services that are similar to existing ones, being able to clone an existing configuration and modify only the differing attributes saves significant time compared to building each configuration from scratch. This is especially useful during onboarding of new infrastructure where many similar devices need to be added quickly.

SLA and Availability Reporting

Nagios Core logs state history, but generating formatted SLA and availability reports from that data requires additional tooling. In practice, many teams end up manually compiling availability figures from log data—an error-prone and time-consuming process.

Enterprise monitoring platforms typically include reporting engines that can:

• Generate availability and SLA reports for specified hosts, services, or business service groups over configurable time periods.
• Schedule automatic report delivery by email.
• Export reports in multiple formats (PDF, HTML, spreadsheet formats) suitable for different audiences.

Service Desk Integration

When monitoring generates an alert, the typical operational response is to create a ticket in a service desk system. Doing this manually for every alert introduces delay and relies on on-call staff to act immediately. Automated service desk integration allows monitoring alerts to trigger ticket creation directly in ITSM platforms, eliminating the manual step and ensuring that every alert has an associated ticket for tracking and audit purposes.

Common integration targets include platforms such as ServiceNow, Atlassian Jira Service Management, and similar ITSM tools. The specific integrations supported vary by monitoring platform and version.

Flexible Notification Profiles

Nagios Core supports notification escalations and time-period-based notification suppression, but configuring fine-grained notification routing is complex. The result in many Nagios deployments is that teams receive too many alerts, or alerts go to the wrong people, leading to alert fatigue and missed incidents.

Notification profile systems let administrators configure rules such as:

• Send email alerts for a specific service only during business hours.
• Send SMS alerts for critical e-commerce services at any hour.
• Route alerts for Windows services to the Windows team, and Linux service alerts to the Linux team.
• Automatically create service desk tickets for high-severity alerts and assign them to the relevant engineer group.

APIs for Automation and Integration

In modern DevOps and infrastructure-as-code workflows, monitoring configuration needs to be manageable programmatically—not only through a web UI. REST APIs for monitoring platforms allow teams to:

• Automate the addition and removal of hosts and services as infrastructure changes (for example, integrating with Terraform or Ansible).
• Query current monitoring state from other tooling or dashboards.
• Trigger configuration reloads or acknowledgements from CI/CD pipelines.
• Integrate monitoring data into broader IT management or observability platforms.

Mobile Access

On-call engineers need to check monitoring status and acknowledge alerts from mobile devices. While Nagios Core’s web interface can be accessed via a mobile browser, dedicated mobile applications provide a better experience with features such as push notifications that alert engineers even when the app is not in the foreground.

Commercial Support

Nagios Core is community-supported. For test environments and non-critical monitoring this is generally acceptable, but for monitoring that underpins production infrastructure, having access to vendor support with defined response times is important. Commercial monitoring platforms built on Nagios foundations typically offer tiered support plans backed by engineers familiar with the product internals.

Evaluating Your Options

Nagios Core remains a viable starting point for many environments, and a significant ecosystem of Nagios-compatible tools, plugins, and extensions exists. However, the features described in this article—configuration UI, role-based dashboards, auto-discovery, distributed monitoring, HA clustering, agentless Windows monitoring, SNMP trap processing, SLA reporting, service desk integration, and automation APIs—represent a meaningful capability gap between bare Nagios Core and what most production IT operations teams need.

When evaluating whether to extend Nagios Core with additional tooling or move to a more complete platform, map your operational requirements against these capabilities and assess both the initial configuration cost and the ongoing maintenance burden of each approach.

Alternatives in the Nagios ecosystem and broader monitoring space include Icinga 2, Naemon, Zabbix, Opsview, and others. Each has different strengths, licensing models, and integration ecosystems. The right choice depends on your infrastructure scale, team skills, and budget.