I have been deploying containers and creating applications on Kubernetes for the better part of the last couple of years. I should have written a lot more about the journey because there is so much to learn (by doing quite a few mistakes).
I should have learned by now that any of these great new ways of doing things that will simplify the delivery of applications is a journey where you are going to re-learn how to do what you have always been doing. The same “problems” exist in creating an application no matter the framework or language.
The new tool is going to address pain points from the last best framework ever and it will be very attractive to use the new one. The fun is in solving all the other problems that still exist and have not necessarily been addressed as well as the pain points that attracted you to it.
I had to re-learn so much about networking with Kubernetes because your micro-services all need to communicate with each other.
I had to learn a lot about Kafka because it is our messaging queue. Please don’t tell them that is what it is. It is so much more.
I had to learn about service mesh and got to the points of many memes about this one.
We had to learn so much about so many different applications and infrastructure pieces that the promise of delivering faster is not as true as we would have liked. Don’t get me wrong, I love learning but I hate over-promising and finding myself in a bad position.
The journey is far from done and I have an awesome team that is helping me and I hope that I am helping them along the way as well.
May the learning continue…
For some reason, I expected the installation was going to be a bit more complicated on MacOS. It is actually quite easy.
I downloaded the latest MacOS binaries from https://jdk.java.net/11/
I clicked the .tar.gz that I got to decompress it in the jdk-11.0.1.jdk directory.
I moved it to the directory for MacOS to pickup the new version:
sudo mv jdk-11.0.1.jdk /Library/Java/JavaVirtualMachines/
I was done with these steps.
You can test by running:
to confirm that you see the new version:
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
I have heard of serverless from so many vendors by now that it feels more about marketing than anything else. I have a bad gut reaction when I feel that there is more marketing than substance about any technology.
I decided to look at Now from Zeit just out of curiosity and I think that I should look at it a bit more since it looks quite easy.
On the Zeit site, you can see the free offering that they have and it allows you to get your feet wet and be more curious about what you can do.
The Now CLI also looks like a very simple way to perform everything you need.
I also like the immutability approach that they have that allows you to move quickly from one deployed version to another.
It is definitely worth more time to see what I could do with this platform.
Nice article about some framework that we should all learn and as much as I know a few this list of classics certainly has a few that I should learn before the end of the year.
Which one are you learning?
It is always a good reminder when you read this type of article. Producing good code that can be easily maintained is very important.
- S: Single Responsibility Principle
- O: Open-Closed Principle
- L: Liskov Substitution Principle
- I: Interface Segregation Principle
- D: Dependency Inversion Principle
This presentation has a series of coding habits that can cause problems if applied blindly:
I have seen many of these bad habits and I have quite often used them because they are my habits as well. I am unsure how we can lose these habits easily because some are embedded in the team and getting the entire team to change is not easy.
I like that he explains the fact that some of these start small and grow to be a problem. You have to be very attentive and make sure you don’t start on the wrong path.
This presentation from Google Next 2018 is very good to understand how to use Vault in Kubernetes:
The details of the demos are available on GitHub:
The details shown on how to run Vault in Kubernetes and how to get application in Kubernetes to use Vault are very good and help understand how we can deploy our own.
I have been getting an error every time I try to install a new homebrew package and I found a quick and easy solution to it.
The problem looks like this:
user1$ brew install kubernetes-helm
Warning: git 2.15.1 is already installed
Error: Git must be installed and in your PATH!
Error: The following formula:
cannot be installed as a binary package and must be built from source.
Install the Command Line Tools:
Git is available on my system without issues so I was puzzled about this “invalid” error.
I found that if you set this variable:
It would allow brew to update and then install new packages without an issue.
Very simple workaround.
Some applications started to require a newer version of the bash shell on my Mac. Apple ships a version of 3.2 but Bash is up to version 4.4 and Apple is not able to ship a newer version because Bash 4 uses a GPLv3 license.
I found this quick solution where you use homebrew to install the latest Bash version and changing the terminal configuration to use this new shell.
If you don’t have homebrew it is quite easy with this one command:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then you simply have to execute:
brew install bash
Changing the terminal configuration is easy because it is on te first tab of the preferences. Where it says “Shells open with” change from “Default login shell” to “Command (complete path)” and enter this string:
Obviously your version may vary depending on what is the latest one available.
We have been seeing this intermittently in our different kubernetes clusters, kube-dns is not resolving some hosts names and it is causing failures with some batch jobs or containers that are dependent on others to start.
We know that the networking is working because we are able to reach services or containers with IPs. So I had to stop blaming flannel.
Our Linux architect noticed that br_netfilter module was loaded but not the xt_physdev one.
On each node he fixed it with these commands (first and last ones to verify the loaded modules and second to load the missing module):
[root@server ~]# lsmod | grep br_
br_netfilter 22209 0
bridge 136173 1 br_netfilter
[root@server ~]# modprobe xt_physdev
[root@server ~]# lsmod | grep br_
br_netfilter 22209 1 xt_physdev
bridge 136173 1 br_netfilter
Everything started to work perfectly after that little fix.