ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

2年間Ansibleだけ使用したことから学んだ教訓

本日はCorban Raunによって書かれた素晴らしいゲスト記事を紹介させて頂きます。Corban氏は2年間に渡りAnsibleを使用しており、Ansible playbook!の開発を担当しています。

彼は何年も前にLinuxを習い始めてから、システム管理を自動化してきました。さらに詳しく知りたい場合は、Corbanのツイッター (@corbanraun)もしくは彼のウェブサイトでお礼を言ったり、質問をすることができます。前置きはこのくらいにして、Ansibleに関する素晴らしい記事をお楽しみ下さい!

—-
Linuxシステム管理者として、私は構成管理ツールを必死に探してきました。私はPuppet、ChefやSaltStackのような製品を調べてみましたが、選択肢の多さに圧倒され、どのツールを選択すべきか確かではありませんでした。

そこで、私は、うまく機能するものを見つける必要がありましたがら、それでにはそれほど時間があかかりませんでした。すべての既存のツールにはそれぞれ長所と短所があり、構成管理を処理する独自の方法があるっように思えました。この間、私の友人や師匠は、Ansibleと呼ばれるあまり知られていない製品を調べてみるように提案しました。

振り返らない

私はRails 、 DjangoやMeteor のWebアプリケーション、MongoDBのクラスタリング、ユーザー管理、CloudStackのセットアップおよび監視を含むいろいろなプロジェクト、プラットフォームとアプリケーションなど幅広くAnsible だけを2年間に渡り使用してきました。

私は、Amazon、Google及びDigitalOceanなどにクラウドプロバイダや反復可能なプロセスと一貫性のある環境を必要とするタスクやプロジェクトのために(ほとんどすべてと言えますが)、Ansible を使用しています。

DevOps automation ansible

Credit DevOps Reactions – 提供元 DevOps Reactions – Continuous delivery

Ansible 対Puppet、Chef、 Saltstack

私は Ansible を選んだ理由の一つは、完全で不変なサーバーアーキテクチャと設計を維持する能力でした。 後で細かく述べますが、 私がこのポストを書く目的は、他の製品とAnsible を比較や対照することではないのです。オンラインでもそれに関する多くの記事があります。実際に、私がAnsible で気に入っている機能は他の構成管理ツールでも利用できます。

この記事で私は Ansibleの事例、実用的なアプリケーション及びベストプラクティスを提供したいと思っています。Ansibleが皆さんが探していたような価値のある製品であると説得したいと思います。また、Ansibleが皆さんの環境に適したツールであるか否かについてご自身の結論に至ることができると思います。

不変のサーバー·アーキテクチャ

Ansibleで新しいプロジェクトを始める際に、まずは初めに考えることは、アーキテクチャが不変サーバーをサポートするかどうかである。この記事では、不変のサーバアーキテクチャとは、サービスを中断を引き起こすことなく、サーバーを作成、破棄、交換できる能力を意味します。

例えば、サーバーのメンテナンス期間の一部が更新及びサーバにパッチを適用することを含むとします。現在、稼動するサーバーを更新するの代わりに、我々は適用するアップグレードやセキュリティパッチが含むサーバーの複製をスピンアップすることができるはずです。それから、現在稼働中のサーバーを交換したり、破壊することができます。なぜまたはどうしてこれが有益なのでしょうか?新規アップグレードを含む現在の環境と同じ全く新しいサーバーを作成することで、我々は、更新されたパッケージが壊れたり、サービス中断しないと確信することができます。適切なソース管理を使用して、Ansible にサーバー構成がある場合は、不変のアーキテクチャの考えを持ち続けることができます。これにより、文書化されていないような変更を行う可能性がある人たちによって変更されず、純粋にサーバーを維持することができます。

Ansible はすべての変更を集中的に管理することを可能にします。この実現できていない利点としては、Ansible の構成が、マニュアル及び災害復旧のリソリューションのように見えることです。そのいい例がServer DensityのPuppet.についてのブログでご覧いただけます
この不変のアーキテクチャの考え方により、ベンダーに依存しないになる状態になることができ、これは異なるプロバイダ間で使用するAnsible のプレイブックを簡単に書いたり修正することできることを意味します。これにはカスタム·データセンターのレイアウト並びにアマゾンEC2 、 Googleクラウドコンピューティング及びRackspaceのようなクラウドプラットフォームが含まれています。マルチベンダーのAnsible のプレイブックはthe Streisand project.でご覧いただけます。

活用事例

活用事例 #1: セキュリティパッチの適用

Ansibleは信じられないほど強力で堅牢な構成管理システムです。自分のお気に入りの機能とは?それはシンプルであることです。これは、それが脆弱なサーバーにパッチを適用することがいかに簡単であるかで分かります。

例#1: Shellshock

以下のプレイブックは、 100台以上のサーバーに対して実行し、 10分未満でbashの脆弱性に対してパッチを当てました。以下の例では、Debian及びRed Hat Linuxの両方のバリアントを更新します。最初のインベントリ·ファイルに定義されているすべてのホストの半分で実行されます。


- hosts: all
  gather_facts: yes
  remote_user: craun
  serial: "50%"
  sudo: yes
  tasks:
    - name: Update Shellshock (Debian)
      apt: name=bash
           state=latest
           update_cache=yes
      when: ansible_os_family == "Debian"

    - name: Update Shellshock (RedHat)
      yum: name=bash
           state=latest
           update_cache=yes
      when: ansible_os_family == "RedHat"

例 #2: Heartbleed とSSH

以下のプレイブックはHeartBleedの脆弱性に対して、100台以上のサーバーにパッチを適用して実行されました。当時は、私は、サーバーがOpenSSHの更新されたバージョンが必要であることに気づきました。以下の例では、DebianとのRedHat Linuxの両方のバリアントを更新します。これは、パッチを適用し、インベントリファイルで定義されたホストのすべてが更新されるまで、一度にサーバーの25%を再起動します。


- hosts: all
  gather_facts: yes
  remote_user: craun
  serial: "25%"
  sudo: yes
  tasks:
    - name: Update OpenSSL and OpenSSH (Debian)
      apt: name={{ item }}
           state=latest
           update_cache=yes
      with_items:
        - openssl
        - openssh-client
        - openssh-server
      when: ansible_os_family == "Debian"

    - name: Update OpenSSL and OpenSSH (RedHat)
      yum: name={{ item }}
           state=latest
           update_cache=yes
      with_items:
        - openssl
        - openssh-client
        - openssh-server
      when: ansible_os_family == "RedHat"
  post_tasks:
    - name: Reboot servers
      command: reboot

活用事例 #2: 監視

私がAnsibleを使用した最初のプロジェクトの一つは、同時に監視ソリューションを展開し、削除することでした。プロジェクトは簡単でした: Zabbixのを削除し、Server Densityと交換してしました。これはAnsibleのおかげで、信じられないほど簡単でした。私自身がこのプロジェクトを楽しみ、私はそれをオープンソース化しました。

私の好きなAnsibleの一つは、プレイブックを書くのが簡単でありながら、改善する余地があることです。Server DensityのAnsibleのプレイブックは、私が一年以上前から始めたオリジナルコードの改訂した結果です。私は継続的に再検討し、新たな知識とAnsibleの最新バージョンでリリースされている追加の機能を使ってアップデートしてしました。

その他すべて

クラウドインフラストラクチャのプロビジョニング、アプリケーション·コードの装備、 SSHキーの管理、データベースの構成、およびWebサーバを設定のようにこの記事に述べたように、Ansibleはより多くの活用事例があります。Ansibleを使用する私のお気に入りのオープンソースプロジェクトの一つはStreisandと呼ばれています。StreisandプロジェクトはAnsibleが複数のクラウド·プラットフォームとデータセンターインフラストラクチャで使用することができる方法の良い例です。VPNサービスを設定のような困難なことを、苦もなく、反復できるプロセスを変えるこがいかに簡単なのかを示しています。既にPuppet やSaltStackのような製品を使っていますか? 他の構成管理ツールと同様にAnsibleを使用する利点を見つけることができます。エージェントを再起動する必要がありますか?Ansibleはエージェントレスであるので、このように実行することができます:


ansible -i inventories/servers all -m service -a "name=salt-minion state=restarted" -u craun -K --sudo

コマンドラインからエージェントを再起動します。また、他の構成管理ツールで必要なエージェントをインストールするためにAnsibleを使用することができます。

ベストプラクティス

過去数年間でAnsibleを使用して、私は皆さんがを試してみる価値がある役に立ちそうなことを学びました。

できるだけAnsibleのモジュールを活用する

私が最初にAnsibleを使い始めた時、かなり定期的にコマンドとシェルのモジュールを使用していました。私はBashで自動化することに慣れていたので、古い習慣に陥いってしまうことが容易でした。Ansibleは非常に使いやすいモジュールがたくさんあります。

しばしばプレイブックの` コマンド’と`シェル `のモジュールを使用する場合は、より良い方法がある可能性があります。まずはAnsibleが提供するモジュールに精通することから始めましょう。

自分の役割をモジュール形式にします(再利用可能)

私は、すべての新しいアプリケーションスタックまたはプロジェクトに対して別々のAnsible プロジェクトのフォルダを持っていました。 私はある一つのプロジェクトから別のプロジェクトへ、全く同じ役割をコピーして、軽微な変更を(例えば、 Nginxの設定やバーチャルホストファイル)加えていたことに気づきました。私は基本的に同じステップを繰り返して、非効率的で面倒であったと気づきました。私は雇用者を変更してチームメートから学ぶまで、プロジェクトを設定するもっと良い方法があることを知りませんでした。例えば、AnsibleではJinja2を使用して、テンプレートを作ることができます。以下のnginx vhost のテンプレートで、 Nginxの役割があったとします。:

server {
  listen 80;

  location / {
    return 302 https://$host$request_uri;
  }
}

server {
  listen 443 ssl spdy;
  ssl_certificate    /etc/ssl/certs/mysite.crt;
  ssl_certificate_key    /etc/ssl/private/mysite.key;
  server_name www.mysite.com 192.168.1.1;

  location / {
    root   /var/www/public;
    index  index.html index.htm;
  }
}

この上の事例が適当ですが、変数を足してモジュールを活用することができる。


server {
  listen 80;

  location / {
    return 302 https://$host$request_uri;
  }
}

server {
  listen 443 ssl spdy;
  ssl_certificate    {{ ssl_certificate_path }};
  ssl_certificate_key    {{ ssl_key_path }};
  server_name {{ server_name }} {{ ansible_eth0.ipv4.address }};
  location / {
    root   {{ web_root }};
    index  index.html index.htm;
  }
}

そして、同じNginxのロールを使いながら、この変数をたくさんのプレイボークに変更できます。


- hosts: website
  gather_facts: yes
  remote_user: craun
  sudo: yes
  vars: 
    ssl_certificate_path: "/etc/ssl/certs/mysite.crt"
    ssl_key_path: "/etc/ssl/private/mysite.key"
    server_name: "www.mysite.com"
    web_root: "/var/www/public"
  roles:
    - nginx

テスト、リンス、繰り返し

test-rinse-repeat

Credit DevOps Reactions - 提供元 DevOps Reactions – Writing Unit Tests

変更点をテストし、何度もテストを繰り返して下さい。変更点のテストの実践と考え方は新しいものではありません。しかしながら、システム管理者と開発者の両方が同じアーキテクチャの異なる部分への変更を行っている際は、テストの修正が困難になることがあります。私がAnsibleを選んだ理由の一つは、従来のシステムの管理者と開発者の両方で使用し、理解できる能力です。これはまさに開発オペレーションのツールです。

例えば、 HashiCorpのVagrantのようなツールでAnsibleを統合するのは信じられないほど簡単です。ツールを組み合わせることで、皆さんと皆さんの開発者が、製作中のもので、ローカル環境で繰り返して、テストできるかを確信持てるようになります。これは構成のトラブルシューティングやアプリケーションの変更において極めて重要です。これらのツールで変更点ををテストすれば、皆さんが変更により何かを壊してはいないということに、より自信を持てるようになります・(不変という意味を覚えていますか? ) 。

それでは、何をすべきか?

前述したように、私の目的は他の製品とAnsible を比較することではありませんでした。既に他の構成管理ツールを持っている環境で、その用途を見つけることができます。また他の製品でも私が述べた機能は利用することができます。

この記事を通じて、Ansibleがサーバーアーキテクチャにおいてなぜ役に立つのかご理解頂けたと思います。もし、この記事からひとつだけ要点を取り出すとしたら、こういうことになります。Ansibleを使用すれば、思い通りにサーバーアーキテクチャを維持し、管理することができ、自動化を開始するのにいいツールであるということです。