diff --git a/CHANGELOG.md b/CHANGELOG.md index 6597cf4eb..428d401d5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -39,9 +39,10 @@ IMPROVEMENTS: * client: Precise snapshotting of TaskRunner and AllocRunner [GH-403, GH-411] * client: Task State is tracked by client [GH-416] * client: Test Skip Detection [GH-221] - * driver/docker: Advanced docker driver options [GH-390] - * driver/docker: Docker container name can be set [GH-389] - * driver/docker: Docker hostname can be set [GH-426] + * driver/docker: Can now specify auth for docker pull [GH-390] + * driver/docker: Can now specify DNS and DNSSearch options [GH-390] + * driver/docker: Can now specify the container's hostname [GH-426] + * driver/docker: Containers now have names based on the task name. [GH-389] * driver/docker: Mount task local and alloc directory to docker containers [GH-290] * driver/docker: Now accepts any value for `network_mode` to support userspace networking plugins in docker 1.9 * driver/java: Pass JVM options in java driver [GH-293, GH-297] diff --git a/client/driver/docker.go b/client/driver/docker.go index fcbe14418..ab0ac96e0 100644 --- a/client/driver/docker.go +++ b/client/driver/docker.go @@ -25,16 +25,14 @@ type DockerDriver struct { fingerprint.StaticFingerprinter } -type DockerAuthConfig struct { - UserName string `mapstructure:"auth.username"` // user name of the registry - Password string `mapstructure:"auth.password"` // password to access the registry - Email string `mapstructure:"auth.email"` // email address of the user who is allowed to access the registry - ServerAddress string `mapstructure:"auth.server_address"` // server address of the registry - +type DockerDriverAuth struct { + Username string `mapstructure:"username"` // username for the registry + Password string `mapstructure:"password"` // password to access the registry + Email string `mapstructure:"email"` // email address of the user who is allowed to access the registry + ServerAddress string `mapstructure:"server_address"` // server address of the registry } type DockerDriverConfig struct { - DockerAuthConfig ImageName string `mapstructure:"image"` // Container's Image Name Command string `mapstructure:"command"` // The Command/Entrypoint to run when the container starts up Args string `mapstructure:"args"` // The arguments to the Command/Entrypoint @@ -45,6 +43,7 @@ type DockerDriverConfig struct { DNSSearchDomains []string `mapstructure:"dns_search_domains"` // DNS Search domains for containers Hostname string `mapstructure:"hostname"` // Hostname for containers Labels []map[string]string `mapstructure:"labels"` // Labels to set when the container starts up + Auth []DockerDriverAuth `mapstructure:"auth"` // Authentication credentials for a private Docker registry } func (c *DockerDriverConfig) Validate() error { @@ -380,11 +379,14 @@ func (d *DockerDriver) Start(ctx *ExecContext, task *structs.Task) (DriverHandle Tag: tag, } - authOptions := docker.AuthConfiguration{ - Username: driverConfig.UserName, - Password: driverConfig.Password, - Email: driverConfig.Email, - ServerAddress: driverConfig.ServerAddress, + authOptions := docker.AuthConfiguration{} + if len(driverConfig.Auth) != 0 { + authOptions = docker.AuthConfiguration{ + Username: driverConfig.Auth[0].Username, + Password: driverConfig.Auth[0].Password, + Email: driverConfig.Auth[0].Email, + ServerAddress: driverConfig.Auth[0].ServerAddress, + } } err = client.PullImage(pullOptions, authOptions) diff --git a/website/source/docs/drivers/docker.html.md b/website/source/docs/drivers/docker.html.md index 4d1d5b958..d1c6bafbe 100644 --- a/website/source/docs/drivers/docker.html.md +++ b/website/source/docs/drivers/docker.html.md @@ -56,11 +56,13 @@ specification: following authentication parameters. These options can provide access to private repositories that utilize the docker remote api (e.g. dockerhub, quay.io) - - `auth.username` - (Optional) The account username - - `auth.password` - (Optional) The account password - - `auth.email` - (Optional) The account email - - `auth.server-address` - (Optional) The server domain/ip without the - protocol + +The `auth` object supports the following keys: + +* `username` - (Optional) The account username. +* `password` - (Optional) The account password. +* `email` - (Optional) The account email. +* `server_address` - (Optional) The server domain/ip without the protocol. ### Port Mapping diff --git a/website/source/docs/jobspec/index.html.md b/website/source/docs/jobspec/index.html.md index 64228ed21..cffc04ed1 100644 --- a/website/source/docs/jobspec/index.html.md +++ b/website/source/docs/jobspec/index.html.md @@ -135,7 +135,8 @@ The `job` object supports the following keys: * `type` - Specifies the job type and switches which scheduler is used. Nomad provides the `service`, `system` and `batch` schedulers, - and defaults to `service`. + and defaults to `service`. To learn more about each scheduler type visit + [here](/docs/jobspec/schedulers.html) * `update` - Specifies the task update strategy. This requires providing `max_parallel` as an integer and `stagger` as a time duration. If stagger @@ -240,7 +241,7 @@ restart { } ``` -The default non-batch restart policy is: +The default non-batch restart policy is: ``` restart { diff --git a/website/source/docs/jobspec/schedulers.html.md b/website/source/docs/jobspec/schedulers.html.md new file mode 100644 index 000000000..9cd1fdde3 --- /dev/null +++ b/website/source/docs/jobspec/schedulers.html.md @@ -0,0 +1,46 @@ +--- +layout: "docs" +page_title: "Nomad Schedulers" +sidebar_current: "docs-jobspec-schedulers" +description: |- + Learn about Nomad's various schedulers. +--- + +# Scheduler Types + +Nomad has three scheduler types that can be used hen creating your +[job](/docs/jobspec/): `service`, `batch` and `system`. Here we will describe +the differences between each of these schedulers. + +## Service + +The `service` scheduler is designed for scheduling long lived services that +should never go down. As such, the `service` scheduler ranks a large portion +of the nodes that meet the jobs constraints and selects the optimal node to +place a task group on. The `service` scheduler uses a scoring algorithm based on +Google's BestFit v3 algorithm. Ranking this larger set of candidate nodes +increases scheduling time but provides greater guarantees about the optimality +of a job placement, which given the service workload is highly desirable. + +## Batch + +Batch jobs are much less sensitive to short term performance fluctuations and +are short lived, finishing in a few minutes to a few days. Although the `batch` +scheduler is very similar to the `service` scheduler, it makes certain +optimizations for the batch workload. The main distinction is that after finding +the set of nodes that meet the jobs constraints it uses the power of two choices +described in Berkeley's Sparrow scheduler to limit the number of nodes that are +ranked. + +## System + +The `system` scheduler is used to register jobs that should be run on all +clients that meet the job's constraints. The `system` scheduler is also invoked +when clients join the cluster or transition into the ready state. This means +that all registered `system` jobs will be re-evaluated and their tasks will be +placed on the newly available nodes if the constraints are met. + +This scheduler type is extremely useful for deploying and managing tasks that +should be present on every node in the cluster. Since these tasks are being +managed by Nomad, they can take advantage of job updating, rolling deploys, +service discovery and more. diff --git a/website/source/layouts/docs.erb b/website/source/layouts/docs.erb index e428cb593..115623599 100644 --- a/website/source/layouts/docs.erb +++ b/website/source/layouts/docs.erb @@ -38,6 +38,9 @@ > Runtime Environment + > + Scheduler Types +