Understanding the inventory file - Alfresco Content Services - 23.4 - 23.4 - Ready - Alfresco - external

Alfresco Content Services

Platform
Alfresco
Product
Alfresco Content Services
Release
23.4
License

An inventory file is used to describe the architecture or environment where you want to deploy the Content Services platform. Each managed machine/host taking part in the environment needs to be described with at least:

  • a host name: a name, which in most cases can be anything (It is though a good practice to use a name or an address that all managed machines can resolve and reach from their local network).

And optionally:

  • an ansible_user variable: if the host requires a unique and specific user to login to.
  • an ansible_host variable; if the host needs to be reached through an address that’s different from the inventory_hostname (e.g. machine is only reachable through a bastion host or some sort of NAT).
  • an ansible_private_key_file in case your hosts needs a specific SSH key in order to login to it.

A Content Services inventory file has the following groups a host can belong to:

  • repository: the list of one or more hosts that will get a Content Services repository deployed.
  • database: a host on which the playbook will deploy PostgreSQL.
  • activemq: the host on which the playbook will deploy the message queue component required by Content Services.
  • external_activemq: an alternative group to activemq in case you don’t want to deploy ActiveMQ using our basic activemq role but instead use an ActiveMQ instance of yours which matched your hosting standards.
  • search: a single host on which to deploy Alfresco Search Services.
  • search_enterprise: one or more hosts on which to deploy Search Enterprise, as an alternative to Alfresco Search.
  • elasticsearch: one or more hosts on which to deploy the ElasticSearch cluster backing Search Enterprise.
  • external_elasticsearch: an alternative group to elasticsearch in case you don’t want to deploy ElasticSearch using the community ElasticSearch role but instead use an ElasticSearch cluster of yours which matches your hosting standards.
  • nginx: a single host on which the playbook will deploy an NGINX reverse proxy configured for the numerous http based services, such as Alfresco Digital Workspace and Alfresco Share.
  • acc: a single host where you want the Alfresco Control Center UI to be installed.
  • adw: a single host where you want the Alfresco Digital Workspace UI to be installed.
  • transformers: a single host where the playbook will deploy the Alfresco Transform Service components.
  • syncservice: a single host where the Alfresco Sync Service will be deployed.
Note: Ansible also ships with a default group called all, which all hosts always belongs to.

Inventory files provided as examples in this playbook are all written in YAML. Groups are always children items of the all group itself or of other groups. Hosts are mentioned after a hosts key under any group (including the all group). So a generic example would be:

---
all:
  children:
    repository:
      hosts:
        repo1.example.com:

An inventory file can also be used to set variables within a specific scope. Variables can be specified at the hosts, groups, or all levels, thus affecting the scope in which that variable is available. So if a variable, such as ansible_user, is valid for all hosts, it should be set once under the all group.

See Ansible variable precedence documentation to better understand how precedence works.

In most cases we recommend that you use your inventory to add the configuration variables that you need, tweaking the playbook to your needs.

We provide example inventories:

  • Local where all the components are installed on the control node machine:
    A diagram of a Local inventory, where all components are installed on the local machine, and then all roles are executed locally.
  • Remote (also known as ssh) where components are installed on one or more remote hosts. These hosts can be bare metal machines, virtual machines, or instances running on a public cloud:
    A diagram of an SSH inventory, where all components are installed on several remote hosts, which execute tasks.
  • HA (also known as ha - high availability). It’s very similar to the ssh one but also provides a skeleton for repository clustering.

Complete documentation about the inventory file is available at Ansible.