Getting started

Support for multiple Python versions

The role allows management of multiple Python versions at the same time. The available Python version is dependent on the OS release used on a given host.

Separate default variables can be used to specify APT packages to install for Python 2.x and Python 3.x series. The different Python versions can then be enabled or disabled independently - role automatically disables Python 3 support on older OS releases without adequate versions available, and disables Python 2 support if Ansible is configured to use Python 3 interpreter on a given host, or Python 3.x is autodetected as the Python interpreter on Ansible Controller.

Python environment bootstrapping

The special "raw" mode of operation with a custom Ansible playbook that doesn't gather Ansible facts automatically can be used to "bootstrap" Python support on a host. Role will automatically purge an existing Python 2.x packages if Python 2.x operation is disabled; this can be leveraged to maintain Python 3.x-only setup, depending on the OS release used on the host.

To support environments without proper DNS service, the bootstrap playbook can inject host entries into the /etc/hosts configuration file, using the python__raw_etc_hosts variable. This can be used to configure access to APT repositories via a HTTP proxy, for example. After bootstrapping, the debops.netbase Ansible role takes over the /etc/hosts config file management.

Example inventory

The debops.python role is included by default in the common.yml DebOps playbook; you don't need to add hosts to any Ansible groups to enable it.

Example playbook

If you are using this role without DebOps, here's an example Ansible playbook that uses the debops.python role:

---

- name: Manage Python environment
  collections: [ 'debops.debops', 'debops.roles01',
                 'debops.roles02', 'debops.roles03' ]
  hosts: [ 'debops_all_hosts', 'debops_service_python' ]
  become: True

  environment: '{{ inventory__environment | d({})
                   | combine(inventory__group_environment | d({}))
                   | combine(inventory__host_environment  | d({})) }}'

  roles:

    - role: python
      tags: [ 'role::python', 'skip::python' ]

There's a separate Ansible playbook that allows usage of the debops.python role in a "raw" mode, without fact gathering. This can be used to bootstrap Python support on a host, so that normal Ansible modules can be used afterwards:

---

- name: Bootstrap Python environment
  collections: [ 'debops.debops', 'debops.roles01',
                 'debops.roles02', 'debops.roles03' ]
  hosts: [ 'debops_all_hosts', 'debops_service_python' ]
  strategy: linear
  become: True
  gather_facts: False

  tasks:

    - name: Initialize Ansible support via raw tasks
      ansible.builtin.import_role:
        name: 'python'
        tasks_from: 'main_raw'
      tags: [ 'role::python_raw', 'skip::python_raw' ]

Ansible tags

You can use Ansible --tags or --skip-tags parameters to limit what tasks are performed during Ansible run. This can be used after a host was first configured to speed up playbook execution, when you are sure that most of the configuration is already in the desired state.

Available role tags:

role::python

Main role tag, should be used in the playbook to execute all of the role tasks as well as role dependencies.

Other resources

The debops.resources role can be used to manage pip and virtual environments, see Python Virtual Environment management documentation for more details.

List of other useful resources related to the debops.python Ansible role: