Friday 1 March 2024

Resolving Pre-Configuration Issues for Sonar with Elasticsearch and Tuning 'vm.max_map_count'


In large-scale deployments, integrating SonarQube (Sonar) with an Elasticsearch stack for code analysis can lead to configuration challenges. A common hurdle DevOps Engineers encounter is the 'vm.max_map_count' setting on the Elasticsearch nodes. This article delves into understanding why this setting is crucial, how to resolve pre-configuration issues, and the steps to adjust it for optimal performance.

Why 'vm.max_map_count' Matters

  • Elasticsearch Memory Mapping: Elasticsearch heavily relies on virtual memory mapping for its indexing and search operations. The 'vm.max_map_count' kernel setting on Linux systems limits the maximum number of virtual memory areas a process can have.
  • SonarQube and Indexing: When Sonar analyzes large codebases, it sends a significant amount of data to Elasticsearch for indexing. If the 'vm.max_map_count' value is too low, Elasticsearch may run out of available virtual memory areas, leading to errors and instability.

Pre-Configuration Checks

  1. Baseline: Before modifying the setting, check the current value on your Elasticsearch nodes:

    Bash
    sysctl -a | grep vm.max_map_count
    
  2. SonarQube Recommendations: Refer to the official SonarQube documentation for recommended 'vm.max_map_count' settings based on your deployment size and expected project load.

Configuring 'vm.max_map_count'

  1. Temporary Adjustment: To temporarily change the setting for the current session:

    Bash
    sudo sysctl -w vm.max_map_count=262144  # Example value
    
  2. Permanent Change: To persistently modify the setting, edit the /etc/sysctl.conf file:

    Bash
    sudo nano /etc/sysctl.conf 
    

    Add the following line:

    vm.max_map_count = 262144  # Adjust the value as needed
    

    Save the file and apply the changes:

    Bash
    sudo sysctl -p
    

Additional Considerations

  • Heap Size: Ensure your Elasticsearch nodes have sufficient memory allocated to the heap (consult SonarQube documentation for recommendations). Increasing 'vm.max_map_count' without adequate memory can lead to other performance issues.
  • Monitoring: After making the changes, closely monitor Elasticsearch and SonarQube performance. Look for errors related to memory mapping or out-of-memory exceptions.
  • Alternative File Storage: For very large-scale deployments, investigate alternative file storage options for Elasticsearch that may be less reliant on memory mapping.

Important Notes:

  • The appropriate value for 'vm.max_map_count' will depend on your specific deployment. Start with the SonarQube recommendations and adjust as needed.
  • Thoroughly test any configuration changes in a staging environment before applying them to production.

Let me know if you'd like a more tailored guide with specific values based on your deployment scale and SonarQube version!

Thursday 29 February 2024

Terraform configuration to build a Zero-trust network



Terraform configuration to build a Zero-trust network for web applications in Azure MS, with Azure Firewall and application gateways:

Terraform
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = ">= 3.0.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "zerotrust" {
  name     = "zerotrust-rg"
  location = "westus"
}

resource "azurerm_virtual_network" "app-vnet" {
  name     = "app-vnet"
  location = azurerm_resource_group.zerotrust.location
  address_prefixes = ["10.0.0.0/16"]

  subnet {
    name         = "app-subnet"
    address_prefix = "10.0.1.0/24"
  }
}

resource "azurerm_application_gateway" "app-gw" {
  name     = "app-gw"
  location = azurerm_resource_group.zerotrust.location
  capacity = 2

  frontend_port {
    name     = "http"
    port     = 80
    protocol = "Http"
  }

  frontend_port {
    name     = "https"
    port     = 443
    protocol = "Https"
  }

  backend_address_pool {
    name = "app-backend-pool"
  }

  frontend_ip_configuration {
    name   = "app-frontend-ip"
    public_ip_address_id = null
  }

  listener {
    name                 = "http-listener"
    protocol             = "Http"
    frontend_port_name   = "http"
    frontend_ip_config_name = "app-frontend-ip"
  }

  listener {
    name                 = "https-listener"
    protocol             = "Https"
    frontend_port_name   = "https"
    frontend_ip_config_name = "app-frontend-ip"
  }

  request_routing_rule {
    name         = "app-http-rule"
    listener_name = "http-listener"
    backend_address_pool_name = "app-backend-pool"
    backend_http_setting_name = "app-http-setting"
  }

  request_routing_rule {
    name         = "app-https-rule"
    listener_name = "https-listener"
    backend_address_pool_name = "app-backend-pool"
    backend_http_setting_name = "app-https-setting"
  }

  backend_http_setting {
    name         = "app-http-setting"
    idle_timeout_in_minutes = 10

    path_rule {
      name         = "app-rule"
      path_patterns = ["/*"]
      backend_pool_name = "app-backend-pool"
      backend_http_setting_name = "app-http-setting"
    }
  }

  backend_http_setting {
    name         = "app-https-setting"
    idle_timeout_in_minutes = 10

    path_rule {
      name         = "app-rule"
      path_patterns = ["/*"]
      backend_pool_name = "app-backend-pool"
      backend_http_setting_name = "app-https-setting"
    }
  }

  probe {
    name        = "app-probe"
    path        = "/"
    interval_in_seconds = 30
    threshold = 3
  }

  health_monitor {
    name     = "app-monitor"
    probe_name = "app-probe"
  }
}
YAML
---
- name: Provision whitelist configuration
  hosts: all
  become: true
  tasks:
    - name: Get whitelist data from database
      uri:
        url: "https://database

OBS: 

Disclaimer

This Terraform and Ansible code is provided for informational purposes only and should not be considered production-ready. Running this code may have unintended consequences and could potentially compromise your Azure environment.

By using this code, you assume all risk and responsibility for any damages or losses that may occur. It is highly recommended to thoroughly understand the code and modify it to fit your specific needs and security requirements before deploying it in a production environment.

Additionally, always consult with qualified Azure and security professionals before implementing any changes in your environment.


Source Code:


What are the steps to remove a Git branch from both my local machine and the remote repository?

Many times, I found myself having to delete Git repositories as part of my daily duties. Following some of the documentation online, I tried...