NETWAYS Blog

Konzeption oder Proof of Concept? So wird dein IT-Projekt zum Erfolg

von Thilo Wening | Apr 13, 2023 | NETWAYS

This entry is part 1 of 4 in the series So geht IT Consulting

In unserer Blogserie „So geht …“ geben wir Dir spannende Einblicke in die Geschäftsfelder von NETWAYS Professional Services und unseren Arbeitsalltag als 360° Open Source IT-Dienstleister. Dabei möchten wir Dir vermitteln, mit welchen typischen Problemen unsere Kolleg:innen konfrontiert werden, was dahintersteckt und wie wir diese, auf unsere Art, lösen.
Den Anfang macht ein Bereich der seit über 10 Jahren das Herz von NPS darstellt: IT Consulting. Unsere erfahrenen Consultants nehmen dich mit in ihre Welt und erklären dir, woraus das NETWAYS IT Consulting eigentlich besteht und worauf du Dich als unser:e Kund:in freuen kannst.

Thilo Wening ist unser Manager Consulting. Er ist seit vielen Jahren Teil unseres Unternehmens und hat für verschiedenste Großkunden Projekte erfolgreich umgesetzt. Er startet diese neue Blogserie mit einer Frage: Konzept oder Proof of Concept?

Konzept

Jedes Projekt steht bzw. fällt mit dem zugrundeliegenden Konzept. Erst mit diesem können wir für Dich als unsere:n Kund:in ein spezifisches Angebot mit genauen Arbeitspaketen und Abfolgen erstellen.

Um ein gutes Grobkonzept zu erstellen, sammeln wir Informationen wie Ziele, Wünsche oder bestehende Probleme für die neue Umgebung. Dazu sammeln wir mit Dir zusammen Eckdaten und definieren Ziele in einem gemeinsamen Onboarding Workshop.

Was wollen wir erreichen mit der Umgebung?

Benachrichtigen im Fehlerfall?
Metriken sammeln und Trends erkennen?
Automatisierte Installation?
SLAs für Kunden bereitstellen?

Wer ist die Zielgruppe?

Kollegen aus dem Nachbarbüro
Kund:innen mit SLA Vereinbarungen
Zentrale Ansicht für ein Incident Management Team
Verteilte Teams die Tool as a Service nutzen

Handelt es sich um eine Migration von Icinga oder einem anderen Tool, ist es besonders wichtig Probleme in der aktuellen IT-Umgebung zu identifizieren. Dazu zählen Ausfälle des Systems, Performance Probleme, Schwierigkeiten bei der Handhabung, beim Update oder bei der Erweiterung der Umgebung.

Mit diesen Informationen wird das bereits angesprochene Grobkonzept erstellt. Es enthält eine Analyse des aktuellen Stands, Herausforderungen mit der bestehenden Umgebung und die gemeinsam definierten Ziele. Um das Projekt für Dich transparent und mit klaren Arbeitspaketen zu gestalten, werden alle definierten Tools und Lösungsansätze umfangreich beschrieben.

Um Dir einen Überblick über den zeitlichen Rahmen des Projekts zu geben, kalkulieren wir um NETWAYS IT Consulting den zeitlichen Aufwand der definierten Arbeitspakete.

Proof Of Concept

Ein Proof of Concept (POC) hilft bei der Projektplanung dabei eine Lösung zu simulieren, Probleme in der Benutzung zu finden oder technische Möglichkeiten aufzuzeigen. Bevor ein POC umgesetzt wird, muss festgelegt werden, was genau simuliert oder dargestellt werden soll. Diese Ziele und ein zeitlicher Rahmen werden in einem gemeinsamen Termin zwischen Dir und deinem persönlichen Consultant besprochen und festgelegt.

Im Anschluss wird die Vorgehensweise des Proof of Concept festgelegt. Im Icinga Umfeld kann zum Beispiel eine in Deiner Infrastruktur gestartete Virtuelle Maschine aufgesetzt werden. Diese kann vom Dir und Deinem Team umfangreich getestet und weiteren Kolleg:innen bzw. dem Management vorgeführt werden. Des Weiteren kann können wir individuelle Lösungen auch in einer lokalen Entwicklungsumgebung testen, falls Freigaben oder Vorbereitungen kurzfristig nicht umgesetzt werden können.

Im Falle von Icinga können meine Kolleg:innen oder ich mit Hilfe von Automatisierungslösungen wie Ansible oder Puppet schnell eine Umgebung aufsetzen. Dadurch sparen wir uns wertvolle Zeit, um gemeinsam weitere Lösungen für die individuellen Herausforderungen Deines Unternehmens zu evaluieren.

Konzept vs POC

Je nach Anforderungen und Projekt ist ein Konzept oder ein POC sinnvoll. Grundsätzlich kann ein Proof of Concept Deine Wünsche schneller abbilden, eine Umgebung visualisieren sowie Vorteile und Nachteile einer Lösung hervorheben. Ein Konzept hingegen ist lediglich die theoretische Planung eines Projekts und kann wenig über die Funktionalität der Lösung aussagen. Daher ist hier die Expertise und Erfahrung des Consultants wichtig.
Bei größeren Projekten mit neuen Herausforderungen werden häufig beide Varianten gemeinsam eingesezt, um die Komplexität des Projekts bestmöglich abzubilden. Ein POC, welches Dir und deinem Team die spezielle Lösung visuell demonstrieren und simulieren kann. Im Anschluss wird die endgültige Lösung in einem Konzept festgehalten um einen zeitlichen Projektrahmen zu schaffen. Zudem werden für das Projekt Voraussetzungen, Arbeitspakete und Sizing definiert.

Die Umsetzung des Projekts ist bei allen Unternehmen individuell gestaltet. Mein Team und ich können, wenn ein Zugriff gegeben ist, die Umgebung kundenunabhängig aufbauen und im Anschluss eine technische Dokumentation der Arbeitsschritte bzw. der Umgebung liefern. Hierbei arbeiten Deine NETWAYS Consultants mit einer Vielzahl von Tools wie Citrix, AnyDesk oder VPN.

In anderen Fällen ist kein direkter Zugriff auf den Server vorhanden oder Du willst direkt bei der Umsetzung dabei sein, um gleichzeitig vom Workshop als direkte Schulung zu profitieren. Dabei werden Fragen zu Handling und Aufbau direkt beantwortet.

Wissen für alle

Nach erfolgreicher Umsetzung des Projekts muss schließlich noch ein Wissenstransfer stattfinden. Dieser ist je nach Projekt, Tool und Umgebung verschieden. Nach Projekten in enger Zusammenarbeit sind während des Workshops bereits viele grundsätzliche Fragen geklärt und meist ist der Kunde im Handling mit der Umgebung sicher. In solchen Fällen ist eine technische Dokumentation des Projekts ausreichend.

Falls ein Projekt unabhängig vom Kunden durchgeführt wurde, sollte idealerweise noch ein Wissenstransfer in Form eines extra Workshops oder gar einer Schulung stattfinden. Abhängig von der Anzahl der Mitarbeiter, welche die Umgebung bedienen, ist es sinnvoll eine Schulung für das gesamte Team durchzuführen. Bei einer kleineren Anzahl an Benutzern kann bereits ein Hands-On Workshops von ein paar Stunden ausreichen, um dem Kunden den Umgang und die Konfiguration der neuen Umgebung nahe zu bringen.

Falls Du nun Neugierig geworden bist und aktuell sowieso auf der Suche nach einem erfahrenen Open Source IT-Dienstleister mit Herz bist, dann melde dich gerne bei uns! Ich und meine Kolleg:innen führen gerne eine individuelle Betrachtung zu Deiner IT-Umgebung und ihren Anforderungen durch. Im Rahmen eines ersten Consultingtermins sprechen wir gemeinsam gerne über Deine Vorstellungen und Wünsche für deine IT-Infrastruktur. Ich bin mir sicher, gemeinsam finden wir die beste Lösung!

Thilo Wening

Manager Consulting

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.

Lies mehr von Thilo und triff unser Team

Ansible – Testing roles with Molecule

von Thilo Wening | Sep 15, 2022 | Python, Ansible, Linux, Automation, DevOps

Ansible is a widely used and a powerful open-source configuration and deployment management tool. It can be used for simple repetitive daily tasks or complex application deployments, therefore Ansible is able to cover mostly any situation.

If used in complex or heterogene environments it is necessary to test the code to reduce time to fix code in production. To test Ansible code it is suggested to use Molecule.

Molecule is a useful tool to run automated tests on Ansible roles or collections. It helps with unit tests to ensure properly working code on different systems. Whether using the role internally or provide it to the public, it is useful to test many cases your role can be used. In addition Molecule is easily integrated into known CI/CD tools, like Github Actions or Gitlab CI/CD.

In this short introduction I’ll try get your first Molecule tests configured and running!

Please make sure you installed Molecule beforehand. On most distributions it’s easily installed via PIP.
The fastest and most common way to test roles would be in container. Due to a version problem with systemd currently it’s not possible to start services over systemd in containers. For this reason you can easily start with a vagrant instance and later migrate to docker or podman easily.


pip install molecule molecule-vagrant

If you have a role you can change into the role directory and create a default scenario.


cd ~/Documents/netways/git/thilo.my_config/
molecule init scenario -r thilo.my_config default
INFO     Initializing new scenario default...
INFO     Initialized scenario in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default successfully.

Below the molecule folder all scenarios are listed. Edit the default/molecule.yml to add the vagrant options.

Add a dependency file with your collections as with newer Ansible versions only the core is available. If needed you can add sudo privileges to your tests.

molecule/default/molecule.yml


---
dependency:
  name: galaxy
  options:
    requirements-file: collections.yml
driver:
  name: vagrant
platforms:
  - name: instance
    box: bento/centos-7
provisioner:
  name: ansible
verifier:
  name: testinfra
  options:
    sudo: true

The converge.yml is basically the playbook to run on your instance. In the playbook you define which variables should be used or if some pre-tasks should be run.

molecule/default/converge.yml


---
- name: Converge
  hosts: all
  become: true
  tasks:
    - name: "Include thilo.my_config"
      include_role:
        name: "thilo.my_config"

Now you can run your playbook with molecule. If you want to deploy and not delete your instance use converge. Otherwise you can use test, then the instance will be created, tested and destroyed afterwards.


python3 -m molecule converge -s default
or 
python3 -m molecule test -s default

Finally we can define some tests, the right tool is testinfra. Testinfra provides different modules to gather informations and check them if they have specific attributes.

Your scenario creates a tests folder with the following file: molecule/default/tests/test_default.py

In this example I’ll test the resources my role should create.


"""Role testing files using testinfra."""


def test_user(host):
    """Validate created user"""
    u = host.user("thilo")

    assert u.exists

def test_authorized_keys(host):
    """Validate pub key deployment"""
    f = host.file("/home/thilo/.ssh/authorized_keys")

    assert f.exists
    assert f.content_string == "ssh-rsa AAAA[...] \n"

And if we already converged our instance, we can verify these definitions against our deployment.


python3 -m molecule verify
INFO     default scenario test matrix: verify
INFO     Performing prerun with role_name_check=0...
[...]
INFO     Running default > verify
INFO     Executing Testinfra tests found in /Users/thilo/Documents/netways/git/thilo.my_config/molecule/default/tests/...
============================= test session starts ==============================
platform darwin -- Python 3.9.12, pytest-6.2.5, py-1.11.0, pluggy-0.13.1
rootdir: /
plugins: testinfra-6.4.0
collected 2 items

molecule/default/tests/test_default.py ..                                [100%]

============================== 2 passed in 1.79s ===============================
INFO     Verifier completed successfully.

With those easy steps you can easily test your roles for any scenario and your deployments can run without any hassle or at least you will be more relaxed during it 😉

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening

Manager Consulting

Lies mehr von Thilo und triff unser Team

Ansible – How to create reusable tasks

von Thilo Wening | Mrz 24, 2022 | Python, Ansible, DevOps

Ansible is known for its simplicity, lightweight footprint and flexibility to configure nearly any device in your infrastructure. Therefore it’s used in large scale environments shared between teams or departments. Often tasks could be used in multiple playbooks to combine update routines, setting downtimes at an API or update data at the central asset management.

To use external tasks in Ansible we use the include_task module. This module dynamically includes the tasks from the given file. When used in a specific plays we would assign play specific variables to avoid confusion. For example:


vim tasks/get_ldap_user.yml

- name: get user from ldap
  register: users
  community.general.ldap_search:
    bind_pw: "{{ myplay_ad_bind_pw }}"
    bind_dn: "{{ myplay_ad_bind_dn }}"
    server_uri: "{{ myplay_ad_server }}"
    dn: "{{ myplay_ad_user_dn }}"
    filter: "(&(ObjectClass=user)(objectCategory=person)(mail={{ myplay_usermail }}))"
    scope: children
    attrs:
      - cn
      - mail
      - memberOf
      - distinguishedName

If this task should be used in another playbook to reduce the amount of code or is used again with other conditions or values. Therefore the variables need to be overwritten or if it is another playbook the variables are named wrong.

The solve this problem change the variables to unused generic variables. And assign your own variables in the include_task statement.


vim tasks/get_ldap_user.yml

- name: get user from ldap
  register: users
  community.general.ldap_search:
    bind_pw: "{{ _ad_bind_pw }}"
    bind_dn: "{{ _ad_bind_dn }}"
    server_uri: "{{ _ad_server }}"
    dn: "{{ _ad_user_dn }}"
    filter: "(&(ObjectClass=user)(objectCategory=person)(mail={{ _ad_usermail }}))"
    scope: children
    attrs:
      - cn
      - mail
      - memberOf
      - distinguishedName

The include_task vars parameter provides own variables to the tasks.


vim plays/user_management.yml
[...]
- name: check if user exists in ldap
  include_tasks:
    file: tasks/get_ldap_user.yml
  vars: 
    _ad_bind_pw: "{{ play_ad_pw }}"
    _ad_bind_dn: "{{ play_ad_user }}"
    _ad_server: "{{ play_ad_server }}"
    _ad_user_dn: "OU=users,DC=example,DC=de"
    _ad_usermail: "{{ play_usermail }}"

This can be easily combined with loops, to enhance the reusability of your tasks even more! Checkout this blogpost about looping multiple tasks. Ansible – Loop over multiple tasks

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening

Manager Consulting

Lies mehr von Thilo und triff unser Team

Ansible – check your data

von Thilo Wening | Nov 3, 2021 | Ansible

The automation and deployment tool Ansible is able to configure applications in multiple environments. This is possible due to variables used in Roles.

Variables are key to make roles reusable, but without proper documentation or descriptions they can get complicated.
If you want to provide different scenarios which are defined by specific variables, you can provide a good documentation and hope it will be seen and understood, otherwise users will get failed runs.

But instead of failed runs with cryptic messages which show that the used variables are wrong, we can easily check beforehand if the variables are set correctly.

The Ansible module ansible.builtin.assert can provide the solution to this problem.

With Ansible when expressions you can define rules and check variables. If the conditions aren’t true the module will fail with a custom message or if true, reward the user with a custom „OK“ message.


- assert:
    that: role_enable_feature is true and role_feature_settings is defined 
    success_msg: The feature is configured correctly and will be managed. 
    fail_msg: To use the feature please configure the variable role_feature_settings, please look at the documentation section X.

With this module it’s easy to guide users when they forgot to use a specific variable or if they use multiple variables which shouldn’t be used together.

If you want to learn more about Ansible, checkout our Ansible Trainings or read more on our blog.

Thilo Wening

Manager Consulting

Lies mehr von Thilo und triff unser Team

Ansible – AWX|Tower State handling on Workflows

von Thilo Wening | Apr 27, 2021 | Python, Ansible, NETWAYS, Icinga

The Ansible Tower or its upstream AWX provides an easy to use GUI to handle Ansible tasks and schedules. Playbooks are configured as templates and as the name suggests, they can be modified to the needs, extended by variables, a survey or tags.

Furthermore those templates can be logically grouped, connected and visualised in Workflows.

The downside to those Workflows, all playbooks affected by this are executed separately and can’t access each others variables. On first glance we maybe only spot that we can define variables for the whole workflow but those are not changeable throughout the flow.

But there is a solution, which is the module set_stats. This module allows to save or accumulate variables and make them available for other playbooks within the workflow.

As an example we could use the monitoring environment when setting downtimes.

As a downtime is created before a maintenance and should be gone when the maintenance is done. This creates a dependency on the first task, which can be solved as we save the result of the first tasks with the set_stats module.


      - name: schedule downtimes
        icinga2_downtimes:
          state: "{{ downtime_icinga_state | default('present') }}"
          host: ***
          author: "{{ icinga2_downtimes_author | default('ansible_downtime') }}"
          comment: "{{ icinga2_downtimes_comment | default('Downtime scheduled by Ansible') }}"
          duration: "{{ icinga2_downtimes_duration | default(omit) }}"
        register: content
 
      - set_stats:
          data:
            downtime: "{{ content }}"

The content of the data will be now available to all playbooks included by the workflow. The variable is also shown as artefacts in the GUI.

Keep in mind that the variable will be part of the extra variables for all other playbooks. As covered in the variable precedence it will overwrite any other variable named the same.