0:05 Introduction and Series Context

0:05 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan. Although you may know me, across the Internet is Rawkode. Today is the third episode of our Portainer in production series. Before we begin, I'd like to say thank you to the team at Portainer who sponsored my time to put this course together. It's been a whole lot of fun. I'm really enjoying using Portainer, and you're gonna see why. So what is on the menu for today? Well, I wanted to see if I could choose Portainer with Equinix Medal together to deliver an application

0:28 The Challenge: Automating Edge Deployments for Low Latency

0:41 to my customers with as low latency as possible. Now I can do this with Equinix Medal by using global Anycast BGP advertising to route traffic to any region they support. But it comes with a maintenance overhead. I then need to manage bare metal in Asia, The US, and Europe continuously. I need to update my applications. I need to use something like SaltStack or Ansible to push out updates to all of them at the same time. It's cumbersome. And in fact, this is why we fall back to tools like Docker Swarm, Nomad, and Kubernetes. However, those all bring a level of complexity as

1:18 Why Traditional Orchestrators Struggle at the Edge

1:28 well. And I love Kubernetes. I talk about Kubernetes all the time. However, it's a pain in the ass when you have to distribute it and scale it globally. Kubernetes using etcd is a very chatty system, and in fact, it's often encouraged and recommended never to scale your Kubernetes cluster beyond a single region. So if I want to deploy an application to my customers all around the world with low latency, Kubernetes is not a good fit. Now if I were doing microservices with thousands of services, I'd maybe find a way to make it work, but I'm not. I'm scaling

2:04 a few containers. So let's move all of this to a platform designed to do this properly, and that is Portainer. I'm gonna show you how to run Portainer in an edge environment. Now I'm only using three nodes around the world. However, Portainer scales that has been tested to over 15,000 edge connections. So it doesn't matter if you've got my scale for a few people or your scale for a few million. So let's take a look at the code to spin up and manage Portainer in an edge environment all around the world on Equinix Metal with any cast written using BGP.

2:35 Overview of Infrastructure Automation (Terraform CDK, Equinix Metal, BGP)

2:45 This demo was super fun for me. I hope you enjoy it. Let's dive right in. Alright. So today, everything that I'm going to show you is available on the Portainer in production repository. The link is in the description below. We are using Terraform CDK to automate the provisioning of four bare metal devices. One, Portainer admin node, which will act as the central point for distributing commands down to our edge agents, and three edge agents, three bare metal devices distributed around the world, all sharing one common Anycast BGP advertisement. This will allow us to request a simple

2:50 Overview

3:25 NGINX container from anywhere in the world and see very low latency response time. Now I'm gonna spin this up in a way that we see it with two edge agents, one in The US and one in Europe. We'll see that the response time from Asia and Australia is pretty poor. We're gonna bring in a third node, and we're not gonna install anything to it. We're gonna let Portainer do what Portainer does best, which is manage all of these edge devices for us using edge stacks. We'll then rerun our tests, and we'll see that we've substantially improved the latency to our customers in

4:02 that region. And that is the goal. Right? We wanna be able to have ephemeral automated compute infrastructure handled for us with all our applications deployed via Portainer with no manual intervention. So let's take a look at the Terraform CDK. Now, we are gonna do this in a two phase deploy. One to deploy the admin node to get the token that we need, which is the edge key here, to then do the second part of our deployment with the edge agents. Now we've got the Portainer admin Terraform stack, which uses Cloud init, and I'll show you

4:18 Examining the Terraform CDK Code

4:44 the scripts to do the provisioning in just a moment. To handle deploying Portainer as an admin node and as an agent. And then we have the Equinix provider so that we can provision some bare metal devices with a BGP advertisement. We reserve a global IPv four address on the Equinix metal network. We build our cloud and a configuration, and we deploy the device. Now I am enabling a BGP session on the admin node. We could in theory double down and use that as a edge compute node if we wanted. However, for today, I'm not really doing that.

5:22 We use Terraform outputs to publish the admin IP, so that we can get to the web interface and the BGP IP, so that we can request traffic or we can request the NGINX application. Next, we define the Portainer at the Edge stack. Now this also uses Cloud in it and Equinix just like we do above. The user data that we're generating Web Cloud in it is just a little bit different and that we are setting up BGP and our Portainer agent instead of the Portainer installation script. Like so. Then we provision the device. This time, we

6:01 are passing in the edge key and the global BGP IP address as custom data so that we can fetch that back down from a user data script. And then we output the worker IP, and we also configure the BGP session. So this is not terribly complicated. It's just a hundred and so lines of Terraform CDK. You can pull this, you can run it yourself, it should just work TM. Now down here, we have defined our stacks in Terraform CDK, but we actually need to tell it what to synthesize and what to run. So we generate the application.

6:35 We create the admin stack. We can now have this new container at the edge stack. We can actually duplicate this as many times as we want to any facility within or any metro or facility within the network, and it continues to scale out geographically as much as we want. Perhaps we want more infrastructure on the East Coast and the West Coast Of The US. Perhaps we want infrastructure in Central Europe, Western Europe, and how to infrastructure distributed across Asia. That is up to you. You know your customers, and once you have the stack run up,

7:08 Portainer does all the heavy lifting. All you need to do is spin up new nodes, join a Portainer cluster, and you're you're golden. And then we synthesize and we run it. So we have no edge key here, so I'm gonna walk you through the process of spinning up the Portainer admin stack, turning on edge compute, getting that key, and then we'll take a look at the edge deployment mechanism. So first step, as you'll see, I've already ran these commands a few times, is to do a CDK t f deploy admin. This will set up everything that we need

7:20 Deploying the Portainer Admin Node

7:45 to get the edge key available for the edge compute deployment. Now this is bare metal. It is not a virtual machine on any of the hyperscalers, So we're not gonna see this return in ten seconds, thirty seconds, or even a minute. It's gonna be closer to one to two minutes. So I'm gonna go poof, now back in a second. Sweet. We have our admin stack deployed. We have our BGP address, which won't be resolving any traffic at the moment. And we have our admin IP, which will allow us to set up our Portainer instance. Let's copy our admin IP

8:24 Setting up the Portainer Admin Interface and Edge Compute

8:24 and pop it open in our browser. We will be presented with the Portainer setup screen. We've seen this before, so I'm not gonna spend any time on it just now. Provide my password. I hit go. And I'm going to provide my license key. Remember, the business edition of Portainer is free for up to five nodes. So if you're a small scale deployment like me, take advantage of that. Sign up now. Okay. Now that we have Portainer admin node running, the first thing we wanna do is go to settings. From here, we can click on edge compute

9:00 Enabling Edge Compute Features and Getting the Edge Key

9:05 where we turn on the edge compute features and click save. We then want to scroll down to the automatic edge environment creation. You will see your admin IP address and port number here. You can disable the waiting room if you want. However, we're going to leave that on so you can see how it works in this demo. Now because I'm using my CDK Terraform or Terraform CDK automation, I don't need to worry about edge ID generators or dropping an environment variables into this script here because it's already done. So just go check out that automation

9:48 and CloudEdit configuration scripts to see how I generate those values. The only thing I really want is this edge key here. So we're going to copy this and switch back to Versus Code to drop it in, like so. From there, we can run a CDKTF deploy, and we're going to deploy US and EU. However, I also specify admin. That's just because that The US and EU stacks do have that dependency on the admin stack, so it will force you to specify all three. We click the button, we wait a few moments, and we'll get an approval prompt for two

10:00 Deploying Initial Edge Agents (US & EU)

10:32 stacks to be deployed. We had approved twice. Those devices are now created on the Equinix middle platform, and I'll be back in just a moment to show you the next step. Sweet. We now have a worker IP in The US and a worker IP in The EU. Now before I go to the browser and show you the next step, I do wanna push out one caveat. If you're running the same automation and you go to your browser, you may not see the pending nodes right away. The reason this is is that CDKFTF is not waiting for the user data to

11:11 finish provisioning. So while these bare metal devices are now available and I have IP addresses, the cloud in it process is probably still running, and it can take anywhere from thirty seconds up to a minute and a half to complete. That is because it's pulling down a Docker image. It's then starting in the Docker image, it has to register with the Portainer admin instance blah blah blah blah blah. Now because of the per video, when I go to my browser, things are magically gonna be there. Please just remember, it can take a few more seconds.

11:41 Associating Edge Agents in the Portainer Waiting Room

11:41 And that being said, let's now go to my Portainer admin instance. So we can click on edge devices and click on the waiting room. And we'll see at the moment, I have one of my devices waiting. Hit refresh and by the power and magic of video, now both are available. We can now click on this and see that we're happy to associate these devices with our Portainer cluster. Now where we click on edge devices, we will see that we have Portainer at the edge Frankfurt and Portainer at the edge Dallas. This is our US and European

12:08 Organizing Edge Devices (Groups)

12:17 devices. Now, Portainer has a cool feature where you can enable groups. This is not important for today's Edge stacks demo. However, if you have more than one administrator of your cluster, you may be able to use groups to be able to facilitate access to multiple edge devices with ease. To do so, I will create a group called production, and instead of saying this is static and selecting the two machines, I'm gonna make this dynamic, and I'm gonna base it on environment variables. We can say environment production, and we'll see that the two devices already provisioned are now available to add to our

12:54 edge group. Now, again, not important for the stacks demo, but for managing access to more than one edge device, groups are super cool feature. Next up, we're gonna add our edge stack. So we go to edge stacks, we click add, and I'm gonna call this NGINX. We're gonna use a very simple Docker compose file to deploy NGINX to each of our edge location. We then select the group of production and the type of deployment will be composed. Now if you go to the repository in the description below, you will see that there is a docker composed file.

13:06 Deploying Applications with Edge Stacks (NGINX Example)

13:33 You can copy this or type it. It's very simple. It's just going to deploy NGINX and expose it on the host or node port of 8,080. And then we say deploy. You'll see here we have status indicators, blue, green, and red. Let's turn on auto refresh to ten seconds, and you'll see now we have two successful environments. Blue for acknowledged and red for failed. If we click on this and then environments, you'll see that this stack is successfully deployed in both Dallas and Frankfurt. Well, let's go back to our CDKTF for just a moment. We have this BGP advertisement

14:15 Checking the Deployed Application

14:22 here. So let's pop this open in our browser. And if I browse to eighty eighty, we are presented with the NGINX web page. So let's check the performance of our application using a nice web performance checker from KeyCDN. You can go to tools.KeyCDN.com/performance, where you can drop in your URL and port number and say test. Now what we see here is pretty standard for web applications, especially deployed in this topology. The latency for European and US websites is pretty high in Asia and Australia. You can see Frankfurt has less than two milliseconds response time or at

15:00 Latency

15:22 least a connect time. We have less than three milliseconds for time to first date. This is peak performance. Now Amsterdam is gonna rise a little bit, but you're still on the European continent and the traffic is still pretty decent. And the same for London. Now New York being on the East Coast is a little bit higher, but you can see in Dallas, at least where our infrastructure is actually hosted, we've got less than four milliseconds on the connect and five milliseconds on the time to first pay. Pop down to San Francisco, we've got the West Coast. So if you're not sure where

15:58 Dallas is, it's in Texas. It's kinda right in the middle. That's why both the coast are a little bit slower. Let's look at Singapore. We're waiting over two hundred milliseconds for the connect, and we're waiting almost half a second for time to first bite. Sydney is not much better. Two hundred milliseconds or at least a hundred ninety milliseconds on the connect with three hundred and seventy three milliseconds on the time to first bite. Tokyo's high and Bangalore is high. So we can improve this performance, and I'm not gonna do anything except for deploy our other stack.

16:36 Now the Terraform CDK will provision the instance or cloud and it will install a Portainer agent. Portainer stacks will detect the new device. We will approve it because we have the waiting room turned on. However, you could turn that off. Once we approve that device, Portainer will realize that it is part of our stack configuration, deploy NGINX, we'll be able to rerun the tests, and everything will be super fast and low latency everywhere we go. Let's do it. So let's do our CDK deploy, and remember, because each of our edge deploys have a dependency on the admin stack, we need to add

17:05 Deployment

17:16 the admin stack too. However, nothing will need to be deployed for the admin stack, and that will just offer us one change for our compute stack, which is our Asian compute node. So for the last time, I will be back in just a moment. Alright. It's almost time for the moment of truth. We now have an IP address for our Asian compute node. So let's head over to the Portainer admin interface and check out our waiting room. And there we go. We have our Singapore instance ready to be associated. If we come to our stacks,

17:55 Stacks

18:00 hopefully, that the refresh is right, although it may be a little too fast. There we go. We caught it. We have our acknowledged environment, and I wait for the automatic refresh in ten seconds or refresh it myself manually. We should see that turn green. Hey. Love it when stuff works. We can click on this, click on environments, they're all okay. And what I really love about this is that we don't need to worry too much about the management layer of a geographically distributed compute cluster. This is something that Kubernetes is notoriously bad at. Stretching Kubernetes clusters across more than one

18:25 Environments

18:46 region is super painful. You pay a lot of money on egress traffic because the communication patterns for the kubelet and the API server were built under the assumption that these things were almost collocated within the same building. Portainer is different, especially with their edge compute semantics. So we have to complete the demo. Let's check key CDN to see the performance of our application. So I'm not going to change anything. It's the same IP address, the same port, but a different topology for our deployment. And those numbers are looking pretty different already. Singapore, we have three and four milliseconds.

19:30 Improving Performance by Adding an Asia Node

19:34 Of course, that is where we deployed the other node. Sydney is a little bit higher, but much less than what it was without the Singapore region. And Tokyo and Bangalore have improved slightly as well. So that's pretty cool. And this is one last thing we haven't looked at, which is edge jobs. Now that we have our geographically distributed compute cluster with our application being delivered to our customers and a low latency environment using any cache routing with BGP, We may have admin things that we need to run on a regular cadence, and Portainer supports this through

19:45 Edge Jobs

20:12 edge jobs. Now let's assume we wanted to run a backup. We can use cron syntax if we want or the basic configuration. We can mark this as recurring and say run once per day. From here, we can use whatever script we want. So if you need to backup any of your volumes or your containers or logs to Amazon s three or GCS or anything like that, script it away. We can select the node or nodes we wish to run it and click create. As simple as that, we have our backups good to go. So that is the edge compute capabilities of

20:58 Portainer. Coupled with Equinix Medal and BGP written, you can get some pretty impressive architectures to satisfy your customers wherever they are. Join us for the next video in this course. I'm gonna be diving deep into how Portainer can enrich Kubernetes. I'm very excited for the next video. I hope you are too. I'll see you soon. Until next time. Have a good day.