2 # The "region" parameter specifies the region in which to execute the job.
3 # If omitted, this inherits the default region name of "global".
6 # The "datacenters" parameter specifies the list of datacenters which should
7 # be considered when placing this task. This must be provided.
8 datacenters = "${datacenters}"
10 # The "type" parameter controls the type of job, which impacts the scheduler's
11 # decision on placement. This configuration is optional and defaults to
12 # "service". For a full list of job types and their differences, please see
13 # the online documentation.
15 # For more information, please see the online documentation at:
17 # https://www.nomadproject.io/docs/jobspec/schedulers
22 # The "max_parallel" parameter specifies the maximum number of updates to
23 # perform in parallel. In this case, this specifies to update a single task
27 health_check = "checks"
29 # The "min_healthy_time" parameter specifies the minimum time the allocation
30 # must be in the healthy state before it is marked as healthy and unblocks
31 # further allocations from being updated.
32 min_healthy_time = "10s"
34 # The "healthy_deadline" parameter specifies the deadline in which the
35 # allocation must be marked as healthy after which the allocation is
36 # automatically transitioned to unhealthy. Transitioning to unhealthy will
37 # fail the deployment and potentially roll back the job if "auto_revert" is
39 healthy_deadline = "3m"
41 # The "progress_deadline" parameter specifies the deadline in which an
42 # allocation must be marked as healthy. The deadline begins when the first
43 # allocation for the deployment is created and is reset whenever an allocation
44 # as part of the deployment transitions to a healthy state. If no allocation
45 # transitions to the healthy state before the progress deadline, the
46 # deployment is marked as failed.
47 progress_deadline = "10m"
50 # The "canary" parameter specifies that changes to the job that would result
51 # in destructive updates should create the specified number of canaries
52 # without stopping any previous allocations. Once the operator determines the
53 # canaries are healthy, they can be promoted which unblocks a rolling update
54 # of the remaining allocations at a rate of "max_parallel".
56 # Further, setting "canary" equal to the count of the task group allows
57 # blue/green deployments. When the job is updated, a full set of the new
58 # version is deployed and upon promotion the old version is stopped.
61 # Specifies if the job should auto-promote to the canary version when all
62 # canaries become healthy during a deployment. Defaults to false which means
63 # canaries must be manually updated with the nomad deployment promote
67 # The "auto_revert" parameter specifies if the job should auto-revert to the
68 # last stable job on deployment failure. A job is marked as stable if all the
69 # allocations as part of its deployment were marked healthy.
74 # The reschedule stanza specifies the group's rescheduling strategy. If
75 # specified at the job level, the configuration will apply to all groups
76 # within the job. If the reschedule stanza is present on both the job and the
77 # group, they are merged with the group stanza taking the highest precedence
81 delay_function = "constant"
85 # The "group" stanza defines a series of tasks that should be co-located on
86 # the same Nomad client. Any task within a group will be placed on the same
89 # For more information and examples on the "group" stanza, please see
90 # the online documentation at:
92 # https://www.nomadproject.io/docs/job-specification/group
94 group "prod-group1-${service_name}" {
95 # The "count" parameter specifies the number of the task groups that should
96 # be running under this group. This value must be non-negative and defaults
98 count = ${group_count}
100 # The restart stanza configures a tasks's behavior on task failure. Restarts
101 # happen on the client that is running the task.
103 # https://www.nomadproject.io/docs/job-specification/restart
112 # The constraint allows restricting the set of eligible nodes. Constraints
113 # may filter on attributes or client metadata.
115 # For more information and examples on the "volume" stanza, please see
116 # the online documentation at:
118 # https://www.nomadproject.io/docs/job-specification/constraint
121 attribute = "$${attr.cpu.arch}"
127 attribute = "$${node.class}"
131 # The "task" stanza creates an individual unit of work, such as a Docker
132 # container, web application, or batch processing.
134 # For more information and examples on the "task" stanza, please see
135 # the online documentation at:
137 # https://www.nomadproject.io/docs/job-specification/task
139 task "prod-task1-${service_name}" {
140 # The "driver" parameter specifies the task driver that should be used to
144 %{ if use_vault_provider }
146 policies = "${vault_kv_policy_name}"
150 # The "config" stanza specifies the driver configuration, which is passed
151 # directly to the driver to start the task. The details of configurations
152 # are specific to each driver, so please see specific driver
153 # documentation for more information.
155 command = "local/alertmanager-${version}.linux-amd64/alertmanager"
157 "--config.file=secrets/alertmanager.yml"
161 # The artifact stanza instructs Nomad to fetch and unpack a remote resource,
162 # such as a file, tarball, or binary. Nomad downloads artifacts using the
163 # popular go-getter library, which permits downloading artifacts from a
164 # variety of locations using a URL as the input source.
166 # For more information and examples on the "artifact" stanza, please see
167 # the online documentation at:
169 # https://www.nomadproject.io/docs/job-specification/artifact
175 # The "template" stanza instructs Nomad to manage a template, such as
176 # a configuration file or script. This template can optionally pull data
177 # from Consul or Vault to populate runtime configuration data.
179 # For more information and examples on the "template" stanza, please see
180 # the online documentation at:
182 # https://www.nomadproject.io/docs/job-specification/template
186 change_signal = "SIGINT"
187 destination = "secrets/alertmanager.yml"
188 left_delimiter = "{{{"
189 right_delimiter = "}}}"
191 # The directory from which notification templates are read.
193 - '/etc/alertmanager/template/*.tmpl'
196 # # CA certificate to validate the server certificate with.
197 # ca_file: <filepath> ]
199 # # Certificate and key files for client cert authentication to the server.
200 # cert_file: <filepath>
201 # key_file: <filepath>
203 # # ServerName extension to indicate the name of the server.
204 # # http://tools.ietf.org/html/rfc4366#section-3.1
205 # server_name: <string>
207 # # Disable validation of the server certificate.
208 # insecure_skip_verify: true
210 # The root route on which each incoming alert enters.
212 receiver: '${slack_default_receiver}'
214 # The labels by which incoming alerts are grouped together. For example,
215 # multiple alerts coming in for cluster=A and alertname=LatencyHigh would
216 # be batched into a single group.
218 # To aggregate by all possible labels use '...' as the sole label name.
219 # This effectively disables aggregation entirely, passing through all
220 # alerts as-is. This is unlikely to be what you want, unless you have
221 # a very low alert volume or your upstream notification system performs
222 # its own grouping. Example: group_by: [...]
223 group_by: ['alertname']
225 # When a new group of alerts is created by an incoming alert, wait at
226 # least 'group_wait' to send the initial notification.
227 # This way ensures that you get multiple alerts for the same group that start
228 # firing shortly after another are batched together on the first
232 # When the first notification was sent, wait 'group_interval' to send a batch
233 # of new alerts that started firing for that group.
236 # If an alert has successfully been sent, wait 'repeat_interval' to
240 # All the above attributes are inherited by all child routes and can
241 # overwritten on each.
242 # The child route trees.
245 alertname: JenkinsJob.*
246 receiver: ${slack_jenkins_receiver}
250 receiver: '${slack_jenkins_receiver}'
254 receiver: ${slack_default_receiver}
258 receiver: '${slack_default_receiver}'
260 # Inhibition rules allow to mute a set of alerts given that another alert is
262 # We use this to mute any warning-level notifications if the same alert is
269 equal: ['alertname', 'instance']
272 - name: '${slack_jenkins_receiver}'
274 - api_url: 'https://hooks.slack.com/services/${slack_jenkins_api_key}'
275 channel: '#${slack_jenkins_channel}'
277 icon_url: https://avatars3.githubusercontent.com/u/3380462
279 [{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonLabels.alertname }} for {{ .CommonLabels.job }}
280 {{- if gt (len .CommonLabels) (len .GroupLabels) -}}
282 {{- with .CommonLabels.Remove .GroupLabels.Names }}
283 {{- range $index, $label := .SortedPairs -}}
284 {{ if $index }}, {{ end }}
285 {{- $label.Name }}="{{ $label.Value -}}"
292 *Alert:* {{ .Annotations.summary }}{{ if .Labels.severity }} - `{{ .Labels.severity }}`{{ end }}
294 *Description:* {{ .Annotations.description }}
297 {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
301 - name: '${slack_default_receiver}'
303 - api_url: 'https://hooks.slack.com/services/${slack_default_api_key}'
304 channel: '#${slack_default_channel}'
306 icon_url: https://avatars3.githubusercontent.com/u/3380462
308 [{{ .Status | toUpper }}{{ if eq .Status "firing" }}:{{ .Alerts.Firing | len }}{{ end }}] {{ .CommonLabels.alertname }} for {{ .CommonLabels.job }}
309 {{- if gt (len .CommonLabels) (len .GroupLabels) -}}
311 {{- with .CommonLabels.Remove .GroupLabels.Names }}
312 {{- range $index, $label := .SortedPairs -}}
313 {{ if $index }}, {{ end }}
314 {{- $label.Name }}="{{ $label.Value -}}"
321 *Alert:* {{ .Annotations.summary }}{{ if .Labels.severity }} - `{{ .Labels.severity }}`{{ end }}
323 *Description:* {{ .Annotations.description }}
326 {{ range .Labels.SortedPairs }} • *{{ .Name }}:* `{{ .Value }}`
332 # The service stanza instructs Nomad to register a service with Consul.
334 # For more information and examples on the "task" stanza, please see
335 # the online documentation at:
337 # https://www.nomadproject.io/docs/job-specification/service
340 name = "${service_name}"
341 port = "${service_name}"
342 tags = [ "${service_name}$${NOMAD_ALLOC_INDEX}" ]
344 name = "Alertmanager Check Live"
352 # The "resources" stanza describes the requirements a task needs to
353 # execute. Resource requirements include memory, network, cpu, and more.
354 # This ensures the task will execute on a machine that contains enough
357 # For more information and examples on the "resources" stanza, please see
358 # the online documentation at:
360 # https://www.nomadproject.io/docs/job-specification/resources
365 # The network stanza specifies the networking requirements for the task
366 # group, including the network mode and port allocations. When scheduling
367 # jobs in Nomad they are provisioned across your fleet of machines along
368 # with other jobs and services. Because you don't know in advance what host
369 # your job will be provisioned on, Nomad will provide your tasks with
370 # network configuration when they start up.
372 # For more information and examples on the "template" stanza, please see
373 # the online documentation at:
375 # https://www.nomadproject.io/docs/job-specification/network
378 port "${service_name}" {