0

I am trying to get started in the DevOps Field by setting up a small server currently with Virtualbox, later on for a small team. For my basic setup I plan to use gitea as self-hosted git and Jenkins as CICD tool which also provides a lot of extensions.

The server OS I chose is RHEL 8 since the systems on which I will setup up my DevOps system in a distant future will use this OS.

Now I find a lot of sources in the internet that point me to install both tools using containers combined with an orchestration tool like kubernetes. I have a certain degree of theoretical understanding of docker and kubernetes and also experimented a little bit with both tools.

My research also provided me information on the advantages of running Jenkins in a pod:

  • only required in certain situations
  • sometimes several instances of Jenkins for different projects can be required to run in parallel

At least were that the points that I found on different blogs websites that discussed this topic for Jenkins.

For Gitea I was not able to determine reasons why it should be run in container inside a pod in kubernetes but there is a helm-chart managed by the community of it. Also I found several sources on the internet telling me helm-charts are bad, don't use them.

To build, test and deploy applications (which will be Rest applications with react/node-js frontend and different backends) I will use container and kubernetes to orchestrate the container.

Could you help me understand why I should decide for or against containers/pods for the different applications and maybe even provide reliable sources, since most information I found are just opinions spread through the internet.

1 Answer 1

1

We're using a self-hosted gitlab, nexus and Jenkins (controller) and both are hard installs on CentOS7. Jenkins agent is a remote CentOS7. That approach made the most sense to us as opposed to breaking out the whole automated pipeline shebang to deploy gitlab/jenkins/nexus. Gitlab/Jenkins/Nexus are part of the foundation of our CICD infrastructure so it made no sense to make them ephemeral by using container, scaling or orchestration approaches. The actual software components we build & deploy are ephemeral (ie: a new build / config & deploy many times a day) and that infrastructure building, deploy & config is pretty much automated from scratch.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.