If you changed the sudoer password hash in group_vars/<environment>/vault.yml, then what you’ve said sounds right, because the task right before the failed task is the Setup users task, which would be the one to update the sudoer password hash on the server. I’ll explain.
With root login disabled, you would have had to pass the admin_user sudoer password to the ansible-playbook command using the option --ask-become-pass. You probably passed in the old sudoer password, which would still have been in effect on the server and would have worked for all tasks up till the point the password hash was changed in the Setup users task. Then the next task would fail because Ansible was still trying to use the sudoer password passed to --ask-become-pass, which was suddenly out-of-date.
My guess is that the playbook will run completely and successfully if you run it again, but this time pass in the new sudoer password with --ask-become-pass.
Changing the sudoer password hash is appropriate given that you were enabling vault and wanted the newly encrypted vault.yml file to have a new hash that wasn’t in plain text in your git history.
However, changing an existing password for a sudoer while connecting as that same sudoer does present the complication you experienced here. It’s not a scenario I’ve considered before. I suppose a person who wants to change the sudoer password after root login is disabled has four options after changing the sudoer password hash in group_vars/<environment>/vault.yml.
First, you could take your approach of just running server.yml, having to enter the old sudoer password with the --ask-become-pass, then just let the playbook fail right after the password is changed, as you experienced. Then just use the new password with Ansible commands going forward (with --ask-become-pass).
Second, an alternative would be to change back to sshd_permit_root_login: true and run the sshd role of server.yml to apply that change (e.g., ansible-playbook server.yml -e env=<environment> --tags sshd). Then run the users role, which will change the sudoer password. It will connect as root now, so no need for --ask-become-pass (e.g., just run ansible-playbook server.yml -e env=<environment> --tags users). Then finally, change back to sshd_permit_root_login: false and apply the change by running the sshd role again. That’s a bit of a hassle in effort to avoid seeing the failed task that you saw.
Third, an alternative would be to change the hash manually by ssh-ing into the server (and still change it in your group_vars/<environment>/vault.yml of course).
I guess a fourth alternative would be to back up and database, uploads, etc. (if you even need them), then rebuild the server completely, this time with the new sudoer password hash, of course.
You’re right that it is only deploy.yml that uses web_user, but that user must be set up first before it can be used. The user setup takes place in server.yml, in the users role where you saw the failed task.
