Rancherを活用した開発事例の紹介　～Rancherのメリットと辛いところ～

Rancherを活用した
開発事例の紹介
~Rancherのメリットと辛いところ~
1(C) Recruit Technologies Co.,Ltd. All rights reserved.
ITS SRE ISG/ G

自己紹介
名前: 藤原涼馬
所属: リクルート
テクノロジーズ株式会社
業務内容:
インフラエンジニア
いろんなサービスのインフラ構築手伝い
最近はバックエンドのコード書いたりも
Docker
/Rancher歴: ほぼ1年
Rancher関連の活動:
Rancher JPコミュニティコアメンバー
Rancher meetup登壇
リリースノートの翻訳(v1.5.0とv1.6.0、あと他にもなんかあったはず)
Rancher JPのslackでしゃべる(素子のアイコンです)

リクルートテクノロジーズとは

リクルートテクノロジーズの役割
開拓
実装・展開活用・進化

目次
• 本発表の目的について
• プロジェクトの概要
• Rancherのプロジェクトでの活用について
• Rancherを使うメリット
• Rancherを使っていてつらいところ
• まとめ

本発表の目的
本発表を通じて以下の内容をざっくり
理解していただけると嬉しいです
• 具体的にプロジェクトの中でどんな形でRancherを利用しているのか
• Rancherを利用することで何が嬉しいのか、どんな効果があるのか
• Rancherのつらいところはどんなところか
• 結局Rancherってどうなのか
こうやれば良い!
といった虎の巻ではないです
(あくまでもイチ事例と使ってみての所感)。

プロジェクトの概要
プライベートクラウド基盤(Fleet)の構築プロジェクト
• 新規サービスの立ち上げを迅速化
• セルフサービス型でVM構築・OS設定・MW導入・NW設定を可能にする
ことで即応性と柔軟性を確保
今回の発表はこのプロジェクトでの
“クラウド環境を利用するユーザへのGUIとそのバックエンド”の
アプリケーションとコンテナ環境構築が範囲です。

システムの規模

Docker
Rancher/Cattle
システムの構成
アプリケーションとしてはREST APIによる連携を用いたマイクロサービス
アプリケーション本体はDB等も含めて全てコンテナ化
主要なもののみ、他にも多数のコンテナあり
コンテナ化されている
コンポーネント

開発体制概要
• アジャイルによる開発(特別なことはやっていないはず)
• Aチーム + Bチーム + インフラチームの3チーム体制(計
30人程度)
BチームAチームインフラチーム
マネジメント
(プロジェクトリーダーなど)
サービスの企画
DC管理(NW・ストレージ
のHWやVMWare周り)
・セキュリティ
など
技術統括

Rancherのプロジェクト内での活用について
プロジェクト内でのRancherの利用について
３つの視点から説明します。
① 環境構築
– 環境内におけるコンテナ構成、コンテナ間の関連をコード化
② ビルド※
– コンテナイメージのビルドと保存
③ デプロイ
– ビルドしたコンテナの環境への配置(既存コンテナの更新)
※ Rancher

① 環境構築
Rancherのカタログを用いて環境を記述
• 独自カタログを作成してコンテナ以上のレイヤについて環境全体を定義
• 独自カタログの作成方法についてはmeetup#4の資料を参照
https://www.slideshare.net/m-daichang/rancher-
compose?ref=https://rancherjp.connpass.com/event/47273/presentation/

② ビルド
Dockerfile
アプリケーション
コード
アプリケーション
コード
(単体テスト済み)
ビルド + 単体テスト
Jenkins
コンテナイメージビルド
Jenkins
コンテナ
イメージ
Container
Registry
1. ソースコードのビルドと
単体テストを自動実行
(コードプッシュ時・MR時に実施)
2. コンテナイメージのビルド
と保存を自動で実行
(特定ブランチでは自動実行・他は手動でパイプラインを実行)
特別なことは何もやっていません

③ デプロイ
1. スタック内のサービスを選択
2. イメージのタグ名そのほかを修正
3. アップグレードボタンをクリック
Rancher CLIも活用することで、ビルド+テスト+デプロイ
まで全てを自動化することも可能ですが、
そこまでは取り組んでいません

Rancherを使うメリット
① カタログによる環境構成のコード化
② ビルド・デプロイフローの定型化
+上記によるプロジェクト全体の雰囲気の変化
もちろん他にも細々とした部分はあります。

① カタログによる環境構成のコード化 (1/2)
• Dockerfileによって個別コンポーネントの動作環境をコード化
• カタログによって、環境全体をコード化
• 環境の面数を増やす際の手間を削減
短時間で確実に同一環境を構築することができるようになった
<開発面を増やす時でも所要時間は合計15分程度(待ち時間含む)>
GUI上で指定された
項目を入力し、
起動ボタンを
クリックすれば
立ち上げは完了

① カタログによる環境構成のコード化 (2/2)
全面的に環境をつくりなおすという
思い切った判断も軸に含まれるようになった※
短時間で確実に同一環境を構築することができようになった
<開発面を増やす時でも所要時間は合計15分程度(待ち時間含む)>
※

② ビルド・デプロイフローの定型化 (1/3) サービス更新の容易化
• GUIを使って、定型的にシステムを構成するサービスを更新できる
GUIで作業を完結できるので、
Docker CLIの知識がなくてもデプロイが可能になった
Jenkins
パイプラインを実行する
だけでビルド完了
(Dockerfileによって
パイプラインそのものの
複雑さも軽減できている)

② ビルド・デプロイフローの定型化 (2/3) 切り戻しの定型化
• 切り戻しが短時間かつ容易に実施可能できる※
何か誤りがあっても用意かつ確実に切り戻しできることで
エンジニアの学習コストとストレスを軽減できた
※ただしDBのスキーマなどが変更されていない場合に限る

② ビルド・デプロイフローの定型化 (3/3) 結果としてどうなったか
チーム内の全員が様々なコンポーネントの
デプロイを容易に実施可能になりました。
開発環境へのデプロイの頻度も多い日は10回/日を軽く超えています。
1. Docker CLIの知識がなくてもビルド・デプロイが可能
2. 切り戻しが確実にできる
上記2つを確実に実施できるようになった結果、
開発環境では積極的にデプロイ&テストが行われるように

Rancherをつかうことによるメリットまとめ
①カタログによる
環境構成のコード化
②ビルド・
デプロイフローの
定型化
障害発生時に
思い切った判断
(丸ごと作り直し)も
考慮に含められるようになった
チームメンバー全員が様々なコ
ンポーネントのデプロイを
実施できるようになった
デプロイ頻度が高くなり、
こまめなテストを行える
ようになった

Rancherをつかうことによるメリットまとめ
①カタログによる
環境構成のコード化
②ビルド・
デプロイフローの
定型化
障害発生時に
思い切った判断
(丸ごと作り直し)も
考慮に含められるようになった
チームメンバー全員が様々な
コンポーネントのデプロイを
実施できるようになった
デプロイ頻度が高くなり、
こまめなテストを行える
ようになった
開発メンバーが特定のコンポーネントだけでなく積極的に
色々なコンポーネントに関わろうとしているのは
強烈なメリットだと感じています

Rancherを使っていてつらいところ
① カタログの肥大化
② Rancherのアップデートが速い
③ 日本語情報が少ない
どちらかというと
”悩んでるので聞いてください”的
な内容になります

① カタログの肥大化
環境全体を単一のカタログに詰め込もうとするとカタログが肥大化。
• 単純にymlが大きくなって見通しが悪くなる
• Configuration Optionsの項目数が増える
• 現在、65項目(デフォルト値の指定はできるがやはりギョッとする & 心理的な障壁は大
きくなる、サービス単位でのデプロイと比較すると実施できるメンバーは少ない)
↓ Rancher zookeeper
完全に私見ですが、
• 一定以上のサイズになってしまったカタログは分割
• 定期的にConfiguration Optionsの項目を見直す
しかないと思います。

② Rancherのアップデートが速い
• 月一回のリリースという驚異のスピードに追従するのが大変
• 一度振り落とされると次回アップグレードしようとした時に辛くなります
アップデート手順自体はドキュメント※が充実しているので、
現時点では地道にフォローするしかないのかなと感じています。
(または求むLTS版)
※ https://docs.rancher.com/rancher/v1.6/en/upgrading/

③ 日本語情報が少ない
Rancher自体の日本語情報があまり多くないです(最近は事例含めて増えてきました)
) Qiita (2017/5/12 )
• 英語情報のキャッチアップ
• ここ(Rancher meetup)や懇親会、Slackで悩み相談
• 地道な学習 & 情報発信(Give & Givenを作る)
積もる悩み

Rancherを使っていてつらいところまとめ
①カタログの肥大化
② Rancherのアップデートが早い
カタログの分割
設定項目の見直しと削減
つらいところ解決策?
こまめなアップデート
③ 日本語情報の少なさ
• 英語情報のキャッチアップ
• コミュニティの活用
• 地道な学習 & 情報発信
コミュニティとして利用事例などの情報を集約して
ベストプラクティスを整理する??

逆にRancherなしだったらどうだったかと考えると、
完遂は無理だっただろうというのが所感です
まとめ Rancherを使っていてどうだったか、どうするか
メリット
について
つらいところ
• 一人のメンバーが単一のコンポーネントだけでなく、様々
なコンポーネントに主体的に携われるようになった
⇨ 継続
(メリットをより大きくするための方策を検討・検証することも含めて)
• 現時点で辛い部分はある
• 辛い部分を解消するための活動を地道にすすめる
⇨ コミュニティを経由した各種ノウハウの共有・
蓄積の活発化(meetup, もくもく会, ドキュメント日本語化)
コミュニティコアメンバー
として頑張る部分

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

Rancherを活用した開発事例の紹介　～Rancherのメリットと辛いところ～

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (19)

Similar a Rancherを活用した開発事例の紹介　～Rancherのメリットと辛いところ～

Similar a Rancherを活用した開発事例の紹介　～Rancherのメリットと辛いところ～ (20)

Más de Recruit Technologies

Más de Recruit Technologies (7)