Dockerは、アプリケーションを軽量でポータブルなコンテナにカプセル化することで、アプリケーションの構築、配布、実行の方法に革命をもたらしました。シェルとSSHを使用してこれらのコンテナと対話することは、ベストプラクティスではありませんが、開発者にとって便利です。このブログ投稿では、シェルアクセスとSSHを使用してDockerコンテナと対話する方法を探求します。
コンテナへのシェルアクセス
実行中のDockerコンテナと対話する最も簡単な方法は、Docker execコマンドを使用することです(シェルを含めてイメージをビルドした場合)。このコマンドを使用すると、実行中のコンテナで新しいコマンドを実行できます。これは、デバッグや迅速な変更に特に便利です。
使用方法は次のとおりです:
-
コンテナの特定: まず、コンテナのIDまたは名前を知る必要があります。
docker ps
で実行中のすべてのコンテナをリストできます。 -
コマンドの実行: コンテナ内でコマンドを実行するには、
docker exec
を使用します。たとえば、対話型シェルセッションを開始するには、次のようにします:docker exec -it <container_id_or_name> /bin/sh
<container_id_or_name>
を実際のコンテナIDまたは名前に置き換えてください。-it
フラグは、コンテナに対話型ttyをアタッチします。
セキュリティの維持
不要なコンポーネント、特にシェルを含めてコンテナイメージをビルドすると、セキュリティリスクが生じる可能性があることを忘れないでください。常にFROM scratch
からイメージをビルドしてクリーンに保ち、トラブルシューティングのために可観測性と統合してください。
コンテナへのSSH
シェルアクセスは便利ですが、SSHのようなより永続的な接続方法が必要な場合があります。DockerコンテナへのSSHアクセスを設定するには、いくつかの追加手順が必要です:
-
Dockerfileの作成: SSHをインストールし、必要な設定を行うDockerfileが必要です。簡単な例を次に示します:
FROM ubuntu:latest RUN apt-get update && apt-get install -y openssh-server RUN mkdir /var/run/sshd RUN echo 'root:YOUR_PASSWORD' | chpasswd RUN sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config EXPOSE 22 CMD ["/usr/sbin/sshd", "-D"]
YOUR_PASSWORD
を選択した安全なパスワードに置き換えてください。 -
コンテナのビルドと実行:
docker build
でイメージをビルドし、docker run
で実行します。SSHポートをマッピングすることを忘れないでください:docker build -t ssh-enabled-container . docker run -d -p 2222:22 ssh-enabled-container
-
コンテナへのSSH: SSHクライアントを使用してコンテナに接続します:
ssh root@localhost -p 2222
Dockerfileで設定したパスワードを使用してログインします。
セキュリティの維持
コンテナでSSHを公開すると、セキュリティリスクが生じる可能性があることを忘れないでください。常に強力なパスワードまたはSSHキーを使用し、ファイアウォールやSSHハードニングプラクティスなどの追加のセキュリティ対策を検討してください。SSHポートにアクセスする他の危険な方法もありますが、この投稿ではこれ以上詳しく説明しません。
シェルとSSHがDockerに良くない理由
コンテナにSSHで接続すると、本質的に従来の仮想マシンのように扱うことになり、これは分離された、一時的な、ミニマリスティックな環境というコンテナの哲学に反します。
-
セキュリティリスク: SSHサーバーは、コンテナに不要な複雑さと潜在的な脆弱性を追加します。コンテナで実行される各SSHプロセスは、悪意のある攻撃者にとって追加の攻撃面となります。
-
コンテナの肥大化: コンテナは軽量で、アプリケーションの実行に必要な必須パッケージのみを含むことを意図しています。SSHサーバーとシェルをインストールすると、コンテナのサイズが増加し、アプリケーションの機能に必要のない追加のレイヤーが追加されます。
-
コンテナオーケストレーションツールからの逸脱: Kubernetesのような最新のコンテナオーケストレーションツールは、
kubectl exec
などのコンテナにアクセスする独自の方法を提供します。SSHとシェルを使用すると、これらのツールをバイパスし、標準化されたワークフローからの逸脱につながり、構成のドリフトを引き起こす可能性があります。 -
ステートフルネス: コンテナは、ステートレスで不変であるように設計されています。コンテナにSSHとシェルで接続して変更を加えると、コンテナのイメージや定義ファイルに反映されないステートフルな構成につながる可能性があります。これは、コンテナが再デプロイされたり、異なる環境にスケーリングされたりするときに問題を引き起こす可能性があります。
-
ライフサイクル管理: Dockerコンテナは頻繁に停止および開始されることを意図しており、変更はコンテナイメージの更新を通じて行われます。SSHとシェルを使用することで、実行中のコンテナにアドホックな変更を加えたくなるかもしれませんが、これは不変インフラストラクチャの原則に反します。
-
管理の複雑さ: SSHキーの管理、ローテーションの確保、セキュリティの維持は、コンテナ管理に追加の複雑さの層を追加します。また、コンテナへのアクセスを管理する管理オーバーヘッドも増加します。
結論
Docker execのシンプルさを好むか、SSHの永続性を好むかにかかわらず、両方の方法はDockerコンテナと対話するための堅牢な方法を提供します。これらのツールを責任を持って使用し、セキュリティを念頭に置いて、コンテナを効果的に管理できるようにしてください。
このガイドがお役に立てば幸いです。詳細な手順とベストプラクティスについては、公式のDockerドキュメントとSSH設定ガイドを参照してください。ハッピーコンテナ化!