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 < it-services(a)marcoristuccia.com> wrote: 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 deployment manifests: - 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 automatically. - 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 Diego deployments. - 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 IP to garden.insecure_docker_registry_list and diego.stager.insecure_docker_registry_list 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. Best, Eric Malm, CF Runtime Diego PM
|
|