open-nomad/command/asset/connect.nomad.hcl
Charlie Voiselle 0b9ba1ae92
chore: Convert assets from bindatafs to go embeds (#16066)
* Convert assets from bindatafs to go embeds
* Add command/asset to "uninteresting" list for missing test check
* Remove generate-examples target
* Update paths in tests
2023-02-10 12:02:29 -05:00

480 lines
18 KiB
HCL

# There can only be a single job definition per file. This job is named
# "countdash" so it will create a job with the ID and Name "countdash".
# The "job" block is the top-most configuration option in the job
# specification. A job is a declarative specification of tasks that Nomad
# should run. Jobs have a globally unique name, one or many task groups, which
# are themselves collections of one or many tasks.
#
# For more information and examples on the "job" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/job.html
#
job "countdash" {
# The "region" parameter specifies the region in which to execute the job. If
# omitted, this inherits the default region name of "global".
# region = "global"
#
# The "datacenters" parameter specifies the list of datacenters which should
# be considered when placing this task. This accepts wildcards and defaults
# allowing placement on all datacenters.
datacenters = ["*"]
# The "type" parameter controls the type of job, which impacts the scheduler's
# decision on placement. This configuration is optional and defaults to
# "service". For a full list of job types and their differences, please see
# the online documentation.
#
# For more information, please see the online documentation at:
#
# https://www.nomadproject.io/docs/jobspec/schedulers.html
#
type = "service"
# The "constraint" block defines additional constraints for placing this job,
# in addition to any resource or driver constraints. This block may be placed
# at the "job", "group", or "task" level, and supports variable interpolation.
#
# For more information and examples on the "constraint" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/constraint.html
#
# constraint {
# attribute = "${attr.kernel.name}"
# value = "linux"
# }
# The "update" block specifies the update strategy of task groups. The update
# strategy is used to control things like rolling upgrades, canaries, and
# blue/green deployments. If omitted, no update strategy is enforced. The
# "update" block may be placed at the job or task group. When placed at the
# job, it applies to all groups within the job. When placed at both the job and
# group level, the blocks are merged with the group's taking precedence.
#
# For more information and examples on the "update" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/update.html
#
update {
# The "max_parallel" parameter specifies the maximum number of updates to
# perform in parallel. In this case, this specifies to update a single task
# at a time.
max_parallel = 1
# The "min_healthy_time" parameter specifies the minimum time the allocation
# must be in the healthy state before it is marked as healthy and unblocks
# further allocations from being updated.
min_healthy_time = "10s"
# The "healthy_deadline" parameter specifies the deadline in which the
# allocation must be marked as healthy after which the allocation is
# automatically transitioned to unhealthy. Transitioning to unhealthy will
# fail the deployment and potentially roll back the job if "auto_revert" is
# set to true.
healthy_deadline = "3m"
# The "progress_deadline" parameter specifies the deadline in which an
# allocation must be marked as healthy. The deadline begins when the first
# allocation for the deployment is created and is reset whenever an allocation
# as part of the deployment transitions to a healthy state. If no allocation
# transitions to the healthy state before the progress deadline, the
# deployment is marked as failed.
progress_deadline = "10m"
# The "auto_revert" parameter specifies if the job should auto-revert to the
# last stable job on deployment failure. A job is marked as stable if all the
# allocations as part of its deployment were marked healthy.
auto_revert = false
# The "canary" parameter specifies that changes to the job that would result
# in destructive updates should create the specified number of canaries
# without stopping any previous allocations. Once the operator determines the
# canaries are healthy, they can be promoted which unblocks a rolling update
# of the remaining allocations at a rate of "max_parallel".
#
# Further, setting "canary" equal to the count of the task group allows
# blue/green deployments. When the job is updated, a full set of the new
# version is deployed and upon promotion the old version is stopped.
canary = 0
}
# The migrate block specifies the group's strategy for migrating off of
# draining nodes. If omitted, a default migration strategy is applied.
#
# For more information on the "migrate" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/migrate.html
#
migrate {
# Specifies the number of task groups that can be migrated at the same
# time. This number must be less than the total count for the group as
# (count - max_parallel) will be left running during migrations.
max_parallel = 1
# Specifies the mechanism in which allocations health is determined. The
# potential values are "checks" or "task_states".
health_check = "checks"
# Specifies the minimum time the allocation must be in the healthy state
# before it is marked as healthy and unblocks further allocations from being
# migrated. This is specified using a label suffix like "30s" or "15m".
min_healthy_time = "10s"
# Specifies the deadline in which the allocation must be marked as healthy
# after which the allocation is automatically transitioned to unhealthy. This
# is specified using a label suffix like "2m" or "1h".
healthy_deadline = "5m"
}
# The "group" block defines a series of tasks that should be co-located on
# the same Nomad client. Any task within a group will be placed on the same
# client.
#
# For more information and examples on the "group" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/group.html
#
group "api" {
# The "count" parameter specifies the number of the task groups that should
# be running under this group. This value must be non-negative and defaults
# to 1.
count = 1
# The "restart" block configures a group's behavior on task failure. If
# left unspecified, a default restart policy is used based on the job type.
#
# For more information and examples on the "restart" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/restart.html
#
restart {
# The number of attempts to run the job within the specified interval.
attempts = 2
interval = "30m"
# The "delay" parameter specifies the duration to wait before restarting
# a task after it has failed.
delay = "15s"
# The "mode" parameter controls what happens when a task has restarted
# "attempts" times within the interval. "delay" mode delays the next
# restart until the next interval. "fail" mode does not restart the task
# if "attempts" has been hit within the interval.
mode = "fail"
}
# The "ephemeral_disk" block instructs Nomad to utilize an ephemeral disk
# instead of a hard disk requirement. Clients using this block should
# not specify disk requirements in the resources block of the task. All
# tasks in this group will share the same ephemeral disk.
#
# For more information and examples on the "ephemeral_disk" block, please
# see the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/ephemeral_disk.html
#
ephemeral_disk {
# When sticky is true and the task group is updated, the scheduler
# will prefer to place the updated allocation on the same node and
# will migrate the data. This is useful for tasks that store data
# that should persist across allocation updates.
# sticky = true
#
# Setting migrate to true results in the allocation directory of a
# sticky allocation directory to be migrated.
# migrate = true
#
# The "size" parameter specifies the size in MB of shared ephemeral disk
# between tasks in the group.
size = 300
}
# The "affinity" block enables operators to express placement preferences
# based on node attributes or metadata.
#
# For more information and examples on the "affinity" block, please
# see the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/affinity.html
#
# affinity {
# # attribute specifies the name of a node attribute or metadata
# attribute = "${node.datacenter}"
#
# # value specifies the desired attribute value. In this example Nomad
# # will prefer placement in the "us-west1" datacenter.
# value = "us-west1"
#
# # weight can be used to indicate relative preference
# # when the job has more than one affinity. It defaults to 50 if not set.
# weight = 100
# }
# The "spread" block allows operators to increase the failure tolerance of
# their applications by specifying a node attribute that allocations
# should be spread over.
#
# For more information and examples on the "spread" block, please
# see the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/spread.html
#
# spread {
# # attribute specifies the name of a node attribute or metadata
# attribute = "${node.datacenter}"
# }
# targets can be used to define desired percentages of allocations
# for each targeted attribute value.
#
# target "us-east1" {
# percent = 60
# }
# target "us-west1" {
# percent = 40
# }
# }
# The "network" block for a group creates a network namespace shared
# by all tasks within the group.
network {
# "mode" is the CNI plugin used to configure the network namespace.
# see the documentation for CNI plugins at:
#
# https://github.com/containernetworking/plugins
#
mode = "bridge"
# The service we define for this group is accessible only via
# Consul Connect, so we do not define ports in its network.
# port "http" {
# to = "8080"
# }
# The "dns" block allows operators to override the DNS configuration
# inherited by the host client.
# dns {
# servers = ["1.1.1.1"]
# }
}
# The "service" block enables Consul Connect.
service {
name = "count-api"
# The port in the service block is the port the service listens on.
# The Envoy proxy will automatically route traffic to that port
# inside the network namespace. If the application binds to localhost
# on this port, the task needs no additional network configuration.
port = "9001"
# The "check" block specifies a health check associated with the service.
# This can be specified multiple times to define multiple checks for the
# service. Note that checks run inside the task indicated by the "task"
# field.
#
# check {
# name = "alive"
# type = "tcp"
# task = "api"
# interval = "10s"
# timeout = "2s"
# }
connect {
# The "sidecar_service" block configures the Envoy sidecar admission
# controller. For each task group with a sidecar_service, Nomad will
# inject an Envoy task into the task group. A group network will be
# required and a dynamic port will be registered for remote services
# to connect to Envoy with the name `connect-proxy-<service>`.
#
# By default, Envoy will be run via its official upstream Docker image.
sidecar_service {}
}
}
# The "task" block creates an individual unit of work, such as a Docker
# container, web application, or batch processing.
#
# For more information and examples on the "task" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/task.html
#
task "web" {
# The "driver" parameter specifies the task driver that should be used to
# run the task.
driver = "docker"
# The "config" block specifies the driver configuration, which is passed
# directly to the driver to start the task. The details of configurations
# are specific to each driver, so please see specific driver
# documentation for more information.
config {
image = "hashicorpdev/counter-api:v3"
# The "auth_soft_fail" configuration instructs Nomad to try public
# repositories if the task fails to authenticate when pulling images
# and the Docker driver has an "auth" configuration block.
auth_soft_fail = true
}
# The "artifact" block instructs Nomad to download an artifact from a
# remote source prior to starting the task. This provides a convenient
# mechanism for downloading configuration files or data needed to run the
# task. It is possible to specify the "artifact" block multiple times to
# download multiple artifacts.
#
# For more information and examples on the "artifact" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/artifact.html
#
# artifact {
# source = "http://foo.com/artifact.tar.gz"
# options {
# checksum = "md5:c4aa853ad2215426eb7d70a21922e794"
# }
# }
# The "logs" block instructs the Nomad client on how many log files and
# the maximum size of those logs files to retain. Logging is enabled by
# default, but the "logs" block allows for finer-grained control over
# the log rotation and storage configuration.
#
# For more information and examples on the "logs" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/logs.html
#
# logs {
# max_files = 10
# max_file_size = 15
# }
# The "identity" block instructs Nomad to expose the task's workload
# identity token as an environment variable and in the file
# secrets/nomad_token.
# identity {
# env = true
# file = true
# }
# The "resources" block describes the requirements a task needs to
# execute. Resource requirements include memory, network, cpu, and more.
# This ensures the task will execute on a machine that contains enough
# resource capacity.
#
# For more information and examples on the "resources" block, please see
# the online documentation at:
#
# https://www.nomadproject.io/docs/job-specification/resources.html
#
resources {
cpu = 500 # 500 MHz
memory = 256 # 256MB
}
}
# The Envoy sidecar admission controller will inject an Envoy task into
# any task group for each service with a sidecar_service block it contains.
# A group network will be required and a dynamic port will be registered for
# remote services to connect to Envoy with the name `connect-proxy-<service>`.
# By default, Envoy will be run via its official upstream Docker image.
#
# There are two ways to modify the default behavior:
# * Tasks can define a `sidecar_task` block in the `connect` block
# that merges into the default sidecar configuration.
# * Add the `kind = "connect-proxy:<service>"` field to another task.
# That task will be replace the default Envoy proxy task entirely.
#
# task "connect-<service>" {
# kind = "connect-proxy:<service>"
# driver = "docker"
# config {
# image = "${meta.connect.sidecar_image}"
# args = [
# "-c", "${NOMAD_TASK_DIR}/bootstrap.json",
# "-l", "${meta.connect.log_level}"
# ]
# }
# resources {
# cpu = 100
# memory = 300
# }
# logs {
# max_files = 2
# max_file_size = 2
# }
# }
}
# This job has a second "group" block to define tasks that might be placed
# on a separate Nomad client from the group above.
#
group "dashboard" {
network {
mode = "bridge"
# The `static = 9002` parameter requests the Nomad scheduler reserve
# port 9002 on a host network interface. The `to = 9002` parameter
# forwards that host port to port 9002 inside the network namespace.
port "http" {
static = 9002
to = 9002
}
}
service {
name = "count-dashboard"
port = "9002"
connect {
sidecar_service {
proxy {
# The upstreams block defines the remote service to access
# (count-api) and what port to expose that service on inside
# the network namespace. This allows this task to reach the
# upstream at localhost:8080.
upstreams {
destination_name = "count-api"
local_bind_port = 8080
}
}
}
# The `sidecar_task` block modifies the default configuration
# of the Envoy proxy task.
# sidecar_task {
# resources {
# cpu = 1000
# memory = 512
# }
# }
}
}
task "dashboard" {
driver = "docker"
# The application can take advantage of automatically created
# environment variables to find the address of its upstream
# service.
env {
COUNTING_SERVICE_URL = "http://${NOMAD_UPSTREAM_ADDR_count_api}"
}
config {
image = "hashicorpdev/counter-dashboard:v3"
auth_soft_fail = true
}
}
}
}