Header

<h2>What are Merkle Trees?</h2>Although the name sounds a bit corny in my opinion, Merkles are a form of cryptographic data structure used commonly in the Web3 ( blockchain ) space. A Merkle Tree, also known &nbsp;as a &quot;binary tree&quot; is used in distributed systems for efficient data verification. They are efficient because they use hashes instead of full files.&nbsp;To put it simply, take three 16 digit numbers. Hash each one of them using a hashing algorithm like keccak256. These are now considered leaves on a Merkle Tree. Take those leaves, and link them together and you have a tree filled with leaves. Encoding the tree will result in a single alphanumeric output called a root ( Merkle Root ).<pre>let numbers = [ 1250125, 952195, 2955986 ]
let leaves = numbers.map(numbers =&gt; keccak256(numbers);
let merkleTree = new MerkleTree(leaves, keccak256, {sortPairs: true}
=====================================================================

 Hash1 [ABCD]
 / \
 Hash2 [AB] Hash3 [CD]

======================================================================</pre>Without jumping too far into coding yet. We can see how an array of numbers when converted into leaves by hashing, then encoded by a Merkle Tree create a &quot;tree&quot; structure. Where each item is essentially linked together. The tree is all knowing of all it&#39;s leaves.<h2>Creating a Merkle Tree With Node</h2>Now that we somewhat understand what a Merkle Tree is we can start to build one to better understand its use cases.Let&#39;s start by spinning up a new Node project<pre>touch index.js
npm init -y
npm i merkletreejs
npm i keccak256</pre>That&#39;s all we&#39;ll need! Next we can start creating a list of hex values to add to our tree<pre>const {MerkleTree} = require(&quot;merkletreejs&quot;)
const keccack256 = require(&quot;keccak256&quot;)

// List of addresses
let addresses = [
    &#39;0x33039b066102dEb002313B8ee75514d5e16f161e&#39;,
 &#39;0x80f4760E9309E60c7ef066827846B792AEeEAd57&#39;,
 &#39;0x1B7C182AF1c1504AA2f95392720724a28a214B1C&#39;
]</pre>With our addresses in place we can now turn them into leaves by hashing them.<pre>// Hash our leaves
let leaves = addresses.map(addr = keccak256(addr))</pre>Awesome, we have some leaves to assemble our tree with. Now let&#39;s finish up with our tree.<pre>// Create Tree
let merkleTree = new MerkleTree(leaves, keccak256, {sortPairs: true})
let rootHash = merkleTree.getRoot().toString(&#39;hex&#39;)

// Print it out
console.log(merkleTree.toString())
console.log(&quot;Root Hash:&quot;, rootHash)

// Run with node index.js
&gt; └─ 030ce4dccc57ba8af18fcc1e16523a167963dd25c4b3fd227b293cd7837bac23
   ├─ a41044c97488d3d3b3bca9d1140345bc904d70d40152f2eafb5d40427f798eef
   │  ├─ 0edf1f7db2bdb8874cf8f8b0b7c565839100e4129bbc08e652ab860d6ebe858b
   │  └─ f68fe227337e08d1dfe556724673c999fb398e8c31188ad2e331f4cba4bd1c0a
   └─ 8ccd02bcea47496fadaa9cd78f3795e6dcdd5063e456e611f076dd175967fb1f
      └─ 8ccd02bcea47496fadaa9cd78f3795e6dcdd5063e456e611f076dd175967fb1f

&gt; Root Hash: 030ce4dccc57ba8af18fcc1e16523a167963dd25c4b3fd227b293cd7837bac23</pre>Holy smokes! We just turned out leaves into a full grown tree!!For real though. You can see from the console output that we&#39;ve converted a list of hex addresses into a linked (hashed ) binary tree. Additionally we&#39;ve output our root hash which is extremely&nbsp;important. Our root hash is how we can verify that one of our hex addresses is actually part of the tree! How you ask?<pre>// =====&gt; Getting Proof
let address = address[0]
let hashedAddress = keccak256(address)
let proof = merkleTree.getHexProof(hashedAddress)
console.log(&quot;Merkle Proof&quot;, proof)

// Run with node index.js
&gt; Merkle Proof [
  &#39;0xf68fe227337e08d1dfe556724673c999fb398e8c31188ad2e331f4cba4bd1c0a&#39;,
  &#39;0x8ccd02bcea47496fadaa9cd78f3795e6dcdd5063e456e611f076dd175967fb1f&#39;
]</pre>Well.. we got our proof. Unfortunately it&#39;s not necessarily human readable. That Merkle Proof we have in our console output is merely cryptographic proof. Luckily however, we have utilities available to use to compare the Merkle Proof, the hashed address, and the Root Hash together to tell us if we&#39;re actually part of the tree!<pre>// Verify proof
let verified = merkleTree.verify(proof, hashedAddress, rootHash)
console.log(verified) // returns a Bool

// Run with node index.js
&gt; true</pre>Excellent! We&#39;ve sent our information into the verify function and have confirmed verification of proof that we are indeed cryptographically part of this tree.<h2>How is this used in the real world?</h2>But where does all this leave us ? Well.. you&#39;re ready &nbsp;to use merkles in the real world. Merkle Trees are part of a large cryptographic family of systems of verification. They are used because they are efficient and we essentially only need our Root Hash and our Proof to determine if something is valid on our tree. This could be used as a checksum to determine if a file is part of a larger directory, or if an address is allowed to access parts of a smart contract.&nbsp;To summarize what we&#39;ve went over:<ul><li>We learned What a Merkle Tree is</li><li>We learned How to create a Merkle Tree</li><li>We learned How a Merkle Tree could be used </li></ul>A sincere thank you if you&#39;ve made it this far. I enjoy writing these articles, even if it&#39;s only myself who uses them for reference. Until next time.

Creating a Merkle Tree using node js

<h2>What is docker?</h2>To keep it simple, Docker is an open-platform used for developing, running, and deploying applications in a containerized environment. Well what is a container you might ask. You can think of a container as a micro operating system that can be spun up
or down at whim. The container can host media, applications, utilities, or whatever else a typical operating system can run. Multiple containers can be run simultaneously, and via a network-bridge they can even communicate with each other and the host
operating system as well! In theory docker is much more, but to avoid being esoteric this is the general idea of Docker and containers.<h2>How can I use docker?</h2>Docker can be used in many ways, but to keep it simple we&#39;ll focus on using it for creating application images that can be made portable to host virtually anywhere!The docker CLI tool is the best way of getting started with becoming familiar with docker and it&#39;s abilities. All documentation can be found at docker&#39;s website here: <a href="https://www.docker.com/">https://www.docker.com/</a>.Again this article is less about getting familiar with docker and more about using it for a controlled deployment cycle, so I&#39;ll skip the deep explanation and focus primarily on the use case. I will assume if you&#39;re reading this you have docker
installed and have used it at least a handful of times.<h2>Creating a simple application</h2>We&#39;ll start of by putting together a fairly normal application. In this case we&#39;ll use JS for simplicity and create an API that returns a health check ( status 200 &quot;ok&quot; ).I have my setup in the directory `/dev/health-check-api`. My `index.js` file is fairly plan but does the trick:<pre>var express = require(&quot;express&quot;);
var app = express();

app.get(&quot;/health&quot;, (req, res, next) =&gt; {
 res.json({&quot;message&quot;: &quot;ok&quot;});
});

app.listen(5000, () =&gt; {
 console.log(&quot;Server running on port: 5000&quot;);
});</pre>That&#39;s it! You can run the app to test it out ( you&#39;ll need to install express with npm, yarn, or pnpm first ). In theory it should return `{&quot;message&quot;: &quot;ok&quot;}` with a status code of `200` every time we visit `localhost:5000/health`.<h2>Time to dockerize</h2>Now we can actually build our app inside a docker container. To do so you should have docker cli installed. Aside from the the first step is creating a docker file at the root of your project. `touch Dockerfile`.The Dockerfile should look like this:<pre># We&#39;ll be using node alpine linux for this containers OS
FROM node:alpine as builder

# Change into the /app directory
WORKDIR /app

# Set our node environment
ENV NODE_ENV production

# Copy our package.json + lock and run npm install to build our deps
<code>COPY [&quot;package.json&quot;, &quot;package-lock.json*&quot;, &quot;./&quot;]</code>
RUN npm install --production

# Copy everything that was build into the root directory
COPY . .

# Run the app calling node on our index file
CMD [ &quot;node&quot;, &quot;index.js&quot; ]</pre>With this in place we can hit the last step of actually building an image using docker!<h2>Build our docker image</h2>I know i didn&#39;t clarify to well what an &#39;image&#39; is. But just think of it as a pre-built container that we can save, commit, move, run, etc.. Now that we have everything we need let&#39;s put it all together. Using Docker CLI we can run a simple command to actually run the build.`docker build --tag node-api .` - You should see a progress screen of the container being built and ultimately a success message.You can view all of your images by running `docker images` which will output a list of images including your `node-api` image.&nbsp;To run the image we can tell docker to simply run our image using: `docker run node-api`. You should see some output about the container starting up. Once it&#39;s built we can visit `localhost:5000/health` and see our output! That&#39;s it! You build a docker image and ran it as a container. This image can be sent to a container registry or run directly on a server alongside other docker containers!<h2>Summary</h2>Today we&#39;ve put together quite a bit of development magic. We created a simple Node API, created a Docker image and ran it as an independent container. This is quite the feat! There&#39;s A LOT more that can be done with docker such as: - Connecting multiple containers over a network bridge- Orchestrating docker containers using Kubernetes- Building a CI/CD flow to build the images, tag them and run them automatically Let me know if this article helped you out, or if there are any ways I could improve. Thanks!

Dockerizing a Node API

<h2>Introduction</h2>The technical definition of GraphQL is: an open-source data manipulation and query language for APIs. It&#39;s also a runtime used for fulfilling graph queries with existing data. &nbsp;To simplify, GraphQL is both a query language, as well as a runtime environment that allows you to fulfill queries using the GraphQL syntax, while also creating shared-schemas between different services and applications.In this module I hope to bridge the gap between transitioning from using a traditional REST-API to using GraphQL to provide data for our applications. This article itself acts as both an information resource and a training document for referencing.<h2>Prerequisites</h2><ul><li>Having Go installed - Preferably &nbsp;&gt; 1.16</li><li>A basic knowledge and understanding of Go</li><li>A basic understanding of GraphQL, you can find in-depth tutorials on GraphQL <a href="https://graphql.org/learn/">here</a></li></ul><h2>1. Setting up the project</h2>Typically in the setup sections I would briefly go over creating an initial project directory. However, because we are using the <a href="https://github.com/99designs/gqlgen">gqlgen</a> library to bootstrap our GraphQL server + schema there are a few extra steps I will document here.First we&#39;ll start off by installing the primary gqlgen tool:<pre>$ go install <a href="//github.com/99designs/gqlgen@latest">github.com/99designs/gqlgen@latest</a></pre>Now we can create and initialize our typical Go project<pre>$ mkdir gqlexample
$ cd gqlexample
$ go mod init gqlexample</pre>Our project directory is now set up. We&#39;ll need to create a tools.go file to store our build tools<pre>// +build tools

package tools

import _ &quot;github.com/99designs/gqlgen&quot;</pre>Execute the tidy command to install dependencies<pre>$ go mod tidy</pre>Lastly for this section we will use the installed gqlgen tool to generate all the boilerplate files that are necessary for the GraphQL API<pre>$ gqlgen init</pre>The gqlgen command generates a server.go file that runs the actual GraphQL runtime server, as well as a /graph directory containing a schema.graphqls file which holds the schema definitions for our GraphQL API. In this project we won&#39;t necessarily have to interact with the server file. We will however be using the schema.graphqls file to define the models that we will be interacting with using GraphQL!<h2>2. GraphQL Schema Definition</h2>In the first section we set up our project directory and using the gqlgen tool to generate some boilerplate files. In this section we&#39;ll be interacting with these files to define our schema. If you&#39;re new or only slightly familiar with GraphQL the next few steps may seem confusing, but I&#39;ll try to do my best to be esoteric with explaining.To define our own schema we&#39;re going to open up the schema.graphqls file and drop in our own code. Considering this is module is meant to be an introduction to GraphQL we&#39;ll keep it simple with only creating a User model and functionality for creating/querying the user.Open the schema.graphqls file and replace the code with the code below:<pre>//schema.graphqls

scalar Upload

type User {
 id: ID!
 name: String!
 email: String!
 createdAt: String!
}

type Query {
 users: [User]!
}

input NewUser {
 name: String!
 email: String!
 createdAt: String
}

type Mutation {
 createUser(input: NewUser!): User!
}</pre>OK, what did we do? Gqlgen automatically defines the Upload scalar type, and the properties of a file. It&#39;s defined once at the top of the file.We defined a User type which is the core data model of what our user will look like in our database and what our application will receive when querying for a full user. Also defined is a Query. The query specifies when querying for users the server will expect the User type to be returned. Our input is defined as NewUser meaning when creating a new user these are the fields expected to be present in the request body. Finally we declared a Mutation. If you&#39;re not familiar with Mutations that&#39;s OK, the definition is in the name. It&#39;s meant to store functions that mutate or change the state of our database. In this case we defined a single function in our mutation called createUser, and you guessed it.. it creates a user. The createUser mutation accepts our NewUser input and returns a full User model!<h2>3. Generating Resolvers</h2>In the previous step we modified our graph schema to define a few data models, a query, and a mutation for creating users. That&#39;s fantastic, but we still need a way for the outside world to interact with this functionality. Lucky for us gqlgen has thought about that and includes a tool to generate the resolvers based on our defined schema! Run the following command to generate the resolvers:<pre>$ gqlgen generate</pre>Don&#39;t be afraid, but this command will probably do a few things. You may receive some validation errors, and you probably have a few new folders + files in your project. Don&#39;t worry if this looks complex, once you take a peek into each file the context is fairly idiomatic.To resolve the validation errors simply delete the extraneous mutationResolvers gqlgen moved to the bottom of schema.resolvers.go these were sample functions and are no longer need ( they&#39;re also not modeled in our schema ) so we can easily remove them. While in this file also notice that we have functions related to our schema that have been generated! - CreateUser &lt;- This is used to create a new user utilizing our User model- User &lt;- Used to request/query our User modelI&#39;ll keep this section short because we did exactly what we intended on doing. We generated resolvers for our schema!<h2>4. Database Interactions</h2>For the sake of the length of this already arduously long module I will not go into depth about how to set up a database connection in Go. I will cover this in another shorter module. However, In this section I will describe how to use a database connection in tandem with GraphQL.It&#39;s recommended to create a db.go file under the graph directory. In this file we can specify a function that will automatically create the schema in our database!<pre>package graph

import (
 //... Your database library
)

func createSchema(db *pg.DB) error {
 for _, models := range []interface{}{(*model.User)(nil)}{
 if err := db.Model(models).CreateTable(&amp;orm.CreateTableOptions{
 IfNotExists: true,
 }); err != nil {
 panic(err)
 }
 }
 return nil
}</pre>This function will create the tables in our database for us. Using IfNotExists is helpful in only creating the table if it doesn&#39;t already exist!Below the createSchema&nbsp;function you should create a Connect function to actually connect to your database.Now we&#39;re going to move into the server.go file to initialize our database and start GraphQL!In this file we&#39;re going to replace the existing srv variable with our database handler:<pre>package main

import (
 ...
)

const defaultPort = &quot;8080&quot;

func main() {
 // ...

 Database := graph.Connect()
 srv := handler.NewDefaultServer(
 generated.NewExecutableSchema(
 generated.Config{
 Resolvers: &amp;graph.Resolver{
 DB: Database,
 },
 }),
 )

 // ...
}</pre>Here we&#39;re essentially bootstrapping the database connection using the Connect function and starting call for the Resolver struct. The only issue is our Resolver struct doesn&#39;t contain a database connection. But we can quickly fix that by adding our db connection to the Resolver struct in resolver.go:<pre>package graph

import &quot;your-database-driver&quot;

type Resolver struct {
 DB *a.Db
}</pre>Now your app has a database connection that can be established when the server.go is invoked and your app is started. At this point personally I&#39;m using go-pg which is dual used as an ORM so it&#39;s injected as well.This section might have seemed a bit complicated, if not, awesome! Thankfully we&#39;re just about out of the weeds. In the last and final section we&#39;ll go over finishing the implementation of our resolvers that we left blank before. Then we can start querying!<h2>5. Implementing Resolvers</h2>If you&#39;re familiar with building traditional REST-APIs in Go then you shouldn&#39;t have any problems with the following section. We&#39;re going to be filling out the functionality of the CreateUser&nbsp;and Users functions that were generated for us earlier.Let&#39;s jump back into schema.resolvers.go and write some code!<pre>import (
 //...
 &quot;github.com/google/uuid&quot;
)

func (r *mutationResolver) CreateUser(ctx context.Context, input model.NewUser) (*model.User, error) {
 user := model.User{
 ID: fmt.Sprintf(&quot;%v&quot;, uuid.New()),
 Name: input.Name,
 Email: input.Email,
 CreatedAt: time.Now().Format(&quot;01-02-2003&quot;),
 }

 _, err := r.DB.Model(&amp;user).Insert(); if err != nil {
 return nil, fmt.Errorf(&quot;error inserting user: %v&quot;, err)
 }

 return &amp;user, nil
}</pre>In the mutation above we defined a few items. First, we accept our NewUser model as input and add a UUID ( I&#39;m using the google/uuid package ). I also added a timestamp for our created time. After that I&#39;m using the ORM to insert the new model into the database. Finally we handle any error from the response, if there are none we return the created user!We can now run our app to test creating users. Start the app with:<pre>$ go run ./server.go</pre>If you navigate to the defined port on our local system you can access a build in GraphQL editor ( localhost:8080&nbsp;). You can paste the create mutation below to create a new user:<pre>mutation createUser{
 createUser(
 input: {
 email: &quot;testemail@gmail.com&quot;
 name: &quot;Bilbo Baggins&quot;
 }
 ) {
 id
 }
}</pre>If you execute this mutation you &nbsp;should receive a response that contains a data key returning the id of your newly created user!For the last step in this model we will implement the Users&nbsp;query resolver to be able to query our users from the database.Head back to the schema.resolvers.go file and add the following code under the Users function:<pre><code>func (r *queryResolver) Users(ctx context.Context) ([]*model.User, error) {</code>
 var users []*model.User
 
 err := r.DB.Model(&amp;users).Select()
 if err != nil {
 return nil, err
 }

 return users, nil
}</pre>Theoretically you could expand the Select method to include clauses like LIMIT or WHERE to narrow the results. For this example we&#39;re just returning all users.Head back to the browser and in our GraphQL sandbox enter the following query:<pre>query fetchUsers{
 users {
 name
 id
 email
 }
}</pre>Your output should match the single user we created in the earlier step!<h2>Summary</h2>In this module we used the gqlgen library and created a Go project that defines a graph schema and mutations that we can use to interact with our GraphQL server using graph queries.In future articles I&#39;ll go over more deployment methods like containerizing and deploying in a multitude of different ways.

Build a simple Go GraphQL API

<h2>Introduction</h2>Traditionally a cron is a <a href="https://en.wikipedia.org/wiki/Job_scheduler" rel="noopener noreferrer" target="_blank">job-scheduler</a> that allows the user to run &quot;jobs&quot; at specifically timed intervals. The most common application for creating cron-Jobs is scheduling repetitive tasks .In this post we&#39;ll go over setting up a simple cron using the go-co-op/gocron package and logging a message to our log file. This sets up the ground work for adding actual jobs into the cron later down the line.<h2>Setup &amp; Go</h2>First things first let&#39;s set up our new project.<pre>$ mkdir examplecron &amp;&amp; cd examplecron</pre>Now that we have a project directory, create a main.go file in the root of that directory so we have a place to write our code.As a personal preference, I create my main.go and then follow it with initializing go-mod<pre>$ go mod init</pre>After creating a main.go we need to install a reference to the gocron package to be able to use it in our project.<pre>$ go get github.com/go-co-op/gocron</pre> Now we can start writing some code. Let&#39;s begin by setting up our initial go project by declaring a package and initiating a main function<pre>package main

func main() {
}</pre>Now create a function to simple print to console for now so we can test our progress so far. In this case I&#39;ll call the function printOut and it will take a single string as the parameter.<pre>package main

import &quot;fmt&quot;

func printOut(msg string) {
 fmt.Println(msg)
}

func main() {
 printOut(&quot;Hello, world!&quot;)
}</pre>Run the program!<pre>$ go run main.go
&gt;&gt; Hello, world!</pre>Nice, we haven&#39;t broken anything yet.. At last we can pull in gocron and create a cron job that can run out printOut() function for us on a schedule. I&#39;ll make note of each step below.<pre>package main

import (
 &quot;fmt&quot;
 &quot;time&quot;
 &quot;<a href="//github.com/go-co-op/gocron"></a>github.com/go-co-op/gocron&quot; // 1
)

func printOut(msg string) {
 fmt.Println(msg)
}

func runJobs() {
 s := gocron.NewScheduler(time.UTC) // 2
 
 s.Every(1).Minutes().Do(func() { // 3
 printOut(&quot;Hello, world!&quot;) // 4
 }

 s.StartBlocking() // 5
}

func main() {
 runJobs() // 6
}</pre>Alright! For simplicity I&#39;ve numbered the actions so I can describe them more in-depth below.<ol><li>Here we import the gocron library for use in our code</li><li>We ask gocron to create a new scheduler. The s variable here will hold onto the scheduler so we can use it in the future to create our scheduled jobs. Into the scheduler we pass time.UTC which is a reference to *time.Location to tell the scheduler the time zone associated with our time.</li><li>We declare our cron task here. More specifically we tell our scheduler to do something every 1 minute.</li><li>This is where the execution lives, or the action we want our cron to perform within the interval we requested. In this case we want it to run our printOut function.</li><li>This line starts the scheduler in non-blocking mode which blocks the current execution path.</li><li>Here we&#39;ll execute our runJobs&nbsp;function which will start our cron.</li></ol>And that&#39;s it!If we run our program at this point we should see &quot;Hello, World!&quot; print out every minute in our terminal.<pre>$ go run main.go
&gt;&gt; Hello, World!
&gt;&gt; Hello, World!
&gt;&gt; Hello, World!</pre> We have successfully created and scheduled a cron job using Go and the gocron library! There are a handful other libraries to take into consideration, but this one has worked for me in many cases. Thanks for reading!

Building a CRON Job package in Go with gocron

## Load Balancer To ease the pain of manually writing all of the service mapping configurations for an Ingress-NGINX load balancer, I found that it could be easily deployed with a command that pulls directly from the Kubernetes/Ingress-NGINX repo. This command runs a
deploy.yaml file that is specific to Digital Ocean ( or any other provider ).<pre>$ kubectl apply -f <a href="https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.4.0/deploy/static/provider/do/deploy.yaml">https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.4.0/deploy/static/provider/do/deploy.yaml</a></pre> However, As noted in the <a href="https://kubernetes.github.io/ingress-nginx/deploy/#digital-ocean">documentation</a> for the specific Digital Ocean installation there are missing annotations that will help further auxiliary processes to function properly. Without them we lose some abilities in DO: - Naming conventions for Digital Ocean UI - Opening ports for HTTP throughput graphing - Enabling ports for TLS traffic - Enabling the ability to proxy certain traffic To mitigate this, I downloaded the `deploy.yaml` file directly into the `/Charts` directory under the file name `staging_load.yaml` and added the annotations manually. The specific annotations to be used can be in this <a href="https://github.com/kubernetes/ingress-nginx/issues/8965">GitHub Issue</a>. I omitted the service.beta.kubernetes.io/do-loadbalancer-hostname annotation because it broke internal proxying for endpoints. Everything else worked perfectly. In short, the annotations I added:<pre>$ kubectl apply -f ./Charts/beehive/staging_load.yaml</pre> You should get an output similar to:<pre>namespace/ingress-nginx created
serviceaccount/ingress-nginx created
role.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx created
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission created
rolebinding.rbac.authorization.k8s.io/ingress-nginx created
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx created
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission created
service/ingress-nginx-controller created
service/ingress-nginx-controller-admission created
deployment.apps/ingress-nginx-controller created
job.batch/ingress-nginx-admission-create created
job.batch/ingress-nginx-admission-patch created
ingressclass.networking.k8s.io/nginx created</pre> After the Load Balancer finished installation I ran the following command to get the assigned `External IP`. This was saved and used to point the DNS A Record to the Load Balancer.<pre>$ kubectl --namespace ingress-nginx get services -o wide

NAME                                 TYPE           CLUSTER-IP      EXTERNAL-IP               PORT(S)                      AGE   SELECTOR
ingress-nginx-controller             LoadBalancer   10.245.185.32   &lt;your-ip-here&gt;   80:31259/TCP,443:31757/TCP            12m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kubernetes.io/name=ingress-nginx
ingress-nginx-controller-admission   ClusterIP      10.245.69.146   &lt;none&gt;                    443/TCP                      12m   app.kubernetes.io/component=controller,app.kubernetes.io/instance=ingress-nginx,app.kub</pre>

Configuring a Kubernetes NGINX Load Balancer

## Cert Manager Next up is installing and configuring cert manager to manage all issuing/expiration of certificates via the CA ( Certificate Authority ) of our choosing. I&#39;ve already spent most of a day trying ( and failing ) to get it properly configured, but alas, there is no growth without failure. * <a href="https://cert-manager.io/v0.12-docs/installation/kubernetes/" rel="noopener noreferrer" target="_blank">Cert Manager Docs</a> * <a href="https://artifacthub.io/packages/helm/cert-manager/cert-manager" rel="noopener noreferrer" target="_blank">Helm Repo</a> At the time of writing this the latest version of Jetstack/Cert-Manager is `1.10.0` so we will use that for our installation. The instructions in the Helm Repo state that CustomResourceDefinitions (CRDs for short) are highly recommended prior to installing the cert-manager. This separate step allows that ability to easily uninstall/reinstall cert-manager without deleting any existing custom resources. Installing CustomResourceDefinitions (CRD)<pre>$ kubectl apply -f <a href="https://github.com/cert-manager/cert-manager/releases/download/v1.10.0/cert-manager.crds.yaml">https://github.com/cert-manager/cert-manager/releases/download/v1.10.0/cert-manager.crds.yaml</a>
&gt;&gt;
customresourcedefinition.apiextensions.k8s.io/clusterissuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/challenges.acme.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/certificaterequests.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/issuers.cert-manager.io created
customresourcedefinition.apiextensions.k8s.io/orders.acme.cert-manager.io created</pre> After CRDs have been applied we can add Jetstack/Cert-Manager to our helm repo list<pre>$ helm repo add jetstack https://charts.jetstack.io</pre> Install the cert-manager under it&#39;s own release and namespace using Helm<pre>$ helm install app-cert --namespace cert-manager --create-namespace --version v1.10.0 jetstack/cert-manager
&gt;&gt;
NAME: app-cert
LAST DEPLOYED: Mon Oct 17 12:04:33 2022
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
cert-manager v1.10.0 has been deployed successfully!</pre> Now that the certificate manager is installed in it&#39;s own namespace, and on it&#39;s own release we can easily manage it. The next step is to provision an `Issuer` resource so we can begin issuing certificates to our services! The primary reason I&#39;m using an `Issuer` resource as opposed to a ClusterIssuer is that this fairly simple architecture only uses one namespace (`default`) for the applications that need to be secured. If I had multiple applications in different namespaces I would would ClusterIssuer which is namespace-agnostic. The issuer will look like this: <pre>apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-app-prod
  namespace: default
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: myEmail
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: someSecretString
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: nginx</pre> I&#39;m using the production letsencrypt endpoint here because this domain will continue to be used and locked to this application for the foreseeable future. Once everything is properly configured in our `staging_issuer.yaml` file we can apply it using kubectl<pre>$ kubectl apply -f staging_issuer.yaml
issuer.cert-manager.io/letsencrypt-beehive-prod created</pre> We should now have an active Issuer resource! However, we&#39;re not done just yet. We&#39;ll need to re-configure each services Ingress to specify some annotations and enable TLS. To keep this short I&#39;ll provide the resource re-configuration here:<pre>ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
    # Here we added the annotations to enable TLS-Acme, and specified the cert managing Issuer we&#39;ll hook onto
    kubernetes.io/tls-acme: &quot;true&quot;
    cert-manager.io/issuer: letsencrypt-app-prod
  hosts:
    - host: app.mysite.com
      paths:
        - path: /{servicePath}
          pathType: Prefix
          backend:
            service:
              name: #{serviceName}
              port:
               number: 80
  # Here&#39;s the TLS stanza that we&#39;ve added. Note the host name to be secured, as well as a TLS-Secret
  # that is relative to the individual service we&#39;re updating.
  tls:
  - hosts:
    - app.mysite.com
    secretName: #{serviceName}-tls</pre> After that&#39;s all set we can apply the configuration changes using Helm<pre>$ helm upgrade beehive ./Charts/beehive</pre> This is where the issues start.. ### Issues 1. On initial observation the SSL Cert was applied, however it was being denied by browser due to error &quot;Kubernetes Issued Fake Certificate&quot; To locate the source of the issue I made a deep-dive into troubleshooting via `Kubectl`. Using `kubectl describe` I can find logs on individual reason why the certificates were not being correctly provisioned.<pre>$ kubectl describe certificates
&gt;&gt;
NAME             READY   SECRET           AGE
characters-tls   False   characters-tls   3m6s
media-tls        False   media-tls        3m6s
players-tls      False   players-tls      3m5s
quests-tls       False   quests-tls       3m5s
store-tls        False   store-tls        3m5s</pre> Well shit.. Let&#39;s take a look at a single certificate.<pre>$ kubectl describe certificate characters-tls
&gt;&gt;
............
Status:
  Conditions:
    Last Transition Time:        2022-10-17T16:58:41Z
    Message:                     Issuing certificate as Secret does not exist
    Observed Generation:         1
    Reason:                      DoesNotExist
    Status:                      False
    Type:                        Ready
    Last Transition Time:        2022-10-17T16:58:41Z
    Message:                     Issuing certificate as Secret does not exist
    Observed Generation:         1
    Reason:                      DoesNotExist
    Status:                      True
    Type:                        Issuing
  Next Private Key Secret Name:  characters-tls-6x2nk
Events:
  Type    Reason     Age    From                                       Message
  ----    ------     ----   ----                                       -------
  Normal  Issuing    3m29s  cert-manager-certificates-trigger          Issuing certificate as Secret does not exist
  Normal  Generated  3m28s  cert-manager-certificates-key-manager      Stored new private key in temporary Secret resource &quot;characters-tls-6x2nk&quot;
  Normal  Requested  3m28s  cert-manager-certificates-request-manager  Created new CertificateRequest resource &quot;characters-tls-z72fs&quot;</pre>OK so the certificate doesn&#39;t exist and is having issues provisioning. Going down the troubleshooting list for ACME/LetsEncrypt found [here](https://cert-manager.io/docs/troubleshooting/acme/) it says we should check to make sure that the `http01` challenge is working correctly. Let&#39;s check it out<pre>$ kubectl get challenges
&gt;&gt;
NAME                                         STATE     DOMAIN               AGE
characters-tls-z72fs-3765316351-1478577462   pending   app.mysite.com   6m32s
media-tls-2df7m-3765316351-1478577462                  app.mysite.com   6m32s
players-tls-hcn4f-3765316351-1478577462                app.mysite.com   6m32s
quests-tls-t6xvj-3765316351-1478577462                 app.mysite.com   6m32s
store-tls-gwmx6-3765316351-1478577462                  app.mysite.com   6m31s</pre> Hmm that&#39;s strange, why is the challenge not completing. Let&#39;s find out.<pre>
$ kubectl describe challenge characters-tls-z72fs-3765316351-1478577462
&gt;&gt;
....
Status:
  Presented:   true
  Processing:  true
  Reason:      Waiting for HTTP-01 challenge propagation: failed to perform self check GET request &#39;http://app.mysite/acme-challenge/Gy5Fk4oxKTXYM3gIXdl2P1IwBSeoc66c5I4CE42ScwQ&quot;: EOF
  State:       pending
Events:
  Type    Reason     Age    From                     Message
  ----    ------     ----   ----                     -------
  Normal  Started    7m14s  cert-manager-challenges  Challenge scheduled for processing
  Normal  Presented  7m14s  cert-manager-challenges  Presented challenge using HTTP-01 challenge mechanism</pre> Interesting. The challenge is failing from a simple HTTP-01 request. My thought&#39;s are is if we can fix the Challenge we fix the certificate provisioning. ### Solution *Luckily* after only a few minutes of ninja-level google searching I came across this <a href="https://stackoverflow.com/a/65879795" rel="noopener noreferrer" target="_blank">answer</a> in StackOverflow. Let&#39;s break down what this solution would do to our infrastructure. When making a Challenge, the LoadBalancer want&#39;s to test the internal services using the `http01` method. That&#39;s great.. except the internal services are configured to only be recognized by their internal IP addresses. If we change the annotation on our LoadBalancer to specify an internal host name to use, this could potentially solve our issue. Let&#39;s add the annotation to our LoadBalancer config staging_load.yaml.<pre>apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: &quot;true&quot;
    service.beta.kubernetes.io/do-loadbalancer-hostname: &quot;app.mysite.com&quot; # We&#39;re adding our Hostname as an annotation here
    service.beta.kubernetes.io/do-loadbalancer-name: &quot;ingress-nginx-load-balancer&quot;
    service.beta.kubernetes.io/do-loadbalancer-protocol: &quot;http&quot;
    service.beta.kubernetes.io/do-loadbalancer-tls-ports: &quot;443&quot;
    service.beta.kubernetes.io/do-loadbalancer-tls-passthrough: &quot;true&quot;
    service.beta.kubernetes.io/do-loadbalancer-http-ports: &quot;80&quot;
    service.beta.kubernetes.io/do-loadbalancer-algorithm: &quot;least_connections&quot;
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.4.0
  name: ingress-nginx-controller
  namespace: ingress-nginx</pre> Re-applying the configuration..<pre>
$ kubectl apply -f staging_load.yaml
&gt;&gt;
serviceaccount/ingress-nginx unchanged
serviceaccount/ingress-nginx-admission unchanged
role.rbac.authorization.k8s.io/ingress-nginx unchanged
role.rbac.authorization.k8s.io/ingress-nginx-admission unchanged
clusterrole.rbac.authorization.k8s.io/ingress-nginx unchanged
clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission unchanged
rolebinding.rbac.authorization.k8s.io/ingress-nginx unchanged
rolebinding.rbac.authorization.k8s.io/ingress-nginx-admission unchanged
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx unchanged
clusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission unchanged
configmap/ingress-nginx-controller unchanged
service/ingress-nginx-controller configured
service/ingress-nginx-controller-admission unchanged
deployment.apps/ingress-nginx-controller configured
job.batch/ingress-nginx-admission-create unchanged
job.batch/ingress-nginx-admission-patch unchanged
ingressclass.networking.k8s.io/nginx unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission configured</pre> After checking the output via Browser, and PostMan I can confirm.. we have successfully provisioned our SSL!

Dillon Lomnitzer | Blog

About Dillon Lomnitzer

Posts by Dillon Lomnitzer

Creating a Merkle Tree using node js

Dockerizing a Node API

Build a simple Go GraphQL API

Building a CRON Job package in Go with gocron

Configuring a Kubernetes NGINX Load Balancer

Configuring a Kubernetes Cert Manager