Automation Field Guide: Quick AWS NextCloud Instance

October 27, 2017 by John Lieske


This is a practical use story utilizing Ansible to solve a small hurdle in an everyday workflow. 

Code for this can be found here

In this post, I’ll be sharing a practical situation where Ansible makes tasks easier. The Getting Started team works with organizations who may be putting together a proof-of-concept to evaluate Red Hat® Ansible® Tower. If troubleshooting gets into the weeds, it can include sharing documentation, instructions for common setup scenarios, or going through system settings to make sure everything’s in order.

Sometimes there's no other way: we need to get a full environment report from the system to troubleshoot, mostly in the form of a sosreport. We found that getting the report to us can be challenging, so we had to find a reliable way for people to send us their log files. A file drop web app that could be spun up on demand fit the need nicely. A Nextcloud install with a CentOS LAMP stack turned out to be a great tool, using Ansible to automate the provisioning and installation for us. Because this little trick proved so helpful, I wanted to share how I put the short playbook together, with the roles broken down step by step.


To make our playbook reusable and able to be modified for other tasks later (which we'll share in the future), I've split the playbook into discrete roles that should work on any base CentOS 7.2+ installations without modification.

The directory tree looks like:

aws_nextcloud $tree
|-- roles
|   |-- common
|   |   `-- tasks
|   |       `-- main.yml
|   |-- nc-httpd
|   |   |-- handlers
|   |   |   `-- main.yml
|   |   `-- tasks
|   |       `-- main.yml
|   |-- nc-php
|   |   |-- handlers
|   |   |   `-- main.yml
|   |   |-- tasks
|   |   |   `-- main.yml
|   |   `-- templates
|   |       `-- phpinfo.php
|   |-- nc-sql
|   |   |-- handlers
|   |   |   `-- main.yml
|   |   `-- tasks
|   |       `-- main.yml
|   `-- nextcloud
|       |-- handlers
|       |   `-- main.yml
|       `-- tasks
|           `-- main.yml
`-- site.yml

The roles show the steps and are self-explanatory:

  1. install the common packages needed (unzip, wget),
  2. install Apache,
  3. install PHP (in this case PHP 7),
  4. install MariaDB server,
  5. finish with the Nextcloud installation.


Splitting the playbook into roles makes the plays more portable, flexible, and easier to maintain. The roles in this playbook aren't very complex on their own but some of them will be reused regularly as we share some of our practical use stories. To run quickly through the roles to show what they're doing, here are the main.yml files with brief descriptions:


- name: install EPEL repo
    name: epel-release
    state: present

- name: install tools
    name: '{{item}}'
    state: latest
    - unzip
    - wget
    - bzip2

- name: Set SELinux to permissive
    policy: targeted
    state: permissive

The common play simply installs the EPEL repo, installs tools to download files and unzips them. Because this is a demonstration, I’ve set selinux to permissive mode. You might need to change the selinux policy to match your access needs.

- name: Installing Web Server
    name: httpd
    state: latest

- name: Web Server Installed Starting
    name: httpd
    state: started
    enabled: yes

This play contains more obvious tasks: install httpd (Apache) & start the service. There is a handler for restarting the service, but it's redundant.

The role for installing PHP gets a little more involved, but that was because this the version of Nextcloud requires PHP 7 while the base repos for CentOS will install PHP 5.4 by default. To install PHP 7, we’ll install the Webtatic repository to install PHP 7 and extra modules.

- name: Add Webtatic repo
    state: present

- name: Install PHP
    name: '{{item}}'
    state: present
    - php70w
    - php70w-dom
    - php70w-mbstring
    - php70w-gd
    - php70w-pdo
    - php70w-json
    - php70w-xml
    - php70w-zip
    - php70w-curl
    - php70w-mcrypt
    - php70w-pear
    - php70w-mysql
    - php70w-fpm

- name: Drop in PHPinfo for debug
    src: phpinfo.php
    dest: /var/www/html/phpinfo.php
  notify: restart httpd

- name: PHP Installed Starting
    name: php-fpm
    state: started
    enabled: yes

As an added debug measure, I use the file module to write a phpinfo.php file to the web root. The phpinfo file can be used to check that PHP and the modules installed smoothly. That phpinfo.php file looks like:

<!DOCTYPE html>



// Show all information, defaults to INFO_ALL



The nc-sql role is, like the nc-httpd role, intentionally simple:

- name: Install MariaDB package
    name: '{{item}}'
    state: latest
    - mariadb-server
    - MySQL-python
    - libsemanage-python

- name: Start MariaDB Service
    name: mariadb
    state: started
    enabled: yes

Aside from installing mariadb and component modules, the play makes sure the service is started.

Finally, we have the Nextcloud play. The play will download and extract the installer, set the directory and its permissions, then create a database and user in SQL.

- name: extract installer
    dest: /var/www/html/
    remote_src: True
    owner: apache
    group: apache

- name: Create Data Directory
    dest: /var/www/html/nextcloud/data
    owner: apache
    group: apache
    mode: 0775
    state: directory

- name: Create NextCloud database
    name: nextcloud
    state: present

- name: Create NextCloud database user
    name: ncuser
    password: passd234
    priv: nextcloud.*:ALL
    host: localhost
    state: present

Once these roles have completed without errors, Nextcloud is installed. After this is complete, the web setup/configuration page would be available at https:///nextcloud/ to create an admin user.

The top level to the playbook calls the roles in order, naming the target tag from our AWS inventory.

- name: Install Nextcloud
  hosts: tag_Name_meseeks
  remote_user: centos
  become: true

    - common
    - nc-httpd
    - nc-php
    - nc-sql
    - nextcloud

Once configured and a new user is added, Nextcloud is accessible and ready to use as a quick file drop for transfer.

This playbook is useful for helping automate some repetitive IT processes, and it doesn’t have to be limited to one single use. Part of this playbook creates a basic LAMP stack that can be used in other small projects. In future posts sharing examples like this one, most of these roles will be reused with only slight modifications.

Are you ready to get started? Check out the Ansible Getting Started page and begin automating in a simple and fast way.



AWS, Automation Field Guide


John Lieske

John Lieske is a Partner Engineer with Ansible at Red Hat. Having worked in technology since 2003, he's worn a lot of different hats. Here at Red Hat Ansible, John works with partners looking to contribute modules and other content. John's also an amateur musician & aspiring illustrator in his spare time. He can be found on Twitter and on Github at @johnlieske.


See All

rss-icon  RSS Feed