Overview on Containers including their use cases, upsides, demerits and challenges.
Containers will become more prevalent. Existing models can integrate Containers and a vision with its existing services and methods eg. Apps modernisation, Integration, Security, Java frameworks, EJBs
Key factors which impact Container build and management:
Within the Enterprise there are many questions about the use cases of Containers and Virtual Machines and what the differences might be. As well, within AWS, Containers are now becoming a key part of the infrastructure through the utility of Elastic Container Services, Docker and Elastic Beanstalk. This is a quick overview of the differences between Docker and Containers, with VMs.
Docker:
Docker is a piece of software that allows us to automate the installation and distribution of applications inside a Linux Container (LXC). Docker automates the many repetitive tasks of setting up and configuring development environments, so engineers can refocus efforts on building code that is error-free, documented and which resolves business requirements and technical specifications.
Container(s):
A Container possesses all the artefacts that an application needs to run from within its isolated package. This may include system libraries, code, system tools, run time, etc. Unlike a VM or Virtual Machine, a Container does not include an operating system. This reduces the overhead and ‘weight’ of the Container, making them ‘lightweight’ implementations specific applications and functions. These characteristics in turn make Container applications very portable, flexible, and scalable across a Cloud environment. This ensures that the application will always run as expected, regardless of its deployment location.
How are Docker and Containers, different from VMs?
Building Docker inside in a container means that the container and associated software will only share kernel resources with all the other virtual and bare metal software, running on your machine and therefore you don’t need the installation footprint that a VM would need.
A VM installs an entire operating system separately with the large overhead of OS installation and configuration. This means that typically, a VM, running a full operating system, can be gigabytes in size. Docker and LXC Containers do not carry this added overhead and can start up, and be shut down, incredibly quickly, sometimes in less than one second – unlike a VM.
There is also no HyperVisor within a Container – but something akin, named a ‘Container Engine’. A Container Engine is usually a cluster of instances running the Container(s). Within AWS, this is called ECS (Elastic Container Services). A Container Engine consists of one or more node instances, and a managed endpoint. This container cluster is the foundation of a Container Engine application—pods, services, and replication controllers all run on top of a cluster. The image below illustrates this:
Light-Weight Builds:
LXC’s and Docker containers owe their remarkable efficiency to the use of Linux Cgroups and their related name space isolation, which serve to dynamically isolate processes from each other allowing them full access to appropriate kernel resources without exposing other resources and processes to any risk. This means that any number of containers can fully share the computer resources of their hardware host.
VMs on the other hand have to fire up a full virtual OS for each virtual instance meaning that there’s an enormous duplication of effort and an associated drain on system resources. The host of a VM is often called a hypervisor as opposed to just host of an LXC container. However, it’s worth noting that many LXC users will also refer to their host machines as hypervisors.
Density:
Docker instances can be more densely packed on servers, which can be advantageous in a cloud environment where costs can make or break a project. If you need less storage space, if you need less memory, if you need less computing space, or computing resources you can fit more applications into a hardware profile.
Free App Repositories:
There exist many thousands of free app repositories that can do just about any task either natively or with some development. This improves and reduces the cost of app building. It also leads to standardisation.
The Key feature:
The key feature and use case of both Docker (single piece of definable software) and a Container (a definable executable application) is immutability and reuse. Both Docker and a Container will run, in the targeted OS and system environment, as expected, anywhere, anytime. You literally pick them up, deploy and run. This important principle is central to building a professional software development practice.
On AWS:
Docker and existing Containerized applications packaged locally, work seamlessly on Amazon ECS (Elastic Container Service). ECS is essentially the AWS implementation of Docker and Containers (Linux bound and based).
ECS:
EC2 Container Services removes the need to manage a cluster management system. It is a service offered by AWS that abstracts the management of the Containers and instance cluster, away from the client. These tasks are usually very time consuming and require a lot of overhead to continually monitor, maintain and scale. With Amazon ECS there is no need to install any management software for your cluster. Neither is there a need to install any monitoring software. All of this and more is taken care of by the service.
ECS Monitoring:
Monitoring is handled by AWS CloudWatch, which will monitor metrics against the containers and clusters. You can easily create alarms based off of these metrics, providing a notification of when specific events occur, such as a cluster size scaling up or down.
Security:
Given that ECS is a cluster of instances, we can use security groups to implement instance level security at the port and protocol level, along with ELB and auto scaling. Although these EC2 instances form a cluster, they still operate in much the same way as a single EC2 instance.
ECS Scalability:
The clusters themselves act as a resource pool, aggregating resources such as CPU and memory. This make ECS dynamically scalable. This means that we can start a cluster as a single, small instance, but it can dynamically scale to thousands of large instances. Multiple instance types can be used within the cluster if required. ECS is region based and constrained. ECS can used with Auto-Scaling, as any normal set of EC2 instances to scale up or down, dynamically.
Automation:
For more advanced architectures we can combine Docker, ECS with Jenkins and Github to automate a DevOps deployment of Container applications to an ECS stack using Cloud Formation and Jenkins.
