2 ansible playbooks #6
Conversation
playbooks/.env.example
Outdated
| @@ -0,0 +1,4 @@ | |||
| # Those variables needs to be set on the server when accessed via SSH | |||
| # I.e. they will need to be in the .bashrc (or equivalent) file | |||
There was a problem hiding this comment.
Is it possible to load from an adjacent .env instead? If so I think we should adopt it as convention
There was a problem hiding this comment.
Using .env files seems a bit tricky, since Ansible is run over SSH and every tasks has its own shell. According to this post, we could manually parse a .env file and save its content into a variable, but it seems a bit dirty imo.
There was a problem hiding this comment.
I think we should set those variables in the inventory.yaml, what do you think ?
playbooks/deploy.yaml
Outdated
| hosts: all | ||
| tasks: | ||
| - name: Deploy | ||
| loop: "{{ [] }}" |
There was a problem hiding this comment.
Info: what does this loop directive do?
There was a problem hiding this comment.
It executes the task for every item in the loop. Currently the loop is empty, but we'll fill it when we add services. The items of the loop are accessed with "{{ item }}"
There was a problem hiding this comment.
We may want to automate the loop at some point. See the find module
playbooks/init.yaml
Outdated
| - role: borgbase.ansible_role_borgbackup | ||
| borg_repository: "{{ ansible_env.BACKUP_DIR }}" | ||
| borgmatic_timer: cron | ||
| borgmatic_timer_hour: 0 | ||
| borgmatic_timer_minute: 0 | ||
| borg_source_directories: | ||
| - /var/lib/docker/volumes | ||
| borgmatic_hooks: | ||
| before_backup: | ||
| - echo "`date` - Starting backup." | ||
| postgresql_databases: | ||
| borg_retention_policy: | ||
| keep_hourly: 3 | ||
| keep_daily: 7 | ||
| keep_weekly: 4 | ||
| keep_monthly: 6 |
There was a problem hiding this comment.
Info: what is a role in the context of ansible? It it mapped to a specific UNIX user or role?
Also, are we sure that backing up all volumes directly (i.e. from the filesystem) is safe w.r.t to consistency and integrity? See the PostgreSQL docs for instance:
An alternative backup strategy is to directly copy the files that PostgreSQL uses to store the data in the database; Section 19.2 explains where these files are located. You can use whatever method you prefer for doing file system backups; for example:
tar -cf backup.tar /usr/local/pgsql/data
There are two restrictions, however, which make this method impractical, or at least inferior to the pg_dump method:
The database server must be shut down in order to get a usable backup. Half-way measures such as disallowing all connections will not work (in part because tar and similar tools do not take an atomic snapshot of the state of the file system, but also because of internal buffering within the server). Information about stopping the server can be found in Section 19.5. Needless to say, you also need to shut down the server before restoring the data.
If you have dug into the details of the file system layout of the database, you might be tempted to try to back up or restore only certain individual tables or databases from their respective files or directories. This will not work because the information contained in these files is not usable without the commit log files, pg_xact/*, which contain the commit status of all transactions. A table file is only usable with this information. Of course it is also impossible to restore only a table and the associated pg_xact data because that would render all other tables in the database cluster useless. So file system backups only work for complete backup and restoration of an entire database cluster.
There was a problem hiding this comment.
For the databases we'll use the dedicated hooks (like the empty postgresql_databases on line 51). I forgot that databases would also be there, so I will restrict the source directories to the non-databases volumes (we'll fill it when adding services).
playbooks/init.yaml
Outdated
| - docker | ||
| - cron |
There was a problem hiding this comment.
See if we need to list these deps explictly. We may need to setup git
- Fix variable names to be extracted from inventory - Check borg repository existence before creation - Fix BorgBackup inclusion to avoid multiple runs of the task
- Add task to install required packages - Improve backup repository checks - Decrease backup retention policy
- Move all docker operations to deploy.yaml - Add missing packages - Use explicit services list for loop
Thechi2000
force-pushed
the
2-ansible-playbooks
branch
from
6753a07 to
c653ad7
Compare
playbooks/init.yaml
Outdated
| - ansible-core | ||
| - docker.io | ||
| - borgbackup | ||
| - python3-docker | ||
| - python3-jsondiff |
There was a problem hiding this comment.
Consider commenting what task requires each package
Closes #2