ぐるなび×GitLab×Rancher

Rancher Meetup Tokyo #13
https://rancherjp.connpass.com/event/85028/
こちらでお話させていただいた資料です

Transcript

1. ぐるなび × GitLab × Rancher
   株式会社ぐるなび
   インフラストラクチャサービスグループ
   遠藤 耕平
   Rancher Meetup Tokyo #13 (GitLab x Rancher特集)
   

   View Slide

2. 自己紹介
   ● 株式会社ぐるなび（2010入社）
   ○ インフラストラクチャサービスグループ（サーバチーム）
   ○ サイトのインフラ構築 /運用
   ○ インフラ作業の自動化
   ○ 性能試験, 障害試験, 障害対応
   ○ etc..
   ● 出没界隈
   ○ Cloud Native
   ○ Microservice
   ○ Chaos Engineering
   ○ etc..
   

   View Slide

3. Agenda 1. ぐるなび × GitLab
   2. ぐるなび × Rancher
   3. ぐるなび × GitLab × Rancher
   

   View Slide

4. ぐるなび × GitLab
   

   View Slide

5. ● お話する内容
   ○ Omnibusを導入して運用している方向け
   ○ ぐるなびでの利用
   ○ 運用を始めてからの悩み
   ○ 構成/運用のポイント
   ※ GitLab CI/CDについては後半ご説明します
   

   View Slide

6. GitLabとは
   VCS にとどまらない Complete DevOps を実現するツール
   Plan Milestones, Issue, Boards, etc..
   Create Project, Commit Graph, Merge Request, Web IDE, etc..
   Verify SAST, DAST, GitLab CI/CD, etc..
   Package Container Registry
   Release GitLab CI/CD, GitLab Pages, Chatops(Mattermost), artifacts, etc..
   Configure Auto DevOps, Integration kubernetes clusters, etc..
   Monitor Server Monitoring (Prometheus), App Performance Monitoring, etc..
   

   View Slide

7. GitLabを取り巻く生き物たち
   fox.png
   images/404/illustration.png
   images/logo.png
   

   View Slide

8. ぐるなびでの利用規模
   Users：1300+
   Groups：250+
   Projects：3500+ Use Omnibus Package
   Active Users : 40~50
   Active SSHs : 20~30
   

   View Slide

9. リポジトリホスティング導入の歩み
   2014~
   ~2011 2011~
   入社前より存在していたので導
   入の経緯は不明。開発者/デザイ
   ン/マークアップが利用。2011年
   頃に開発者からGitやMercurial
   の要望が出てきて検討を開始
   GitとMercurial共に利用できる
   Rhodecodeを導入。Subversionは
   利用継続。一方でRhodecodeのみ
   では実現できなかった要件を
   Backlogで満たすといったホスティン
   グ戦国時代
   デプロイ環境の抜本的な見直しと共にホスティ
   ングの見直しに着手。オンプレでの運用を前提
   に検討し、最終的にGitHub Enterpriseと
   GitLabに絞られ、金額面を考慮しGitLab導入
   に決定。
   Subversion/Rhodecode/Backlogの利用も現
   在はなくなりGitLabに統一された
   

   View Slide

10. 運用を始めてからの悩み
    ①ロゴのインパクトが強すぎた
    ②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の直編集はよくない）
    →　バージョンアップで随時対応
    

    View Slide

11. 構成/運用のポイント
    ● バージョンアップを毎月実施する（前頁①,②,⑤）
    ○ 機能追加, バグ改修, 性能改善, Security Fix, etc..
    ● オールインワン構成でも事足りる（前頁③）
    ○ https://docs.gitlab.com/ee/install/requirements.html#hardware-requirements
    ○ 2000users = 4コア/16GB
    ○ 足りない場合はスケールアップでの対応
    ● 容量拡張目的ならストレージはLVMで（前頁④）
    ○ NFSにする場合はNFSリクエストを分散できる構成を検討
    

    View Slide

12. その他：試行錯誤したこと
    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. sshdのMaxStartupsの変更
    a. デフォルトの設定は「10」
    b. Jenkinsなどでリポジトリをポーリングするジョブな
    どが多いとすぐに到達
    c. /etc/sshd/sshd_configにて変更可
    

    View Slide

13. GitLab関連の書籍
    GitLab のコンセプトからセットアップ、各機能詳細に至るま
    で幅広く解説されている日本で初めての GitLab 本
    (2018/02/01発売)
    インフラ管理のためのCI手法の紹介とベストプラクティスを、
    GitLab や Ansible をはじめとした様々な OSS で紹介
    (2018/06/18発売)
    

    View Slide

14. 明日22日は...
    Major version 11.0 Release!!
    

    View Slide

15. ぐるなび × Rancher
    

    View Slide

16. ● お話する内容
    ○ これからコンテナでリリースする方向け
    （技術的にというよりは、マインド的な）
    ○ リリースまでに感じたこと
    ○ リリースしてからの変化
    ○ Rancher 2.0 に向けて
    

    View Slide

17. Rancherとは
    ● Rancher Kubernetes Engine (RKE) によるk8sクラスタの追加/インポート
    ● EKS / GKE / AKS などクラウド上の Kubernetes クラスタも管理
    ● Helm 対応のカタログ機能を有する
    ● Ingress リソースもサポート
    ● 認証, Role Based Access Control (RBAC), Pod Security Policy
    ● etc..
    http://www.rancher.jp/releasenote/v2.0.0/
    Complete Container Management Platform for Production Environment
    

    View Slide

18. ぐるなび
    ×
    ● 半年以上の 稼動実績
    2017年11月～（v1.6, cattle）
    ● 今年3月に 1サービス追加
    更なる追加要望も
    ● 現在まで No trouble
    

    View Slide

19. リリースまでの道程で感じたこと
    ● Microservice
    ● 作業コスト削減
    ● Infrastructure as Code
    ● etc..
    ○ Cloud Native
    Motivation
    Support
    &
    Activity
    Rancher 2.0
    ● 手厚いサポート
    ● Rancher Labs のフォロー
    ● Rancher Partner の方々の助言
    ● Meetupでの活動が活発
    ● 様々な資料が簡単に見つかる
    ● Slackで気軽に質問ができる
    http://slack.rancher.jp/
    ● デリバリースピードの向上
    ● Blue/Green Deployment
    ● 膨らむ期待
    ○ Kubernetes
    ○ alphaの更新が早い
    ● 一方で多少の不安
    ○ cattleで進めた件
    ○ 1.6はサポートされていくのか
    不安　＜＜＜　期待
    

    View Slide

20. ● 「それコンテナでできない？」
    ● 「コンテナでリリースしたい」
    まだまだ多大な検証と後押しが必要
    リリースしてからの変化
    ontainer first
    C
    ● Container ベースでの検討
    ● 物理/仮想では難しいサイクルの実現
    アプリのみではなくインフラ領域にも適用可
    I/CD Pipeline
    C
    ● ServiceMesh
    ○ Circuitbreaker / Timeout / Retry..
    ○ Fault Injection (Chaos Engineering)
    ○ Canary release
    ● etc..
    loud Native
    C
    ● 物理/仮想からのコンバートは大変
    ● 可搬性に優れたコンテナを横展開
    ○ 突発的なリソース増強時など
    　→　これから検証
    Ioud Service
    C
    

    View Slide

21. Rancher 2.0 に向けて
    When will Rancher v2.0 be ready for use in production?
    We anticipate Rancher v2.0 will be
    ready for production use during
    the second quarter of 2018. Until
    then, please continue to use v1.6
    in production.
    We anticipate Rancher v2.0 will
    be ready for production use
    during the first quarter of 2018.
    Until then, please continue to
    use v1.6 in production.
    2017/10/09 2018/05/16
    https://github.com/rancher/rancher/issues/10054 https://rancher.com/docs/rancher/v2.x/en/faq/
    2018/05/18
    記述削除
    

    View Slide

22. 1. 2.0に移行する
    ○ yamlを自分たちで変換
    ○ UI操作で全部作る
    2. 2.1が出たら移行する
    ○ 移行ツールを利用
    Rancher 2.0 に向けて
    Rancher 1.6 Rancher 2.x
    ×
    export import
    convert
    upgrade
    ● 移行に避ける時間や運用規模により手段は変わる
    ● 2.0での＋αを盛り込む予定なら早め検証は ○
    ● 動作テストのシナリオがあれば安心
    check edit
    

    View Slide

23. ぐるなび
    ×
    ● 本番サービスの導入実績
    ● Rancher 2.0 への移行
    ● CI/CD 実行環境としての利用
    ● Cloud Native な Apps の検証
    ● クラウド展開
    のこれから
    

    View Slide

24. ぐるなび × GitLab × Rancher
    

    View Slide

25. ● お話する内容
    ○ ぐるなびの CI/CD事情
    ○ GitLab Runner について
    ○ GitLab × Rancher による CI/CD計画
    

    View Slide

26. ぐるなびのCI/CD事情
    OS
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job
    job job
    job
    job
    job
    job job
    job
    job job
    ● Many Jenkins processes on one server
    (not container)
    ● Many jobs in one Jenkins
    ● この構成が4台..
    ○ 計75+ Jenkins
    ● 構成変更の希望が増加
    ○ モノリシックのため困難
    ● サービスによってはジョブが非常に多い
    ○ 1000 jobs / 50 views
    ● どのリポジトリに関連するジョブか？
    ○ 紐付けが容易ではない
    ○ 1 service != 1 repository ! = 1 job
    

    View Slide

27. Hyper Monolithic Jenkins の改善
    ● Monolithic → Microservice
    ○ サービス毎にCI/CD実行環境を提供可能
    ○ サービス毎に言語/バージョンを選択
    ○ 追加、変更が容易
    Microservice なCI/CD実行環境
    = Container でCI/CDを実行する
    

    View Slide

28. ■ GitLab Runnerとは
    ● GitLab CI/CD 機能を提供
    ○ Omnibus Packageでインストール
    ○ GitLabサーバとは別のサーバへのインストール推奨
    ● どのExecutorでジョブ実行するかを定義
    ○ Executor = ジョブを実行する環境
    ■ shell, ssh, docker, kubernetes (= Rancher2.0!!)
    CI/CD with Container
    RUNNER
    

    View Slide

29. GitLab Runner × Rancher ?
    RUNNER
    ×
    できました
    

    View Slide

30. Running GitLab CI/CD with Rancher
    GitLab
    Service A
    Contents
    .gitlab-ci.yml
    Service B
    Contents
    .gitlab-ci.yml
    Rancher 2.0
    GitLab
    Runner
    Shared
    config.toml
    GitLab
    Container Registry Image A Image B
    Running
    Service A's
    Job
    Image A
    Running
    Service B's
    Job
    Image B
    Edit/Commit/Push
    check/
    response
    execute/
    response
    (Build/) Push
    Pull
    

    View Slide

31. Running GitLab CI/CD with Rancher
    # gitlab-runner register --non-interactive \
    --name 'rancher-executor' \
    --url 'http://mygitlab.local' \
    --registration-token 'XXXXXXXXXXXXXXXXX' \
    --tag-list rancher-dev \
    --executor 'kubernetes' \
    --kubernetes-host 'https://myrancher.local/k8s/clusters/c-8hhc2' \ …①
    --kubernetes-ca-file /etc/kubernetes/ssl/certs/serverca \ …②
    --kubernetes-image 'mygitlab.local/images/centos:7.3.1611' \
    --kubernetes-bearer_token 'token-XXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' …③
    ① RancherのクラスタのDashboard -> 「Kubeconfig File」-> 「server」
    ② Global -> 「Settings」 -> 「cacerts」
    ③ API & Keys より「Add Key」で作成したときに表示される「Bearer Token:」
    Runner: 10.7.2-1
    GitLab: 10.7.3
    Rancher: v2.0.1
    動作確認したVersion
    

    View Slide

32. 以上の検討結果を報告 (2018/01)
    RUNNER
    ×
    ( ﾟдﾟ) ... Where is Jenkins??
    

    View Slide

33. Jenkinsも必要
    ● 大きな変更は混乱を招く
    ○ 社内的な（恐らく世間的にも）実績では
    GitLab CI/CD < Jenkins
    ● Jenkinsの良い点を捨てる必要はない
    ○ 豊富なPlugin
    ○ Pipeline処理の決め細やかさは
    Jenkinsの方が直感的でわかりやすい
    まずはJenkinsをコンテナ化しよう
    （それをGitLab CI/CD使ってRancherにのせよう）
    

    View Slide

34. Jenkinsのコンテナ化
    ● Rancher側設計
    ○ JENKINS_HOME 用の Persistent Volume を用意
    ○ IngressでJenkinsのPrefix URL毎に振り分け（=Serviceの単位）
    ○ JenkinsのPrefix URL毎にNamespaceを分ける
    ● Jenkins側設計
    ○ Dockerfileを作成する（Master/Slave）
    ○ 変更が発生し保持するべきデータは全て JENKINS_HOME にまとめる
    ○ 予めインストールするべき Plugin をリストアップ & 自動インストール
    ● GitLab側設計
    ○ Prefix URL毎のプロジェクトを払い出しと同時に作成
    ■ Dockerfileと .gitlab-ci.yml
    

    View Slide

35. GitLab
    RUNNER
    Rancher 2.0
    Ingress
    Jenkins Containers
    Service A Service B
    Service C Service D
    Kubernetes Cluster
    Node
    Node
    Node
    Master
    GitLab
    Service A
    Dockerfile
    .gitlab-ci.yml
    DockerImage
    Service B
    Dockerfile
    .gitlab-ci.yml
    DockerImage
    Service C
    Dockerfile
    .gitlab-ci.yml
    DockerImage
    Service D
    Dockerfile
    .gitlab-ci.yml
    DockerImage
    Access updated
    jenkins
    Edit/Commit
    /Push
    Build/Push
    kubectl
    apply
    

    View Slide

36. Happy!! (in the future)
    ● Jenkinsの利便性が向上
    ○ 使い慣れているJenkinsを提供
    ○ 変更作業権限を開発者に譲渡
    ● GitLab CI/CDの実績
    ○ 開発者の目にも触れる
    ○ インフラも実績を得ることができる
    ● Rancher 2.0の実績
    ○ 稼動実績
    ○ ノウハウの蓄積
    ■ Ingress, Persistent Volumeの知見も得ることができる
    

    View Slide

37. 補足：GitLab Kubernetes Cluster Integration
    GitLab 10.7.3 / Rancher 2.0.1 時点では 連携に工夫が必要
    ● Rancher
    https://github.com/rancher/rancher/issues/13058
    ● GitLab
    https://gitlab.com/gitlab-org/gitlab-ce/issues/45796
    ● kubeclient
    https://github.com/abonas/kubeclient/issues/318
    

    View Slide

38. まとめ
    ぐるなび × GitLab × Rancher
    × Jenkins
    ● ぐるなびと GitLab
    ○ 色々と工夫して利用
    ○ 特にバージョンアップ大事
    ○ GitLab 11.0 間近
    ● ぐるなびとRancher
    ○ No trouble (1.6, cattle)
    ○ 導入によりもたらされた「 4つのC」
    ○ Rancher 2.0に向けて
    ● CI/CD × Container = GitLab × Rancher
    ○ Remember Jenkins..
    ○ Kubernetes integration機能は様子見
    

    View Slide

39. ご清聴ありがとうございました
    

    View Slide