Machine: DockerMachineがメンテナンスモードになりました

ああ ：（

それが続いている間、これはよかったです:)
みなさん、お疲れ様でした！

readme.mdも更新してください。

マシンの公式サポートが終了した場合、このリポジトリでコミュニティ主導のサポートが継続される可能性はどのくらいありますか？

マシンが必要な方のために、 https：//github.com/machine-drivers組織でいくつかのアクティビティがあり、 ます。ドライバー/マシン...

パッチはここでマージされないように思われるため、この組織へのパッチの追加についてはすでに検討しました：＃4509（これはWindowsのローカライズバージョンをブロックしています）。 最善の方法は、何らかの形式のリリースを進めることですが、私たちにとっては、minikubeとminishiftは、ライブラリに対してリンクするだけで済みます。

@ shin-考えとして、新しいユーザーの「Getting Started」ドキュメントでは、イントロの中心部分としてdocker-machineを使用しています。

ドキュメントの更新に関心のある人は、代わりにどちらを説明する必要がありますか？

• Windows：Windows用のDockerデスクトップのよう
• Mac： macOS用のDockerデスクトップのよう
• Linux：マシンドキュメントを使い続けますか？

これは本当に残念だと思います。 マシンの真の力は、デスクトップを使用して1台のマシンで動作させるという単純さと、インフラキットの背後にある複雑さの間のどこかにあり

こんにちは！

誰かがLinux用の代替ソフトウェアを持っていますか？ ホストマシンでrootとしてdockerを実行したくないので、docker-machineはこの点である程度の分離を行っていました。 Docker for Linuxの計画はありますか？

ありがとう！

@gilbsgilbs現在と

@ shin-ご提案ありがとうございます。 私は新しいプロジェクトを始めているので、docker-machineを使用するのは奇妙な動きですよね。

@ shin- Weelll ...新しいプロジェクトにPRを使用するような手段に近づかないのはおそらく悪い考えです。 ：ウィンク：

@justinclift準備されたステートメントでより多くの情報が提供されているので、あまり詳細には述べようとしたように、プロジェクトはPRに閉じられていません。 新しい機能ではなく、バグ修正に限定することを目指しています。 docker-machineの現在のイテレーションの機能セットがニーズに合っている場合は、新しいプロジェクトであっても、それを放棄する理由はありません。

インフラキットもアクティブではないようです。 1年以上リリースはなく、DockerCon 2018のアップデートも、 https： //docs.docker.com/machine/のようなユーザードキュメントもありませんでした

Dockerマシンのドキュメントでは、Docker Cloudを試してみることを提案しています。DockerCloudは、Docker EE（一般には利用できません）を優先してシャットダウンします。

プロジェクトをフォークするか、他の場所を探すことをお勧めします： https ：

不平を言うのではなく、私の見方を説明するだけです。

面白い。 InfraKitのコミット履歴を見ると、数日ごとに新しいコミットを受け取りますが、ほとんどの場合、 1人の作業であるように見えます。

活動は4月/ 5月頃に枯渇したようです。 人々の時間を推測することは他のものにリダイレクトされました。

それは物事の間違った見方ですか？

@ shin-しかし、PRの多く（Hyper-Vの国際化を機能させるために提供するバグ修正など）はマージされていません。 これは、「新しいプロジェクトであっても、それを放棄する理由がない」という観点から、「新しい機能ではなく、単にバグ修正に限定しようとしている」という良い兆候ではありません。

@ shin-

準備されたステートメントでより多くの情報が提供されているので、あまり詳細には触れたくありません

その公式声明にリンクしてもらえますか（公開されるたびに）私はそれを見つけることができません。

最新になるようにドキュメントを変更することを強くお勧め
私の最後の1時間は、boot2dockerの無意味な調査でした。これは、dockerクラウドを最新のテクノロジーとして使用するようにアドバイスする警告がメインページにあるdockermachineを明確に示しています。 これは、Dockerクラウドドキュメントの説明（移行ページではありません!!!!）を示しており、5月に廃止されたことを確認するためにグーグルが必要でした（ただし、3月に発表されたため、7か月前）。 Docker Machineのドキュメントから警告を削除することを提案するためにここに来ました。この3か月前の問題で、DockerMachineも廃止されていることがわかりました。
これは、ドキュメントがどのように機能するかではありません。 アドホックソリューションに戻りますが、まだ使用していない場合はDockerを放棄します。

@aliceminottoあなたが話しているサイトやページを指すことができれば、私たち全員が古いドキュメントを更新するのに役立ちます。

docker-machineがなくなるわけではなく、機能の範囲が広がるだけではありません。

Docker Cloudがなくなることはなく、サーバーのプロビジョニング/管理に使用されなくなっただけです。 それはまだイメージ構築のためにあります。 Dockerには、 Docker for AWS 、 Docker for Azure 、 DCI for DockerEnterpriseなどの本番サーバー用の他のツールがあります。

私は古いhttp：//boot2docker.ioWebサイトのことを完全に忘れていて、そこにある通知の文言があまりにも貧弱であることに気づいていませんでした（混乱の原因となったことをお詫びします！）-更新（およびスリム化）しましたうまくいけば、古代のCLIツールであるboot2dockerがDocker Machineを支持して非推奨になり、boot2dockerディストリビューションは非推奨ではなく、メンテナンスモード（Docker Machineと同じ）になっていることをより明確にするためのコンテンツ。

別の言い方をすれば、新しいDockerリリース、カーネルの更新などですが、Windows用のより適したDockerにまだ移行できない少数の人々の継続的な保守性を確保するために、新しい機能を最小限に抑えるための協調的な試み/ Docker for Mac製品または上記の本番サーバーツール/ソリューション（Docker forWindowsをまったく実行できないWindows7ユーザー、Hyper-Vを実行できないWindows 10 Homeユーザー、Hyper-を実行できないVirtualBoxユーザーVなど）。

@tianon ：MacやWindowsへの移行を望まないLinuxユーザーについても言及したいと思うかもしれません...

@afbjorklundすでにLinuxを使用しているのに、なぜ

@Vanuan ：ディストリビューションが古すぎるため（RHEL6など）、またはルートが許可されなかったため...

いずれにせよ、Dockerデスクトップへの移行はオプションではありません-DockerEngineまたはDIYLinuxKitのどちらですか？

dockerをよりアクセスしやすくしてくれたdocker-machineとboot2dockerのメーカーに感謝します。

そして、マシンドライバー（KVM用）の努力により、それがまだしばらくの間機能し続けることを願っています

デスクトップにサーバーディストリビューションを使用するのはなぜですか？ そして、なぜ私は自分のデスクトップの管理者ではないのですか？ しかし、どういうわけか私はKVMへのアクセスを許可されていますか？

KVMサーバーでdockerを実行するためのソリューションを探しているようですか？ その場合、私は現在ここでインフラキットを調査しています： https ：

しかし、Linuxデスクトップでdockerを実行することだけを考えているのなら、DockerCEと一緒に最新のUbuntuをインストールしない理由がわかりません。 VMで実行する場合は、実行します。 VirtualBoxにホームディレクトリをマウントし、SSH経由でdockerを使用できます。 ここで何が問題なのですか？ 意味がないため、Linuxデスクトップ用のDockerはありません。 少なくとも私には。

デスクトップにサーバーディストリビューションを使用するのはなぜですか？ そして、なぜ私は自分のデスクトップの管理者ではないのですか？ しかし、どういうわけか私はKVMへのアクセスを許可されていますか？

一部の人々は、雇用主から渡されたデスクトップOSを使用する必要があります。 RHEL6は、私が（数か月前に）株式取引所で働いている男から話された例です。 ：ウィンク：

一般的なデータポイントとして、Libvirtでは（少なくとも以前は）ユーザーが自分のアカウントで実行できるVMの概念があり、それはユーザー専用です。 たとえば、同じマシンにログインしている他の人がアクセスできない

Libvirtの開発作業のほとんどは、ユーザーレベルではなく、「システムレベル」のVMに向けられていたため、これまでに開発されたかどうかはわかりません。

Linuxデスクトップでdockerを実行することだけを考えているのなら、なぜ最新のUbuntuをインストールしないのかわかりません。

かなりの数の人々が何らかの理由でUbuntuを嫌っています。 ：ウィンク：

v18.09（ DOCKER_HOST=ssh:// ）以降、 docker-machineなしでリモートDockerマシンをセットアップするのは本当に簡単です： https ：

一般的なデータポイントとして、Libvirtでは（少なくとも以前は）ユーザーが自分のアカウントで実行できるVMの概念があり、それはユーザー専用です。 たとえば、同じマシンにログインしている他の人がアクセスできない

はい、 qemu：// sessionと呼ばれます
最新のGNOMEには、そのための優れたアプリもあります-ボックス： //en.wikipedia.org/wiki/GNOME_Boxes

ユーザーモードのKVM仮想化には、ネットワーキングに関していくつかの欠点があります。 ですから、これらの状況ではVirtualboxが唯一の選択肢だと思います。

そして、VirtualBox用のCLIを使用するには、選択が迷います。 その上でdockerを実行するには、いくつかのLinuxディストリビューションが必要です。 そして、テストされた最も多くの戦いはUbuntu / Debianです。 ただし、他のディストリビューションはダウンロードできます。 ただし、Vagrantで使用するには、自分でパッケージ化する必要があります： https ：

古いMacや古いWindowsのユーザーと同じように、 docker-machineはこれらのLinuxユーザーにとって良い解決策だと言っているだけです...必要なのは、標準ではないポートでdockerを実行することだけでした。ハードコードされた2376？ そして、libvirtグループ（つまりroot）を必要としない新しいqemuドライバー。 将来的にはインフラキット/ハイパーキットが代替になるかもしれませんが、現時点では（上記のリンク）、まだ端がかなり荒いように見えます。

@Vanuan ：ubuntu / Dockerエンジン」と呼んでいます。

@justinclift ：各ユーザーは独自のsshキー/ドッカー

@afbjorklund心配ありません。 LibvirtチームのRedHatで働いてから何年も経ちました。 最近では、問題を診断するときに、それを非常に深く理解するのではなく、一般的に使用しています。 ：スマイル：

@afbjorklundこれを

MacやWindowsへの移行を望まないLinuxユーザーについても言及することをお勧めします...
いずれにせよ、Dockerデスクトップへの移行はオプションではありません-それはDockerエンジンまたはDIY LinuxKitのどちらですか？
私はubuntu / vagrantオプションについて知っていますが、上記では単に「DockerEngine」と呼んでいます。

boot2dockerは、ディストリビューション（ boot2docker.iso ）であり、virtualboxを管理するためのツール（ boot2docker-cli ）でもあります。 boot2docker.isoには、 Docker CE （以前のDockerエンジン）が含まれてい

https://github.com/boot2docker/boot2docker/blob/d465167d83310295b5847ba315905f52c3ca1435/Dockerfile#L426 -L435

そして、これは新しいDockerCEリリースに更新され続けます。

boot2docker-cliはなくなりましたが、本質的には、virtualboxを使用しているだけです。 浮浪者はまだ周りにいます。

KVMドライバの使用libvirtのVMに提供_Docker CE_にboot2docker.iso。

Docker Desktopは、 linuxkitで構築されたディストリビューションを使用して、_DockerCE_をHyper-Vおよびxhyveにプロビジョニングします。

すべてを描くには：

ご覧のとおり、すべてのソリューションには、Docker Engine（現在はDocker CE for Linuxと呼ばれてい何らかの形で含まれています。

環境と仮想化/クラウドソリューションが多すぎます。 その結果、windows / mac / linuxで同等に機能し、QEMU / Virtualbox / xhyve / Hyper-vとさまざまなクラウドおよびオーバーSSHプロビジョニングをサポートできるツールは1つもありません。 また、このようなツールには構成可能性も必要です。さまざまなポート、メモリ/ CPUリソース管理、ネットワークなどをサポートします。したがって、おそらく汎用ツールとhttp経由でダウンロードした構成ファイルが最適なソリューションです。

@Vanuan ：はい、これは私たちが上で言ったことです。 docker-machineを置き換えるには、MacまたはWindowsとDockerデスクトップに切り替える必要があります。少なくとも_someone_がLinuxKitやlibvirtと同様のものを作成するまでは...

boot2docker-cliについて話す必要はもうありません。また、Linuxドライバーのサポートは_すでに_「machine-drivers」組織に移行しています。標準のdocker-machineではVirtualBoxしか利用できないためです。

@ shin-新しい機能を許可しなくなった場合は、 README.mdとCONTRIBUTING.mdの上部に非常に明確なメモを追加することを検討してください。

これらのファイルの両方を注意深く読み、ドライバーを実装し（数日間の作業）、ドライバーがもうマージされないことに気付かないのは非常に面倒です。 これははるかに明確なはずです。

これがすべて誤解であり、それでもドライバーのプルリクエストを許可されている場合は、お知らせください。 現時点では、プルリクエストを作成すると表示されるのは隠しファイルでのみ言及されているということです。

README.mdおよび/またはCONTRIBUTING.mdメンテナンスモードに関する明確な情報はまだありません。 私は休暇時間の半分を費やして、ProxmoxVEVM作成とDockerデプロイメント用の軽量Linuxの実用的なソリューションを見つけました- docker-machine + docker-machine-driver-proxmox-veの組み合わせは、その使用に非常に適していることがdocker-machineを優先して非推奨になり、一部のスレッドのメンテナは、RancherOSを提案しています。 docker-machineは、それが何を意味するのかを明確に定義せずにメンテナンスモードに移行します（バグ修正のみが受け入れられ、新しいプロジェクトに問題がないことを示唆することは、矛盾するIMOです）。 2018年8月に公式発表もありましたが、ここでは言及の兆候はありません。

SMB向けの合理的なインフラストラクチャを構築したいという部外者の観点からは、 docker-machineは正しい長期的なソリューションのようには見えません。 ハイパーバイザーおよびDockerをサポートする最小限のLinuxとしてProxmoxVEVMをプロビジョニングおよび管理するためのReasonablyGood™は誰でも提案できますか？

残念ながら、boot2dockerに依存しています。これは、docker-machineを優先して非推奨であり、一部のスレッドのメンテナーは、RancherOSを示唆しています。

boot2dockerがdocker-machineを支持して非推奨であると主張している場所をより具体的に教えてください。そうすれば、それを適切に明確にすることができますか？ （何年も積極的に保守されていない古代のboot2docker CLIツールを具体的に参照しない限り、それは真実ではないため）

boot2dockerディストリビューション（具体的には、Docker CEの新しいリリースごとにリリースされるboot2docker.isoアーティファクト）は、焦点が非常に狭いものの、私が知っている限りすぐになくなることはありません。現在（したがって、新しい機能/機能はマージの対象とは見なされない可能性があります）。

@tianonそうです、混乱してすみません。 ウェブサイトのメッセージにはboot2docker CLIと書かれていますが、一見したところ、違いがあるかどうかはわかりませんでした。 boot2docker.iso直面する可能性が高いため、他のユーザーも混乱する可能性があると確信しています。 boot2docker CLIは聞いたことのないもので、プロジェクト間の関係を言うのは難しいです。 OTOH boot2docker.isoステートメント"maintenance mode"は、この返信に基づいて結論付けたdocker-machineと同じように曖昧です。

混乱を要約すると：

1. "maintenance mode" -両方のプロジェクトで明確ではありませんが、中小企業での生産に使用できますか？
2. 両方のプロジェクトリード開発者/メンテナは、以前にサポートされたユースケースのすべての使用をカバーしていないように見える他のプロジェクトの使用を提案します

理想的には、@ tianonと@ shin-から明確な声明をdocker-machine使用が本番環境で問題ない場合は？

Docker Machineについて話すことはできませんが、boot2dockerが本番環境に適した選択肢ではありませんでした。 そのターゲットは、開発/パーソナルワークステーションの使用です。

https://github.com/boot2docker/boot2docker#readmeに追加されたメモも参照して

他の多くの人と同じように、SMBクライアントにマシンを使用することに努力した後、Githubの問題からこれについて学ぶことに不満を感じました

公式ドキュメントを更新するためのPRを作成し、マシンのメンテナンスモードに関するアドバイザリを追加しました。

https://github.com/docker/docker.github.io/pull/9239を参照して

開始するDockerも変更するとよいでしょうhttps://docs.docker.com/get-started/part4/

編集：aws ec2インスタンスにdocker-ceをインストールし、sshポートでdockerデーモンを転送するという解決策を見つけました。

ssh -NL localhost:23750:/var/run/docker.sock -i ***.pem ubuntu@***.compute.amazonaws.com
docker -H tcp://localhost:23750 run hello-world

🎉

Docker Desktopがインストールされているため、最近docker-machineを使い始めました。ローカルマシンよりもはるかに強力なawsインスタンスでdockerを実行できることに気付きました。 Visual Studio CodeなどのDockerコマンドを使用するローカルアプリは、ローカルで実行されているかのようにDockerマシンコンテナーで動作できるのが魅力です。

インフラキットやkubernetesなど、クラスターをプロビジョニングする新しい方法がたくさんあるのと同じように、docker-machineに取って代わられていないように思えます。

私は誤解している可能性があります。 上記のことを行うための移行戦略はありますか？

GitLabとGitLabRunnerツールを使用して、CI / CDジョブを実行するためのEC2スポットインスタンスを動的にプロビジョニングします。 GitLab Runnerは、DockerMachineを使用してこのマシンプロビジョニングを実行します。

Amazon Linux 2を優先して、すべてのサービスをUbuntuから（肥大化した）Ubuntuに移動することにしました。嬉しいことに、PR＃3609でこれが可能になります。

しかし、この「蛇口の閉鎖」のために、＃3609はその場で死ぬようです。 現在の競合しないマージ可能な状態で、マージすることを検討してください。

Gitlabの人たちはすでにフォークを維持しているので、おそらく彼らはこのレポの世話をすることに興味があるでしょうか？

@ usha-mandya @ Dawn-docker / docker.github.io＃9239で更新を行いましたか？ 念のため、すべてのDockerマシンページに警告を追加します。 これはマージされましたが、エンタープライズ分割が行われている間に元に戻されたため、yallはDMの将来についていくつかの決定を下すことができました。 DMがメンテナンスモードを継続する場合は、このアドバイザリを用意しておくとよいでしょう。

最新バージョンのDockerDesktopにdocker-machine含まれなくなったAFAIK

DockerDesktopの最新バージョンであるAFAIKには、docker-machineが含まれなくなりました

デスクトップ2.2.0.0のdockerにアップデートした後、内部のdocker-machineツールが機能しなくなったため、この問題についてそのように学びました。

この動きがデスクトップリリースノートのDockerにも記載されていないのは、一種の苛立ちです。

Docker-machineを多用して、Hyper-Vドライバーを使用した内部DEVおよびステージング環境用の共有booot2dockerベースのdocker-machineを管理および保守します（したがって、docker-machineを使用してboot2docker hyper-v VMをプロビジョニングします）。 そのため、LinuxクライアントとMacクライアントがあり、Windows / OS XにDockerを使用している場合でも、CI / CD関連のDockerマシンに大きく依存しています。

私はこのセットアップの同様の代替品を知りません-ここで明らかな何かが欠けていますか？

brew（macOS）を使用して、最新のバイナリをいつでも直接ダウンロードできます。
リポジトリから。 それはまだ維持されています（パッチ）がゆっくりです
DockerDesktopなどのツールは段階的に廃止されました。
https://github.com/docker/machine/releases

11:47時月、2020年1月27日にはsambernet [email protected]書きました：

DockerDesktopの最新バージョンであるAFAIKには、
docker-machine

DockerDesktopの最新バージョンであるAFAIKには、
docker-machine

私たちの内部docker-machineとして、この問題についてそのように学びました
デスクトップ2.2.0.0のdockerにアップデートした後、ツールが機能しなくなりました

この動きがDockerに記載されていないのはちょっとイライラします
デスクトップのリリースノートも。

共有を管理および維持するためにdocker-machineを多用しています
内部DEVおよびステージング用のbooot2dockerベースのdocker-machines
Hyper-Vドライバーを使用する環境（したがって、boot2dockerhyper-vをプロビジョニングします
docker-machineを使用するVM）。 つまり、LinuxとMacのクライアントがあり、
したがって、Windows / OS XにはDockerを使用しますが、それでもdocker-machineに大きく依存しています
CI / CD関連のもの。

私はこのセットアップの同様の代替品を知りません-私は行方不明ですか
ここで明らかな何か？

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/docker/machine/issues/4537?email_source=notifications&email_token=AAGBNX2APIHK6CBNGSAMLDDQ74FYPA5CNFSM4FJ53G3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWS
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAGBNXZV7PCYP3TLWSZ7QODQ74FYPANCNFSM4FJ53G3A
。

また、Docker-machineが先週困難な方法で段階的に廃止されていることも学びました😒
docs.docker.comには、docker-machineが「置き換えられた」と書かれていますが、置き換えられたものに関する情報が見つかりません。 ローカルのvirtualboxマシンをSOMEthingで管理し続けたいのですが、将来を見据えた方法でそれを行うためのヒントはありますか？

export DOCKER_HOST = ssh：// user @hostが機能する場合があります

ローカルのvirtualboxマシンをSOMEthingで管理し続けたいのですが、将来を見据えた方法でそれを行うためのヒントはありますか？

あなたはおそらくそのためにVagrantを使うことができますか？ または、 docker-machine引き続き使用することもできます...

ただし、Docker（Desktop）の一部ではなくなったため、バイナリ用にここに来る必要があります。

私はこのセットアップの同様の代替品を知りません-ここで明らかな何かが欠けていますか？

代替品はありませんが、多くの人がmachineとlibmachineの継続的な使用に興味を持っています。

もちろん、_代替品_（異なる製品）がありますが、それは（フォークと）実際には同じではありません。

@afbjorklundまあ、

それが今あなたのために起こっていることだけではない場合（のみ）、おそらくそれについてGitHubサポートにpingするのが最善です。

コンテナを単純にデプロイするための好ましい方法について、私は非常に混乱しています。
Dockerを介したコンテナーの作成は、サービスを作成するための標準的な広く使用されている方法として推進されています。 これが、現在作成しているWebサイトのコンテナーを作成するために使用したものです。
しかし、明らかに、これらのコンテナーをVPSにデプロイする必要があります。 だから私はdocker-machineを使用します。これは、私が知っている唯一の文書化された、実際には非推奨ではない方法だからです。 そして今、私はそれが「メンテナンスモード」にあることを知ったので、新しいプロジェクトでそれを使いたくないかもしれませんが、インフラキットとは何ですか？ 2Kの星がありますが、それが何のためにあるのか（そしてDockerマシンを簡単な方法で置き換えることができますか）または公式ドキュメントを理解するのに苦労しています。現在は読み取り専用モード（アーカイブ）になっているので、使用するべきではないと感じていますまた、このリポジトリのReadme / issuesには新しいリポジトリへのリンクはありません。 ドキュメントがなく、Dockerマシンを置き換えると廃止されるのはなぜですか。
Dockerは非常に人気のあるソリューションのようですが、コンテナーをデプロイするための廃止されていない（または「メンテナンスモード」の）方法を1つも見つけることができません。 Dockerが非常に広く使用されている場合、Dockerを使用する数百万人の開発者がアプリケーションのデプロイにどのように対処しますか？

もともと、Dockerは、コンテナーをデプロイする公式の方法として、有料バージョンのDockerEEを宣伝したと思います。 そこで彼らは、DockerマシンとInfrakitのイニシアチブを、ビジネスモデルを脅かすものとして否定しました。

さらに、k8sは状況を完全に変え、Dockerは適応に苦労しました。

MirantisがDockerEEを買収した今、Dockerは別のビジネスモデルを模索しています。 新しい方向性は、アプリケーションバンドルをk8sエコシステムに注入し、k8sのデプロイ自体をコミュニティに任せようとしていると思います。 特にk8sはDockerCE（Linux上）の一部ではないためです。

K8s、OTOHはGoogleによって管理されています。Googleは、K8sのデプロイを非常に複雑にして、文字通り「ねぇGoogle、K8sクラスターをインストールしてください」と言うほどのインセンティブを持っています。 したがって、Googleクラウドサービスにロックインします。

そのため、クラウドをロックインから解放し、クラウドを商品にするというソロモン・ハイクスのビジョンは、惨めに失敗しました。

@NitroBAYのサーバー上で実行中のアプリケーションにコード作成から「ソフトウェアのライフサイクル」（および最終的にはサーバー上で更新）が「サーバに構築され、ダウンロードされたコンテナの画像を取得」の様々な方法のトンで、非常に複雑であるため、それは言うのは難しいですあなたの解決策はどうあるべきか。

もともと、docker-machineは次の3つのことを行うことでした。

1. 主要なクラウドプロバイダー、またはローカルマシンのVMマネージャー（VirtualBox、Hyper-V、VMWare、Parallelsなど）で単純なVMをプロビジョニングします。
2. 自己署名証明書を含め、そのVMにDockerをインストールし、APITCPポートを開きます
3. そのサーバーへの簡単なssh、およびdocker cli（docker-machine env）を使用したリモートでのdockerの制御

（古典的な群れの作成などのレガシー機能については忘れましょう）

最初の「LinuxVMの作成」の場合： VMの作成方法として選択したクラウドのツールに置き換えることをお勧めします。 ローカルで、Linux VMをインストールするよりも高速なものが必要な場合は、マルチパスを確認してください。これは、1つのコマンドで新しいUbuntuVMを数分で起動するための私のお気に入りの方法です。

2番目の「LinuxVMへのdockerのインストール」では、インストールスクリプトまたはOSディストリビューションの公式ドキュメントを使用して、最新のVMにdockerをインストールでき

DockerはすべてのCI / CDの問題を解決することはできませんでした。また、docker-machineは実際にはVMプロビジョニングと基本的なインストールツールにすぎないため、多くの人がより柔軟で保守しやすいソリューションを必要としていました（たとえば、docker-machineは簡単に共有できません）。マシン間のサーバー構成）。 Dockerチームは、工作機械がこれらすべての問題を解決することを意図したものではありませんでした。 それは今日でもそれらのオリジナルのもののために働きます、それでそれがあなたのために働く限りそれを自由に使ってください。 私は今でも毎月使用しており、2015年から使用しています。

docker-machineが解決した特定の問題について詳しく説明した場合は、実装できる特定の代替案をお勧めします。

たとえば、上記の「dockerをリモートで制御する」の＃3に関しては、docker-machineがAPI認証用の自己署名証明書をプロビジョニングし、dockerenvをローカルで変更してリモートサーバーを制御できるようにするのが好きでした。 そのレガシーメソッドは、2018年以降、Docker CLI用のはるかに簡単な（そしてより柔軟で安全な）SSHトンネル組み込みメソッドにのDockerCLIに、2つの方法のいずれかを介して接続する場所を指示する必要があります行い、昨年の夏に新しいコンテキスト機能のデモをライブショーで行いました。これにより、DockerサーバーのリストをDocker CLIに直接保存し、SSHまたはTCPを使用してそれらをリモートで制御できます。

また、InfraKitはシステムビルダー（カスタムLinux OSを作成するppl）向けのツールであり、ホスティング業者で作成された通常のLinuxディストリビューションを必要とし、DockerをインストールするようなLinuxユーザーではありません。

うわー@BretFisherあなたの非常に詳細な答えを
記録のために、リモートマシンにconfig.jsonをアップロードするスクリプト（プライベートイメージをダウンロードできるようにするため）と作成ファイルを作成することになりました。 そして、「dockerstackdeploy」を実行します
私のデプロイshは次のようになります

#!/bin/bash
ssh -o StrictHostKeyChecking=no -l root "$HOST" root@$HOST "mkdir /opt/app; mkdir /root/.docker"
source ./devops/generate-branch-hostname.sh
scp ./devops/docker-compose-prod.yml root@$HOST:/opt/app/docker-compose-prod.yml
scp $HOME/.docker/config.json root@$HOST:/root/.docker/config.json
echo "BRANCH_HOSTNAME=$BRANCH_HOSTNAME"
ssh root@$HOST "export BRANCH_HOSTNAME=$BRANCH_HOSTNAME; docker stack deploy --compose-file /opt/app/docker-compose-prod.yml webapp --with-registry-auth"

（BRANCH_HOSTNAMEは明らかに必要ありません。たまたま、スクリプトをトリガーするGitブランチに基づいて異なるサブドメインがあります（私はCI / CDを使用しています））
そして、私はまだdocker-machine createを使用して、ubuntuリモートVPSにdockerをインストールしています。

とにかく、DockerマシンはCI / CDではお勧めできません。証明書の共有は簡単ではなく（フォルダー全体）、証明書を再生成するとDockerが停止する可能性があるため、これもオプションではありません。

DOCKER_HOSTなどをプロビジョニングし、SSHキーを使用するツール（コミュニティまたはDockerによって作成されたもの）が存在する必要があると私はまだ信じています。 「scp」や「ssh」よりも簡単です。

Dockerマシンは避けられないことが判明しました。

私はプロではありません。私は自分のWebプログラミングで学び、大きなプロジェクトでサイドタイムに取り組んでいるだけなので、K8sは簡単ではないツールとして説明されているため、私のニーズに合わないと思います。少なくとも中規模/大規模の専門家チームのみが対象であり、開発（フロント/バックエンド）と展開の両方を行う時間がほとんどない1人の個人は対象外です。 だから、Dockerの場所はまだあると思いましたが、おそらく私が聞いた福鼎の問題がないために、アプリをデプロイするための公式の好ましい方法と、Dockerマシンの後継者のための計画についてより明確にする必要がありますそれについての計画はありません。

DOCKER_HOSTなどをプロビジョニングし、SSHキーを使用するツール（コミュニティまたはDockerによって作成されたもの）が存在する必要があると私はまだ信じています。 「scp」や「ssh」よりも簡単です。

export DOCKER_HOST=ssh://[email protected]実行するだけです

rootユーザーに対してsshログインを無効にしている場合は、root以外のユーザーuserを使用できます。
export DOCKER_HOST=ssh://[email protected] userを使用してdockerグループにuserを追加した後、 sudo usermod -aG docker user 。 （Ubuntu 18.04でテスト済み）

WindowsでマルチノードのDockerSwarmを試してみる代わりの方法はありますか？ 群れのチュートリアルでは、現在、DockerマシンがないWindowsではこれは不可能であると述べています。

現在、Docker Desktop forMacまたはDockerDesktop for Windowsのみを使用して、マルチノードスウォームをテストすることはできません。 ただし、付属のバージョンのDocker Machineを使用してスウォームノードを作成し（Docker MachineとローカルVMの使用を開始するを参照）、すべてのマルチノード機能のチュートリアルに従うことができます。

https://multipass.run/を使用して、複数のUbuntuVMをすばやく作成します。 docker-machineと同じくらい高速です。 3ノードのSwarmでの使用方法については、デモを参照してください： https ：

そのデスクトップの使用法は、ほとんどがDockerデスクトップ製品に取って代わられています。

このスレッドのすべての人への注意：Dockerデスクトップはフリーソフトウェアではなく、オープンソースではなく、大量のスパイウェアが埋め込まれているため、そのアップグレードパスに従うことについてよく考えてみてください。

これが誰かに役立つかもしれない場合のために、リモートホストにdockerをインストールするスクリプトがあります（Debian 10 =バスターでテスト済み）：
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213 -L252

これは、Fabricと呼ばれるサーバー自動化フレームワーク（特にfab-classic githubとdocs ]に基づいています。Fabricを使用したくない場合でも、コマンドを簡単に読み取って手動で実行し、bashスクリプトに変換できます。

その後、 export DOCKER_HOST=ssh://[email protected]を実行すると、Dockerマシンを使用したときの状態に戻ります。

このスレッドのすべての人への注意：Dockerデスクトップはフリーソフトウェアではなく、オープンソースではなく、大量のスパイウェアが埋め込まれているため、そのアップグレードパスに従うことについてよく考えてみてください。

@sneak 「スパイウェアのトン」とは、「エラーレポート、システムバージョン、言語、およびDockerデスクトップのライフサイクル情報（起動、停止、リセットなど）を送信する」という設定設定の「使用統計を送信する」を指します。どちらをオフにすることができますか？

私は、プロプライエタリのクローズドソーススパイウェアについてさらに議論することに時間を費やすことには興味がありません。

低品質のトロール

トローリングには巧妙さが必要です。 私は誠実であり、私の発言は正確です。

• dockerデスクトップは独自仕様です

• dockerデスクトップはクローズドソースソフトウェアです

• dockerデスクトップは、同意を得ずにユーザーをスパイします（dockerマシンと同様）

したがって、これらの上記の点から、合理的な人は、Docker-the-companyはソフトウェアの自由、ユーザーのプライバシー、またはユーザーの監視への同意を気にしないと結論付けるかもしれません。

私はGitHubや、フリーソフトウェアやオープンソースで作業するためにそれを好む他のサイトにいます。Dockerデスクトップのような非フリープロジェクトは、すべての人に利益をもたらすフリーソフトウェアでの作業から気をそらすだけです。 私は自分の時間や注意をそのようなことに向けるつもりはありません。

個人的な攻撃に頼るのではなく、問題に直接対処する方がよいでしょう。 今このスレッドをミュートして、良い一日を。

これが誰かに役立つかもしれない場合のために、リモートホストにdockerをインストールするスクリプトがあります（Debian 10 =バスターでテスト済み）：
https://github.com/minireference/sample-book/blob/master/fabfile.py#L213 -L252

これは、Fabricと呼ばれるサーバー自動化フレームワーク（特にfab-classic githubとdocs ]に基づいています。Fabricを使用したくない場合でも、コマンドを簡単に読み取って手動で実行し、bashスクリプトに変換できます。

その後、 export DOCKER_HOST=ssh://[email protected]を実行すると、Dockerマシンを使用したときの状態に戻ります。

@ivanistheoneいいえ、そうではありません。 docker-machine 、それはまた、均一な方法で、CLIでマシンを作成するために、様々なクラウドプロバイダですべてのAPIを実装しているためである偉大な（？）でした。 もちろん、 gcloud 、 azなどがありますが、それぞれに異なるオプションとセマンティクスがあります。 docker-machineは、それらすべてに対する1つのCLIです。 ハイブリッドクラウドでの作業が少し簡単になります...