|
この文書は自動機械翻訳技術を使用して翻訳されています。 正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。 相違がある場合は、元の英語版 英語 が優先され、正式なテキストとなります。 |
オンボーディングと実装ガイド
開発者は`docker pull`を手に取ります。それは速く、機能し、セキュリティの問題は後回しにできます。オペレーションチームは、信頼できるレジストリからの検証済みコンテンツを使用して`helm install`を手に取ります。なぜなら、Kubernetesに安全にデプロイすることが彼らの仕事だからです。これら二つのワークフローの間には、摩擦、セキュリティの負債、そして最後の瞬間の驚きが生じるギャップがあります。
SUSE Rancher Developer Accessがこのギャップを埋めます。それはKubernetesと信頼できるコンテンツを開発者のローカル環境に直接持ち込み、最小限の認知的負担で済みます。ローカルクラスタはRancher DesktopとそのK3sエンジンによって動作しており、軽量で生産品質のKubernetesディストリビューションで、RKE2の埋め込みエンジンとしても機能します。最初のコード行から、ローカル開発は本番環境と同じランタイムと同じコンテンツで実行されます。
1.サブスクリプションのアクティベーション
信頼できるOCIレジストリ（dp.apps.rancher.io）にアクセスする前に、SUSE Rancher Developer Accessサブスクリプションのアクティベーションが必要です。
1.1.サブスクリプションのアクティベーション
サブスクリプションを購入するか、無料トライアルを開始した後、あなたの主な連絡先は14文字の登録コードを含む案内メールを受け取ります。
手順:アクセスのアクティベーション
-
SUSE Customer Centerにログインします。
-
サイドバーで、*マイツール*に移動し、*サブスクリプションをアクティブ化*を選択します。
-
提供されたフィールドに*登録コード*を入力します。
-
サブスクリプションをあなたの組織に関連付けて、*アクティブ化*をクリックします。
-
完了したら、*SUSE Rancher Developer Access*が*サブスクリプション*タブの下でアクティブとして表示されることを確認します。
1.2.ユーザーアカウントとアクセストークン
SUSE Rancher Developer Accessは、個々のユーザーアカウントに割り当てられます。
-
スコープ:これらのアカウントは、開発、テスト、およびプロトタイピング専用です。本番のワークロードには使用できません。本番要件については、SUSE営業チームに連絡するか、SUSE Rancher Primeのドキュメントを参照してください。
-
アクセストークン:レジストリへの認証は、アクセストークンを介して行われます。異なる環境（たとえば、ローカルワークステーションとリモート開発環境）用に複数のトークンを作成できますが、すべてのトークンは単一の認可されたユーザーアカウントにリンクされます。
-
サービスアカウント:このサブスクリプション層には、CI/CDパイプラインなどの自動化ツールに必要なサービスアカウントは含まれていません。ワークフローに自動化が必要な場合は、SUSEに連絡してRancher Primeの詳細を確認してください。
2.ローカル環境:Rancher Desktop
Rancher Desktopは、ローカルクラスタとコンテナエンジンを提供します。これは独立したアプリケーションであり、このガイドではSUSE Rancher Developer Accessから信頼できるコンテンツを実行するために使用されます。
2.1.コンテナエンジンの選択
セットアップ中に、コンテナエンジンを選択する必要があります。選択に関係なく、アプリケーションとKubernetesクラスタの動作は同じであり、どちらのオプションも本番環境の整合性のための堅実な基盤となります。K3sは、ローカルクラスタを支えるエンジンであり、軽量で生産品質のKubernetesディストリビューションで、RKE2のコアに組み込まれたエンジンです。ローカルで実行するクラスタは、本番環境の任意のcontainerdベースのKubernetesディストリビューションと同様に動作します。
コンテナエンジンの選択は、ローカル環境とのインタラクションに影響を与えますが、クラスタ自体の動作には影響を与えません：
-
Moby (Docker Engine)：これはほとんどの開発者に推奨される選択です。Tilt、Dev Containers、Testcontainersなどの人気のあるサードパーティツールとの最大の互換性を提供します。
-
containerd (nerdctl)：このオプションは、nerdctl CLIを使用して管理者と同じパターンでローカルクラスタと対話したいユーザーを対象としています。
3.Rancher Desktop用のSUSEアプリケーションコレクションUI拡張
*SUSEアプリケーションコレクションUI拡張機能（Rancher Desktop用）*は、レジストリ認証を自動化し、必要なKubernetesプルシークレットを作成し、SUSEアプリケーションコレクションからアプリケーションをブラウズ、インストール、設定するためのグラフィカルインターフェースを提供します。[1]
3.1.拡張機能のインストールと設定
-
Rancher Desktopの拡張タブから拡張機能をインストールします。
-
拡張機能を開き、設定に移動します。
-
SCCユーザー名とセクション1.2で生成されたアクセストークンを入力します。
-
「認証情報を保存」をクリックします。
設定が完了すると、拡張機能は自動的に次の操作を実行します：
-
レジストリログイン:選択したコンテナエンジンのために`dp.apps.rancher.io`にログインし、CLIから認証されたイメージプルを可能にします。
-
プルシークレットインジェクション:デフォルトのネームスペースに`application-collection`という名前のKubernetes imagePullSecretを作成します。imagePullSecretは、レジストリの認証情報をKubernetesオブジェクトとして保存し、クラスタが手動設定なしで認証されたレジストリからイメージをプルできるようにします。
-
Helm設定:ローカルHelmクライアントを設定して、信頼されたOCIリポジトリを解決します。
SUSEアプリケーションコレクションのすべてのHelmチャートは、標準のglobal.imagePullSecretsパラメータを公開しています。チャートを手動でインストールする際は、このパラメータを[application-collection]に設定して、すべてのチャート依存関係が正しい認証情報を使用してプルされるようにします。
|
UI拡張は、Helmチャートとして利用可能なアプリケーションのインターフェースを提供しています。あなたのサブスクリプションは、拡張機能にまだ表示されていないスタンドアロンコンテナイメージ（ベースイメージ、言語スタック、CLIツールなど）の膨大なライブラリへのアクセスも提供します。完全なカタログを探索するには、 apps.rancher.ioを訪問してください。 |
[^1]:この拡張機能は、Docker Desktopとも互換性があります。
4.なぜ信頼できるコンテンツが重要なのか
公開されているコンテナイメージは、CVEの露出を優先して維持されていません。代わりにSUSEアプリケーションコレクションを使用することで、フルスタックプロジェクトの合計脆弱性数を数千から50未満に減少させることができます。
4.1.言語スタックとベースイメージ
未審査の言語またはベースコンテナは、あなたが一行のコードも書く前に、プロジェクトに数千の脆弱性を導入する可能性があります。公開レジストリからの人気のあるイメージは、便利さのために構築されており、安全性のためではありません。それらは、CVEの露出を最小限に抑えるために体系的に維持されていません。SUSEアプリケーションコレクションの言語スタックは、SLE BCIという、SUSEが積極的に維持し、パッチを適用する最小限のベースレイヤーの上に構築されています。継承された脆弱性は、Node.js、Go、OpenJDKなど、すべてのサポートされているランタイムで大幅に削減されています。 4.2.アプリケーションとミドルウェア あなたのスタックが依存しているアプリケーションにも同様のことが言えます。公開レジストリから広く利用されているミドルウェアイメージは、ソフトウェア自体が安全でないためではなく、広範なベースレイヤー上に構築され、依存関係の更新が追跡されないために、数百のCVEを容易に抱える可能性があります。SUSEアプリケーションコレクションのイメージは、最小限にキュレーションされた依存関係を利用し、積極的にパッチが適用されます — これは、イメージの構成に対する異なるアプローチであり、パッチの適用を遅延させるものではありません — これにより、脆弱性の数は公開されている同等のイメージのごく一部に抑えられます。
5.例：開発者のワークフロー：迅速な反復の内部ループ
5.1.TiltとVS Codeを使用したライブ開発
このセクションでは、*Tilt*と*VS Code*という2つの人気のあるサードパーティツールに基づいたパターンを実用的な例として説明します。
目標は、緊密な内部ループを実現することです。ローカルでコードを編集すると、その変更が手動による再構築、リモートレジストリへのプッシュ、ゼロからの再展開といった作業を経ることなく、Rancher Desktopのローカルクラスタ上で実行中のコンテナに瞬時に反映されます。
Rancher Desktopは、*Local Image Store*を通じてこれを可能にします。Tiltがイメージを構築すると、それはK3sによって使用されるストアに直接プッシュされ、リモートレジストリを完全にバイパスします。VS Codeでファイルを保存すると、Tiltのsyncがトリガーされ、数秒以内に実行中のコンテナが更新されます。SUSEアプリケーションコレクションのベースイメージで構築されたアプリケーションは、プロダクションでの動作と全く同じです：同じcontainerdランタイム、同じKubernetes環境。
ステートフルアプリケーションはこのパターンに適しています。PostgreSQLやメッセージブローカーなどの依存関係は、アプリケーションコンテナが継続的に更新される間に、ローカルクラスタに信頼されたHelmチャートとして一度デプロイできます。スタック全体はローカルで実行され、外部依存関係はありません。
完全なセットアップガイドと動作する参照実装については、 Rancher Developer Access Demoリポジトリを参照してください。
6.ベストプラクティスとヒント
6.1に設定する必要があります。バージョンを固定し、信頼できるベースイメージを使用する
SUSEアプリケーションコレクションは、`:latest`タグをサポートしていません。常に`Dockerfile`とHelmチャートを、 apps.rancher.ioにある特定のバージョンおよびリビジョンのタグに固定してください。これにより、環境が再現可能になり、開発と本番環境の間でバージョンのずれがなくなります。
常に信頼できるレジストリからベースイメージを使用してください：
FROM dp.apps.rancher.io/containers/suse-bci-base:15.76.2.Kubernetesに不慣れな開発者へのヒント
Kubernetesは、Dockerのみのワークフローに直接的な同等物がない概念を導入します。いくつかの調整を行うことで、移行が容易になります：
-
Ingress経由のポートフォワーディング：Rancher DesktopポートフォワーディングUIを使用して、1クリックでlocalhost上にクラスターサービスを公開します。ローカル開発のためにIngressコントローラーを設定することは不要なオーバーヘッドです。
-
ネームスペース：拡張機能によって作成されたimagePullSecretは、`default`ネームスペースに注入されます。他のネームスペースにワークロードをデプロイする場合は、そこでもシークレットを作成する必要があります。または、チャートを明示的に参照するように構成する必要があります。
-
ログと状態：最初の診断ツールとして`kubectl logs <pod>`と`kubectl describe pod <pod>`を使用してください。ローカル開発中のほとんどの問題（イメージプルの失敗、クラッシュループ、誤設定された環境変数）は、そこで即座に確認できます。
-
コンテキスト認識:Rancher Desktopは自らをkubectlコンテキストとして登録します。複数のクラスターで作業する場合は、コマンドを実行する前に`kubectl config current-context`でアクティブなコンテキストを確認してください。