Technology Tales

DevOps with VS Code, GIT, and SASjs

The integration of SAS development with DevOps practices through tools like SASjs and Visual Studio Code streamlines workflows for coding, testing and deploying SAS applications. Developers can configure multiple targets for isolated builds and deployments, ensuring collaboration without conflicts.

Automated linting enforces coding standards, while unit tests generate coverage reports and results in JSON or CSV formats. Documentation is automatically generated from SAS program headers, and data lineage can be tracked by defining inputs and outputs within jobs. The process supports iterative development, with commands for executing code, managing SAS Drive folders and triggering jobs in Viya.

Although the VS Code extension is tailored for Visual Studio Code, the SASjs CLI offers core functionality for those using alternative IDEs. Community engagement and feature requests are encouraged, with options to contribute directly or collaborate with SAS Apps developers. This approach enhances code quality, reduces manual checks and aligns SAS workflows with modern software development practices, facilitating smoother integration into automated release pipelines and continuous improvement.

SAS DevOps with SASjs CLI

The SASjs Command-Line-Interface offers a range of tools for managing development and deployment processes in SAS environments, supporting tasks such as creating structured repositories, compiling services with dependencies, building deployment packages, executing deployment scripts and generating documentation from code metadata. It includes features for testing macros and jobs, managing compute contexts, synchronising files and deploying frontend applications as streaming services, along with a variety of commands to streamline workflows from initial setup through to execution and validation.

Encrypting content with Ansible Vault

The Ansible vault documentation covers how to protect sensitive data such as passwords within Ansible by using encryption. It addresses the management of vault passwords, including how to choose between single and multiple passwords, work with vault IDs and store passwords securely. It also explains how to encrypt individual variables and files, pass passwords or vault IDs at runtime and configure default settings for working with encrypted content. Additional detail is provided on when encrypted files are decrypted during execution and the technical format used by Ansible vault for encrypted files.

Ansible Vault is a feature that encrypts variables and files to protect sensitive data such as passwords and keys, preventing them from being exposed as plaintext in playbooks or roles. It requires one or more passwords to encrypt and decrypt content, which can be managed via a command-line tool or accessed through a script if stored in a third-party secret manager. Encrypted content can be placed under source control for safer sharing and used in both ad hoc commands and playbooks by supplying the relevant passwords. It is worth noting that the protection applies only to data at rest, meaning that once content is decrypted, responsibility for preventing any disclosure of secrets falls to the play or plugin author.

How to Run Ansible Playbook Locally

There are four methods available for running an Ansible playbook on a local machine rather than on remote hosts. The first involves specifying localhost in the hosts directive of the playbook, optionally adding a connection parameter set to "local" for clarity. The second, and generally most recommended, approach uses the local_action clause within the playbook to designate specific tasks as local, which is commonly used for actions such as creating cloud instances. The third method involves explicitly defining localhost as an entry in the Ansible inventory file, where it can also be assigned a custom alias for reference within playbooks. The fourth method bypasses the hosts directive entirely by using command-line flags, specifically combining the connection, inventory and limit options to force execution on the local machine, though omitting the limit flag may cause Ansible to attribute local results to remote host names, which can be a source of confusion.

Ansible – “sudo: a password is required”

When running Ansible tasks that require privilege escalation using "become: true", users may encounter a "sudo: a password is required" error. There are four ways to resolve this. The first is to use the --ask-become-pass flag with the ansible-playbook command, which prompts for a password at runtime. The second is to pass the password non-interactively as an ansible_become_password variable, though this is discouraged for security reasons as the plain-text password may be exposed in command history and process listings. The third and recommended approach is to use Ansible Vault to store an encrypted version of the password in a separate file, which is then referenced during playbook execution alongside a vault password file with restricted permissions that is excluded from source control. The fourth option is to configure the target machine to allow the Ansible user to run sudo commands without a password at all, by adding an appropriate line to the sudoers file using the visudo command.

ansible.builtin.reboot module – Reboot a machine

The ansible.builtin.reboot module, introduced in Ansible 2.7, reboots a target machine, waits for it to go offline and come back up, and then confirms it is responsive before allowing further tasks to proceed. It offers a range of configurable parameters, including pre- and post-reboot delays, a customisable reboot command, a timeout setting for how long to wait for the machine to return and a test command to verify readiness. The module also allows users to define search paths for the shutdown command, set a message to display before rebooting and specify a command for identifying the last boot time. It supports check mode, enabling a prediction of changes without modifying the target system, and has a corresponding action plugin. For Windows machines, a separate module, ansible.windows.win_reboot, should be used instead.

Working with playbooks for Ansible

Ansible playbooks are human-readable files written in a basic language that record and execute configuration, deployment and orchestration functions, allowing users to define policies for remote systems or outline steps in broader IT processes. They can manage configurations and deployments at a basic level, and at a more advanced level can sequence multi-tier rollouts with rolling updates, delegate actions to other hosts and interact with monitoring servers and load balancers. Key areas covered in working with playbooks include templating via Jinja2, data manipulation using filters, conditional logic, loops, error handling, variable management and the use of roles for reusable content.

Intro to playbooks for Ansible

Ansible Playbooks are a configuration management and multi-machine deployment system that allows users to define repeatable, reusable automation tasks written in YAML format. A playbook consists of one or more ordered plays, each targeting specific managed nodes and executing one or more tasks that call Ansible modules.

Playbooks run sequentially from top to bottom, and most modules operate idempotently, meaning the outcome remains consistent regardless of how many times a playbook is run. Tasks can be executed synchronously or asynchronously, and behaviour can be further controlled through playbook keywords, command-line flags and inventory settings.

The ansible-pull command inverts the standard architecture by having nodes check out configuration instructions from a Git repository rather than receiving them via a central push. Before running playbooks in a live environment, users can verify them using built-in flags such as --check, --diff and --syntax-check, or through external tools such as ansible-lint, which provides detailed feedback on potential errors and rule violations.

Creating a playbook for Ansible

Ansible playbooks are YAML-formatted automation blueprints used to deploy and configure managed nodes, structured around plays, tasks and modules. A play maps an ordered list of tasks to managed nodes in an inventory, while each task references a single module, which is a unit of code that Ansible runs on those nodes.

To create a basic playbook, a YAML file is set up with named plays and tasks, such as pinging hosts and printing a message, then executed via the command line using the ansible-playbook command. When run, Ansible first gathers facts about the inventory by default, then executes each task in order, reporting the status of every operation per host and producing a final recap summarising the results.

A successful run shows an OK status for each task across all hosts, confirming that the defined operations completed without error. It is recommended that descriptive names be given to plays and tasks to make verification and troubleshooting more straightforward.