repository·main·Indexed 41 days ago
https://github.com/cloudfoundry/bosh-cliCommand-line interface for interacting with Bosh Directors to manage deployments, releases, stemcells, and UAA services. Includes tools for environment management, task control, resource cleanup, and programmatic access to the Director API via Go packages.
The bosh delete command is used to tear down existing BOSH deployments.
Inputs required for deletion:
Actions performed by deletion:
The bosh deploy command is used to install a Cloud Platform Interface (CPI) locally and then deploy BOSH and its associated jobs onto remote cloud infrastructure.
Inputs required for deployment:
Outputs produced by deployment:
The bosh-init deploy command follows a specific sequence of steps to manage the lifecycle of a Virtual Machine (VM) and its associated components. The CLI automates the transition from a deployment manifest to a running VM by interacting with a Cloud Provider Interface (CPI) and an agent running on the VM via an SSH tunnel and Mbus.
networks, resource_pools, disk_pools, and jobs) and a CPI configuration (derived from the cloud_provider section).cloud_provider.template.job) uses properties from cloud_provider -> properties to render templates.create_stemcell method.create_vm method and persists the VM CID in a deployment state file.persistent_disk_pool or persistent_disk in the manifest, the CLI calls create_disk and attach_disk via the CPI, then issues a mount_disk request to the agent.stop message is sent to prepare the agent.<mbus URL>/blobs), and sends an apply message containing package lists and template specs.start message is sent to begin running the jobs.The bosh-cli repository provides the director and uaa Go packages, which are intended for developers who need to interact with the Bosh Director API programmatically within their own Go projects.
To implement programmatic access, you can use these packages to perform operations typically handled by the CLI. For a practical implementation guide, refer to the docs/example.go file in this repository.
// See docs/example.go for a live short usage exampleTo develop on bosh-cli, you need gcc (or an equivalent) and a package manager (like brew or apt-get). You must also install go, git, and hg (Mercurial), as Go requires these for dependency management.
On macOS using Homebrew:
brew update
brew install go
brew install git
brew install hgUse go get to download the source code into your $GOPATH:
go get -d github.com/cloudfoundry/bosh-cli
cd $GOPATH/src/github.com/cloudfoundry/bosh-clibrew update
brew install go
brew install git
brew install hg
go get -d github.com/cloudfoundry/bosh-cli
cd $GOPATH/src/github.com/cloudfoundry/bosh-cliOnce you have cloned the repository and are working within the $GOPATH/src/github.com/cloudfoundry/bosh-cli directory, you can build the CLI using the provided build script. The resulting bosh binary will be placed in the out/ directory.
bin/buildTo request a disk during deployment, you can use one of two methods in your deployment manifest:
cloud_properties for the disk. Add the persistent_disk_pool property to a job, referencing a pool defined in the top-level disk_pools section.persistent_disk property to a job to specify the size of the persistent disk.When a disk is requested, the CLI performs the following:
create_disk method.attach_disk method.mount_disk request to the agent on the VM.# Example manifest structure for disks
disk_pools:
- name: my_disk_pool
cloud_properties:
# ... specific cloud properties
jobs:
- name: my_job
persistent_disk_pool: my_disk_pool
# OR
# persistent_disk: 20Gintegration package contains integration tests. You can execute the entire test suite using the provided bin/test script.bin/testAcceptance tests are designed to exercise core CLI commands such as deployment, deploy, and delete. They are not intended for verifying CPI compatibility or BOSH releases.
To run these tests using fly, you should base your one-off build on the pipeline's test-acceptance job to ensure the correct image, CPI release, and stemcell are used. You only need to override the source under test.
Note: The -p flag is required because the task initializes its own Docker daemon by sourcing start-docker.
fly -t bosh execute -p \
-c ci/tasks/test-acceptance.yml \
--inputs-from bosh-cli/test-acceptance \
--image docker-cpi-image \
-i bosh-cli=<path-to-source-dir>The Bosh CLI implements autocompletion by dynamically discovering commands, flags, and arguments from the internal BoshOpts structure using reflection.
When the CLI is invoked with the completion or __complete commands, it builds a command tree where:
command and description.long, short, default, and description. If a field is tagged with env, the environment variable name is included in the flag's usage description.CompleteFunctionsMap. This allows the CLI to suggest valid values (like environment names or deployment names) based on the current context.environment, config (path), and deployment to resolve flag values used in completion logic.The bosh-cli uses a local cache to store autocompletion results to improve performance. The cache is managed by the CompleteCache component and follows these principles:
completion-cache located in the same parent directory as your Bosh configuration file.The Bosh CLI uses a session-based approach to handle UAA authentication. When the Director's authentication type is set to uaa, the session determines how to obtain tokens based on the credential type:
creds.IsUAAClient()), the session uses boshuaa.NewClientTokenSession to manage token acquisition.creds.IsUAA()), the session uses boshuaa.NewAccessTokenSession with a refreshable access token (using AccessToken and RefreshToken) to manage the session.This ensures that the boshdir.Director always has a valid TokenFunc to call when making requests to the Director API.