Docker ワークフロー ツール コンテナを変換・生成・チェック・サイズ化

それは無害に始まります。あなたはSlackのスレッドにコマンドを貼り付け、チームメイトがローカルのデータベースを立ち上げることができます。2ヶ月後、その同じコマンドは4つのチャンネル、3つのウィキ、そして誰も記憶にないbashスクリプトのコメントに現れています。誰もがそのコマンドがまだ機能しているか、どの環境で使われているかを知りません。 docker run Dockerコマンドは急速に広がります。1つのPostgresインスタンスにはネットワークフラグ、ボリュームマウント、再起動ポリシー、認証用の環境変数、ポートバインディングが必要です。これは200文字の1行命令で、レビュー、バージョン管理、または手渡しするのにほぼ不可能なものです。これを5つのサービスに拡張すると、維持不可能なインフラ構成になります。

4つの無料ツールがこの問題の異なる部分を解決します。順番に使用することで、10分以内に混乱した実行コマンドから、プロダクション用のチェック済みコンテナ設定に至ります。

ツール1：Docker RunからComposeへのコンバータ

Dockerを多く使うワークフローにおいて最も辛い瞬間は、誰かのシェル履歴に存在するサービスを継承することです。その考古学的なアーティファクトを、適切な

に変換します。 Docker Run to Compose Converter 以下は現実的な例です：Postgresコンテナは昔の方法で開始されました。 docker-compose.yml.

それをコンバータに貼り付けますと、次のようになります：

docker run -d \
  --name postgres-db \
  --restart unless-stopped \
  -e POSTGRES_USER=myapp \
  -e POSTGRES_PASSWORD=secretpassword \
  -e POSTGRES_DB=myapp_production \
  -v postgres_data:/var/lib/postgresql/data \
  -p 5432:5432 \
  --network app-network \
  postgres:15-alpine

これは、すべてのフラグを覚えていなければ正しく実行できないコマンドではなく、レビュー可能でバージョン管理可能なファイルになります。コンバータはネットワークエイリアス、ボリューム宣言、再起動ポリシー、環境変数など、誰も記憶にないときに失われる要素を処理します。

services:
  postgres-db:
    image: postgres:15-alpine
    container_name: postgres-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: myapp
      POSTGRES_PASSWORD: secretpassword
      POSTGRES_DB: myapp_production
    volumes:
      - postgres_data:/var/lib/postgresql/data
    ports:
      - 5432:5432
    networks:
      - app-network

volumes:
  postgres_data:

networks:
  app-network:

新しいサービスのオンボーディングに特に役立ちます。代わりに「runコマンドを送ってください」というのではなく、「composeファイルを送ってください」と問うことができます。もしもcomposeファイルを持っていない場合は、その人が持っているものから生成できます。

ツール2：Dockerfile生成器

新しいサービスのDockerfileをゼロから書くには、別のプロジェクトのものをコピーする（そしてその悪い習慣を継承する）か、20分のドキュメント作業が必要です。その

は、選択した言語とランタイムに基づいて、プロダクション用のスタートポイントを提供することで、両方をスキップします。 Dockerfile 生成ツール Node.js、Python、Go、PHP、または他のランタイムを選択し、生成器はすでに次の要素を含むDockerfileを生成します：

特定の、ピン留めされたベースイメージバージョンではなく

• 適切な場合にマルチステージビルド（ビルドステージと実行ステージを分離） latest
• アプリケーションを実行するための非rootユーザー
• キャッシュ効率を最大化するための適切なレイヤー順序
• -フレンドリーな構造
• あ .dockerignore開発者が時間圧迫の下でDockerfileを書く際に、頻繁にスキップする要素であり、セキュリティ審査がそれらを指摘したときに慌てて修正するものです。生成されたテンプレートから始めるということは、すでにベースラインがカバーされているということです。

出力はそのままデプロイするためのものではありません——あなたはまだエントリポイント、環境変数、ビルドコマンドをカスタマイズします。しかし、構造的な決定はすでに適切であり、あなたは作成するのではなく、編集するということです。

ツール3：Dockerfile チェック

経験豊富なエンジニアでも、Dockerfileに微妙な問題を書くことがあります。よく見られる問題は、

をベースイメージタグとして使うこと、 latest は正しいが、 ADD において COPY を根拠に、プロセスをrootとして実行すること、またはパッケージをインストールした後にaptキャッシュをクリーンアップしないこと。これらはビルドをクラッシュさせないが、セキュリティリスク、膨らんだイメージ、再現性のないビルドを生み出します。

の Dockerfile Linter これらを生産環境に到達する前に検出します。Dockerfileを貼り付け、警告と説明のリストが返されます——ただ何が間違っているかだけでなく、なぜそれが重要で、どうすべきかを示します。

実際のDockerfileに見られる一般的なフラグ：

• ベースイメージをピン留め — FROM node:latest は毎回異なるイメージを取得するため、再現性を確保するために node:20-alpine を使用
• COPYを使用する — ADD は暗黙的な動作（tarファイルの自動展開、URLの取得）があり、予測不可能なビルド結果を生み出します
• root権限を削除 — アプリケーションをコンテナ内でrootとして実行しないように、 USER ディレクティブを追加
• パッケージキャッシュをクリーンアップ — apt-get install without && rm -rf /var/lib/apt/lists/* 各イメージレイヤーに無駄なメガバイトを追加する

リーダーを30秒かけて実行し、ほとんどのDockerfileがチェックリストに基づいて書かれていない場合、少なくとも2つまたは3つの問題を検出します。これは、PRを開く前に部分的なセキュリティおよび正確性レビューを行うための安価な方法です。

ツール4：Dockerコンテナリソース計算器

開発者がメモリ制限を誤って設定していることを発見するのは、プロダクションでコンテナがOOMキルされ、サービスがダウンするときです。その Dockerコンテナリソース計算機 は、その前に起こるべき予防ステップです。

コンテナタイプ、予想されるワークロード、同時リクエストまたはプロセス数、および1つのワーカーあたりのベースメモリを入力します。計算器は、ピーク時のためのバッファを含む推奨 --memory と --cpus 制限を返します。

これは重要です。デフォルトの動作——制限が設定されていない——は、1つの異常なコンテナがホスト上のすべてのサービスを奪うことを意味します。共有インフラでは、それはインシデントです。計算器は、実際のものではなく任意のものに設定するのではなく、現実的な制限を設定するための助けになります。そのため、あなたは 512m を予測して、希望するものに頼る必要がなくなります。

ホストサイズを決定する場合にも役立ちます。アプリケーションが1ワーカーあたり256MB必要であるとし、4ワーカーを実行したい場合、プロビジョニング前に最小のインスタンスサイズを計算できます——プロビジョニングが小さすぎず、負荷の下でサイズを調整する必要がなくなるのです。

ワークフローをまとめる

これらの4つのツールは、新しいサービスを設定するか、古いサービスを継承する際の自然な順序にマッピングされます：

1. 最初に実行コマンドから始めます。 機能する docker run コマンドがある場合、まずcomposeファイルに変換します。これにより、レビュー可能でバージョン管理可能なものになります。
2. Dockerfileが存在しない場合は、Dockerfileを生成します。 ランタイムを選択し、堅固なスタートポイントを得て、アプリケーションに合わせてカスタマイズします。
3. Dockerfileをチェックします。 コミットする前にリーダーを通します。検出された問題を修正します——ほとんどの問題は1分以内に解決できます。
4. リソース制限を設定します。 共有ホストにデプロイする前に、現実的なメモリとCPU制限を計算し、composeファイルに追加します。

この順序は説明するのに長くかかりますが、実際には2から4のステップは1サービスあたり約5分かかります。報酬は、再現可能でレビュー可能、かつホスト上で適切にサイズ設定されたコンテナ設定になります。

あなたも好きかもしれません