Docker 1.13 version got released last week. Some of the significant new features include Compose support to deploy Swarm mode services, supporting backward compatibility between Docker client and server versions, Docker system commands to manage Docker host and restructured Docker CLI. In addition to these major features, Docker introduced a bunch of experimental features in 1.13 release. In every release, Docker introduces few new Experimental features. These are features that are not yet ready for production purposes. Docker puts out these features in experimental mode so that it can collect feedback from its users and make modifications when the feature gets officially released in the next set of releases. In this blog, I will cover the experimental features introduced in Docker 1.13.
Following are the regular features introduced in Docker 1.13:
- Deploying Docker stack on Swarm cluster with Docker compose.
- Docker cli with Docker daemon backward compatibility. This allows newer Docker CLI to talk to older Docker daemons.
- Docker cli new options like “docker container”, “docker image” to collect related commands in docker sub-keyword.
- Docker system details using “docker system” – This helps in maintaining Docker host for cleanup and to get Container usage details
- Docker secret management
- docker build with compress option for slow connections
Following are the 5 features introduced in experimental mode in Docker 1.13:
- Experimental daemon flag to enable experimental features instead of having separate experimental build.
- Docker service logs command to view logs for a Docker service. This is needed in Swarm mode.
- Option to squash image layers to the base image after successful builds.
- Checkpoint and restore support for Containers.
- Metrics (Prometheus) output for basic container, image, and daemon operations.
Experimental Daemon flag
Docker released experimental features prior to 1.13 release as well. In earlier release, users needed to download a new Docker image to try out experimental features. To avoid this unnecessary overhead of having different images, Docker introduced a experimental flag or option to Docker daemon so that users can start the Docker daemon with or without experimental features. With Docker 1.13 release, Docker experimental flag is in experimental mode.
By default, experimental flag is turned off. To see the experimental flag, check Docker version.
Continue reading Docker 1.13 Experimental features
Public clouds have grown tremendously over the last few years and there are very few companies who do not use public cloud at this point. Even traditional enterprises with in-house data centers have some presence in the public cloud. I was looking at Amazon’s re:Invent conference details and I was amazed by the number of new services and enhancements that were announced this year. It is very difficult for private clouds to keep up in pace with the new features of public cloud. There is no doubt that public clouds will overtake private clouds in the long term. Private clouds still have a wide deployment and there will be enough use cases for quite some time to deploy private cloud. The use cases includes regulated industries, compute needed in remote locations not having access to public cloud and some specialized requirements that public clouds cannot meet. For some enterprises, private cloud would make more sense from a costing perspective. Having hybrid cloud option is a safe bet for most companies as it provides the best of both worlds. I saw 2 recent announcements in hybrid cloud that captured my attention. One is Azure stack that allows running Azure stack in private cloud. Another is VMWare cloud on AWS that allows running entire VMware stack in AWS public cloud. I see these two services as 2 ends of the hybrid cloud spectrum. In 1 case, public cloud infrastructure software is made to run on private cloud(Azure stack) and in another case, private cloud infrastructure software is made to run on public cloud(Vmware cloud on AWS). In this blog, I have tried to capture more details on these 2 services.
There are predominantly 2 options currently to run Private cloud. 1 option is to use vendor based cloud management software along with hardware from same vendor.
Continue reading Hybrid cloud recent solutions from Microsoft and VMWare – 2 different ends of the hybrid cloud spectrum
For folks who want to get started with Docker, there is the initial hurdle of installing Docker. Even though Docker has made it extremely simple to install Docker on different OS like Linux, Windows and Mac, the installation step prevents folks from getting started with Docker. With Play with Docker, that problem also goes away. Play with Docker provides a web based interface to create multiple Docker hosts and be able to run Containers. This project is started by Docker captain Marcos Nils and is an open source project. Users can run regular containers or build Swarm cluster between the Docker hosts and create container services on the Swarm cluster. The application can also be installed in the local machine. This project got me interested in trying to understand the internals of the Docker host used within the application. I understood that Docker hosts are implemented as Docker in Docker(Dind) containers. In this blog, I have tried to cover some details on Dind and Play with Docker.
Docker in Docker(Dind)
Docker in Docker(Dind) allows Docker engine to run as a Container inside Docker. This link is the official repository for Dind. When there is a new Docker version released, corresponding Dind version also gets released. This link from Jerome is an excellent reference on Docker in Docker that explains issues with Dind, cases where Dind can be used and cases where Dind should not be used.
Following are the two primary scenarios where Dind can be needed:
Continue reading Docker in Docker and play-with-docker
This link has the slides that I presented as part of lightning talk at Devops Days India, 2016. In the slides, I have tried to capture how automation in networking area is evolving. I attended first day of the conference and it had a pretty decent collection of talks in Devops area.
This blog is a continuation of my previous blog on Vault. In the first blog, I have covered overview of Vault. In this blog, I will cover some Vault use cases that I tried out.
Install and start Vault
I have used Vault 0.6 version for the examples here. Vault can be used either in development or production mode. In development mode, Vault is unsealed by default and secrets are stored only in memory. Vault in production mode needs manual unsealing and supports backends like Consul, S3.
Start Vault server:
Following command starts Vault server in development mode. We need to note down the root key that will be used later.
Continue reading Vault – Use cases
I have always loved Hashicorp’s Devops and cloud tools. I have used Vagrant, Consul, Terraform, Packer and Atlas before and I have written about few of them in my previous blogs. Vault is Hashicorp’s tool to manage secrets securely in a central location. Secret could be database credentials, AWS access keys, Consul api key, ssh private keys etc. It is necessary for secrets to be managed centrally and having strict control and audit policies. By having a separate tool to manage secrets, application developer don’t need to worry about security internals and leave it to Vault to manage secrets. In this blog, I will cover Vault overview and internals and in the next blog, I will cover some use cases that I tried out.
Vault uses the following principles:
Continue reading Vault Overview
In this blog, I will cover 5 different options to deploy Docker Containers in AWS infrastructure. There are pros and cons of each option and the goal in this blog is not to suggest that some options are better than others, but to highlight the suitable option for a particular use case. I have taken a sample multi-container application and deployed in all the 5 different models to illustrate this. Following are the 5 options/models discussed in this blog:
- Docker Machine for AWS
- Docker for AWS
- Docker cloud for AWS
- Docker Datacenter for AWS
- AWS ECS
I have separate blog for each of the above deployment options which are linked to this blog.
Following is the sample application used in this blog:
Continue reading Docker for AWS – Deployment options