Hi all,

one of my customers wishes to go the PaaS way.
We are evaluating a selected list of potential platforms, Cloud Foundry is one of them, and I like a lot.
I have successfully deployed a Bosh-Lite release with Diego support, we want to only deploy Docker images into CF.

Everything works well. I have read all the published official documentation of CF. But there are the following "critical" things that I didn't find at all:

1)
How to pull Docker images from our internal Docker repository. I have installed Diego Docker Cache but there is no documentation on how to first pull the image from our repository (where to put the URL of the repo? where to configure the connection account user and password, etc...)

2)
Are the internal CF services (Consul, Etcd, UAA) intended only for CF internal use, or can they be used by the deployed applications too? If yes, where is the documentation on how to connect and use them? (URLs, access accounts, etc.)?

3)
Is there by any chance a way for BOSH to deploy CF on a Microsoft Hyper-V on-premise infrastructure? (not Azure, neither the upcoming on-premise Azure-stack, just MS System Center).

Thank you in advance for your kind help and support!

Best regards,
Marco

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,

one of my customers wishes to go the PaaS way.
We are evaluating a selected list of potential platforms, Cloud Foundry is
one of them, and I like a lot.
I have successfully deployed a Bosh-Lite release with Diego support, we
want to only deploy Docker images into CF.

Everything works well. I have read all the published official
documentation of CF. But there are the following "critical" things that I
didn't find at all:

1)
How to pull Docker images from our internal Docker repository. I have
installed Diego Docker Cache but there is no documentation on how to first
pull the image from our repository (where to put the URL of the repo? where
to configure the connection account user and password, etc...)

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)
Are the internal CF services (Consul, Etcd, UAA) intended only for CF
internal use, or can they be used by the deployed applications too? If yes,
where is the documentation on how to connect and use them? (URLs, access
accounts, etc.)?

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.

3)
Is there by any chance a way for BOSH to deploy CF on a Microsoft Hyper-V
on-premise infrastructure? (not Azure, neither the upcoming on-premise
Azure-stack, just MS System Center).

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 regards,
Marco

Best,
Eric Malm, CF Runtime Diego PM

Hi Eric,

thank you for the kind and comprehensive answer!

Regarding point 1, I still have some difficulties.
Our internal Docker repository is configured in HTTPS, self signed certificate, no username, no password, so it must be called by using his name, not the IP address.
On the other side, it seems that the CF stager is able to only resolve DNS names through the public Google DNS (8.8.8.8), so when we use the domain name of our internal Docker repository, Cloud Foundry is not able to resolve it.
Is there a way to configure CF/Diego so that DNS names can be resolved by means of our company internal DNS server?

Best,
Marco

Hi Eric,

thank you for your kind and comprehensive answer!

Regarding point 1) I still have problems.
Our internal Docker registry is configured with HTTP, a self signed certificate, no user and no password. Due to the NGINX server configuration, it must be called through its name, not with its IP address.
On the other side, it seems that the CF stager is able to resolve DNS names only by means of the Google public DNS server (8.8.8.8), so it cannot resolve the name of our internal Docker registry server.
Is there a way to configure Cloud Foundry in a way that it uses our internal DNS server instead of the Google one?

Thanks in advance.

Best,
Marco

Hi Eric,

forget my preceding messages. I had to add and bind the security groups. Now it seems to work.

What if I have a username/password protected registry? (https, self signed certs)
Where do I have to put the account information when I make a "cf push -o"?

Thank you again.

Regards,
Marco