tanshu
be53cec757
The playbook is meant to be usable on its own, on any host, the way every other one here is: the first run creates the container, and every run after that converges it. It had picked up a migration shape instead -- a readme that assumed a webroot copied in from monoco, a warning that nagged when config.php was missing, and, worse, readiness gates that only passed for an instance that was already installed. That last one was a real bug for the intended use. On a host with no webroot, the image initialises the code, writes no config.php because it has no admin credentials to install with, and serves the setup wizard -- so `occ status` never reports installed: true, and the play would have spent its whole retry budget and then failed on a first run that was going exactly as designed. What replaces it: - The readiness gate is Apache answering status.php inside the container, which is Nextcloud's own endpoint and reports `installed` either way. It is the one thing `is-active` cannot tell us, and it passes for a wizard that has not been completed. - config.php's presence then decides the report: wait for maintenance mode to clear and print `occ status` for an instance, or say what is left for a human to do for a fresh one -- and succeed. The two optional credentials in vars/default.yml install unattended instead, in which case the same endpoints come back installed and the wizard note never appears. - The app creates its own database. Postgres is a shared unit with one default database and nothing else in this repo knows this app's database name, so a fresh cluster previously reached the installer and failed on "database nextcloud does not exist". It is a lookup and a `createdb`, a no-op afterwards, and it fails with the instruction to run postgres/playbook.yml if the cluster is not there rather than with a bare psql error. - Updates. An update in a Quadlet deployment is "pull, then recreate": the unit names a tag, `podman run` reuses the local image, and nothing fetches a newer one. The role pulls on every run and compares the image ID either side, so an unchanged tag is not a change and a running site is not restarted for nothing. - Handlers are flushed before verification, so a queued recreate -- new image, changed unit, changed environment -- happens before the checks rather than after them, and the checks describe what will keep running. Removed: the entire monoco migration section and its copy commands, the config.php warning that existed only to serve it, the host-specific notes, and the narrative comments about this play's first runs. References to the audit and migration planning docs go with them; the ownership reasoning is stated inline, since it does not depend on where an instance came from. `hosts:` is now the only host-specific thing in the directory. The readme is rewritten around the two paths it now has -- "First run" and "Updates" -- with the deploy order, the session-file trap and the debugging commands kept.
Ansible Playbooks
A collection of minimalist Ansible playbooks for automating server setups, based on DigitalOcean's Community guides.
- Initial Server Setup for Ubuntu 18.04 *
- Apache on Ubuntu 18.04
- Postgres on Ubuntu 19.10
- Redis on Ubuntu 19.10
- Bitwarden Ubuntu 19.10
- Gitea on Ubuntu 19.10
*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. Adefault.ymlvar 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
- Apache on Ubuntu 18.04
- LEMP (Linux, Nginx, MySQL, PHP) on Ubuntu 18.04
- LAMP (Linux, Apache, MySQL, PHP) on Ubuntu 18.04