Local Kind ingress ¶

If you have deployed the local kind cluster as outlined on the create a local cluster page, follow these instructions to use an ingress for accessing your products.

Prerequisites ¶

A kind cluster deployed with ingress enabled. For this guide, the cluster name ping is assumed
The hostname aliases have been appended to the /etc/hosts file
You have created the secret for your DevOps user and key for retrieving licenses

Assumptions ¶

With the /etc/hosts file entries created from the page linked above, the release in helm must be myping for the hostnames to work with the configuration here. Consider the first entry as an example:

127.0.0.1 myping-pingaccess-admin.pingdemo.example ...

When using our charts, the release name provided to helm is prepended - that is what provides the myping- portion of the hostname in the file. The pingdemo.example domain suffix is provided through the ingress definitions as shown later on this page. So, the structure is:

<helm-release-name>-<ping-product-service>.<domain-name-from-ingress>

If you use a release name other than myping or a domain other than pingdemo.example you will need to update the aliases in /etc/hosts/ accordingly.

Instructions ¶

There is a file under the 30-helm directory of this repository named ingress.yaml. Modify this file for use with a local cluster:

Replace insert domain name here with your domain name (pingdemo.example in this guide)
Edit line 11, removing the -public suffix for the class

The file should look as shown here:

global:
  envs:
    PING_IDENTITY_ACCEPT_EULA: "YES"
  ingress:
    enabled: true
    addReleaseNameToHost: prepend
    defaultDomain: "pingdemo.example"
    defaultTlsSecret:
    annotations:
      nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
      kubernetes.io/ingress.class: "nginx"

Create ingresses ¶

When deploying using helm and one of the example YAML files in the 30-helm directory, also pass in the ingress.yaml file to include the ingress definitions as part of the overall deployment.

For example, to use the everything.yaml and include ingresses, you would run the following command from the 30-helm directory (after updating the ingress.yaml file):

helm upgrade --install myping pingidentity/ping-devops -f everything.yaml -f ingress.yaml

After everything has started, you will see the same pods and services as in the getting started example. In addition, you will see ingress definitions in the same namespace as the products:

# List ingress definitions
kubectl get ingress

# Output
NAME                         CLASS    HOSTS                                       ADDRESS     PORTS     AGE
myping-pingaccess-admin      <none>   myping-pingaccess-admin.pingdemo.example      localhost   80, 443   47m
myping-pingaccess-engine     <none>   myping-pingaccess-engine.pingdemo.example     localhost   80, 443   47m
myping-pingauthorize         <none>   myping-pingauthorize.pingdemo.example         localhost   80, 443   47m
myping-pingdataconsole       <none>   myping-pingdataconsole.pingdemo.example       localhost   80, 443   47m
myping-pingdirectory         <none>   myping-pingdirectory.pingdemo.example         localhost   80, 443   47m
myping-pingfederate-admin    <none>   myping-pingfederate-admin.pingdemo.example    localhost   80, 443   47m
myping-pingfederate-engine   <none>   myping-pingfederate-engine.pingdemo.example   localhost   80, 443   47m

The HOSTS column reflects the entries added to the /etc/hosts file.

To access a given service, enter the HOSTS entry in your browser (you will have to accept the self-signed certificate). For example, to view the Ping Federate console, you would access https://myping-pingfederate-admin.pingdemo.example/. For the Ping Data console, https://myping-pingdataconsole.pingdemo.example and so on.

Here are the credentials and URLs. This table is similar to the getting started example but reflects the release name used on this page:

Product	Connection Details
PingFederate	URL: https://myping-pingfederate-admin.pingdemo.example/pingfederate/app Username: administrator Password: 2FederateM0re
PingDirectory	URL: https://myping-pingdataconsole.pingdemo.example/console Server: ldaps://myping-pingdirectory-cluster:1636 Username: administrator Password: 2FederateM0re
PingAccess	URL: https://myping-pingaccess-admin.pingdemo.example Username: administrator Password: 2FederateM0re
PingAuthorize	URL: https://myping-pingdataconsole.pingdemo.example/console Server: ldaps://myping-pingauthorize-cluster:1636 Username: administrator Password: 2FederateM0re

Cleaning up ¶

Since the ingresses are deployed as part of the overall release, deleting the release will also remove the ingress definitions (leaving the ingress controller intact).

The ingress controller will be removed when the cluster is deleted. If you only want to remove the ingress controller, you can either:

Run kubectl delete -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/1.23/deploy.yaml if you installed the controller from Github

OR

Run kubectl delete -f ./20-kubernetes/kind-nginx.yaml if you used the local copy to install the controller.