Overview¶
CF Dev is a tool that stands up a Cloud Foundry, that you can push applications to, on your local workstation. It achieves this by standing up a VM on your machine that satisfies the BOSH interface and performing BOSH deploys on the VM. Once the VM is up and running, the Cloud Foundry instance is made available locally at https://api.dev.cfdev.sh. It was originally built as a way to evaluate Cloud Foundry, but customer developers adopted it as a quick, and free, way to iterate on a Cloud Foundry platform.
CF Dev is distributed as a small CF CLI Community Plugin.
Install
You can install the CF Dev plugin with the following command: cf install-plugin cfdev
At runtime, the plugin downloads the necessary dependencies to set up the VM which can be inspected with the cf dev catalog
command:
$ cf dev catalog
{
"Items": [
{
"URL": "https://d3p1cc0zb2wjno.cloudfront.net/cfdevd/cfdevd-darwin-amd64-0.0.18-rc.36",
"Name": "cfdevd",
"MD5": "7d530c7315b844f88dc1f2ff1ceab017",
"Size": 6154096,
"InUse": true
},
{
"URL": "https://d3p1cc0zb2wjno.cloudfront.net/analyticsd/analyticsd-darwin-amd64-0.0.18-rc.36",
"Name": "analyticsd",
"MD5": "4afc33905b6d611c14d02450f7557900",
"Size": 8635508,
"InUse": true
},
{
"URL": "https://d3p1cc0zb2wjno.cloudfront.net/cfdev-state/cfdev-deps-darwin-0.0.208.tgz",
"Name": "cfdev-deps.tgz",
"MD5": "84f1d8326cf90c6770cb91a594b991c1",
"Size": 9519411130,
"InUse": true
}
]
}
The dependencies differ among the OS platforms but, in general, they consist of an analyticsd (analytics daemon) and a dependencies tarball. The analyticsd is responsible for collecting and reporting opt-in telemetry data, while the dependencies tarball contains all the necessary bits for standing up the CF Dev VM.
AnalyticsD¶
The analytics daemon is a small golang binary that runs as a service on a user's machine alongside CF Dev. When the user opts in, the analyticsd process continually queries the CF Dev Cloud Controller API for a set of whitelisted events. When an event is detected, it is sent to our analytics vendor. See here for a list of monitored events.
Dependency Tarball¶
# contents of cfdev-deps-darwin-<version>.tgz
.
├── bin
│ ├── UEFI.fd
│ ├── bosh
│ ├── cfdev-efi-v2.iso
│ ├── hyperkit
│ ├── linuxkit
│ ├── qcow-tool
│ └── vpnkit
├── services
│ ├── cf.yml
│ ├── deploy-cf
│ ├── deploy-cf.ps1
│ ├── mysql.yml
│ ├── deploy-mysql
│ ├── deploy-mysql.ps1
└── state
├── bosh
│ ├── ca.crt
│ ├── cloud-config.yml
│ ├── director.yml
│ ├── env.yml
│ ├── jumpbox.key
│ ├── state-temp.json
│ └── state.json
├── id_rsa
├── linuxkit
│ └── disk.qcow2
├── metadata.yml
└── vpnkit
The contents of the dependency tarball are listed above. CF Dev works by downloading the dependencies tarball, untarring it in the $CFDEV_HOME
directory and performing its operations. These operations include:
-
Standing up a VM running on native hypervisors, with the artifacts of the ./bin directory.
-
Communicating with the VM via SSH to stand up a BOSH Director inside, with the artifacts of the ./state/bosh directory.
-
Communicating with the BOSH Director to perform BOSH deploys inside, with the artifacts of the ./services directory.
The primary asset is the VM disk (disk.qcow2
here), which is pre-loaded with the BOSH stemcells and releases that will used throughout the CF Dev lifecycle.
Run
You start CF Dev in OSS mode with the following command: cf dev start
What CF components are currently supported?
$ cf dev version
CLI: 0.0.18
BUILD: 36 (f58f3cc)
cf: v13.2.0
cf-mysql: 36.19.0
PCF¶
A major value proposition of CF Dev for customers is the ability to not only stand up a Cloud Foundry for local development, but also stand up major Cloud Foundry services as well. The OSS flavor will only stand up the deprecated OSS version of cf-mysql, but the PCF flavor can stand up rabbitmq
, redis
, spring-cloud-services
, and more. Users opt into the PCF flavor of CF Dev by manually downloading a seperate dependency tarball from Pivotal Network. They can then invoke the plugin like above but with the -f
flag.
The PCF dependency tarball is similar to the OSS dependency tarball. It only differs in that there are more scripts in the services
directory, for BOSH deploying additional services, and that the VM disk is much larger. The VM disk being much larger due to a larger amount of BOSH releases pre-loaded within. Otherwise, the CF Dev lifecycle is the same in both cases.
# contents of pcfdev-v<version>-darwin.tgz
.
├── bin
...
├── services
│ ├── cf.yml
│ ├── deploy-apps-manager
│ ├── deploy-apps-manager.ps1
│ ├── deploy-cf
│ ├── deploy-cf.ps1
│ ├── deploy-mysql
│ ├── deploy-mysql.ps1
│ ├── deploy-rabbitmq
│ ├── deploy-rabbitmq.ps1
│ ├── deploy-redis
│ ├── deploy-redis.ps1
│ ├── deploy-scs
│ ├── deploy-scs.ps1
│ ├── mysql.yml
│ ├── rabbitmq.yml
│ ├── redis.yml
│ └── spring-cloud-services.yml
└── state
├──
...
Run
You start CF Dev in PCF mode with the following command: cf dev start -f ./path/to/pcfdev-<version>-<platform>.tgz
What PCF components are currently supported?
$ cf dev version
CLI: 0.0.18
BUILD: 36 (f58f3cc)
pas: 2.5.7
p.mysql: 2.5.4-build.51
p.redis: 2.0.1
p.rabbitmq: 1.15.8
p.spring-cloud-services: 2.0.10
Additional Features¶
Additional features of CF Dev can be found here.
-
Insecure Docker Registries: Invoke
cf dev start
with the-r
flag to specify a comma separated list of insecure docker registries that will be available for use during thecf push
process. -
Proxy Support: Export
HTTP_PROXY
,HTTPS_PROXY
,NO_PROXY
environment variables during your terminal session to have them respected during the start process and within your CF Dev virtual machine. Not yet supported on the Linux platform. -
Host Access: Access the host machine from within application containers using the
host.cfdev.sh
domain name. -
TCP Routing: You can learn more about TCP Routing from within the Cloud Foundry platform here.