Hydra App "Service" ingress construct

[TallenOwen-zz]

We need a logical Hydra App service ingress construct that supports ingress into components but can persist outside the component life-cycle. The following requirements must be met:

1. The service ingress must be able to obtain an IP from an existing vNet subnet private address space and reserve the IP as static. The IP would serve as the VIP for one or many Hydra App components and outlive the component life-cycle.
2. The service ingress must support certificates for customer provided DNS names such as myapp.domain.net.
3. Through the Service Ingress, the Hydra App Components must recognize customer DNS and support component to component communication using customer provided DNS namespaces across Hydra Apps in different customer subnets.
4. The service ingress must not require a dedicated subnet to obtain a static IP reservation.
5. The service ingress must provide the capability to prevent public internet ingress.

One possible option to implement the Hydra App service ingress would be to create a new "Service Network Scope" that represents a service ingress boundary across Hydra App components with the characteristics outlined above. This allows the service ingress to be declared within operational configuration and subsequently defined in the component scope attributes.

[hongchaodeng]

Using scope is definitely the way to go!

My 2c: I would model this as the ingress server as a workload/component, and a scope captures those who want to be served by the ingress server.

[TallenOwen-zz]

@hongchaodeng Yes, that was the original proposal made to @suhuruli. It might make sense to use a separate component to manage the persistent state of the service ingress. That would also allow extended traits to be added to the service ingress component that are specific to the characteristics or properties of "service" ingress, similar to what native Kubernetes provides.