Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

コンテナ運用基盤 with OpenShift

838 views

Published on

Dockerコンテナで作ったシステムのOpenShift上での運用を検討した内容をLTしてみる。5分短いから全然ないです。
カタログ回りとクラスタリソースの管理あたりちょこっとだけ機能紹介してます。
機能の使い方的なところは収まらないので入れてないです。

Published in: Technology
  • Be the first to comment

コンテナ運用基盤 with OpenShift

  1. 1. コンテナアプリ基盤 運用WITH OPENSHIFT 2018/07/19 DockerMeetup LT資料
  2. 2. ■ Yoshihiro Kimura @ OpenStream ■ 最近の仕事 – AWS上でSolrCloud構築等 – Cordova x Angular で iOSアプリ開発 – (直近)Enterprise用途でOpenShift導入検証中 ■ SNS – Qiita: kimura-y ■ 趣味とか – ボルダリング – 読書 ■ その他 – スライドのセンスは勘弁してください(´・ω・`) – Docker歴半年ちょい
  3. 3. OPENSHIFT紹介 知ってる人はスルーでOK
  4. 4. OpenShift とは? ■ コンテナアプリケーション基盤 ■ Kubernetes + α ■ Origin :コミュニティ版 ■ Container Platform:エンタープライズ版 Base Image Source Environment App on Container Service Route Deploy Image Internet
  5. 5. OpenShift 導入のメリット ■ コンテナで比較的お手軽にCI/CDを導入可能 ■ コンテナオーケストレーション機能を比較的お手軽に導入可能 ■ クラスタ認証機能 ■ ポータビリティ等
  6. 6. カタログ運用
  7. 7. エンタープライズ開発 ■ 開発環境の構築方法不明 ■ インフラ準備遅い・高い ■ デプロイ手順が煩雑 ■ 構成が古いまま – JDK古い – ビルドツールAnt ■ プロジェクト毎にアーキテクチャがバラバラ – Java(Maven / Ant / sbt)、Ruby、Node、PHP ■ 求)リファクタリング ■ セキュリティ厳しい ■ 管理!管理!管理!そしてまた管理!
  8. 8. カタログ 様々なアプリ構成 に対応 独自テンプレート 作成可 実態はBuildConfigや DeploymentConfigの 集合
  9. 9. カタログでできること ■ カスタマイズ自由 – 構成古くても大丈夫 ■ カスタムベースイメージ作ればいいじゃない – ビルドがスクリプト化されてない? ■ スクリプト化すればいいじゃない(.s2i/bin/assemble) ■ ロゴも自由 – templateのyamlにicon-classを設定し、openshift-web-consoleのconfig-mapに外 部CSSを設定しましょう
  10. 10. BuildConfig 独自カタログのCI/CD ■ ベースイメージ → 独自ベースイメージ → アプリイメージ ■ Dockerfileからもビルド可能 Base Image Dockerfile/s2i App source 独自ベースイメージ Deploy Image BuildConfig
  11. 11. 作ってみた(Gitbookテンプレート) s2i-nodejs Gitbook リポジトリ Gitbook デプロイイメージ ローカル環境 ・VSCode ・Node.js ・gitbook ■ マークダウンでドキュメント作成 ■ ドキュメントをお手軽公開
  12. 12. 作ってみた(Gitbucketテンプレー ト) s2i-wildfly Gitbucket ビルドスクリプト Gitbucket コンテナ Gitbucket デプロイイメージ MySQL:v5.7 ベースイメージ MySQL:v5.7 コンテナ PVC PVC
  13. 13. リソース運用
  14. 14. マルチテナントでクラスタを使う ■ 独立した複数のチーム・組織で一つのクラスタを使う ■ あのプロジェクト使いすぎじゃない? ■ アクセス制限したい
  15. 15. リソース制限をかける ■ kubecli が使用するリソースを確保する – node-config.yaml の kubeletArgs に設定 – これを書けないとクラスタに負荷がかかるとkubecliが使用できなくなる ■ プロジェクト毎に制限をかける – ResourceQuota – LimitRange – 運用面倒そう。ClusterResourceQuotaの方を使いたい。 – BuildConfig / DeployConfig に resources.limits.cpu / memoryの設定が必須になる。設定されていない場合はビル ドもデプロイも始まらない。 ■ ユーザー毎に制限をかける – ClusterResourceQuota – 複数プロジェクトを跨って制限可能。
  16. 16. ユーザー管理 ■ OpenShift内部での管理 – User – Identity ■ パスワードとかはOpenShiftの外で管理している。 ■ 何で管理するかはmaster-config.yamlのIdentityProviderで指定。 ■ 紐づけるユーザーをUIDとユーザー名でyamlに書く必要がある。 – ClusterResourceQuota ■ ユーザー単位のリソース使用量制限 ■ ユーザー作成 – 一番簡単なhtpasswdで認証 – ユーザー作成はClusterResourceQuotaの設定を含めてスクリプト化 – せめてkeycloak入れようかな?
  17. 17. まとめ ■ カタログなら大概のことはできる – 独自のテンプレート作成 – 独自のベースイメージ作成 – ベースイメージのCI/CD ■ マルチテナントでのクラスタ運用 – リソース管理どうしようか ■ クラスタ固まらないように対策する ■ 特定のプロジェクトで使いすぎないように対策する – ユーザー管理どうしようか

×