Closed rauldpm closed 4 months ago
all:
hosts:
Agent:
ansible_host: 192.168.56.34
ansible_port: 22
Manager:
ansible_host: 192.168.56.35
ansible_port: 22
vars:
ansible_user: 'vagrant'
ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
ansible_ssh_private_key_file: './utils/key'
ansible-playbook playbooks/provision_test.yml -i ./inventory.yaml --limit Agent
ansible-playbook playbooks/test.yml -i ./inventory.yaml --limit Agent
infra.py
---
specs/roles.yaml
specs/os/*.yaml
grouped by OS family i.e ubuntu.yaml
---
linux-ubuntu-22.04-amd64:
specs:
distro: ubuntu
familly: linux
version: 22.04
codename: jammy
arch: amd64
providers:
aws:
ami: ami-0fc5d935ebf8bc3bc
zone: us-east-1
vagrant:
box: ubuntu/focal64
linux-ubuntu-22.04-arm64:
specs:
distro: ubuntu
familly: linux
version: 22.04
codename: jammy
arch: arm64
providers:
aws:
ami: ami-016485166ec7fa705
zone: us-east-1
specs/providers/*.yaml
i.e aws.yaml
security-group: [ sg-0877d224f9c5b2708 ]
zone: us-east-1
key:
type: fixed
name: jnasselle-dev
name:
type: dynamic
prefix: dt-${tier}-${os}-${arch}-${type}
tags:
type: qa
Still on hold due https://github.com/wazuh/wazuh/issues/19166
Still on hold due https://github.com/wazuh/wazuh/issues/19300 and https://github.com/wazuh/wazuh/issues/19166
Proposed architecture
Working on the proposed architecture, only the part that will enter DTT1
Jenkins:
Loki metrics:
Grafana dashboard:
Jenkins log:
Grafana Loki datasource
I am investigating Jenkins, Prometheus and Grafana integration. The objective is to obtain a graph like the following:
This could give us a lot of real-time information that we do not have today.
Configured Prometheus with Jenkins and Grafana:
This can give us a lot of information about metrics of Jenkins, such us:
After analyzing prometheus and grafana, I was able to configure the following dashboards which provide information about:
Jenkins metrics:
Pipeline metrics:
Based on PoC feedback (functional and non-functional) and weekly design meetings, the next tasks should be addressed
@fcaffieri take a look at https://github.com/PrefectHQ/prefect and https://github.com/dagster-io/dagster
We must ensure the functionality of the main modules (Allocator/Provision/Test) before readapting the Observability module. Before working on each module, the previous one must be completed and validated. Each module must take into account the previous one
Allocator
module
Provision
module
Testing
module
Before continuing with the final development of the modules, we should consider the changes and proposals discussed in the last meeting to evaluate the impact and carry out a second iteration of the PoC so that we validate these annotations.
The PoC is not clear, we must establish a series of actions to validate it before continuing with the next iteration
The documentation will be generated in the last iteration of the development, because as progress is made, problems are found that are being resolved, for more details on this see issue: https://github.com/wazuh/wazuh-qa/issues/ 4495 Referring to the modules and their easy execution, it is one of the problems found after the PoC and we are working on iteration 2. Regarding the observability module, as it was built it is not invasive or intrusive in the modules, it only collects information from the nodes where said modules run and stores it in Loki. No configuration or development is required within each module for its operation.
We must ensure the functionality of the main modules (Allocator/Provision/Test) before readapting the Observability module. Before working on each module, the previous one must be completed and validated. Each module must take into account the previous one
Exactly, this is what was proposed in iteration 2 to be developed, in conjunction with the analysis and implementation of the orchestrator of said modules.
Indeed, iteration 2 is where everything mentioned in @raul's comment will be taken into account, in summary:
The PoC is considered finalized, according to the fact that the proposed objective for it was completed in the branch https://github.com/wazuh/wazuh-qa/tree/enhancement/4495-deployability-tier-1 and presented with acceptance of those interested. Another PoC will be scheduled at the end of iteration 2 of the DTT to address the points raised and problems found in iteration 1.
EPIC: https://github.com/wazuh/wazuh-qa/issues/4495
Description
This issue aims to design and create an initial Proof of Concept based on the analysis carried out in the issue https://github.com/wazuh/wazuh-qa/issues/4519
In this way, the PoC will show the following functionalities on a single system:
This PoC will have the following bases:
The composition of the tests will be as follows: