デビッド、ノードはbootstrapが実行される前に存在しません。オーケストラはノードを最初からインストールしてからjujuを開始するようにcobblerを構成します。これは、デプロイされたjujuチャームがベースのクリーンなシステム。jujuを使用して既存のマシンを簡単に制御できるようにすることが議論されましたが、現時点ではそれが機能していません。
juju bootstrap基本的にこれはオーケストラで行います：
- XML-RPC APIを介してcobblerと通信し、「available-mgmt-class」にあるPXEブート用にマークされたシステムを見つけ、データを注入してjujuを最初のブート時にインストールし、それを「acquired-mgmt-class」に移動します。次に、電源インフラストラクチャが定義されている場合は、それを使用してマシンの電源をオンにします。このマシンは、zookeeperとプロビジョニングエージェントを実行する「ブートストラップノード」になります。 「最初のブート」シードデータには、「ubuntu」ユーザーにインストールするユーザーのSSH公開鍵が含まれているため、jujuクライアントはsshトンネルを介してbootstrapノードと通信できます。
- オブジェクトをファイルストレージ（通常はorchestra-provisioning-server上のssl webdavサービス）に格納し、環境がブートストラップされていることと、bootstrapノードへの接続方法）を将来のjujuクライアントに通知します。
使用するssh承認済みキーのパスを上書きできることに注意してください。通常は〜/ .ssh/id_rsa.pubまたは〜/ .ssh /id_dsa.pubを使用します。また、environments.yamlで「authorized-keys-path」を使用して設定することもできます。実際のキーを挿入して、すべてを「authorized-keys」でオーバーライドすることもできます。