Test Drive Docker Enterprise Edition at VMworld 2017

Docker will be at VMworld 2017 next week (August 27-31) in Las Vegas to highlight new developments with Docker Enterprise Edition (EE), the only Container as a Service (CaaS) platform for managing and securing Windows, Linux and mainframe applications across any infrastructure, both on premises and in the cloud.
Stop by Booth #1206 to learn more about:

How VMs and containers work together for improved application lifecycle management
How containers and Docker EE can help IT with day-to-day maintenance and operations tasks
How IT can lead modernization efforts with Docker EE and become drivers of innovation in their organizations

Just as VMware vSphere simplified the management of VMs and made virtualization the de facto standard inside the data center, Docker is driving containerization of your entire application portfolio with Docker EE and helping organizations like yours to achieve their cloud and app modernization goals without requiring you to change how you operate.
Test Drive Docker EE in the Booth
Don’t miss the chance to get hands-on experience with Docker with our in-booth labs. Led by Docker experts, you will get to see for yourself how Docker brings all applications—traditional and cloud-native, Windows and Linux, on-prem and in the cloud—into a single experience for IT. Learn how standard IT tasks like patching and rolling updates are 10x easier with Docker EE and see how you can centralize security and access control through Docker EE’s management interface.
Pre-register here to sign up for one of the lab sessions and get a free Docker t-shirt when you show up!

Monday, August 28th @ 1:15pm
Tuesday, August 29th @ 1:15pm
Wednesday, August 30th @ 1:15pm

Congrats to 2017 vExperts!
We didn’t forget you! Come by our booth to collect special vExpert swag or better yet, sign up for our vExpert challenge! Special prizes in store for winners of our challenge.
Register here for special vExpert Challenge time slots and compete against fellow vExperts for some great Docker swag.

Monday, August 28th @ 3:10pm
Tuesday, August 29th @ 3:10pm

Sign up for a #Docker in-booth lab at #VMworld 2017Click To Tweet

To learn more about Docker solutions for IT:

Visit IT Starts with Docker and sign up for ongoing alerts
Learn more about Docker Enterprise Edition
Start a hosted trial
Sign up for upcoming webinars

The post Test Drive Docker Enterprise Edition at VMworld 2017 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Kubernetes Meets High-Performance Computing

Editor’s note: today’s post is by Robert Lalonde, general manager at Univa, on supporting mixed HPC and containerized applications  Anyone who has worked with Docker can appreciate the enormous gains in efficiency achievable with containers. While Kubernetes excels at orchestrating containers, high-performance computing (HPC) applications can be tricky to deploy on Kubernetes. In this post, I discuss some of the challenges of running HPC workloads with Kubernetes, explain how organizations approach these challenges today, and suggest an approach for supporting mixed workloads on a shared Kubernetes cluster. We will also provide information and links to a case study on a customer, IHME, showing how Kubernetes is extended to service their HPC workloads seamlessly while retaining scalability and interfaces familiar to HPC users.HPC workloads unique challengesIn Kubernetes, the base unit of scheduling is a Pod: one or more Docker containers scheduled to a cluster host. Kubernetes assumes that workloads are containers. While Kubernetes has the notion of Cron Jobs and Jobs that run to completion, applications deployed on Kubernetes are typically long-running services, like web servers, load balancers or data stores and while they are highly dynamic with pods coming and going, they differ greatly from HPC application patterns.Traditional HPC applications often exhibit different characteristics: In financial or engineering simulations, a job may be comprised of tens of thousands of short-running tasks, demanding low-latency and high-throughput scheduling to complete a simulation in an acceptable amount of time.A computational fluid dynamics (CFD) problem may execute in parallel across many hundred or even thousands of nodes using a message passing library to synchronize state. This requires specialized scheduling and job management features to allocate and launch such jobs and then to checkpoint, suspend/resume or backfill them.Other HPC workloads may require specialized resources like GPUs or require access to limited software licenses. Organizations may enforce policies around what types of resources can be used by whom to ensure projects are adequately resourced and deadlines are met.HPC workload schedulers have evolved to support exactly these kinds of workloads. Examples include Univa Grid Engine, IBM Spectrum LSF and Altair’s PBS Professional. Sites managing HPC workloads have come to rely on capabilities like array jobs, configurable pre-emption, user, group or project based quotas and a variety of other features.Blurring the lines between containers and HPCHPC users believe containers are valuable for the same reasons as other organizations. Packaging logic in a container to make it portable, insulated from environmental dependencies, and easily exchanged with other containers clearly has value. However, making the switch to containers can be difficult. HPC workloads are often integrated at the command line level. Rather than requiring coding, jobs are submitted to queues via the command line as binaries or simple shell scripts that act as wrappers. There are literally hundreds of engineering, scientific and analytic applications used by HPC sites that take this approach and have mature and certified integrations with popular workload schedulers. While the notion of packaging a workload into a Docker container, publishing it to a registry, and submitting a YAML description of the workload is second nature to users of Kubernetes, this is foreign to most HPC users. An analyst running models in R, MATLAB or Stata simply wants to submit their simulation quickly, monitor their execution, and get a result as quickly as possible. Existing approachesTo deal with the challenges of migrating to containers, organizations running container and HPC workloads have several options:Maintain separate infrastructuresFor sites with sunk investments in HPC, this may be a preferred approach. Rather than disrupt existing environments, it may be easier to deploy new containerized applications on a separate cluster and leave the HPC environment alone. The challenge is that this comes at the cost of siloed clusters, increasing infrastructure and management cost.Run containerized workloads under an existing HPC workload managerFor sites running traditional HPC workloads, another approach is to use existing job submission mechanisms to launch jobs that in turn instantiate Docker containers on one or more target hosts. Sites using this approach can introduce containerized workloads with minimal disruption to their environment. Leading HPC workload managers such as Univa Grid Engine Container Edition and IBM Spectrum LSF are adding native support for Docker containers. Shifter and Singularity are important open source tools supporting this type of deployment also. While this is a good solution for sites with simple requirements that want to stick with their HPC scheduler, they will not have access to native Kubernetes features, and this may constrain flexibility in managing long-running services where Kubernetes excels.Use native job scheduling features in KubernetesSites less invested in existing HPC applications can use existing scheduling facilities in Kubernetes for jobs that run to completion. While this is an option, it may be impractical for many HPC users. HPC applications are often either optimized towards massive throughput or large scale parallelism. In both cases startup and teardown latencies have a discriminating impact. Latencies that appear to be acceptable for containerized microservices today would render such applications unable to scale to the required levels.All of these solutions involve tradeoffs. The first option doesn’t allow resources to be shared (increasing costs) and the second and third options require customers to pick a single scheduler, constraining future flexibility.Mixed workloads on KubernetesA better approach is to support HPC and container workloads natively in the same shared environment. Ideally, users should see the environment appropriate to their workload or workflow type.One approach to supporting mixed workloads is to allow Kubernetes and the HPC workload manager to co-exist on the same cluster, throttling resources to avoid conflicts. While simple, this means that neither workload manager can fully utilize the cluster. Another approach is to use a peer scheduler that coordinates with the Kubernetes scheduler. Navops Command by Univa is a solution that takes this third approach, augmenting the functionality of the Kubernetes scheduler. Navops Command provides its own web interface and CLI and allows additional scheduling policies to be enabled on Kubernetes without impacting the operation of the Kubernetes scheduler and existing containerized applications. Navops Command plugs into the Kubernetes architecture via the ‘schedulerName’ attribute in the pod spec as a peer scheduler that workloads can choose to use instead of the Kubernetes stock scheduler as shown below.With this approach, Kubernetes acts as a resource manager, making resources available to a separate HPC scheduler. Cluster administrators can use a visual interface to allocate resources based on policy or simply drag sliders via a web UI to allocate different proportions of the Kubernetes environment to non-container (HPC) workloads, and native Kubernetes applications and services.From a client perspective, the HPC scheduler runs as a service deployed in Kubernetes pods, operating just as it would on a bare metal cluster. Navops Command provides additional scheduling features including things like resource reservation, run-time quotas, workload preemption and more. This environment works equally well for on-premise, cloud-based or hybrid deployments.Deploying mixed workloads at IHMEOne client having success with mixed workloads is the Institute for Health Metrics & Evaluation (IHME), an independent health research center at the University of Washington. In support of their globally recognized Global Health Data Exchange (GHDx), IHME operates a significantly sized environment comprised of 500 nodes and 20,000 cores running a mix of analytic, HPC, and container-based applications on Kubernetes. This case study describes IHME’s success hosting existing HPC workloads on a shared Kubernetes cluster using Navops Command.For sites deploying new clusters that want access to the rich capabilities in Kubernetes but need the flexibility to run non-containerized workloads, this approach is worth a look. It offers the opportunity for sites to share infrastructure between Kubernetes and HPC workloads without disrupting existing applications and businesses processes. It also allows them to migrate their HPC workloads to use Docker containers at their own pace.
Quelle: kubernetes