※当サイトの記事には、広告・プロモーションが含まれます。

docker execでコンテナに接続と同時に実行させたい処理を複数ヒアドキュメントで渡せるっぽい話

gigazine.net

2025年1月20日、DeepSeekが推論モデルの「DeepSeek-R1-Zero」と「DeepSeek-R1」をMITライセンスの下でオープンソースとして公開しました。

DeepSeekはなぜこんな大騒ぎになっていて一体何がそんなにスゴいのか - GIGAZINE

「R1」のトレーニングコストはOpenAIの推論モデル「o1」の約3%程度だとも伝えられたために、AIの開発に対する業界の見方を大きく変えたこのモデルについて、AppleMicrosoft、Automatticでの勤務経験があるアナリストのベン・トンプソン氏が解説しました。

DeepSeekはなぜこんな大騒ぎになっていて一体何がそんなにスゴいのか - GIGAZINE

トンプソン氏は「つまり、推論の仕方を人間が教えずとも、十分な計算量とデータを与えればAIが勝手に推論してくれるという状態を実現したのです」と解説しています。

DeepSeekはなぜこんな大騒ぎになっていて一体何がそんなにスゴいのか - GIGAZINE

このアプローチによりモデルは思考時間により多くの時間を割り当てることが可能になり、予期せぬ能力が開花しました。これは、従来のデータセットを使い果たすことで学習のスケーリングが限界に近づくという既存のモデルの問題を解決する可能性があります。

DeepSeekはなぜこんな大騒ぎになっていて一体何がそんなにスゴいのか - GIGAZINE

⇧ 画期的なのかもしれないですが、利用者にとっては如何に「幻覚(ハルシネーション)」の発生が無くなっているかが重要なんですよね...

開発者にとっては、少ないコストで開発できるメリットがあるのかもしれませんが...

根本的な問題の解消までは、まだ遠い道のりということですかね...

プログラムは、解釈する機械が忖度してくれないから動作するには100%が求められるのだが、AIって70%ぐらいで良しとしてくるのであって、残りの30%の解決が困難ということ往々にしてあるのが現状だものね...

こちらが、誤りを提示しても「幻覚(ハルシネーション)」を発生させ続けて、解決策に至らずに堂々巡りになってしまうのが現状のAIなのだけど、「DeepSeek」はそのあたりの問題を解消してくれるんだろうか?

docker execでコンテナに接続と同時に実行させたい処理を複数ヒアドキュメントで渡せるっぽい話

Docker Composeで動作するアプリケーションのデリバリ作業を自動化できないものかと考えていて、ChatGPTに質問してみたところ、

■ChatGPT提案のシェルスクリプト

#!/bin/bash

...省略

# Dockerイメージを読み込む(イメージが無ければ)
echo "Dockerイメージが存在しない場合は読み込み中..."
if ! docker images | grep -q "$DOCKER_IMAGE"; then
  echo "イメージが存在しないため、読み込みます..."
  docker load -i "$LOCAL_PATH/$DOCKER_IMAGE"
else
  echo "イメージは既に存在しています。"
fi

# docker-compose up
echo "docker-composeでコンテナを立ち上げ中..."
docker-compose -f "$DOCKER_COMPOSE_FILE" up -d

# コンテナが起動するまで待機
echo "コンテナが起動するまで待機中..."

MAX_RETRIES=10  # 最大試行回数
RETRY_INTERVAL=5  # 5秒間隔で確認

# コンテナが起動しているか繰り返し確認
for ((i=1; i<=MAX_RETRIES; i++)); do
  if docker-compose ps | grep -q "Up"; then
    echo "コンテナが正常に起動しました。"
    break  # 起動成功したのでループを抜ける
  fi

  # 最大試行回数に達したらエラーとして処理を終了
  if [ $i -eq $MAX_RETRIES ]; then
    echo "エラー: コンテナの起動に失敗しました。最大試行回数に達しました。"
    docker-compose logs  # エラーログを表示
    exit 1  # スクリプトを終了
  fi

  echo "コンテナが起動していません。再試行中... ($i/$MAX_RETRIES)"
  sleep $RETRY_INTERVAL  # インターバルを待機
done

echo "コンテナが起動しました。"


# コンテナ内の処理
docker exec -it "$CONTAINER_NAME" /bin/bash <<EOF

# コンテナ内で実行したい処理

# コンテからログアウト
exit

EOF

# docker-compose down
echo "docker-compose downを実行中..."
docker-compose -f "$DOCKER_COMPOSE_FILE" down

...省略


⇧ というような回答が返ってきました。

ネットの情報を漁っていたところ、

hfuji.hatenablog.jp

⇧ 上記サイトで、SSHで接続してコマンドを実行していらっしゃったので、理論上はDockerコンテナに対しても似たようなことができるということなんですかね?

一応、

docs.docker.jp

⇧ 公式のドキュメントで、コンテナに接続と同時にコンテナ内でコマンドを実行させることはできるという記述が見られる。

ネットの情報を漁っていたところ、

qiita.com

⇧ ハマりどころがあるっぽい...

何やら、

stackoverflow.com

⇧ stackoverflowでも紹介されておりました。

それにしても、公式のドキュメントで見当たらないのに、解答に辿り着いているのが驚きですな...

公式のブログで、

www.docker.com

⇧ Dockerfileでヒアドキュメントする方法は紹介されておりましたが...

By the way、誠に遺憾ではありますが、この度も、ChatGPTの回答は「幻覚(ハルシネーション)」を引き起こしていた模様...

とりあえず、docker execで接続を維持した状態で複数コマンドをコンテナ内で実行することは実現できそうではある。

ちなみに、

qiita.com

⇧ 上記サイト様によりますと、Dockerコンテナ内のアプリケーションがログ出力している場合に、ログから特定の文言が出力されるまで処理をブロックすることもできそう。

ただ、処理が失敗することも想定して、タイムアウトなどは設けた方が良さそうな気がしますかね。

というのも、

qiita.com

⇧ 上記サイト様にありますように、常に再起動するという「再起動ポリシー」を設定していたとしてもコンテナが起動しないことがあるらしいので。

ちなみに、公式のドキュメントでは、

■Docker

docs.docker.jp

■Docker Compose v3

docs.docker.jp

github.com

■Docker Compose v2

⇧「Docker」と「Docker Compose」で微妙に設定で差分が出て来てるっぽいのが辛い...

何というか、

  • restart
  • restart_policy

の違いが分らん...

stackoverflow.com

⇧ 同じような疑問を抱えていらっしゃる方がおられました。

なるほど、

⇧ ということで、「restart_policy」の方は、

docs.docker.jp

⇧「Docker Swarm」で「Docker Compose」を利用した時の設定らしい、無茶苦茶に分り辛いんだが...

「Docker Compose」のドキュメントで「Docker Swarm」のセクションを明確に分けた方が良い気がするんだが...

話が脱線しましたが、各処理が完了するまで待機させて直列な処理が実現することができれば、Docker Composeで動作するアプリケーションのデリバリ作業をシェルスクリプトで自動化することはできそうってことですかね。

シェルスクリプトだとバックグラウンド処理とかを同期させるのが厳しいところもありますからな...

後は、シェルスクリプトはエラーハンドリングとかも微妙なので、プログラミング言語で自動化できれば良いんですけどね...

毎度モヤモヤ感が半端ない…

今回はこのへんで。