As a software engineer, I admit I am not the best at networking. Can’t connect to your app for some reason, one going joke is to “always blame DNS” e.g the Domain Name System. My personal DNS experience is usually editing a few records for my personal blog and connecting a few tools and that is it. Thanks to distributed systems, had to learn all about SRV records and some more DNS concepts. One of the first items that drew me to Shipa was the ability just to wire publicly addressable endpoints for me just by producing an application image. I did not have to learn about the complexities of Kubernetes networking and it just worked. Though like most firms, you’ll need to customize or put constraints on your networking stack. This is where the power of Shipa CNAMEs comes in.
Shipa Automatic DNS
By default, if you were to just deploy something with Shipa, you’ll notice that an Endpoint is created for you.
A lot is going on in the backend e.g the CRDs written for your Ingress Controller of choice and DNS wirings occurring. But the seamless experience is a Shipa created Endpoint.
Shipa -> Applications -> <your_app> -> Application Details
And you will notice something like “https://coolapp.a4e4df0d46eb94143b90d4fe2696731c-432303744.ap-southeast-1.elb.amazonaws.com.shipa.cloud” created for you.
For organizations that have regulated or limited connectivity environments or even, if you want the endpoint to be something more recognizable, you can change the address with Shipa CNAMEs.
Great Example of a Shipa CNAME
So let’s say we want to change the address of an app. An example could be the Shipa Dashboard itself since it’s a Shipa App; if you are deploying Shipa Self-Managed and the out-of-the-box address does not work. This example is geared towards a DevOps Engineer; applies to anything that Shipa deploys so you could even re-wire the “cool-app” mentioned above. You can leverage the Shipa UI or Shipa CLI to create a Shipa CNAME. If you are installing for the first time and can’t access the UI, you’ll need to start with the CLI.
Via the UI
You can create a new CNAME for the Shipa Dashboard itself.
Shipa -> Applications -> Dashboard -> CNAMEs [the little globe]
You can create an address that is accessible by your DNS zone. Here I am just going to make a fake address “shipaisamazing.com”.
Just like that, you have a new entry to route traffic. To test on your local machine, you can modify your etc/hosts file by pointing to the Ingress address.
For the Dashboard, this is your Shipa Target address. You will need to grab the Ingress address. This is your Shipa Target. You can look this up in the UI.
Settings -> General -> Target Address.
E.g mine is “a3899ca1b7b2543e4ad9e4c92e91c465-1100808758.ap-southeast-1.elb.amazonaws.com”
Grab the IP of the Ingress/Target by pinging the address. Or if you have access to those details from your cloud provider, etc can look there.
ping a3899ca1b7b2543e4ad9e4c92e91c465-1100808758.ap-southeast-1.elb.amazonaws.com
Now you can wire the IP into your etc/hosts.
18.140.41.155 shipaisamazing.com
Save the etc/hosts entry and now you can try the new address.
Via the CLI
Especially if you are installing with limited connectivity, the Shipa CLI would be your best route.
Gathering the above information, you can grab the Ingress address with a kubectl command. Then wire the IP address in your etc/hosts to test or a DNS record of your choice.
kubectl get ingress -n name_space_you_installed_shipa_to_or_default dashboard-0-http-ingress -o yaml
First grab the name of the application you want to modify.
shipa app list
The CLI Format is shipa cname add <cname> [<cname> …] [-a/–app appname]
shipa cname add shipaisamazing.com -a dashboard
Now head back to shipaisamazing.com.
To further validate you can see there is a new host entry in the spec.
kubectl get ingress -n name_space_you_installed_shipa_to_or_default dashboard-0-http-ingress -o yaml
Though that is not all, Shipa can help enable SSL.
What About HTTPS?
So if you take a closer look at the above example, we did not do anything about certificates or SSL. Again this HTTPS example would be designed for a DevOps Engineer leveraging Shipa.
Shipa underneath the covers uses Let’s Encrypt and Cert Manager to issue certificates on your behalf. Let’s re-add a CNAME but this time for HTTPS. Let’s Encrypt does have validation requirements so if you enter something completely bogus would not be able to generate automatically. Thanks to my friend and lead SRE at Shipa, Brendon, who decided to be kind enough to give me ravi.digestibledevops.com which has Domain Control Validation
Add ravi.digestibledevops.com as a CNAME to the Dashboard App.
Then click Add.
Important: Here is the DNS Entry for my new subdomain. Points to the Ingress Controller of the Shipa Cluster. This is crucial for Domain Validation.
You can also validate with kubectl has been wired up with TLS.
kubectl get ingress -n name_space_you_installed_shipa_to_or_default dashboard-0-https-ingress -o yaml
If you are waiting for DNS propagation, you might have to add an entry back in your etc/hosts file for the new domain until propagation.
Navigate to the HTTPS domain and relish in certificate glory.
If you are running into trouble with the certificates, can take a look at the certificate requests event in Cert Manager. Here is one for a valid domain and one for a fake or un-validated domain with different ready statuses.
kubectl get certificaterequests.cert-manager.io -A
Lastly, all of this can be automated.
Automate Shipa CNAMEs
We dug into the concepts of Shipa CNAMEs in the blog. From a DevOps perspective, you can easily create Shipa CNAMEs as part of your journey with your IaC of choice. Now at or near deployment time, you have a clean route for customizing your endpoint.
Here is a Terraform Example:
resource "shipa_app_cname" "acmeappcname" {
app = "acme-app"
cname = "app.acme.io"
encrypt = true
}
The power of Shipa CNAMEs allows you to hide the complexity of DNS from your developers or if you are a developer like myself, easily tame the complexity.
Cheers,
-Ravi
