Ansible 2.5 におけるネットワークモジュールのトピック
- @akira6592
- 横地晃さん(エーピーコミュニケーションズ)
- https://www.slideshare.net/akira6592/ansible25rc1-nw
- https://qiita.com/t-tkgh/items/79479d553784e2fe04c6
Ansibleとは
- 構成管理ツール
- Simple
- Powerful
- Agentless
Ansibleのネットワーク対応
- SSH
- NETCONF
Ansible2.5
- 2018/3リリース予定
- 変更点色々
- ネットワークモジュールにフォーカス
ネットワークモジュール
- フォルダ構成のベストプラクティス公開
- group_varsの利用
AWS Lambdaで作る GitHub bot
- @siroken3
- 佐々木健一さん(メルカリ)
- SRE
- https://speakerdeck.com/siroken3/github-bot-made-with-aws-lambda
GitHub bot
- PRにコメントで何かしてくれる
- issueに自動的にラベリング
- PRの内容チェック
- GitHubAPIは多機能
PRのコメントに反応
ライブラリ
- @octcat/rest
- Apex
- デプロイ
- http://apex.run/
デモ
Lambda -> GitHub
SNS -> Lambda
GitHub -> SNS
まとめ
- システム関連携が大変
- GitHubAPIのドキュメント重要
運用の負担を減らすログ送信システムの設計
- @oshiumi
- 鴛海太一さん(Aiming)
- https://www.slideshare.net/taichioshiumi/ss-89764642
ログ送信機構
- 従来
- flientdとかでBigQuerynに投げる
- 見直し後
- GCP活用
- Cloud Storage
- バックアップ用
- Cloud Pub/Sub
- ログ投げる側と受ける側の責務分けられた
要件
- 欠損なく重複なく送信したい
- 簡単な加工もしたい
- BQのpartitionやテーブル振り分け
- Pub/Subの重複排除
- 人の作業を減らしたい
アーキテクチャ
- Extractor -> Transformer -> Loader
どこまで自動化するか
- 手動対応しないといけないケース
- スキーマが違うログ
- 例外の種別を明確にすることが大切
例外設計
- warn
- 想定されている
- 自動対応化
- error
- 想定されている
- 手動対応要
- fatal
- 想定されていない
各プロセス
- 疎結合でべき等
- 気軽に再実行
- fatalが起きても他プロセスに影響しない
まとめ
- 作業者の負担をできるだけ減らす
- 例外種別をしっかり分ける
- 冪等性の担保
退屈なブラウザ作業をpuppeteerにやらせたいお話
- @tadashi
- 根本征さん(メルカリ)
- QA-SET
- https://speakerdeck.com/tadashi0713/tui-qu-naburauzazuo-ye-wopuppeteerniyarasetaiohua
ブラウザ作業の自動化
- 繰り返しやる作業を自動化
- Seleniumで作った
- Seleniumじゃなくてもいいんじゃないか
- 複数ブラウザでやらなくていいし
- スクリプト作るのも面倒
- https://chrome.browserless.io/
- https://github.com/joelgriffith/browserless
やりたいこと
世界のカンファレンスから~SeleniumCamp 2018~
- @mkwrd
メルカリの自動化への取り組み
- @k-oguma(メルカリ)
- SREチーム
- https://www.slideshare.net/KatOguma/automationnight2-lt-89891485
メルカリの自動化
node-core-utils
- @hiroppy
- Yuta Hiroto(ドワンゴ)
- N予備校とか
- https://abouthiroppy.github.io/slides/node-core-utils/
Nodeそのものの自動化
- jenkinsでCI
- いろんな環境で動かないといけない
- Bot
- issueにラベル付け
- node-core-utils
node-core-utils
- git-node
- コミットのルールのチェック
- ncu-team
コミットのルール
- masterに直接pushする
- mergeボタン押すわけではない
- ルール
- 24時間待つこと
- 世界各地にいるから
- レビューは2人以上
- タイトルの長さとか
<ecosystem>: <title> <description> PR-URL: <pr id> REFS: <ref id> ISSUES: <issue id> Reviewed-By: <name>:<email address> Reviewed-By: <name>:<email address>
- 24時間待つこと
自動回帰テストフローとGitHub Apps
GitHubApps
- GitHubAPI
- API実行によるレポジトリ操作
- Webhook
- レポジトリに起きたイベントに反応
OAuth Apps
- OAuthApps
- GitHubアカウントに紐付く
- GithubApps
- レポジトリに紐付く
- チームでやるならGitHubApps
求めていたもの
- スナップショットの差分を見てテスト
スナップショットの更新要件
- 差分があったか
- その差分は意図したものか
- 意図してればマージ
OSS作った
デモ
まとめ
- GithubAPI
- CIの結果をPRへコメント
- Webhook
- レビュー結果に応じてコメントを更新