I am pleased to announce v1.6 of PiCluster. In this release there are a few usability bugs fixed and a new feature that allows you to change the host of a running container. Having the ability to easily change where a container is running is a standard and crucial feature to expect from a container management platform. I am glad that it is finally here and let’s explore how it works!
I am pleased to announce the new version of PiCluster. In this release, users can connect to a host running an rsyslog server and the PiCluster agent to view the log drain in the PiCluster web console and run searches. This combined integration provides a single pane of glass to monitor physical hosts and Docker containers easily. Let’s take a look on how to enable this functionality.
Most people will say that 2016 was a terrible year and can’t wait for 2017. I agree that 2016 was not perfect for many people but it was a great year for linux-toys. I made this blog with the goal to influence people and drive that creative spark that we all have inside. In this blog post I will go over the website statistics and discuss a few of the blog entries that I thought were most influential for the year.
I was always fascinated with distributed filesystems and wanted to learn more about Gluster since it is becoming more popular in larger open-source projects. Since I have a few Raspberry Pi’s, I thought that now is the best time to learn. This blog post will explain how to run Gluster on a two-node Raspberry Pi cluster from a Docker container.
- Two Raspberry Pi’s (rpi-1 and rpi-2)
- Running a Gluster image from a local Docker registry
- Hostnames are resolvable in /etc/hosts on both Pi’s
- Docker 1.12.x installed
I recently started to check out Kubernetes and wanted to share with everyone how I got WordPress running on it as a three-tier application. I made the decision to learn Kubernetes because Docker Swarm was not working well for me. To start, I downloaded and installed MiniKube on my laptop.
I then created three Docker images and pushed them to my Docker Hub registry:
If you have been keeping up with Docker lately, you may have come across my blog post about the sad state of Docker. In this post, I go over how the 1.12 release appeared interesting from all the marketing announcements and the constant copying and pasting of the same Docker content into blogs over the world. However, many others and I expressed our opinions on Hacker News on how Docker failed to deliver a quality product and how they failed to create a quality release. The New Stack then summarized all of the weekend discussions going on in a new blog post and discussed that a fork of Docker may arise. Is a fork really the best answer? Let’s take a look.
The nice thing about open source software is that anyone can take the software and modify it as needed or even create their own version of the software for redistribution. Software repositories like GitHub make it really easy for developers to fork a project and begin making their own changes and improvements. A recent example was the fork of OwnCloud into NextCloud. My problem with forking is that it leads to fragmentation. I personally like one or two ways of doing something well versus many different ways to partially achieve the same goal.
The container space is already starting to grow rapidly in terms of building and orchestration. The biggest container format is of course Docker and they have Swarm for their container orchestration. CoreOS also has their own container runtime called Rocket which is starting to gain traction and uses Kubernetes for orchestration. There are many other companies sprouting up in the container management area with their own unique solutions. However, Kubernetes appears to be coming the standard orchestration layer that many products use now. To help standardize containers, the Open Container Initiative (OCI) was formed to help define how containers work.
The OCI was created by members of CoreOS, Red Hat, Docker, and a few others on June 22, 2015 and gained support from companies like Apcera, Google, Apprenda, Amazon, and many more. Collaboration between companies for the greater good is terrific and we need more of this. Docker made strides to make an official OCI compliant version in their v1.11 release. Progress is being made to better standardize in this space but it takes time to achieve. Instead of forking Docker, the community should continue to raise their concerns in a nice manner and wait a little bit longer for change to happen.
Creating more fragmentation will be counterproductive because the attention of the people will be split amongst projects. How will companies new to containers and microservices ever learn to adopt this great new way of doing things if they can never decide on what to use? Anyone can fork Docker but we need to ask ourselves if another container solution is really needed when we have many to choose from already. If the answer is yes, we must ask ourselves who will maintain it? How long can this fork last? How much time will be wasted? Do the forkers have enough resources to make a quality project? How will they make their product secure and address vulnerabilities?
How about instead we stay positive and keep containing?
I have always been a big fan of Docker. This is very visible if you regularly read this blog. However, I am very disappointed lately how Docker handled the 1.12 release. I like to think of version 1.12 as a great proof of concept that should not have received the amount of attention that it already received. Let’s dive deep into what I found wrong.
First, I do not think a company should market and promote exciting new features that have not been tested well. Every time Docker makes an announcement, the news spreads like a virus to blogs and news sites all over the globe. Tech blogs will basically copy and paste the exact same procedure that Docker discussed into a new blog post as if they were creating original content. This cycle repeats over and over again and becomes annoying because I am seeing the same story a million times. What I hate most about these recent redundant articles is that the features do not work as well as what is written about them.
I was really excited hearing about the new Swarm mode feature and wanted it to work as described because this means that one day I can easily make a Swarm cluster with my four Raspberry Pi’s and have container orchestration, load balancing, automatic failover, multi-host networking, and mesh networking features without any effort. Swarm in v1.12 is very easy to setup versus the predecessor and I wanted to put it in production at home (homeduction). To test Swarm, I setup a few virtual machines using docker-machine on my laptop and went through the Swarm creation process and then began to run into issues when deploying my applications.
An important feature to have in a Swarm cluster is multi-host networking for containers. This allows containers to talk to each other on a virtual network across many hosts running the Docker engine. Multi-host networking is important for containers to communicate with each other such as web application connecting to another container with MySQL. The problem I faced is that none of my containers could communicate across hosts. When it did work sometimes, the mesh networking would not route traffic properly to the host running my container. This means none of my applications worked properly. I went to the Docker forums and many people shared my pain.
It is not wise to explode the Internet and conventions with marketing material about exciting new features that do not work as presented. There are still many bugs in Swarm that need to be fixed before releasing to the general public to have them beta test for you. What is the rush to release? Will it hurt that much to wait a few more weeks or months to do it right and have the product properly working and tested? Yes, we all know Docker is awesome and is trying to play catch up with competitors such as Apcera and Kubernetes, but please take it slow and make Docker great again!
Tweaked paragraphs to make it more clear that my testing was not done on the Raspberry Pi and done with docker-machine on a laptop.
SSH is the Swiss Amy Knife of system administration and provides the easiest way to manage a system remotely. When running containers, there is typically someway to connect to a container’s shell from a client that communicates through an API like Docker or by using an SSH solution which is how Apcera does it. Some applications that run in containers may require SSH access to communicate with other containers or services. For example, Hadoop is a popular cluster application that uses a distributed filesystem spread across many nodes and communicates with each other via SSH. Let’s take a look on how to setup an SSH server running inside a capsule (a minimal OS container) on the Apcera Platform.
I like to take a break from my usual Docker blog posts and discuss the Apcera Cloud Platform. The Apcera Cloud Platform runs containerized workloads such as Docker images or applications from source code in a clustered environment. For the past several weeks, I have been playing with Docker Swarm and spent time researching how to put this blog into production on it. Life has been very difficult for this migration because Swarm requires a lot of handholding and lacks the failover automation that I need. I began researching the Apcera Platform and tried out the community edition that users can try for free. The areas that I focused on for my needs regard ease of use and workload portability.
This is a followup on how to use Docker after building a Swarm cluster. I think it is important for people to understand the different ways to create containers and choose the best way for their needs.This blog post will explain docker-compose, docker engine, and how to do persistent storage.