0

I am having a lot of trouble conceptualizing what CICD even is... and how it does what it does. I use it every day and really grasp very little of how it works and it's frustrating to me.

I have been working in the devops space for a long time but one thing that has always truly escaped me somehow is how gitlab runners for example actually do what they do.

I get it: a runner is a machine for all intents and purposes; a containerized one that can provide a developer information about errors they'd naturally encounter had they manually run the code in the environment in question. This way you can iteratively spin up a job over and over and debug your deployment process with far greater speed without having to worry about version control.

What I don't understand is how this is even working.

It's a container with self contained OS, dependencies and so on, that runs a series of commands that you specify to it, such as with its bash shell executor. And then it reaches outside of itself at some point and terminates once the series of instructions is completed. What I don't understand is how it's doing this. A lot of people have this idea that everything that happens inside of the runner is entirely self contained but as far as I can tell this is not true at all especially if the command makes an external connection to something.

For example suppose I had a gitlab project that, when deployed, runs rsync to create a connection to an external machine. Supposing I were to change the password that rsync relies on, then what? If I were to trigger a re-deploy using the same runner, the job would ultimately fail, which means the runner is in fact deploying itself to 'things that exist outside of itself'.

0 Answers0