The last week’s I was busy to get two pull requests merged for docker-machine. Here I will tell you the story which experiences I gained and why it was worth the work. I write this during our journey and flights to Docker Con EU 2017, because I am in a good mood and exited to be there soon and it’s another way to support the community too.
In the last summer we started to use Gitlab more extensively because we get used to the integrated CI/CD pipelines in combination with Docker. For this setup we installed a appropriate number of Gitlab-runner too. After a month or two we recognized that we were facing some build peaks during the day and therefore we decided to use our Microsoft Azure connection to the Cloud to setup a Gitlab-autoscale runner.
Docker Con EU 17 break on
Yes, I really wanted to write this blog post during the Docker Con EU 17, but there was too much of fun and information there! It was really exciting and therefore this post was delayed until now … 🙂 . But happily you might find a review of our Docker Con EU 17 journey and impressions here soon!
Docker Con EU 17 break off
This was the point where the problems started. The first thing I mentioned was, that I was not able to reach the Azure VM which is created when the Gitlab-autoscale runner starts. To figure out what was happening there, I started the docker-machine binary manually and tried to create a Azure VM manually, because the Gitlab-autoscale runner uses docker-machine in the background.
After a view tries and some debugging runs of docker-machine I realized, that the network routing table which is used to establish the side-by-side connection to the Azure cloud, gets deleted upon the creation of an VM in the Azure cloud. That is really bad because it does not only interrupt the connection to the freshly created machine, it causes that the whole subnet is not reachable anymore. If there are other VM’s existing in the same subnet, they are also not reachable anymore. Ouch.
Open Source is great! Why? You can look at the code! And yes, even if you are not a full time programmer – DO IT! I am an Ops guy, I was able to do this to! Ok, to be fair, we are often forced to solve problems on our own, especially if your main work is to work with Linux, you learn that you can do a lot of tasks in a more fashion manner if you just write a script, or two… (= to code).
So yes, after some digging, I found the place where to change the code and I changed it for on-prem usage and tests. After some time I thought that it will be useful to others and so I filed an issue and I also put in a corresponding pull request.
I had already learned to use Git, but through this pull request I learned a lot more! Thanks to Joffrey who was very kind to support me and after additional work, I was able to get my pull request merged. No more deleted routing table entries!
But the story does not end here 🙂 – during our on-prem tests we also recognized that the Azure storage accounts of delete VM’s are not deleted too! After some days of running the Gitlab-autoscale runner, we messed up our Azure ressource group with lots of orphaned storage accounts. Not nice 😉
I guess you know what is coming now? Correct, filing an issue. But wait! Always take a look if there is already a filed issue for a problem! An yes, there was one already filed. So once more I changed the code for on-prem use, tested it and opened a pull request. And again Joffrey was so kind to help me with my questions. After I while, this pull request was merged too and hopefully it helps someone out there.
Yes you can help others! There are plenty of things you can do to the community, not only coding. You can also support others by filing issues or write documentation about projects you use (in no case limited to Docker). There was also a great talk at Docker Con EU 17 held by Ashley McNamara on this topic. To quote one of her slides and to end this blog post:
We are a Community
of coders. But if
all we do is code
then we've lost the community.