Containers have become identified with 'webscale' but sometimes it's useful to take a step back and consider some of the more straight forward benefits that don't involve adopting any complicated stack.
There is still a lot of confusion about containers and we have a quick guide that gets you up to speed.
First lets get a layer of complexity out of the way. Containers are like lightweight VMs that are more portable. LXC gives you that out of the box. Docker based on LXC modified the container and went in a different direction with single process containers, non standard OS environments, layers and ephemeral storage.
In this article we do not want any of the overhead. We are going to focus on containers purely as simple lightweight VMs. And here is where the natural advantages of containers begin to emerge.
Containers are just a folder on your filesystem and can be simply zipped and moved across servers at will. You can deploy all your apps in containers and you are not dependent on any server or provider, thus you cannot be locked in.
This gives you immense flexibility and freedom. You have abstracted away the host and can simply move your applications when required. This makes everything easier.
If you are on Digitalocean and would rather move to Vultr or Linode or vice versa it's as simply as copying your containers across. No lock in. This applies to any server, using containers means the server ceases to matter. The same applies to AWS or GCE or any provider as long as you don't use any of their specific tooling or apps.
Many are rightfully wary of complexity, they know how to install and run apps on their servers. Why adopt containers? Well avoiding lock-in is one good reason and containers are simple to use once you understand them and other use cases emerge.
A container is just a namespaced process like any other process on your system. A Linux namespace can isolate processes. The Linux kernel supports 6 main namespaces and a container is a process launched in its own namespace. The container manager launches an init in the namepace so you can get a separate OS running as an isolated process. You can thus run multiple Linux distributions simulteneously, so you could be on a Ubuntu host and run Fedora, Centos and Debian containers, useful for testing and deployment.
The container is also launched in its own network namespace so it get its own network stack isolated from the host. This is what makes them like lightweight VMs. Docker does not launch an OS init and instead directly launches the application process which gives you a single process container and a non standard OS environment which requires its own tooling and understanding.
Conceptually that's all a container is. The container manager also sets up a default NAT network for containers similar to VM managers. Containers get their networking from this network. Container managers also provide a library of base OS images for instance Centos, Debian, Ubuntu, Alpine or Arch. You can download base OS images, start them and install your apps in them. So you could be on an Ubuntu host and run multiple container OSs. That's a lot of flexibility. You can login, logout, shutdown and reboot a container and treat it just like a VM and it supports all services a VM would.
With LXC, containers are placed in the /var/lib/lxc folder. Your first step is to create a container with the lxc-create command. This gives you a list of base OS container images. Once downloaded you can start the container and install your apps. You can clone contaiers and make snapshots with the lxc-copy command. To run a container simply start it with lxc-start. You can get an overview of all runing containers with the lxc-ls command. You can stop a containe with the lxc-stop command.
You can login to a container with the lxc-attach command. This will drop you into a terminal in the container. This is just like logging into a VM. Here you can run all commands as you would on any host, you can install and run apps and do anything you would in a VM. You can even poweroff and reboot the container with the standard commands.
By default the container is running in a private NAT network and is not accessible outside your host similar to how your home devices are connected to youe wifi router and can access the internet but are not accessible from outside. To make containers accessible outside the host you can use port forwarding.
For instance if Nginx is running in a container on port 80 and you would like to access it you can simply forward host port 80 to container port 80. There are a number of networking options you can adopt depending on your setup.
The container with installed apps is located in the /var/lib/lxc folder. You can copy and move files to and from the container with standard filesystem operations. This is where all the flexibility of containers comes from. Since this is a simple folder it can be easily moved across servers. On any server that has LXC installed you can start and run the container.
LXC containers also do not have any limitations and constraints about storage and layers. Layers and 'volumes' or bind mounts are supported and It is left to the user to use them as required. Container storage behaves exactly like VM or host storage. It's there untill you choose to delete it. You can store application state outside the container with bind mounts or volumes as Docker users know them as. Architecture and concepts like statelessness is left to the user and this delivers maximium flexibility. In the real world most apps are not designed to be stateless and 99% of users have to deal with state.
Flockport supports LXC containers and provides an App store and orchestration. The Flockport App store lets you downloaded and run apps without any setup or configuration. So if you need to run Wordpress or Discourse simply download the app from the store and access it on the browser. All apps are signed and downloaded securely.
Flockport lets you provision servers and deploy, run and move containers across servers in minutes. You can have your apps deployed on a set of servers or a provider and move everything over to another provider seamlessly.