ansibleはじめよぉ -infrastructure as codeを理解-

39
Ansibleはじめよぉ。 Hewlett Packard Enterprise Japan, Ltd Shingo.Kitayama - Infrastructure as Code -

Upload: shingo-kitayama

Post on 11-Apr-2017

1.456 views

Category:

Technology


4 download

TRANSCRIPT

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

Ansibleはじめよぉ。Hewlett Packard Enterprise Japan, LtdShingo.Kitayama

- Infrastructure as Code -

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

2

自己紹介

元楽天株式会社 所属国際ECサービスのインフラ部門

好評発売中

http://amzn.asia/ghfpKwi

2016年末「Ansible実践ガイド」執筆

経歴など

shkitayama spchildren

Shingo.Kitayama

日本ヒューレット・パッカード株式会社 所属

テクノロジーコンサルティング事業統括クロス・インダストリ・ソリューション統括本部テクノロジーアーキテクト部

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

3

Agenda

1. Infrastructure as Codeの背景

2. Ansibleとは

3. Ansibleのアーキテクチャ

4. 継続的インテグレーションへの展開

5. HPEにおけるAnsibleの取り組み

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

Infrastructure as Codeの背景

4

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

従来の構成管理における課題

5

構成管理DB(CMDB)

InstallInstall

・機器情報・変更情報・属性情報

情報更新

手順書

従来の構成管理

従来のオンプレミス環境におけるインフラ構築作業は、エンジニアが複雑なオペレーションを実施し、一度構築したものは保守期限が切れるまで長期的に利用し続けていた。

・ミドルウェアのクラスタ構築・数百台のOS初期設定やインストール・運用における変更管理・CMDBの手動更新など

クラウドが登場し、インフラリソースのライフサイクルが短くなると、構築/運用コストが肥大化する傾向にある。

仮想化による物理的な制約がなくなり管理が複雑化

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

構成管理ツールの必要性

6

Install Install

構成管理ツール

動的機器情報取得

Cloud Platform

状態の管理

API

Code

構成管理ツールによる管理

オペレーション自動化における構成管理ツールの役割りは、情報を動的に取得して、意図する状態にシステムを収束させること。

・機器の構成情報はクラウドが提供するAPIによって取得・状態を管理するためには、動的な管理が可能

プログラマブルな構成管理ツール、Infrastructures as Codeに注目が集まっている。

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

Infrastructure as Codeとは

7

Infrastructure as Code

手作業で行っていたインフラの構築や変更作業をコードで定義し、自動化すること。

ソフトウェア開発で実施されてきた開発プロセスをインフラシステム、アプリケーション、ミドルウェアのデプロイメントやコンフィグレーションの管理に適用。

つまり、インフラリソースをコードで操作するということは、そのコード自体が「品質管理」「バージョン管理」「テスト」の対象となるということ

継続的インテグレーションバージョン管理

バージョン管理システム

CI Server

Build Test

Check構成管理ツール

Feedback

Commit 自動化(デプロイ/テスト)

DevelopmentCI/Test

Code

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

Infrastructure as Codeのメリット

8

オペレーション工数の削減従来、手動で行ってきた作業をコード化、自動化することにより、オペレーション工数および納期の短縮が期待できる。

オペレーション品質の向上作業をコード化して、自動化することにより、オペレーション品質を均一に保つ効果がある。

システム運用の標準化の促進自動化やバージョン管理を適切に行うことで、システム運用のポリシーや業務標準化を形成できる。また、コードを再利用することにより無駄を排除し、継続的インテグレーションやデリバリを実現できる。

作業統制の強化作業オペレーションを自動化することにより、内部統制やセキュリティ対策面での効果が期待できる。

Infrastructure as Codeを適用することでアジリティの高いサービスを提供

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

Infrastructure as Codeの適用範囲

9

Application ServiceDeployment

ConfigurationManagementシステムの構成管理

Bootstrappingブートストラッピング

SystemConfiguration

Cloud or VMImage 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によって分類されている。

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

Ansibleとは

10

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

Ansibleとは

11

Ansible

システムオペレーションの自動化を提供する、Python製の構成管理ツールです。

オンプレミスのシステムから、パブリッククラウドまでマルチベンダー連携が可能であり、大手金融機関や大規模製造業を中心とした採用も多く、飛躍的に認知度が上がっている。

2012 -開発Project開始2013 - Ansible.Inc設立2015 - RedHat.IncがAnsible.Incを買収

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

Ansibleの特徴

12

・YAML形式で読みやすく書きやすい。・属人化しにくい・学習コストが低い

Simple・エージェント導入コストがない・SSH接続のため安全

Agentless・多数のベンダー機器に対応・マルチレイヤ対応・同時実行可能

Powerful

Ansibleには、Simple, Agentless, Powerfulの3つの特徴がある。

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

Ansibleの特徴 - Simple -

13

Ansible(YAML)の表記

apache_setup_playbook.yml

---- name: Install Apache

yum: name: httpd

when: ansible_distribution == 'CentOS'

- name: Configure Apachetemplate:

src: httpd.confdest: /etc/httpd/conf/httpd.conf

- name: Start Apacheservice:

name: httpdstate: startedenabled: yes

Chef(Ruby)の表記

apache_setup_recipe.rb

case node[‘platform’]when “centos”

package ‘httpd’ doaction: install

endend

template “httpd.conf” dopath “/etc/httpd/conf/httpd.conf”source “httpd.conf.erb”

end

service “httpd” dosupports :status=>true, :restart=>true, :reload=>trueaction [ :enable, :start ]

end

YAML形式は読みやすく書きやすいため、学習コストが低く、属人化しずらい。

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

Ansibleの特徴 - Agentless -

14処理対象サーバー

管理サーバー

Agent型 Agentless型

Agent

全ての変更対象サーバーにエージェントのインストールが必要

処理対象サーバー

管理サーバー

Agent不要

変更対象サーバーの設定が容易

Agent

Agent

Agentless型のプロダクトは、エージェントの導入コストがない。

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

Ansibleの特徴 - Powerful -

Application ServiceDeployment

ConfigurationManagementシステムの構成管理

Bootstrappingブートストラッピング

SystemConfiguration

Cloud or VMImage Launch

OS Install

Orchestrationアプリケーションデプロイメント

Ansible

“Automation for Everyone”

Infrastructure as Codeの対象範囲全てのレイヤに対応している。(マルチレイヤ対応)

商標: それぞれのロゴは、各社/組織団体の登録商標です。

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

Ansibleの特徴 - Powerful -

16

多数のベンダー機器にも対応している。(マルチベンダー対応)

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

(補足) Moduleのサポートに関して

17

コアチームが管理を維持し、常に安全な状態で出荷されるモジュールです。また、すべての要求に対して優先順位が高くなります。

他の企業によって提出されたり、コミュニティによって維持されるモジュールです。モジュールの管理者は、報告された問題やモジュールに対して発生した要求を監視する必要があります。

コアチームまたはモジュールに関連付けられた企業/パートナーによってサポートされていないモジュールです。これらはコミュニティによって維持されます。問題への対応は、全てコミュニティに依存します。ベストエフォートでのサポートは提供されますが、サポート契約の対象とはなりません。

Core

Curated

Community

Ansibleは数多くのモジュールを提供しますが、各モジュールごとにサポートの内容が異なります。

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

処理対象サーバー処理対象サーバー

他の構成管理ツールとのアーキテクチャ比較

18

(1)変更内容を定義

(2)変更対象に送信

(3)変更実施

(1)変更内容を定義

(2)定期的に

変更有無を問い合わせ

(3)変更があれば更新

管理サーバー 管理サーバー

Push Architecture Pull Architecture・シンプルな仕組み・コントロールの柔軟性

・配布のスケーラビリティ・完全自動化

「Push Architecture」と「Pull Architecture」があり、AnsibleはPush Architectureを採用している。

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

他の構成管理ツールとの比較表

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 DashboardPuppet Enterprise(有償)

Chef Server ansible-semaphoreAnsible Tower(有償)

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

Ansibleが注目されている理由

20

Ansibleが最も重視している点は、開発組織の共通言語としての役割りであり、DevOpsの課題を「Simple」という特徴で補っている。

Sharing Measurement

Culture Automation

コミュニケーションを推進するためのイノベーションを引き起こすこと

互いに学び成長できるよう、経験を共有すること

フィードバックを得ながら、成果を計測し、開発サイクルに活用すること

各プロセスにおける手作業の処理をなくしていくこと

Ansible

開発組織の共通言語

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

Ansibleのアーキテクチャ

21

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

Ansible Core Engine

Ansibleのコンポーネント

22

Ansible CLI

Modules

Python API

Playbook

Inventory

PluginInterfaceConnection Type Plugin

Callbacks Plugin

Ansibleの各コンポーネントは、インストール時にCore Engineに組み込まれている。

再利用可能な処理ユニット。作業をラッピングしたコンポーネント

Ansibleのコア機能を拡張するためのコンポーネント

Ansibleを操作するためのインターフェイス

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

Ansible Core Engine

Ansibleのコンポーネント

Ansible CLI

Modules

Python API

Playbook

Inventory

PluginInterfaceConnection Type Plugin

Callbacks Plugin

Ansibleの各コンポーネントは、インストール時にCore Engineに組み込まれている。

再利用可能な処理ユニット。作業をラッピングしたコンポーネント

Ansibleのコア機能を拡張するためのコンポーネント

Ansibleを操作するためのインターフェイス

ユーザーが作成するのは、「Inventory」と「Playbook」の2つのファイル

23

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

Inventory

24

Inventoryとは、処理対象サーバの接続情報を記載したファイルです。

[web_servers]web-01 ansible_host=192.168.101.1web-02 ansible_host=192.168.101.2web-03 ansible_host=192.168.101.3

[db_servers]db-01 ansible_host=192.168.201.1db-01 ansible_host=192.168.201.2

inventory.iniall

web_servers db_servers

192.168.101.1

192.168.101.2

192.168.101.3

192.168.102.2

192.168.102.1

環境に合わせて処理対象サーバをグループ化することができる。

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

Playbook

25

Playbookとは、一連の作業を順序立てて定義するファイルです。

---- hosts: web_servers

vars:apache_conf: /etc/httpd.conf

tasks:- name: Install Apache

yum:name: httpd

- name: Configure Apachetemplate:

src: httpd.conf.j2dest: “{{ apache_conf }}”

- name: Start Apache processsystemd:

name: httpdstate: started

site.yml

Target Sectionweb_serversグループに適応

Vars Sectionapache_confの変数定義

Tasks Section(1) Apacheのインストール

- yumモジュールの利用

(2) Apacheの設定-templateモジュールの利用

(3) Apacheプロセスの開始-systemdモジュールの利用

上から順に実行される。

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

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

実行処理順序

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

AnsibleのクラウドAPI連携

27

SetupInstall

Public Cloud Platform

各クラウドAPIを操作するためのモジュールが用意されている。

SetupInstall

Public Cloud Platform Private Cloud Platform

Install

CloudModules

Bridge Bridge

Ansibleが各クラウドAPIを統括的にコントロール

Playbook

Ansible

APIAPIAPI

AnsibleのクラウドAPI連携により、ハイブリッドクラウドの実現をサポートする。

商標: それぞれのロゴは、各社/組織団体の登録商標です。

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

継続的インテグレーションへの展開

28

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

29

継続的インテグレーションバージョン管理

バージョン管理システム

CI Server

Build Test

Check構成管理ツール

Feedback

Commit 自動化(デプロイ/テスト)

DevelopmentCI/Test

Code

コードのコミットビルド

単体テスト開発成果物の管理 デプロイ 機能テスト

AnsibleとCIパイプライン

Playbookをバージョン管理システムに保存

各Playbookタスクの単体テストを実施

作成したVMのテンプレート化や、コンテナのテンプレート化

Ansibleにより、デプロイメントを実施

デプロイメントした環境の機能テストを実施

CIパイプラインにおいて、Ansibleはデプロイメントを実施する役割りを担っている。

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

デプロイ テスト

30

バージョン管理システム

開発成果物管理システム

チェックアウト

アプリケーション

Infrastructureas code

アプリケーションエンジニア

インフラエンジニア

アプリケーション開発

構成管理の自動化

コードのコミットビルド

単体テスト開発成果物の管理 デプロイ 機能テスト

ContinuousIntegrationCIツール

開発成果物の展開 機能/結合テスト

アプリケーション単体テスト

applicationcode

ビルド/テスト自動化ツール

IaaS

CIパイプラインと役割り

イメージ化

VMテンプレートの管理

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

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・BluemixContainer Orchestration・Docker Datacenter・Mesosphere・Kubernetes構成管理の自動化・Ansible・Chef

※凡例

手動タスク

自動化タスク

機能テストツール・UFT・Selenium・Appium・JMeter

コードのコミットビルド

単体テスト開発成果物の管理 デプロイ 機能テスト開発環境

CI環境

ステージング環境QA環境

本番環境

利用ツール例

デプロイ 機能テストコード反映

コード反映

デプロイ リリース

Issue Tracking・JIRA・Redmine

Promote

Promote

開発成果物の管理

開発成果物の管理

CI/CDのプラットフォーム選択

デプロイメントのプラットフォーム選択がCI/CDのプロセスに大きく影響を及ぼす。

アプリケーションのアーキテクチャおよび非機能要件/運用要件によって選択

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

HPEにおけるAnsibleの取り組み

32

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

OneViewによるプログラマブルインフラストラクチャ

33

ITインフラの統合管理と自動化を推進「HPE OneView」

HPE OneViewは、サーバーのみならず、ストレージ、ネットワークまでITインフラストラクチャ全体を構成するハードウェアの統合的な管理を実現します。REST APIを介してOpenStack、Microsoft、System Center、VMware vCenterをはじめとする様々なソフトウェアと連携し、サービス、ソフトウェア、ハードウェアまで一気通貫した運用が可能になります。HPE OneViewは、「インフラストラクチャの自動化ハブ」としての機能を強化し進化し続けています。

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

34

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

35

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

36

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

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

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

38

Enjoy AnsibleThank you

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

本資料に関するお問い合わせ

39

Shingo.Kitayama

Mailto: [email protected]

Ansibleは、米国およびその他の国において登録されたRed Hat, Inc.の商標です。その他、本資料で記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。

本資料に関しては、お気軽にお問い合わせ下さい。また、内容に関しては個人の意見に基づくものであり、十分考慮の上ですが、所属組織団体の公式見解とは異なる場合がございます。何卒、ご了承下さい。

商標