Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ぐるなび×GitLab×Rancher

endo-k
June 21, 2018

 ぐるなび×GitLab×Rancher

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

endo-k

June 21, 2018
Tweet

More Decks by endo-k

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  4. ぐるなび × GitLab

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  15. ぐるなび × Rancher

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size slide

  24. ぐるなび × GitLab × Rancher

    View full-size slide

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

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size slide

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

    View full-size slide