jarjar/DVOP2025_Exercise
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
DVOP2025_Exercise/answers.md
jarjar bfc61d596e The end
2025-03-08 13:51:38 +00:00

5.3 KiB
Raw Permalink Blame History

DVOP2025_Exercise

Git link : https://gitea.jarodcajna.fr/jarjar/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. This modification implies a change in the source code.

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.
To test without changing the code, you can use the CMake “CXXFLAGS” environment variable. This solution is less viable, as it's easy to forget to set this environment variable.

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.

  • Access to jenkins is via a user-specific password (SSO if available to simplify user experience) and a 2FA. A policy of least privilege can be implemented, with plugins such as https://plugins.jenkins.io/role-strategy/.

  • Have at least two masters with a Haproxy in front, so that if one master goes down, the other takes over. To avoid SPOF on the haproxy, you can install two with keepalived so that you can access the masters via a VIP.

  • For scalability and security, the distributed build architecture is privileged. This means that builds are carried out by agents instead of the master, thus protecting the master from deployed code or improper handling by a developer. As for scalability, if you need more resources to manage more builds, you can add more agents.

  • A plugin such as https://plugins.jenkins.io/job-restrictions/ can be used to make jobs run only on certain agents. This makes it possible to separate jobs and agents by team. Each team has its own resources.

  • Set up a backup system to recover data or return to a previous state.

  • Connect Jenkins to the company's log centralization system, in particular audit logs to know what actions are being performed on Jenkins.

  • If administrators have the knowledge and time to set this up, installing Jenkins in a Kubernetes cluster can be a good solution to take advantage of its scalability.

  • The Jenkins documentation also recommends setting up a “test” master to test plugin version upgrades.

All these points can be used to set up a production deployment.