Kategorie: Kubernetes

Image2Docker: A New Tool for Prototyping Windows VM Conversions

Docker is a great tool for building, shipping, and running your applications. Many companies are already moving their legacy applications to Docker containers and now with the introduction of the Microsoft Windows Server 2016, Docker Engine can not run containers  natively on Windows.To make it even easier, there’s a new prototyping tool for Windows VMs that shows you how to replicate a VM Image to a container.
Docker Captain Trevor Sullivan recently released the Image2Docker tool, an open source project we’re hosting on GitHub. Still in it’s early stages, Image2Docker is a Powershell module that you can point at a virtual hard disk image, scan for common Windows components and suggest a Dockerfile. And to make it even easier, we’re hosting it in the Powershell Gallery to make it easy to install and use.
In Powershell, just type:
Install-Module -Name Image2Docker
And you’ll have access to Get-WindowsArtifacts and ConvertTo-Dockerfile. You can even select which discovery artifacts to search for.

Currently Image2Docker supports VHD, VHDK, and WIM images. If you have a VMDK, Microsoft provides a great conversion tool to convert VMDK images to VHD images.
And as an open source project, lead by a Docker Captain, it’s easy to contribute. We welcome contributions to add more discovery objects and functionality.
More Resources:

Check out Image2Docker in the Powershell Gallery
Contribute to Image2Docker
Learn More: Docker and Windows Server
Get Started with Windows Server Containers with Docker

Introducing Image2Docker: A New Tool for Prototyping @Windows VM Conversions by @pcgeek86Click To Tweet

The post Image2Docker: A New Tool for Prototyping Windows VM Conversions appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

How Qbox Saved 50% per Month on AWS Bills Using Kubernetes and Supergiant

Editor’s Note: Today’s post is by the team at Qbox, a hosted Elasticsearch provider sharing their experience with Kubernetes and how it helped save them fifty-percent off their cloud bill. A little over a year ago, we at Qbox faced an existential problem. Just about all of the major IaaS providers either launched or acquired services that competed directly with our Hosted Elasticsearch service, and many of them started offering it for free. The race to zero was afoot unless we could re-engineer our infrastructure to be more performant, more stable, and less expensive than the VM approach we had had before, and the one that is in use by our IaaS brethren. With the help of Kubernetes, Docker, and Supergiant (our own hand-rolled layer for managing distributed and stateful data), we were able to deliver 50% savings, a mid-five figure sum. At the same time, support tickets plummeted. We were so pleased with the results that we decided to open source Supergiant as its own standalone product. This post will demonstrate how we accomplished it.Back in 2013, when not many were even familiar with Elasticsearch, we launched our as-a-service offering with a dedicated, direct VM model. We hand-selected certain instance types optimized for Elasticsearch, and users configured single-tenant, multi-node clusters running on isolated virtual machines in any region. We added a markup on the per-compute-hour price for the DevOps support and monitoring, and all was right with the world for a while as Elasticsearch became the global phenomenon that it is today.BackgroundAs we grew to thousands of clusters, and many more thousands of nodes, it wasn’t just our AWS bill getting out of hand. We had 4 engineers replacing dead nodes and answering support tickets all hours of the day, every day. What made matters worse was the volume of resources allocated compared to the usage. We had thousands of servers with a collective CPU utilization under 5%. We were spending too much on processors that were doing absolutely nothing. How we got there was no great mystery. VM’s are a finite resource, and with a very compute-intensive, burstable application like Elasticsearch, we would be juggling the users that would either undersize their clusters to save money or those that would over-provision and overspend. When the aforementioned competitive pressures forced our hand, we had to re-evaluate everything.Adopting Docker and KubernetesOur team avoided Docker for a while, probably on the vague assumption that the network and disk performance we had with VMs wouldn’t be possible with containers. That assumption turned out to be entirely wrong.To run performance tests, we had to find a system that could manage networked containers and volumes. That’s when we discovered Kubernetes. It was alien to us at first, but by the time we had familiarized ourselves and built a performance testing tool, we were sold. It was not just as good as before, it was better.The performance improvement we observed was due to the number of containers we could “pack” on a single machine. Ironically, we began the Docker experiment wanting to avoid “noisy neighbor,” which we assumed was inevitable when several containers shared the same VM. However, that isolation also acted as a bottleneck, both in performance and cost. To use a real-world example, If a machine has 2 cores and you need 3 cores, you have a problem. It’s rare to come across a public-cloud VM with 3 cores, so the typical solution is to buy 4 cores and not utilize them fully.This is where Kubernetes really starts to shine. It has the concept of requests and limits, which provides granular control over resource sharing. Multiple containers can share an underlying host VM without the fear of “noisy neighbors”. They can request exclusive control over an amount of RAM, for example, and they can define a limit in anticipation of overflow. It’s practical, performant, and cost-effective multi-tenancy. We were able to deliver the best of both the single-tenant and multi-tenant worlds.Kubernetes + SupergiantWe built Supergiant originally for our own Elasticsearch customers. Supergiant solves Kubernetes complications by allowing pre-packaged and re-deployable application topologies. In more specific terms, Supergiant lets you use Components, which are somewhat similar to a microservice. Components represent an almost-uniform set of Instances of software (e.g., Elasticsearch, MongoDB, your web application, etc.). They roll up all the various Kubernetes and cloud operations needed to deploy a complex topology into a compact entity that is easy to manage.For Qbox, we went from needing 1:1 nodes to approximately 1:11 nodes. Sure, the nodes were larger, but the utilization made a substantial difference. As in the picture below, we could cram a whole bunch of little instances onto one big instance and not lose any performance. Smaller users would get the added benefit of higher network throughput by virtue of being on bigger resources, and they would also get greater CPU and RAM bursting.Adding Up the Cost SavingsThe packing algorithm in Supergiant, with its increased utilization, resulted in an immediate 25% drop in our infrastructure footprint. Remember, this came with better performance and fewer support tickets. We could dial up the packing algorithm and probably save even more money. Meanwhile, because our nodes were larger and far more predictable, we could much more fully leverage the economic goodness that is AWS Reserved Instances. We went with 1-year partial RI’s, which cut the remaining costs by 40%, give or take. Our customers still had the flexibility to spin up, down, and out their Elasticsearch nodes, without forcing us to constantly juggle, combine, split, and recombine our reservations. At the end of the day, we saved 50%. That is $600k per year that can go towards engineering salaries instead of enriching our IaaS provider. Download KubernetesGet involved with the Kubernetes project on GitHub Post questions (or answer questions) on Stack Overflow Connect with the community on SlackFollow us on Twitter @Kubernetesio for latest updates
Quelle: kubernetes

Introducing Docker for Windows Server 2016

Today, Microsoft is announcing general availability of Windows Server 2016 at the Ignite conference in Atlanta. For Windows developers and IT-pros, the most exciting new Windows feature is containers, and containers on Windows Server 2016 are powered by Docker.
The first version of Docker was released in 2013, and in the 3 years since launch, Docker has completely transformed how Linux developers and ops build, ship and run apps. With Docker Engine and containers now available natively on Windows, developers and IT-pros can begin the same transformation for Windows-based apps and infrastructure and start reaping the same benefits: better security, more agility, and improved portability and freedom to move on-prem apps to the cloud.
For developers and IT-pros that build and maintain heterogenous deployments with both Linux and Windows infrastructure, Docker on Windows holds even greater significance: The Docker platform now represents a single set of tools, APIs and image formats for managing both Linux and Windows apps. As Linux and Windows apps and servers are dockerized, developers and IT-pros can bridge the operating system divide with shared Docker terminology and interfaces for managing and evolving complex microservices deployments both on-prem and in the cloud.

Running Containers on Windows Server
Docker running containers on Windows is the result of a two-year collaboration between Microsoft that involved the Windows kernel growing containerization primitives, Docker and Microsoft collaborating on porting the Docker Engine and CLI to Windows to take advantage of those new primitives and Docker adding multi-arch image support to Docker Hub.
The result is that the awesome power of docker run to quickly start a fresh and fully isolated container is now available natively on Windows:
PC C:> docker run -ti microsoft/windowsservercore powershell
Windows PowerShell

Copyright (C) 2016 Microsoft Corporation. All rights reserved.

PS C:>
The kernel containerization features are available in all versions of Windows Server 2016, and are also on Windows 10 systems with the Anniversary Update, and the Windows-native Docker daemon runs on both Windows Server 2016 and Windows 10 (although only containers based on Windows Server build and run on Windows 10).
docker run on Windows comes with the same semantics as on Linux: Full process isolation and sandboxed filesystem (and Windows Registry!) with support for layering changes. Each container sees a clean Windows system and cannot interfere with other processes (containerized or not) on the system.
For example, two dockerized apps using different Internet Information Services (IIS) versions and different .NET frameworks can co-exist merrily on the same system. They can even write to their respective filesystems and registries without affecting each other.
With containerization, Windows IT-pros get most of the isolation and release-artifact-stability benefits of VMs, without the resource overhead and lost agility inherent in hardware virtualization.
Similar to how containers on Linux can run with different security profiles, containers on Windows run in one of two isolation modes:

Windows Server Containers use the same shared-kernel process-isolation paradigm known from Linux. Since containers run as normal (but isolated) processes, startup is fast and resource overhead is minimal.
With Hyper-V isolation, container processes run inside a very minimal hypervisor created during container start. This yields potentially better isolation at the cost of slower startup and some resource overhead.

Isolation can be set with a simple switch passed to docker run:
docker run –isolation=hyperv microsoft/nanoserver
As long as the underlying host supports the requested isolation mode, any Windows container image can be run as either a hyper-v or server container and a container host can run both side by side. Container processes are oblivious to the isolation mode they run in, and the Docker control API is the same for both modes.
This makes isolation mode not generally a developer concern and developers should use the default or what’s convenient on their system. Isolation mode does give IT-pros options when choosing how to deploy containerized apps in production.
Also note that, while Hyper-V is the runtime technology powering hyper-v isolation, hyper-v isolated containers are not Hyper-V VMs and cannot be managed with classic Hyper-V tools.
For readers interested in details of how containers are implemented on Windows, John Starks’ black belt session at DockerCon ‘16 is a great introduction.

Building Windows Container Images
Thanks to layering improvements to the Windows Registry and filesystem, docker build and Dockerfiles are fully supported for creating Windows Docker images. Below is an example Windows Dockerfile that Stefan Scherer has proposed for the Node.js official Docker library image. It can be built on Windows with docker build:
FROM microsoft/windowsservercore
ENV NPM_CONFIG_LOGLEVEL info
ENV NODE_VERSION 4.5.0
ENV NODE_SHA256 16aab15b29e79746d1bae708f6a5dbed8ef3c87426a9408f7261163d0cda0f56
RUN powershell -Command
$ErrorActionPreference = ‘Stop’ ;
(New-Object System.Net.WebClient).DownloadFile(‘https://nodejs.org/dist/v%NODE_VERSION%/node-v%NODE_VERSION%-win-x64.zip’, ‘node.zip’) ;
if ((Get-FileHash node.zip -Algorithm sha256).Hash -ne $env:NODE_SHA256) {exit 1} ;
Expand-Archive node.zip -DestinationPath C: ;
Rename-Item ‘C:node-v%NODE_VERSION%-win-x64′ ‘C:nodejs’ ;
New-Item ‘%APPDATA%npm’ ;
$env:PATH = ‘C:nodejs;%APPDATA%npm;’ + $env:PATH ;
[Environment]::SetEnvironmentVariable(‘PATH’, $env:PATH, [EnvironmentVariableTarget]::Machine) ;
Remove-Item -Path node.zip
CMD [ “node.exe” ]
Note how PowerShell is used to install and setup zip files and exes: Windows containers run Windows executables compiled for Windows APIs. To build and run a Windows container, a Windows system is required. While the Docker tools, control APIs and image formats are the same on Windows and Linux, a Docker Windows container won’t run on a Linux system and vice-versa.
Also note that the starting layer is microsoft/windowsservercore. Starting FROM scratch is not an option when creating Windows container images. Instead, images are based on either microsoft/windowsservercore or microsoft/nanoserver.
The Windows Server Core image comes with a mostly complete userland with the processes and DLLs found on a standard Windows Server Core install. With the exception of GUI apps and apps requiring Windows Remote Desktop, most apps that run on Windows Server can be dockerized to run in an image based on microsoft/windowsservercore with minimal effort. Examples include Microsoft SQL Server, Apache, Internet Information Services (IIS) and the full .NET framework.
This flexibility comes at the cost of some bulk: The microsoft/windowsservercore image takes up 10GB. Thanks to Docker’s highly efficient image layering, this is not a big problem in practice. Any given Docker host only needs to pull the base layer once, and any images pulled or built on that system simply reuse the base layer.
The other base layer option is Nano Server, a new and very minimal Windows version with a pared-down Windows API. Lots of software already runs on Nano Server, including IIS, the new .NET Core framework, Node.js and Go. And the Nano Server base image is an order of magnitude smaller than Windows Server Core, meaning it has less dependencies and surface area to keep updated. Nano Server is an exciting development, not only as a base for minimal containers that build and boot quickly, but also as a Minimalist Operating System that makes for a great container host OS running just the Docker daemon and containers, and nothing else.
With the choice of Windows Server Core and Nano Server, developers and IT-pros can opt to lift-and-shift existing Windows-based apps into Server Core containers or adopt Nano Server for greenfield development or incrementally as part of breaking monolithic apps into microservices components.
Docker is working with Microsoft and the community to build container images based on both Windows Server Core and Nano Server. Golang, Python and Mongo are available as official Docker images (more are on their way), and Microsoft also maintains a set of very popular sample images.
Summary
Today’s announcement of Docker Engine building, running and managing containers on Windows is the fruit of years of labor by teams at both Microsoft and Docker and by the Docker community. We’re incredibly proud of the work we’ve done with Microsoft to bring the benefits of containerization to Windows developers and IT-pros, and we’re excited about the prospect of getting Windows and Linux technologists building, shipping and running apps together with a common set of tools and APIs.
Here are some resources to help you get started

Sign up to be notified of GA and the Docker Datacenter for Windows Beta
Register for a webinar: Docker for Windows Server
Learn more about the Docker and Microsoft partnership

The post Introducing Docker for Windows Server 2016 appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Docker Announces Commercial Partnership with Microsoft to Double Container Market by Extending Docker Engine to Windows Server

With industry analysts declaring Windows Server with more than 60% of the x86 server market, and citing Microsoft Azure as the fastest-growing public cloud, it comes as no surprise that Microsoft, even at its current scale, is further extending its leadership as a strategic, trusted partner to enterprise IT.
It is this industry leadership that catalyzed our technical collaboration in the Docker open source project back in October 2014, to jointly bring the agility, portability, and security benefits of the Docker platform to Windows Server.  After two years of joint engineering, we are excited to unveil a new, commercial partnership to extend these benefits for both Windows developers targeting Windows Server and enterprise IT professionals.
Specifically, the commercial partnership entails:

The Commercially Supported Docker Engine aka “CS Docker Engine”, Docker, Inc.’s tested, validated, and supported package of Docker Engine, will be available to Windows Server 2016 customers at no additional cost
Microsoft will provide Windows Server 2016 customers enterprise support for CS Docker Engine, backed by Docker, Inc
Docker and Microsoft will jointly promote Docker Datacenter to enable IT Pros to secure the Windows Server software supply chain and manage containerized Windows Server workloads, whether on-prem, in the cloud, or hybrid.

These fruits of this partnership for the first time offer enterprise IT professionals with a single platform for both Windows and Linux applications on any infrastructure, whether bare metal, virtualized, or cloud.
 

CS Docker Engine and Docker Datacenter for Windows Server represent a major addition that complements several other joint initiatives as depicted above.
 

For developers, the integration of Visual Studio Tools for Docker and Docker for Windows provides complete desktop development environments for building Dockerized Windows apps;
To jumpstart app development, Microsoft has contributed Windows Server container base images and apps to Docker Hub;
For IT pros, Docker Datacenter will be designed to manage Windows Server environments in addition to the Linux environments Datacenter already manages.

Availability
Windows Server 2016 will be generally available in October, when Windows Server 2016 customers will be able to download the first version of the CS Docker Engine. Docker Datacenter for managing Windows Server containerized workloads will be available shortly thereafter.  While the announcements today represent another significant milestone in our partnership, Docker and Microsoft are just getting started.
Check out the below to learn more!

Learn more about Docker on Windows Server
Sign up to be notified of GA and the Docker Datacenter for Windows Beta
Register for a webinar: Docker for Windows Server
Learn more about the Docker and Microsoft partnership

The post Docker Announces Commercial Partnership with Microsoft to Double Container Market by Extending Docker Engine to Windows Server appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/

Walk, Jog, Run: Getting Smarter About Docker

I’ve spent most of the summer traveling to and speaking at a lot of different trade shows: EMC World, Cisco Live!, VMworld, HP Discover, Dockercon, and LinuxCon (as well as some meetups and smaller gatherings). A lot of the time, I’m speaking to people who are just getting familiar with Docker. They may have read an article or have had someone walk into their office and say “This Docker thing, so hot right now. Go figure it out”.
Certainly there are a number of companies running Docker in production, but there are still many who are asking fundamental questions about what Docker is, and how it can benefit their organization. To help folks out in that regard, I wrote an eBook.
After someone gets a grasp on what Docker is, they tend to want to dive in and start exploring, but often times they aren’t sure how to get started.
My advice (based on the approach I took when I joined Docker last year) is to walk, jog, and then run:
Walk: Decide where you want to run Docker, and install it. This could be Docker for Mac, Docker for Windows, or just installing Docker on Linux. Pick whatever makes the most sense for your environment and load it up.
From there run your first Docker app: hello-world
$ docker run hello-world
After you know you have Docker running, work your way through one of our labs. I’d suggest starting with this beginner lab we have on GitHub.
Jog: You’ve got Docker installed, and you have played with the command line a bit. You’ve probably run a few containers as well. The next step is to try and replicate a commonly deployed application in Docker.
When I started working with Docker the first application I tried to deploy was WordPress. It is a good example because it has a few moving parts (the web front end and a database backend), and there are about a thousand blogs on how to do it. Read a bunch of blogs, and then give it a go.
After WordPress I decided to build a very simple CI pipeline using Jenkins. CI is a great use case for Docker. Docker vastly simplifies your build environments, and, because containers deploy so quickly, customers can see some real time savings as well.
Run: So you’ve been able to stand up someone else’s application, now it’s time to take the next step. Deploy one of your own. Take an existing application, and move it into a container.
This will allow to build your own Dockerfile from scratch, and maybe even a Docker Compose file as well. Try and choose an app with on a few moving parts, and be mindful of things like static configs and port mappings which can add additional complexity.
So download the eBook  and get started walking. If you get stuck, ask for help from the community, or attend a meetup. There are a growing number of Docker experts out there who are always more than willing to lend a hand.

Practical advice to walk, jog, run your way to @Docker expertiseClick To Tweet

 
Here are some helpful links:

Download Docker onto your favorite environment
Check out all the hands on tutorials for Docker and product documentation
Learn more about our latest Docker 1.12 release
Join our community, or attend a meetup or ask a Docker expert for help

The post Walk, Jog, Run: Getting Smarter About Docker appeared first on Docker Blog.
Quelle: https://blog.docker.com/feed/