Greetings to you dear reader!
I am Murathan, one of the DevOps Talks organizers. Today, I will be your narrator to tell you the story of how our 7th DevOps Talk on the 21st of December went.
Here we are once again! While we are getting into the Christmas spirit and snow is falling with a magical view outside, Uldis the Santa is starting our 7th DevOps Talk by introducing who we are. We are Latvia DevOps community made by 5 different companies. We are part of Techies of Baltics movement! We organize DevOps Talk events monthly. We love DevOps and we talk about everything. Because DevOps is about everything!
Our special guest, today, is Aleksandrs Zolotarjovs from Accenture Baltics. In his free time, Aleksandrs likes to play with reindeers and help Santa. Tonight, he will be presenting and showing us “Creating Services Using Kubernetes”. Behold and watch him doing his magic!
You can also watch the presentation part:
Ups! Even though an unfortunate problem with sharing screen showed up just from the very first minute; the Great Aleksandrs has solved it quickly and returned! While Aleksandrs is taking the stage we are wishing Uldis to have a nice dinner! The presentation will consist of two parts. First the theory part and then the demonstration part. Aleksandrs is starting his presentation by getting to know his audience, who are completely new to Linux, servers and services, virtual machine concept, Docker and containers.
A brief history of how containerization emerged. It all started in 1979, with Unix chroot. It’s released to test the installation and building of the system. In 2006, one of the Google engineers created cgroups. It was named as Process Container but then renamed as cgroups which was designed to isolate specific computer resources (such as CPU, memory, disk) for the application. And then there were namespaces by Redhat and LXC buy IBM.
But why these all are important? Because, starting from 2013, these components are used in Docker Engine. And in 2014, while there is a need for orchestrating different multiple containers, Google has launched Kubernetes that the development was influenced by Google’s Borg system.
Kubernetes consist of nodes and a control plane. You configure some files and push these into the control machine which is like a brain of Kubernetes. Then it configures nodes to make and maintain the desired state. The idea of Kubernetes is to continue maintaining this desired state. Once you configure the brain to do something, in case of a failure of a node, the brain will try to recreate the entire configuration to make sure it is consistent.
Now Aleksandrs will be demonstrating to us the deployment of a web service with Kubernetes. Who would like to go with this lab individually can check Katacoda and start enjoying working with Kubernetes. It allows you to run a virtual environment to test Docker/Kubernetes and even Linux commands.
Tatjana is a DevOps intern who is with us tonight to gain more experience on Kubernetes! After the event, she thinks “It was very handy for a newbie :)”.
As Aleksandrs is finishing the informative lab session with cool hints, Arturs is getting on the stage again! He feels good but cold! 🙁 – Yeah, I get you Arturs, feeling the same here.
It is time now to move on to the second part, the actual DevOps Talk. Arturs is beginning by explaining the rules. Yes, we have rules! I will quote Uldis from our 6th DevOps Talk once more, “Rules are meant to protect us!”:
- When adding and discussing topics, remember to be respectful and judgement-free, and remember about NDA’s- there are people from other companies as well
- You do not have to talk- you can also just listen, but those who want to actively engage- put your name on the board
- Every active participant will have one minute to express his opinion on the subject
- Each participant gets one vote
This is the part you can come up with a topic you would like to discuss, about anything. Just remember, you need to talk if you are writing down a topic! Well of course it is not an obligation but come on, would be nice for you to talk. Arturs is starting the countdown and you have 3 minutes 3 seconds to write down your topic. So go on, don’t be shy and put your ideas to discuss!
While our guests are thinking, Arturs is reminding us that today is also a special day. It is the winter solstice. Some people celebrate it, I guess. And the time is up! Before we start voting, everyone will have 1 minute to explain their topics briefly.
The first topic is coming from dear Marcis, “How to deal with increasing complexity”. Imagine the case, there is already an existing platform with some deployments with Ansible, Jenkins, Docker etc. Then Kubernetes comes. With CI/CD processes and everything, there will be new services added. There are many services and systems that are working. Marcis would like to hear the ideas from others, in such conditions, how to get the whole picture of this?
Next, we have Aleksandrs who has 3 topics. “Building own Linux distribution”, “chroot/cgroups/namespaces” and “Containers from scratch”. As he has 3 topics, now he has 3 minutes to tell us more detail about his topics. He thinks that building Linux from scratch is an interesting topic. He is sharing with us links to two useful resources on this, for the ones who may be interested in that. (One–Two). He is sharing another link for a resource on containers from scratch about how to use chroot/cgroups/namespaces. It is a good one to get a better understanding of how containers actually work and what is behind them.
The next 2 topics are coming from Kristians. The first is “Docker Swarm – Should I try to use it for new projects (Or what are the other options for your projects)”. He’d like to hear some opinions from others on how to deal with complexity. There are Docker Swarm, Kubernetes and alternatives. Which one to use when?
And the second one is “K8s clusters: from scratch, turn-key (e.g RKE) vs cloud whenever possible”. In the case of the need, which is the best option? Building the Kubernetes cluster from scratch, perhaps using Rancher or maybe hiring someone to manage the cluster. He believes probably there are different advantages and also shortages of each. So he would like to hear about others’ experiences.
The last topic is from Mustafa, “What methods are you using to be aware of security vulnerabilities”. We are using a lot of different tools and packages. Mustafa is wondering how people are proactively following and being aware of the security vulnerabilities.
We have quite interesting topics. So now is the time for voting. 1 minute and, only 1 vote! Those who didn’t have a topic still can join the discussion. Heta and Anton are willing to be active participants. As the time is up, we have a winner, Marcis!
How to deal with increasing complexity?
Marcis says that as a DevOps/SRE it is still hard to wrap your hand around all the new tooling and the new concepts coming in. So maybe someone has some practical tips to share?
“Tough question!” says Aleksandrs. It depends on what is exactly meant by the “complexity”. Is it the complexity in life generally or is it the complexity of the tools? – Marcis adds here that for him the main complexity is how to integrate everything together and unify the pipeline. Aleksandrs tells that it is impossible to keep up with the speed of the new tools incoming and new approaches happening. So to deal with that, there should be a limit set. It requires a lot of time and it is not possible to learn everything. You cannot choose everything. So yes, there is complexity but there is also diversity.
Kristians thinks maybe sometimes it is better to look at what we actually need. Decide what we might need for the near future and optimize for that.
Mustafa agrees with Aleksandrs, it is a tough topic indeed. It is almost impossible to cut off the complexity. A new tool is coming up almost every day. So maybe it is better to strict yourself with several tools and somehow limit the usage.
In Anton’s opinion, it is inevitable not to get more tools. -I can’t be the only one who enters the Matrix with this word- The best is to analyze and understand what tools suit you the best and then make the choice. As much as possible, maybe the less is better.
For Heta, it is all about structuring it. It works in a reverse engineering way. In a general sense, she puts it in a structure and then goes to the micro-level. And this is the way of finding the complexity to resolve it.
Marcis adds that if you have more than one team in your company, it is not possible to stick to only one tool and it is inevitable that there will be more tools. So it is about how to structure your exploration of the new tools.
Albert is thinking that people pretend to have a solution but actually, no one has it. Some business people manage their complexity very well, they just make it your problem. It also depends on what position you are looking at it from. But the thing is, there is no single solution to this.
We still have 20 minutes left. Therefore, after a quick voting session, we are moving to the second topic of the day. Our next winner is Mustafa!
What methods are you using to be aware of security vulnerabilities?
Mustafa, at the moment, is using some resources and newsletters to check on that. But he believes he needs some alarm system for this purpose. Maybe a tool would be nice that sends alarms about some specified tools/plugins.
For Anton, SonarQube is a good platform to set up automatic checks for the code, test and run analyzes. It is better to have a separate security team that can track all the things.
I think Arturs liked the idea of classical outsourcing this to someone to make it someone else’s problem. 😀
Kristians is sharing some useful resources for scanning nodes, scanning containers and scanning of libraries. We need to consider what we can do from the tools perspective. And also perhaps consider using fewer libraries.
What our active participant Kristians thinks about our Talk: “Pretty good format – talking among the participants and hearing what everyone thinks, what their experiences have been like. It was a little bit short but was a fun experience!”
Aleksandrs is pointing out the fact that is; as more tools are coming up, new vulnerabilities are coming up as well. We need to keep up with those, need to read articles and CVEs which is very crucial. SonarQube is also a good option for automating.
For Marcis, it is relying on the security teams to discover and report the vulnerabilities. He is keeping up-to-date with the newsletters.
Uldis tries to make a point with an analogy – it is like you are in a street and you see a green and red light blinking. In IT, you never see the green light. It doesn’t matter what you are deploying there, it always is risky. How do you know the language that you are using is not hacked when you write your custom code on top of it?
Mustafa seems to like the idea of outsourcing and making it someone else’s problem. 😀
We have still some minutes left! So why not move to the third topic to discuss. Kristians wins the cup this time.
Kubernetes Clusters from scratch
Kristians is wondering that as there are a lot of options, what options can be good to use when?
Marcis, for learning purposes, likes to use some Ansible playbooks for provisioning.
Aleksandrs says what important is at first is that what is the aim and what you are trying to accomplish. To build up a highly reliable service, then maybe the cloud is the best option. If the purpose is to learn something or make it highly customizable, then maybe better to go from scratch. If you want to build a cluster in your home just to play around, then Minikube could be your solution.
Mustafa has experience working with dedicated servers. He really likes going from scratch, building with no tools and using pure K8s. Yes, it is the hard way but also a fun way.
Anton points out that it is dependent on the task. If you want a customizable solution then better to go from scratch. But if you need a quick setup, then cloud providers’ services are the best option.
Nora found us on meetup and shared her thoughts: “Liked the presentation by Aleksandrs as well as the discussions on security, minimizing complexity and Kubernetes.”
Thank you all, for being with us tonight to have the joy of DevOps all together. We have our next event on the 25th of January. Whether you have topics in your mind you would like to share and discuss or you want to hear about interesting discussions from others, we have an open place for you. Come and join us!
We are looking for new speakers! Do you have a topic/case you would like to present and tell about? You can contact us through the Techies of Baltics LinkedIn page or Slack channel to be our next presenter!