If you look at the CNCF landscape, there are over 1,300 tools available. Whether you’re an engineer that’s new in the space or a 20-year VMWare engineer, you’re going to look at that landscape and think “this is a lot”. Because of that, when you’re deploying Kubernetes workloads to production, you need to choose the right tool for you. There are a lot of tools/platforms that do the same thing, but there’s always going to be a particular “niche” that will suit your environment more appropriately.
In the Portainer In Production blog series, you’re going to learn why Portainer would be a good choice for your environment when dealing with production workloads as an engineer that’s new to engineering in general or a seasoned engineer with little to no Kubernetes/container experience.
In the first blog, you’ll see how you can deploy workloads into production with and without Portainer so you can weigh the pros and cons along with the weight deployments will carry without Portainer.
Why Portainer For Production
Portainer is designed for many use cases, but the two primary cases are:
1. You’re an engineer that’s new to engineering and the cloud in general. You have a task
to deploy Kubernetes and containers, but the landscape is new to you and you need an
easy way to solve this task.
2. You’re an engineer with X amount of years of experience in the datacenter and you’re
tasked with deploying Kubernetes and containers, but the world of k8s and containers is
new to you and you need a simple way to solve the problem.
Portainer also works very well with seasoned k8s and container engineers, but the target focus is the engineers that are new to k8s and containers. The goal is to use Portainer as the “easy button” when it comes to k8s and containers.
As an engineer and consultant (speaking from my own personal experience), I’ve seen teams struggle for many months to get Kubernetes up and running properly. The primary reason is that they either lack the knowledge or they don’t have enough time to put into learning Kubernetes. Kubernetes and the entire k8s landscape is incredibly vast and you need to dedicate a lot of time to learning it. Otherwise, you’ll have a Kubernetes environment implementation project that sits for a long time. You can’t just log into the cloud, click a few buttons, deploy a Managed Kubernetes Service, and walk away. Often times Kubernetes is talked about as this magical environment that does all of the work for you, and it does do a lot of the work for you, but you have to understand how and why it’s doing it to implement it properly.
With Portainer, the goal is for engineers to not have to dedicate a ton of time learning Kubernetes. Do you need to understand Kubernetes and containerization prior to utilizing Portainer? Yes, absolutely. Do you need to go as in-depth with Kubernetes and containerization as you would without Portainer? No, not at all. That’s the goal of Portainer. To be your Kubernetes team.
The goal of Portainer is to make implementing Kubernetes for the non-expert more efficient. Its goal is to give everyone a chance to make Kubernetes work properly in production without being an expert.
Getting The App Ready
Now that you’ve learned the theory behind why you’d want to use Portainer, let’s dive into the hands-on piece of the blog post.
First things first, to utilize Kubernetes in Portainer, you need a containerized application. For the purposes of this blog series (this blog post and the three that follow), you’ll use the infamous Sock Shop stack. When finding a demo app to truly test Kubernetes, you want to ensure that it’s an app that deploys several workloads that you can manage individually to truly test the power of Kubernetes. Sock Shop is a perfect candidate for this.
To get the Sock Shop application, you can clone it from the GitHub repo (remember this link for later).
git clone https://github.com/microservices-demo/microservices-demo
Once the repo is cloned, change your current directory into the directory where the app exists.
You should now see files and directories similar to the screenshot below.
You can also take a look at the getting started docs here: https://microservices-demo.github.io/docs/quickstart.html
Deploying The App Manually
The Sock Shop app repo is now on your localhost and you’re ready to deploy. First, you’ll take a look at how you’d deploy the app manually. Then, you’ll see how to do it on Portainer.
Take a look at the Kubernetes directory which exists in microservices-demo → deploy. You’ll see several directories and files for various types of deployments, but the one you should focus on is the complete-demo.yaml. This Kubernetes Manifest deploys the entire Sock Shop application stack.
To deploy the application stack, ensure that you are in the Kubernetes directory and run the following command:
kubectl apply -f complete-demo.yaml
Check all of the Deployments in the sock-shop Namespace and you should now see that the application stack is in the process of getting up and running (it takes a few minutes as it’s a large stack).
The deployment seemed straightforward, right? Yes, it was, but there are several anti-patterns with this approach.
1. You deployed the application stack with kubectl, which is not a good practice as it’s
incredibly manual and it’s imperative, which goes against Kubernetes best practices. It
doesn’t seem like a big deal for one application stack, but imagine if you have five or ten.
2. The code for the application stack and the process of deployment is on your localhost.
That means other team members cannot follow the same approach and if they try, there
are bound to be misconfigurations and engineers deploying workloads differently, which
means there’s no unity in the deployment measures.
3. There’s no central location for other members of your team to see what’s running, how
it’s running, and the health of the stack. Every engineer will have to run a bunch of
kubectl commands just to get the information that should be accessible to every
engineer in the same location.
4. You had to manually clone the repository down to your localhost instead of deploying
from where the code exists, which is on GitHub. This may cause issues if the code is
changed or altered locally, which would mean no proper review of the code change has
Deploying in this fashion ensures that other team members cannot deploy in the same fashion and repeatable processes are not met.
Deploying The App With Portainer
Now that you’ve seen how to deploy without Portainer, let’s take a look at deploying with Portainer.
First, within your Kubernetes environment, click on the Applications pane and then click the blue + Create from manifest button. This will load up a screen that shows you how to start customizing your application stack deployment.
Next, choose the namespace that you want your application stack to be deployed to and the name of your stack.
Choose where you want to pull the application stack from. In this case, it’s coming from a Git repo and being deployed to Kubernetes.
The last step is to:
1. Put the Git repo where the code exists.
2. Choose the repository reference (see below screenshot).
3. The path to the complete-demo.yaml Kubernetes manifest.
Once complete, you’ll now see that the application stack is coming up on your Kubernetes environment.
Now that the application stack is deployed, you can monitor it, look at logs, and confirm any issues with your stack in a central location vs having to rely on the terminal across multiple engineer's environments.
Throughout the rest of this series, you’ll learn about some key features that Portainer can assist with which include:
1. Portainer and GitOps
2. Portainer and Service Mesh
3. Portainer and Pod Security
Try Portainer with 3 Nodes Free