EKS complete with eksctl / Sprint 4

Ok, in the last sprint we implemented GitOps using FluxCD. Since we are doing GitOps we don’t need scrips anymore and rolling out apps or even a complete cluster is a repeatable task now. However, our app is still not reachable using a fixed DNS name. Time to fix this.

In this article we are going to introduce one extra repo and make changes on the other repo’s. Therefor please checkout sprint 4.

git clone https://github.com/enschede/eks-demo.git
git checkout tag/sprint4
git submodule update

You can clone it and, please, check out tag “sprint4”.

Sprint goal

The main goal for this sprint is to have a stable DNS-name for our app. We want de DNS-name to be available in Route53 (AWS’ DNS register) and coupled to the load balancer we introduced in sprint 2.

To have the DNS-name published we need to:

• Add a DNS-name controller that adds, modifies en removes DNS-entries.
• Make the application reachable using a fixed DNS-name and https.

Making the application reachable using a fixed DNS name requires a DNS name to be available somewhere in a DNS server. To do this, we will use Route53 and maintain the DNS records from our K8S descriptor files. And yes, this requires a new controller; the binami external dns controller.

And, as a bonus, we are going to make our GitHub repo’s private

Adding the DNS controller

First, we are going to create the bitnami external dns controller repo (grey) that will hold the and a reference to it in the eks demo infra repo.

Adding the Bitnami external DNS controller

The content of the Bitnami external DNS controller will look like this.

eks-demo-bitnami-external-dns % tree
.
`-- deployment
    |-- external-dns.yaml
    `-- kustomization.yaml

deployment/external-dns.yaml

The controller is packed in a Helm chart and we are able to load that Helm chart.

The descriptor is not very special. Please note the value section and the end. The service account is not created by the helm chart because it cannot create the necessary role outside the cluster. Therefor we will create the service account from the eksctl configuration file. See later.

deployment/kustomization.yaml

Adding the controller repo to the eks demo infra repo

Now that the dns controller repo is ready, we have to refer to it from the infra repo (blue). To do that, we will create an extra folder in the app-cluster folder in the infra repo. Like this:

eks-demo-infra % tree
.
|-- app-cluster
|   |-- external-dns
|   |   |-- external-dns.yaml
|   |   `-- kustomization.yaml
...

deployment/external-dns.yaml

deployment/kustomization.yaml

Once both files are committed and pushed, the DNS-controller will start. Problem is that is will not work. Therefor we need to add an extra role in the eksctl configuration file.

Adding the service account to EKS

As you can see, a service account is created and it is connected to a predefined role.

Restarting the cluster will do the job. The DNS controller will be part of the configuration.

Add domain name to Ingress descriptor

Now that we have the DNS controller available, we are going to add a DNS name in a descriptor file. But before we are going to do this, we will create a https certificate. To do so, we will go to the AWS certificate manager and add a certificate. The certificate will ask us to show that we are the owner of the domain, I hope you are able to walk through the process yourself, I created a *.liberaalgeluid.nl certificate. Why, that is the domain of an old podcast I used to make with a friend of mine and it is my testdomain now.

Now that there is a certificate for the domain, please copy the ARN of the certificate. We will need this one in the next step.

And in this next step we are going to modify the ingress.yaml part of the spring-boot-app.yaml configuration in the eks-demo-app repo (dark red).

configuration/spring-boot-app.yaml (only the ingress part)

The lines 15 to 18 are added. As you can see, the ingress will have 3 different DNS-name, it will have 4 ports to listen, all http traffic is redirected to an https port and a certificate is configured.

The certificate in line 18 is defined by its ARN. And, as you can see, my AWS account id is replaced by a variable that has to be substituted.

To substitute the variable, we need to update the kustomization in the infra repo.

app-cluster/eks-demo-app/eks-demo-app.yaml (blue)

2 new parts are added:

• lines 28–31 are added to substitute variables. The values comes from a secret. We have to add the secret from outside the cluster. See later.
• lines 32–34 are added to define a dependency. I guess you will understand.

As said, we need the account id to be added as a secret. Therefor we will extend the start.sh script as below.

The secret can now be added during startup. Of course you can execute the create secret command stand alone to prevent a restart.

Now it is time to test the DNS entry. Check below.

Retro

Ok, in the last sprints we created an app to show data. We added a load balancer, GitOps with FluxCD and a fixed DNS-name using Route53.

Still, the content is not very flexible. So in the next sprint we want to introduce a database in the cloud. And to create that database, outside of the cluster, we are going introduce Crossplane.

Bonus: Make git repo’s private

Till now all GitHub repo’s were public. This is not exactly what we want in commercial situations. We want our code to be private.

So, as a bonus, we are going to make our repo private. Or at least, I’m going to tell you how to make your repo’s private. I will leave my eks-demo repo’s public of course.

Luckily this is very simple with FluxCD. First we have to add the GitHub username and token as secrets to the flux-system namespace.

start.sh

As you can see, a github-credential secret is added.

Next the GitRepository descriptors have to have a reference to the secret

By adding a secretRef to the github credentials, FluxCD has the access to the private repo’s. Finally we have to change the settings in the GitHub repo to private 😀.

Happy developing!