Uploaded image for project: 'Ansible Automation Platform RFEs'
  1. Ansible Automation Platform RFEs
  2. AAPRFE-1416

[RFE] Allow to preview resources in AAP as YAML code to foster CaC and GitOps principles

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • 2.4
    • content
    • False
    • Hide

      None

      Show
      None
    • False

      Configuration as Code (CaC) is crucial in today's IT landscape because it streamlines development processes, enhances reliability, and promotes agility in managing complex software systems and infrastructure.

      Red Hat supports CaC within AAP by offering a dedicated Ansible collection (ansible.controller) and allowing the "pre-seeding" of objects into containerized and OpenShift (OCP) installation methods.
      However, CaC presents a significant entry barrier for new users of AAP, as they must simultaneously learn both AAP itself and the specific method of defining resources as code using complex YAML formatting. The complexity of nested YAML implementations is often intimidating for new users.

      A feature that automatically generates code representation for resources, such as Projects or Job Templates, is particularly helpful for new users. It substantially reduces the entry barrier, as users only need to learn the specifics of AAP while having the code generated for them.
      Once the code is generated for the user (via a Preview button or similar), the user is then able to commit the code to their git repository allowing them to tap into CaC without much effort.
      This not only promotes CaC and GitOps but also facilitates quicker deployment cycles and aids in aids in high availability and disaster recovery scenarios, which are currently not supported by Red Hat as by https://access.redhat.com/articles/4010491, ensuring that customers can swiftly resume operations with the latest configurations.

      Moreover, this feature benefits existing AAP users by streamlining deployment processes and facilitating transitions between different installation or deployment methods of AAP, such as RPM-based, containerized, or OCP-based setups. This will be especially valuable if VM installations were to be deprecated.
      Furthermore, given that AAP's reference architecture [1], [2] is centered around CaC, fostering the adoption of this reference architecture, as well as CaC and GitOps principles, would greatly benefit from such a feature.

      OCP implements a comparable feature through Custom Resource Definitions (CRD) [3], allowing resources in OCP to be represented in YAML code.

      To emphasize on the importance of CaC in today’s complex IT landscape, following key improvements can be gained by customers when adopting CaC with AAP:

      1. Reproducibility
      CaC allows developers to recreate entire environments consistently. Instead of manually configuring each resource in Ansible Automation Platform (AAP), developers can define configurations in code, ensuring that environments can be replicated precisely, leading to fewer deployment errors and inconsistencies.

      2. Scalability:
      With CaC, scaling AAP becomes easier. By defining AAP resources like Projects, Job Templates, and Credentials, it's simpler to add or remove resources as needed, automatically (e.g. GitOps) or with minimal manual intervention.

      3. Version Control
      Code configurations can be managed using version control systems such as git. This enables tracking changes over time, rolling back to previous configurations if necessary, and collaborating effectively among teams.

      4. Automation:
      CaC facilitates automation of deployment and management tasks. By "codifying" configurations, developers can automate the provisioning, configuration, and deployment processes, reducing manual overhead and the potential for human error.

      5. Consistency and Standardization
      CaC promotes consistency across environments. Developers can define standards and best practices in code, ensuring that all deployments adhere to the same configurations and reducing the risk of configuration drift. Code can be promoted using the principles of GitOps.

      6. Documentation:
      Configuration code serves as self-documentation. Instead of relying on external documentation, developers can understand the AAP deployment relevant to their team by examining the code directly, leading to better transparency and easier onboarding for new team members.

      [1]: https://www.redhat.com/en/blog/new-reference-architecture-deploying-red-hat-ansible-automation-platform-2.1?sc_cid=7015Y000003t7aWQAQ
      [2]: https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/2.1/html-single/deploying_ansible_automation_platform_2.1/index#config_as_code_using_webhooks
      [3]: https://docs.openshift.com/container-platform/4.14/operators/understanding/crds/crd-managing-resources-from-crds.html

              dmendoza@redhat.com Dafne Mendoza
              rhn-support-sscheib Steffen Scheib
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: