The right way to Ansiblically deploy environments directly from Github:

Question

Can one deploy an environment for some Linux OS (say, Ubuntu) from a raw Github playbook in a way similar to this (I wonder if it's the correct syntax)?

bash <(curl -s https://raw.githubusercontent.com/user/repo/master/nginx-cms-addons.yml | tr -d '\r' | ansible-playbook)

_{Edit: This is my own Github account so there isn't a risk.}

In use a similar pattern to download and execute bash scripts but I want to know if the principle is identical for Ansible playbooks.

If it matters, the environment I want to deploy directly from the Github raw yaml configures Ubuntu a bit (firewall), installs some trivial software like zip, a server environment (Nginx/Postfix) and that's basically it.

My purpose to execute my playbook with ansible as a substitute for the long Bash script I currently use, made of this code, basically:

#!/bin/bash
ufw --force enable && ufw allow 22,25,80,443,9000/tcp
apt-get update -y && add-apt-repository ppa:certbot/certbot -y && apt-get update -y
apt-get upgrade zip unzip tree unattended-upgrades sshguard nginx python-certbot-nginx mysql-server php-fpm php-mysql php-mbstring php-mcrypt -y
DEBIAN_FRONTEND=noninteractive apt-get upgrade postfix -y
sed -i "s/post_max_size = .M/post_max_size = 250M/ ; s/upload_max_filesize = .M/upload_max_filesize = 250M/" /etc/php/*/fpm/php.ini
sed -i "s/;cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/" /etc/php/*/fpm/php.ini
# sed -i "s/# gzip_/gzip_/g" /etc/nginx/nginx.conf
/etc/init.d/php*-fpm restart && systemctl restart nginx.service

Answer 1

There is no "right" or "wrong". If the commands work when you type them in, then they work, and we won't keep you from doing it.

Everything else is opinion. Sure, there are some best practices, for example some people find it unwise to directly fetch scripts from a public (3rd party) website and execute those locally without having a look inside first.

It goes without saying that your approach is in fact a rather significant risk. You are effectively giving root access on the target machine (and any other machine your local user has ssh keys for...) to anyone who can push into your repository. How earnest that risk is is something only you can decide.