tanshu
1038037e45
The real first run of this play did not fail on a transition. The journal shows
the entrypoint dying on every attempt:
nextcloud[302063]: => Configuring PHP session handler...
nextcloud[302063]: /entrypoint.sh: 121: cannot create
/usr/local/etc/php/conf.d/redis-session.ini: Permission denied
With REDIS_HOST set, the entrypoint generates PHP's session-handler config on
every start, and the target directory belongs to the image's root: the php base
image does `mkdir -p "$PHP_INI_DIR/conf.d"` with no chown. The uid this container
runs as has no write bit on it, the entrypoint exits 2 before Apache is reached,
Restart=always retries that, and systemd's start limit turns it into a `failed`
unit. Nothing in that shape says "permissions": the symptom is a unit state and a
message that only exists in journalctl.
The container now mounts a host-owned file over that exact path. A bind-mounted
file replaces the directory entry, so the directory's ownership stops mattering
and the write lands on podman_user. The role templates the five lines the
entrypoint would have written, so a refused write is no longer fatal either --
PHP still gets Redis sessions instead of a crash loop.
This also corrects a reading of the previous run that this play got wrong and
documented wrongly: `activating` is not evidence of a healthy start. A
crash-looping container spends its time `activating` between restarts, so the
earlier "reports a healthy start as a failure" comment and commit message were
describing a start that was in fact failing. The wait is still right -- it stops
promptly at a terminal state and hands over to a rescue that has the logs -- but
its comment now says what it actually buys.
Apache's own runtime directories need none of this, and the php base image is why:
it chowns /var/run/apache2, /var/lock/apache2 and /var/log/apache2 to www-data and
chmods them 1777, so only the session file was ever going to bite. The readme
gains a section on it, the diagnostic commands the play now collects, and a note
that the uid mapping is not to be derived from a `docker exec id -u` of 0.
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