「Kubernetes CI/CDパイプラインの実装」から見るコンテナ市場
こんにちは。レッドハット 北山晋吾です。
このたび「Kubernetes CI/CDパイプラインの実装」(2021.10)を出版いたしました!!
数多くの方々に関わっていただき、ありがとうございます。
この場をお借りしてお礼申し上げます。
出版に伴い、書籍執筆の視点で市場の変化を紹介できればと思います。
書籍から見るコンテナ市場の動向
今回は書籍の内容ではなく、(身勝手な) コンテナ市場のお話をさせてください。
本書を見たときに、すでにクラウドネイティブを牽引されている八百万の神がKubernetesやコンテナ(Docker)の名著を出しているのも関わらず、改めてまた…Kubernetes!?
と思われた方も少なくないのではないでしょうか。
自分も書店に行くのが好きで、色々な書籍を拝読させていただいています。
そこで、ふと感じたことが一つありました。
コンテナを活用したCI/CDの商業誌って…実は多くない？
皆さまはどのように感じるでしょうか？
近年では技術書典を始めとして、個人出版されている素晴らしいCI/CD本があります。それでも、CI/CD基盤でコンテナ開発を行い、Gitリポジトリのブランチ戦略を解説していく書籍は、まだまだニッチ分野という印象を持っています。
(ごめんなさい…あくまで主観です。)
そして、おなじみのTrailMapにも記述された『CI/CD』の内容を書籍化するには、以下を乗り越えていく必要があります。
- Kubernetes is Hard Way
- 僕が考えた最強のCI/CD論
- GitOpsへのシフト
- 「作る」から「使う」時代へ
これらについての主観的な感想を添えつつ、本書の執筆経緯を紹介していきます。
Kubernetes is Hard Way
Kubernetesを主体とした本の場合、はじめにKubernetesの複雑さにぶち当たります。
Kubernetesを使う限り、デフォルトリソース(API)を理解しないと始まりません。それに加え、コントロールプレーンなどの物理的な話もあります。それだけでまず1~3章くらいは最低かかります。入門書になればなるほど平易な言葉でこれらを表現するテクニックが必要です。
ほんと、CI/CDどころの話ではないです。
ということで。本書では、ほぼKubernetesのデフォルトリソースの話は省略しました。Kubernetesそのものは良書が多いので、是非いろいろ読んでいただきたいです。
僕が考えた最強のCI/CD論
いかに効率よく開発サイクルを早く、安定的に管理するのかが継続的デリバリ
と考えたときに、開発チームにとってそのパイプラインの改善は重要な仕事の一つです。これをいかにアプリに最適な形にカスタマイズし、適したツールを選択するかがベストプラクティスです。したがって、アプリケーションごとにその改善内容は異なってきます。
その結果、どうしても僕が考えた最強のCI/CDができあがります。
これ自体は悪い話でわけではありません。しかし、ここでお伝えしたいのは書籍のように一般化することが少し難しい分野だということです。
一方で本書で利用したTektonは、パイプラインの標準化を推進しています。いかにカスタマイズせずに使いこなせるかが鍵です。
このあたりは、CD Foundationが標準化を検討している分野です。属人化からの開放の一歩ということですね。
GitOpsへのシフト
近年GitOpsという手法が確立され、CIとCDの分離、そして開発者とリリースエンジニア(SRE)の権限分離がこれによって整いつつあると期待しています。
詳しくはコチラが素晴らしい内容なので是非↓↓
それでも、現場ではCIOpsのわかりやすさが浸透しているのも事実です。したがって、これまではCI/CDの書籍というとツールでパイプラインを作る話に近い内容でした。
一方、GitOpsを前提とするとGitリポジトリの構成が命です。これを正しく設計できるか、だれがCommit権限を持つのかという話が中心です。
GitOpsのように運用の方法論にシフトしていくと、ツール自体の機能は本質ではなくなっていきます。
本書ではこのあたりの変化について、すこしでも体感いただけるよう心がけて解説しています。クラウドネイティブ官能小説みたいにタラタラと話していたらごめんなさい。
「作る」から「使う」時代へ
ここまでの話でお伝えしたとおり、ツールの紹介といった時代は変わりつつあると感じています。
そして今回、実践ガイド というタイトルを卒業しました。
急に何のことかと思われるかも知れませんが、実はこれまでにも何冊か執筆に携わらせていただいていました。そのタイトルがどれも「〇〇実践ガイド」でした。(半分くらい自分で付けているのですがｗ)
実践ガイドと付けると、だいたいが前がツール名(AnsibleとかGitLabとか)になります。時代がそれで良かったんだと思います。
ただし、クラウドネイティブになると環境を「作る」ことよりも「使いこなす(運用)」ことが重要になります。構築やその機能の話をいくらしても、コマンド一発で実装は終わります。それよりも、これまでのやり方をどのように変えて、クラウドネイティブに適した運用プロセスを作るのかが主体になります。
ということで、祝）脱実践ガイド
まとめ
あくまで書籍という観点でお伝えしましたが、企業のコンテナ推進についても同じではないでしょうか。
Kubernetesを使い始めたときは、色々なリソースの使い方を学んでいくことになります。しかし、ある程度機能が把握できてくると、その標準化、自動化の素晴らしさに気づくと思います。すると、今度はこれをどのように使っていくのかが重要になってくると思います。そういった局面に立ったとき、本書に向き合っていただけると大変うれしいです。
最後に。購読いただいたみなさまと、一緒にクラウドネイティブ時代を築き上げていけることを願っています。
Red Hat on Red Hat at RHFT2019
なんか急に寒い季節になりましたねー。2019年ももぅクリスマスですよ。はやっ。こうやって日々おっさんに向かっていくんですね。
毎年恒例のAdvent Calendarの季節になりました。いつも本みたいに構成を考えてしまうので、全くブログとか苦手なんですが、この時期だけブログでも書いてみる気が起きるもんなんですね。
Advent Calendar万歳 (/･ω･)/
今回は『赤帽エンジニア Advent Calendar 2019 - Qiita』の1日目に投稿してみます。
特に話すネタもないのですが、キリ番ゲットしたので、2019/11/15に開かれたRed Hat Forum Tokyo 2019で自分が公演した内容を振り返ろうかと思っています。
使った資料はこちら↓
セッションタイトルの思案
今回もForumの1ヶ月位前にタイトルを考えて事務局に以下を提出。
毎年Red HatのSolution Architectが話すセッションが何個かあります。そのうちのOpenShiftを担当させていただきました。
セッションタイトル
The world after Kubernetes Native
-コンテナが日常化した世界-
セッション概要
Kubernetesを使いこなし、企業価値を高めている企業はどのようなプロセスを経たのでしょうか。
多くの企業がデジタルトランスフォーメーションの旗を掲げ、コンテナ化を推進しています。しかし現場では、迅速な開発体制だけでなく、ブラックボックス化したシステムの運用効率化が求められています。本セッションでは、Kubernetesがデファクトになったイマ、現場は何から取り組むのかを紹介します。
タイトル付けで考えること
はい。タイトルかっこいいですね。（なにが
いや、大きなセッション内容を考えるときは、まず本屋に行ってビジネス書を開く。これを毎回しています。
最近どんな本が流行っていて。なにが注目されているのかというのを知ったかしておくのが重要ですよね。
今回のタイトルはチョット前に流行っていた「アフターデジタル」をもじってみました。
ただし、よくあることなんですが、タイトルをイベントのかなり前に設定した挙げ句に、資料を前日に書き始めるので、結局なんやっけ？みたいな日々を過ごしています。今回も前日にイベントサイトでタイトルを見直す前までは、「The Day after Tomorrow」みたいなタイトルやったことくらいしか覚えてません。
セッションでお伝えしたかったこと
この内容としてお伝えしたかったのは、OpenShiftは「迅速に変わるビジネス要求に対して、開発者が環境を全く意識せずにコアビジネスのアプリ開発に集中できる世界」を創り出しているのだよ。というお話。
以上です。
みんなKubernetesの運用をしたいのか
Kubernetesって難しいじゃないですか。それを頑張って行く人材を社内で育てるんですっ！って言うのも素敵だと思うんです。
ただし、全企業がそうなるってわけでもないと思っていて。ビジネスのコアがサービス開発なのであれば、開発者は煩雑な運用に時間を割くよりも、開発に時間を割いたほうがいいんですよ。そしてKubernetesを導入するステップでいちばん重要なのが、その判断。この判断を失敗するとだいたいKubernetes導入も失敗する。
「Kubernetes導入の全体的な成功を決定するメトリックを定義し、事前に十分に理解すること」
↓そんな話の詳細がこちら。
今後のKubernetesの運用はどうなるのか
でもって、運用者はもっと動的に運用できるツールを作る。かっこよく言うと運用ノウハウをコード化できるSRE(Site Reliability Engineering)みたいに。という未来があるはずなんです。
もちろん、コアビジネスが運用じゃないのなら、マネージド・サービス化ってのも選択肢の一つになるはず。
そこでOpenShiftにはOpenShift Dedicated(OSD)やAzure Red Hat OpenShift(ARO)というマネージドの選択肢があります。そして、KubernetesにもAKSやEKS、GKEなどもあります。
こうしたものが当たり前になっていくと、いままでIaaSをおもりをしてきた運用者は、SREになるかマネージドを管理する役割に意識を変えていかないといけなくなるんですよね。これがいわゆる「DX(Digital Transformation)」(話飛躍したな…)。要は人間のモチベーションや運用プロセスが変わらないと、運用なんてのは変わらないんですよ。
Kubernetesの技術的な変化
もちろん、Kubernetes自体もそういった世界を見越して、大きく機能を改善しています。
Kubernetesのアーキテクチャでは、コントローラーがコンテナの状態を監視し、実行中の各ワークロードを「望ましい状態」に可能な限り近づけます。つまり、コントローラは、Kubernetes上におけるコンテナやネットワークを始めとする各ワークロードのリソースを管理しています。KubernetesではこれをReconciliation loopとも呼んでいます。
このように、これまではKubernetes固有のリソースだけを取り扱っていました。しかし、今後はCustom Resource Definition(CRD)を使うことで、Kubernetes以外の「リソース」を管理していきます。それがCRDであり、Operatorの役割です。
Kubernetes以外のリソースには、IaaS上の仮想マシンも含まれます。これまでは仮想マシンの上でコンテナを管理していたのが、仮想マシンもOperatorを使ってKubernetes上から制御します。例えば、Cluster Autoscalerを活用することで、負荷に応じたWorker Nodeの動的なスケールアウトなども、Operatorを活用した運用自動化です。
こうした、Operatorは多くのベンダーによって活用されており、その中核機能となるCRDはKubernetesの次世代のプラットフォーム管理を担う重要な要素であり、Kubernetes1.16から正式にGAとなりました。
もちろん、これまでもCRDを応用した話はありましたが、やっとこれらがエンタープライズの世界にも来たということでしょうか。
Operatorは運用者が苦労してきた運用を自動化する
OpenShiftでは、こうしたOperatorを各ベンダーが作って公開できる場として、「OperatorHub.io」を提供しています。これまで、ここにはDatabaseやKVSなどを始めとする、Kubernetes上のステートフルなミドルウェアが多く公開されていました。
しかし、今後はKubernetesの外にあるリソースまでもOperatorによって管理できることになります。
例えば、Nvidiaが提供しているGPU Operatorは、GPUのリソースを取り扱います。
devblogs.nvidia.com
また、OpenShiftでは「Cluster Node Tuning Operator」が動いており、指定された条件内でWorker NodeのOSのチューニングを実施し、コンテナのワークロードに合わせて、カーネルの設定変更を動的に行います。 blog.openshift.com
さらに、IaaSレベルの制御だけではありません。Operatorによって業界ごとの規制をコード化してしまえば、コンプライアンスさえも動的に監視管理できます。
こうした運用を人間が判断するのではなく、より自動化して品質を上げることが安定なKubernetes運用には必須なのです。
OpenShiftのエコシステム
OpenShiftはエコシステムを作り上げています。これまでは、OpenShiftのサポートを重視してきましたが、これからはそれらを含めOperatorをISVとしてエコシステムを広げていきます。その他にもサービスをサポートして行くことがOpenShiftの強みだと言えます。
- Managed Service (Managed OpenShift)
- Service Catalog (Operator ISV)
- Integration Service (Open Innovation Labs)
これはもともとRed HatがRHELを提供してきたときに築き上げてきた世界です。
よくOpenShiftと他のKubernetesとの違いはなんですか。と言われるのですが、こうした運用に関わるエコシステムをサポートとして提供できることこそが、OpenShiftの強みなのではないでしょうか。
「Red Hat on Red Hat」-- Red Hatはこれまで築き上げてきたRed Hatプロダクトの上で、次世代の市場を描く
現場からは以上です。
OpenShiftは「迅速に変わるビジネス要求に対して、開発者が環境を全く意識せずにコアビジネスのアプリ開発に集中できる世界」を創り出しているのだよ。というお話。
.oO(えらく壮大だな。
登壇の感想とお知らせ
当日の様子はこんな感じ。
セッションレポートも見れるようになったらしいです。
Red Hat Forum Tokyo 2019 - Session Report
資料作成で考えること
最近思うのは、技術的なことよりもそうじゃない発表シナリオを考えるほうが大変。
いつも何を聞きに来てくれているのかなぁー。なんて考えていますが、正直答えはなく。
「そもそも万人に受けよう」なんてことは考えないことですね。
自分が伝えたいことを、ちゃんと絞って伝えることがいい登壇なのかなと。
あと、最低限資料はちゃんと書こうね。みたいな。
色々なおしらせ
なんとですよ。OpenShift User Group Tokyoのミートアップがグローバルのコミュニティ担当にハイライトされました。
OpenShift User Group Tokyoは、Twitterなどもやっているので、気ままに見てください。
あと、冬なんで忘年会をしようと思っています。是非×3!!!遊びに来てくださいねー。
https://www.openshift.run/www.openshift.run
まとめ
ということで、壮大な話から始まりましたが、『赤帽エンジニア Advent Calendar 2019 - Qiita』の1日目の投稿でした。
Advent Calendarの中でもOperatorの話が盛り沢山なので、是非見てねー。
「GitLab実践ガイド」出版しました。
2018.02 このたび「乗り鉄実践ガイド -世界の車窓から- 」を執筆いたしましたっ!!
ポエムをQiitaに書くのも微妙なので、数年前に作ったはてなブログアカウントを掘り起こしました。
と、いうことでこんにちはー。北山晋吾です。
書店で見ていただくのが一番早いのですが、改めてどういったものを執筆したのかを紹介します。
概要
ImpressさんTopのPOPにしていただきましたっ!! .oO (ありがとうございます
ここに紹介頂いているとおりなのですが、DevOpsにおけるアプリケーション開発を、GitLabで行うための方法を紹介しています。
↓ご購入はこちらから
- Impress Books: GitLab実践ガイド (impress top gear)
- Amazon: GitLab実践ガイド (impress top gear)
- Rakuten: GitLab実践ガイド (impress top gear)
目次
本書を分けているわけではないのですが、おおよそ2部構成のイメージで作っています。
【第1部】 GitLabの基礎 (1-3章)
1章から3章まではGitLabを利用する上で最低限知っておくべき利用方法です。 ここまでがいわゆるDevOpsにおけるVCS(Version Control System)のお話。
【第2部】 GitLabの実践 (4-7章)
4章から7章では、GitLabに付随されている機能をDevOpsのデプロイメントパイプラインに従って構成しています。つまり、DevOpsツールチェーンをGitLabで実現するお話です。
第1章 GitLab が目指す開発スタイル
まずはDevOpsにおけるGitLabの立ち位置と、GitLabが必要とされる根本的な理念についてです。
- 1-1 DevOps とチーム開発
- 1-1-1 組織のコラボレーション
- 1-1-2 継続的改善を実現する開発ツール
- 1-2 GitLab とは
- 1-2-1 GitLab の歴史と開発コミュニティ
- 1-2-2 GitLab Inc. のプロダクト
- 1-2-3 GitLab CE の主な機能
- 1-2-4 GitLab CE のメリット
- 1-2-5 他のツールとの比較
- 1-2-6 GitLab のユースケース
- 1-3 まとめ
第2章 GitLab の導入
GitLabのインストールから管理までをざっと紹介です。GitLab運用者の方はココ必見!!のはず
- 2-1 GitLab のアーキテクチャ
- 2-1-1 内部コンポーネントの役割
- 2-1-2 内部処理フロー
- 2-2 GitLab CE のセットアップ
- 2-2-1 インストールの準備
- 2-2-2 本書の動作環境
- 2-2-3 GitLab CE のインストール
- 2-2-4 インストール中に起きる問題と対応
- 2-3 GitLab CE の運用管理
- 2-3-1 ディレクトリ構造と権限
- 2-3-2 管理コマンドの利用
- 2-4 まとめ
第3章 GitLab を使ってみよう
ここはGitLabというよりGitのお話です。Gitのローカルリポジトリとリモートリポジトリの関係性と、最低限のVCSの使い方が書いています。もちろんGitLabで行っていますが、個々の操作は基本的にはGitHubでも同じです。
この章の内容がつらつらと書いてある本と思われがちですが、ココを重視したいわけじゃないので、意外とさらっと書いてます。
- 3-1 GitLab を利用する準備
- 3-1-1 ユーザーの管理
- 3-1-2 グループの管理
- 3-1-3 プロジェクトの管理
- 3-2 Git の基礎
- 3-2-1 Git の概念
- 3-2-2 Git クライアントのインストール
- 3-2-3 Git の基本操作
- 3-3 Git によるチーム開発
- 3-3-1 ブランチの利用
- 3-3-2 リモートリポジトリの活用
- 3-4 まとめ
第4章 開発ワークフロー
チャットツールはSlackが有名ですが、実はオンプレ用に構築するチャットツールにMattermostというのがあります。それとGitLabを連携することにより、課題チケットをチャットから作ることが出来ます。いわゆるチャットOpsをGitLabでやっちゃうぜ－っていうお話です。
- 4-1 アイデアの共有
- 4-1-1 GitLab Mattermost
- 4-2 課題の管理と開発計画
- 4-2-1 Issue Tracker
- 4-2-2 Issue Board
- 4-3 開発フローとコード管理
- 4-3-1 Merge Request
- 4-3-2 GitLab Flow
- 4-4 まとめ
第5章 継続的インテグレーション
いわゆるJenkins Jobです。密かにGitLabってCIツールがメインになってきてるんですよねー。
- 5-1 継続的なビルドとテストの実施
- 5-1-1 GitLab CI/CD Jobs
- 5-2 まとめ
第6章 継続的デプロイ
もちろんCI出来たらCDできます。またDocker HubならぬContainer Registryが使えちゃいます。むりょうでっ！
- 6-1 デプロイメントパイプラインの実現
- 6-1-1 GitLab CI/CD Pipeline
- 6-1-2 Review Apps
- 6-2 コンテナイメージの管理
- 6-2-1 GitLab Container Registry
- 6-3 まとめ
第7章 フィードバック
何かと話題のPrometheusですね。Applicationパフォーマンスレビューは、もぅDevOpsに必須の連携になってきてますよー。終
- 7-1 システムのパフォーマンス測定
- 7-1-1 GitLab Prometheus
- 7-2 アイデアからビジネスへ
- 7-2-1 Cycle Analytics
- 7-2-2 ConvDev Index
- 7-2-3 Auto DevOps
- 7-3 まとめ
ターゲット読者
Git初めてですという内容を掘り下げているわけではなく、チームでGitを使ってアプリケーション開発を行う方向けに解説をしています。
そのため、DockerやGitHubといったツールの概念は普通に出てくる感じです。
- これからGitLabをチームに導入しようと検討している方
- GitLabをGitのリモートリポジトリとしてしか利用できていない方
- GitHubからGitLabに移行したいと考えている方
- JenkinsからGitLab CI/CDに移行したいと考えている方
- GitLabの古いバージョンを運用していて、最近の機能を知りたい方
などなど
執筆の感想
編集者の土屋様を始め、いろいろな方々にレビューなどご協力いただきありがとうございました。この場をお借りして改めて、お礼申し上げます。
感想としては、GitLab機能大杉ww
書いている途中でも1ヶ月に一度バージョンアップが行われるので執筆した後の校正がつらたん…
とはいえ、本には事細かなバージョンに追随するのではなく、そのツールのあるべき姿。つまり、ツールのビジョンに沿った機能紹介を優先するものなので、細かな機能追加なのか、ビジョンと密接に関係する機能なのかを見極めることが重要なのかなと思います。
GitLabで言うなれば、
「誰しもがデジタルコンテンツを共有し、チームが協力しあってより良い成果を早く実装する」
ための機能を執筆するということ。そのため本書ではDevOpsツールチェーンと密接に関わる機能を、今回は重視して取り上げています。
GitLabといえばGitのWebインターフェイスでありGitHubのOSSオンプレ版くらいだと思われがちですが…GitLabは現在こんなに変わってますよっ。という点を意識して今回執筆を行いました。
販促
今回出版社の方々にご無理をお願いして、1章無料公開をしていただきましたー。
とりあえず今のGitLabの面白さを知っていただき、DevOpsにおけるGitLabの位置づけやGitHubとの違いなどをみて、興味を持っていただければと思います。
impress.tameshiyo.me
もしGitLabについて興味があれば、社内外の勉強会やら、イベントなどでお話しますのでお気軽に呼んでくださーい。(twitter DMなど…
最後に
テレフォンショッピングならここから押し売り商法が始まるのですが、実際は業務で利用している方やこれから利用したいと思っている方が必要になるので、バンバン買ってください!!というよりも、少しでもDevOpsやCI/CDが世の中に浸透していくためのコンテンツになれば嬉しい限りです。
DevOpsを社内にも導入したいんだけどツールが多すぎて、どの組合せが最適なのかとお悩みの方は、是非一度GitLabの導入を試してみてはいかがでしょー。
ではー。
