3

新しい docker swarm modeを使用して、ラップトップ (x86_64) と Raspberry Pi のクラスター (armhf) の両方で分散アルゴリズムをテストしたいと考えています。

一連の構成の後、1 つのマネージャー ノード (ラップトップ) と N+1 のワーカー ノード (N rasps と私のラップトップ) で構成される swarm クラスターを正常に作成できます。次のようになります。

laptop$ docker swarm init --advertise-addr 192.168.10.1
raspi1$ docker swarm join --token <TOKEN> 192.168.10.1:2377
# [...]
raspiN$ docker swarm join --token <TOKEN> 192.168.10.1:2377

ここで、プロジェクト用に 2 つのイメージを作成しましmy_project:x86_64た。x86_64 のイメージ ( ) と armhf のイメージ ( my_project:armhf) です。M 個の (準) 独立したノードを作成することはまさに私が望んでいることなので、この新しいスウォーム モードのノード/サービス アーキテクチャが本当に気に入っていますが、コマンドを使用して適切なノードに適切なイメージを与えるにはどうすればよいでしょうか?docker service create ...

私が見たところ、docker service createパラメータとして1つの画像しか取りません! ここで、各ノードにラベルを付けて、この特定のラベルを持つノードのみを使用するようにサービスに依頼できることを確認しましたが、それは私が望んでいるものではありません。最終的には、アーキテクチャごとに分割された 2 つのタスクのクラスターを管理することになり、swarm モードのスケジューラーとディスパッチャーを活用したいという私の欲求を押しつぶすことになります。

私は移植性への彼の探求の悲しいオタクです, それが私です!

PS: docker swarmとdocker swarm モードは 2 つの異なるものであるため、これには「docker-swarm」タグではなく「docker-swarm-mode」タグが付いていることに注意してください。

4

2 に答える 2

2

エイドリアン、ドッカー船長です。

現時点では、コンテナーがスケジュールされているノードに応じて異なるイメージをプルするサービスを作成することはできません。

ただし、両方のアーキテクチャの docker イメージに静的バイナリをバンドルし、基礎となるアーキテクチャに応じてどのバイナリを呼び出すかを entrypoint.sh で決定することができるハックがあります。

一方、アーキテクチャごとに 2 つのサービスを作成できるという事実は、それほど悪くありません。アプリの Arm および x86_64 バージョンは、ハードウェアの仕様に応じて異なるスケーリングが必要になる場合があります。追加のボーナスとして、基盤となるハードウェアに基づいて異なるメモリ/CPU 制限を適用することもできます。

これらのサービスは、 --network オプションを使用して同じネットワークに配置した場合でも相互に通信できるため、相互の対話方法を制御できます。

これがあなたの現在の問題を回避するのに役立つことを願っています. まだ代替案を検討中の場合は、お気軽にお問い合わせください。

于 2016-12-16T00:03:44.123 に答える
0

これについて考えてみると、armhf イメージをあらゆる場所で実行し、それらの一部をエミュレートして実行することで、パフォーマンスとオーバーヘッドが多少低下しますが、やりたいことを実行する方法があると思います。

画像 hypriot/qemu-register を見てください - そのソースはhttps://github.com/hypriot/qemu-registerにあります- そしてそれが何をしているのか理解できるところまで読んでください。基本的に、x86 マシンで armhf および aarch64 バイナリをエミュレートできます。次に、クラスター全体で単一のイメージを実行できます。

これはまさにあなたが求めていたものではなく、他の人が他の解決策に取り組んでいることは知っていますが、それにもかかわらず、これは役立つかもしれません.

于 2016-12-26T15:05:36.437 に答える