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

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

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

ぐるなび × GitLab

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

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..

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

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

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

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

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

その他：試行錯誤したこと 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にて変更可

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

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

ぐるなび × Rancher

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

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

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

リリースまでの道程で感じたこと ● 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はサポートされていくのか 不安　＜＜＜　期待

● 「それコンテナでできない？」 ● 「コンテナでリリースしたい」 まだまだ多大な検証と後押しが必要 リリースしてからの変化 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

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 記述削除

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

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

ぐるなび × GitLab × Rancher

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

ぐるなびの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

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

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

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

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

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

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

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

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

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

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

補足：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

まとめ ぐるなび × 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機能は様子見

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