ピッツバーグとクリーブランドのDockerコンサルティングとサポート

アプリケーションのコンテナ化

アプリケーションをコンテナ化する前に、何を読み込み、何を書き込み、どのポートを使い、起動時に何が必要かを調べます。コードと実行環境は使い捨てにできます。一方、データベースとアップロードされたファイルは保持する必要があるため、コンテナの内部ではなく、名前付きボリュームまたはバインドマウントに置きます。

データベースのパスワードなどのシークレットは、イメージやバージョン管理に含めません。コンテナの起動時に渡します。

業務アプリケーション向けのDocker Compose

ホストが1台なら、Docker Composeが適した手段であることが多くあります。1つのファイルでアプリケーション、データベース、キャッシュを定義し、1つのコマンドですべてを起動できます。

• リバースプロキシとTLS:プロキシがHTTPSを終端し、ホスト名でルーティングし、証明書を更新するため、アプリケーションが直接公開されることはありません。
• 再起動の動作:再起動ポリシーとヘルスチェックにより、クラッシュや再起動のあとにサービスが復帰します。
• 監視:稼働チェックとログは、他のシステムと同じダッシュボードに集約されます。

イメージレジストリとCIビルド

ノートパソコンでイメージをビルドしてサーバーにコピーする方法は、1人を超えると運用が追いつきません。当社は、プライベートレジストリと、コードが変更されるたびにイメージをビルドし、バージョンでタグ付けして公開するGitLab CIパイプラインを用意します。デプロイでは、タグ付けされた既知のイメージを取得し、ロールバックは前のタグを指定するだけで済みます。

バックアップとセキュリティアップデート

コンテナは使い捨てですが、ボリュームはそうではありません。当社はボリュームとデータベースを定期的にバックアップし、コピーをオフサイトに送り、復元テストを行います。データベースのコンテナでは、稼働中のサービスからファイルをコピーするのではなく、データベース自体のダンプまたはバックアップ機能を使います。バックアップとディザスタリカバリサービスをご覧ください。

セキュリティアップデートは2つの層に分かれます。ホストのOSにはパッチ適用が必要で、イメージは、そのベースイメージやライブラリが修正されたら再ビルドが必要です。当社は両方を計画的に実施し、結果をテストし、以前のバージョンも利用できる状態に保ちます。Dockerホストは、Proxmox上の仮想マシンとして動かすことがよくあります。

Kubernetesへ移行するべき時期

Docker Composeは1台のホストで動作します。そのホストを失うことが許容できなくなった場合や、サービスを複数のマシンに分散させ、ダウンタイムなしで更新し、マシンが故障したら別の場所で再起動する必要が出た場合は、Kubernetesを検討してください。クラスターは運用の手間が増えるため、当社はそれが必要な場合にのみ推奨します。その段階で、LinuxとKubernetesのコンサルティングで説明しているクラスターにワークロードを移行します。

導入の進め方

1. ヒアリング。アプリケーションの機能と稼働場所を確認します。
2. 作業範囲の文書化。コンテナ、プロキシ、バックアップ、アップデートの計画をまとめます。
3. 構築と引き渡し。デプロイし、復元をテストして、運用方法を文書化します。
4. 継続サポート。任意で、担当エンジニアが付きます。

1営業日以内にご返信します。オフィスはペンシルベニア州のCoraopolisとBeaver Fallsにあります。クリーブランド周辺の現地作業は、プロジェクトに合わせて日程を調整します。

Dockerサポートに関するご質問

Docker Composeは本番環境で十分ですか?

1台のホストで動かす多くの業務アプリケーションでは十分です。ただし、バックアップ、監視、パッチ適用の手順が整っていることが条件です。ホスト間のフェイルオーバーはありません。

自社で開発していないソフトウェアもコンテナ化できますか?

多くの場合は可能です。多くのアプリケーションはコンテナイメージを公開しており、当社が設定とバックアップを行います。独自開発のソフトウェアは、当社でパッケージ化するか、お客様の開発者と協力して進めます。

他社が構築したDockerサーバーを引き継げますか?

はい。変更を加える前に、コンテナ、ボリューム、証明書を棚卸しし、バックアップを確認し、見つけた内容を文書化します。