DevOps Loft Blog

Minimal Viable Product

2023-07-23T00:00:00+00:00

Last week I shared that I started working on a slightly different project than usual. Managing the permissions scheme for the tree of Git projects managed in the namespaces tree in Gitlab.
As Evgeny pointed out in the comments, one of the tools that might be suitable is backstage. There are of course other tools in this domain. port is one of them.
Strategically, this is definitely the right direction to go with, but on a tactical level, when the chaos reigns and the engineering work is stuck due to imprecise permissions, it is important to provide a tactical response. I call it - MVP or alternatively quick and dirty solution.
For the benefit of my project, I chose terraform as a development tool to help me code the configuration. In addition, I decided (and not for the first time) to break the deployment into very small parts. And each time deploy a small change, stop, check the pulse and only after making sure that everything is good to move on to the next step.

I have dug enough and therefore I will go to the stage of the identical questions:-
Did this post bring you new insights?
Did you learn something you didn’t know before?
Have you faced a similar challenge in a different way? in different tools?

Original Facebook post in Hebrew here

Product Discovery

2023-07-17T00:00:00+00:00

Well… I missed my own deadline. Happens. Happened. Will happen.

Last week I was busy with a new and slightly different project. Managing the permissions scheme for the tree of Git projects managed in the namespaces tree in Gitlab. On the face of it, it sounds uncomplicated. This is true until product discovery is conducted. Do you know what is it?

This is from the product domain. What is the connection between devops and product. In most if not all of the organizations I’ve encountered, and I must admit that I’ve encountered quite a few of these, the devops people receive a short and concise requirement. Characterize the solution, implement and deploy. And continue on more or less. Most of the time this is satisfactory, but sometimes we forget that there are users on the other side. Our users are the development people (not only). But they deserve a good user experience if not better. We all want to implement new features as quickly, as qualitatively, as we say. And in order for all this goodness to happen, someone has to extract the requirements and understand in depth what the users really need.
This is where the product discovery process comes in. Sit with the helpers and dig for them until you extract the maximum possible requirements. User-stories are created from the requirements and from here the road to design, implementation and deployment is already paved.

Original Facebook post in Hebrew here

Getting Help

2023-07-10T00:00:00+00:00

After opening and closing parentheses in last week’s post, I’m back on track. Not a question. Time is short and the work is plentiful. The goal is - to set up a DEV environment with a Gitlab server and also a runner running on minikube. And all this goodness using devcontainer and helm chart. In the previous post (not the one from last week. The one before it) I shared that I ran into some problem that at the time I didn’t have the solution to. And when I’m stuck, I also know how to ask for help. And the one who came to my aid is Guy Inger. His PR is still in the review stage, so if you have something to contribute, add, feedback then now is the time.

What’s more, I came to know that there is no sufficient information in the project about how to set up the DEV environment. Having the devcontainer configuration files doesn’t make it clear enough for a new contributor. So today, I will work on that too. I will improve the README and maybe I will find a volunteer who wants to do a review for me.

Original Facebook post in Hebrew here

Platform Engineering

2023-07-02T00:00:00+00:00

Pausing for a second to share a video that made a lot of sense in my mind. In recent months I hear more and more the concept of platform engineering. Intuition felt to me that this was the next thing for me. Not exactly the next but what is today and another layer. But I didn’t know how to explain to others what it meant.

So receive the ultimate, clear and simple explanation with drums and dances. A little less than 43 minutes. You don’t have to watch until the end because there is no good without trying to sell me and you something. Lest it be implied that there is anything wrong with this practice. I’m all for it.

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here

Tech Journaling

2023-06-25T00:00:00+00:00

Lately I’ve had an aha moment that this group has become my personal travel diary into the ins and outs of DevOps and Platform Engineering. I came to know that I learn a lot through the journeys of others and also from my own journey. A significant part of my time is devoted to exchanging opinions with people from the industry, colleagues and even with those who work at Red Hat but not in my organization. I highly recommend the practice. I hope that one day this group will serve not only me. There is something empowering about unpacking and receiving feedback.

Just FYI, I’m still on a quest to acquire kubernetes knowledge. The journey is going to be long and tiring. I realized that I have many holes in my education. Remember the problem I ran into in the previous chapter? (Do not answer, rhetorical question). I recalculated my route and realized that I was trying to mix a DEV environment with a PROD environment, so the problem is a problem. The runner that remains “registered” in the PROD environment pollutes my environment. The conclusion is that there is no way to mix the environments. I need a gitlab server in the DEV environment. One that is created when I deploy an environment and one that is torn down when I don’t need it. And therefore, I switched to a helm chart that knows how to deploy both the server and the runner in one operation. It turns out there is one. Maybe in the future I will split, but right now it seems like a more correct move.
This move also creates new challenges that I still can’t solve. It turns out that the domain parameter is a mandatory one. The domain is used to access the console or whatever you call it. Well… to the GitLab UI. But, I don’t have local dns when I deploy minikube inside devcontainer. And to complicate matters, browsing is done in a browser running on the host while the server runs in a container running on the host. The plot gets complicated. There is a situation where I put myself in hopeless challenges. Of course I did the obvious and addressed the general public for help. This time to the community of Gitlab users on Discord. Maybe salvation will come from there. Until then I populated the parameter with something completely random.

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here

Kubernetes - Gitlab runner

2023-06-18T00:00:00+00:00

I’m still on a journey to acquire kubernetes knowledge. The tech wealth (with light sarcasm) is significant.
I made a little progress last week. In the previous chapter I shared that I encountered a problem sharing secrets in both environments: DEV & CI. So, I just wanted to say that I got good feedback from you and others and in the end I chose to go with kustomize. I came across this technology years ago but only now the insight, why it is good, landed. What’s more, it seems to me that the kubernetes community has officially adopted this technology (which probably wasn’t the case when I first encountered it).

A short summary of what is already working in the project:

DEV environment using devcontainer and the feature
Uploading and downloading the environment using make, minikube, kustomize & helm
CI environment using GitHub Actions & GitHub Secrets

What’s more, I encountered a problem that started as soon as I transferred the Gitlab Runner Token from the values file to the secret stored in the cluster. When I download the environment, the registration of the runner is not deleted. I made quite an effort to locate the problem and even tried to fix it. But I still haven’t found a solution. And when I reach a kind of dead end, I turn to the general public, which is the community. There are two options. Either I have a problem with the configuration or it’s a bug. I believe that I will have a proper answer by the next chapter.

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here

Kubernetes - second round

2023-06-11T00:00:00+00:00

Summary of the previous chapters on the way to the destination - kubernetes:
I started with the project itself but encountered difficulties due to the architecture of my laptop- macOS M1. I tried kind which worked quite nicely and also colima. Both worked on the laptop but I was not able (in the short time I invested in them) to use them in CI. And finally, I got to minikube thanks to one recommendation from last week. I have an environment that works both locally (development environment) and there is also an environment that works in CI. And when I say local I mean the dev container environment. This was made possible because there is a feature that fit me like a charm. Oh, one more little detail… I proceeded to install gitlab ci runner using helm chart and it worked like a dream.

What’s more, I haven’t yet found the elegant way to share secrets in both environments. Right now, I’m using the values file in the DEV environment. While in the CI environment I use GitHub Secrets. Not the DRYest to say the least. A tech debt that I will close as soon as possible.

And below is the project in which I implemented the entire tech stack mentioned above.

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here

Kubernetes - initial steps

2023-06-04T00:00:00+00:00

I finally returned to Israel after a significant stay in Milan, Italy. Back to Israeli time.
Sunday at 10:00 a new post lands.
Last week I updated that I am entering the world of Kubernetes. Yes yes… the time
has come even though I have been in business for years, just not at the level
I would like to be at.
So, I made a move forward and also one backwords. I said to myself, how do one
starts with a new technology when the table is completely clean. For me the
answer is quite clear. First of all, clone the project, go through the
instructions and start a development environment.
Oh, here I failed. It turns out that the combination of macOS M1 and
Kubernetes still does not work smoothly. So, I took a step back and am trying
a new approach. I took out of the attic my old laptop. At the time it was a
bad beast. Macbook Pro based on Intel this time. I am trying. What will be
will be. What is important is to try, at most I will succeed.
In parallel, I’m also diving into kind. For those who don’t know, it’s an
abbreviation of Kubernetes in Docker. One of the lighter versions adapted to a
local development environment and CI. That’s what they say. I haven’t tried yet.

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here

Cocktail 1

2023-05-28T00:00:00+00:00

Yesterday I found out that a new chapter in the Paved Paths series was
released. I still haven’t finished going through it and getting the
information to sync in. From what I have already read, this is another
excellent episode. One that has something to take from it and apply already
today.
As a live example, the project behind devopsloft’s English blog. All the
topics on the short and improving list are already there. And so that I don’t
get confused, God forbid, I also bothered to add badges in the README to avoid
misunderstandings.
And now, with the information I have acquired in the field, I continue on and
expand the canvas. And this time it is about one of the most exciting projects
in the devops industry - kubernetes.
There is tons and tons of information about Kubernetes on the web. Since the
forest is large and scattered, you can’t see the trees. My way of getting into
things goes through my hands. That means, start from the bottom. This means,
pick up a local environment and grow from there.
Here too, the information is scattered and the road is really not paved
(or it is and I still haven’t found the beginning of the route).
I started with fork and clone and from there I continued to spin the
environment according to the instructions (and there are quite a few of them
scattered over several files).
I still haven’t succeeded. I’ll update later.

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here

Paved Paths 2

2023-05-21T00:00:00+00:00

Following on from last week’s post. The series of blog posts talks about paved paths.
I won’t tell you what it means. Read the series (which is not yet completed). The writers explain it really well and clearly.
I have been thinking with myself since I came across the topic about how it is
actually applied in the environment I work in.
It’s true, it’s still WIP (work in progress). But, I already have several
processes and technologies that I can put on the table here.
Below is my initial list:-

Static code analysis - pre-commit. I make sure every project I work on including open source projects, are onboarded.
There are several areas in the development lifecycle it can be applied:
- Locally, by IDE extensions which warn/correct while editing the code
- Locally, which is triggered by the git commit command
- In CI, catching the cases where it was not run locally
Automatic dependency update - renovate. I’ve been digging into this topic quite a bit in the last few weeks. Say no more.
A development environment inside a container. Instead of installing and maintaining on my computer(s) all the tools required to run an environment all that is required is docker or podman or any other containers engine.
Two options for activation:
- Local - devcontainer
- Remote - codespaces or gitpod

P.S. Want to talk to me one on one. Click on link.

Original Facebook post in Hebrew here