Windows clients

Nomad Enterprise's platform-agnostic design extends to Windows environments, including Windows Subsystem for Linux 2 (WSL2). While core functionalities remain consistent, operating Nomad Enterprise on Windows presents unique considerations in file systems, process management, networking, and security.

This section highlights these Windows-specific nuances, offering key insights and best practices for effectively implementing and managing Nomad Enterprise in Windows ecosystems.

Path conventions

Golang uses a backslash \ as an escape character which conflicts with Windows file system conventions. To work around this, utilize a double backslash for Windows specific paths.

# Windows data_dir = "C:\\nomad\\data"
# Linux/WSL2 data_dir = "/opt/nomad/data"

Allocation isolation

Windows does not have a concept of Cgroups, therefore there is no filesystem isolation that occurs within Windows which means the exec and exec2 drivers are not supported.

For any executable workloads, you must use the raw_exec driver. This creates a security concern were the allocation ever compromised, as the entire underlying Windows host is then exposed.

Docker and Podman orchestration

It is important to note that the correct setup and configuration of Docker and Podman on Windows are prerequisites for Nomad Enterprise's integration. However, the specifics of configuring these container engines are beyond the scope of this document.

For detailed guidance on setting up Docker and Podman on Windows, please refer to their respective official documentation:

• Docker for Windows
• Podman on Windows

For information on configuring Nomad to work with Docker and Podman, please consult the official Nomad documentation:

• Nomad Docker driver
• Nomad Podman driver

Allowed caps

You need to define allow_caps=["all"] in your Docker plugin configuration, otherwise container workloads fail to deploy.

IPv6

Unless you are using IPv6, Nomad Enterprise advertises the ipv6 address by default over IPv4. Disable this functionality by setting the advertise_ipv6_address = false in the Nomad client configuration or completely turn off IPv6 on the network interface.

Logs

Nomad Enterprise logging on Windows is not automatically integrated with the Windows Event Viewer. By default, these log files continuously grow without any built-in size limitation, potentially consuming all available disk space.
To prevent this, it is highly recommended to implement log rotation. You can configure Nomad Enterprise to limit the total log storage to 5MB using the following log rotation options:

client {
    log_file = "C:\\Nomad\\logs.txt"
    log_rotate_bytes = "100000"
    log_rotate_max_files = "5"
}

Volumes

SMB mounts are commonly used in Windows environments for various workloads. Nomad Enterprise can leverage these existing drive mounts, however for container workloads, the underlying Windows filesystem is not accessible.
To enable this, add the following to your Nomad client configuration.

plugin "docker" {
    config {
        volumes {
            enabled = true
        }
  }
}

This configuration enables Nomad Enterprise to access all Windows volumes on the host, including but not limited to SMB mounts. It grants containerized workloads the ability to utilize any mounted drive or volume present on the Windows host system.

WSL2 networking

By default, WSL uses a NAT (network address translation) based architecture for networking. This is not ideal when accessing WSL2-hosted applications. Enable network mirror mode to enable the newer networking architecture for WSL2 and allow external access to your applications within WSL2.

Example Nomad Windows client configuration

data_dir = "C:\\Nomad"

# Specifies which address the Nomad agent should bind to for network services,
# including the HTTP interface as well as the internal gossip protocol and RPC mechanism.

bind_addr = "0.0.0.0"

log_file = "C:\\Nomad\\logs.txt"
log_rotate_bytes = "100000"
log_rotate_max_files = "5"

client {
    enabled = true

#Specifies a list of server addresses to join and will continue to attempt
#to join even after a failure at a specified occurrence.
    server_join {
        retry_join = [ "1.1.1.1", "2.2.2.2", "3.3.3.3" ] #Replace these with the IPs of the server nodes
        retry_max = 3
        retry_interval = "15s"
    }
}

plugin "docker" {
    allow_caps = ["all"]
    config {
        volumes {
            enabled = true
        }
    }
}