99 private links
Ansible role to install and configure neovim
Recommended practices for all elements of automation using Ansible, starting with collections and roles, continuing with playbooks, inventories and plug-ins... These good practices are planned to be used by all Red Hat teams interested but can of course be used by others. - automation-good-practices/README.adoc at main · redhat-cop/automation-good-practices
ansible-language-server extension for coc.nvim. Contribute to yaegassy/coc-ansible development by creating an account on GitHub.
Using SSH agent forwarding is dangerous. However, a dedicated agent can mitigate the risks.
Important for HCL Connections Automation! The global UseAgentForward needs more documentation and anrework to avoid.
Ansible is one of the most prominent tools among DevOps for managing software configuration because of its ease of use and bare minimum dependencies. The highlight of this tool is Ansible roles which provide a wholesome package of various functionalities that we need for software configuration.
As we know that ansible roles have a wide directory structure that looks something like this.
$ tree -d . ├── defaults ├── files ├── handlers ├── media ├── meta ├── molecule │ └── default │ └── tests ├── tasks └── templates 10 directories
We can read online about the significance of these directories but often there is some confusion around two of them that always bugs me, which are vars and defaults. Whenever I write a role I often think of whether to put my variables in defaults or the vars.
According to Ansible’s definition, the difference between defaults and vars is:
defaults mean “default variables for the roles” and vars mean “other variables for the role”.
The priority of the vars is higher than that of defaults.
For example, consider a variable named ‘version’ defined in the defaults have value ‘5.0.1’ and the same variable defined in vars have value ‘7.1.3’, so the final value that will be taken into account is the value defined in vars i.e., ‘7.1.3’.
Due to my limited understanding of this, I used to define all variables in defaults and whenever needed to override them, I declared those variables in vars.
But there was more to it just than precedence, which motivated me to deep dive into it and finds out that there are two types of variables in terms of content, “static” with constant value and “dynamic” with changing value. According to the ansible definition, the static variables should be placed in default and the dynamic should be placed in vars.
If you’ve used Ansible, you’re likely very familiar with this default output when a playbook runs a few tasks: the green indicates “ok” and unchanged, and the yellow indicates that a task has reported a change on the remote node.
Ansibles Callback plugins control most of the output you see when running the command line programs, but can also be used to add additional output, integrate with other tools and marshall the events to a storage backend
Ansible is a great tool for automating IT workflows, and I use it to manage hundreds of servers and cloud services on a daily basis. One of my small annoyances with Ansible, though, is it's default CLI output—whenever there's a command that fails, or a command or task that succeeds and dumps a bunch of output to the CLI, the default visible output is not very human-friendly.
How to develop Ansible roles w/ unit test and continuous integration services.
