Watch / Tutorial On demand
Overview

About this video

What You'll Learn

  1. Provision an AWS EKS cluster from Portainer with cloud credentials and a named environment
  2. Deploy the Google Cloud Platform microservices demo from a Git repository path
  3. Use Portainer's in-browser kubectl shell to inspect services and load balancer access

Provision an AWS EKS cluster from the Portainer UI, deploy the Google Cloud Platform microservices demo via a Git manifest, then hit the cluster with Portainer's in-browser kubectl shell, all in under ten minutes.

Chapters

Jump to a chapter

  1. 0:00 Portainer is TOO Easy
  2. 1:10 Creating an EKS Cluster
  3. 1:14 Portainer Setup and AWS Credentials
  4. 2:00 Provisioning an EKS Cluster with Portainer
  5. 3:47 Deploy with GitOps
  6. 3:49 EKS Cluster Ready & Environment Navigation
  7. 4:03 Deploying Application via GitOps Manifest
  8. 6:15 Verifying Deployment & Exploring Application Details
  9. 6:16 Access with kubectl
  10. 7:17 CLI Access and User Management
  11. 8:47 Closing
Transcript

Full transcript

Generated from the English captions. Timestamps jump the player to that moment.

Read the full transcript

0:00 Portainer is TOO Easy

0:00 It's been a while since we did a Portainer video and there is a terrible reason for that. Portainer asked me to make videos showing people how to operate Portainer in production. I've done a few videos, but ultimately I came to the same conclusion over and over again. Nothing is hard with Portainer. It's all too damn easy. Portainer has this very annoying habit of taking complicated, cumbersome, complex tasks and making them trivial. Point, click, done. So with that in mind, we're changing tact. In this video, I'm going to take what is traditionally a complicated and cumbersome and complex

0:51 task and show how Portainer makes it easy. So let's deploy in your EKS cluster on AWS and get our application running with a GitOps pipeline all in under ten minutes. Let's go. Okay. So the first thing you're going to need is obviously a Portainer running. Here I am running the Portainer business edition which is free for anything up to three node. I have also configured some production credentials. I've done this in advance because I don't really want to show you any AWS credentials on this video. But you can see here, we have the provider configured as AWS.

1:14 Portainer Setup and AWS Credentials

1:39 I've just called it production and we've added an access key ID and our secret access key. To add these you just say add credentials, fly to Amazon and fill in the form. And keeping with Portainer, it's pretty simple. From here we can go to the Portainer home screen. Now you can see here we only have a local environment, that is the Docker engine that this Portainer instance is running on. We want to add a new environment. So let's click on environment and add. From here, could say that we wish to provision a Kubernetes cluster. We select our cloud provider

2:00 Provisioning an EKS Cluster with Portainer

2:30 and give our cluster a name. Here I will call it Rawkode test. You can then set the region you wish to deploy it to. As I'm in Scotland, I'll choose London down in England. Next you can change your AMI type, the instance size, your disks, the number of nodes and even the Kubernetes version. None of this is particularly important for today's video. So we're just gonna go straight ahead and click revision. Now let's go back to our environment page where we'll see that our agent is now provisioning an AWS EKS cluster. Now while Portainer does amazing things at taking

3:36 complicated complex tasks and making them trivial or easy, it cannot speed up the provision of an EKS cluster. So we'll be back with some movie magic in just a moment. Alright. The dance has been danced, and we have the Rawkode test AWS EKS Kubernetes cluster running. Let's get our application deployed. To do this we can just jump back home and set the Rawkode test environment as our current environment. This opens up all of Portainer's Kubernetes tools including browsing the namespaces and resources within a cluster. Here we can see the default namespace. Now this is a new cluster with nothing

4:03 Deploying Application via GitOps Manifest

4:24 installed so we're not going to see too much. So let's click on applications and create our manifest. From here we can add a GitHub URL or any Git repository URL. Here I'm going to deploy the Google Cloud Platform microservice demo. Next, we can specify the path to the gamma we wish to apply. Which in this case is release Kubernetes manifest and you can see Portainer is now auto completing the path from the repository. And that's it. We go back to the top, call this microservice demo, and hit deploy. Portainer is now cloning this repository and applying our manifest from the release directory

5:46 to the cluster. And as you can see it's discovered the ad service, cart service and so forth, all of the microservice examples from this repository. Now currently it says replicated zero of one but if we give that a few minutes for the cluster to pull the images and get these replica sets and pods running, we will start to see green and one zero one across the board. Like so. So now that we have our application deployed, we probably want to check that it worked. Now we can see all the applications here including our front end.

6:16 Access with kubectl

6:28 From here we can see that it's in the default namespace, it has an internal service with a cluster IP and an external load balancer type service with external access. We can see the environment variables passed in to this pod. We can also see the events to see if the pods have been restarted or if anything is wrong fetch the log. Or in the event that something goes wrong, jump to application and ask for the logs. But maybe your developers don't always want to access the UI. Perhaps you want to use the CLI and that's okay too.

7:17 CLI Access and User Management

7:21 WebProtainer you have the choice. Now typically what you could do is generate a KubeConfig and give it to someone in your team but then you have to worry about them sharing that KubeConfig or getting the AWS IAM authenticator or the recent version of the AWS CLI in order to be able to authenticate and they also need to have AWS access blah blah blah blah blah. Giving people access to your cluster isn't really that easy to do well, but we have Portainer. It has user management. We could invite our entire team and even configure SSO. Check out the video in the course for

7:59 that. So if you want to hook in to that I'm policy in our back then the developers or anyone you wish can just use the cube control shell button. I click this and right in my browser, I can run kubectl commands. I can now see all of my services including the host name to access our load balancer service and there we go this is the Google microservice demo running on EKS provisioned by Portainer. Your life made easier. So there you have it. While I couldn't make the video Portainer wanted me to make because they just make things

8:47 Closing

8:53 too simple, I hopefully showed you how Portainer can simplify other things too. We all need Kubernetes clusters. Hopefully, you're using a managed provider. Portainer gives you a simple interface to spin up those clusters on demand. We can then set up GitOps pipelines either manually like I did or using Edge stacks. Check out the video in this course to see how you can automate the rollout of your application to one or many clusters using Portainer. The convenience of the UI is there if you want it and the CLI is just a click away too. Portainer is a fantastic tool.

9:37 I hope you found this video useful. Until next time. Have a great day.

Technologies featured

Weekly Cloud Native insights

Stay ahead in cloud native

Tutorials, deep dives, and curated events. No fluff.

Comments, transcript, and resources

More about Portainer

View all 7 videos
Kubernetes

More about Kubernetes

View all 172 videos