Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Easy and Flexible Application Deployment with HashiCorp Nomad
Similar to Easy and Flexible Application Deployment with HashiCorp Nomad (20)
More from Amanda MacLeod
More from Amanda MacLeod (7)
Recently uploaded
Recently uploaded (20)
Easy and Flexible Application Deployment with HashiCorp Nomad
- 1. Copyright © 2018 HashiCorp Easy and Flexible Application Deployment with HashiCorp Nomad Rob Genova - Nomad Product Manager Nic Jackson - Developer Advocate
- 2. Copyright © 2018 HashiCorp Company overview 2 Mission Key Products Founded 2012 by Mitchell Hashimoto and Armon Dadgar We enable organizations to Provision, Secure, Connect, and Run any infrastructure for any application https://www.hashicorp.com/blog/the-tao-of-hashicorp
- 3. Copyright © 2018 HashiCorp 3 DEVELOPMENT SECURITY OPERATIONS Run applications Secure infrastructure & applications Provision infrastructure The HashiCorp open source suite THE PRACTITIONER
- 4. Copyright © 2018 HashiCorp 4 DEVELOPMENT SECURITY OPERATIONS Run applications Secure infrastructure & applications Challenges for organizations as they scale ENTERPRISE ENTERPRISE ENTERPRISE THE PRACTITIONER TEAMS • Collaboration • Operations • Governance & policy ENTERPRISE DEVELOPMENT SECURITY OPERATIONS Run applications Secure infrastructure & applications Provision infrastructure
- 5. Copyright © 2018 HashiCorp Schedulers and orchestration tools generally leverage containerization to: - Improve deployment workflows - Reduce the tight coupling between developers and operators - Increase the resilience of running applications - Enable more efficient use of compute resources However, there are a number of drawbacks: - Overly complex for developers to define and run workloads - Difficult to deploy and operate - Inflexible with respect to both workload and packaging - Difficult to scale and deploy across regions - Difficult to grasp mental model; steep learning curve Nomad Origin 5
- 6. Copyright © 2018 HashiCorp Nomad’s goal is to enable an organization to easily run any application on any infrastructure at any scale. With the following characteristics: -Easy to learn, simple mental model -Easy and efficient for developers to define and run workloads -Easy to deploy and operate -Integrates easily into existing workflows -First-class support for all major workload types -Easy to deploy across regions and cloud providers -Easy to scale -Integrates seamlessly with other HashiCorp tooling Nomad Objectives 6
- 7. Copyright © 2018 HashiCorp Nomad Workflow 7 User Nomad Servers Submits Job Nomad Clients Deploy App Skip (Busy)
- 8. Copyright © 2018 HashiCorp 8 Declarative Job Specification job "my_job" { datacenters = ["us-west-1", “us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 } }
- 9. Copyright © 2018 HashiCorp Single Binary - Client/Server Deployment Topology 9
- 10. Copyright © 2018 HashiCorp Multi-region Deployment Topology 10
- 11. Copyright © 2018 HashiCorp Internal State, Parallelized Scheduling 11
- 12. Copyright © 2018 HashiCorp Job Specification - Regions, Datacenters ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration 12 job “my_job" { region = "us" datacenters = ["us-west-1", "us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { static = 443 } }
- 13. Copyright © 2018 HashiCorp Job Specification - Job Type 13 job “my_job" { region = "us" datacenters = ["us-west-1", "us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { static = 443 } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 14. Copyright © 2018 HashiCorp Job Specification - Group 14 job “my_job" { region = "us" datacenters = ["us-west-1", "us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { static = 443 } } } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 15. Copyright © 2018 HashiCorp Job Specification - Task 15 job “my_job" { region = "us" datacenters = ["us-west-1", "us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { static = 443 } } } } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 16. Copyright © 2018 HashiCorp Job Specification - Driver 16 job “my_job" { region = "us" datacenters = ["us-west-1", "us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { static = 443 } } } } } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 17. Copyright © 2018 HashiCorp Job Specification - Resources 17 job “my_job" { region = "us" datacenters = ["us-west-1", "us-east-1"] type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-frontend" } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { static = 443 } } } } } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 18. Copyright © 2018 HashiCorp Job Specification - Constraints 18 job “my_job" { # All tasks in this job must run on linux. constraint { attribute = "${attr.kernel.name}" value = "linux" } group "example" { # All groups in this job should be scheduled on different hosts. constraint { operator = "distinct_hosts" value = "true" } task "server" { # All tasks must run where "my_custom_value" is greater than 3. constraint { attribute = "${meta.my_custom_value}" operator = ">" value = "3" } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 19. Copyright © 2018 HashiCorp Job Specification - Priorities 19 job “my_job" { region = “north-america" datacenters = [“us-east-1"] priority = 100 constraint { # ... } group "example" { # ... } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 20. Copyright © 2018 HashiCorp Job Specification - Environment Variables 20 job “my_job" { group "example" { task "server" { env { my_key = "my-value" } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 21. Copyright © 2018 HashiCorp Job Specification - Periodic Jobs 21 job “my_job" { periodic { cron = "*/15 * * * * *" prohibit_overlap = true } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 22. Copyright © 2018 HashiCorp Job Specification - Updating Jobs 22 job “my_job” { update { max_parallel = 3 health_check = "checks" min_healthy_time = "10s" healthy_deadline = "10m" auto_revert = true canary = 1 stagger = "30s" } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 23. Copyright © 2018 HashiCorp Job Specification - Consul Integration 23 job “my_job" { group "example" { task "server" { service { tags = ["leader", "mysql"] port = “db" check { type = "script" name = "check_table" command = "/usr/local/bin/check_mysql_table_status" args = ["--verbose"] interval = "60s" timeout = “5s" } template { source = "local/redis.conf.tpl" destination = "local/redis.conf" change_mode = "signal" change_signal = "SIGINT" } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
- 24. Copyright © 2018 HashiCorp Job Specification - Vault Integration 24 job “my_job" { group "example" { task "server" { vault { policies = ["cdn", "frontend"] change_mode = "signal" change_signal = "SIGUSR1" } } } } ▪ Region, Datacenters ▪ Job Type ▪ Group ▪ Task ▪ Driver ▪ Resources ▪ Constraints ▪ Priorities ▪ Environment Variables ▪ Periodic Jobs ▪ Updating Jobs ▪ Consul Integration ▪ Vault Integration
Editor's Notes
- Thanks Amanda! Hello to everybody on the line. As Amanda mentioned, I’d like to spend a few minutes going over how the HashiCorp product portfolio fits together and also give a brief technical overview of Nomad before we jump into Nic's demo.
- HashiCorp has been around for almost six years. We have found that as organizations move from monolithic applications running on dedicated infrastructure to service-oriented applications running across multiple cloud providers, there are a common set of challenges that are encountered. HashiCorp's mission is to enable a consistent set of workflows as organizations make this transition and to do so with a suite of products that have well-defined scope and are loosely coupled but elegantly integrate with each other to form a solid/complete solution rather than taking an all-in-one platform type approach. Our four primary products - Terraform, Vault, Consul and Nomad together enable an organization to provision, secure, connect and run any infrastructure for any application (respectively).
- So, I am going to quickly introduce each of the products at a high level in case anyone on the call isn't familiar. Starting from the bottom of the slide. Terraform provides a common infrastructure provisioning workflow across private cloud, public cloud and external services with built-in dependency management and an "as code" approach. Moving up the stack, Vault enables a unified secrets management workflow across cloud providers and identity sources. Consul provides a backbone that more-or-less enables an organization to connect, configure and monitor their services across data centers and regions. Consul is widely used today for service discovery and dynamic configuration, for example. And finally, Nomad enables a common workflow for both container-based and legacy application deployment. And again - like the other products - it does so in a way that elegantly spans both private infrastructure and public cloud providers.
- The enterprise versions of the products add collaboration, operations and governance features that help organizations address the challenges that arise as the scale and complexity of their internal operational platform increases.
- So, Nomad is HashiCorp’s scheduler and application deployment tool. The product niche that it fits into is often referred to as container management or container orchestration. It is the newest of the four primary HashiCorp products and was designed first and foremost in accordance with HashiCorp principles. It is workflow oriented. It is simple and modular, and can be easily combined with our other tools to solve the wider challenges. But in many ways Nomad’s design was also a response to the operational challenges and the lack of flexibility that we observed with some of the other container management tools.
- At a high level, Nomad’s goal is to enable an organization to easily run any application on any infrastructure at any scale with the characteristics listed here. Nomad is easy to learn; it has a very simple mental model. It’s easy to use for both developers and operators. Nomad is flexible and can be easily integrated into your existing workflows. It supports all workload types. Nomad is dead simple to federate across regions and cloud providers. It is also easy to scale and elegantly integrates with other HashiCorp tooling.
- Lets cover how Nomad works at a high level before we turn it over to Nic. Nomad uses a simple client/server architecture. The servers handle application placement across a set of client nodes, optimizing for resource efficiency and accounting for the defined priority and constraints. From a workflow perspective, Nomad enables a user to define the deployment requirements for an application which can then be submitted to any server.
- Nomad’s job specification is declarative and uses the HashiCorp Configuration Language (HCL) which will be familiar to any Terraform users. The job spec defines the deployment schema for the application and includes the task definition, the driver (which may or may not be Docker), the image, resource reservations, job priority, constraints, service registrations and any other information required to deploy the application. I’ll go over the job spec in more detail in a few minutes.
- From an operational perspective, Nomad consists of a single binary that can run in either client or server mode. Three or more servers form a highly available control plane to handle scheduling. The servers store state internally and use a Raft-based consensus protocol for state replication and automatic leader election. This makes Nomad highly available out of the box. There is no etcd or Zookeeper external dependency. The clients register with the servers, wait for work to be assigned and execute tasks. A single, logical cluster defines a region which can contain multiple data centers.
- Multiple regions can be easily federated together with a single CLI command. Nomad natively uses a gossip protocol for cross region cluster membership and failure detection. Work can be scheduled across the region boundary.
- As mentioned earlier, Nomad stores and replicates state internally across all servers. This architecture enables an optimistically concurrent and parallelized scheduling strategy that can yield thousands of job placements per second (a key advantage for batch processing workloads).
- I am going to finish up by quickly running through the job spec in a bit more detail. A job can be submitted to exactly one region but can request placement across multiple data centers within that region.
- Type indicates whether the job is a service, a batch job or a system job. System jobs run on every node automatically.
- The group stanza defines a series of tasks that should be co-located on the same Nomad client. This is similar to a pod in Kubernetes.
- The task stanza defines an individual unit of work, such as a web application or a batch processing task.
- The task stanza includes the driver and the image (next slide)
- .. as well as the resource requirements for the task.
- Constraints limit placement based on client properties or metadata and can be specified at the job, group or task levels.
- Priority can be specified at the job level. Higher priority jobs will be sorted the top of the evaluation and planning queues for scheduling.
- The env stanza can be used to populate the task's environment before starting.
- The periodic stanza allows a job to run at fixed times, dates, or intervals (similar to cron).
- The update stanza can be used to perform rolling, canary-based or blue/green job updates. Updates can be gated on Consul health check status and automatically reverted. Nic will be demonstrating updates as part of the demo.
- There are a couple of different ways that Nomad integrates with Consul. The service stanza in the job spec can be used to register services and health checks in Consul. The template stanza can be used to update configuration files and environment variables in a running task based on Consul KV data. This feature uses consul-template under the hood. A Nomad cluster can also be automatically bootstrapped if a Consul deployment already exists.
- And finally, Nomad supports a first-class Vault-based workflow for secrets retrieval. The vault stanza in the job spec allows a task to specify that it requires a token from an existing instance of Vault. Nomad will automatically retrieve a Vault token for the task upon job placement. The template stanza can be used for automatic secret renewal and re-rendering of configuration files (or updating environment variables).