Monday, 27 July 2015

Docker and Virtualisation links


Docker for Java Developers: How to sandbox your app in a clean environment

Continuous Delivery with Docker Containers and Java EE

A Practical Introduction to Docker Container Terminology

ANNOUNCING DOCKER TOOLBOX

Docker cheat sheet







Why I love Docker

In my view Docker will enable the IT industry to adopt to DevOps and Microservices not by being a tool, but rather being a technology that fundamentally changes how we manage IT services. The practical difference is that we can now life-cycle manage everything isolated. If one application needs a new version of a JVM or PHP library they can safely upgrade without affecting other containerized applications. This enforces the organization to embrace DevOps culture and processes.
Docker also enables us to create small independent deployments, which is the foundation of Microservices architecture. This does however add another dimension to the problem, where we have to manage service dependencies. I’ll talk more about Microservers and how to manage remote dependencies in later blogs.
So to summon up, why I love Docker is not only that it’s easy to use, gives me high density and isolation, the main reason to me is that it’s going to change how we operate and manage applications. 





What is LXC and how to get started?

You don't always need to use Docker!

Linux Containers (LXC) are lightweight virtualization technology and provide a free software virtualization system for computers running GNU/Linux, This is accomplished through kernel level isolation, It allows one to run multiple virtual units (containers) simultaneously on the same host.
A container is a way to isolate a group of processes from the others on a running Linux system. By making use of existing functionality like the Linux kernel's new resource management and resource isolation features (Cgroups and name spaces), these processes can have their own private view of the operating system with its own process ID (PID) space, file system structure and network interfaces.
Containers share the same kernel with anything else that is running on it, but can be constrained to only use a defined amount of resources such as CPU, memory or I/O. By combining containers with other features like the Btrfs file system , it will be possible to quickly set up multiple lightweight isolated Linux instances on a single host. Therefore containers are better compared to Solaris zones or BSD jails.

Linux Containers Compared to KVM Virtualization

The main difference between the KVM virtualization and Linux Containers is that virtual machines require a separate kernel instance to run on, while containers can be deployed from the host operating system. This significantly reduces the complexity of container creation and maintenance. Also, the reduced overhead lets you create a large number of containers with faster startup and shutdown speeds. Both Linux Containers and KVM virtualization have certain advantages and drawbacks that influence the use cases in which these technologies are typically applied:

KVM virtualization

KVM virtualization lets you boot full operating systems of different kinds, even non-Linux systems. However, a complex setup is sometimes needed. Virtual machines are resource-intensive so you can run only a limited number of them on your host machine.
Running separate kernel instances generally means better separation and security. If one of the kernels terminates unexpectedly, it does not disable the whole system. On the other hand, this isolation makes it harder for virtual machines to communicate with the rest of the system, and therefore several interpretation mechanisms must be used.
Guest virtual machine is isolated from host changes, which lets you run different versions of the same application on the host and virtual machine. KVM also provides many useful features such as live migration. For more information on these capabilities, see Red Hat Enterprise Linux 7 Virtualization Deployment and Administration Guide.

Linux Containers:

The current version of Linux Containers is designed primarily to support isolation of one or more applications, with plans to implement full OS containers in the near future. You can create or destroy containers very easily and they are convenient to maintain.
System-wide changes are visible in each container. For example, if you upgrade an application on the host machine, this change will apply to all sandboxes that run instances of this application.
Since containers are lightweight, a large number of them can run simultaneously on a host machine. The theoretical maximum is 6000 containers and 12,000 bind mounts of root file system directories. Also, containers are faster to create and have low startup times.




LXC gives you OS containers that are like lightweight efficient VMs. Docker takes this as a base, runs the container OS without an init system to give you a container that can only run a single app at a time, removes storage persistence and builds the file system with layers of aufs.. For the vast majority of use cases limiting the container to a single app adds complexity and has limited value beyond PAAS centric use cases.
Further removing a mature OS init system that manages processes and apps introduces significant operational issues in day to day container usage and management, given the large ecosystem of Linux apps and tools expect a multi-process OS environment to work. So for Docker containers you need to find a Docker way to do things.
Unlike LXC containers Docker containers do no behave like lightweight VMs and cannot be treated as such. Docker containers are restricted to a single application by design.





voxxed.com: 9 Docker Recipes for Java EE Applications
e.g.Docker Recipe #7: Two Containers on Different Hosts using Docker SwarmDocker Recipe #2: Application Server + In-memory DatabaseDocker Recipe #9: Test Java EE Applications using Arquillian Cube


Lets review.. Docker (again) abysmal performance, hacky workarounds and rage inducing user experience

If your development workflow is sane, then you will already understand that Docker is unnecessary. All of the features which it claims to be helpful are either useless or poorly implemented, and it's primary benefits can be easily achieved using namespaces directly. Docker would have been a cute idea 8 years ago, but it's pretty much useless today.










Burr Blog: Getting Started with Docker, boot2docker, on Windows for the Java Developer
For those of you following along at home (not physically making it to TriJUG or DevNexus), please check out the written Docker Tutorial materials - the focus is on the Windows-based enterprise Java Developer. With our JBoss Tools project, we receive opt-in usage data that shows us that the vast majority of enterprise Java developers run Windows as their primary desktop. While Docker is a Linux innovation, it can be run on Windows via boot2docker (which includes VirtualBox in its installation). And Java developers do want to understand how building Docker images and running containers could impact their future toolchain and workflow.
I wrote the tutorial documents in markdown (many thanks to Pete Muir for helping my formatting) and stored them in github to make them "forkable" - hopefully allowing anyone who wishes to run their own Docker Workshop use the materials and perhaps even send back a pull request.
Getting Started with Docker, boot2docker, on Windows for the Java Developer
Adding MySQL and additional tips for Java EE on Docker


Brian Christner: Docker Base Image OS Size Comparison


Posted by at
Labels: , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)