Command bootstrap
Usage: juju bootstrap [options] [<cloud name>[/region] [<controller name>]]
Summary:
Initializes a cloud environment.
Options:
-B, --no-browser-login (= false)
Do not use web browser for authentication
--agent-version (= "")
Version of agent binaries to use for Juju agents
--auto-upgrade (= false)
After bootstrap, upgrade to the latest patch release
--bootstrap-constraints (= "")
Specify bootstrap machine constraints
--bootstrap-series (= "")
Specify the series of the bootstrap machine
--build-agent (= false)
Build local version of agent binary before bootstrapping
--clouds (= false)
Print the available clouds which can be used to bootstrap a Juju environment
--config (= )
Specify a controller configuration file, or one or more configuration
options
(--config config.yaml [--config key=value ...])
--constraints (= "")
Set model constraints
--credential (= "")
Credentials to use when bootstrapping
-d, --default-model (= "default")
Name of the default hosted model for the controller
--keep-broken (= false)
Do not destroy the model if bootstrap fails
--metadata-source (= "")
Local path to use as agent and/or image metadata source
--model-default (= )
Specify a configuration file, or one or more configuration
options to be set for all models, unless otherwise specified
(--model-default config.yaml [--model-default key=value ...])
--no-gui (= false)
Do not install the Juju GUI in the controller when bootstrapping
--no-switch (= false)
Do not switch to the newly created controller
--regions (= "")
Print the available regions for the specified cloud
--to (= "")
Placement directive indicating an instance to bootstrap
Details:
Used without arguments, bootstrap will step you through the process of initializing a Juju cloud environment. Initialization consists of creating a ‘controller’ model and provisioning a machine to act as controller.
We recommend you call your controller ‘username-region’ e.g. ‘fred-us-east-1’ See --clouds
for a list of clouds and credentials.
See --regions
for a list of available regions for a given cloud. Credentials are set beforehand and are distinct from any other configuration (see juju add-credential
).
The ‘controller’ model typically does not run workloads. It should remain pristine to run and manage Juju’s own infrastructure for the corresponding cloud. Additional (hosted) models should be created with juju create- model
for workload purposes.
Note that a ‘default’ model is also created and becomes the current model of the environment once the command completes. It can be discarded if other models are created.
If --bootstrap-constraints
is used, its values will also apply to any future controllers provisioned for high availability (HA).
If --constraints
is used, its values will be set as the default constraints for all future workload machines in the model, exactly as if the constraints were set with juju set-model-constraints.
It is possible to override constraints and the automatic machine selection algorithm by assigning a “placement directive” via the --to
option. This dictates what machine to use for the controller. This would typically be used with the MAAS provider (--to .maas
).
Available keys for use with --config
can be found here:
https://jujucharms.com/stable/controllers-config
https://jujucharms.com/stable/models-config
You can change the default timeout and retry delays used during the bootstrap by changing the following settings in your configuration (all values represent number of seconds):
# How long to wait for a connection to the controller
bootstrap-timeout: 600 # default: 10 minutes
# How long to wait between connection attempts to a controller address.
bootstrap-retry-delay: 5 # default: 5 seconds
# How often to refresh controller addresses from the API server.
bootstrap-addresses-delay: 10 # default: 10 seconds
Private clouds may need to specify their own custom image metadata and tools/agent. Use --metadata-source
whose value is a local directory. By default, the Juju version of the agent binary that is downloaded and installed on all models for the new controller will be the same as that of the Juju client used to perform the bootstrap.
However, a user can specify a different agent version via --agent-version
option to bootstrap command. Juju will use this version for models’ agents as long as the client’s version is from the same Juju release series.
In other words, a 2.2.1 client can bootstrap any 2.2.x agents but cannot bootstrap any 2.0.x or 2.1.x agents.
The agent version can be specified a simple numeric version, e.g. 2.2.4. For example, at the time when 2.3.0, 2.3.1 and 2.3.2 are released and your agent stream is ‘released’ (default), then a 2.3.1 client can bootstrap: * 2.3.0 controller by running ... bootstrap --agent-version=2.3.0 ...
; * 2.3.1 controller by running ... bootstrap ...
; * 2.3.2 controller by running bootstrap --auto-upgrade
.
However, if this client has a copy of codebase, then a local copy of Juju will be built and bootstrapped - 2.3.1.1.
Examples:
juju bootstrap
juju bootstrap --clouds
juju bootstrap --regions aws
juju bootstrap aws
juju bootstrap aws/us-east-1
juju bootstrap google joe-us-east1
juju bootstrap --config=~/config-rs.yaml rackspace joe-syd
juju bootstrap --agent-version=2.2.4 aws joe-us-east-1
juju bootstrap --config bootstrap-timeout=1200 azure joe-eastus
See also:
add-credentials, add-model, controller-config, model-config, set-constraints, show-cloud
Last updated 2 years ago.