operate_free_gitlab

Transcript

1. 運用フリーを目指す運用管理術 株式会社ぐるなび インフラストラクチャサービスグループ 遠藤 耕平 GitLab Meetup Tokyo #8: GitLab 11.0
2. 自己紹介 • 株式会社ぐるなび（2010入社） ◦ インフラストラクチャサービスグループ（サーバチーム） ◦ サイトのインフラ構築 /運用 ◦ インフラ作業の自動化 ◦ 性能試験, 障害試験, 障害対応 ◦ etc.. • 出没界隈 ◦ Cloud Native ◦ Microservice ◦ Chaos Engineering ◦ etc..
3. • お話する内容 ◦ オンプレで運用している方向け ◦ 運用を始めてからの悩み ◦ 構成/運用のポイント ◦ 運用フリーを目指して工夫したこと
4. ぐるなびでの利用(since 2014, v7.4) Users：1300+ Groups：250+ Projects：3500+ Use Omnibus Package (Community Edition) Active Users : 40~50 Active SSHs : 20~30
5. リポジトリホスティング導入の歩み 2014~ ~2011 2011~ 入社前より存在していたので導 入の経緯は不明。開発者/デザイ ン/マークアップが利用。2011年 頃に開発者からGitやMercurial の要望が出てきて検討を開始 GitとMercurial共に利用できる Rhodecodeを導入。Subversionは 利用継続。一方でRhodecodeのみ では実現できなかった要件を Backlogで満たすといったホスティン グ戦国時代 デプロイ環境の抜本的な見直しと共にホスティ ングの見直しに着手。オンプレでの運用を前提 に検討し、最終的にGitHub Enterpriseと GitLabに絞られ、金額面を考慮しGitLab導入 に決定。 Subversion/Rhodecode/Backlogの利用も現 在はなくなりGitLabに統一された
6. 運用を始めてからの悩み ①ロゴのインパクトが強すぎた ②Merge Requestが終わらない ④I/Oが思った以上に出ない ⑤reconfigureで元に戻る ③システムを複雑に構成してしまった • 視線を感じる • 「変えて欲しい」との声多し • 8.xで現在のロゴがデフォルトに • 先勝ち or 後勝ちが発生 • 該当Issueは未確認 • 8.xで改善を確認 • 各コンポーネントを別々のサーバで構成 • バージョンアップの調査検証が大変に.. （しなくなっていった） • 現在はオールインワンで構成 • リポジトリをNFS上に配置 • IOPSが10もいかず • getattrが4k/s （ACT/ACTで分散したらよかったかも） • LVMに変更すると30~50 IOPS • reconfigureすることは結構ある （no_proxyの追加など） • そのたびに独自設定が元に戻る （timeout/threshold tuning） • gitlab.rbで編集できるのが一番 （scriptの直編集はよくない） →　バージョンアップで随時対応
7. 構成/運用のポイント • バージョンアップを毎月実施する（前頁①,②,⑤） ◦ 機能追加, バグ改修, 性能改善, Security Fix, etc.. • オールインワン構成でも事足りる（前頁③） ◦ https://docs.gitlab.com/ee/install/requirements.html#hardware-requirements ◦ 2000users = 4コア/16GB ◦ 足りない場合はスケールアップでの対応 • 容量拡張目的ならストレージはLVMで（前頁④） ◦ NFSにする場合はNFSリクエストを分散できる構成を検討
8. その他：運用フリーを目指して工夫したこと 1. バージョンアップ作業の自動化 a. 22日直前がおすすめ i. 毎月22日がバージョンアップDay ii. 適用が早すぎるとバグを踏む 1. 10.3.0で503エラー多発(#41510) 2. 10.3.3まで修正が長引いた b. 機能テストで失敗したらロールバック 2. 機能テストの自動化 a. 全ての変更の事前キャッチアップは困難 b. 機能テストを実施＆自動化することで構成変更時 の異常を早期キャッチアップ i. Group/Project作成 ii. Commit/Push iii. Branch/Issue iv. Merge Request/Merge 3. ELK/EFKによるログの可視化 a. production_json/api_json ログ i. 「誰が」「どこで」がより明確に取得 b. 50xエラーを検知したら発砲 i. バグ/設定ミス/タイムアウト c. どのリソースが不足しているか i. Active users / IOPS / Projects etc.. 4. 応答遅延/50xエラー検知で再起動 a. zabbixエージェントを利用 b. APIのURLを監視し、以下条件でGitLab再起動 i. 応答遅延 ii. 50x系エラー c. 適切なエラーと対処については模索中
9. 運用フリー ≠ 放置 • Deprecationsの確認は大事 ◦ 11.0：APIv3の完全廃止 　　　Mattermostのオプション変更 　　　DSA SSHキーのサポート終了 　　　9.5未満のPostgreSQLサポート終了 　　　etc..（重たいものはメジャーバージョン時が多い） ◦ 事前に告知されているのでリリースページで確認する • 新機能の追加 ◦ GitLab Runner / ContainerRegistry / Auto DevOps / etc.. ◦ 運用をフリーにして浮いた時間で新機能の検証を！！
10. まとめ • 運用しやすい構成にする • 自動化で運用フリーにする • 浮いた時間でよりよい運用の輪を ◦ Deprecationsは確認大事 ◦ 新機能の追加
11. ご清聴ありがとうございました