1:57 Introduction and Course Overview

1:57 Hello, and welcome back to the Rawkode Academy. Today, we are doing the next part of our limitless global reach with BGP course. That means that we are gonna be continuing to experiment on the Equinix metal platform, leveraging their network and BGP support in order to build out some sample applications that are globally available with minimal latency. If you don't understand what that means, then I recommend that you go back and check part one where I was joined by Jeremy Tanner slash Penguin on the Internet, where we talked about what BGP is, how it works, and why it's important to build

2:37 low latency globally distributed applications. Today, we're gonna build on top of the work that we did in the first part, and we'll be repeating some of the first part as well. So you don't have to go back and watch the first part right now. I will cover the essentials as we go because we still need to spin up some more Equinix ML devices, enable BGP and deploy a workload. What we're gonna be doing today with that workload is running core DNS as a DNS server in three metros or regions, facilities, whatever you wish to call them

3:01 Today's Goal: Global DNS Architecture with BGP

3:11 around the world. We will be using The US, Europe, and Asia, for example. Using BGP, we can broadcast that DNS server with a single IP address, which will be available to anyone via their closest region. This is really cool because it means you can build at the edge platforms. So I'm only using three metros today. However, there could be as many as you need to handle your customers and keep them happy at the same time. Now, before we dive into the hands on component of which all these courses are, If you wanna work along and do this

3:45 Equinix Metal Credits & Resources

3:53 on your own, there's a link below, rawkode.linkmetal. This will take you to the Equinix Medal homepage, where you can sign up and use the code, Rawkode. This code will get you a 200 USD in credit to experiment and play with Equinix Medal throughout this course. 200 USD is around anywhere from one hundred to four hundred hours, depending on what size of hardware you use on your platform. So there is plenty, plenty of credits there for you to experiment, have some fun and learn some cool stuff along the way. That being said, we're gonna dive straight over

4:35 Course Repository and Materials

4:35 to my screen share. So this course is available and really a smarter person would have had the link available. Where's my mouse? There we go. Can't even frame my mouse, so it's a perfect start. So let's pull this window into display. We have the GitHub Academy, the Rawkode Academy GitHub page available at github.com/rawkodeacademy. There is a repository there called courses. You will find the global reach BGP directory here. This is today's session with the README and some Pulumi automation that we'll be taking a look at and pretty much everything you need to do this on your own. However, I'm going to run

4:40 Course Overview

5:28 through it too. So any hiccups that I get also means that you can see how I fix it and I get to update the course material, win win. If you have any questions throughout today's session, please feel free to drop them straight into the comments, or if you just wanna say hello, go for it. I'd love to say hello. Alright. So the start of this workshop is gonna feel very similar to part one and that we are going to need to provision some Equinix metal devices. Oh, we have our first hello. Hey, Maz. Thanks for joining us. Alright.

5:49 Beginning Manual Setup: Provisioning Devices

6:05 So we're gonna spin off some Equinix Mail devices. We're going to configure BGP, and we're going to do this all manually, run and install core DNS. Of course, I do have the Pulumi automation here, so we'll spin that up too, so you can see what this would look like in a fully automated environment. Oh, we got a few more hellos. Hey, Rio, thank you for joining us. And Manuel, thank you for saying hello. I appreciate that. Okay. So let's get started. Today, we're gonna spin up the core DNS and three metros. We're gonna see how this works and then

6:40 we're gonna take a look at some automation to do it. Now, all of this takes a little bit of time. We have to provision some machines and we have to automate the provision of some machines. They all take about ten minutes. I'm gonna kick it all off at the start and then we will run through the rest of today's examples and materials. But the first thing we need to do here is to go to the Equinix Medal console, first request a global IP that we can use as our BGP advertisement around the world. This will be advertised on all of Equinix

7:12 Medal's autonomous systems around the Internet. If you're not familiar, Equinix has a completely amazing backbone around the Internet. So it's a fantastic network to build on, and in fact, they have direct connections to all the major cloud providers too. So worth checking out Equinix Connect and seeing what you can do with that too, but that's not for today session. So let's spin up some manual machines first, then we'll kick off the automation. I'm gonna click new server. Well, I have some clustered stuff because I have an episode of clustered tonight. So we'll ignore that. On demand,

7:51 we'll make this bigger so you can kind of follow along. And let's see, we're gonna kick off our first one in London, just because that's where I am. We'll do a C3 medium. We're just gonna use Ubuntu. I'm gonna use 22.4 because it has this wonderful little lightning bolt, which means it's quite fast to provision, which is great. I don't need to change the name of the host name. I'm happy for that to just to be l l d blah blah blah. We'll hit deploy. We all spin up, I'll maybe just do two for now, although the automation will spin

8:28 up more. In fact, manually, I'll just do one and the automation can spin up the rest. So if we come to the automation, there's a Pulumi directory and here you're gonna see the cloud config that I used to automate the entire process of installing and configuring core DNS, as well as a Pulumi program, which I'm using Q for today. So if you're not familiar with q oh, I don't have that on this machine. I have a new machine, which is the proven fun. My dot fails were not as complete as I was hoping. This q lang program

8:35 Automation

9:02 does everything that we need to do to spin up these servers. We can use QX port to see what that looks like in JSON or even YAML. Actual YAML. How did I set YAML? Oh, out fail. Okay. Dash out YAML. There we go. This is what it looks like in YAML. This is what's actually being run by Pulumi. And we'll go through that in more detail once we've run through the actual example. All I really want to do right now is just spin this up. Oh, my token. All right, let's do this in a nice,

9:44 safe and secure fashion. Now I'll grab a token from another browser. Too many monitors, I keep losing my mouse. Okay. Where did I just paste that? Nothing is on screen. I think I'm okay. Okay, so now we should have a password set and we can run Pulumi up. What we're gonna see here, let's just go into our IP block, three devices, one in The US, EU and Asia. We've got IP attachments and BGP sessions for all of these and we'll hit go. Right. Hopefully that just well, hopefully, that just works. Invalid authentication token. Okay. So do I not

10:48 know how to paste? Ah, I still got all the YAML on my buffer. There we go. Who'd have thought it was the token that stumped me or copied and pasted. Let's let that go. So that should be better now. And I'm feeling confident, so I'm gonna go away from here. We'll come back to courses, global reach part three, create failed. But only my Tokyo machine. So that's probably just I've got the Metro wrong, which I really should have double checked it, but I'm not gonna worry about that machine right now. We can still work it with that. And so I'm gonna

11:36 let that spin up just now. We'll pop back over to Versus Code and yeah. Rio. Copy and paste is definitely an art that I should invest in time and learning and improving, but not right now because we're busy. Okay. So we have one device. So I've done this back here, but I actually forgot to reserve myself a global IP. So we're gonna come over here. We're gonna go to IPs. And we're gonna request a new one. You'll see that my automation already has one, but we're going to do one more. Now you've got a couple of options on Equinix.

11:56 Reserving a Global IP Address (Manual)

12:13 You've got public IPv4. These are announced or advertised only within metros. Now, because we want globally available IP, which means it can be from anywhere in the world and we're treated accordingly, we need to go for global. It's a little bit more expensive. But again, if you're watching this video and you want globally distributed service, then it's probably gonna be worth it. We just want one, I'm not gonna get any more. And then I'm gonna submit my request. And if I refresh oh, there we go. I thought they were the same. They're different. We now have forty dot twelve as well

12:59 as our automation, which got forty dot ten. Okay. Let's jump back over here. So we've reserved one. We have deployed a server. So I was supposed to be using Chicago, London, and Sydney. I've been deviated slightly from that, but you can use whatever metros you want. What we need to do now is for each of the servers where we want to be able to advertise BGP address is that we have to go on and configure a piece of software called BERT. BERT is a BGP advertiser. BERT BGP. Here. So it's just open source software that anyone

13:23 Configuring BGP Manually: Introducing BERT

13:45 can use. There are other options for advertising BGP addresses, but I'm quite comfortable with BERT and Equinix better provide some network helpers, which you'll see shortly, which actually configure pretty much everything that we need to do today. So we're gonna stick with that. So we are going to apt update, apt install bert and Python three, and then we're going to get these network helpers. So what do we need? We need the IP address of our first server, so we can come back to here. Oh, no, I clicked on demand. And this No, I spun up the medium

14:29 in London. Yep. This is my automation. So we're gonna ignore that for now. And we are now on a machine, we can do our apt update. Moj says awesome Versus Code theme. Thank you. This is base 16 dark ocean. I'm quite partial for the base 16 themes. There's a whole bunch of varieties, but the ocean one I find is there. It's quite nice, especially looking at code. It's it's really readable, which is awesome. Alright. So we've run an apt update. We now need to install Python pep get bert. Think it's just Python three actually. Nice. Just takes a moment. These boxes have

15:37 pretty good to interact. And we have a question from Manuel who asks, do you know if it's possible to bring your own IP to Equinix Metal? You can, actually. You get a couple of options when it comes to IPs and BGP with Equinix Metal. Now I believe you do need to speak to the support team. Not all of what I'm about to mention is available via the portal. But I know that from the portal you can bring your own ASN and have Equinix advertise IP addresses to it, which is very, very cool. It does take

16:17 this is one to two business days for a response. During my experimentation, it's it's been much faster, closer to twelve hours. So you can bring your own ASN and and could have a password on it, and you can advertise to it from Equinix Metal. Very cool. And if you want to bring your own IP address, you reach out to support, and then they can hook that up and advertise the IP address for you once you've confirmed that it is your IP address to advertise. So, yes, you 100% can. Alright. So we now have all of that

16:50 Configuring Interface

16:51 bits of software installed, so now we need to configure our interface. So we have this cat command here, which is going to basically add a new IP address to the loopback device, and we want this here to be our BGP global IP. Why did I get logged out? Strange. Okay. So let's grab that dot 12 IP address so that we can configure that as required. So we'll just copy this, assuming I know how to copy paste. Right. And I'll drop this into Versus code here. Make sure I have the right space there. And we add this to our interfaces file.

17:43 Like so. Oh. Nope. Having that error is okay. Yes. It is. Good. So we do have our our IP address on the loop back to five. This may be an ubuntu twenty two zero four error. I'm gonna ignore it anyway. My testing was all done with twenty zero four, but I decided at the last minute we should probably use the latest and greatest. In fact, my automation still uses 2004, so it's fine. But I'm gonna ignore this message. This is, I believe, just superficial. What we really need to see here is that when we run IP adder, we see

18:27 our address. So I'm happy with that. And so that I don't commit this, put this back. Next, we have to use the Equinix metadata service. So you can curl and get a whole bunch of data from metadata.platformequinix.com metadata, type that to JQ, app install JQ. And you get all the information about your actual bare metal device. So you'll see that you have information on the host name, the operator of the system, the Metro and facilities, SSH keys that have access. You have the specification for the machines, the type of CPU, type of drives, the type of NICs.

18:37 Using the Equinix Metadata Service

19:15 You've got all the storage information, file system, everything that you need to know about this machine, which some of it you can get just by working with the device file system in Linux, but it's all available over an API. What's really important for us right now is that we need access to the BGP neighbors configuration, which we haven't enabled yet. So if I actually run my terminals a bit overzealous with a copy there. If we try and fetch out the BGP neighbor information, we're not gonna get anything yet. Now our automation handles as follows, but the manual approach is that we need

19:53 Enabling BGP in the Equinix Console

19:55 to come into our servers, click on our manual device, go to BGP, and I could say turn it on, but it does appear to be on. Did that just happen? No. This was the manual. Yep. London BGP. Let's just do a quick refresh. That's weird. Whenever I'm very unlucky and there's some issues. Ah, there we go. We're gonna turn on BGP for IPv4. Someone knocking at my door. We're going to turn on BGP IV4 for this device. Now this should be pretty instant. Yep. There we go. We do a curl to the metadata service again, using GAQ to

20:53 pull it the best that we need to, and we'll see that here's the ESN number that we need to advertise to. Here are the IP addresses that we can do that with and yeah, nothing else particularly important there. So when you're doing this manually, just remember to come here and turn it on for IPv4 and IPv6, depending on what you're doing. Right, next. So we need to run this command, which is pretty much the same. However, what we're doing here is getting the gateway on the management, getting the gateway on the management interface for IPv4,

21:16 Configuring Network Interfaces and Routes for BGP

21:37 so that we can configure the routes to go through this. And then we can configure the gateway IP for these routes. So we're gonna copy this, come to Versus Code and do this. And this is all handled by the automation. If you don't like doing this stuff manually, it's all good. Oops. Oh, I forgot to add the PIN addresses. This is why automation is important. So we did this and this. And now if we run IP routes, you'll see that we can successfully route traffic to the peers through the public IPv4 address. We'll undo that, so it'll commit it

22:33 and keep going. So now that we have the roots configured to speak to the peers, we can configure and install BERT. Now you don't need to do any of this manually. The network helpers available at github.com/packethost/network-helpers do everything for you. They speak to the metadata API to pull out all the peer information to configure BERT. We'll take a look at the config, and BERT just starts running via system d and everything is good. So you'll see here, it spits that out. We've got our static roots configured here. Oh, cool. I guess you don't need to

22:39 Installing and Configuring BERT with Network Helpers

23:09 add that manually. Well, we're still gonna do it. Add the it's got the roots, it's got the neighbor and it's got the other neighbor. So exactly what we need. We can run a system control status bert. We can see that it's running and I'm just gonna ignore these letters. These are superficial as well. Next, we can run a BERT shell to confirm that is actually working and doing what we want. BERT c. And we'll see here that our BGP state is established. This is good. This is what we want. We want BERT to be able to successfully

23:31 Verifying BERT Status (BGP Established)

23:48 establish and talk to those peers so we can advertise the address. And this is not always instantaneous, but if you need to confirm this even further, you can go to the admin console. And if you hit refresh, yeah, it's not always as instantaneous, but I updated every six hours. Let's try and force it be update. As we should see that this machine has a learned route. Yeah. Okay. We're not gonna wait for that. So that's okay. Alright. So BGP is now configured on this device and ready to go. Next, what we wanna do is actually run

24:27 Installing CoreDNS Manually

24:27 core DNS. Now you can do the trace route here if you want, but it's just gonna confirm the route that you take on your local machine or an Equinix Mineral infrastructure back to that IP address should be pretty trivial, I would hope. So next we're going to install core DNS on this machine, which is just a curl from the GitHub release bayon array and then making it available on our path, And then doing that, we have a question from Moz. What advantages does BGP offer over direct routing apart from dynamic routing? So BGP is what makes it possible to advertise

25:11 one IP address across the entire internet and route it to different machines depending on where the source request comes from. I don't I don't believe it's possible to do this with other technologies. So what this means is if you think about traditional networking landscape, you have an IP address that maps to one machine. Sure. It can go through some routers and and other pieces of kit before it gets there, but it's always one IP address as one machine. BGP makes it because it works at the AS level, the autonomous system level, that if you come into an autonomous system, it can

25:50 actually advertise a prefix or an IP address and say, I know how to route this traffic and all of those different autonomous systems can route differently depending on where the source traffic is coming from. Meaning that if you're in Australia, then you're gonna be routed to a server in Australia or as close to Australia as you can get. Whereas if you're in Europe or The US, we're gonna route you to traffic within Europe and The US and as minimal hops as possible. We're just in that latency to the first bite because that's how we build truly scalable

26:18 distributed systems on a global scale. And I don't think it's possible to do this without BGP. Although, I am happy to be corrected. So that is why we would do this with BGP. Now the other alternative way to do it, which is not through a single IP address, but just through sharding geographically at the DNS level, which is having DNS servers and and edge locations and having them route the traffic and return different IP addresses depending on where the request comes from. That is not as I I don't like it as much. There's definitely more margin for error

26:55 and DNS caching and a whole bunch of other things that you have to deal with, but it is a route that cloud providers have used. AWS and Route 53 definitely offer this as a feature. But if you have access to BGP, I really struggle to see why you just wouldn't go down the BGP route. So I hope that helps, Mozz. If you have any follow-up questions, just drop them in the chat. And a cool comment there from Manuel. Just a reminder to everyone here who's not a network engineer, you want BGP to be established, not active.

27:24 Good tip. Thank you. Cool. Let's jump back into this. So we've got available, but we need to be able to configure it. And I'm going to do this rather chaotically. So let's just oh, Let's do this first. So we're gonna create a core DNS directory and we're gonna write a fake domain to it. Of course, you should you should choose real domains, but because of the way the internet works, I can use whatever the hell I want and it will just work because I'm gonna be directly sending DNS requests to this BGP address. So what we're doing here is we're ran

27:36 Configuring CoreDNS (Zone & Core File)

27:59 we're using the core DNS file plugin, which means that you can store all of your DNS records inside of a file and core DNS will load them just like bind another DNS systems to be fair. You can hook core DNS up to like databases if you wanted to build it out that way. But for today, in fact, in general, like a drill, I think the file plugin is is pretty spawn, especially as you can store all these configurations and get sync them onto the machines, run CoreDNS, and then set up system data to do reloads whenever the files changes and pull new

28:30 changes from Git. So, yeah, good way to do it. Manuel, gotta go. Make sure you watch later. I appreciate the comment. Thank you very much. I really do appreciate that. Thank you for joining, and feel free to comment later when you get around to watching the rest of the video. So we are configuring an origin or domain here for yourfirstdomain.com. We're setting up some store records. We can pretty much just ignore these or copy them from the internet, wherever you want. If you want to do it a bit more nicely or properly, feel free. But the only bet

29:00 I'm really concerned about right now is that we have two records on this domain. One of them, we're setting up an a record for www, which is always gonna resolve to 127001 and an IPv6 local host QUADI record or 40. I don't know. I'm not sure what the proper terminology is there. However, this is all you need to configure core DNS to start serving records. Next, we need a core file, which tells it to load this configuration. The core file is the main configuration for core DNS. What we're seeing here is that we're gonna run core DNS support

29:28 Core DNS Configuration

29:40 one five three instead of 53. And that's because if we try and run it on 53, system d resolve is gonna yell at us. So you don't really want system d resolve to yell at. You could stop it. I'll leave that up to you. What I'm saying here is that I'm gonna forward all unknown domains to Google's DNS at eight dot eight dot eight dot eight. If you wanna use Cloudflare @ 1 1 1 1 go for it or your own preferred service, up to you. Next, we say that any request for your firstdomain.com will be loaded from the configuration file that

30:14 we wrote earlier. Next, I've written a systemd service file that we copy here, which gives us core DNS handled by systemd. We can run a daemon reload, start core DNS. Now, if we've done this correctly, we should be able to dig at one hundred twenty seven thousand and one dash P one hundred fifty three and say google.com. Maybe not. CoreDNS running. It is not. Alright. Guess we're debugging. So Oh, the directory doesn't the file doesn't exist. Twitch, core DNS. Interesting. I think there's something wrong with my unit fail. Let's fix it. User Rawkode band. CoreDNS.

30:49 Debugging Manual CoreDNS Startup Issues

31:33 Well, this user won't exist. So these two capabilities allow us to bind on ports less than one zero two four. Mean, it does look alright actually. In fact, let's try running it. Then core DNS core fail. Oh, and it's then dash c. Nope. Dash conf. Okay. That worked. Restart core DNS. Restart. I'm not having much luck here. Alright. Data for DNS. Yeah. I think it was just the user pragma instead of my unit file. So, I mean, that's best practice, but we haven't set up a user, so I'm gonna remove it. And we do have it working

32:48 Core DNS Plugins

32:53 and we do a dig, we get it forward and on and we get an IP address. So this looks good at the moment, but we'll confirm that. Let me jump into the comment. So we've got one from RIO. BGP can be fun. I remember someone able to draw a nine cat on the right dashboard that were in traffic different over time. That's scary. I'd love to see that. That sounds awesome. Very cool. Oh, you were trying to debug my problem with me, chmod plus x. No, I I think the permission was okay. The the script

33:22 that we used to install that do a chmod anyway, but I think it was just the user. And the question from us, does core DNS support caching? It does. It has a whole bunch of plugins actually. So if you come here to core dns. Go to plugins. Well, we got here, we've got ACLs. If you wanna control who can request records from particular domains, if you wanna load bind files, if you wanna work with Azure, then there's a cache one here. So if we click on that, this will cache records. Yeah. Well, the configuration or how long to

34:03 cache it for, etcetera. Those plugins for yeah. There's lots of stuff here. DNSSEC. Really, I should start experimenting with that. I keep being entered to that in my domains, but I just haven't got around to it yet. STD support, GeoIP, if you want to go down that route, gRPC, headers. Yeah. There there's there's just the support to plug ins and then there's the external plug ins as well. So, yeah, there's there's lots of cool stuff here. So core DNS is great. So let's, we tested Google and we've seen that that was forwarded on correctly, which is great.

34:43 Testing Google

34:50 Let's try your firstdomain.com and we only set up www as IPv4. So if we do that, we do get this here, although we still, you know, we have fake authority section here. Don't do that in your own configuration. This is just a demo. But we have the 12700 here. So this is working. We have a DNS server that works. I can use our BGP address now instead of doing 127. So I can come here and as you can see, I've tested this on my own machine previously. Our BGP address, it's similar, but not, I know it's dot 12 and

35:16 Testing Manual Setup via BGP IP & Traceroute

35:32 there's something in the middle. So let's take a look at what that is. BGP. Nope. BGP. Oh, it's not completely different IP address this time. We're not completely different. Okay. So we do dig at port and we hit it and we get one two seven back. So this is from my local machine. This is not with an Equinix metal. And if we actually do a trace route to the type, I've obviously got copy on highlight on this new machine. And if we run the trace route, we're gonna have to go through this is a five g router that I'm

36:18 on in my office, believe it or not. So we're gonna see a whole bunch of failed hops. And I really should have set the retry on failed hops to one, but never gonna have to wait for five stars on each. But we'll see the route that this takes to the Equinix better infrastructure, and, course, we could run this from another machine and see that routed slightly differently if we had more than one server, which is where the automation comes in. So we can take a look at how you take this manual process that I've done,

36:38 Transition to Automation Overview

36:41 repeat that using Pulumi. You could also do this with TerraForm and deploy to as many regions as you want. So we'll take a look at how I'm using CURE to template out all this YAML and hopefully give you a good idea of how you can do something similar for yourself. I'm going to drink this coffee and hope that the stars disappears. More stars. So people that aren't aware, the stars on a tracer are in fact, here's do you know how how a tracer works? What it does is that every time you make a request to something on the Internet,

37:28 How BGP works

37:38 it goes through something called a hop. Every device that you go past in order to get to your target device is one hop. As those hop respond to an ICMP ping, then we will get information like we see here. If they did not respond to an ICMP ping, it will try it again. And I thought it was five times, but it's three stars, so it tries three times and the star just means that it didn't respond. So what we'll see here is that when we do get information, things are much faster, which is why a

38:07 trace route can be a little bit slow at times. And the way that it works out the devices is also kinda crude, but really, really cool. When you set up any request on your machine to the Internet, you set a time to live, which means that every time you go through another device, it will decrement that and when basically, how many hops you're willing to accept to reach or be routed to another device. And what Tracer actually does is set that time to left to one so that it gets terminated at the first device and then

38:39 gets the ping back and then sets it to two and then sets it to three and then sets it to four until you get to the device that correctly identifies as the device that you're trying to reach. Very crude, but it works really, really well. And Rio is talking about MTR as well in the comment. Yeah. Yeah. Definitely very cool too. I don't believe I have MTR available. Okay. So there's not really much more to show from the manual perspective. We deployed a metal device. We hooked up BGP via IPv4. We deployed a configured BERT, and then

39:17 we configured core DNS using the fail plugin to specify the domains that we wanted to respond for. We have made requests from the machine itself and from my own machine using the BGP address. We could see the trace route does get there eventually. I'm not actually sure. This must be a BGP thing. I never actually considered it before. This is not IP address multiple times just means that we're being routed through. That's just the Equinix Mail infrastructure at that point. Now let's see the automation. So if we pop over here oh, okay. Oh, I think that failed because of that

39:53 Pulumi Automation Status & Rerun

39:56 one device that I couldn't spin up, which is a it's just a wrong metro. Oh, there aren't any servers. Alright. Okay. Let's just remove that one. So I'm gonna modify the automation and run it again, and then we'll run through the automation as well. Now let's just remove that. Those devices, the other two devices are already spun up, that should be nice and fast and we're not gonna have to wait too long. Yeah. So now we're just doing attachments and BGP sessions. Okay. So this is a Pulumi YAML program. However, I have used a custom

40:35 Explaining the Pulumi/Q Program

40:39 compiler, which we can do with Pulumi, but I just say instead of we're gonna provide you YAML straight up. Instead, we have to do some sort of compilation step to get the YAML back out or JSON. And for that, we're going to use Q export as I ran on the command line earlier. Q actually allows us to take Q and spit out a whole bunch of formats. We can do JSON. I'm sure there's more, but I'm not gonna risk it and try and see if TOML is supported. So, yeah, that's the PLUIvy program written in Q.

41:13 Queue

41:13 We're using Q because that allows us to encapsulate YAML into, like, definitions, which can be reused over and over again, and we'll go through that in just a moment. So the first thing I need to do is set some variables. Now we can specify here a project ID. I do include the code and the repository if you want to create the project by yourself. However, waiting for the approval for the global BGP to be enabled on that, again, can take a little bit of time. So that's if you want to go down that route, but you don't have to.

41:46 Reviewing Cloud Config Scripts

41:46 Next, we're using Cloud Config and here we're just saying that we have these parts. I've not added all the parts. In fact, Skeptr here, I've just not added them to the queue. I'll update that after this session. But the first thing we want to do is Bootstrap. There's also setup bird and core DNS. So these are just shell scripts that do everything that we did manually by SSH, but in an automated fashion. So you'll see here we installed JQ. We're looking and waiting, so we're on a while loop or an until loop until that BGP information comes through

42:08 JQ

42:19 the metadata API. So if it's not there at first, it usually just takes a few few seconds. And we also write custom data to some JSON as well. The custom data endpoint is how we pass in the BGP address to the machine because that is not available over the metadata API. Next, we set a BERT exact same commands, and we pull the global IP address from the custom data using JQ to get a single value. We configure the look back device. We get the gateway IP address. For each of those peers, we add a root,

42:38 Bird

42:51 and then we install BERT and use network helpers. So the exact same commands almost verbatim that we ran via SSH. Next, have the core DNS configuration. Again, it's pretty much the same. We download the binary and we stuck it into a directory. We write some configuration and we set up the system to the unit file, remove the user, and that'll just work. Well, actually, that's probably not working and I'm gonna have to manually go into those two devices, remove that user and restart it, but maybe open. If we go back to the queue, we have a request for the global IP. So

43:28 Global IP

43:31 we're not manually looking for a BGP address this time. We are using the Pulumi provider. It's saying give me a reserved IP block. It has to be a global IPv4. We only need one address, so slash 30 two. Then we're using something called a core DNS device, which is a definition in queue, which is how we get modularity slash reuse, and we configure that definition. So we're saying here, tweak the name of the device to be EU or US and deploy it to different metros. This is Dallas in The US, and this is Amsterdam in The EU.

44:05 And we're just pulling out the resources from that definition and to the top level plan. The queue definition itself has the configuration values at the top where we specify the type that we expect, but nothing else. Then we can define the resources for this definition. So we have a device. Here's supports interpolation. So we're saying pull in the name from here. We spin up an Equinix model device. We're using c three smalls with a older version of Ubuntu passing the project ID, the Metro, the user data as our cloud config, but it's the rendered version.

44:13 Define resources

44:41 So we're concatenating all those different scripts together as a multi part cloud configuration file. And we pass in our global IP so that we have access to that within the cloud and its system, which is important because we need it. Once that device spins up, we do the IP attachment. So we tell EquinixMetal that this device can advertise this IP address and we create the session. So we just say, hey, we want to enable IPv four on this device. The same way we did on the interface with the little tick box that had me confused for half a minute.

45:17 That's it. The Pulumi app gives us the devices. We come to the console. We'll see we have one machine here in Dallas. So let's jump onto there. Get my finger. Let's see if Bart is happy first. Oh, It's not happy, which means something went wrong. This is the output from my user data script. You can see it's sleeping, sleeping, sleeping, waiting for that BGP information. It has the BGP information. Oh, that's why. Because I am silly. I even mentioned this as I did it, but we need to do all the scripts. So we have just

46:19 Applying Fixes to Automated Devices

46:19 run these ones manually that are needed. So there's setup bert and there is three core DNS. So let's just run the script and we'll grab this script. I think what we'll do is I'm gonna jump onto the other machine and start pasting these scripts in as well. That's the core DNS one. Woah. I definitely angered that. And the other server is here. Alright. What did I copy incorrectly from here? Oh yeah, because this is a markdown fail. No, wait, it shouldn't be. Oh, I have just copied this wrong. That should be that. There's no more of those, is there?

47:39 No, good. Okay, so that should fix the first device. Okay. We'll do that one by one. Do we have core DNS? Yeah. Do we have our config? Yes. So it's just the unit fail. That looks alright. Yeah. Clearly I'm just struggling with copy and paste again. So let's do a restart core DNS, status, core That's probably that unit fail system core DNS. Of course. Thank you, Rio. Rio noticed that main pad will need to be escaped. Good call. Because it's saying include in it, it's not saying here. And I can just copy it. Alright. Save

49:11 daemon reload. Restart core DNS status. What? Oh, the origin hasn't been escaped either. Ran into this. I do do some testing. Yeah. This here is gonna be wrong. So let's just fix that. This is just stuff that works when it runs through cloud in it, but not when I'm pasting it into the terminal because the interpretation works differently. That's what was missing. That actually looks alright. Run it manually. Okay. Restart core DNS. Hopefully, it must be running low because the port was taken. No. Maybe it was restarting when it did it. Oh, wait. Cannot serve DNS one type three

50:33 is already defined. Computers. And that should be the fail. First demand. That looks fine. Core fails probably where there's a bug. Oh, because by automation, append to the file. Right. Things work when I'm not being very, very stupid. So let's restart core DNS. The status on this is 100% gonna be okay now. Good. We wanted to be able to run this on the second machine. So we're gonna quickly run through the set up BERT again. I believe this just worked. There was no errors here. And then we'll be careful with this one. I'm just gonna copy the whole thing,

51:36 write it to file and then execute it, and then we don't have to worry about the interpolation. So Mozz asked, is it a good idea to replace bind with core DNS? Depends on your use case. I find it easier to work with core DNS. I like its plugins. It's what Kubernetes uses, so I feel like my knowledge is a bit more transferable there than my you know, I have a lot of Bain knowledge from the early two thousands, late '2 thousands, but I think it's consolidating on more modern technology. Even though Bain still works, it's still great.

51:48 Core DNS

52:14 It probably still powers most of the Internet, I just I'm leaning more towards core team these days. Alright. So let's just paste this and run this. Oh, wait. Let's see my local. I'm just doing everything wrong. 40 c. Yeah. This is a different machine. Oh, that's my London machine. Computers are kicking my ass. Alright. So fem a Sh, what is there? So I got exited from this for reasons. No. Cool. Let's make sure there's no duplication in our core DNS file, in our core file. Good. The daemon reload. We're gonna get there and the core DNS.

53:17 If we run a status, it's happy. Now where we are is we have one machine running in Dallas, One machine running in Amsterdam, both handling a DNS for your first domain dot com via a single global IPv four BGP advertised address. Okay. Let's grab that address. And it's the 40 Dot 10. And we're on my local machine. Do a dig at -p153google.com. Oh, on port. So that uses the forward plugin and pushes me on. Your firstdomain.com should be empty, but if we add w w w, we get the correct record. So this is cool. But where am I going? Well, let's do

54:23 Testing Automated DNS via BGP & Traceroute

54:26 a traceroute. What's the parameters on that to do field ping one. Let's try that. Yeah. Cool. This won't take too long. But hopefully, we see this go through some sort of European Amsterdam data center into Equinix Medal. We can use like we did on part one of this course, there's some web interfaces, which will give you a kind of better this traceroute actually isn't very useful whatsoever. So let's do traceroute web. Maybe. There we go. So we're not really getting any reverse DNS information. Normally, it would show you. However, not a big deal. What we can see here from Frankfurt is

55:56 we go through some sort of forty five eleven network from Amsterdam is 1851, from London is 1851, is 19832. Well, we don't have reverse DNS lookup to show us, like, maybe this comes through Amsterdam Center, Dallas Center, parts of The US, etcetera. And the IP addresses are all different. The routes are being different. They are being propagated through the Equinix metal network. Good. What's BGP Looking Glass do? Is that anything cool? I don't know. There's normally a more visual one, but it doesn't really matter. So that's it for today. This repository, I'll push these updates that we've

56:34 Session Wrap-up and Summary

56:39 fixed during today's session. I hope this gives people a good understanding of, you know, cementing and building on the knowledge that hopefully we transferred to part one about what BGP is and why it's important to a more concrete use case where you can run your own DNS servers. Now you probably you may, but, you know, you may not do this with your own public domains, but if you have certain security characteristics or constraints in your organization, running your own private DNS servers using BGP could be a a good way to navigate and handle some of those traffic.

57:13 And we're gonna build on this yet again with the next session in this course. Let me pop back over to face mode. So on the next session, we are actually going to take this up gear and okay. What else is really good at the edge in multiple locations? We're gonna take a look at applying a functions as a service or serverless framework and multiple metros across Equinix Metal so that you can have functions at the edge. Cloudflare Workers are amazing. They have this wonderful technology where you can write code that gets run-in over 250 locations

57:24 Preview of Next Session: Functions at the Edge

57:52 as close to your customers as possible. This is a really compelling argument for building globally distributed applications. So we're gonna take a look at how we can do that using EquinixMail and some open source software. So we will deploy functions at the edge. We'll use a web system scraper to fire off bunch of requests from a bunch of different locations. And what we wanna be able to see and what we will see is that no matter where we send requests, we're gonna see very, very good first of time to first bite and minimal latency across

58:24 all of those edge locations. But until then, I will see you all soon. If you have any questions, feel free to leave some in the comments below. We'll be back with the third part of this course in two weeks. I'm at a conference in London next week, but I will be back the week after where we'll do and build something fun. So until then, have a great day. I'll see you all soon. Bye.