Deleting dynamic host volumes in Nomad
While doing a bit of spring cleanup in the various Nomad clusters we host for us and our customers, I wanted to delete a few dynamic host volumes that were no longer in use.
While doing a bit of spring cleanup in the various Nomad clusters we host for us and our customers, I wanted to delete a few dynamic host volumes that were no longer in use.
A while ago, Nomad introduced the concept of Workload Identity to authenticate to Vault and obtain a Vault ACL token specific to the task. This way, Nomad jobs only have access to "their" own secrets, which provides an additional layer of security.
Recently, I encountered an issue with our new Nomad cluster. After adding a Nomad client node via a VPN connection, the node was successfully visible in Nomad and able to run workloads.
However, I experienced a problem with Nomad's built-in service discovery feature, which was unable to retrieve the correct IP address for a deployed service.
With the 1.10.0 release of Nomad, dynamic host volumes can now be managed without restarting a Nomad Client node to apply the configuration change.
I'm excited to announce that I've been selected as a HashiCorp Ambassador for 2025.
Writing Nomad Job files isn't that hard. Once you understand the basic structure, you can quickly write job files to deploy an application on a Nomad cluster.
Hashicorp Nomad is a simple and flexible scheduler and orchestrator that helps organizations reduce operational overhead and maximize infrastructure usage. We've been using Nomad to run our internal workloads since about 2018.
HashiCorp Boundary provides access to applications and critical systems with fine-grained authorizations without managing credentials or exposing your network internals.
In the process of migrating our workloads from our old Hashicorp Nomad cluster to the new cluster, I encountered an issue where our Sonatype Nexus instance failed to start properly in the new environment.