{"id":15081,"date":"2022-09-26T05:13:35","date_gmt":"2022-09-26T05:13:35","guid":{"rendered":"https:\/\/www.insentragroup.com\/us\/?p=15081"},"modified":"2024-12-13T02:01:26","modified_gmt":"2024-12-13T02:01:26","slug":"introduction-to-ansible-builder","status":"publish","type":"post","link":"https:\/\/www.insentragroup.com\/us\/insights\/geek-speak\/modern-workplace\/introduction-to-ansible-builder\/","title":{"rendered":"Introduction to Ansible Builder\u00a0"},"content":{"rendered":"\n

What is Ansible Builder<\/h2>\n\n\n\n

Ansible<\/a> Builder is a command line tool which facilitates the development of Ansible Execution Environments (EEs).<\/p>\n\n\n\n

Let’s take a step back and talk about what Execution Environments are to fully appreciate the concepts.<\/p>\n\n\n\n

Execution Environments: A Quick Guide<\/h2>\n\n\n\n

Before the dawn of the Execution Environments, the Ansible Automation Platform execution system was executing jobs inside bubble wrap to separate processes. There were plenty of issues with this approach, including the requirement for all container-running jobs to execute in privileged mode on Red Hat OpenShift and Kubernetes.<\/p>\n\n\n\n

There were other problems, too. Users had a difficult time managing Ansible module dependencies and customised Python virtual environments while using Ansible Content Collections. The concept of Execution Environments, essentially container images which can be used as Ansible control nodes, is the answer to these issues.<\/p>\n\n\n\n

The Dawn of Ansible<\/h2>\n\n\n\n

Ansible Builder was created to automate the creation of Execution Environments so developers, contributors and consumers may benefit from this novel idea (it\u2019s even better when the experts are able to implement the automation solution<\/a>!). It accomplishes this by utilising both the user-specified dependency information and those defined in other Ansible Content Collections. The container image build will use Ansible Builder to create a directory which serves as the build context and contains the Container file and any additional files required to be added to the image.<\/p>\n\n\n\n

Installation<\/h2>\n\n\n\n

The easiest way to install the ansible-builder is to run the following command:<\/p>\n\n\n\n

(Note: If you have Ansible Automation Platform Hub nodes, the builder should be already installed there.)<\/p>\n\n\n\n

pip3 install ansible-builder        <\/code><\/pre>\n\n\n\n
How to Create Ansible Builder Definition<\/h2>\n\n\n\n
The “definition” in the realm of Ansible Builder is a YAML file which lists the dependencies at the Collection-level, the base image source and additional components which have to be overridden in the Execution Environment. The definition file is used as the input argument by the ansible-builder build command. It outputs the build context required to create an Execution Environment image, which is then utilised to actually build the final image. The same build context created during the build can be shared with other users to create environments with specific Ansible Collections.<\/p>\n\n\n\n
The following example presents a definition file:<\/p>\n\n\n\n
---\nversion: 1\ndependencies:\n  galaxy: requirements.yml\n  python: requirements.txt\n  system: bindep.txt\n \nadditional_build_steps:\n  prepend: |\n    RUN pip3 install --upgrade pip setuptools\n  append:\n    - RUN ls -la \/etc\n<\/code><\/pre>\n\n\n\n
The ansible-builder build command will default to execution-environment.yml file. To override this behaviour, specify a different definition file, using -f (or \u2014file) flag.<\/p>\n\n\n\n
The elements which would be listed in the dependencies section might either be an absolute path or a relative path from the directory of the Execution Environment definition’s folder.<\/p>\n\n\n\n