This is the second post on Zuul, which focuses on deploying it and its services. To learn what is Zuul and how it works, I recommend to read the previous post.
Methods of deployment
I’ll introduce two ways to deploy Zuul. Both are basically the same, but in one you will have this nice Ansible role which you can execute really quickly, while using the other way will require you to execute each command manually.
For quick deployment, use the Ansible way. To learn how exactly the deployment is done, step by step, use the manual way.
Recently I had the time to explore Zuul. I decided to gather everything I learned here in this post. Perhaps you’ll find it useful for your understanding of Zuul.
I split it into two posts. This post will focus on understanding what is Zuul and how it works. The second post will focus on how to deploy it along with common failures in the process.
What is Zuul?
In the beginning there was only Jenkins. The infra was unformed and broken , darkness and sadness was among developers. So the wise infra people decided to create Zuul.
What is a signal?
Software interrupts sent to the program to notify on significant event or request the program to run special sequence .
For example, the following command uses SIGHUP signal to request the program to reload it’s configuration
What is a daemon?
Except for nature spirit, a daemon is also a process running in the background, meaning it’s a non-interactive program. It’s detached from the terminal of an interactive user.
There is no easy way to identify which processes on the system are daemonas. It’s common to think that processes with ppid (parent pid) of 1 are daemons, but you can easily create in your terminal interactive process with ppid of 1, meaning not all processes with ppid 1 are daemons.
What is GIL?
GIL (Global interpreter Lock) is a mutex. Mutex is an mutual exclusion object used to prevent from two threads or more, to access the same piece of code. This piece of code also called ‘critical section’.
So GIL is Python’s way to ensure only one thread is running the code at any given time. It serializes the access to the interpreter and ensures that each thread gets exclusive access to the interpreter internals when running.