github.com/jrxfive/nomad@v0.6.1-0.20170802162750-1fef470e89bf/command/init.go (about) 1 package command 2 3 import ( 4 "fmt" 5 "io/ioutil" 6 "os" 7 "strings" 8 ) 9 10 const ( 11 // DefaultInitName is the default name we use when 12 // initializing the example file 13 DefaultInitName = "example.nomad" 14 ) 15 16 // InitCommand generates a new job template that you can customize to your 17 // liking, like vagrant init 18 type InitCommand struct { 19 Meta 20 } 21 22 func (c *InitCommand) Help() string { 23 helpText := ` 24 Usage: nomad init 25 26 Creates an example job file that can be used as a starting 27 point to customize further. 28 ` 29 return strings.TrimSpace(helpText) 30 } 31 32 func (c *InitCommand) Synopsis() string { 33 return "Create an example job file" 34 } 35 36 func (c *InitCommand) Run(args []string) int { 37 // Check for misuse 38 if len(args) != 0 { 39 c.Ui.Error(c.Help()) 40 return 1 41 } 42 43 // Check if the file already exists 44 _, err := os.Stat(DefaultInitName) 45 if err != nil && !os.IsNotExist(err) { 46 c.Ui.Error(fmt.Sprintf("Failed to stat '%s': %v", DefaultInitName, err)) 47 return 1 48 } 49 if !os.IsNotExist(err) { 50 c.Ui.Error(fmt.Sprintf("Job '%s' already exists", DefaultInitName)) 51 return 1 52 } 53 54 // Write out the example 55 err = ioutil.WriteFile(DefaultInitName, []byte(defaultJob), 0660) 56 if err != nil { 57 c.Ui.Error(fmt.Sprintf("Failed to write '%s': %v", DefaultInitName, err)) 58 return 1 59 } 60 61 // Success 62 c.Ui.Output(fmt.Sprintf("Example job file written to %s", DefaultInitName)) 63 return 0 64 } 65 66 var defaultJob = strings.TrimSpace(` 67 # There can only be a single job definition per file. This job is named 68 # "example" so it will create a job with the ID and Name "example". 69 70 # The "job" stanza is the top-most configuration option in the job 71 # specification. A job is a declarative specification of tasks that Nomad 72 # should run. Jobs have a globally unique name, one or many task groups, which 73 # are themselves collections of one or many tasks. 74 # 75 # For more information and examples on the "job" stanza, please see 76 # the online documentation at: 77 # 78 # https://www.nomadproject.io/docs/job-specification/job.html 79 # 80 job "example" { 81 # The "region" parameter specifies the region in which to execute the job. If 82 # omitted, this inherits the default region name of "global". 83 # region = "global" 84 85 # The "datacenters" parameter specifies the list of datacenters which should 86 # be considered when placing this task. This must be provided. 87 datacenters = ["dc1"] 88 89 # The "type" parameter controls the type of job, which impacts the scheduler's 90 # decision on placement. This configuration is optional and defaults to 91 # "service". For a full list of job types and their differences, please see 92 # the online documentation. 93 # 94 # For more information, please see the online documentation at: 95 # 96 # https://www.nomadproject.io/docs/jobspec/schedulers.html 97 # 98 type = "service" 99 100 # The "constraint" stanza defines additional constraints for placing this job, 101 # in addition to any resource or driver constraints. This stanza may be placed 102 # at the "job", "group", or "task" level, and supports variable interpolation. 103 # 104 # For more information and examples on the "constraint" stanza, please see 105 # the online documentation at: 106 # 107 # https://www.nomadproject.io/docs/job-specification/constraint.html 108 # 109 # constraint { 110 # attribute = "${attr.kernel.name}" 111 # value = "linux" 112 # } 113 114 # The "update" stanza specifies the update strategy of task groups. The update 115 # strategy is used to control things like rolling upgrades, canaries, and 116 # blue/green deployments. If omitted, no update strategy is enforced. The 117 # "update" stanza may be placed at the job or task group. When placed at the 118 # job, it applies to all groups within the job. When placed at both the job and 119 # group level, the stanzas are merged with the group's taking precedence. 120 # 121 # For more information and examples on the "update" stanza, please see 122 # the online documentation at: 123 # 124 # https://www.nomadproject.io/docs/job-specification/update.html 125 # 126 update { 127 # The "max_parallel" parameter specifies the maximum number of updates to 128 # perform in parallel. In this case, this specifies to update a single task 129 # at a time. 130 max_parallel = 1 131 132 # The "min_healthy_time" parameter specifies the minimum time the allocation 133 # must be in the healthy state before it is marked as healthy and unblocks 134 # further allocations from being updated. 135 min_healthy_time = "10s" 136 137 # The "healthy_deadline" parameter specifies the deadline in which the 138 # allocation must be marked as healthy after which the allocation is 139 # automatically transitioned to unhealthy. Transitioning to unhealthy will 140 # fail the deployment and potentially roll back the job if "auto_revert" is 141 # set to true. 142 healthy_deadline = "3m" 143 144 # The "auto_revert" parameter specifies if the job should auto-revert to the 145 # last stable job on deployment failure. A job is marked as stable if all the 146 # allocations as part of its deployment were marked healthy. 147 auto_revert = false 148 149 # The "canary" parameter specifies that changes to the job that would result 150 # in destructive updates should create the specified number of canaries 151 # without stopping any previous allocations. Once the operator determines the 152 # canaries are healthy, they can be promoted which unblocks a rolling update 153 # of the remaining allocations at a rate of "max_parallel". 154 # 155 # Further, setting "canary" equal to the count of the task group allows 156 # blue/green deployments. When the job is updated, a full set of the new 157 # version is deployed and upon promotion the old version is stopped. 158 canary = 0 159 } 160 161 # The "group" stanza defines a series of tasks that should be co-located on 162 # the same Nomad client. Any task within a group will be placed on the same 163 # client. 164 # 165 # For more information and examples on the "group" stanza, please see 166 # the online documentation at: 167 # 168 # https://www.nomadproject.io/docs/job-specification/group.html 169 # 170 group "cache" { 171 # The "count" parameter specifies the number of the task groups that should 172 # be running under this group. This value must be non-negative and defaults 173 # to 1. 174 count = 1 175 176 # The "restart" stanza configures a group's behavior on task failure. If 177 # left unspecified, a default restart policy is used based on the job type. 178 # 179 # For more information and examples on the "restart" stanza, please see 180 # the online documentation at: 181 # 182 # https://www.nomadproject.io/docs/job-specification/restart.html 183 # 184 restart { 185 # The number of attempts to run the job within the specified interval. 186 attempts = 10 187 interval = "5m" 188 189 # The "delay" parameter specifies the duration to wait before restarting 190 # a task after it has failed. 191 delay = "25s" 192 193 # The "mode" parameter controls what happens when a task has restarted 194 # "attempts" times within the interval. "delay" mode delays the next 195 # restart until the next interval. "fail" mode does not restart the task 196 # if "attempts" has been hit within the interval. 197 mode = "delay" 198 } 199 200 # The "ephemeral_disk" stanza instructs Nomad to utilize an ephemeral disk 201 # instead of a hard disk requirement. Clients using this stanza should 202 # not specify disk requirements in the resources stanza of the task. All 203 # tasks in this group will share the same ephemeral disk. 204 # 205 # For more information and examples on the "ephemeral_disk" stanza, please 206 # see the online documentation at: 207 # 208 # https://www.nomadproject.io/docs/job-specification/ephemeral_disk.html 209 # 210 ephemeral_disk { 211 # When sticky is true and the task group is updated, the scheduler 212 # will prefer to place the updated allocation on the same node and 213 # will migrate the data. This is useful for tasks that store data 214 # that should persist across allocation updates. 215 # sticky = true 216 # 217 # Setting migrate to true results in the allocation directory of a 218 # sticky allocation directory to be migrated. 219 # migrate = true 220 221 # The "size" parameter specifies the size in MB of shared ephemeral disk 222 # between tasks in the group. 223 size = 300 224 } 225 226 # The "task" stanza creates an individual unit of work, such as a Docker 227 # container, web application, or batch processing. 228 # 229 # For more information and examples on the "task" stanza, please see 230 # the online documentation at: 231 # 232 # https://www.nomadproject.io/docs/job-specification/task.html 233 # 234 task "redis" { 235 # The "driver" parameter specifies the task driver that should be used to 236 # run the task. 237 driver = "docker" 238 239 # The "config" stanza specifies the driver configuration, which is passed 240 # directly to the driver to start the task. The details of configurations 241 # are specific to each driver, so please see specific driver 242 # documentation for more information. 243 config { 244 image = "redis:3.2" 245 port_map { 246 db = 6379 247 } 248 } 249 250 # The "artifact" stanza instructs Nomad to download an artifact from a 251 # remote source prior to starting the task. This provides a convenient 252 # mechanism for downloading configuration files or data needed to run the 253 # task. It is possible to specify the "artifact" stanza multiple times to 254 # download multiple artifacts. 255 # 256 # For more information and examples on the "artifact" stanza, please see 257 # the online documentation at: 258 # 259 # https://www.nomadproject.io/docs/job-specification/artifact.html 260 # 261 # artifact { 262 # source = "http://foo.com/artifact.tar.gz" 263 # options { 264 # checksum = "md5:c4aa853ad2215426eb7d70a21922e794" 265 # } 266 # } 267 268 # The "logs" stana instructs the Nomad client on how many log files and 269 # the maximum size of those logs files to retain. Logging is enabled by 270 # default, but the "logs" stanza allows for finer-grained control over 271 # the log rotation and storage configuration. 272 # 273 # For more information and examples on the "logs" stanza, please see 274 # the online documentation at: 275 # 276 # https://www.nomadproject.io/docs/job-specification/logs.html 277 # 278 # logs { 279 # max_files = 10 280 # max_file_size = 15 281 # } 282 283 # The "resources" stanza describes the requirements a task needs to 284 # execute. Resource requirements include memory, network, cpu, and more. 285 # This ensures the task will execute on a machine that contains enough 286 # resource capacity. 287 # 288 # For more information and examples on the "resources" stanza, please see 289 # the online documentation at: 290 # 291 # https://www.nomadproject.io/docs/job-specification/resources.html 292 # 293 resources { 294 cpu = 500 # 500 MHz 295 memory = 256 # 256MB 296 network { 297 mbits = 10 298 port "db" {} 299 } 300 } 301 302 # The "service" stanza instructs Nomad to register this task as a service 303 # in the service discovery engine, which is currently Consul. This will 304 # make the service addressable after Nomad has placed it on a host and 305 # port. 306 # 307 # For more information and examples on the "service" stanza, please see 308 # the online documentation at: 309 # 310 # https://www.nomadproject.io/docs/job-specification/service.html 311 # 312 service { 313 name = "global-redis-check" 314 tags = ["global", "cache"] 315 port = "db" 316 check { 317 name = "alive" 318 type = "tcp" 319 interval = "10s" 320 timeout = "2s" 321 } 322 } 323 324 # The "template" stanza instructs Nomad to manage a template, such as 325 # a configuration file or script. This template can optionally pull data 326 # from Consul or Vault to populate runtime configuration data. 327 # 328 # For more information and examples on the "template" stanza, please see 329 # the online documentation at: 330 # 331 # https://www.nomadproject.io/docs/job-specification/template.html 332 # 333 # template { 334 # data = "---\nkey: {{ key \"service/my-key\" }}" 335 # destination = "local/file.yml" 336 # change_mode = "signal" 337 # change_signal = "SIGHUP" 338 # } 339 340 # The "template" stanza can also be used to create environment variables 341 # for tasks that prefer those to config files. The task will be restarted 342 # when data pulled from Consul or Vault changes. 343 # 344 # template { 345 # data = "KEY={{ key \"service/my-key\" }}" 346 # destination = "local/file.env" 347 # env = true 348 # } 349 350 # The "vault" stanza instructs the Nomad client to acquire a token from 351 # a HashiCorp Vault server. The Nomad servers must be configured and 352 # authorized to communicate with Vault. By default, Nomad will inject 353 # The token into the job via an environment variable and make the token 354 # available to the "template" stanza. The Nomad client handles the renewal 355 # and revocation of the Vault token. 356 # 357 # For more information and examples on the "vault" stanza, please see 358 # the online documentation at: 359 # 360 # https://www.nomadproject.io/docs/job-specification/vault.html 361 # 362 # vault { 363 # policies = ["cdn", "frontend"] 364 # change_mode = "signal" 365 # change_signal = "SIGHUP" 366 # } 367 368 # Controls the timeout between signalling a task it will be killed 369 # and killing the task. If not set a default is used. 370 # kill_timeout = "20s" 371 } 372 } 373 } 374 `)