Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

0

Share

Download to read offline

Modern Scheduling for Modern Applications with Nomad

Download to read offline

Watch this succinct guide to the benefits of modern scheduling and how HashiCorp Nomad can help you move your organization toward more modern deployment patterns.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Modern Scheduling for Modern Applications with Nomad

  1. 1. © 2018 HashiCorp Nomad Modern Scheduling for Modern Applications Jasmine Dahilig
  2. 2. 80%+ companies are deploying containers with Multiple OSes across Multiple Clouds Majority of surveyed organizations are deploying containers with both Linux and Windows, across on-premises and multiple clouds 40% of surveyed organizations cited “complexity” as the number one challenge in container deployment. Management Complexity is a top challenge in using and deploying containers https://www.cncf.io/blog/2018/08/29/cncf-survey-use-of-cloud- native-technologies-in-production-has-grown-over-200-percent/ https://goto.docker.com/rs/929-FJL-178/images/IDC- containerplatform-wp.pdf
  3. 3. A Common Cloud Operating Model App App Run Provision Connect Secure Compliance&Governance
  4. 4. The Need for a Modern Orchestrator
  5. 5. © 2018 HashiCorp The Move to Containers and Clouds 5 ● Adopt containers and microservices for new applications ● Re-architect & migrate existing applications ● Segment of legacy applications remains the same
  6. 6. © 2018 HashiCorp The Fundamental Needs for a Container Orchestrator 6 How do we run containers in production? ”
  7. 7. © 2018 HashiCorp Challenges of Moving to Containers 7 ● Lack of budget or time to refactor existing applications ● Increased complexity to support mixed systems and workflows ● Limited time to meet IT/Business requirements - Incremental vs Overhaul
  8. 8. © 2018 HashiCorp Guiding Principle Orchestrate Any Application 8 ● Bringing modern orchestration benefits to all - containerized, non-containerized and batch applications ● A simple, lightweight layer that can be integrated with any existing infrastructure ● A single, unified workflow to accelerate incremental application modernization
  9. 9. © 2018 HashiCorp NOMAD ECOSYSTEM Single Orchestrator for Clouds
  10. 10. Using Nomad
  11. 11. Automated Deployment Workflow
  12. 12. Application Deployment as Code ● Declarative specification using HCL (like Terraform) or JSON ● Set the deployment rules for applications fast and intuitively. Define tasks, images, resources, priorities, constraints, service registrations, secrets and other information required to deploy the application. 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 TERMINAL
  13. 13. Intuitive Deployment Rules 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 job # define the deployment rules for applications _ group # defines a series of tasks that should be co-located on the same Nomad client _ task # defines a command, service, application or "set of work" to execute, such as a docker container, webapp or batch processing. Tasks are executed by their driver
  14. 14. job “my_job" { region = "us" datacenters = ["us-west-1", "us-e type = "service" group "web" { count = 5 task "frontend" { driver = "docker" config { image = "hashicorp/web-fron } resources { cpu = 500 # MHz memory = 128 # MB network { mbits = 100 port "http" {} port "https" { ● Batch Scheduler is optimized for fast placement for short-lived workload. Example: Daily reports, transactions, billing invoices ● Service Scheduler is optimized for long-running workloads. Example: Business-critical applications, customer facing webapps, database ● System Scheduler is optimized for background tasks Example: Logging/monitoring, security, background processes Schedulers to Run All Types of Workloads
  15. 15. Enable Flexibility with Extensible Drivers 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 ● Task Drivers execute tasks on the Nomad Client and provide resource isolation ● First-class support of a broad set of workloads across all major operating systems
  16. 16. Robust Application Update Strategy Automate job update and migration to minimize down time ● Rolling Updates ● Blue/Green deployments ● Canaries deployments ● Updates can be gated on Consul health checks and automatically reverted job “my_job” { update { max_parallel = 3 health_check = "checks" min_healthy_time = "10s" healthy_deadline = "10m" auto_revert = true canary = 1 stagger = "30s" } } TERMINAL
  17. 17. Operating Nomad
  18. 18. Nomad Architecture - Single Process Single Binary (<35MB) NOMAD AGENT NOMAD SERVER NOMAD CLIENT Nomad Server forms the control plane for scheduling. $ .nomad -config=server.hcl Nomad Client runs on the node which registers with the servers, watching for any work to be assigned and execute tasks $ .nomad -config=client.hcl
  19. 19. Nomad Architecture - Single Region
  20. 20. Nomad Demo
  21. 21. Scheduling in Nomad
  22. 22. Overall Scheduling Process Define the “Desired States” of tasks by users, bounded by hard and soft constraints Triggered by any change of Jobs or Nodes when Nomad needs to re-evaluate the the “state of world” Nomad generates a plan on how a set of tasks in a job should be run on a particular node Nodes form a resource pool where the tasks can be executed. Nomad monitors their health status Nomad scheduler is responsible for processing an evaluation and generating an allocation plan.
  23. 23. Improved Application Resiliency
  24. 24. Improved Resource Utilization ● Improve resource utilization by densely scheduling applications over underutilized resources
  25. 25. Native Integration with Vault and Consul
  26. 26. Secrets Management with Vault ● Automatic Vault token retrieval ● Automatic Vault token renewal ● Automatic secret retrieval and renewal via template stanza Job file job “my_job" { group "example" { task "server" { vault { policies = ["cdn", "frontend"] change_mode = "signal" change_signal = "SIGUSR1" } } } } TERMINAL retrieve renew
  27. 27. Service Discovery with Consul ● Built-in service discovery, registration, and health check monitoring for all applications deployed under Nomad
  28. 28. Service Mesh with Consul ● Network Namespaces to create isolated network for a task group ● Native Consul Connect integration to launch sidecar proxies for applications ● Intentions*are defined in Consul and transparent to job spec authors as applications scale up and down *Note: Intentions define access control for services via Consul Connect and are used to control which services may establish connections.
  29. 29. Nomad Ecosystem
  30. 30. © 2018 HashiCorp NOMAD ECOSYSTEM Broad Ecosystem Integration
  31. 31. Monitoring ● The Nomad client and server agents collect runtime telemetry. ● Operators can use this data to gain real-time visibility into their Nomad clusters and improve performance. ● The metrics can be exported to tools like Prometheus, Grafana, Graphite, DataDog, and Circonus. telemetry { publish_allocation_metrics = true publish_node_metrics = true } telemetry { datadog_address = "dogstatsd.company.local:8125" datadog_tags = ["my_tag_name:my_tag_value"] }
  32. 32. Specialized Hardware with Device Plugins Run any workload against any hardware infrastructure with extensible device plugins ● Nomad clients discover and fingerprint the attributes of available hardware resources in addition to existing built-in resources ● plugin also assists the Nomad client in making the allocated device available to run the task type DevicePlugin interface { Fingerprint(ctx context.Context) (<-chan *FingerprintResponse, error) Reserve(deviceIDs []string) (*ContainerReservation, error) Stats(ctx context.Context, interval time.Duration) (<-chan *StatsResponse, error) } TERMINAL
  33. 33. What’s New with Nomad 0.11 Enhance Core Orchestration Capabilities
  34. 34. Container Storage Interface Deploy stateful applications with any storage provider of choice (EBS, EFS, etc.) Task Dependencies Run interdependent applications in their sequential orders easily and efficiently at scale Autoscaling Dynamically scale application instances based on real-time load without manual intervention Nomad 0.11 Key Features | OSS Remote Exec (UI) Directly execute commands in running allocations through the Nomad UI for faster operability
  35. 35. Audit Logging Provides administrators with a complete set of records for all user- issued actions to fulfill compliance requirements. [Governance & Policies Module] Nomad 0.11 Key Features | ENT
  36. 36. © 2018 HashiCorp nomadproject.io learn.hashicorp.com/nomad github.com/hashicorp/nomad
  37. 37. www.hashicorp.com hello@hashicorp.com Thank you
  38. 38. HashiCorp VirtualDays: Asia Pacific Thank You!

Watch this succinct guide to the benefits of modern scheduling and how HashiCorp Nomad can help you move your organization toward more modern deployment patterns.

Views

Total views

595

On Slideshare

0

From embeds

0

Number of embeds

532

Actions

Downloads

13

Shares

0

Comments

0

Likes

0

×