[debops] Philosophical design usage of debops
drybjed at drybjed.net
Sun Sep 6 00:27:40 CEST 2015
On Sep 05, Hendrik Visage wrote:
> Hi there,
Hello and welcome on the list.
> 1) how can I disable ie. all email sending (in my cases, I'll have a
> different HTTPS based server reporting so no emails to be send out)?
If you want to disable Postfix (default SMTP server) in the main DebOps
playbook completely, you can set 'postfix: False' in the Ansible inventory.
For example, to disable it by default on all hosts, create file
'ansible/inventory/group_vars/all/postfix.yml' and inside put:
This will tell the 'debops.postfix' role to not configure itself.
However, on Debian system you will probably end up with an SMTP server pretty
# aptitude why mail-transport-agent
i apticron Depends mailx
i A bsd-mailx Provides mailx
i A bsd-mailx Depends default-mta | mail-transport-agent
apticron is installed by 'debops.apt' Ansible role to manage package updates,
it sends emails about what updates are available on a host. Ironically, on
Debian 'default-mta' depends on 'exim4-daemon-light' which will be installed,
and then removed and replaced by 'postfix' package (Postfix is default on
Ubuntu). Debate on the default MTA in Debian is ongoing:
In DebOps, mails are the primary way of the Ansible roles and system in
general to message the administrator abount important things - for example.
'debops.lxc' and 'debops.openvz' roles require the system kernel to be
upgraded in certain situations and the system needs to be rebooted to achieve
that; however because we are assuming that playbook is executed on production
systems, DebOps does not reboot the hosts automatically - instead an email is
sent to 'root@<domain>' account with information about what's happening and
what you need to do.
Default Postfix configuration sets up the SMTP daemon to not allow for
incoming external mail, and to send the outgoing mail to the default domain
MX. That way if you have one configured properly, you should have received
some interesting messages about pending package upgrades by now.
To summarize - I suggest that you should leave Postfix set up as is, you will
probably end up with an SMTP server sooner rather than later, and it's better
if it's under control.
> 2) When I need to add extra and custom roles, what is the "debops way"
> of integrating them?
> ie. will I have a project.yml playbook that includes/runs the various
> debops playbooks like site.yml?
> or do I do those in separate project.yml playbooks?
DebOps operates in context of the "project directories", each such directory
is some kind of environment - a group of hosts all over the place, or
a specific data center, whatever you specify in Ansible inventory. I usually
sit in the root of this project directory (let's call it $PWD) and run the
commands from there.
'debops' command expects playbooks to be placed either in '$PWD/playbooks/' (I
store temporary ones there, quick tests, and so on), or
'$PWD/ansible/playbooks/' (these are permanent playbooks used in this
project). Similarly roles can be stored in '$PWD/roles/' (temporary roles,
role development) or '$PWD/ansible/roles/' (permanent roles used in this
When you put your playbooks / roles in one of these directories, they are
available in the context of this particular project directory. You can execute
them using 'debops' command, which checks if the first argument you give it is
potentially a playbook stored in one of above directories (+ DebOps own
playbooks/ directory). For example, if you put your playbook as
'$PWD/playbooks/custom.yml', running command:
will execute that playbook. The rest of the arguments given to the script is
passed to 'ansible-playbook' command directly, which supports playbook
chaining. Knowing that, you can chain additional playbooks, although you need
to specify their full name instead:
debops custom playbooks/project.yml
This command will run 'playbooks/custom.yml' and 'playbooks/project.yml' in
> 3) How is an "ansible-playbook project.yml" different from a "debops
> project.yml" execution for a "pure" ansible playbook?
First of all, 'debops' is shorter. :-) In my opinion (which some of the people
share), 'ansible' command should have been called something like
'ansible-task', and 'ansible-playbook' should have been 'ansible' instead.
'ansible-playbook' is used more often, at least by me, so making it shorter is
'debops' script maintains the 'ansible.cfg' configuration file in the project
directory. This allows the environment to be separate from default
'/etc/ansible/ansible.cfg' configuration, and lets you store the main DebOps
playbooks in a central location (by default
~/.local/share/debops/debops-playbooks/) instead of putting them multiple
times in all project directories. Playbooks can be easily kept up to date, and
various Ansible plugins provided in DebOps are easily accessible.
When 'ansible.cfg' has been generated at least once by 'debops' script, you
don't really need to run it again. 'ansible' and 'ansible-playbook' commands
should work without issues. For example, the command:
is equivalent to:
So if you prefer to use 'ansible-playbook' directly instead of 'debops', after
the 'ansible.cfg' configuration file have been generated, you can switch to
Your above example is equivalent, if the 'project.yml' playbook is stored in
the root of the project directory, ie. '$PWD/project.yml'.
> Sorry to ask the newbie questions <blush>
No problem. I realize that the project documentation is still lacking,
especiially the first steps, and I try to bring myself to update it, but it's
hard for me to know what to write about from the beginner perspective, and
there are other things to tend to first. If you want, you could update
/ expand the documentation available on http://docs.debops.org/ by posting
a pull requests to the 'debops/debops-playbooks' repository (if they are about
the main playbook) or 'debops/debops' repository (if they are about scripts).
More information about the debops-users