Machine: 別のクライアントから既存のマシンに接続する

：+1：

'generic'ドライバーを使用して2番目のシステムに追加し、そこで同じevalコマンドを使用するのはどうですか？

@clnperezは、これが提案であるか、それが機能すると確信しているものですか（つまり、現在実行中であっても、既存のリモートマシンを再利用します）。

まあ、後から考えると、sshキーを再度設定したり、他のシステムからインポートしたりする必要があるので、これを行うことはできないと思います。

私はあなたのケースを見ます。 元のdocker-machineセットアップを無効にする場合を除いて、汎用ドライバーを使用して2番目のシステムにdocker-machineエントリを追加することはできません（たとえば、新しいcredsが生成されるため）。 2番目のシステムでdocker-machine create -d none --url [...]を実行して、最初のシステムでの元の作成から重要なオプション（スウォームフラグなど）をミラーリングし、選択した.pemファイルとid_rsaファイルを最初のマシンから2番目のマシンに手動でコピーすることができます。そして、SSHアクセス用のセクションを手動で追加します（そして、ドライバーをnoneからgenericに手動で変更します）。 ピタです。 適切なエクスポート/インポート機能は、共有を許可するのに便利です。 Dockerを手動で構成するために必要なcredファイルだけを共有することもできます。

正しい。 現在の唯一の方法はディレクトリ全体を取得することですが、これは一部のドライバーでは機能しません（つまり、VMとネットワークを一致しないUUIDで登録するためVirtualBox）。 過去にインポート/エクスポート機能に関する議論がありました（https://github.com/docker/machine/issues/23）

私はこれに対するPR /ハッキーな解決策を持っています...一般的に、現在のようにハードコーディングするのではなく、構成をポータブル/テンプレート化に移行したいと思います。

+1

すでに存在するクラウドインスタンス（GCEを使用）にすばやく再接続できるようにしたいと思います。

確かにインポート可能/エクスポート可能な構成を持つことは非常に便利ですが、ドライバーの懸念としてこの問題に（さらに）対処しても、より単純なユーザーエクスペリエンスが得られないのではないかと思います。

このように、Googleドライバーを使用すると、有効なアクセストークンを提供するだけで、代替コンピューター上の既存のインスタンスに接続できます（ドライバーはユーザーに自動生成を求める場合があります）。

同様に、たとえばawsドライバーを使用する場合（私はまだ行っていませんが、おそらく）、有効なキーとシークレットのペアを提供することで（おそらく関連するドライバー固有の環境変数を介して）既存のインスタンスに接続できます。フラグ-期待値が少し異なるため、プロセスが「create」以外のdocker-machineサブコマンドを介して発生すると想定します）。

これは本当に素晴らしい機能になるという点でチャイムを鳴らしたいだけです。 チームメイトとマシンを共有できるようにしたいと思っていますが、現時点では基本的にこれを行う方法がないことに失望しました。 たとえば、 genericドライバーが、特定のボックスがすでにdocker-machineプロビジョニングされているかどうかを自動的に検出し、誰かがdocker-machine create実行したときに、tls証明書などを再利用できるとしたら素晴らしいでしょう。そのボックスに再び

：+1。 私はそれが機能するのを見たいです。 現在、同じマシン（Google Compute Engine上）を別の人と共同管理しています。作業していることがわかった唯一の方法は、ディレクトリ全体をコピーすることです（+ config.jsonファイルの絶対リンクを変更します）。 ださいよ。 ジェネリックドライバーはこの方法では簡単に使用できないと思います-もちろん認証の問題があります（tls certsなど）実行時に単純に再利用することはできません--create with generic driver（どういうわけか、認証してドライバーごとに異なるマシンにアクセスできます。GCEでは、gcloud認証でマシンへのアクセスが許可されているかどうかを確認する必要があります）。 また、特定のドライバーを使用して以前にマシンを作成していない限り、認証部分が欠落しているという小さな問題があります（認証する唯一の方法は..マシンを作成することです）。

私が最善の解決策だと思うのは、「import」コマンドを使用することです（ドライバーごとに実装が異なります）。 たとえば、GCEでは、必要なすべての詳細（キーなど）をマシンのメタデータのどこかに保存できます： https ：

この機能を本当にいただければ幸いです。

@potiukどのディレクトリをコピーしますか？

@AlexZeitler ~/.docker/machine/machines/<machinename>

+1！

+1私もこれに対する解決策を見たいです:-)

私は今日、同僚にアクセスを与えるためにまさにその問題に遭遇しました。

+1 !!!!!

＃23の複製のようですよね？
この機能について話してからほぼ1年が経ち、PRを試みた人もいましたが、閉鎖されました...
この機能が次の（メジャー）リリースになることを願っています:)

これは、TravisまたはCircleCIのキーを使用してデプロイする継続的デリバリーシナリオでは絶対に必要です。 ETAに関する手がかりはありますか？

これにも+1を与えなければなり

+1

+1

~/.docker/machine/machines/<name>フォルダーをコピーして絶対パスを変更する以外に、何かしなければならないことはありますか？ 証明書に関連するエラーメッセージが表示され、それらを再生成しようとしても失敗します。

@jbasraiアクセスしようとしているもののIPは変更されましたか？

https://github.com/docker/machine/issues/2516を提出して、これを簡単にするための正しい方向への手順の検討を開始しました。

これは重要な機能であり、近い将来のリリースで見たいと思います。 私の意見では、マシン構成は、インポート/エクスポートではなく、クライアントに固有のままである必要があります。 代わりに（他の人が言及しているように）同じ引数で実行されたdocker-machine createは、現在のように失敗するのではなく、リモートにすでに存在している場合でも、マシンの構成を作成できるはずです。 既存のamazonec2マシンに対してcreateコマンドを再実行すると、ホストがすでに存在することを示す次のエラーが表示されます。

Error creating machine: Error with pre-create check: There is already a keypair with the name testing-recreate.  Please either remove that keypair or use a different machine name.

代わりに、ホストがすでに存在していることを警告し、最初の作成時と同じようにマシンを追加し続ける場合があります（おそらくオーバーライドフラグを渡す必要があります）。 そうすれば、開発/ CI環境のセットアップスクリプトをシンプルに保つことができ、チームメート（または他の関係者）がアクセスできる場所にこの構成を保存する必要がなくなります。

複数の人が同じVMで作業するために、あるマシンから別のマシンに証明書をエクスポート/インポートする必要があることは確かに驚くべきことです。 誰かが実用的で本番環境に対応したソリューションを見つけた場合、それを知っておくとよいでしょう。

+1

+1

正しい。 現在の唯一の方法はディレクトリ全体を取得することですが、これは一部のドライバーでは機能しません（つまり、VMとネットワークを一致しないUUIDで登録するためVirtualBox）。 過去にインポート/エクスポート機能についての議論がありました（＃23）

@ehazlettなので、awsドライバーを使用しています。

1. クラウドマシンを圧縮する~/.docker/machine/machines/staging
2. チームメンバーと共有すると、 ~/.docker/machine/machines/解凍されます
3. 彼らは私と同じようにステージングマシンを持っていますか？ docker-machine ls （または別のコマンドを実行する必要がありますか）

@leandromoreiraこのアプローチの1つの障壁は、

cat ~/.docker/machine/machines/local/config.json

outputs:

...
        "AuthOptions": {
            "CertDir": "/Users/pretzel/.docker/machine/certs",
            "CaCertPath": "/Users/pretzel/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/pretzel/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/pretzel/.docker/machine/machines/local/server.pem",
            "ServerKeyPath": "/Users/pretzel/.docker/machine/machines/local/server-key.pem",
            "ClientKeyPath": "/Users/pretzel/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/pretzel/.docker/machine/certs/cert.pem",
            "ServerCertSANs": [],
            "StorePath": "/Users/pretzel/.docker/machine/machines/local"
        }

したがって、ディレクトリ全体をコピーするだけでは完全な解決策にはなりません。

@bhurlowどうもありがとう：smile ：、これを助けるツールはありますか？ または、 config.jsonを自分で手動で編集する必要がありますか？ それが唯一の障壁ですか？

@leandromoreira私はこのようにスクリプトを作成しましたが、 docker -machineの最近のバージョンでは、構成ファイルのキーがbase64でエンコードされなくなりました。 結局のところ、リモートのdocker-machineを使用したい人は誰でもTLS証明書を持っている必要があるので、当事者間の交換が必要だと思います

ありがとう@bhurlow

@bcwalrusは、何か公式になるまで素晴らしいツールを

npm install -g machine-share

# export
machine-share export amazon

# import
machine-share import  amazon.tar

# fix locations :D (it seems this is not using base64 anymore)
machine-share driverfix amazon

@leandromoreiraは素晴らしい

@muhammadghazaliそれは@bhurlowのアイデアと努力でした：stuck_out_tongue：

+1これに対する公式の解決策に関する更新はありますか？

dockerバージョン1.10.1では、config.jsonファイルに〜/ docker / machine / certsディレクトリからの次の参照があることに気付きました

        "CertDir": "/home/abc/.docker/machine/certs",
        "CaCertPath": "/home/abc/.docker/machine/certs/ca.pem",
        "CaPrivateKeyPath": "/home/abc/.docker/machine/certs/ca-key.pem",
        "ClientKeyPath": "/home/abc/.docker/machine/certs/key.pem",
        "ClientCertPath": "/home/abc/.docker/machine/certs/cert.pem",

このシナリオを機能させるには、元のマシンから〜/ .docker / machine / certsフォルダーもコピーする必要があります。

これに対する現在の解決策は次のように思われます（たとえば、あるコンピューター上のAWSでDockerマシンを作成し、別のコンピューターからマシンへのログまたはSSHを表示する場合）。

1. 共有するDockerマシン用に新しいディレクトリmy-dirとmy-dir/machineを作成して、デフォルトの証明書を使用しないようにします
2. --storage-path my-dir/machineオプションを使用してDockerマシンを作成します（絶対パスを指定してください）
3. マシンを共有するには、編集config.jsonでmy-dir/machine/machines/machine-nameとは、絶対パス置き換えるmy-dir/machineと$MACHINE_STORAGE_PATH
4. my-dirどこかにアップロードします（例：Github）

誰かがこのマシンをインポートしたい場合：

1. my-dirクローンまたはダウンロード
2. my-dir/machine/machines/machine-name内のマシンのconfig.jsonを編集し、 $MACHINE_STORAGE_PATHをローカルコンピューターのmy-dir/machineへの絶対パスに置き換えます
3. chmod 0600 id_rsaでmy-dir/machine/machines/machine-name

--storage-path my-dir/machineオプションを使用してDocker Machineコマンドを使用できるようになりました（絶対パスを指定してください）。

これは、次の方法で改善できる可能性があります。

• 相対パスをconfig.jsonに保存するDockerマシンなので、これを編集する必要はありませんでした
• Docker Machine SSH（および関連コマンド）id_rsaを0600に自動的に変更します（権限がある場合）

簡単なポイントとして、 envsubstを使用する場合は、プログラムで$ MACHINE_STORAGE_PATHを置き換えることができ、手動で編集する必要はありません。 それでも、Docker-Machineシステムのファームを使用しようとしているチームにとっては、全体的に不便です。

ただし、人々が回避策を探している場合、私が見つけた最も簡単な方法は次のとおりです。

1. .docker/machine/certsをプライベートスポットにコピーします。 他のマシンへのアクセスを許可するシークレットがあるため、これをリポジトリに入れないでください。 私たちはこの目的のためにプライベートストアを使用します
2. 新しいホストマシンで、証明書を新しい.docker/machine/certsにコピーします
3. ここで、docker-machineが作成したものを再実行すると、すべての構成を変更せずにこれを使用できるようになります。 時間がかかりますが、移植性が高く、これらすべての構成ファイルを編集する必要はありません。

私は2台の異なるコンピューターを使用していますが、これは私にとって大きな問題です。
ここでは、docker-machineを使用するときに期待する夢の動作について説明します。

1）DockerマシンとDigitalOceanドライバーを使用してDigitalOceanにドロップレットを作成します（DigitalOceanのコントロールパネルから取得したトークンを使用）。

docker-machine create --driver digitalocean --digitalocean-access-token \
    [token_goes_here] --digitalocean-image ubuntu-16-04-x64 --digitalocean-size \
    1gb [host_name_goes_here]

2）別のコンピューターに移動し、DigitalOceanから別のトークンを取得し、次のような魔法のアタッチコマンドを使用して既存のマシンにアタッチします。

docker-machine **attach** --driver digitalocean --digitalocean-access-token \
    [token_goes_here]  [host_name_goes_here]

これを機能させる上での障害は何ですか？ DigitalOceanアクセストークンは、既存のホストに接続してすべての安全な通信をセットアップするのに十分な特権を1つ与えると思います。

今のところ、 @ bhurlowによるmachine-shareを試してみます： //github.com/bhurlow/machine-share

これに+1バンプ-誰かがこれに関する更新を持っていますか？

@brandontamm ：この問題を自分で処理するためのスクリプトをいくつか作成しました。 彼らがあなたの問題を解決するかどうかはわかりませんが、少なくとも試すことはできます。 ここで要点を確認して

要点の要約：store_machineとload_machineの2つの関数があります。 store_machineは、マシンに関するすべての情報をセキュアスタッシュ（ディスクデータストアで暗号化）内に格納します。 パスワードを入力する必要があります。 load_machine関数は、ディスクデータストアからマシンをロードします。

このPythonコードは、sstash（Python Secure Stash）がインストールされていることを前提としていることに注意してください。 を実行してインストールできます

pip install sstash

+1

真剣に-別の事前定義されたデバイスからアクセスできない限り、Docker-Machineは何が良いのか...。

ユースケース-職場でDockerマシンを構築しましたが、サーバーが爆発した場合に備えて、休暇のためにラップトップが必要です...

さあ、Docker Adminはどこでチャイムを鳴らしますか？！ これは、誰もが理解できるユースケースです。

@realcrマシンシェアを試しましたか？

これ以上の依存関係を使用することを拒否します:)。dockerフォルダーを両方のOSXマシンにコピーすることは私にとって完全に機能しました。 私のパスとユーザー名は両方のマシンで同じだったので、手動でパスを編集しなくてもそれが鍵になります。

ブランドンタム
携帯から送られました

2016年11月4日には、午前3時36分AMで、セバスチャン・Bouletさんの[email protected]は書きました：

@realcrマシンシェアを試しましたか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

+1

+1

+1

+1

この問題を解決するためにdocker_machinatorを
これは、すべてのDockerマシンの資格情報と構成を、たとえばクラウドプロバイダーに保存できる暗号化されたスタッシュに保存できるようにするPythonツールです。 次に、これを別のホストからダウンロードして、マシンをスタッシュからロードし直すことができます。
これはPythonツールなので、使用することでpip installなるはずです。

これが完璧な解決策だとは思いませんが、より良い解決策が見つかるまで、これでうまくいく可能性があります。

皆さん、 machine-shareは、汎用ドライバーを使用してdocker-machineを介してdockerhostを作成するために使用したプライベートsshキーをエクスポートすることを知っておく必要があります。 したがって、エクスポートされたアーカイブを送信するすべての人が、dockerを実行しているサーバーにアクセスできるようになります。

@mxl docker -machineは、サーバーへのアクセスを許可するsshサブコマンドを提供するため、構成全体をインポート可能なファイルとして作成するツールがある場合、説明している状況は避けられません。

➜ docker-machine
Usage: docker-machine [OPTIONS] COMMAND [arg...]
...
Commands:
...
  ssh                   Log into or run a command on a machine with SSH.

これを回避する方法は、リモートマシンから現在の構成をダウンロードできるコマンドを作成することだと思います。 このようなダウンロードでは、インポート可能なファイルにアクセスをパッケージ化するのではなく、マシンにSSHで接続できる必要があります。

1つのホストからのみdocker-machineを制御できることは、不快な制限です。
docker-machine config-from <otherhost>ようなものも見たいです。

だから私からも+1。

/編集：現在、 .dockerを「マスターサーバー」から同じ構成を必要とする他のすべてのサーバーに同期することで問題を解決しています-cronとrsyncを介して。 これは、たとえば、複数のビルドスレーブに必要です。 あまり良い解決策ではありません。

+1

これが私をここに連れて来る別のシナリオです。

後でホスト領域を移動する必要があることに気付くために、Dockerイメージの束を作成するためのドロップレットを作成しました...

問題は、新しいホストで実行されているスナップショットから復元されたdocker-machineインスタンスをどのように接続するかです。

6時16分AMで金、2017年3月10日には、exjimsk [email protected]は書きました：

後で気付くために、Dockerイメージの束を作成するためにドロップレットを作成しました
ホストリージョンを移動する必要があります。 docker-machineインスタンスをアタッチするにはどうすればよいですか
新しいホストで実行されているスナップショットから復元されましたか？

証明書が変更されていない場合は、ローカルを変更するだけで済みます。
新しいIPアドレスを指すようにするdocker-machineconfig。 あなたは見つけるでしょう
〜/ .docker / machine / machine / your-machine-name /config.jsonにあるファイル。

または、Dockerコンテナにデータを永続化しない場合は、代わりに
ホストを移動し、それを殺し、新しいものを作り、そして同じように起動する
新しいホスト上のコンテナ。
ᐧ

+1

+1

+1

+1

+1

+1

+1

+1

docker-machine attachお願いします。

そのような明白な機能がまだ箱から出して存在しないことはかなり注目に値します。 Dockerホストを共同で管理するので、これは非常に厄介です。

私の場合、既存のホスト${HOST}を接続して非常に満足しています

docker-machine --tlscacert=ca.pem --tlscert=cert.pem --tlskey=key.pem create \
    --drive none --url tcp://${HOST}:2376

ただし、証明書（ DOCKER_CERT_PATH手動でコピーする必要があります。

これについて何か計画はありますか？ フルパスをconfig.json記録するのはイライラします。

私のユースケース：マシン構成が含まれているgitリポジトリがあります（docker-machineをポイントするために-sを使用します）。 シークレットはgit encrypt保存され、CIジョブがこれらの構成を利用して、アクセスする必要のあるマシンを操作できるようにするという考え方です。

参考： ＃3212

@lyda https://github.com/dmstr/docker-rojでこのようなアプローチを使用してい

rojは常に同じパスで機能しますが、コンテナー内にあるため、次のような他のソリューションがあります。

• https://github.com/bhurlow/machine-share
• https://gist.github.com/realcr/2363c699e893c66ac7ed72da29804b0a

これは基本的にconfig.jsonいくつかのパスを変更します。
私がここで何かを完全に見逃していない限り、それは大きな魔法ではありません。

docker-machineはdockerによって積極的に開発されていますか？ コミットがマスターに到達してから1か月以上経過しているので、質問します： https ：

+1

+1

+1

私の神、ホラー！ このスレッドは、ほぼ3年経ってもまだ生きていますか？！？ これは、誰もがぶつかる、またはそう思われるユースケースです。 何が足りないのですか？

docker-machineは死んでいると思います（少なくとも私にとっては：D）。 kubernetesに切り替えました。 アルファバージョンのセルフホストkubeadmでさえ、実際にはこれよりもうまく機能します。 私はそれをお勧めすることができます:)

これをサポートしてください:(

両方のマシンのクラウドフォルダーに同期されているか、シンボリックリンクされているフォルダーに「〜/ .docker」を追加します。 いくつかの構築済みソリューションがあります。 それほど難しい人ではありません。調査を行ってください。30秒間1回設定した後、問題が発生することはありませんでした。

+1

+1

この機能と静的IPの指定（docker-machineプロジェクトの歴史の中で最も要求された2つの機能）がどのように実装されないかは、私にはわかりません。

ほぼ4年が経過しました😮これに関する更新はありますか？

現時点では、Dockerに関する多くの記事/チュートリアルで、ホストを管理するための事実上のツールとしてdocker-machineを使用することを提案しています。 ただし、この問題の存在は強力な制限要因です。

私は現在、docker-machineを使い続けており、「copy-certs-dirs」アプローチを使用してローカルコンピューター間で共有しています。 Kubernetesにアップグレードしたいのですが、私のプロジェクトには多すぎます。

Dockerコンテナ内からdocker-machine createを実行するの

まだアタッチメントがありません、なんてことだ