Merge branch 'master' into f-docker-dns-config

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]

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)

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
 

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 {

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.

website/source/layouts/docs.erb

@@ -38,6 +38,9 @@
                         <li<%= sidebar_current("docs-jobspec-environment") %>>
                             <a href="/docs/jobspec/environment.html">Runtime Environment</a>
                         </li>
+                        <li<%= sidebar_current("docs-jobspec-schedulers") %>>
+                            <a href="/docs/jobspec/schedulers.html">Scheduler Types</a>
+                        </li>
                     </ul>
                 </li>