同様のシェルスクリプトを使用して、リモートDebianシステムにいくつかの追加機能を含むLAMPを設定しました。
#/bin/bash
apt update -y
apt upgrade ufw sshguard unattended-upgrades wget curl git zip unzip tree -y
ufw --force enable
ufw allow 22,25,80,443
apt upgrade lamp-server^ ssmtp
apt upgrade python-certbot-apache
apt upgrade php-{cli,curl,mbstring,mcrypt,gd} phpmyadmin
curl -sS https://getcomposer.org/installer -o composer-setup.php
php composer-setup.php --install-dir=/usr/local/bin --filename=composer
cat <<-EOF > /etc/php*/conf.d/local.ini
upload_max_filesize = 2000M
post_max_size = 2000M
EOF
a2enmod http2 deflate expires
同様のスクリプトを見た一部のシステム管理者は、「これを行うにはAnsibleを使用することをお勧めします。そうしないと、メンテナンスは悪夢になるでしょう」と言いました。
まあ、私は私が書いた後、Ansible Playbookを使って本質的に同じ効果を得ることができます(現在は無料のマシンがないのでまだテストされていませんが、すべてのマシンにデプロイすると動作するはずです)。
---
- hosts: all
become: yes
become_user: root
tasks:
- name: Update apt package-indexes cache
apt:
update_cache=yes
- name: Install external basics
apt: state=latest
with-items:
- ufw
- sshguard
- unattended-upgrades
- wget
- curl
- git
- zip
- unzip
- tree
- name: Setup firewall with ufw
ufw:
rule: allow
port: 22,25,80,443
- name: Establish a LAPMS server environment (Linux, Apache, PHP, MySQL, SSMTP)
apt: state=latest
with-items:
- apache2 # Web server
- python-certbot-apache
- php
- php-mysql # MySQL server
- php-cli
- php-curl
- php-mbstring
- php-mcrypt
- php-gd
- phpmyadmin
- ssmtp # Email server
- name: Manually install PHP Composer
get_url:
url: https://getcomposer.org/installer
dest: /tmp/composer-setup.php
command: php /tmp/composer-setup.php --install-dir=/usr/local/bin --filename=composer
- name: Configure PHP variables
shell: |
cat <<-EOF > /etc/php*/conf.d/local.ini
upload_max_filesize = 2000M
post_max_size = 2000M
EOF
args:
executable: /bin/bash
- apache2_module:
state: present
name: http2
- apache2_module:
state: present
name: deflate
- apache2_module:
state: present
name: expires
私の考え
上記の小さな例では、純粋なシェルスクリプトに比べて純粋なAnsibleを使用することに大きな利点はないと思います。Ansibleは私たちが指示したとおりに行うだけです。release_upgrades(Apache 2.4から3.4へ)を実行せず、基本的に予約apt upgrade -y
と同じ自動化(例:cron
よく構成されたプログラムであるAnsible-Galaxyロールを使用しない限り、行数ははるかに高くなります(20/21ではなく72行)。
私の質問
上記のマイナーな作業では、Ansible自体(Ansible-Galaxyロールを使用せずに)が通常のシェルスクリプト(特にBash)よりも効率的ですか?
ベストアンサー1
私は1〜2台のマシンのためのシェルスクリプトで、20行が大きな問題だとは思いません。これは良いことです。
言い換えれば、スクリプトはすごいものではありません。たとえば、apt-get upgrade foo
このシステムでスクリプトがすでに実行されている場合でも、変更を実行できます。使用する価値がないと思いますapt-get upgrade foo
。このコマンドは、セキュリティ更新プログラムまたはバグ修正更新が依存関係に適用されることを保証しません。
よく書かれたAnsibleプレイブックは、ミニシステムチェックとしても利用できます。これはプレイブックが凄等的(そして「変更された」状態を正確に報告する)に依存します。ランタイムは、ansible-playbook --check
システムが定義されているすべての操作を満たしているかどうか、または変更が発生したかどうかを示します。これは後で役に立つか、プレイブックを実行した直後に矛盾を見つけるのに役立ちます。
複数のマシンで同時に実行できるようにAnsibleを設定できます。
Ansibleなどの設定ツールは、大規模なアプリケーションに非常に役立ちます。その理由の1つは、これらの特性によるものです。部分的には、これらの制限のためにこれに従うことをお勧めします。
メンテナンス目的にも役立つべき等級スクリプトを作成することをお勧めします。既存のファイルに行を追加する(または既存の行に:-()マーカーを追加するスクリプトを作成しようとしている誘惑を考えてください)。
もう1つの制限は、インストールされているシステムから何かを削除したい場合です。ほとんどの場合、これは問題ではなく、後でアンインストールスクリプト/プレイブックを作成できます。しかし、これに注意しなければならない状況があります。たとえば、Ansibleを使用してlineinfile
個々の行を置き換えるのではなく、ファイル全体を独自のバージョンで上書きしたいとします。これは行Aのデフォルト設定を変更したくないが、行Bは変更を続けたい場合に便利です。
私が使用するためには、ファイアウォール管理時に削除の問題を解決したいと思います。インストールスクリプトでポートの許可を停止すると、どこでもそのポートを明示的にブロックすることを忘れることがあります。 Ansibleufw
モジュールは個々のルールを追加または削除することのみを許可するため、ここでは役に立ちません。私は現在、ufw
プロファイル操作を適切にサポートするファイアウォールを使用するための代替案を検討しています。 (たとえばfirewalld
、、、、shorewall
… ferm
)。