Deploying Secure Containers for Training and Development

Henry Dalziel, Jon Schipp

• Publisher: Syngress
• Year: 2015
• ISBN:
  9780128051047
• Topic: Computer Science
• Subtopic: Cyber Security
• Index: Computer Science

In the book we will be talking about Deploying Secure Containers for Training and Development. The book covers the technology behind Linux-based containers and what they can be used for. Details on how to use containers in training and development are also provided.

• Provides information on using secure containers for training and develpoment.

Chapter 1

Containers

Abstract

Our focus is a subset of what can be used for container something that I’ve been doing a lot with; and then there is using them for software development and event training. Training of IT tools you would find on Linux operating system for example. Containers are typically used to deploy applications on the Internet an example of this is deploying web applications or hosting your website in the container with the Apache or Engine X. These are common things you’ll find on the available used in production by number of companies because they’re very hideous when their package can be reproducible and they’re very scalable. So you can quickly and officially deploy these lightweight containers across your enterprise and to talk about a different way to use these resources.

Keywords

IT tools; containers; Linux; scalability; data; web applications

Containers are typically used to deploy web applications and software stacks. An example of this is deploying software such as WordPress, MySQL, or just hosting your website in a container running Apache or NGiNX. Reproducibility and scalability are two benefits of deployment with containers. You can think of container as a package of software including libraries, services, and the application itself. Having your application and all its dependencies wrapped up in a container allows you to deploy it to any system that uses the same container runtime engine or container specification. Reproducibility is achieved in that way, in addition it’s easily scalable across multiple systems when network traffic is high or provides redundancy when a system needs an upgrade. All one has to do is configure the container to run on multiple systems and tell a load balancer where to redirect traffic. Tools like Kubernetes, Docker Swarm, and others make it easy to scale containers across hosts. While these are typical uses, we will look into the use of containers for software development and training. For example, we can utilize Linux containers to provide a package of a filesystem containing all the common tools used for training on the GNU/Linux operating system. Another example is to compile and run applications for testing and deployment in containers without installing them on your host filesystem. The result of which ends up providing a tidier filesystem and eliminates inconveniences of managing multiple versions of shared libraries or programs.

Let’s move on to describe what containers are and what they can provide. Containers enable a layer of isolation and this is done in the Linux Kernel via two kernel components: namespaces and cgroups. Namespaces divide the operating system into virtual segments. For example, assigning a process to namespace A makes it invisible and unreachable to a process in namespace B, even if root uses the “ps” command in a different namespace. Cgroups are short for control groups, which can apply constraints, or limitations, to system resources such as memory, by utilization; and CPU, by a percentage of its use.

From the perspective of the user, interacting with software such as a web application in a container, a virtual machine, or on bare metal, acts and looks the same. The average user is not able to tell what kind of system they are in, or what kind of level of virtualization that they are using.

Scalability with containers seems to be very easy to do and that’s one of its promising points. You can scale both horizontally and vertically. With vertical scaling we scale by applying more resources to the host: more CPU, more memory, faster disks, etc. You can do this with a virtual machine as well, any software really… You can add more resources to the box and thus can usually perform more work. More interesting though is the number of tools that exist to scale horizontally by clustering nodes to run containers. The Apache Mesos project is one such example where running your application in a container can be scaled over pools of hundreds or thousands of different machines. Newer tools include Google’s Kubernetes and Docker’s very own Swarm.

Containers tend to be lightweight in size which makes them suitable for scaling. The acronym JeOS (Just Enough Operating System) indicates this, in other words it’s alright to say that many images are bare bones. A testament of this is that while using a Debian or Ubuntu Docker container image and issuing the “man” command to view the manual pages will result in a “command not found” error from the shell. This is because even the man-doc package isn’t installed! They tend to be measured in hundreds of megabytes instead of the full distribution one installs which is usually much larger.

Containers share the kernel that is running on the host. This means there is one running kernel, the Linux kernel, and it’s asked for resources directly. The application can ask it to write a buffer to disk, to send a packet across the network, to read from an open file, etc. without having to pass instructions through another layer such as a Hypervisor as is the case in Virtual Machines. This tends to give us a performance increase because the system has to perform less work for kernel requests i.e. system calls. Less instructions and translations means less work and the result is higher level of density for containers than you would have with virtual machines. That means you can run many more containers on a host than you would have been able to with virtual machines. It’s not unheard of to be able to run 1000 containers on commodity hardware.

In sum, applications in containers tend to run faster than their counterparts in a virtual machine. A user can get near bare metal performance in the right conditions and the startup time for a container is often less than a second where multiple seconds is the norm when booting virtual machines.

Let’s delve into a few other differences on security, portability, concurrency, and the kernel. Containers happen to ...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• About the Authors
• Introduction
• Chapter 1. Containers
• Chapter 2. Using Containers in Training
• Chapter 3. Experimentation
• Conclusion
• References