Re: Some in-depth info on how to use CF
Eric Malm <emalm@...>
Thanks for asking, Marco! Some responses inline below.
On Wed, Apr 27, 2016 at 9:19 PM, Marco Ristuccia <
Hi all,If your internal Docker registry is accessible by IP or DNS from within
your CF/Diego deployment, you should be able to stage and run images from
it simply by specifying that IP or host name as the initial part of the
image to push (for example, `cf push -o
myregistry.internal:5000/my-user/my-image:v3`). If the registry is not
accessible on the public internet, you may also need to make a security
group in CF that allows egress to its IPs and to then bind that as a
staging security group.
Also, depending on the TLS security configuration of that registry, you may
need to add some additional configuration to your BOSH or CF/Diego
- If the internal Docker registry has an SSL certificate signed by an
authority in the globally trusted trust chain, such as one issued by
Digicert or Let's Encrypt, staging and running images from it should work
- If you have signed the registry's SSL certificate with your own CA,
you'll have to make sure that CA's certificate is installed on both the
BOSH-deployed VMs and in the cflinuxfs rootfs.
- For the BOSH VMs, add the PEM-encoded certificate to the
director.trusted_certs property in the BOSH deployment manifest (see
http://bosh.io/docs/trusted-certs.html for more details). Once the BOSH is
redeployed with those properties, you'll then need to update the CF and
- For the rootfs, if you're using the relatively new cflinuxfs-rootfs
release, you should add that same certificate to the
cflinuxfs2-rootfs.trusted_certs property in the Diego deployment manifest
that colocates the cflinuxfs2-rootfs-setup job on the Diego cells. If
you're using the scripts in diego-release to generate your manifest,
instead include the contents of that certificate in the property-overrides
stub file at property_overrides.rootfs_cflinuxfs2.trusted_certs.
- If you're operating the registry with a self-signed SSL certificate or
without TLS enabled, you'll need to add the registry's domain name and/or
to be able to stage and run the images.
CF does not currently support pushing images from private repositories:
it's our understanding that even though the v2 Docker registry supports the
OAuth2 protocol, it doesn't yet support an authorization-code grant type,
which we would strongly prefer to use as the only acceptable set of
credentials to access Docker image repositories that require authentication.
The core CF teams aren't actively working on the Diego Docker Cache at the
moment, and with the switch to supporting v2 Docker registries I don't
believe it currently works correctly. You can still run a Docker image as a
CF app without the cache deployment, though: each time it runs as a
container, the image will be pulled from the internal registry. In the
longer term, that "caching" system should be reworked somewhat so that
Cloud Controller manages staged docker-image assets similarly to how it
manages droplets for buildpack-based apps.
2)These services are intended to be used only by the other CF components.
Consul, etcd, and UAA all have their own BOSH releases, though, so if you
would like to deploy a separate cluster for use by applications running on
CF that should be straightforward to do. You can likely even bind apps to
it manually as a user-provided service, or write and deploy a service
broker to provide access to them through the services marketplace.
I'm not certain about plans for Hyper-V support, but Dmitriy, czar of all
things BOSH, might have more context. :)
Thank you in advance for your kind help and support!Please feel free to ask more questions, especially in our Slack channels!
See http://slack.cloudfoundry.org/ to sign up.
Eric Malm, CF Runtime Diego PM