tanshu 90b1149413 Get the reason for a failed Nextcloud unit, not just the state
The second run of this play stopped at "Wait for the Nextcloud unit to become
active" with:

    {"attempts": 2, "cmd": ["systemctl", "--user", "is-active",
     "nextcloud.service"], "rc": 3, "stdout": "failed"}

The wait itself did the right thing: `failed` is not `activating`, so it stopped
immediately instead of retrying for five minutes. But it sat outside the start
block, so the rescue that pulls status, journalctl and podman logs never ran, and
the failure carried no reason at all.

Move the wait inside "Start Nextcloud" so one rescue covers both, and widen the
diagnostics for the failure that is most likely after an interrupted run:

- `systemctl --user cat` -- the generated unit, which settles what systemd thinks
  it is waiting for when a unit sits in `activating`.
- `podman ps -a --filter name=...` -- a container left behind under this name
  makes `podman run` refuse to start, `Restart=always` retries that into systemd's
  start limit, and the unit ends up `failed` while `podman logs` shows only the
  previous container and explains nothing.

The final message now names that case and the commands that clear it, and points
an `activating`-for-the-whole-budget unit at the generated unit and journalctl
instead.
2026-10-16 11:36:29 +05:30
2025-07-31 11:14:47 +00:00
2024-09-19 06:49:59 +05:30
2020-10-17 12:29:51 +05:30
2024-12-17 17:52:46 +05:30
2020-05-04 17:05:08 +05:30
2026-08-29 12:31:09 +00:00
2024-09-19 06:49:39 +05:30
2020-10-17 12:28:36 +05:30
2024-05-27 13:25:44 +05:30
2020-05-04 17:04:48 +05:30
2023-01-02 12:23:38 +05:30
2026-10-15 21:24:32 +05:30
2026-10-15 16:04:41 +00:00

Ansible Playbooks

A collection of minimalist Ansible playbooks for automating server setups, based on DigitalOcean's Community guides.

*the Initial Server Setup should be your starting point for fresh servers.

Playbook Structure

The playbooks contained in this repository were created for educational purposes, and should serve as a base for you to create your own playbooks and roles.

Although we opt to not use roles, our playbooks follow a distinctive structure to facilitate reuse while keeping them mostly self-contained and straightforward.

For instance, this is how the lemp playbook is structured:

lemp_ubuntu1804
├── files
│   ├── info.php.j2
│   └── nginx.conf.j2
├── vars
│   └── default.yml
├── playbook.yml
└── readme.md
  • files/: directory containing templates and other files required by the playbook.
  • vars/: directory to save variable files. A default.yml var file is included by default.
  • playbook.yml: the playbook file.
  • readme.md: instructions and links related to this playbook.

Getting Started

To set up your Ansible environment, please follow our guide on How to Install and Configure Ansible on Ubuntu 18.04.

Connection Test

From your local machine or Ansible control node, run:

ansible all -m ping -u remote_user

If you're able to get a "pong" reply back from your node(s), your setup works as expected and you'll be able to run both ad-hoc commands and playbooks on your nodes, using Ansible.

Guides

The following guides cover how to use the playbooks you'll find in this repository.

Initial Server Setup

Once you have executed the initial server setup, you can choose from any of the available server setup playbooks:

Web Servers

Applications & CMSs

Containers & K8s

S
Description
Ansible playbooks for Digital Ocean host
Readme
733 KiB
0 Stars 1 Watchers 0 Forks
Languages
Jinja 58%
Shell 32.9%
JavaScript 6.1%
Dockerfile 1.7%
Makefile 1.3%