Category Archives: Containers & Kubernetes

LXC Containers

This blog is part of my ongoing series on Docker containers. In this blog, I will take a deviation from Docker and focus on LXC. LXC manages Containers like Docker, there are some differences, I will cover the differences in a later blog. LXC is an Opensource Linux container project from Linuxcontainers.org that provides an user space interface to manage Linux containers.There are other projects from linuxcontainers.org focusing on containers like LXD, LXCFS, CGManager etc. In this blog, I will cover some hands-on stuff I tried with LXC.

My environment:

Ubuntu 14.04 running in Virtuabox in Windows 7.

Hands-on:

To install lxc, I followed the below steps:

sudo apt-get update
sudo apt-get install lxc

Following command creates a Ubuntu LXC container.

sudo lxc-create -t ubuntu -n cn-01

Continue reading LXC Containers

Docker Networking – CoreOS Flannel

This blog is part of my ongoing series on Docker containers. In this blog, I will cover Flannel which is a CoreOS networking solution to connect containers across multiple hosts. Please refer to my first blog on CoreOS to understand CoreOS basics as well as how to setup CoreOS cluster.

Flannel Overview:

Flannel creates an Overlay network using either udp or vxlan encapsulation. Flannel links itself to the Docker bridge to which the containers are attached and creates the overlay. Following picture illustrates this.

coreos3

Demo:

Lets create 3 containers in 3 different CoreOS hosts that are part of same cluster in 11.0.0.0/16 subnet, connect them using Flannel and try to ping them. Create the 3 node cluster using the procedure in my previous CoreOS blog.

Continue reading Docker Networking – CoreOS Flannel

CoreOS overview

This blog is part of my ongoing series on Docker containers. In this blog, I will cover basics of CoreOS and some hands-on stuff I tried with CoreOS. As mentioned in my other blog on Docker  orchestration, CoreOS falls in the category of specialized Linux distributions that can host Containers and are suitable for massive server deployments.

CoreOS is a Linux distribution with very minimal services installed and the primary goal is to have a scalable clustering system. Following 2 pictures from CoreOS shows the details from both single host perspective as well as Cluster perspective.

Continue reading CoreOS overview

Docker Networking – Weave

This blog is part of my ongoing series on Docker containers. Weaveworks is developing a Docker Networking solution to connect Containers. I recently played around with their solution and in this blog, I will capture some of my thoughts.

Following are some internals on their implementation as I understood:

  • Weave creates a Weave bridge as well as a Weave router in the host machine.
  • Weave router establishes both tcp and udp connection across hosts to other Weave routers. TCP connection is used for discovery and protocol related exchange. UDP is used for data encapsulation. Encryption can be done if needed.
  • The Weave bridge is configured to sniff the packets that needs to be sent across hosts and redirect to the Weave router. For local switching, weave router is not used.

Following is a picture of the data path between 2 containers on 2 different hosts.

Continue reading Docker Networking – Weave

Docker Networking – Socketplane

This blog is part of my ongoing series on Docker containers. In my previous blogs 1 and 2, I covered basics of Docker Networking and also covered some of the limitations with the current solutions. In the next few blogs, I will cover Docker Networking solutions from Socketplane, Weaveworks, CoreOS. Socketplane is developing a Docker networking solution that links containers across multiple hosts. They released a technology preview recently of their initial implementation. In this blog, I will cover some of my thoughts related to trying out the their initial solution.

Following are some internals of the implementation as I understood:

  • Openvswitch is used as the bridge where container interfaces are connected.
  • Multicast DNS is used to discover other cluster members. As of now, multicast is a requirement in Underlay network.
  • Consul is used as a service discovery mechanism where the key, data values for the whole cluster is stored. When socketplane agent is started, it prompts to choose the primary and secondary cluster members.
  • vxlan is used as a tunneling mechanism for data encapsulation between hosts.

Following is a picture of the data path between 2 containers on 2 different hosts.

Continue reading Docker Networking – Socketplane

Docker Orchestration

This blog is part of my ongoing series on Docker containers. Orchestrating Containers is a pretty complex task and there is a lot of work ongoing to solve this particular problem. There are big companies, startups as well as Opensource projects involved with this work. There are many different technologies and projects ongoing that got me really confused when I started looking at this. In this blog, I have tried to break down the Docker orchestration problem into smaller pieces and have tried to map different existing/developing solutions into the smaller pieces. Considering that the technologies are evolving and that my knowledge in this area is limited, this blog might need updates and corrections as we move forward. Also, I might have missed few technologies as well as companies..

Problem statement:

Docker does a great job in packaging and transporting single containers. Following are specific problems we need to address:

  • Distributed Applications split between multiple containers.
  • Manage a large number of containers both in terms of allocating the containers to the cluster of hosts as well as handling container failures.

Orchestration blocks:

Continue reading Docker Orchestration

Docker Networking – Part2

This blog is part of my Docker series. This is a continuation from my previous blog on Docker Networking. In this blog, I will cover current Docker networking limitations, Pipework overview and a sample Docker application where I have linked containers in 2 different hosts.

There are 4 networking options that Docker provides when creating containers:

  1. –net=bridge. This is the default option that Docker provides where containers connect to the linux “docker” bridge.
  2. –net=host. In this option, there is no new network namespace created for the container and the container shares the same network namespace as host machine.
  3. –net=(container name or id). In this option, the new container shares the same network namespace as the specified container in the ‘net’ option. (Example:  “sudo docker run -ti –name=ubuntu2 –net=container:ubuntu1 ubuntu:14.04 /bin/bash”. Here, ubuntu2 container shares same network namespace as ubuntu1 container)
  4. –net=none. In this option, container does not get allocated a new network namespace. Only the loopback interface is created in this case. This option is useful in scenarios where we want to create our own networking options for the container.

Currently, Native Docker networking has the following limitations.

Continue reading Docker Networking – Part2

Docker Networking – Part1

This blog is part of my Docker series. In this blog, I will cover basics of Docker Networking that covers the ingress and egress connectivity for containers and how containers are linked together. I will cover advanced networking topics in next blog.

When docker service is started, a linux bridge is created on the host machine. The interfaces on the containers talk to the bridge and the bridge proxies to external world. Multiple containers on the same host can talk to each other through the linux bridge.

Following is the bridge created on host machine seen through ifconfig. The bridge gets allocated IP address 172.17.42.1.

docker0   Link encap:Ethernet  HWaddr 56:84:7a:fe:97:99  
          inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Now, lets create 2 containers:

Continue reading Docker Networking – Part1

Docker hands-on with boot2docker

This blog is part of my Docker series. In my previous blog, I covered installation and usage of Docker on Ubuntu Linux. I had installed Ubuntu Linux as a VM inside Virtualbox running in Windows 7. For folks who are interested in trying Docker using a simpler approach on Windows or Mac, boot2docker is an option.

boot2docker:

Docker is supported currently only on Linux kernel. boot2docker is a tiny distribution of Linux on top of which Docker is installed. Installing boot2docker on Windows would allow us to run Docker on Windows machine. Actually boot2docker runs as a VM on top of Virtualbox. During installation, an option is given to install Virtualbox along with boot2docker. If you have Virtualbox already installed, you can select installation of only boot2docker, otherwise you can install both together. boot2docker for Windows can be installed from here. It does not make much sense to run boot2docker in Linux since Docker is supported natively in Linux and there will be performance impact of running boot2docker in a VM under Linux. Infact, I did not seen an option to install boot2docker under Linux.

Continue reading Docker hands-on with boot2docker

Docker Hands-on

This blog is part of my Docker series. In this blog, I will cover some Hands-on stuff that I tried with Docker.

I installed Docker in my Ubuntu 12.04 that is running on Virtualbox using the procedure here. I have also installed Docker in Ubuntu 14.04 using the procedure here. To install a specific version of Docker and not the latest, use the procedure here.

Following is the docker version that got installed. I have seen recently that 1.4.1 is the default version that gets installed.

$ docker --version
Docker version 1.3.1, build 4e9bbfa
$ sudo docker version
Client version: 1.3.1
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 4e9bbfa
OS/Arch (client): linux/amd64
Server version: 1.3.1
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 4e9bbfa

To test the basic container functionality, try the following:

$ sudo docker run -t -i ubuntu:14.04 /bin/bash
root@ce1b5eff4e71:/#

Continue reading Docker Hands-on