Ansible APK Module

From Alpine Linux
Revision as of 19:48, 11 October 2017 by Ttrask (talk | contribs) (Clarify repository info)
Jump to: navigation, search
Underconstruction clock icon gray.svg
This material is work-in-progress ...

Do not follow instructions here until this notice is removed.
(Last edited by Ttrask on 11 Oct 2017.)

Alpine Linux uses APK for all package management. As of Ansible 2.0, there is an module included in Ansible that provides support for package management on Alpine Linux hosts. This document provides some playbook samples and explanations for using this Ansible module.

Details on Module Options


The 'name' option can contain a single package or list of packages to install.


The 'state' option specifies what you want to do with the listed package(s) - present (installed but not upgraded), latest (installed or upgraded), absent (removed). The option defaults to 'present', so this command will not upgrade a package that is already installed if 'state' is not specified as 'latest'.


It is always a good idea to include the 'update_cache' option, because the command might fail otherwise if the repositories contain a newer version of the package than listed in the local package index cache. The name 'update_cache' is slightly misleading, because it actually refers to the local package index cache, not the local package cache. The system repositories are specified in the /etc/apk/repositories file (or files within /etc/apk/repositories.d/). There is a separate locally cached index for each repository specified, including the system repositories and those specified in the 'repository' option.


The 'upgrade' option is a system-wide upgrade of all packages. If you want to upgrade specific packages, use 'state' = 'latest'.

available (Ansible 2.4)

The 'available' option only applies to the 'upgrade' option. According to the documentation: "During upgrade, reset versioned world dependencies and change logic to prefer replacing or downgrading packages (instead of holding them) if the currently installed package is no longer available from any repository." In other words, using 'available' makes downgrades possible.

repository (Ansible 2.4)

If the 'repository' option is not specified, 'apk' will use the system repositories specified in /etc/apk/repositories (or files within /etc/apk/repositories.d/). (More specifically, it will always use the local package index cache for the system repositories, and the local package index cache will be updated for the system repositories if 'update_cache' is set.) If you specify the 'repository' option, 'apk' will use BOTH the system repositories AND those specified in the option. Note that 'apk' will install the newest package if multiple versions of the same package are available in the package index(es). There are some quirks to the 'repository' option: - There is a bug for state='latest' when the 'repository' option is supplied. In this case, the 'repository' option appears to be ignored. See bug #7531 - Because the system repositories AND the specified repositories are used, it is difficult to see package downgrades in check mode.

Basic Package Installation

Package Present

# Update repositories and install "foo" package
- apk:
    name: foo
    update_cache: yes

Advanced Features

tagged repos

check doesn't do actual update

system upgrade / downgrade - Upgrades to newer repository will work (with or without update). Attempting to downgrade with the newer repository still in /etc/apk/repositories will not downgrade.

trigger service restart based upon package upgrade

      - name: upgrade available
          available: yes
          upgrade: yes
          update_cache: yes
          repository: '{{ REPO }}'
        register: result

      - debug:
          msg: "The openssh package was updated so we should restart the sshd service"
        notify: restart sshd
        changed_when: "'openssh' in result.packages"
        when: "'openssh' in result.packages"

      - name: restart sshd
        service: name=sshd state=restarted

See Also