NoOps Meetup Tokyo #2 カンファレンスノート

# イベント情報
[NoOps Meetup Tokyo #2 - connpass](https://noops.connpass.com/event/103846/)

> **NoOps = No "Uncomfortable" Ops**
> NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう！」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。
> NoOps Meetup Tokyo #2 では、#1に引き続き、業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。

[NoOps Meetup Tokyo #1 カンファレンスノート - Qiita](https://qiita.com/saitotak/items/2f85918aa329c4af2073)
第一回のカンファレンスノートはこちら

# 資料リンク集
- [NoOps Meetup Tokyo #2 Opening](https://www.slideshare.net/hiromasaoka/noops-meetup-tokyo-2-opening)
- [MicroserviceでのNoOps戦略 - NoOps Meetup Tokyo #2 #NoOpsJP](https://www.slideshare.net/yusuke/microservicenoops-noops-meetup-tokyo-2-noopsjp)
- [The NoOps strategy and tactics](https://www.slideshare.net/irix_jp/the-noops-strategy-and-tactics)
- [なかなか楽にならないSSL/TLS証明書の話 - Speaker Deck](https://speakerdeck.com/shibayan/tlszheng-ming-shu-falsehua)


# オープニング/NoOps Japan 発起人 岡 大勝 `@okahiromasa`
- NoOps Meetup #1 振り返り
    - Publickeyで第一回が記事として取り上げられている
        - [NoOpsを実現できる時が来た。「NoOps」とは運用の“嬉しくない”ことをなくすこと。NoOps Meetup Tokyo ＃1 － Publickey](https://www.publickey1.jp/blog/18/noopsnoopsnoops_meetup_tokyo_1.html)
        - [「NoOps？ よろしい、ならば戦争だ」 NoOpsコミュニティに異議申し立てた「Opsの味方」 決裂か？ 和解か？ NoOps Meetup Tokyo ＃1 － Publickey](https://www.publickey1.jp/blog/18/noops_noopsops.html)
    - 「やめることを決める」ことが大事
        - やめようと言い出すハードルは低くないが、前向きなやめかたをする
    - NoOpsに向かう準備は整っている
        - コンテナ、サーバレス、DevOps、SRE ...
    - みんな違ってみんな良い
        - 背景/手段はたくさんある、いろんな観点を重ねながら学んでいきたい
- Meetupでは知の共有、OpenHackでものづくりを進めるコミュニティ作りを進める
- 行動指針
    - オープン＆フラット
    - 共感駆動のSRCA(Sympaty-Respect-Contribute-Appriciate)
- スポンサー募集中
- Microsoft Tech Summit 2018 / Japan Container Days 2018 登壇します
    - [Microsoft Tech Summit 2018 | インフラエンジニア、アーキテクト、IT IT 戦略にかかわる皆様の為の技術カンファレンス - Microsoft Events &amp; Seminars](https://www.microsoft.com/ja-jp/events/techsummit/2018/)
    - [Japan Container Days v18.12](https://containerdays.jp/)

# MicroserviceでのNoOps戦略/鈴木 雄介 `@yusuke_arclamp` グロースエクスパートナーズ
- NoOpsとは / 歴史経緯
    - ITサービスのライフサイクルを早くする（企画、実装、運用、利用）
    - 2001年 アジャイル
        - アジャイルソフトウェア開発宣言
        - `企画→開発` のスピードアップ
    - 2009年 DevOps
        - アジャイルをインフラや運用の仕事にも適用する
        - `開発-運用`
        - [10+ Deploys Per Day: Dev and Ops Cooperation at Flickr](https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr)
    - 2011年 NoOps
        - 運用はいらない？運用担当者はいらない？という議論へ
        - NoOps炎上事件
        - [Augment DevOps With NoOps](https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203)
    - その後の議論
        - 2012年 Netflix / [Ops, DevOps and PaaS (NoOps) at Netflix](http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html)
            - カナリアリアリリース、アラート収集、Cassandra用運用ツール
            - DevOps/SREチームがこれらのツールを作成
            - 運用するための組織は存在せず，開発者は運用者と話す必要はない
            - 開発者を運用から開放し、セルフサービスツールを提供する
        - [Why 2013 is the year of ‘NoOps’ for programmers [Infographic]](https://gigaom.com/2012/01/31/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)
    - NoOps総論
        - 運用作業の自動化とツール化
            - ツール化するエンジニアがいる
        - 開発者はツールを使って運用作業を行う
            - 作る と 動かす の距離がなくなる
        - ツール化により役割分担が変わった
            - 機能要件だけでなく非機能要件まで
            - プログラマの役割が変わってきた
    - 2014年 Microservices
        - 先端的なウェブサービス企業が似たようなアーキテクチャスタイルを取っている
        - なぜMicroservices？
            - 目的：サービス全体を止めずに一部を変更する
            - 解決：変更発生単位にサービスとして分割し、APIで連携させることで変更時にサービス全体を止めない
    - MicroservicesとNoOps
        - Microservices にNoOpsは織り込み済み
            - 運用作業の自動化、ツール化は重要な土台
            - 「アプリを作る」から「サービスを動かす」へ
        - 全員が NoOpsを目指すべき
    - NoOps とは まとめ
        - 「サービス全体を止めに一部を変更する」ために主に「運用作業の自動化とツール化」を推進すること
        - 開発者にとっては「作る」から「作って動かす」へ
        - 「うちはAWSじゃない」「既存のツールが使えない」は思考停止
- サービスを管理せよ
    - アプリとインフラを一体で管理する
        - 「インフラを用意して、アプリをインストールする」ではなく「サービスとして管理する」
        - PaaS
            - そもそも対障害性、無停止リリース機能を持ったPaaSを利用する
            - すごく便利だが制約に従う必要がある、実現できることと制約が比例する
        - コンテナ
            - ネットワーク/ミドルウェアを含めた構成のバージョン管理
            - ほぼ制約なし
            - コンテナ対応PaaSを利用すると便利
        - 発想の転換：動かす時にインフラ調達
            - 「インフラを用意してアプリを置く」ではなく「アプリを動かす時にインフラを調達する」
            - バッチサーバという概念はいらない、バッチジョブを起動するタイミングでインフラ調達する
- ありがちな課題の解決
    - 固定IP、固定ドメイン前提になってる→動的対応する
    - エージェントが必要→エージェント不要にしていく
    - 設定ファイルで環境切り替え→設定をリポジトリ化
    - DB関連が手動→コード化
- その先へ
    - コンテナオーケストレーション、サービスメッシュ
    - イベントソージング

# ITインフラの NoOps を実現する戦略と方法論/中島 倫明 `@Irix_jp` レッドハット
- NoOps = 戦う階層を変えること
    - 従来インフラではストレージ、サーバ、DB等と戦ってきた
- 安全に確実に動かす、コストを最適化する、に加えて「変化への対応」という3軸目が重要に
    - 1度作ったインフラが変化するのは当たり前
        - パッチ適用、バージョンアップ、設定変更、リソース増減 …
- 戦略的なアプローチ
    - 先に考えること：状態
        - どういう状態にするか、どういう状態になればComfortableなのか
    - 後で考えること：方法
        - どう作るか、どうやって実現するか
- 戦略的な考え方とは
    - 戦術のみを知って戦略を知らざるものは、ついに国家をあやまつ
        - [今、エンジニアに最も必要なものは「戦略」である！孫氏に学ぶ本質のつかみ方](https://www.slideshare.net/irix_jp/jtf2016-the-strategy-and-sun-tzu)
        - [イゼルローン要塞攻略に学ぶエンジニアの戦略思考](https://www.slideshare.net/irix_jp/the-strategy-from-the-iserlohn-fortress-at-jtf2018)
- クラウドファースト、コンテナファースト、自動化ファースト
- NoOpsへの戦略的アプローチ
    - モデルとなる状態を定義：他の成功者を参考にすると近道
    - その状態に行き着くために障害となるギャップを抽出
    - 解消できるギャップ、出来ないギャップ（法律とか業界とかの縛りなど）を整理して、ToBeを描く
    - ギャップ測定
        - バリューストリームマッピングで抽出・可視化
            - 理想的な環境ではどうなるか
            - 現状とのギャップ、障害となるものは何か
        - 今すぐできること、将来的にやること、やらなくて良いことを整理
    - 自動化の戦術
        - 置換：単純に手順を置き換える、
        - 機能化：サービスとして切り出して別の人に実行してもらう
        - 連結：小さな機能を連結して大きな機能を作る
- アンチパターン：全部自動化しなといけない、一気通貫で自動化しなければならない、今の環境のまま自動化しないといけない
    - 戦略的：運用が発生しないアーキテクチャで始める
    - 戦略的：自動化しやすい環境を整える
    - 戦術的：簡単なやりやすいところから自動化してしまう
    - 戦術的：難しいもの、複雑なものをそのまま自動化する

# なかなか楽にならない証明書の話/しばやん `@shibayan`
- SSL/TLS証明書の管理がしんどい
    - 12ヶ月に一回位の作業
    - 認証局からのメールで期限を思い出したり忘れたり
- DV証明書発行の流れ
    - 認証局にCSRを投げる
    - ドメインの所有を確認する
        - whoisに登録されているメールアドレスにリンク送信、指定されたTOKEN入のファイルをサーバに置く、DNSで指定されたレコードを追加するなど
    - 証明書が発行される
        - 中間証明書と一緒にサーバに配置したり、PFXにしたり
- 自動化されない理由
    - 自動化が難しい作業ばかり：CSR作成、ドメイン所有の確認、証明書と秘密鍵の配置
    - 12ヶ月ごとなので、手動でもなんとかなっちゃう雰囲気（自動化のコストが割に合わない）
    - そもそも認証局が自動化前提の作りじゃない
- 更新忘れると
    - SSL/TSL通信がうまくいかない
        - ブラウザが警告出す、ブラウザ意外の通信も同様
    - 最近は常時SSLやHSTSの流れにより致命的
    - [Windows Azure、11時間にわたる全世界的なストレージ障害。原因はSSL証明書の失効 － Publickey](https://www.publickey1.jp/blog/13/windows_azure11ssl.html)
        - 致命的な問題に発展するのに、なかなか楽にならない
- 楽にしようとする動き
    - クラウドベンダが認証局をもつ：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を踏む必要がある（今までと同じく手動の作業が出てくる）
    - 無料
- Azure Key Valt
    - DigiCert と GlobalSignと連携、予めアカウントを作る必要がある
    - 事前に指定したポリシーに従って更新してくれる
    - 自己証明書の発行もできる
    - おそらく有料
- App Service Certificate
    - GoDaddyと連携している、AzurePotalから購入可能
    - 自動更新
    - 有料：1ドメイン$69.999、ワイルドカード$299.999
- Let's Encrypt
    - ACMEプロトコルに基づいた自動での証明書発行
        - 公式のcertbotを使って管理可能
        - v2からはワイルドカードも可能
    - HTTPかDNSを利用してドメイン所有の確認
    - 無料で使える
- 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に感謝を