How Armory Simplifies Exposing Services in Ephemeral Kubernetes Environments

As a developer, it’s important to be able to verify UI and API functionality of services before deploying them to production. Often, this requires setting up complex networking rules, or coordinating different teammates using shared environments. Armory Continuous Deployment-as-a-Service simplifies this by enabling developers to easily connect to any service it deploys, without additional network configuration. This is especially useful when deploying to ephemeral Kubernetes environments, such as those created for a specific PR, since network configuration is otherwise often environment specific. In this blog, we’ll walk you through why you may wish to use this feature, and how to use it to provide a preview of a service.

What is an Ephemeral Environment?

Many teams need to create temporary environments allowing individual developers to test individual changes before their code merges to main or deploys to shared environments. Creating a namespace within a development cluster for a particular PR or branch is a common implementation of Ephemeral Environments.

Deploying to an Ephemeral Namespace with Armory

When you deploy with Armory, you specify a list of Kubernetes manifests we will deploy. If you include a namespace manifest, we will create that namespace. Similarly, in your CD-as-a-Service deploy.yml you can override the namespace all other manifests deploy to. This allows you to easily create and deploy into an ephemeral namespace using the name of your branch.

Existing Kubernetes Options to Expose Services

With an ephemeral environment developers historically had a few options to connect to the Kubernetes services that they deploy. Some techniques require the user who connects to the service to have access to the Kubernetes cluster, which is not always realistic. Others require extensive Kubernetes knowledge to configure.

Port-forward with Kubectl

The kubectl command line allows you to run kubectl port-forward service/service-name portnumber to allow you to connect to any service via a port on your local computer. While this is the easiest native way to connect to a Kubernetes service, it includes several downsides:

1. A developer must have direct access to the Kubernetes cluster in order to issue a port forward
2. It is not practical to share the URL of the forwarded port with a teammate who lacks access to the cluster because the connection is through the developer’s personal computer.
3. It is usually not practical to run integration tests requiring a deployed environment using the port forward.
4. if your computer goes to sleep it will interrupt any connections through the port-forward.

In a world of laptops and firewalls, port-forwarding can be useful for taking a quick look at your services, but is not viable for sharing URLs or running long-running tests.

Configure a Load Balancer

Changing the ServiceType to LoadBalancer exposes Kubernetes services to an external network. If that network is itself internet accessible, this can provide a reasonable path to access. However, Accessing the load balancer may require additional networking outside the cluster. Load balancers are also dedicated infrastructure that often costs money.

Configure Ingress

Ingress allows a single Kubernetes load balancer to route traffic from multiple child directories to multiple independent Kubernetes service objects. This allows you to reuse a single load balancer for multiple service objects. Unfortunately, configuring ingress can be complicated and error-prone. Additionally, many popular Ingress providers require the specific LoadBalancer URL as part of the configuration. This results in ingress configuration being less portable–the configuration is unique to each Kubernetes environment.

How Armory Can Forward a Service

Armory can leverage its remote network agent to expose a preview URL for any Kubernetes service it deploys. CD-as-a-Service generates a cryptographically secure URL for applications developers. You can share this url with teammates and stakeholders who need to review the deployed functionality. This enables developer access to deployed services on-demand without a dependency on other teams to set up networking.

This is similar to the way the kubectl port-forward command works, only instead of running it on a local developer laptop, we run it from the armory side. Similarly, instead of exposing the URL on a particular port, we generate a unique child URL for the service. Armory uses a cryptographically secure random number generate to generate this URL’s unique GUID. After a given amount of time, Armory automatically shuts down this URL so it is no longer accessible. While the URL is cryptographically secure, Armory still recommends only using it to expose services in test environments, not production environments. This is because the preview url does not require any additional authentication beyond that of the exposed service.

To see this functionality in action, you can watch this demo video. If you’d like to try it hands on, you can signup to try Armory CD-as-a-Service for free. In the setup wizard, choose to deploy Armory’s sample application. Once the application deploys to the first environment, click into that environment, and you will be able to open the exposed service to view the deployed application.

Configuring Armory CD-as-a-Service to Forward your Service:

If you are using Armory CD-as-a-Service to deploy your application, adding the preview service is easy. Your application’s configuration already has either a canary or blue/green strategy. Simply add the exposeService step, specify which services to expose, and for how long they should be exposed. Preview links will be available when you click into an environment from your deployment UI.

Example Configuration for a blue-green deployment:

    blueGreen:
      redirectTrafficAfter:
        - exposeServices:
            services:
              - potato-facts-internal
              - potato-lies-internal
            ttl:
              duration: 30
              unit: MINUTES

Example Configuration for a canary deployment

    canary:
      steps:
        - exposeServices:
            services:
              - potato-facts-internal
              - potato-lies-internal
            ttl:
              duration: 30
              unit: MINUTES

Conclusion

Using the Expose Service feature in Armory CD-as-a-Service is a great way to preview your services before deploying them to production. By following the steps outlined in this blog, you can easily preview your service using the Expose Service feature.