Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ansibleはじめよぉ -Infrastructure as Codeを理解-

4,284 views

Published on

■Description
Ansible実践ガイド -入門編-
http://amzn.asia/ebi7wIz
※上記の書籍内容に基づいて作成を行っています。

■Target
・これからAnsibleを学びたい方
・Ansibleとは何かを知りたい方
・Ansibleと他の構成管理ツールとの違いを知りたい方

Published in: Technology

Ansibleはじめよぉ -Infrastructure as Codeを理解-

  1. 1. Ansibleはじめよぉ。 Hewlett Packard Enterprise Japan, Ltd Shingo.Kitayama - Infrastructure as Code -
  2. 2. 2 自己紹介 元楽天株式会社 所属 国際ECサービスのインフラ部門 好評発売中 http://amzn.asia/ghfpKwi 2016年末「Ansible実践ガイド」執筆 経歴など shkitayama spchildren Shingo.Kitayama 日本ヒューレット・パッカード株式会社 所属 テクノロジーコンサルティング事業統括 クロス・インダストリ・ソリューション統括本部 テクノロジーアーキテクト部
  3. 3. 3 Agenda 1. Infrastructure as Codeの背景 2. Ansibleとは 3. Ansibleのアーキテクチャ 4. 継続的インテグレーションへの展開 5. HPEにおけるAnsibleの取り組み
  4. 4. Infrastructure as Codeの背景 4
  5. 5. 従来の構成管理における課題 5 構成管理DB (CMDB) InstallInstall ・機器情報 ・変更情報 ・属性情報 情報更新 手順書 従来の構成管理 従来のオンプレミス環境におけるインフラ構築作業は、エ ンジニアが複雑なオペレーションを実施し、一度構築した ものは保守期限が切れるまで長期的に利用し続けていた。 ・ミドルウェアのクラスタ構築 ・数百台のOS初期設定やインストール ・運用における変更管理 ・CMDBの手動更新 など クラウドが登場し、インフラリソースのライフサイクルが短くなると、 構築/運用コストが肥大化する傾向にある。 仮想化による物理的な制約がなく なり管理が複雑化
  6. 6. 構成管理ツールの必要性 6 Install Install 構成管理ツール 動的機器情報取得 Cloud Platform 状態の管理 API Code 構成管理ツールによる管理 オペレーション自動化における構成管理ツールの役割りは、 情報を動的に取得して、意図する状態にシステムを収束さ せること。 ・機器の構成情報はクラウドが提供するAPIによって取得 ・状態を管理するためには、動的な管理が可能 プログラマブルな構成管理ツール、 Infrastructures as Codeに注目が集まっている。
  7. 7. Infrastructure as Codeとは 7 Infrastructure as Code 手作業で行っていたインフラの構築や変更作業をコードで定義し、自動化すること。 ソフトウェア開発で実施されてきた開発プロセスをインフラシステム、アプリケーション、ミ ドルウェアのデプロイメントやコンフィグレーションの管理に適用。 つまり、インフラリソースをコードで操作するということは、 そのコード自体が「品質管理」「バージョン管理」「テスト」の対象となるということ 継続的インテグレーション バージョン管理 バージョン管理シ ステム CI Server Build Test Check 構成管理ツール Feedback Commit 自動化(デプロイ/テスト) Development CI/Test Code
  8. 8. Infrastructure as Codeのメリット 8 オペレーション工数の削減 従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮 が期待できる。 オペレーション品質の向上 作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。 システム運用の標準化の促進 自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。 また、コードを再利用することにより無駄を排除し、継続的インテグレーションやデリバリを実現できる。 作業統制の強化 作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できる。 Infrastructure as Codeを適用することでアジリティの高いサービスを提供
  9. 9. Infrastructure as Codeの適用範囲 9 Application Service Deployment Configuration Management システムの構成管理 Bootstrapping ブートストラッピング System Configuration Cloud or VM Image Launch OS Install Application Platform … Capistrano, Fabric, Serf, Consul etc. CFEngine, Puppet, Chef, Itamae etc. Orchestration アプリケーション デプロイメント 参照 : velocity-mar2010 「Open Source Provisioning Toolchain」 AWS, Cobbler, Kickstart, VMware, Docker 各ツールは、Provisioning Toolchainによって分類されている。
  10. 10. Ansibleとは 10
  11. 11. Ansibleとは 11 Ansible システムオペレーションの自動化を提供する、Python製 の構成管理ツールです。 オンプレミスのシステムから、パブリッククラウドまで マルチベンダー連携が可能であり、大手金融機関や大規 模製造業を中心とした採用も多く、飛躍的に認知度が上 がっている。 2012 - 開発Project開始 2013 - Ansible.Inc設立 2015 - RedHat.IncがAnsible.Incを買収
  12. 12. Ansibleの特徴 12 ・YAML形式で読みやすく 書きやすい。 ・属人化しにくい ・学習コストが低い Simple ・エージェント導入コスト がない ・SSH接続のため安全 Agentless ・多数のベンダー機器に対 応 ・マルチレイヤ対応 ・同時実行可能 Powerful Ansibleには、Simple, Agentless, Powerfulの3つの特徴がある。
  13. 13. Ansibleの特徴 - Simple - 13 Ansible(YAML)の表記 apache_setup_playbook.yml --- - name: Install Apache yum: name: httpd when: ansible_distribution == 'CentOS' - name: Configure Apache template: src: httpd.conf dest: /etc/httpd/conf/httpd.conf - name: Start Apache service: name: httpd state: started enabled: yes Chef(Ruby)の表記 apache_setup_recipe.rb case node[‘platform’] when “centos” package ‘httpd’ do action: install end end template “httpd.conf” do path “/etc/httpd/conf/httpd.conf” source “httpd.conf.erb” end service “httpd” do supports :status=>true, :restart=>true, :reload=>true action [ :enable, :start ] end YAML形式は読みやすく書きやすいため、学習コストが低く、属人化しずらい。
  14. 14. Ansibleの特徴 - Agentless - 14 処理対象サーバー 管理サーバー Agent型 Agentless型 Agent 全ての変更対象サーバーにエー ジェントのインストールが必要 処理対象サーバー 管理サーバー Agent不要 変更対象サーバーの設定が容易 Agent Agent Agentless型のプロダクトは、エージェントの導入コストがない。
  15. 15. Ansibleの特徴 - Powerful - Application Service Deployment Configuration Management システムの構成管理 Bootstrapping ブートストラッピング System Configuration Cloud or VM Image Launch OS Install Orchestration アプリケーション デプロイメント Ansible “Automation for Everyone” Infrastructure as Codeの対象範囲全てのレイヤに対応している。(マルチレイヤ対応) 商標: それぞれのロゴは、各社/組織団体の登録商標です。
  16. 16. Ansibleの特徴 - Powerful - 16 多数のベンダー機器にも対応している。(マルチベンダー対応)
  17. 17. (補足) Moduleのサポートに関して 17 コアチームが管理を維持し、常に安全な状態で出荷されるモジュールです。また、すべての要求に対して優先順位が高 くなります。 他の企業によって提出されたり、コミュニティによって維持されるモジュールです。モジュールの管理者は、報告された問題 やモジュールに対して発生した要求を監視する必要があります。 コアチームまたはモジュールに関連付けられた企業/パートナーによってサポートされていないモジュールです。これらはコ ミュニティによって維持されます。 問題への対応は、全てコミュニティに依存します。ベストエフォートでのサポートは提供されますが、サポート契約の対象と はなりません。 Core Curated Community Ansibleは数多くのモジュールを提供しますが、各モジュールごとにサポートの内容が異なります。
  18. 18. 処理対象サーバー処理対象サーバー 他の構成管理ツールとのアーキテクチャ比較 18 (1)変更内容を定義 (2)変更対象に送信 (3)変更実施 (1)変更内容を定義 (2)定期的に 変更有無を問い合わせ (3)変更があれば更新 管理サーバー 管理サーバー Push Architecture Pull Architecture ・シンプルな仕組み ・コントロールの柔軟性 ・配布のスケーラビリティ ・完全自動化 「Push Architecture」と「Pull Architecture」があり、AnsibleはPush Architectureを採用している。
  19. 19. 他の構成管理ツールとの比較表 19 Puppet Chef Ansible 基本構成 ツールの使用言語 Ruby Ruby Python ライセンス Apache License Ver2.0 Apache License Ver2.0 GNU Public License Ver3 開発組織 Puppet Labs Chef Software RedHat(旧Ansible.Inc) 開発開始年度 2005年 2009年 2012年 アーキテクチャ 基本構成管理方法 Pull型 (Agent型) Pull型 (Agent型) Push型 (AgentLess型) 実装 コード管理名称 manifest(マニフェスト) recipe(レシピ) playbook(プレイブック) コード記述言語 独自言語(外部DSL) Ruby(内部DSL) 複雑な処理表記が可能 YAML 書式がとてもシンプル 処理実行順序 コンパイル時に決定される ※記述順通りにはならない おおよそプログラムの記述順 プログラムの記述順 その他 システム情報の取得 附属ライブラリ(Facter)によって取 得 附属ライブラリ(Ohai)によって取得 附属モジュール(setup)により取 得 GUIツール Puppet Dashboard Puppet Enterprise(有償) Chef Server ansible-semaphore Ansible Tower(有償)
  20. 20. Ansibleが注目されている理由 20 Ansibleが最も重視している点は、開発組織の共通言語としての役割りであり、DevOpsの課題を「Simple」 という特徴で補っている。 Sharing Measurement Culture Automation コミュニケーションを推進するた めのイノベーションを引き起こす こと 互いに学び成長できるよう、経験 を共有すること フィードバックを得ながら、成果 を計測し、開発サイクルに活用す ること 各プロセスにおける手作業の処理 をなくしていくこと Ansible 開発組織の共通言語
  21. 21. Ansibleのアーキテクチャ 21
  22. 22. Ansible Core Engine Ansibleのコンポーネント 22 Ansible CLI Modules Python API Playbook Inventory PluginInterface Connection Type Plugin Callbacks Plugin Ansibleの各コンポーネントは、インストール時にCore Engineに組み込まれている。 再利用可能な処理ユニット。作業をラッピ ングしたコンポーネント Ansibleのコア機能を拡張する ためのコンポーネント Ansibleを操作するためのイン ターフェイス
  23. 23. Ansible Core Engine Ansibleのコンポーネント Ansible CLI Modules Python API Playbook Inventory PluginInterface Connection Type Plugin Callbacks Plugin Ansibleの各コンポーネントは、インストール時にCore Engineに組み込まれている。 再利用可能な処理ユニット。作業を ラッピングしたコンポーネント Ansibleのコア機能を拡張 するためのコンポーネント Ansibleを操作するための インターフェイス ユーザーが作成するのは、 「Inventory」と「Playbook」の2つのファイル 23
  24. 24. Inventory 24 Inventoryとは、処理対象サーバの接続情報を記載したファイルです。 [web_servers] web-01 ansible_host=192.168.101.1 web-02 ansible_host=192.168.101.2 web-03 ansible_host=192.168.101.3 [db_servers] db-01 ansible_host=192.168.201.1 db-01 ansible_host=192.168.201.2 inventory.ini all web_servers db_servers 192.168.101.1 192.168.101.2 192.168.101.3 192.168.102.2 192.168.102.1 環境に合わせて処理対象サーバをグループ化することができる。
  25. 25. Playbook 25 Playbookとは、一連の作業を順序立てて定義するファイルです。 --- - hosts: web_servers vars: apache_conf: /etc/httpd.conf tasks: - name: Install Apache yum: name: httpd - name: Configure Apache template: src: httpd.conf.j2 dest: “{{ apache_conf }}” - name: Start Apache process systemd: name: httpd state: started site.yml Target Section web_serversグループに適応 Vars Section apache_confの変数定義 Tasks Section (1) Apacheのインストール - yumモジュールの利用 (2) Apacheの設定 -templateモジュールの利用 (3) Apacheプロセスの開始 -systemdモジュールの利用 上から順に実行される。
  26. 26. Ansibleの仕組み 26 Ansibleサーバ 処理対象サーバ (1)処理対象サーバの選定 (2)Python実行コードに変換 (3)プログラム転送 (sftp) PlaybookInventory Ansible (4)プログラム実行 (5)Python実行コード削除 (1) Inventoryから処理対象を選定 (2) PlaybookをPython実行コードに変換 (3) 実行コードをSFTPで転送 (4) 処理対象サーバ側でコードを実行 (5) 実行コードの削除 Ansibleでは、実行処理をはじめる前にAnsibleサーバ側で実行コードに変換しています。 Python Code 実行処理順序
  27. 27. AnsibleのクラウドAPI連携 27 Setup Install Public Cloud Platform 各クラウドAPIを操作するためのモ ジュールが用意されている。 Setup Install Public Cloud Platform Private Cloud Platform Install Cloud Modules Bridge Bridge Ansibleが各クラウドAPIを統括的にコントロール Playbook Ansible API APIAPI AnsibleのクラウドAPI連携により、ハイブリッドクラウドの実現をサポートする。 商標: それぞれのロゴは、各社/組織団体の登録商標です。
  28. 28. 継続的インテグレーションへの展開 28
  29. 29. 29 継続的インテグレーション バージョン管理 バージョン管理シ ステム CI Server Build Test Check 構成管理ツール Feedback Commit 自動化(デプロイ/テスト) Development CI/Test Code コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト AnsibleとCIパイプライン Playbookをバージョ ン管理システムに保 存 各Playbookタスクの 単体テストを実施 作成したVMのテンプ レート化や、コンテナ のテンプレート化 Ansibleにより、デプロ イメントを実施 デプロイメントした環 境の機能テストを実 施 CIパイプラインにおいて、Ansibleはデプロイメントを実施する役割りを担っている。
  30. 30. デプロイ テスト 30 バージョン 管理システム 開発成果物 管理システム チェックアウト アプリケーション Infrastructure as code アプリケーション エンジニア インフラ エンジニア アプリケーション開発 構成管理の自動化 コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト Continuous Integration CIツール 開発成果物の展開 機能/結合テスト アプリケーション 単体テスト application code ビルド/テスト 自動化ツール IaaS CIパイプラインと役割り イメージ化 VMテンプレートの管理
  31. 31. 31 コードレポジトリ ・GitHub Enterprise ・Bitbucket ・GitLab CIツール ・Jenkins ・Circle CI ・Travis CI ・Concourse CI 成果物レポジトリ ・Jfrog Artifactory ・Github Enterprise ・Docker Trusted Repository ・GitLab PaaS ・Cloud Foundry ・Heroku ・Bluemix Container Orchestration ・Docker Datacenter ・Mesosphere ・Kubernetes 構成管理の自動化 ・Ansible ・Chef ※凡例 手動タスク 自動化タスク 機能テストツール ・UFT ・Selenium ・Appium ・JMeter コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト開発環境 CI環境 ステージング環境 QA環境 本番環境 利用ツール例 デプロイ 機能テスト コード 反映 コード 反映 デプロイ リリース Issue Tracking ・JIRA ・Redmine Promote Promote 開発成果物の管理 開発成果物の管理 CI/CDのプラットフォーム選択 デプロイメントのプラットフォーム選択がCI/CDのプロセスに大きく影響を及ぼす。 アプリケーションのアーキテクチャおよび 非機能要件/運用要件によって選択
  32. 32. HPEにおけるAnsibleの取り組み 32
  33. 33. OneViewによるプログラマブルインフラストラクチャ 33 ITインフラの統合管理と自動化を推進「HPE OneView」 HPE OneViewは、サーバーのみならず、ストレージ、ネットワークまでITインフラストラクチャ全体を構成するハードウェアの統合的な管理を実現 します。REST APIを介してOpenStack、Microsoft、System Center、VMware vCenterをはじめとする様々なソフトウェアと連携し、サービス、ソ フトウェア、ハードウェアまで一気通貫した運用が可能になります。HPE OneViewは、「インフラストラクチャの自動化ハブ」としての機能を強化 し進化し続けています。
  34. 34. 34
  35. 35. 35
  36. 36. 36
  37. 37. Ansible教育サービス 37 コース内容 1. Ansibleの概要 2.Ansibleの基礎 3.プレイブックの文法 4.Linux初期セットアップの自動化 5.アプリケーションデプロイメント 6.Ansibleの活用 Ansible実践入門 -Infrastructure as Codeを理解- http://h50146.www5.hpe.com/services/education/teiki/seihin/H0LT0S.html
  38. 38. 38 Enjoy Ansible Thank you
  39. 39. 本資料に関するお問い合わせ 39 Shingo.Kitayama Mailto: shingo.kitayama@hpe.com Ansibleは、米国およびその他の国において登録されたRed Hat, Inc.の商標です。 その他、本資料で記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。 本資料に関しては、お気軽にお問い合わせ下さい。 また、内容に関しては個人の意見に基づくものであり、十分考慮の上ですが、所属組織団体の公式見解とは異なる場合 がございます。 何卒、ご了承下さい。 商標

×