®OTOKO®によるKubernetesとコンテナプラットフォーム
コンテナは、アプリケーションのパッケージ化を簡素化します。しかし本番投入には、アクセスルール、リリース手順、アップデート、データの復旧といった要素がまだ欠けていることが少なくありません。OTOKO®は、貴社のアプリケーションと利用可能な運用スキルに合ったKubernetesプラットフォームを構築し、貴社の開発チームと共にその活用を検証します。
私たちが貴社のために担うこと
OTOKO®による計画、実装、合意した運用
イメージ画像（事業者の拠点を撮影したものではありません）OTOKO®へのご依頼内容
あるチームはすでに問題なくデプロイできている一方、別のチームは独自のスクリプトで対応しており、本番環境への変更のたびに個別の調整が必要になっています。プラットフォームを拡張する前には、共通の手順が必要です。Kubernetesの採用がまだ決まっていない場合は、まずその利点が貴社のプロジェクトにとって追加の運用負荷に見合うかどうかを検討します。
プラットフォームの構築には、合意したアクセス権、プロビジョニング手順、運用フローが含まれます。パイロットアプリケーションは、リリースまでの流れを検証するために用います。ドキュメントの整備と操作説明によって引き継ぎに備え、継続的なサポートとアップデートは、別途のサービス範囲として合意します。
サービスの詳細サービス範囲
プラットフォームの選定、チームのアクセス権、プロビジョニングを共に検討します。パイロットアプリケーションによって、手順を検証可能な形にします。アップデートと永続データについても、構築の段階から運用計画に組み込みます。
プラットフォームの選定は、アプリケーションと運用体制の余力から始めます。候補となる選択肢は、どの作業を事業者が担い、どの作業を貴社チームが担うかという観点で評価します。この役割分担は、技術的な要件と同じくらい判断に影響します。
責任分担を明確にした、根拠あるプラットフォームの目標像。
マネージドコントロールプレーンと自社運用のクラスターでは、必要な業務が異なります。ワーカー、ネットワーク、可用性要件を計画し、そもそもKubernetesがそのワークロードに適しているかを確認します。運用能力と更新の手間も判断材料に含まれます。
チームには、明確なワークスペース、リソース、コミュニケーションのルールが必要です。私たちはこうした基盤を整え、想定する承認手順を説明します。これにより、開発チームが自らデプロイしてよい範囲と、運用チームとの調整が必要な範囲が明らかになります。
関係するチームのための、利用可能なテナント・アクセス構造。
チームには、統制されたアクセスとリソースが必要です。Namespace、ロール、クォータ、ネットワーク通信をあわせて計画します。認証情報と設定には明確な管理経路を設け、共有クラスターが無秩序な相互アクセスにつながらないようにします。
検証済みのイメージから実際に稼働するバージョンまでの流れは、追跡可能でなければなりません。テストとプロビジョニングを調整済みの手順に組み込み、パイロットアプリケーションで検証します。その際、開発チームと運用チームが共に承認内容とロールアウト時の挙動を確認します。
パイロットアプリケーション向けにテスト済みのデプロイメントの流れと、他チーム向けのテンプレート。
コンテナイメージ、検証、デプロイメント設定を、追跡可能なリリースパスに組み込みます。HelmやGitOpsは、そのための適切な手段となり得ます。承認、切り戻し手段、不具合のあるリリースへの対応は、アプリケーションチームとともに取り決めます。
プラットフォームのアップデートと復旧は、永続データや接続先のサービスにも関わります。こうした依存関係は、監視の仕組みとあわせて運用計画に反映します。そこから、保守や障害対応のための具体的なタスクと手順が導き出されます。
更新手順、アラート経路、復旧テストを含む運用計画。
メトリクス、ログ、アラートは、アプリケーションの挙動を説明できるものである必要があります。クラスターのアップグレードと、設定・データのバックアップおよび復旧を計画します。Podの再起動が成功したからといって、データ復旧のテストの代わりにはなりません。
計画と実装の詳細
稼働中のクラスターは重要な構成要素ですが、それだけではアプリケーション運用として完結しません。開発、プラットフォームの保守、データに対する責任が連携して機能する必要があります。私たちの進め方では、技術的な構築と、貴社のチームがリリース、更新、障害対応に必要とする手順とを結び付けます。
プラットフォームを選ぶ前に、どのアプリケーションを対象とするか、チームにどのようなニーズがあるかを確認します。新しいバージョンは現在どのように提供されていますか。どのデータを永続的に保持する必要がありますか。プラットフォームの変更は誰が担当しますか。これらの問いは、必要な範囲を絞り込むのに役立ちます。Kubernetesが適している場合もありますが、アプリケーションや利用できるスキルに合っている必要があります。特定の技術を使いたいという理由だけで判断すると、追加で発生する組織面と技術面の負荷には答えられません。
そのため、候補となる方式は、作業分担の観点からも検討します。マネージドサービスを利用する場合でも、アプリケーション、設定、データについてどの作業が引き続き必要かを明確にする必要があります。目標像には、こうした貴社側の作業内容を明記し、そのうちどの部分をOTOKO®が委託の範囲内で担うかを定めます。代表的なパイロットアプリケーションによって、要件を具体的に把握できます。これにより、他のチームやアプリケーションを迎え入れる前に、選定した構成と想定した手順が実際に期待に応えられるかを確認できます。
チームに必要なのは、クラスターへのアクセスだけではありません。どこで作業してよいか、リソースがどのように割り当てられるか、本番環境への変更にどの承認が必要かを把握している必要があります。これらの基盤は貴社とともに整備し、プロビジョニングの手順と結び付けます。イメージ、検証結果、対象のバージョンは、互いの対応関係が明確である必要があります。具体的な実装は、貴社のアプリケーションや既存のツールに沿って行い、すでに機能している手順は、適合する範囲で目標像に取り入れます。
最初のリリースは、貴社とともに実施します。その際、起動が成功したかどうかだけでなく、手順の分かりやすさも確認します。エラーメッセージから原因を特定できるか、承認は明確か、開発チームと運用チームはいつ対応すべきかを把握しているか、といった点です。合意したエラーケースと切り戻し手順についても、話し合うか実際に試します。そこで得られたドキュメントは、その後のリリースにも役立てます。こうして貴社のチームは、後になって使い方を手探りで見つけ出す技術環境ではなく、実際に使える作業手順を手にすることになります。
コンテナは作り直せますが、関連するデータや接続先のサービスには、それぞれ専用の手順が必要です。どの情報を永続的に保持する必要があるか、その復旧をどのように検証するかを貴社とともに検討します。これには、アプリケーションとデータをどの順序で再び利用可能にするかも含まれます。バックアップの手順は、実際のアプリケーションに合ったものである必要があります。作業は明確に割り当てることで、プラットフォームの保守とアプリケーションに対する責任の間に、意図しない抜け漏れが生じないようにします。
プラットフォームの更新にも、準備とすり合わせが必要です。依存関係、テストの方法、必要な承認は、運用手順の中に記載します。監視と報告経路によって、問題をどのように検知し、適切な担当者に伝えるかを定めます。継続的なサポートを行う場合、サービス範囲には、どのプラットフォームおよび運用タスクを対応範囲とし、どれが貴社のチームに残るかを明記します。この線引きにより、新たな要件を後から意図的に取り込むことや、プラットフォームに必要な作業を現実的に計画することが容易になります。
私たちの協働の進め方
貴社が技術的な作業のすべてを自ら手配する必要はありません。私たちが作業内容と決定事項を記録し、貴社のチームの知見や承認が必要な場面には、その都度参加していただきます。
代表的なアプリケーションを通じて、リソース、データ、プロビジョニングに関する要件を明らかにします。運用体制の余力とプラットフォームの選択肢を共に評価します。
貴社の役割： 開発チームと運用チームを引き合わせ、適したパイロットアプリケーションを選定してください。
プラットフォーム、アクセス権、プロビジョニング手順を構築します。パイロットを通じて、チームが想定した手順どおりにリリースを実施できるかを確認します。
貴社の役割： 貴社の開発チームには、アプリケーションをご提供いただき、リリースと業務上の機能をご確認いただきます。
運用タスク、アップデート手順、復旧の方法を説明し、担当を割り振ります。そこから、継続的なサポートを行う場合の範囲も見えてきます。
貴社の役割： アプリケーション、永続データ、プラットフォームの変更それぞれについて、責任の所在をご確認ください。
プロジェクトのシナリオ例
共同で進めるプロジェクトの一例です。具体的な範囲は、貴社の現状によって決まります。
複数のアプリケーションがコンテナ化されて稼働していますが、デプロイと運用の方法はチームごとに異なります。
選定した1つのアプリケーションを対象に、共通のデプロイルールと運用手順を検証します。
ロール、リリースプロセス、合意した運用責任を含む、ほかのチームにも再利用できる出発点。
貴社が得られるもの
コードで記述された運用可能なKubernetesプラットフォーム
ポリシーを含むセキュリティ・テナント設計
アップグレード・復旧手順を含む運用マニュアル
関心から、具体的なご依頼へ
初回相談の時点では、これらの資料がすべて揃っている必要はありません。何がすでにあるか、アセスメントでどの情報を補うべきかを、共に明確にします。
サービス範囲、貴社チームの関与、必要なアクセス権、検収基準、引き渡しは、見積もりの中に記載します。事業者の利用料金、プロジェクトの作業内容、稼働中の運用は、それぞれ区別して分かりやすく示します。
アセスメントについて相談する着手前に
コードで記述された運用可能なKubernetesプラットフォーム. ポリシーを含むセキュリティ・テナント設計. アップグレード・復旧手順を含む運用マニュアル。範囲と検収基準は最初に合意します。
はい。既存のアプリケーション、インターフェース、運用プロセスを確認し、必要な変更を貴社と一緒に切り分けます。必ずしも全面的な再構築が必要になるわけではありません。
棚卸しの後、作業パッケージ、役割分担、検収基準、引き渡しをすり合わせます。そこから具体的なプロジェクト範囲の見積もりを作成します。
それは事業者と料金プランによって異なります。アプリケーション、設定、権限、データが自動的に全面的に管理されるわけではありません。これらの業務をプラットフォーム・運用モデルの中で明確にします。
はい。構築、共同での支援、継続的な運用は、それぞれ個別に合意できます。文書化された引き継ぎにより、貴社の社内チームのための基盤が整います。
OTOKO®によるKubernetesとコンテナプラットフォーム
代表的なアプリケーション1つが、長いツール一覧よりも多くを示すことがよくあります。それをもとに、プロビジョニング、データの保持方法、運用について話し合い、貴社のプラットフォームが満たすべき要件を明確にします。
Kubernetesとコンテナプラットフォームに関する初回相談
