Deploy and update a job
Now that you have deployed your Nomad cluster and configured the CLI to interact with it, the next step is deploying an application.
In this tutorial, you will deploy and update an example application. In the process, you will learn about the Nomad job specification.
The example application runs in Docker containers and consists of a database and a web frontend that reads from the database. You will set up the database with a parameterized batch job and then use a periodic batch job to start additional short-lived jobs that write data to the database.
Job types
Nomad supports several job types including service, parameterized and periodic batch jobs, and system. In this tutorial, you will be introduced to the service job and both parameterized and periodic batch jobs.
Service jobs are for long lived services that run until explicitly stopped.
Batch jobs are for short lived jobs that run until they exit successfully.
- The parameterized block lets you configure a batch job to accept required or optional inputs. You trigger the job with the
nomad job dispatch
command. - The periodic block lets you schedule a Nomad job to run at set times. These are also known as a Nomad cron jobs.
Review the example application
The example application simulates employees working at a technology company. They come online, complete their tasks, and then log off.
Navigate to the jobs
directory of the example repository on your local machine
Note
If you are following the getting started collection and are using a cloud-based cluster, navigate back to the root of the repository's directory first.
Each of the jobspec files below that make up the application sets the driver
attribute to docker
and specifies an image stored on the GitHub Container Registry in the config
block with the image
attribute. The Redis job is the exception as it uses an official Redis image hosted on Docker Hub. By default, Nomad looks for images on Docker Hub so the full path including https://
is not necessary for the Redis job.
The parameterized and periodic configurations of the pytechco-setup
and pytechco-employee
jobs below are more advanced use cases of the jobspec system and are here to provide an example of what you can do with batch jobs. Many users only use service type jobs because the applications they deploy are long-living. Not all applications require batch jobs and it is okay if yours does not use them.
pytechco-redis.nomad.hcl
- This service job runs and exposes a Redis database as a Nomad service for the other application components to connect to. The jobspec sets the type toservice
, configures a Nomadservice
block to use Nomad's native service discovery, and creates a service namedredis-svc
.pytechco-web.nomad.hcl
- This service jobs runs the web application frontend that displays the values stored in the database and the active employees. The jobspec sets the type toservice
and uses a static port of5000
for the application. It also uses thenomadService
built-in function to retrieve address and port information of the Redis database service.pytechco-setup.nomad.hcl
- This parameterized batch job sets up the database with default values. You can dispatch it multiple times to reset the database. The jobspec sets the type tobatch
and has aparameterized
block with ameta_required
attribute that requires a value forbudget
when dispatching.pytechco-employee.nomad.hcl
- This periodic batch job brings an employee online. It randomizes the employee's job type and other variables such as how long they work for and the rate at which they complete their tasks. The jobspec sets the type tobatch
and has aperiodic
block that sets thecron
attribute to a value that will allow it to start a new job every 3 seconds.
As of Nomad 1.5.0, the datacenter
attribute defaults to all available datacenters in the cluster ("*"
). As a result, the jobspecs for this tutorial omit the attribute because the default value is sufficient. If you are running earlier versions of the Nomad CLI and cluster binary, you will need to include and set the attribute.
Deploy the application
The Docker images in the jobspec files are pre-built but you can checkout and modify the source code and rebuild them. If you do, be sure that you publish them to an accessible image repository like Docker Hub or GitHub Container Registry and update each of the corresponding jobspecs with the new image locations.
Submit the database job.
Submit the webapp frontend job.
Get the IP address of the webapp. The following command gets the allocation ID of the web job and uses that ID to get the status of the allocation. It then searches for the IP address in the allocation status output and formats the IP address into a link with the webapp's port. Open the URL from the output in your browser to see the webapp frontend.
Submit the setup job.
Dispatch the setup job by providing a value for budget.
Submit the employee job.
Navigate to the Nomad UI, click on the Jobs page, and then click on the pytechco-employee
job. Since this is a cron batch job, you can see that it creates a new job every three seconds.
Navigate back to the webapp URL. Note how new employees come online under the Online Employees section as the pytechco-employee
batch job creates new jobs.
Update the application
By default, the example application randomizes the type of employee it brings online. However, you can configure it to only bring on employees of a specific type.
Update the employee jobspec to bring only sales engineers online and increase the budget by dispatching the setup job again.
Stop the employee job. The -purge
flag removes the job history and any children jobs from the Nomad database, and also removes them from the Nomad UI. If they still show up in the UI, you can force Nomad to do a garbage collection to remove them from the UI with nomad system gc
.
Reset the database by dispatching the setup job again with a new budget of 500
.
Open the pytechco-employee.nomad.hcl
file and uncomment the args
block of the task config to have the job create only employees of the type sales_engineer
. Then update the cron to 0/1 * * * * * *
to have the job run every second. Save the file.
Submit the employee job again and navigate to the webapp. Note how all of the online employees are now only Sales Engineers and more of them are online at any given time.
The simulation will continue running until the amount of money reaches 0.
Next steps
In this tutorial, you submitted jobs to Nomad, updated a jobspec, and resubmitted it to Nomad. Continue on to the next tutorial by clicking on the Next button below and learn how to clean up the jobs and your cluster.