In the article, you're just copying a new magic configuration from somewhere vs. "proper" sed use (in reality, it can be a bit more than that) in the shell script.
In the article, you're just copying a new magic configuration from somewhere vs. "proper" sed use (in reality, it can be a bit more than that) in the shell script.
However, I wanted to show the actual process I went through. Editing the file in place seemed silly to do with Ansible, so I went with putting the config file in version control and copying it over. That also had the benefit of showing how Ansible encourages better practices than shell scripts.
Of course, that's totally subjective, so for some folks that use shell scripts, they may already know to put their config files in version control. However, in practice, I've not seen that be the case.
For instance (I know there's vagrant and stuff), I develop on a Mac but deploy on linux. My sed handles that pretty well.
DigitalOcean ships VM that don't have an admin group. So when I tried DO, I added:
grep -q 'admin' /etc/group || groupadd admin
Or, for changing the sshd port:
sed -i -r 's/^#?Port [0-9]*/Port '"$PORT"'/' /etc/ssh/sshd_config
Works great on all platforms... regardless of the default sshd_config.
And nginx is full of compile options and modules to enable and disable, so maybe "the same config in the same version" does not work on different platforms.
If you're reliant on modules being in there you compile it yourself with a source deb/rpm/etc from nginx. If you don't need a module then don't compile it in.
Does it beat sed? Probably not in the short term, but it makes it easier to not forget to sed a file when deploying (not to mention adding the ability to skip changing the remote file and sighup nginx when the file hasn't changed).
In most cases, we recommend using the 'template' module for this reason, in cases where you know what you'd like to put down for the file contents.