Go to Qiita Advent Calendar 2024 Top
LoginSignup
1
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@saitotak(🐑🐑 🐑 🐑 )

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

Last updated at Posted at 2018-10-27

イベント情報

NoOps Meetup Tokyo #2 - connpass

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

NoOps Meetup Tokyo #1 カンファレンスノート - Qiita
第一回のカンファレンスノートはこちら

資料リンク集

オープニング/NoOps Japan 発起人 岡 大勝 @okahiromasa

MicroserviceでのNoOps戦略/鈴木 雄介 @yusuke_arclamp グロースエクスパートナーズ

  • NoOpsとは / 歴史経緯
    • ITサービスのライフサイクルを早くする（企画、実装、運用、利用）
    • 2001年 アジャイル
      • アジャイルソフトウェア開発宣言
      • 企画→開発 のスピードアップ
    • 2009年 DevOps
    • 2011年 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)
    • 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なのか
    • 後で考えること：方法
      • どう作るか、どうやって実現するか
  • 戦略的な考え方とは
  • クラウドファースト、コンテナファースト、自動化ファースト
  • NoOpsへの戦略的アプローチ
    • モデルとなる状態を定義：他の成功者を参考にすると近道
    • その状態に行き着くために障害となるギャップを抽出
    • 解消できるギャップ、出来ないギャップ（法律とか業界とかの縛りなど）を整理して、ToBeを描く
    • ギャップ測定
      • バリューストリームマッピングで抽出・可視化
        • 理想的な環境ではどうなるか
        • 現状とのギャップ、障害となるものは何か
      • 今すぐできること、将来的にやること、やらなくて良いことを整理
    • 自動化の戦術
      • 置換：単純に手順を置き換える、
      • 機能化：サービスとして切り出して別の人に実行してもらう
      • 連結：小さな機能を連結して大きな機能を作る
  • アンチパターン：全部自動化しなといけない、一気通貫で自動化しなければならない、今の環境のまま自動化しないといけない
    • 戦略的：運用が発生しないアーキテクチャで始める
    • 戦略的：自動化しやすい環境を整える
    • 戦術的：簡単なやりやすいところから自動化してしまう
    • 戦術的：難しいもの、複雑なものをそのまま自動化する

なかなか楽にならない証明書の話/しばやん @shibayan

  • SSL/TLS証明書の管理がしんどい
    • 12ヶ月に一回位の作業
    • 認証局からのメールで期限を思い出したり忘れたり
  • DV証明書発行の流れ
    • 認証局にCSRを投げる
    • ドメインの所有を確認する
      • whoisに登録されているメールアドレスにリンク送信、指定されたTOKEN入のファイルをサーバに置く、DNSで指定されたレコードを追加するなど
    • 証明書が発行される
      • 中間証明書と一緒にサーバに配置したり、PFXにしたり
  • 自動化されない理由
    • 自動化が難しい作業ばかり：CSR作成、ドメイン所有の確認、証明書と秘密鍵の配置
    • 12ヶ月ごとなので、手動でもなんとかなっちゃう雰囲気（自動化のコストが割に合わない）
    • そもそも認証局が自動化前提の作りじゃない
  • 更新忘れると
  • 楽にしようとする動き
    • クラウドベンダが認証局をもつ：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に感謝を
1
4
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
4

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?