0:16 Introduction

0:16 Hello, and welcome back to the complete guide to Teleport here at the Rawkode Academy. In this second tutorial, we're gonna take a look at using Teleport provided container images and running Teleport locally on your own machine using Docker for Mac, Docker for Windows, or any container runtime on Linux distribution. We will also explore using Docker Compose to provide a lab like experience using some custom images provided by Teleport as well. We've got lots to cover today. There'll be a whole lot of fun. Let's get started. So as we do on these courses, we're going to rely on the projects and documentation

0:52 Documentation

0:53 as much as possible. Let's jump over to Teleport's documentation right now. Perfect. So as we can see here, we have an entire page dedicated as a to running Teleport with Docker, which is great for us. We can see that the images are hosted on kuai.io and we have access to a seven image, which is an alias to the latest version of seven. X release, but of course semantically versioned and tagged images are available if that is a route that you wish to take and one that I would definitely encourage as much as possible. Now there's one major difference from what happens

1:28 Container vs. Bare Metal Configuration Difference

1:31 with Teleport running and a container image versus the installation methods that we used on bare metal machines on Red Hat, Debian and any other distribution using curl. If you watched the first tutorial, you'll notice that we didn't configure Teleport in any way. We just installed the package and allowed the systemd unit fail to run Teleport. When this happened, Teleport detected that there was no configuration and generated one for us. However, we will not get the same experience when running the container image. Let's take a look. So instead of starting with these commands, we're just going to copy

2:04 Demonstrating Default Container Run Failure

2:11 the image name. And if we run over to a terminal and do a Docker container run dash rm dash it, and we run this without any other parameters, what we're telling Docker or any other container runtime to do is to pull this image and run everything by the default. This would be the entry point and command specified inside of the Docker file or the tool that we choose to generate it. When we run this for the Teleport container images, it's going to exit and tell us, Hey, there was no configuration. So the first major difference is in a

2:48 container environment, we must provide an explicit configuration. And we're going to take a look at how to generate that now also using the same container image. So the Teleport binary does ship with a configure command, which will print out a base configuration for us to use. However, we may also want to understand why this behavior is changed and we can actually inspect the container image to see what is going on underneath the hood. If we do a Docker image and specs passing in the image name, we'll be able to see all the metadata from this container

3:19 Docker Image Inspect

3:25 image manifest. The one that's important to us as the entry point and the command, because we want to know what the default actions are. Now let's just quickly jump to the command, which we can see is null. And then the entry point, which we can see they're using a package called dumbinit, which is an init system built for containers to run Teleport Star and a very explicit dash C pointing to a Teleport configuration. So we could bypass this behavior by overriding the entry point and calling our own Teleport Star, allowing the container image to generate that config

4:03 for us. And while this works, this is not really a great approach because that configuration is now inside of a running container and should this container restart or stopped, we are gonna lose it completely. So in a container environment, we definitely want to be able to pass in or mount a configuration file directly or even both build and ship your own custom images with that config. I'd probably refrain from the latter for a flexibility point of view, mentioned it at runtime, it's going to open up possibilities to migrating to Kubernetes, for example. So we're going to cancel this and not

4:58 use that approach. So let's take a look at modifying the command that we just ran. Well, this time instead of start, we're going to use that configure sub command I mentioned a moment ago. And now we have a base configuration that we can save locally for today's tutorial and use and tweak as we move forward with the exercises. So I have copied and pasted the config from the configure command and saved that locally as teleport. Yml. There is just going to make one change to this configuration and that is to remove the node name from lane two.

5:22 Saving and Modifying Configuration

5:36 This can be inferred by teleport at runtime from the host name of the container or machine that this is running on. Okay, so let's jump back over to the documentation. Now that we have our default configuration, we want to be able to run Teleport. We're going to copy this command to run Teleport and to Versus Code and make one or two modifications to get started. So something that has become a bit of a rule at Rawkode Academy is that we never ever name containers. This becomes a piece of global state that I am not really comfortable with in my

6:04 Understanding Volumes and Ports

6:16 environment, so I'm going to immediately discard name Teleport. We have two volumes being provided to the container, one for the state of Teleport, which is the environment Teleport and the other for the configuration that we need to inject into the system. We're going to modify these in just a second, but let me run over the other flags first. We have a few ports being exported or exposed, sorry, to the whole system. 3,080 is for the web UI, 3,025 is actually used for node communication, node SSH communication within the cluster. So if we wish to add other containers with other members, this

6:55 would be really important. And 3,023 is the actual SSH port required for clients to connect to the Teleport cluster. So let's come back to our volumes. I'm not a fan of using arbitrary directories in my home file system again, because I don't want any sort of global state and I include file system as part of that. So we're going to modify this to be PWD slash teleport. Yml and make this path rather explicit too. So this is going to pull through shell interpolation, my current working directory and the teleport. Yml available there. Now for the state within a teleport system, I don't

7:42 want to mount that to a local file system. So instead I'm going to use Docker volume, create teleport data. This gives me a named volume where a state can be persisted across container restarts and even recreations. We provide the named volume name and see that we wish to mount it to this location. I can now copy and paste all of these commands or both of these commands to my terminal. We'll see the volume as created and we should get a container running with the configuration that we need. Now we can verify that this is correct

8:18 Verifying Single Container Setup (Web UI)

8:18 by browsing to local host on port 3,080. So new tab, local host 3,080, add HTTPS. This is in Chrome, it's Firefox system, so we don't have to type this as unsafe. We can do advanced and accept. And we now have the Teleport UI ready for us to log in. Okay, so there is one more thing I'd like to cover in today's tutorial and that is using Docker Compose to provide a multi node configuration for Teleport, as well as I use to explore all the features available in the Teleport package. Let's jump back over to the code and

8:46 Using a Docker Compose To Provide a Multi-Node Configuration for Teleport

9:00 I'll show you the changes that I have made to allow this to happen. The first thing that I have done is create a Docker compose. Yaml file. I've defined a couple of volumes, one for the certificates to live in, which will be shared across all the nodes in the cluster and data, which will allow the Teleport server to store the state in a persistent manner. The first thing we configure is the Teleport server and you'll see this is very similar to what we did previously. We're using the Docker CLI. We mount our server configuration, our data volume and our certificates.

9:25 Configure Is the Teleport Server

9:38 Now, in order to make this a one command and up Docker compose environment, I have added a health check, which is going to periodically every two seconds run TCTL status. TCTL status will exit zero when the server is healthy and non zero when it is not. This allows us to have a dependency on node one and node two. These containers will only be started after the Teleport server is happy, which will limit and remove most of the error cases that you could see in such an environment. If we take a look at our Teleport server config, again, is very similar to what

10:10 Teleport Server Config

10:14 we've already been working with. However, I have added something called a token to the off service. Now this is just hard coded because this as a lab style environment and should never be deployed to production. But what it says is that we allow anyone with a static token of Rawkode Academy to authenticate against our server on a proxy and node basis. This allows other nodes to join if they have access to the static token. I have also generated a Teleport client configuration. This is very similar to the server one. However, we have the proxy service disabled,

10:41 A Teleport Client Configuration

10:50 the off service disabled. We've left SSH service on. We still want to be able to connect to the other nodes on the cluster. And I have now provided the hard coded token and authentication address for the server. So the off token is Rawkode Academy and off server is Teleport Dash Server on 03/2025. This is just the name of the service and the Docker Compose file. Now what should happen is I'm going to go to my terminal, run Docker Compose up, we should see the Teleport server start first, become healthy, and then the other two nodes

11:15 Starting the Docker Compose Environment

11:23 come online. Let's see what happens. So we can see the server is created first. We don't have any node yet. That's the server coming online and we can see the nodes, the different colors from the container log starting to show up, which gives me a pretty strong indication that this is now worked. But don't take my word for it, let's check. So we're going to jump over to here. We're going to do HTTPS localhost 3,080, and we get the web interface for our Teleport server. Now we haven't created a user yet, so we do need to jump over to our

12:13 Creating the Initial User

12:14 terminal. I'm going to have to do Docker container ls and I'm going to execute into our Teleport server, which is this one here. Container EXPC. We just want a shell. From here, I could do TCL users, add roles, admin, logins, root, and I'll add the Rawkode user. This is going to give me a link that I can copy and paste into my browser. I just need to remember to change the container ID to local host And now we can set a password. So let's just let one password to take care of this. Teleport lab, my username is Rawkode and save.

12:55 Activating User and Logging In

13:05 Now I can click on this and have it scan the QR code. And I also need to copy the password to here, my 2FA into here. And we have now created an account. So if I zoom in a little bit, I have tested this environment and the state has persisted into the data volume, which is why we have a few extra nodes and containers here. Whoops. But we can see that everything seems to be working as expected. And in fact, if we take a look at the container IDs, we have CC9 and 1B6, that I should be able to click on

13:31 Exploring Connected Nodes and Web SSH

13:54 connect and root. And I know inside of my container environment running a Teleport client as part of my Teleport lab environment. Nice and simple, this code will be published and a link will be in the description so you can use this Docker Compose web the configurations to try this out yourself starting now. Go have some fun. We'll be back with the server access workshop tomorrow. I'll see you all then. Have a great day.