The Essential Guide to Containers

Transcription

1 What are containers? Why should you care? This guide examines containers from a technical viewpoint. The goal is to bring clarity to developers and IT operations regarding what containers and Windows containers are, and why they are significant.

2 Contents Containerization Page 3 Virtualization Page 4 What are Containers? Page 5 Container deployment Page 9 What comes next for Containers? Page 10 2

3 Containerization This term has become popular recently in the IT industry. Containerization signifies an employment of containers, an OS virtualization technology, as a software packaging and deployment vehicle. Neither container nor OS virtualization is a new idea. And we can trace the concept of an OS container back to the introduction of chroot of UNIX V7 in One way to fully appreciate the container technology is to first get a clear understanding of virtualization. 3

4 What is virtualisation? This virtualization in the context of IT denotes the ability to run multiple resource instances above a referenced layer, while each instance runs in isolation, i.e. as if it is the only instance occupied the underlying hardware. The implication is in a multi-tenant environment, each tenant runs in its own virtualised environment and is isolated from each other. There are various mechanisms like access control, whitelisting, etc. to manage what resources are available and what operations are permitted to execute in a virtualization instance. Today, Virtual Machines (VMs) is a form of hardware virtualization where multiple OS instances may run in isolation with the same hardware. Benefits of an OS virtualization System Speed Management Disk footprint Anywhere implementation Ability to freeze and unfreeze containers Containers can easily be mov What is OS virtualization? Similarly, OS virtualization indicates that the reference layer is anchored on the host OS to run multiple application instances, while each application runs in isolation. A NCC Group whitepaper has highlighted the pros and cons of an OS virtualization system, as summarised below with a recommendation on reviewing the details to understand the rationale behind each benefits and drawbacks. Drawbacks of an OS virtualization System Security Software all the way down Problem with legacy code Live Migration A homogeneous environment Worth pointing out that the above list is one perspective addressing many interesting and valid points. A good approach to evaluate OS virtualization or any other technologies is to review a list like the above in the context of business requirements with applicable IT practices and relevant technologies, before making a conclusion. OS virtualization apparently has much to do with containers. Which brings up the next question. 4

5 What are containers? As Docker is emerging as a viable service delivery vehicle, container has become synonymous with Docker and signifies a standardised way of packaging and deploying software with biases. Here biases are specifications of a container including host OS dependencies, customisation and start-up operations. Such that at run time, each container is opinionated and projects a unique view of the host OS based on the customisation internal to the container, while without actually altering the host OS. Imagining a host OS as a wall, software running within a container is similar to examining the wall while wearing a goggle without knowing it. Lenses, filters or drawings deliberately put on the viewing (i.e. customisation) will appear superimposed on the wall and present this unique or biased view no matter where the viewer turns. Stop a container is as if taking off the goggle, the wall remains unchanged. Bob Familiar, National Practice Director at BlueMetal uses these descriptions to capture key characteristics of containers. VMs, hardware virtualization and IaaS The following diagram depicts logical views of a container and a VM. Here, the VM runs on type 1 hypervisor which is a small piece of code sitting right above the hardware virtualising, i.e. enabling the isolation of the OS instance from the hardware and other VMs. Purposely, much is simplified and many details are omitted here. The key is that virtualization in this model is set at the hardware level. And an installed OS with its managed software resources with hardware virtualization is packaged and managed as a file, such as a VHD file. Upon deployed and started, this file then expands into a VM and becomes an OS instance with processes running. Comparing Containers and Virtual Machines Containers and virtual machines have similar resource isolation and allocation benefits, but function differently because containers virtualise the operating system instead of hardware, containers are more portable and efficient. Everything required to make a piece of software run is packaged into isolated run-time environments called containers Unlike VMs, containers do not bundle a full operating system; only libraries and settings required to make the software work are needed This makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it s deployed VM vs. container These two can be confusing. They have much in common, yet different in many ways. A general computing model may be oversimplified and described with a few logical components: hardware, software, network and storage. Hardware represents all the physical parts needed to construct the computing facility, either a personal device or an enterprise data centre. Software encompasses the operating system with application software installed. Network and storage are collections of resources to establish connectivity and store data, respectively. CONTAINERS VIRTUAL MACHINES And with a server OS, a VM deployed can then become part of an application infrastructure where the application can be a compute, network, storage, or LOB service. The ability to construct application infrastructure with a set of VMs and deploy on demand at scale is essentially what, Infrastructure as a Service (IaaS), is referred as in cloud computing. 5

6 Containers, OS virtualization and PaaS Considering an apartment building, each apartment relies much on resources available via the building from the construction, water, electricity to entrances, lobby and elevators. And although tenants share the building, the address, the public facilities and perhaps even the same apartment size and layout, a tenant may have a unique perspective and hold very different opinions on matters associated with the building. Nonetheless, a tenant can declare the building address as a home address, as if the entire build is one s home. Containers are similar to those apartments, while a host OS is like the building shared by containers. With OS virtualization, a container is application construct, lives within the host OS instance and runs as a process in isolation. Each container is opinionated with its own projection of the OS via declared OS dependencies and enforced customisation introduced when the container is built. And these biases do not change throughout the life time of a container s image. However, because the isolation is at a process level, a container does not know the existence of other containers on the same host and it is as if the entire OS is consumed by the and only the container. Form a deployment s point of view, containers are deployed as packaged software with OS dependencies and customisation. A container is built with an associated Dockfile. Which specifies the OS dependency, the customised content and operations to build the container. Notice the intended OS itself is not part of the container construction. For instance, a container based on ubuntu is not deployed with ubuntu, other than assuming ubuntu is in place at the container start time. The concept of deploying an application with an assumed OS runtime in place is the essence a realisation of Platform as a Service (PaaS). Platform here is a runtime environment to support a target application. Runtime is an umbrella term to designate all required resources including a host OS and the rest for executing code. Platform as a Service means a target runtime environment is available as a service, namely available on demand. Realise prior to starting the service delivered by a container, the target application runtime is first configured as defined in the Dockerfile. Therefore, considering a service delivered by containers, the premise is that the application runtime environment is defined within the container and must be ready prior to starting the service. Form the service s point of view, the application runtime is basically on demand. Hence, this is equivalent to a PaaS delivery. Friends of foes? Fundamentally, VMs and containers are with different roles and serve different purposes. However, both are essential tools to modernise data centres and applications. For a legacy application migration with lift-and-shift, VMs are an apparent approach to minimise relevant changes on applications. Any refactoring or new development of applications, one should include assessing containers-based design and expect containers will continue play an important role in software design in the next few years. VMs and containers, they are complementary and may reveal two different focuses where the former infrastructure-oriented construction, the latter application-centric with microservices architecture in mind. And it is never wrong to combine them when increasing delivered business values. Ultimately all should still be based on business requirements and the nature of a problem one is trying to solve. Here is a table highlighting some characteristics of the two. Virtual Machine Container Virtualization type Hardware virtualization OS virtualization Runtime An OS instance A process Performance overhead Noticeable Small and may not be noticeable Startup time Generally, minutes Relatively, very short Resources restrictions Applicable Applicable Security VM logical boundary Process logical boundary in OS Target scenario Servers Service and applications Role Infrastructure, app server App deployment vehicle 6

7 Windows containers Microsoft has been a contributing member in the container community and now offered two different runtime environments for Windows containers. First as far as container is concerned, a Windows container runs just like a Linux container. And Docker CLI is almost fully compatible. A Linux development should be operate on Windows containers transparently with Docker CLI. Needless to say, the container feature just like the rest Windows features can be set with PowerShell Cmdlets, Install-WindowsFeature and Uninstall-WindowsFeature. So what is about the two runtime environments of Windows containers? Both Windows 10 and Windows Server 2016 have integrated container technology into the OS. This capability lights up as an OS feature, as shown below, when the corresponding hardware has already been enabled with virtualization. Windows Server containers In Windows 10, one may turn on the container feature in Programs and Features of Control Panel. Notice that at the time of writing this article, Windows 10 natively supports Hyper-V container and only Hyper-V container. More details on this follow. MEanwhile, the following Windows dialog shows the container feature is available in the feature list when adding roles and features using Server Manager in Windows Server A Windows Server container is just like a Docker container running in a hosted Windows environment. All Windows Server containers running on a host share the same host OS, and each container runs in isolation and as a process. Since the host OS is shared, if to start a process within a Windows Server container, the process will be visible and appear on the Process and Details lists when viewed with Task Manager on the host machine, for example. This follow screen capture demonstrates this examination. Note that the examined process here is a PING.EXE and not the process where the container is running within. 7

8 Windows Hyper-V containers The other runtime is a captivating one, the so-called Hyper-V container. It still runs and smells just like a regular Docker container. Distinctively, a Hyper-V container is a Windows container running within a highly optimised VM. This VM is just there, not accessible and does not provide a user interface for an administrator to remotely connect. One way to verify the configuration is to start a process within a Hyper-V container, and this process will not be visible since now the container is in an optimsed VM which does have a local copy of the kernel. Consequently, and contrary to what is experienced in a Windows Server container, the process now will not show up on the host Task Manager s list in Process and Details tabs. The above presents the user experience when examining a PING.EXE started within a Hyper-V container, and on the host OS, the Task Manager is not aware of what processes are running with the Hyper-V container. The key distinction between a Windows Server container and a Hyper-V container is that their runtime environments are with different isolation levels. The above examinations conclude that: A Windows Server container denotes the runtime environment is based on OS virtualization where all containers run on a shared host OS. The isolation is at the process level. The effect is that those processes running within Windows Server containers are exposed to the host OS. A Hyper-V container indicates the runtime environment is an optimised and invisible VM, despite Microsoft does not provide the implementation details, architecturally this apparently is with higher degree of isolation and different from that of a Windows Server container. As the above-mentioned scenario verifies that a process running within a Hyper-V container is not visible on the host, the isolation of a Hyper-V container apparently is at a VM level. 8

9 How to deploy in either runtime environment? Very straightforward, it is. The following sample statements are based on those used in the above screen captures with to the relevant setting highlighted. Those who are not familiar with the docker run command may reference Docker s documentation. This deploys a Windows container with both the host name and the container name as nano : docker run -it -h nano name nano microsoft/nanoserver While this a Hyper-V container with both the host name and the container name as nanoh : docker run -it -h nanoh isolation=hyperv name nanoh microsoft/ nanoserver Notice that both statements employ the same image, i.e. microsoft/ nanoserver. Hence, both have the same composition and original content of a container. The target runtime environment is signified by the flag, --isolation, where the value hyperv indicating a container runtime to be set as that of a Hyper-V container, which is an optimised VM. Since the first statement is without the isolation flag and the container was deployed as a Windows Server container, it appears the default isolation level is set to Windows Server container. Or is it? It turns out that two settings, hyperv and process, are available for isolation flag to designate a container runtime environment with the VM-level or the process-level isolations, respectively. Upon importing the PowerShell module for Docker, the intellisense in PowerShell ISE will display the available isolation level, as shown below. Notice that the default isolation level in Windows Server 2016 is set to process, and Windows 10 hyperv. In fact, at the time this article is written Windows 10 supports Hyper-V containers, and only Hyper-V containers. Therefore, In Windows Server 2016, deploying a container without specifically setting the flag, --isolation=hyperv, the container will by default run as a Windows Server container, i.e. with a process-level isolation. Which behaves the same way as a Docker container running in Linux with a shared host OS. In Windows 10, regardless the presence of the flag, -isolation, and its setting, a container is always deployed as a Hyper-V container, i.e. with a VM-level isolation. This configuration provides a higher isolation since it runs the container in an optimised VM transparent to the user, and adding another layer of isolation provided by the VM. 9

10 Not all Windows container runtime environments are created equal You may have noticed that I have been discrete in using these terms, container type and runtime environment when describing the two different Windows containers. It is significant to distinguish if the difference is due to a Windows Server container and a Hyper-V container are different in the container composition and content themselves, or it is because the discrepancies of the two runtime environments, while the containers are very much identical. The two docker run statements employ the same container image and we may conclude deployed containers will have the same composition and content, i.e. they are technical the same container, per se. Placing them in two different runtime environments, each then behaves accordingly. That means the isolation level of a Windows container is a deployment and not a software design decision. This offers tremendous agility and efficiency in both development and operations. Windows offers a no code change solution to increase or relax the isolation level which has implications on security, traceability, performance, cost, etc. of application development and IT operations. For example, considering the scenarios: What runs in a shared OS environment today may be restricted to run in full virtualization tomorrow due to a change in regulatory compliance or performance requirements. With Windows containers, this can now be easily done with a redeployment of an intended container with the set flag, --isolation=hyperv, without the need to change the code. What must be deployed to a single-tenant environment, i.e. a dedicated VM, in production may be developed and triaged the code not relevant to the isolation level in a process-level isolation, as needed. For whatever reason, a service deployed as Windows containers has a requirement change translated to increase or relax the associated isolation level. Now this can be done without changing the code. Instead, stop the impacted containers, followed by redeploying them with the flag, --isolation, set accordingly. Where to go from here? This article has addresses a number of topics on containers centered on what and why. There are still many important concepts, relevant subjects to examine on containerization. Deploying containers is just a prelude. The exciting and challenging part comes after, that is how to effectively and securely manage the deployed containers. Recognising that containers are supposedly automatous, so any of them can be deployed and forget. It is a very dynamic situation. The ideal deployment platform for containers is a (logical) service bus which is a cluster for high availability. The management, or orchestration, of containers among cluster nodes is a nontrivial problem. And for those who are interested in the management and orchestration of containers, Docker Enterprise Edition and Azure Container Services are good places to start. And on Container Security, here are the study material: Understanding and Hardening Linux Containers by NCC Group and Docker security documentation. Finally, as a friendly reminder, you need to hop on and start now, if not already. The container train is leaving. 10

11 About Insight Today, every business is a technology business. Insight empowers companies of all sizes and government organisations to healthcare and educational institutions with Insight Intelligent Technology Solutions to realise their goals. As a Fortune 500-ranked global provider of hardware, software, cloud and service solutions, our more than 6,000 teammates give clients the guidance and expertise needed to define, architect, implement and manage technology today to help them transform for tomorrow. To learn more call or visit 11 MKT2702