‫このビデオを見るタイミングによって､ runコマンドの使い方の予想が少し違ってくると思います｡
‫バージョン1より開始｡ 12､
‫そして少なくとも現在のバージョンであるRelease 1までは｡ 15､ そしておそらく今後数回は､
‫runコマンドの使い方､ あるいは操作の仕方によって､ 異なるメッセージが表示されるようになるはずです｡
‫その状態も､
‫用途も､ 年々変化しています｡
‫runコマンドの目標は､ その機能を減らし､
‫以前に学んだ多くのジェネレータを非推奨にすることです｡
‫そのほとんどを非推奨とする｡ 実際､ 1つを除いたすべてのコマンドを､
‫ポッドを起動するだけの単一の実行コマンドとして残します｡
‫ここでの目標の1つは､ 複雑さを減らして､ docker runコマンドと非常に似ていて､
‫Kubernetesの上で実行することだけが経験できるようにすることです｡
‫デプロイメントを利用するジェネレータなどは､ kubectl
‫createコマンドで利用できるようになったので､
‫このようなジェネレータを排除したいのです｡
‫だから､ 将来､ ワンライナーのコマンドラインからオブジェクトを作ることを考えたら､
‫createを考えてみてください｡
‫そうすると､
‫ランは本当にポッドをやるだけになってしまうんです｡ ポッドを素早く起動させるのは､
‫何かを始めたいときだけです｡
‫もしかしたら､
‫私はcontainerdやCRI-O､ あるいは他のランタイムエンジンを使っているので､
‫Dockerがないマシンにいて､ Dockerの実行の利便性がないのかもしれませんね｡
‫しかし､ 私はKubernetesをインストールしているので､ kubectlを実行することで同様の体験をすることができます｡
‫私にとっては､ トラブルシューティングやネットワークのテストなど､
‫ワンショットのコンテナを実行するために､ この非推奨のものを日常的に使っている今､
‫本当の理由､ そして唯一のユースケースは､ runを使うことです｡
‫あるいは､
‫コンテナ・ネットワークに飛び込む必要があり､ 何らかの理由でそこにコマンドラインが必要な場合です｡
‫そんな時にランを使うんです｡
‫でも､ 少なくとも今後数年間は､ やはりランの歴史を理解することが､
‫ある意味重要なのです｡
‫というのも､ Kubernetesで多くの歴史を持つrunコマンドを使う例は､
‫このビデオの中にもたくさん出てくるからです｡
‫ですから､
‫例を見ていると､ ブログで翻訳したり､ 別のドキュメントで翻訳したりと､
‫数年後には時代遅れになってしまうかもしれませんね｡
‫そういうのを見て､ よし､ 昔はrunコマンドでやっていたんだ､
‫と翻訳することになる｡
‫さて､ それをcreateコマンドで行うことになった｡
‫そこで､ かつてrunコマンドがどのように動作していたか､ また現在でも率直に言ってどのように動作しているか､
‫いくつかの例を挙げてみましょう｡
‫このコースを行うために使用しているバージョンは､ これが機能しなくなったときに､
‫このビデオを取り出して､ 実行コマンドの記憶の中の一種に置き換えるつもりだからです｡
‫もう持っていないこのモノの話をしよう｡
‫いくつかのコマンドを見てみましょう｡
‫コマンドラインで放り込むだけなので､ 使っていたrunコマンドの種類によって､
‫どんなジェネレータを使っていたのかがわかるようになっているんです｡
‫これは､ コマンドラインから実行するさまざまな操作によって､ リソースを作成するときの動作が変わってしまうためです｡
‫これらすべてで､
‫作成されたオブジェクトが何であるかを示すために､ ドライランを行うだけです｡
‫このコマンドについては､
‫以前Deploymentの作成方法を学んだ標準的なものです｡
‫このデフォルトでは､ ジェネレータを指定していないことにお気づきでしょう｡ これは --generator
‫を指定することで可能です｡
‫でも､ 今回はrunコマンドの経時変化をお見せしたいので､
‫それは使いません｡
‫今日はジェネレーターがないと､ デプロイメントが出ますね｡
‫今後､ 最終的にこの変更が行われた場合､ デフォルトの実行はDeploymentではなくPodを作成し､
‫Deploymentの作成にはcreateやapply､
‫それらのコマンドを使用し､ 実行はPodのみに残すことが期待されます｡
‫今日は､ 114号でご紹介します｡
‫testという名前のDeploymentが作成されるのがわかると思います｡
‫なぜなら､
‫数年後に使うことがないのであれば､ runコマンドのさまざまなニュアンスを覚えてほしくないからです｡
‫この場合､ 通常のように警告が表示され､
‫2つの異なるものが作成されます｡
‫Deploymentとserviceのリソースを2つのコマンドを使わずに作成することができます｡
‫Deploymentを作成し､ 公開するのにとても便利な方法です｡
‫繰り返しになりますが､
‫exposeコマンドやcreateコマンドを別々に使えるようになったため､
‫それがなくなり､ 自動化や複雑化が進むのはよくないかもしれないことがわかりました｡
‫だから､ それを解消するんです｡
‫次はこちら､ 公開する部分を削除して､ 失敗時の再起動を追加しました｡
‫これにより､ 異なるタイプのリソースが作成されます｡
‫バッチジョブまたはジョブタイプだけが作成されます｡
‫あれは本来､ 一発勝負のコンテナ､ 走らせる必要のあるもの向けです｡
‫データベースのスキーマを更新する必要があるかもしれません｡
‫あるいは､ データベースのバックアップを素早く行い､ 失敗したときだけコンテナを再作成するようにしたい場合などです｡
‫それらはランでできることでしたが､
‫他の方法でもできるようになったのです｡
‫次に､ 再起動を失敗時ではなく､ 絶対しないに設定したことです｡
‫これにより､
‫リソースの種類がポッドに変更され､ まもなくデフォルトになります｡
‫これはちょっとわかりにくいですね｡
‫この動作を強制することができます｡ 先ほどお見せしたような以前のコマンドに戻ってみると､
‫失敗時に再起動するときに､ この行があるのは､ 将来､
‫デフォルトでこのようなことが起こるということを意味していることに気がつくと思います｡
‫もしそうしたくない場合は､ 私がここでやっているように､ ジョブV1を使った別のジェネレーターを強制的に作成するか､
‫createコマンドを使うことができます｡
‫どちらを使うのがいいのでしょう｡
‫だから､ 私の講座は､ そのような将来の利用を想定しています｡
‫runコマンドのいろいろな実行方法を教えているわけではありません｡
‫ここでは､
‫createとapplyなどのオプションに絞って説明します｡
‫そして､ 最後の1枚がこちら､ この存在を知らなかったという方のために｡
‫Kubernetesではcronジョブをサポートしているので､
‫同じrunコマンドでも､ スケジュールを指定すれば､ cronジョブを使うようにジェネレータが変更されるのです｡
‫ジョブとは少し違いますが｡
‫cronジョブは再発するように設計されています｡
‫だから､ そうなるんですよ､ この場合､
‫1日1回なんです｡ runコマンドの歴史について､
‫ご理解いただけたでしょうか？ 繰り返しになりますが､ 本当に私たちの未来は､
‫ポッドを作るだけだと思って行動し始めたらいいと思います｡
‫なぜなら､ もうすぐここに､ おそらく116になるか117になるかわかりませんが､
‫いつ本当の変化を強いられるかわからないからです｡
‫これらはすべて､
‫ある時点で引き抜かれ､ これらの発電機を使用するために構築することもないでしょう｡
‫別の方法でcreateとapplyを使い分けることを余儀なくされるでしょう｡