イベント情報
NoOps Meetup Tokyo #2 - connpass
NoOps = No "Uncomfortable" Ops
NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう！」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。
NoOps Meetup Tokyo #2 では、#1に引き続き、業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。
NoOps Meetup Tokyo #1 カンファレンスノート - Qiita
第一回のカンファレンスノートはこちら
資料リンク集
- NoOps Meetup Tokyo #2 Opening
- MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP
- The NoOps strategy and tactics
- なかなか楽にならないSSL/TLS証明書の話 - Speaker Deck
オープニング/NoOps Japan 発起人 岡 大勝 @okahiromasa
- NoOps Meetup #1 振り返り
- Publickeyで第一回が記事として取り上げられている
- 「やめることを決める」ことが大事
- やめようと言い出すハードルは低くないが、前向きなやめかたをする
- NoOpsに向かう準備は整っている
- コンテナ、サーバレス、DevOps、SRE ...
- みんな違ってみんな良い
- 背景/手段はたくさんある、いろんな観点を重ねながら学んでいきたい
- Meetupでは知の共有、OpenHackでものづくりを進めるコミュニティ作りを進める
- 行動指針
- オープン＆フラット
- 共感駆動のSRCA(Sympaty-Respect-Contribute-Appriciate)
- スポンサー募集中
- Microsoft Tech Summit 2018 / Japan Container Days 2018 登壇します
MicroserviceでのNoOps戦略/鈴木 雄介 @yusuke_arclamp グロースエクスパートナーズ
- NoOpsとは / 歴史経緯
- ITサービスのライフサイクルを早くする（企画、実装、運用、利用）
- 2001年 アジャイル
- アジャイルソフトウェア開発宣言
-
企画→開発のスピードアップ
- 2009年 DevOps
- アジャイルをインフラや運用の仕事にも適用する
開発-運用- 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr
- 2011年 NoOps
- 運用はいらない？運用担当者はいらない？という議論へ
- NoOps炎上事件
- Augment DevOps With NoOps
- その後の議論
- 2012年 Netflix / Ops, DevOps and PaaS (NoOps) at Netflix
- カナリアリアリリース、アラート収集、Cassandra用運用ツール
- DevOps/SREチームがこれらのツールを作成
- 運用するための組織は存在せず，開発者は運用者と話す必要はない
- 開発者を運用から開放し、セルフサービスツールを提供する
-
Why 2013 is the year of ‘NoOps’ for programmers [Infographic]
- 90年代 データセンター集約
- 2006 API(AWS)
- 2011 SysOps(Puppet/Chef)
- 2012 AppLifecycle(CloudFoundry/OpenShift)
- 2013 NoOps(Heroku)
- 2012年 Netflix / Ops, DevOps and PaaS (NoOps) at Netflix
- NoOps総論
- 運用作業の自動化とツール化
- ツール化するエンジニアがいる
- 開発者はツールを使って運用作業を行う
- 作る と 動かす の距離がなくなる
- ツール化により役割分担が変わった
- 機能要件だけでなく非機能要件まで
- プログラマの役割が変わってきた
- 運用作業の自動化とツール化
- 2014年 Microservices
- 先端的なウェブサービス企業が似たようなアーキテクチャスタイルを取っている
- なぜMicroservices？
- 目的：サービス全体を止めずに一部を変更する
- 解決：変更発生単位にサービスとして分割し、APIで連携させることで変更時にサービス全体を止めない
- MicroservicesとNoOps
- Microservices にNoOpsは織り込み済み
- 運用作業の自動化、ツール化は重要な土台
- 「アプリを作る」から「サービスを動かす」へ
- 全員が NoOpsを目指すべき
- Microservices にNoOpsは織り込み済み
- NoOps とは まとめ
- 「サービス全体を止めに一部を変更する」ために主に「運用作業の自動化とツール化」を推進すること
- 開発者にとっては「作る」から「作って動かす」へ
- 「うちはAWSじゃない」「既存のツールが使えない」は思考停止
- サービスを管理せよ
- アプリとインフラを一体で管理する
- 「インフラを用意して、アプリをインストールする」ではなく「サービスとして管理する」
- PaaS
- そもそも対障害性、無停止リリース機能を持ったPaaSを利用する
- すごく便利だが制約に従う必要がある、実現できることと制約が比例する
- コンテナ
- ネットワーク/ミドルウェアを含めた構成のバージョン管理
- ほぼ制約なし
- コンテナ対応PaaSを利用すると便利
- 発想の転換：動かす時にインフラ調達
- 「インフラを用意してアプリを置く」ではなく「アプリを動かす時にインフラを調達する」
- バッチサーバという概念はいらない、バッチジョブを起動するタイミングでインフラ調達する
- アプリとインフラを一体で管理する
- ありがちな課題の解決
- 固定IP、固定ドメイン前提になってる→動的対応する
- エージェントが必要→エージェント不要にしていく
- 設定ファイルで環境切り替え→設定をリポジトリ化
- DB関連が手動→コード化
- その先へ
- コンテナオーケストレーション、サービスメッシュ
- イベントソージング
ITインフラの NoOps を実現する戦略と方法論/中島 倫明 @Irix_jp レッドハット
- NoOps = 戦う階層を変えること
- 従来インフラではストレージ、サーバ、DB等と戦ってきた
- 安全に確実に動かす、コストを最適化する、に加えて「変化への対応」という3軸目が重要に
- 1度作ったインフラが変化するのは当たり前
- パッチ適用、バージョンアップ、設定変更、リソース増減 …
- 1度作ったインフラが変化するのは当たり前
- 戦略的なアプローチ
- 先に考えること：状態
- どういう状態にするか、どういう状態になればComfortableなのか
- 後で考えること：方法
- どう作るか、どうやって実現するか
- 先に考えること：状態
- 戦略的な考え方とは
- 戦術のみを知って戦略を知らざるものは、ついに国家をあやまつ
- クラウドファースト、コンテナファースト、自動化ファースト
- NoOpsへの戦略的アプローチ
- モデルとなる状態を定義：他の成功者を参考にすると近道
- その状態に行き着くために障害となるギャップを抽出
- 解消できるギャップ、出来ないギャップ（法律とか業界とかの縛りなど）を整理して、ToBeを描く
- ギャップ測定
- バリューストリームマッピングで抽出・可視化
- 理想的な環境ではどうなるか
- 現状とのギャップ、障害となるものは何か
- 今すぐできること、将来的にやること、やらなくて良いことを整理
- バリューストリームマッピングで抽出・可視化
- 自動化の戦術
- 置換：単純に手順を置き換える、
- 機能化：サービスとして切り出して別の人に実行してもらう
- 連結：小さな機能を連結して大きな機能を作る
- アンチパターン：全部自動化しなといけない、一気通貫で自動化しなければならない、今の環境のまま自動化しないといけない
- 戦略的：運用が発生しないアーキテクチャで始める
- 戦略的：自動化しやすい環境を整える
- 戦術的：簡単なやりやすいところから自動化してしまう
- 戦術的：難しいもの、複雑なものをそのまま自動化する
なかなか楽にならない証明書の話/しばやん @shibayan
- SSL/TLS証明書の管理がしんどい
- 12ヶ月に一回位の作業
- 認証局からのメールで期限を思い出したり忘れたり
- DV証明書発行の流れ
- 認証局にCSRを投げる
- ドメインの所有を確認する
- whoisに登録されているメールアドレスにリンク送信、指定されたTOKEN入のファイルをサーバに置く、DNSで指定されたレコードを追加するなど
- 証明書が発行される
- 中間証明書と一緒にサーバに配置したり、PFXにしたり
- 自動化されない理由
- 自動化が難しい作業ばかり：CSR作成、ドメイン所有の確認、証明書と秘密鍵の配置
- 12ヶ月ごとなので、手動でもなんとかなっちゃう雰囲気（自動化のコストが割に合わない）
- そもそも認証局が自動化前提の作りじゃない
- 更新忘れると
- SSL/TSL通信がうまくいかない
- ブラウザが警告出す、ブラウザ意外の通信も同様
- 最近は常時SSLやHSTSの流れにより致命的
-
Windows Azure、11時間にわたる全世界的なストレージ障害。原因はSSL証明書の失効 － Publickey
- 致命的な問題に発展するのに、なかなか楽にならない
- SSL/TSL通信がうまくいかない
- 楽にしようとする動き
- クラウドベンダが認証局をもつ：AWS Certificate Manager
- 外部認証局とパートナーシップを結んでる：Azure Key Vault/App Service Certificate
- Let's Encrypt を利用している/ACMEプロトコルの導入：GCP の Managed SSL、さくら など数多くの例
- AWS Certificate Manager
- ELB/ALB/CloudFront/APIGatewayで使える
- パブリック向けの場合、ワイルドカード証明書も発行可能、マルチテナントのアプリケーションにも使いやすい
- 自動的に証明書の更新を行ってくれる
- 条件：ドメインが利用中かつSSL/TLSで外部からアクセス可能な場合
- IP制限している場合は、メールが飛んできてURLを踏む必要がある（今までと同じく手動の作業が出てくる）
- 無料
- ELB/ALB/CloudFront/APIGatewayで使える
- Azure Key Valt
- DigiCert と GlobalSignと連携、予めアカウントを作る必要がある
- 事前に指定したポリシーに従って更新してくれる
- 自己証明書の発行もできる
- おそらく有料
- App Service Certificate
- GoDaddyと連携している、AzurePotalから購入可能
- 自動更新
- 有料：1ドメイン$69.999、ワイルドカード$299.999
- Let's Encrypt
- ACMEプロトコルに基づいた自動での証明書発行
- 公式のcertbotを使って管理可能
- v2からはワイルドカードも可能
- HTTPかDNSを利用してドメイン所有の確認
- 無料で使える
- ACMEプロトコルに基づいた自動での証明書発行
- ACMEプロトコルについて
- 認証局が証明書発行に必要な機能を定義している
- REST-API
- 対象のドメイン全てに対してHTTPSかDNSで確認される
- 特殊なファイル、もしくはTXTレコード書き換え
- certbot が使えるケース
- nginxやApacheを直接公開している場合
- Let's Encrypt公式クライアントなので安心
- 各クラウドのManagedDNSに対応（Azure除く）
- Linuxのみサポート
- 所感
- AWS Certificate Managerが突出して便利
- Let's Encrypt周りを面倒見てくれるManaged SSL良さ
- Azureは無料で使えるSSL証明書がない
- まとめ
- SSL/TSL証明書管理は自動化できる（DVのみ）
- AWSならAWS-CM、GCPならManagedSSLを使う
- Azureはお金払うか、コミュニティ作成のIssuerを使う
- Let's Encryptに感謝を