DVOP2025_Exercise/answers.md

DVOP2025_Exercise

Packer installation :

yay -S packer

Download plugins :

packer init NERD_Debian_Exercise.pkr.hcl

Build image for virtualbox :

packer build -only=virtualbox-iso.primary NERD_Debian_Exercise.pkr.hcl
A success message should appear at the end of the build:

Build 'virtualbox-iso.primary' finished after 14 minutes 25 seconds.

The build output is in the “build” directory as defined in the configuration :

output_directory = "${local.build_directory}/packer-${local.name}-virtualbox"

Import the ovf into virtualbox.

Since the machine is in NAT mode, fowarding ports must be used to access it. Use ports 80 and 22.

To see the job in our version of jenkins, we need to update the Jenkins plugins.

Answers :

1. When is the last time the test_app job ran ?
We can see in the Jenkins interface that the last build date is: Apr 1, 2019, 14:12:12

2. When building the job again, can you describe and explain what is going differently than the previous run ?
In blue ocean, for a better visualization, we see that the old build has failed a test called “TestSuite.WontWork”. The new build has an error in the build step with the error :

The source is not compiled in c++11 mode.

In the file “test.cpp” you can see the condition with the macro __cplusplus :

#if __cplusplus != 201103L
#error The source is not compiled in c++11 mode
#endif

This means that the code must be compiled with the c++11 version, otherwise the error is returned.
Macro documentation : (https://en.cppreference.com/w/cpp/preprocessor/replace#Predefined_macros)
We can see that with cmake --version, cmake versions are different between builds. (à delete) Si le CMakeLists n'a pas changé alors il faut voir au niveau de la version GCC (ou peut etre ailleurs) pour voir un potentiellement changement. (https://gcc.gnu.org/gcc-6/changes.html ou https://gcc.gnu.org/gcc-12/changes.html) ou alors le problème vient aussi d'ici : set(CMAKE_CXX_STANDARD_REQUIRED True)

3. Now that you have assessed the situation, make the necessary modifications to make sure the Job environment and/or Job executable behaves in the same manner as it was before.
One solution is to modify the “CMakeLists.txt” file by forcing compilation in c++11. In my “CMakeLists”, i'have added this line : set(CMAKE_CXX_STANDARD 11) (Variable retrieved from this documentation : https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html#prop_tgt:CXX_STANDARD)
So i made the modification and put it on this public git directory : https://gitea.jarodcajna.fr/jarjar/test_app
Then i modified the pipeline to retrieve my git repository and the “main” branch. When i restarted the job, i got the same result as the old build. So the modification worked.

Explain in a few lines the steps you took and provide a package (git repository / patch files) containing your modifications and a note explaining your changes.

4. Describe another solution to make the Job environment and/or Job executable behave in the same manner as it was before.

Explain in a few lines and compare it against your first solution.

5. Now that everything is running as expected, it is time to suggest a production rollout for this service. Please suggest changes to the service to ensure a secure, production-ready deployment to be accessed by a team of developers. The suggestions are not limited in scope, but should focus on security, performance and reliability.

• L'accès à jenkins se fait à travers d'un mot de passe propre à chaque utilisateur (SSO si disponible pour simplifier l'user experience) et avoir une 2FA. Une politique de moindre privilège peut etre mis en place, des plugins comme : https://plugins.jenkins.io/role-strategy/ permettent de faire ce genre d'action.

• Avoir au moins deux masters avec un Haproxy devant pour que si un master tombe l'autre prend le relais. Pour éviter le SPOF sur le haproxy on peut en mettre deux avec keepalived pour qu'on puisse accéder aux master à travers une VIP.

• Dans un soucis de scalabilité et de sécurité l'architecture de build distribué est à priviligié. C'est à dire que les builds sont effectué par des agents au lieu du master, ce qui permet de protéger le master du code déployé ou d'une mauvais manipulation d'un developpeurs. Pour la partie scalabilité, si on a besoin de plus de ressources pour gérer plus de build on peut donc ajouter plus d'agents.

• Un plugin comme https://plugins.jenkins.io/job-restrictions/ permet de faire en sorte que des jobs s'execute que sur certains agents. Ce qui peut permettre de séparer les jobs et les agents en fonction des équipes. Chaque équipe à ses propres ressources.

• Backup

• Centralisation des logs

• kubernetes