今からでも間に合う!インフラ自動化超入門 @渋谷
•Download as PPTX, PDF•
2 likes•1,571 views
外部セミナー向けに展開した資料となります。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 今からでも間に合う!インフラ自動化超入門 @渋谷
Similar to 今からでも間に合う!インフラ自動化超入門 @渋谷 (20)
今からでも間に合う!インフラ自動化超入門 @渋谷
- 1. 今からでも間に合う！ インフラ自動化超入門 @渋谷 1 2018/04/20 connpass 株式会社Rosso 原田大郷
- 6. Agenda 6 ✦ 最近のインフラエンジニアリング ✦ サーバ構築、テストの自動化 ✦ システムの自動化 ✦ デプロイの自動化
- 9. 何が変わったのか？(career) 9 従来は。。 • サーバエンジニア • NWエンジニア • DBエンジニア • ストレージエンジニア etc… 各セクション毎に細分化されており 、連携など無駄なコミニケーション が発生し非効率であり且つアプリエ ンジニアとの距離感もあった
- 10. 何が変わったのか？(career) 10 従来は。。 • サーバエンジニア • NWエンジニア • DBエンジニア • ストレージエンジニア etc… 各セクション毎に細分化されており 、連携など無駄なコミニケーション が発生し非効率であり且つアプリエ ンジニアとの距離感もあった
- 11. 何が変わったのか？(career) 11 従来は。。 • サーバエンジニア • NWエンジニア • DBエンジニア • ストレージエンジニア etc… 各セクション毎に細分化されており 、連携など無駄なコミニケーション が発生し非効率であり且つアプリエ ンジニアとの距離感もあった 現在 • DevOpsエンジニア • SREエンジニア etc… クラウド、自動化を上手く利用する ことで広範囲に渡ったセクションを 少人数でカバーする必要がある アプリエンジニアと直接連携して課 題や問題を解決することが求められ る
- 12. 何が変わったのか？(career) 12 DevOpsエンジニア 概要：開発(Development) と運用 (Operations)が協業する 開発手法 SREエンジニア 概要：Site Reliableity Engineering(サイト信頼性)に着眼した開発手法 DevOps・SREともに定義が曖昧であるが本質は変わらずサービスの安定稼 働・最適化・信頼性の担保させるミッションは同じである。
- 13. 何が変わったのか？(engineering) 13 従来は。。 • 機器選定、見積り、機器到着まで のリードタイム • サーバ、NW機器設定 • 物理キッティング、ケーブリング • OSの初期設定(OSキッティング) • ssh、RDPして1台ずつconfigを手 動設定 サービスをローンチ・デリバリする までのオーバーヘッドが大きい！！
- 14. 何が変わったのか？(engineering) 14 従来は。。 • 機器選定、見積り、機器到着まで のリードタイム • サーバ、NW機器設定 • 物理キッティング、ケーブリング • OSの初期設定(OSキッティング) • ssh、RDPして1台ずつconfigを手 動設定 サービスをローンチ・デリバリする までのオーバーヘッドが大きい！！
- 15. 何が変わったのか？(engineering) 15 従来は。。 • 機器選定、見積り、機器到着まで のリードタイム • サーバ、NW機器設定 • 物理キッティング、ケーブリング • OSの初期設定(OSキッティング) • ssh、RDPして1台ずつconfigを手 動設定 サービスをローンチ・デリバリする までのオーバーヘッドが大きい！！ 現在 • 機器選定、見積り、機器到着まで のリードタイム • サーバ、NW機器設定 • 物理キッティング、ケーブリング • OSの初期設定(OSキッティング) • ssh、RDPして1台ずつconfigを手 動設定
- 16. 何が変わったのか？(engineering) 16 従来は。。 • 機器選定、見積り、機器到着まで のリードタイム • サーバ、NW機器設定 • 物理キッティング、ケーブリング • OSの初期設定(OSキッティング) • ssh、RDPして1台ずつconfigを手 動設定 サービスをローンチ・デリバリする までのオーバーヘッドが大きい！！ 現在 • 機器選定、見積り、機器到着まで のリードタイム • サーバ、NW機器設定 • 物理キッティング、ケーブリング • OSの初期設定(OSキッティング) • ssh、RDPして1台ずつconfigを手 動設定 クラウド、インフラ自動化技術の台 頭によって上記作業を意識せずに即 座にローンチ・デリバリが可能にな ってきた
- 21. サーバ構築、テストの自動化 21
- 22. サーバ・ミドル構築自動化ツール 22 サーバ構築の自動化 特徴 • OS、ミドルウェアの設定をコード化して構成管理 • サーバのインストールはしない。インストールされたサーバに対してOS設定 ミドルウェアのインストール、設定を行うことができる • ツールによっては学習コストがかかる場合がある(特にChef・Puppet) • クライアントのエージェントが必要なもの不要なものがある • 1度のオペレーションで何十台、何百台のサーバへ設定を行うことが出来る • 管理しているコード自体がOS、ミドルの設計書として扱われる
- 23. Code例(Chef) 23 package 'httpd' do action :install end ruby_block 'randomly_choose_language' do block do if Random.rand > 0.5 node.run_state['scripting_language'] = 'php' else node.run_state['scripting_language'] = 'perl' ~以下省略〜
- 24. サーバテスト自動化ツール 24 サーバテストの自動化 特徴 • OS、ミドルウェアのテストをコード化して構成管理(Rubyで記述) • エージェントは不要 • 1度のオペレーションで何十台、何百台のサーバへテスト実施を行うことが出 来る • 管理しているコード自体がテスト仕様書として扱われる • 開発者は日本のエンジニア
- 25. Code例(Serverspec) 25 describe command('ls -al /') do its(:stdout) { should match /bin/ } end describe command('ls /foo') do its(:stderr) { should match /No such file or directory/ } end describe command('ls /foo') do its(:exit_status) { should eq 0 } end
- 31. システムの自動化 31
- 32. システム構築自動化ツール 32 オーケストレーション 特徴 • システム自体をテンプレート化することができる • 事前にテンプレート化することで新旧システムの切り替えが容易となる • テンプレートの記述方法はJSON、YAMLなど様々 • TerraformにおいてはOSSで各クラウドサービスのシステムテンプレートと して管理することができる Azure ARM Template
- 34. テンプレート作成(CloudFormation) 34 service server server Load balancing Fire Wall CloudFormerで各リソースの 情報を取得しテンプレート化
- 35. テンプレート作成(CloudFormation) 35 service server server Load balancing Fire Wall CloudFormerで各リソースの 情報を取得しテンプレート化 CloudFormation(amazon web service社) https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/Welco me.html CloudFormer(amazon web service社) https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn- using-cloudformer.html ※CloudFormerを活用することでウィザード形式でテンプレートを簡単に作成で きる。但し余分なゴミがテンプレートに残っている場合があるので編集が必要。 ※CloudFormer専用のEC2インスタンスも立てる必要がある。 テンプレート作成時にはその分コストも発生するため注意。
- 36. テンプレート例(CloudFormation) 36 { "AWSTemplateFormatVersion" : "2010-09-09", "Description" : "AWS CloudFormation Sample Template EC2_Instance_With_Ephemeral_Drives: Example to show how to attach ephemeral drives using EC2 block device mappings. **WARNING** This template creates an Amazon EC2 instance. You will be billed for the AWS resources used if you create a stack from this template.", "Parameters" : { "KeyName": { "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the web server", "Type": "AWS::EC2::KeyPair::KeyName", "ConstraintDescription" : "must be the name of an existing EC2 KeyPair.” 〜以下省略〜
- 37. テンプレート作成(Terraform) 37 service server server Load balancing Fire Wall Terraformingで各リソースの情 報を取得しテンプレート化し Terraformの管理下におく。
- 38. テンプレート作成(Terraform) 38 service server server Load balancing Fire Wall Terraformingで各リソースの 情報を取得しテンプレート化 Terraform(Hasicorp社) https://www.terraform.io/ Terraforming(GitHub) https://github.com/dtan4/terraforming ※TerraformingはHasicorp製ではなく非公式ツール。 テンプレート化対応されていないリソースもあるので注意。
- 39. テンプレート例(Terraform) 39 provider "aws" { region = "us-west-2" } data "aws_ami" "ubuntu" { most_recent = true filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-trusty-14.04-amd64-server-*"] } 〜以下省略〜
- 40. テンプレート化の応用 40 Old service(blue) server server Load balancing Fire Wall
- 41. テンプレート化の応用 41 New service(green) serve r serve r Load balancing Fire Wall Old service(blue) server server Load balancing Fire Wall
- 42. テンプレート化の応用 42 New service(green) serve r serve r Load balancing Fire Wall Old service(blue) server server Load balancing Fire Wall
- 43. テンプレート化の応用 43 New service(green) serve r serve r Load balancing Fire Wall Old service(blue) server server Load balancing Fire Wall
- 44. テンプレート化の応用 44 New service(green) serve r serve r Load balancing Fire Wall Old service(blue) server server Load balancing Fire Wall
- 45. テンプレート化の応用 45 New service(green) serve r serve r Load balancing Fire Wall Old service(blue) server server Load balancing Fire Wall BGデプロイ(blue green deployment)によって 旧システム→新システムを切り替えてから旧システムを破 棄する。テンプレートを使うことでシステムの使い捨てが 容易となる。
- 46. デプロイの自動化 46
- 47. デプロイ自動化ツール 47 CIツール 特徴 • ジョブ管理ツール • サーバへのデプロイの進捗、成功、失敗状況がGUIで確認できる • Gitで管理されているコードを更新してからリポジトリへpushさせ webhookを通じてCIツールからビルドを開始させることもできる • Jenkinsは自前で構築し管理する必要があるが無料 • CircleCIとTravisCIはSaaSで提供されており管理が不要だが料金がかかる
- 50. environment CI Server デプロイ自動化アーキテクチャ 50 production staging develop web hook push programmer・Infra engineer・designer
- 51. environment CI Server デプロイ自動化アーキテクチャ 51 production staging develop build web hook push programmer・Infra engineer・designer
- 52. environment CI Server デプロイ自動化アーキテクチャ 52 production staging develop build web hook push programmer・Infra engineer・designer SaaS型のCIツールはビルドの時間がかかってしまう場合が ある。クラウド上にあるサーバへデプロイ速度を早くする には同じリージョン内で自前でJenkinsなどのCIサーバを立 てることで同リージョン間内での通信速度を早くしビルド 時間を短縮させるなど工夫が必要となる場合もある。
- 55. インフラ自動化のメリット 55 • 開発環境をスピーディに提供することができる • プログラマは開発だけ専念することができる • サービスリリースまでのリードタイムが短縮される • サービスのアイデア、改善など利益に繋がる事柄に専念することができる • サーバ、スイッチ、アプライアンス製品など物理機器を購入しなくてもよい
- 56. インフラ自動化のデメリット 56 • 自動化に対応したOSSなど学習コストがかかる • OS、NW、ミドルの仕組みなど前提知識は必須 • 人によりオンプレ脳を捨てるのに躊躇する場合がある • sshログインで手動設定をするとコード管理と差異が発生し不整合に陥る • githubにコード管理する際に誤ってAWSなどのアカウント情報(access key/secret key)を公開してしまうと第3者にアクセスされ攻撃されること でAWSのアカウント上で大量の従量課金が請求されるリスクがある
- 61. 最後に 61