読者です 読者をやめる 読者になる 読者になる

ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

4/26(水)、「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」参加レポート

f:id:takigawa401:20170426210316j:plain

はじめに

 東京丸の内:株式会社IDOMさんで開催されたGitHub社・クラスメソッド社の合同開催勉強会「GitHubとクラスメソッドの勉強会〜GitHub x AWSの最新DevOps事情〜」に参加してきました。以下、聴講メモ。


classmethod.connpass.com


メモ

開催概要・諸注意
  • How we ship GitHub
    • スピーカー
      • GitHub池 田タカフミさん(@ikeike443)
        • GitHubは入社するとGitHubのアカウント名のままメールアドレスが作られる
        • セキュリティ強固だからクレジットカード番号とかウェルカム
    • 最近のGitHub
      • 企業向けもガンガン
      • Developer 個人
      • Team チーム
      • Business ビジネス用途
      • GitHub Enterpriseという呼び方はだんだん無くなっていく、Businessプランに集約
    • DevOps
      • 色んな人が色んな意味で使ってる
        • インフラ効率化
        • リリース自動化
        • ただの何かのツール
      • 大事なのは
        • 価値を無駄なく遅滞なく届けること!
    • 近年起きていること
      • アジャイル
        • 三角形はさかさまに
          • スコープがFix、リソースとタイムを動かす
          • →リソースと時間がFix、スコープを動かす
          • →世の中の変化の方が早いので
        • イテレーティブに開発しましょうね
      • コラボレーションがやりやすく
        • 中央集権型→分散型へ
      • CI
        • 必須のプラクティス
      • Continuous deliveryy
        • 今のDevOpsブームが目指しているところ
      • Continuous deployment
        • 常に本番にデプロイされている状態
        • ここまで行くべき
          • ネットフリックス
          • GitHubでは?
            • 数十回デプロイ/日
            • GitHubberは世界中に散らばっている
              • 60%はリモート
              • 日本は11人
                • 実際にはもうちょっといる
              • 米国が明らかに多い
                • 米国各地に散らばっている
              • 地理的にもタイムゾーン的にもバラバラ
            • どうやっているか?
              • GitHub Flow
                • Guide.github.com
                • Masterを
                • 常にデプロイ可能な状態に保つ
                  • 本番とイコールに
                • 必ずブランチを作って開発
                  • 生存サイクルを短く
                • 溜め込まずすぐPull Requestを作り、フィードバックをもらう
                  • Hubotが大活躍
                • Pull Requestブランチを各環境にリリース
                • 問題ないものだけMasterにリリース(マージ)
                  1. もし現在のMASTERブランチの内容がPull Requestブランチに無い場合は、まずMSTER→Pull Requestにマージ
                  2. もう一度テスト
                  3. Masterにコミット
              • Hubot(ChatOps)
                • ディスカッション上で重要な役割
                • OSSチャットボットの仕組み
                  • GitHubで一番働いてるのは人間じゃない!
                • チャット上で様々なオペレーションを行う
                • なぜチャットか
                  • Shared Console
                  • 誰がやっても同じ結果が出る
                  • 他人がやってる様子をチャット上で見て学べる
                  • いつでもどこでもリモートワーク
                    • デプロイだけならスマホでもできる
                      • さすがにコード書くのにはPCが必要
                  • Pull Requestリリース時に、自分がどこにリリース可能か、教えてくれる
                  • Deplyment API
                    • チャットコマンド上で手軽にリリースできる
                  • 「queue for github
                    • プロダクションへのデプロイ待ち状況をHubotが教えてくれる
                      • 待ちが発生している間は他の人がデプロイはできない
                  • Deployment confidence
                    • デプロイしたものが本番環境でどのように動作しているかを確認できる
                  • 様々な形での支援
                    • 自動でISSUEを立ててくれる
                    • etc
                    • チャットやグラフで確認可能
            • 様々なことを全てChatで
              • CIのセットアップ
              • 営業的な見積
              • メンバーの居場所通知
              • Google Map確認
              • 画像(ランダム)
              • GIF画像
              • 近くにいる人
              • メンバーのプロフィールをhubotが紹介
            • 様々なツールを活用
              • GitHub
              • Hubot
              • Slack
              • Janky
              • Heaven
              • Heroku
              • gPanel
              • sentinel
              • etc...
  • まとめ
    • 市場のニーズはすごいスピードで変わっていってる
    • DevOpsは必須
      • さらにその先へ
    • リモートで非同期に
    • ChatOpsは企業をグローバルかつフレキシブルなスタイルに
    • AIが絡んでくる?
DevOpsとAWSサービス
    • スピーカー
      • 千葉 淳さん
        • クラスメソッドAWS事業部
        • 自動化大好き
        • ゼルダ毎日やってる
    • 会場アンケート(挙手)
      • アプリやってる人
        • 半分くらい
      • インフラやってる人
        • 半分くらい
      • AWSやってる人
        • けっこう
    • DevOpsとは?
      • 開発者と運用者が協力した開発手法(Wikipedia)
      • 安全に素早くリリースするための仕組み
        • 属人化の排除
          • 「あの人なら知ってる」をなくす
          • 手作業をなくす
          • デリバリの自動化
            • ビルドからデプロイまで
          • コードで管理
        • 開発の効率化
          • チームコラボレーション
            • GitHub
            • Backlog
            • Slack
            • Atlassian
          • 小さくたくさんリリース
        • 安全なリリース
          • デプロイ自動化
          • フローの整理
            • 承認とか
        • 柔軟性
          • バージョンアップ
          • セキュリティパッチ
          • スケールアップ・スケールダウン
        • モニタリング
    • DevOpsの目的
      • ビジネスに使う時間を増やす
        • デプロイ:月1回→毎日10回
        • 運用者:10人→3人
      • -
    • CIとは?
      • ビルド・テストの自動化
      • 小さくたくさん回す
    • 継続的デリバリー(CD)とは?
      • CIにデプロイまで含む
      • 統合テスト
    • AWSサービス紹介
      • CodeCommit
        • バージョン管理
        • コードビュア
        • SSH(鍵登録) or HTTPS(ID/PW)で接続可能
        • コミット一覧
        • コミット履歴
      • CodeBuild
        • フルマネージドなビルド環境
        • インフラ管理不要
        • サーバスペックを選択可能
        • 数クリックでビルド環境を作成
        • コンテナを利用したクリーンな環境でビルド
          • コンテナを指定可能
        • ビルド環境のスペックを指定
        • ビルド自動化
        • 実行結果・ログをコンソールで確認可能
        • 環境変数の設定が可能
      • CodeDeploy
        • フルマネージドなデプロイサービス
        • CodeDeployエージェント経由でコマンドを実行
        • 数1000台の環境にスケール可能
        • ローリングアップデート Blue/Greenデプロイ
        • 自動化
        • 画面で確認可能
        • デプロイとプロビジョニングを混ぜない!
          • デプロイ:アプリケーション
          • プロビジョニング:OS・ミドルウェアの設定
          • デプロイとプロビジョニングはライフサイクルが異なる
            • 同時に行おうとすると柔軟性を損なう
      • CodePipeline
        • ビルド・テスト・デプロイ・承認などのワークフロー管理
      • CodeStart
        • ここまでのCodeXXXを使ってCI/CD環境を一発で作成できる
      • マイクロサービス
      • 他色々
        • 時間がないので猛ダッシュで
      • サービスをどう選ぶ?
        • 時間がないので後で見てね♪
    • 実装例
      • 例1:CI/CD EC2でBlue/Greenデプロイ
      • 例2:CI/CD ECS
    • まとめ
      • 安全に早くたくさんリリース
      • ユーザーに提供する価値を増やす
      • リリースフローの見える化、自動化
      • モニタリング可能に
      • 開発者・運用者・経営者、三方良しに!


GitHub EnterpriseとAWSを組み合わせたCDP
    • スピーカー
      • 中山幸治(github:knakkayama)
        • オンプレサーバの運用3年
        • AWS歴1年
    • 注意事項
      • 現時点の情報なのでアップデート情報は逐次追ってね
      • Ops寄りな内容多め
    • AWSを使う上での基本姿勢
      • マネージドサービスの利用を検討すること
        • 安定性
        • 他サービスとの連携
        • 運用負荷の低減
        • 自分たちで極力作らない
      • 標準サービスでは要件に会わない場合に自分たちで作る
      • 会社が投資すべきビジネスロジックに集中して取り組む
    • GHEを使う上での基本姿勢
      • GHE自身の設定はいじらない
      • GHEのアップデートで/data/user/以外すべて上書きされるため
      • GitHubが提供してくれる標準機能を利用する
        • 運用負荷を低減した状態でGHEを活用する
  • -
    • Cloud Design Patternの紹介
      • GHEをインターネットに公開したくない
        • セキュリティ上要件的に社外にソースコードを置きたくない
        • プライベートリポジトリをPublicにしてしまった
        • アクセスキーをコミットに含めてしまった
        • 社内LDAPで管理したい
  • ここから先は情報量が多すぎて書ききれないので後日公開資料に任せた!


感想

 とりあえず「GitHubすげえな!」と。チャットってあんなに活用できるもんなんですね。正直ビックリしました。
 同様にhubot凄い。オレの友人に頻繁に承認欲求を満たすために褒めることを要求してくるメンドクサイ奴がいるんですが、そいつのメンタルも管理してくれねーかな。(冗談ですよ、ジョーダン)


 個人的にはお二人目の千葉さんの発表はかなり参考になりました。ちょうどAWS使い始めたばかりだというのもあり、サービス概要を把握してなかった、というのもありますが、今すぐ活用できそうなサービスがあったのも個人的には嬉しかったです。早速明日試してみようかn……いや、明日はダメだ、見積資料作らないとマズイ。


 逆に三人目の中山さんのお話は、そもそも情報量が多かったことと、かなりディープな内容だったこともあって、AWSGitHub Enterpriseも初心者なオレはあっという間に振り落とされました(笑)。最初の事例くらいまでは理解できたんですけどねぇ、GitHub Enterpriseってそんなに色々やんないと使いにくいモンなのかな? 全然使い込みが足らないオレには、その辺がいまいちピンと来なかったです。でもまぁ実際にニーズがあってお客さんがあっての事例でしょうから、必要なんだろうなぁ。



 それはそれとして、クラメソさんの勉強会って、だいぶ久々(数年ぶり?)に参加しました。Adobe Flexとかの頃にはよく参加させて頂いたんですけど。オレ自身、遅まきながらここ最近になってAWSを触り始めたので、また積極的に参加したいですね。


f:id:takigawa401:20170426210337j:plain