operate_free_gitlab

55b7011f037e5da220c314e043e924e5?s=47 endo-k
July 13, 2018
480

 operate_free_gitlab

55b7011f037e5da220c314e043e924e5?s=128

endo-k

July 13, 2018
Tweet

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. ご清聴ありがとうございました