Project: A:Platform64

 █████╗    ██████╗ ██╗      █████╗ ████████╗███████╗ ██████╗ ██████╗ ███╗   ███╗ ██████╗ ██╗  ██╗
██╔══██╗██╗██╔══██╗██║     ██╔══██╗╚══██╔══╝██╔════╝██╔═══██╗██╔══██╗████╗ ████║██╔════╝ ██║  ██║
███████║╚═╝██████╔╝██║     ███████║   ██║   █████╗  ██║   ██║██████╔╝██╔████╔██║███████╗ ███████║
██╔══██║██╗██╔═══╝ ██║     ██╔══██║   ██║   ██╔══╝  ██║   ██║██╔══██╗██║╚██╔╝██║██╔═══██╗╚════██║
██║  ██║╚═╝██║     ███████╗██║  ██║   ██║   ██║     ╚██████╔╝██║  ██║██║ ╚═╝ ██║╚██████╔╝     ██║
╚═╝  ╚═╝   ╚═╝     ╚══════╝╚═╝  ╚═╝   ╚═╝   ╚═╝      ╚═════╝ ╚═╝  ╚═╝╚═╝     ╚═╝ ╚═════╝      ╚═╝


A:Platform64 is an automated infrastructure-as-code management platform based on Ansible.

Design Principles

The platform is designed to take full control of the target infrastructure under the following principles:

  • Automate everything: all management tasks should be automated. Exceptions should be carefully evaluated and only used when no automation is possible.
  • Separate code from end-state configuration: automation scripts must be developed to define a clear and well-documented parameter interface for setting end-state and behaviour data.
  • Ansible Roles must be specialized: roles will be used to manage single components or services. Dependencies must be clearly documented for cases where the role relies on features provided by other roles.
  • Infrastructure data model: the infrastructure will use a data model to represent the target end-state and run-time behaviour. The model includes the following elements:
    • Site: Represents a group of Nodes that are managed by the same Control Node.
    • Node: Compute node that is capable of hosting software components and that is fully managed by the Control Node.
    • Component: Individual software product that is installed in a Node.
    • Service: Group of Components configured in one or more Nodes to serve a particular function.
  • Multi-platform friendly: roles must be prepared to separate platform-specific code into individual files that can be loaded on-demand. Roles should not be allowed to execute on platforms that are not supported.
  • Test everything: roles must include testing code to check platform compatibility, code sanity, standardization, integration and functionality.


The platform defines the following components:

  • Control Node: compute node that will host the Ansible engine and the A:Platform64 platform.
  • Management Node: compute nodes that will me managed by A:Platform64
  • Site: group of hosts that shares a set of configuration files. Sites can be used to isolated environments (e.g.: prod, dev, test, etc.)

Communication between the Control Node and the Management Nodes will be done using OpenSSH and regular Linux user accounts with public/private key pairs. Root privilege will be provided by Sudo.

The Control Node will have the following directory structure to store A:Platform64 components:

Path Content
etc/ Configuration files and keys
inventories/ Ansible inventory files, host_vars and group_vars
collections/ Ansible Collections installed from Ansible-Galaxy
roles/ Custom Ansible Roles
playbooks/ Custom Ansible Playbooks
files/ Ansible data files for custom playbooks and roles
templates/ Custom Ansible templates
tests/ Ansible playbooks for testing Custom Ansible Roles and Playbooks
vars/ Ansible variables for custom playbooks and roles
logs/ Execution logs
var/ Variable and temporal data store
bin/ Shell scripts
docs/ Repository for storing site-specific documentation

The directory structure and configuration are automatically created during the Deployment Procedure

Automation Scripts

The platform uses Ansible Roles to implement automation scripts. Roles are grouped into Ansible Collections based on the managed component type:

Collection Description
application Ansible Roles for automating office applications provisioning
automation Ansible Roles for managing automation tools provisioning
backup Ansible Roles for automating backup tools provisioning
cloud Ansible Roles for automating cloud tools provisioning
container Ansible Roles for automating container tools provisioning
database Ansible Roles for automating database tools provisioning
development Ansible Roles for automating development environment provisioning
devops Ansible Roles for automating devops tools provisioning
hardware Ansible Roles for automating hardware drivers provisioning
hypervisor Ansible Roles for automating hypervisor tools provisioning
infrastructure Ansible Roles for automating infrastructure tools provisioning
monitor Ansible Roles for automating monitoring tools provisioning
network Ansible Roles for automating network tools provisioning
security Ansible Roles for automating security tools provisioning
storage Ansible Roles for automating storage management
system Ansible Roles for automating operating system management
web Ansible Roles for automating web tools provisioning

Services are implemented in the form of Ansible playbooks. Each playbook will integrate the roles needed to implement the service along with their own set of end-state and inventory configurations:

  • Playbooks location: playbooks/<SITE>/
  • End-State configuration location: inventories/<SITE>/group_vars/<GROUP_NAME>/
  • Inventory definition: inventories/<SITE>/<INVENTORY>.ini
Playbook Description
manage_aplatform64_servers Manage A:Platform64 Control node
manage_aplatform64_nodes Manage A:Platform64 Managed nodes
manage_cloud_control_nodes Provision public cloud management tools
manage_dev_nodes Provision software development environments
manage_doc_sites Provision documentation site management tools
manage_file_servers Manage file servers
manage_git_servers Manage GIT servers
manage_hpc_nodes Provision high-performance computing environments
manage_jenkins_controllers Manage Jenkins controllers
manage_jenkins_workers Manage Jenkins workers
manage_linux_servers Manage Linux Servers
manage_linux_workstations Manage Linux Workstations
manage_macos_workstations Manage MacOS Workstations
manage_office_nodes Provision office productivity applications
manage_test_nodes Provision software testing tools


OS Compatibility

A:Platform64 is compatible with the following Linux operating systems:

  • AlmaLinux8
  • CentOS8
  • Debian10, Debian11
  • Fedora33, Fedora35
  • MacOSX12
  • OracleLinux8, OracleLinux9
  • RedHat8
  • RockyLinux8
  • Ubuntu20, Ubuntu21, Ubuntu22

Notice that roles have their own compatibility matrix. Refer to the respective documentation for further details.


  • Control Node:
    • Python 3
    • OpenSSH
    • Sudo
    • Regular user account with sudo privilege for running the installer
  • Managed Nodes:
    • Python 3
    • OpenSSH
    • Sudo
    • Regular user account with sudo privilege for the bootstrap process


  • Download the installation script:
curl -O
chmod 0755 ap64
  • Run installation script with the default options. Curent user must have root privilege with sudo.
./ap64 -i
  • Done, A:Platform64 is now installed and ready to use:
    • installation location: /opt/ap64
    • installation user: ap64
    • CLI: /opt/ap64/ap64


Command Line Interface (CLI)

Usage: ap64 <-i|-j|-c|-o|-r|-u|-l|-n|-t|-k> [-s Site] [-x Host] [-p Playbook] [-e Collection|-f Package] [-b Root] [-d Var] [-v Version] [-g User] [-V Verbose] [-D Debug] [-h]

A:Platform64 command line interface


  -i           : Install A:Platform64
  -j           : Bootstrap A:Platform64 (internal use only)
  -c           : Create a A:Platform64 site
  -o           : Remove a A:Platform64 site
  -r           : Refresh A:Platform64 site configuration by rerunning the setup process
  -u           : Upgrade A:Platform64 Ansible collections to the latest version in Ansible Galaxy
  -l           : List available playbooks
  -n           : Run playbook
  -t           : List sites
  -k           : Add managed node


  -h           : Show usage info


  -b Root      : APlatform64 root path. Default: /opt/ap64
  -d Var       : APlatform64 var path. Default: /var/opt/ap64
  -g User      : APlatform64 user name. Default: ap64
  -v Version   : Ansible Core version for the controller node. Default: 2.13. Format: Major.Minor
  -s Site      : Target Site. Defaul: site
  -x Host      : Target host for playbook run. Default: all
  -p Playbook  : Name of the playbook to run
  -e Collection: Collection name for the upgrade option (-u). Default: all
  -f Package   : Collection package file (-u). Default: none
  -V Verbose   : Set verbosity level. Format: one of BL64_MSG_VERBOSE_*
  -D Debug     : Enable debugging mode. Format: one of BL64_DBG_TARGET_*

Common Use Cases

Register managed node

Use to register managed nodes.

The target node must be prepared for running Ansible (i.e.: have a compatible Linux distro, python3, sudo and openssh)

# Set bootstrap connection credentials. This is required for the initial connection only
export AP64_NODE_USER='sysadmin'
export AP64_NODE_PASSWORD='**change_me**'
# Register the host
/opt/ap64/ap64 -k -x 'host1.domain1'
Create Site

Use to create new environments. Each environment is an isolated set of inventories, playbooks and configurations

# Example: create site 'prod'
/opt/ap64/ap64 -c -s 'prod'

# List available sites
/opt/ap64/ap64 -t
Run A:Platform64 Playbook
# List available playbooks
/opt/ap64/ap64 -l

# Run example playbook on localhost
/opt/ap64/ap64 -n -p 'hello_world'
Upgrade A:Platform64 Collections

Use to upgrade collections from Ansible Galaxy

# Download and upgrade latest collections
/opt/ap64/ap64 -u

# Update site configuration
/opt/ap64/ap64 -r


Help on implementing new features and maintaining the code base is welcomed.