Forem: Okteto

Container Orchestration and Kubernetes

Arsh Sharma — Mon, 19 Dec 2022 07:28:47 +0000

Containers quickly became the norm for how we built and packaged our applications. They made the software delivery and development cycle easy by providing a convenient way to run applications anywhere - without having to worry about setting the environment up from scratch every time. But, to run our containerized applications in production, we still needed to solve a few pieces of the puzzle.

Running Containers in Production

Since we shifted to a microservices based architecture, we started having a separate container for each microservice. But containers are meant to be ephemeral, and things can and do go wrong in production. This can lead to containers going down unexpectedly. And this is just one of the many problems associated with running containers in production. Long story short, we couldn’t just run containers directly to serve our applications. We needed something to manage these running containers - a container orchestrator.

Managing a few containers to serve your application might still be possible with manual effort, but to run containers at scale, we needed some way to automate all the operational tasks associated with container management. Container orchestrators take care of all this. They are responsible for managing the complete container lifecycle and ensuring your applications are always up and running for users to access. They remove the manual effort of monitoring and managing containers by automating the whole process. Some of the tasks they generally take care of are:

Deploying containers with the correct application images
Monitoring provisioned containers and checking if they are healthy
Scaling up or down the number of containers based on the application traffic
Balancing load between different running containers

When it came to container orchestrators, two prominent names appeared: Docker Swarm and Kubernetes. Let’s see how they differ and which one might be ideal for your use case.

Docker Swarm vs Kubernetes

Both Docker Swarm and Kubernetes can help you orchestrate your containers. Deciding between the two primarily depends on your use case. Docker Swarm is an easy to set up and maintain solution when you want to manage simple workloads. It has a lower learning curve and is lightweight. If you have a relatively simple application and don’t have the time to invest in a complex solution, Docker Swarm might be the better choice for you. Kubernetes, on the other hand, offers a lot more features and should be the choice if you want to run complex workloads at scale effectively. It has a lot larger open source community than Docker Swarm and is offered by all the major cloud providers. It also has a vast ecosystem of tools built around it which extend its capabilities and make it the ideal choice for enterprises managing their microservices based applications. But the problem with Kubernetes is that it can be tough to learn and set up when getting started initially.

If you’re looking to get started with Kubernetes, check out our Kubernetes for Beginners blog to get learning!

Migrating your existing applications and development workflows to containers running on Kubernetes can be a tough task. If you’re struggling with that, Okteto can help make the migration easy and simplify how you develop cloud native applications! Reach out to us to talk more :)

How Kubernetes Works As Container Orchestrator

Now that you have an idea of what a container orchestrator is, you might be wondering how exactly do they work. Let’s understand this by taking the example of Kubernetes. K8s works on a declarative system to manage your containerized applications. You tell it how you want things configured by writing a YAML file, and then it will work towards bringing up all the required containers and other needed things.

Then it also continuously monitors the resources it has created and checks that they still match the state we had described in the configuration file. If that’s not the case, it takes the necessary actions required to get to that state. This is how K8s functions as a container orchestrator and avoids application downtime.

Now that you recognize the usefullness of Kubernetes and will be using it to deliver, deploy, and run containers, give Okteto a try and immediately get the development environment to the K8s level and save development time and resources!

Developing Containerized Applications With Okteto

Kubernetes has become the go-to tool for running containers at scale. It has changed how we deploy our applications. But the development of these microservices based applications has still been an area that is lacking behind. Mainly because we’ve been using the same old tools for development that we used before containers came into the picture. Okteto simplifies the development of containerized applications by allowing you to write code in an environment that is exactly like production. This is done by leveraging Kubernetes during development as well! Check out our Getting Started Guide and learn how to simplify the development of your containerized applications.

Kubernetes Cheat Sheet: Must-Know Commands and Examples

Arsh Sharma — Mon, 05 Dec 2022 13:00:07 +0000

Things can be overwhelming when you are new to Kubernetes. You’d think that understanding all the different objects Kubernetes has to offer would be the end of it. But no, when it comes to actually interacting with K8s clusters, things get even more confusing for beginners.

Introduction to kubectl

The most common tool to interact with a Kubernetes cluster is kubectl. This allows you to interact with the objects you create, view logs, etc. But as anyone who’s just starting to learn K8s will agree, THERE ARE JUST TOO MANY KUBECTL COMMANDS TO KEEP TRACK OF!

But don’t worry; this blog is going to be my attempt to simplify things. We’ll go over the most common commands you’d find yourself using throughout your K8s journey. Here’s a meme to ease you in before getting started.

Also, if you’re completely new to Kubernetes, you might want to check out our Kubernetes for Beginners blog before proceeding!

Cluster Info and Configuration

Often you need to get information, not about the application but the cluster itself. Here are a few commands which help with that:

kubectl version: Gives information about what version of Kubernetes the client and server are on.
kubectl cluster-info: Displays the endpoint of the Kubernetes control plane.
kubectl config get-contexts: Lists all the contexts present in the current kubeconfig.
kubectl config use-context <context name>: Allows you to set the default context for all the kubectl commands you’ll run.

Namespaces

Namespaces play a very important role in clusters. They act as a way to organize and isolate the different resources your application might need. By default, you’re in the default namespace (surprise, surprise!), and the resources Kubernetes needs for its functioning are in the kube-system namespace. Here are some other commands related to namespaces you’ll find yourself using frequently:

kubectl get namespaces: Often, you’ll find that you’ve lost track of all the namespaces you’ve created. This command will help you out by listing them all.
kubectl create namespace <namespace name>: This command would create a new namespace for you. Note that it will not set that namespace as the default one, though. So all resources you create will still be created in the default namespace unless you specify the --namespace flag explicitly.
kubectl config set-context --current --namespace=<namespace name>: This allows you to change the default namespace for all the commands you’ll run while still keeping the same context. Just remember that the default namespace is called default in case you ever want to switch back.
kubectl delete namespace <namespace name>: This deletes the specified namespace and all resources under the namespace! The deletion of resources is an asynchronous process, so don’t be surprised if you see your namespace in the “Terminating” state for a while before it’s completely gone.

Pods, Deployments, Secrets, etc

Now there is a certain set of commands which you’ll find yourself using a lot when interacting with most of the Kubernetes resources. Just put in the resource name instead of X, and you should be good to go with these:

kubectl get X: Lists all resources of that particular type in the current namespace.
kubectl create X <name> <other properties>: Creates the “X” resource in the current namespace with the specified name. In most cases, you would have to specify some additional flags to actually create that particular resource.
kubectl delete X <name>: Deletes the “X” resource with the given name in the current namespace.
kubectl describe X <name>: You’ll find yourself using this one a lot when debugging things. This provides details and events related to the resource you specify.
kubectl edit X <name>: This command will allow you to edit the specified resource directly without having to deal with any YAML. Remember to make the changes to your YAMLs once you’re satisfied with your edits because the edits don’t persist once the resource gets deleted!

Nodes

Nodes are what build your cluster, so it’s no surprise that you’ll often find yourself interacting with them. The following commands are worth keeping a note of:

kubectl get nodes: Shows a list of all the nodes along with their role (control-plane, worker, etc.) and the version of K8s they are running.
kubectl top node <node name>: Shows the CPU and memory usage of the specified node.
kubectl cordon/uncordon node <node name>: Cordoning nodes means marking them as unschedulable; that is, no pods will be placed on that particular node. This is useful when you want to isolate a node for something like updating its version or debugging.
kubectl drain node <node name>: You’ll find yourself using this command when doing maintenance tasks for your cluster. Draining a node, cordons it as well, and deletes all pods running on it. If those pods are being managed by a Deployment, DaemonSet, etc., they will be recreated on the remaining nodes.

Other Common Commands

These are some commands which don’t exactly fit into any single category, but you’ll find yourself using them a lot.

kubectl apply -f <filename.yaml>: If you’re creating K8s resources using YAML files, then this is the command you should be using to apply those YAMLs. If the resource specified in the YAML already exists, then this command would update that resource with the latest configuration specified in the YAML file.
kubectl delete -f <filename.yaml>: This command deletes all the resources specified in the particular YAML file.
kubectl port-forward <pod name> <local port>:<remote port>: Relying on services to expose your application to external traffic isn’t always convenient, especially when you’re debugging. The port-forward subcommand provides you with a simple way to do this by letting you forward a local port to a specified port in the mentioned pod.
kubectl logs : This is a very useful command for debugging your deployed application. This command prints the logs for the container running in the specified pod. If your pod is running more than one container, you can additionally specify the --container flag to mention which container’s logs you want to see.

Abstract Away the Complexities of Kubernetes From Developers

While we discussed some common commands you’d find yourself using when working with K8s, I believe that it is not developers who should be taking care of these K8s related tasks. Having developers deal with the infrastructure and deployment side of things during the development process takes a massive hit on productivity and also leads to a poor developer experience. With Okteto, you can define all the things you need to spin up your dev environment in a YAML and have developers skip right to the code-writing phase by running just one single command. Try our Getting Started Guide to see the magic for yourself!

Beginner’s Guide to Network Policies in Kubernetes

Arsh Sharma — Mon, 28 Nov 2022 14:55:20 +0000

Everyone agrees that Kubernetes clusters are not secure by default. But the good thing is that Kubernetes gives you the tools to make it so. In this article, we’re going to learn about one of such resources K8s provides right out of the box to make your deployed applications a bit more secure: Network Policies.

If you’re completely new to Kubernetes, I would recommend you go through our Kubernetes Basics tutorial first before proceeding with this!

Why Network Policies Are Important

When learning about something new, I often find it easier to understand if I start with learning the “why” it was needed, even before knowing “what” it actually is. Let’s do the same with Network Policies, and I’m sure you’ll have a much easier time understanding them! :)

By default, Kubernetes allows traffic from all pods to reach all other pods. But this isn’t something you’d want in production. Why? Because this way, if a pod gets compromised, it will be able to affect other pods and potentially compromise the security of your entire application. Network Policies provide a way to restrict traffic in your cluster so that only legitimate traffic can flow - where the term “legitimate traffic” is for you to decide based on your application.

For example, if you’ve deployed a full-stack application by default, the frontend pods will be able to communicate with the backend as well as the database pods. But we know that the frontend pods don’t actually need to talk to the database pods directly.

In this scenario, it would be ideal for us to leverage Network Policies to allow traffic from the frontend pods only to the backend pods. This way, even if the frontend pods get compromised, we can be sure that our database won’t be affected!

Now that you have an understanding of what utility Network Policies serve let’s start learning about them in more detail.

What Exactly Are Network Policies

Network Policies are a resource in Kubernetes responsible for controlling traffic to and from pods running in a cluster. With Network Policies, you select pods using labels and then specify rules for these selected pods. You can utilize a combination of the following three to precisely control traffic:

Other pods: You can select other pods using labels that should be allowed to talk to the selected pods.

Namespaces: You can select complete namespaces as well. In this case, all pods in the namespace would be able to communicate with the selected pods.

IP blocks: You can specify CIDR ranges from or to which traffic is allowed for the selected pods.

The NetworkPolicy Resource

Let’s look at a sample NetworkPolicy resource and then understand all the fields in a bit more detail. Warning: things aren’t as scary as they might look at first glance! :P

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sample-network-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              project: firstproject
        - podSelector:
            matchLabels:
              role: client
      ports:
        - protocol: TCP
          port: 4614
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              project: secondproject
      ports:
        - protocol: TCP
          port: 1010

Like most other K8s resources, the NetworkPolicyresource also has the usual apiVersion, kind, metadata, and spec fields. The spec field is where things get interesting! You’ll mostly see the following things under this field:

podSelector

This is where we select the pods we want the policy to get applied to.

policyType

NetworkPolicies have two types: Ingress and Egress. A NetworkPolicy resource can be of any of the two types (or even both!). Ingress refers to the traffic entering the pods we select under the podSelector, whereas Egress refers to the traffic leaving the pods. The policyType field indicates whether we will specify ingress rules or egress rules, or both for the pods we’ve selected in our NetworkPolicy resource.

ingress

This is where we list rules for what traffic is allowed to enter the selected pods. All the listed rules get ORed.

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: firstproject
    - podSelector:
        matchLabels:
          role: client

The above section in a network policy would allow traffic to the selected pods:

from all pods in the namespace with the label "project: firstproject" and,
from all pods with the label "role: client" regardless of which namespace they are present in.

In case you wanted a combination of both of these rules, your ingress section would look something like this:

ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          project: firstproject
      podSelector:
        matchLabels:
          role: client

Now, this would allow traffic only from pods with the “role: client” label present in the namespace with the “project: firstproject” label.

The selection capabilities are quite powerful, no?

The ports section simply specifies the ports on which the selected traffic is allowed.

egress

Similar to ingress in terms of selecting things, the only difference being that this is where we select where traffic is allowed to go from our selected pods.

egress:
    - to:
        - namespaceSelector:
            matchLabels:
              project: secondproject

So in the above example, the selected pods are allowed to send traffic to all pods in the namespace with the label “project: secondproject”. The selection rules for egress get ANDed and ORed, similar to ingress rules. The portssection, too, like in the case of ingress, specifies what ports the rules are valid on.

Now that you have a general idea of what a NetworkPolicy does and looks like let’s see things in action!

Working With Network Policies

We’ll keep things simple in this section but, at the same time, ensure that you’re able to understand Network Policies in detail. We’ll work with two pods: frontend and backend, and test the connectivity between them before and after creating some Network Policies.

Let’s first create both our pods:

$ kubectl run frontend --image=nginx
$ kubectl run backend --image=nginx

Next, let’s just expose both these pods by creating cluster internal services so that its easier for us to check the connectivity between them:

$ kubectl expose pod frontend --port 80
$ kubectl expose pod backend --port 80

Confirm that everything is working as expected by running kubectl get all:

NAME           READY   STATUS    RESTARTS   AGE
pod/backend    1/1     Running   0          3m10s
pod/frontend   1/1     Running   0          3m18s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
service/backend      ClusterIP   10.120.37.122   <none>        80/TCP    67s
service/frontend     ClusterIP   10.120.39.94    <none>        80/TCP    72s
service/kubernetes   ClusterIP   10.120.32.1     <none>        443/TCP   257d

Now, if you remember, at the start, I mentioned that by default, all pods in K8s are allowed to interact with each other. Let’s confirm this by trying to ping the backend pod, using the cluster IP of its service, from the frontend pod by running the exec command:

$ kubectl exec frontend -- curl 10.120.37.122

You should get the following output:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="<http://nginx.org/>">nginx.org</a>.<br/>
Commercial support is available at
<a href="<http://nginx.com/>">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

We see the HTML output for the NGINX starter page, which confirms that we were successfully able to ping the backend pod.

You can also try this the other way around as well by running:

$ kubectl exec backend -- curl 10.120.39.94

Let’s now create a very common policy called “Default deny”. Once this is created, it will restrict ALL traffic for ALL pods in your cluster. This is a very convenient and common way to begin thinking about networking rules in your cluster. You begin by stopping all traffic and then create more network policies only for the traffic you want to allow.

Create the following default deny policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Specifying {} for podSelectors selects all pods and not writing an ingress or egress section while mentioning them both under policyTypes blocks all traffic.

Try running the kubectl execcommands we ran before now. You’ll notice that it doesn’t show the HTML and just keeps loading. This is because of the Network Policy that we just created!

Now let’s make sure our frontend pod is able to communicate with the backend pod. For this, we would need to create two rules:

One egress rule which allows outgoing traffic from the frontend to the backend
One ingress rule which allows incoming to the backend from the frontend

The following policy will select the frontend pods and allow outgoing traffic from them to reach the backend pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      run: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              run: backend

Try rerunning the following command to test if things are working or not:

$ kubectl exec frontend -- curl 10.120.37.122

You’ll notice that it still doesn’t work. And that’s expected! Right now, we’ve only created a policy that allows traffic to leave from the frontend pods to the backend pods. The backend pods still need an ingress rule to allow incoming traffic from the frontend pods. Let’s create another policy to achieve this:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      run: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              run: frontend

Once you’ve created both of these policies, try pinging the backend pods again, and it should work! You can also try pinging the frontend pods from the backend ones and confirm that it still does not work because of our default deny policy.

Wrap Up

I think you can now start to appreciate how Network Policies can play a crucial role in helping you ship secure applications. We learned why Network Policies are needed and how they work and then saw them in action. If there is one piece of advice I want to leave you with before concluding, it's that when managing traffic in your clusters, it is best to only allow the required traffic and block everything else!

Okteto allows developers to work on their applications in a production-like environment. This means you can use Kubernetes resources like Network Policies right during the development phase. This allows developers to be sure that the code they write is secure and won’t break in production. Check out our Getting Started guide to learn more!

Beginner’s Guide to Kubernetes Deployments

Arsh Sharma — Thu, 22 Sep 2022 08:19:39 +0000

Over the last five years, Kubernetes has seen rapid adoption as a container orchestrator. And for a good reason too. Containers solved the problem of being unable to run applications easily on different environments and systems. But there were a lot of problems when running containers at scale:

How do you ensure a minimum number of containers are always running?
What happens when a container goes down?
How do you update your application without any downtime?

Kubernetes solved all these and many more problems for us. But its architecture has always been an object of mystery when looked at from far. How is it managing all these containers for us? What inputs does it need from us to do this? All of this can be scary if you haven’t gotten the basics of Kubernetes right. In this article, we will focus on one of the basic objects it has to offer: Deployments.

A Bit About Pods First

Learning about Deployments directly before knowing about Pods is like learning to read without knowing the alphabet. We won’t go into much detail about pods here, but I’ll cover enough so the rest of the article makes sense.

Pods are the most fundamental unit in the K8s world. The simplest way to understand pods without getting confused is to think of them as a wrapper for containers. Kubernetes doesn’t run containers directly. Instead, it runs Pods, where we specify which containers we want to run. Another thing to remember about pods, which we’ll get back to later, is that in the K8s world, pods are meant to be ephemeral: a single pod runs a single instance of your application, and that’s all there is to it. A running pod is only responsible for ensuring an instance of your application is running.

Kubernetes vs Docker Deployments

When we talk of Deployments in Kubernetes, it is very different from what we mean when we refer to deploying your application using just Docker. This is why I wanted to have a separate section to clarify the difference, so you don’t get confused.

When we talk about deploying using Docker, we usually mean the process of building container images from our Dockerfiles, pushing them to a registry, and then running our application containers.

In the world of Kubernetes, however, Deployments are an object. As per the official documentation:

A Kubernetes object is a "record of intent"--once you create the object, the Kubernetes system will constantly work to ensure that object exists.

These objects are accompanied by controllers. So for the Deployment object, there is a Deployment controller. The controllers ensure that the object's current state matches the desired state we specified.

Deployments in Kubernetes

So now we know two things: Pods are the fundamental unit in the world of K8s, and Deployments are a type of Kubernetes object. With this, we’re ready to understand the Deployment object in more detail. Let’s consider the following scenario:

You run a bunch of pods to serve your application to the users. Now let’s say there’s a sudden increase in traffic, and your pods start running out of resources. What should Kubernetes do in this case? If you recall, I mentioned that Pods only have the single function of running your application. They alone can’t bring up more pods if existing pods run out of resources.

To help manage pods, we need another Kubernetes object. And that’s where Deployments kick in. Instead of creating individual pods to serve our application, we create a Deployment object. The Deployment controller is then responsible for the management of these pods. All we have to do is create our Deployment object, and then the controller will handle the task of making sure that our specified number of pods is always running. What’s more, is that it also allows us to do other useful things like scale the number of pods, update the version of our application (without any downtime!), and even roll back to a previous app version if we discover a bug. We’ll soon see all of these in action. But let’s now learn how we can create them.

Creating a Deployment

I'll assume you have a K8s cluster ready to work with. If this is your first time interacting with Kubernetes, I will recommend you read our Beginners’ Guide to Kubernetes before continuing with this.

Let us look at what the YAML for a typical Deployment object would look like:

# nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Looking at the spec section, you’ll notice we have a property called replicas. This refers to the number of pods we want our Deployment to run. The Deployment controller will continuously check if these many pods are up and running at any given time. If that’s not the case, it will work towards reaching this number by creating more pods or deleting existing ones.

Then under the selector, we specify the labels of the pods for the Deployment controller. This is so that it knows which pods it is supposed to manage. Let’s say in our Deployment object, we specify that we want three replicas, but two pods with the label app: nginx already exist before we create the object. In this case, the controller will only create one additional pod for us. Had we not specified any labels, then the controller wouldn’t have been able to identify that two of the needed pods were already running.

The template section is nothing but a Pod template's metadata and specification section. The metadata section lets the Deployment controller know what labels to attach to any new pods it creates, and the spec section has information about the containers which would run in the pod.

You can create this Deployment just like you would any other object by using the kubectl apply command:

kubectl apply -f nginx-deployment.yaml

After creating the Deployment, if you now look at all the objects in our K8s cluster by running:

kubectl get all

you’ll notice that we not only have the Deployment, but we also see the three pods which the Deployment created for us!


NAME                                   READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-877f48f6d-2zp4p   1/1     Running   0          15s
pod/nginx-deployment-877f48f6d-8tf9g   1/1     Running   0          15s
pod/nginx-deployment-877f48f6d-ptgz8   1/1     Running   0          15s

NAME                 TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
service/kubernetes   ClusterIP   10.120.32.1     <none>        443/TCP     223d

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nginx-deployment   3/3     3            3           16s

NAME                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/nginx-deployment-877f48f6d   3         3         3       16s

Performing Rolling Updates

Let’s say you updated your container image and now want all your pods serving your application using the new image. If you were to manually delete and recreate them, you would face downtime. To avoid this, Kubernetes supports something called Rolling Updates. Rolling updates are the default strategy K8s uses whenever you make any updates to your Deployment. When doing a Rolling update, K8s doesn’t bring down all the pods at once and then bring up all the new ones. Instead, it brings down some pods, then brings up some, and then repeats this process until all old pods have been replaced. This ensures that there are always pods available serving the application to the users.

Let’s see this in action by changing the image used in our nginx deployment:

kubectl set image deployment nginx-deployment nginx=nginx:1.19.10

To see the rollout process in action as it proceeds, run:

kubectl rollout status deployment nginx-deployment

When you do this, you’ll notice exactly what I described taking place in the logs:

Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx-deployment" rollout to finish: 1 old replicas are pending termination...
deployment "nginx-deployment" successfully rolled out

Rolling Back Deployments

Now let’s say we realize there’s a bug in the latest container image we just updated nginx to. In this case, we would ideally like to return to the last version of our deployment, which we knew was working. K8s allows us to do exactly that using the undo subcommand.

If you run:

kubectl rollout history deployment nginx-deployment

you should be able to see all the updates we made to our Deployment. We can go back to any previous version (in the case the first one) by running:

kubectl rollout undo deployment nginx-deployment --to-revision=1

Like with Rolling Updates, when rolling back, Kubernetes will ensure that all the pods aren’t brought down all at once to avoid downtime.

Scaling Deployments

The number of pods we mention in the replicassection of our Deployment can be updated. This is very useful when we want the number of pods to be changed based on the load. If at some point, there are a lot of users trying to access our application, we would obviously want more pods so there is no overload.

Let’s say we want Kubernetes to increase the number of pods for our deployment if the CPU load of the node exceeds 80%. But we still want the max number of pods it scales up to to be 7. The autoscalesubcommand helps us achieve exactly that:

kubectl autoscale deployment nginx-deployment --min=3 --max=7 --cpu-percent=80

Based on this, when the load decreases to less than 80%, it will also automatically start scaling down the number of pods until there are just three running pods.

I hope you found this introduction to Kubernetes Deployments useful. There is much more to Deployments, but this should be enough to get you started!

Services and Ingresses in Kubernetes

Arsh Sharma — Thu, 17 Feb 2022 15:05:26 +0000

Before starting this post, I want to congratulate you all for making it till here! Kubernetes is intimidating, especially if you come from a developer background. The fact that you were able to understand the concepts we talked about in the previous articles is a huge feat. Wrapping your head around so many Kubernetes objects is no easy deal!

In the last post we looked at configuration and storage in Kubernetes. We saw how Secrets help provide sensitive configuration data to our app and how Persistent Volumes can be used to make sure we don’t lose our data in case some Pods crash. In the final post of this series, we’re going to take a look at how networking works in Kubernetes.

We will see how we can expose Pods running our application using the Service object. This would help us ensure that different parts of our application (backend, frontend, etc) are able to communicate with each other within the cluster. Then we will see how we can ease external access to our application by setting up routing using the Ingress object. Lots to cover in this one, so let’s begin!

Services

To understand Services, let’s look at what problem they solve. If you recall our discussion of Deployments you’ll remember that deployments create and manage multiple pods for us.

So we would have a deployment for the frontend of our application which would manage multiple pods running our containerized frontend code. Now this code would need to interact with the backend pods. But how does it do that? What IP address should it ping? It clearly can’t be the IP address of a particular backend pod because we know pods are ephemeral so we can’t rely on their IP addresses.

This is where Services come into the picture. Services allow us to send traffic to Pods that match the labels we specify when creating the Service. Let us look at the YAML for a simple service to understand things better:

apiVersion: v1
kind: Service
metadata:
  name: database-service
spec:
  selector:
    app: database
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

The above YAML should be pretty easy to understand - it creates a Service that will route all traffic to Pods that have the label app: database on them. Coming to the ports section which might not be so obvious, we specify a port and a targetPort. targetPort is the port on which the selected pods will be listening. The Service will send requests to the Pods on this particular port. port, on the other hand, is simply the port within the cluster on which we want the Service to be exposed. This is needed because we might have different services in our cluster, which we would then expose on different ports. Another thing worth mentioning is that while TCP is the default network protocol for services in Kubernetes, you can use any of the following instead too.

So far, so good, right? Looking at the movies app we deployed on Okteto Cloud, we have a service created which is exposing the database for our backend pods to talk to. You can confirm that this Service exists by running:

kubectl get services

To see what the YAML for this Service looks like, you can run:

kubectl get service mongodb -o yaml

You’ll see that we have specified 3940 as the value of the port, which is arbitrarily chosen. For the targetPort, we specify 27017 because that is the default port a MongoDB database listens on.

Now, if you look at the backend code you’ll see that we use the name of this Service, which is mongodb, to connect to the database. The url used to connect to the database is:

const url = `mongodb://${process.env.MONGODB_USERNAME}:${encodeURIComponent(process.env.MONGODB_PASSWORD)}@${process.env.MONGODB_HOST}:3940/${process.env.MONGODB_DATABASE}`;

It is using the MONGODB_HOST environment variable, which is set to the name of the Service, that is, mongodb. After that, we also specify the port which we arbitrarily chose when creating our Service (3940).

And voila! This is all the K8s magic we need in order to make different microservices in our application talk to each other. Let’s now take our discussion further and see how we can route incoming traffic to various services.

Ingresses

So you’ve containerized your application, you’ve set up your Deployments and configured Services to enable communication between parts of your application, but what’s next? If your application is deployed on a cloud provider, you would set up a load balancer pointing to your services. The load balancer would provide you with a static IP address accessible from outside the cluster.

But is it cost-effective and manageable to set up different load balancers for each of your services? This is where Ingresses come to the rescue. Think of an Ingress object as a sort of signboard for vehicles at a cross-section of roads.

The roads in this metaphor are different services in our cluster and the vehicles are the requests coming to our cluster. An Ingress object we create will tell the incoming requests to the cluster which Service they should go to. Ingresses don’t enable external access to our app by themselves, but they make it easy. You would now just need one load balancer from your cloud provider, which would point to the Ingress, and then the Ingress will take care of handling the routing of all incoming traffic.

Let’s see what the Ingress object for our movies app looks like by running:

kubectl get ingress movies -o yaml

The output you get should look something like this:

spec:
  rules:
  - host: movies-rinkiyakedad.cloud.okteto.net
    http:
      paths:
      - backend:
          service:
            name: frontend
            port:
              number: 80
        path: /
        pathType: Prefix
      - backend:
          service:
            name: api
            port:
              number: 8080
        path: /api
        pathType: Prefix

You’ll see that under the spec section, we set up two paths for different services in our application which we wanted to expose: the frontend service and the backend service. So requests sent to our cluster at /api will be redirected to the backend service, which further directs them to the backend pods serving our application. All other requests will be redirected to the frontend pods via the frontend service. This simplifies the management of different routes significantly when compared to the traditional way of doing this - setting up an NGINX proxy per application. Very convenient, right? :)

To sum our discussion up, Ingress isn’t something complicated - it’s just a Kubernetes object which allows us to specify routing rules!

However, there is another part to Ingresses that we didn’t touch in this article. The K8s objects we’ve seen so far (Pods, Deployments, etc) come with their controllers preinstalled in the cluster. This is not true for Ingresses. To create an Ingress object, you will need your cluster admin to install an ingress controller in your cluster. I won’t be covering how to do that since as developers we rarely have to do it ourselves. If you’re using Okteto Cloud, the cluster provided to you would already have an Ingress controller installed :)

Well, that wraps up our discussion for this article. We learned that different microservices in our application can talk to each other with the help of the Service K8s object. Then we went ahead and looked at Ingresses, which allow us to route incoming traffic to our cluster to the different Services which we’ve created.

I hope this discussion not only enables you to learn more about this topic but also sparks your curiosity enough so you go give things a try yourself. A very easy way to tinker with all this could be to fork the movies app, edit the YAMLs and deploy on Okteto Cloud using a single click!

This post also concludes our Kubernetes for Developer series. There will, however, be one final brief post to wrap things up and point you to resources that would be helpful for you on your Kubernetes journey ahead. Until then, happy hacking! 😄

The "Kubernetes for Developers" blog series has now concluded, and you can find all the posts in this series here.

Configuration and Storage in Kubernetes

Arsh Sharma — Thu, 10 Feb 2022 15:11:09 +0000

Hello fellow developers! By this point in the series, I hope you’re now much less scared of Kubernetes. So far we’ve explored its architecture, some essential K8s objects, and even deployed an app on a Kubernetes cluster using Okteto! Pat yourselves on the back for making it till here :)

In this article, we’ll first look at two somewhat similar Kubernetes objects which help with providing configuration to our application running in the cluster - ConfigMaps and Secrets. Then we’ll move on to look at how storage is handled in Kubernetes using Volumes and Persistent Volumes. So strap on and let’s get started!

ConfigMaps and Secrets

To inject configuration data into a container, Kubernetes provides us with two objects: ConfigMaps and Secrets. It is highly recommended to separate configuration data from your application code so you’ll see these two objects being used in almost all Kubernetes clusters.

If you see the YAML for a ConfigMap or a Secret you’ll notice that both of them are almost similar. They both have a data key under which the configuration data is provided in key-value pairs. For example,

data:
  key1: value1
  key2: value2

The difference is in the fact that secrets are meant for holding sensitive data. When writing the YAML for a secret we wouldn’t specify value1 and value2 directly like we would for ConfigMaps. Instead, we would specify the base64 encoded versions of these values.

Pods can refer to a particular ConfigMap and/or Secret and specify a key and then they would have an environment variable in their container with the corresponding value. This would enable you to refer to these environment variables in your application code.

For the movies app which we deployed, our api pod needed the credentials for the MongoDB database in order to connect to it. We provided these using a secret. If you see the YAML for the api deployment you’ll see that we’re getting an environment variable called MONGODB_PASSWORD for our container from a secret called mongodb.

If you want to see how the YAML for this secret looks, head over to the terminal and run:

kubectl get secret mongodb -o yaml

The -o yaml flag gets the YAML for a particular Kubernetes object. You’ll see that under the data key for the returned object, we have the mongodb-password key which we were referring to in our api deployment. To see the actual value for this key you’ll have to decode the base64 encoded value shown.

Now that you have an idea of how configuration data is handled in Kubernetes clusters, let’s move on and take a look at how data is shared between K8s objects using Volumes and Persistent Volumes.

Storage in Kubernetes

If you recall, in the second article I mentioned that Pods are meant to be ephemeral. This means that any data generated by containers running in the Pod also gets destroyed when the pod is destroyed. In Kubernetes, Volumes and Persistent Volumes help us solve this problem of data loss. Apart from this they also solve another problem - sharing of data between different containers.

Volumes

There are a lot of volume types offered by Kubernetes. But thankfully as developers we mostly never have to worry about all this stuff. In this section, we’ll just cover a common volume type which you might run into - emptyDir.

The emptyDir type has two important use cases. The first is that it allows us to share data between two containers running in the same pod. The second is that if our container ever crashes, it enables us to still retain all the data created previously. Do note that this volume only exists as long as the Pod is running. So if your pod is destroyed for any reason, you WILL lose all the data. Let’s look at how volumes are configured for Pods:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  volumes:
  - name: cache-volume
    emptyDir: {}
  containers:
  - image: nginx
    name: my-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume

Under the Pod spec we first define our volumes in a list - in the above example we have one volume called cache-volume which is of type emptyDir. Then while specifying our containers we refer to this volume under volumeMounts. mountPath is where in the filesystem of the container the data from the volume should be loaded into.

Persistent Volumes

We just learned that emptyDir volumes won’t save our data if our Pod goes down. So you must be wondering how does one store data which persists regardless of any changes to the Pod. This is where Persistent Volumes come to save the day.

A Persistent Volume (PV) is a cluster level storage object. What this means is that just like nodes, it too is a resource present in the cluster. It is an administrator’s job to provision this so don’t worry too much about how it’s created. However, what we as developers should be familiar with is how to use this provisioned storage.

To use a Persistent Volume, we create a Persistent Volume Claim (PVC) object and then refer to this claim under the volumes key of the Pod YAML like we saw above. A PVC is nothing but a request for storage. This is how a basic PVC object would look like:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Once you create this PVC, the Kubernetes control plane will bind this claim to a suitable persistent volume for you. The above YAML should be pretty simple to understand, we’re requesting 3 Gigabyte of storage with the access mode of ReadWriteOnce. What this means is that the volume can be mounted as a read-write storage but only by a single node.

After you create the PVC, all that you need to do is refer to it in your Pod’s YAML as we did for emptyDir above.

spec:
  volumes:
    - name: pv-storage
      persistentVolumeClaim:
        claimName: pv-claim

And voilà! You now have a persistent storage solution for your application. Okteto gives you the ability to do a lot more with volumes including creating a data clone of your application's database and using it with your development environment. You can read up more on how to do that here.

This concludes our discussion on configuration and storage in Kubernetes. We started by taking a look at ConfigMaps and Secrets and saw how they help provide us configuration data to our application. Then we looked at how we can leverage Volumes to safeguard our application data in case our container restarts. Finally, we looked at Persistent Volumes which provide us a way to persist data in a separate resource present in the cluster - thus ensuring that even Pod deletion doesn't lead to a loss of data.

All of this does look intimidating at first but remember that you don’t have to fight these battles alone as a developer. If you’re using a managed Kubernetes environment like Okteto, most of this is already taken care of for you. If not, even then, you should be receiving support from the infra team. But like I said earlier, even as a developer it is good to have an idea of things so you’re not totally lost! In the final article of this series, we’ll be taking a look at how networking works in Kubernetes so make sure to keep an eye out for that one! :D

The "Kubernetes for Developers" blog series has now concluded, and you can find all the posts in this series here.

Developing and Deploying a Helm Chart Application in Okteto

Abdulazeez Abdulazeez — Mon, 07 Feb 2022 18:17:43 +0000

Deploying applications in Kubernetes can be complicated. Even the simplest application could require creating a series of interdependent components (e.g., namespaces, RBAC rules, ingress, services, deployments, pods, secrets, etc.), each with one or more YAML manifests.

Helm is the de-facto package manager for Kubernetes applications that allows developers and operators to easily package, configure, and deploy applications onto Kubernetes clusters. If you're building an application that will run in Kubernetes, you should really look into leveraging Helm.

In this article, we'll show you how you can deploy a Helm chart powered application to Okteto, a Kubernetes powered service. We'll also show you how to push your application images to the Okteto container registry, create and configure a helm chart, and then develop the deployed application using Okteto's remote development environment.

If you're a beginner to Kubernetes, check out our Kubernetes For Developers series aimed at beginners.

Prerequisites

In order to follow this tutorial, you should have:

An Okteto Cloud Account (It's free!)
Some familiarity with Kubernetes

Install Helm

We'll be needing the Helm command line tool to create and deploy our application.

For MacOS

$ brew install helm

For Linux

Debian/Ubuntu

$ curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
$ sudo apt-get install apt-transport-https --yes
$ echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
$ sudo apt-get update
$ sudo apt-get install helm

For Windows

$ choco install kubernetes-helm

Building a helm powered application

In this section, we'll create a helm chart to enable us to deploy an already built application. Unlike a docker-compose powered application, helm chart powered applications can not be deployed using the okteto stack deploy command. Helm powered applications also depend on prebuilt container images, so we'll have to build and push our images to a registry too.

Clone the application

In your terminal, clone the GitHub repository and make it the working directory:

$ git clone -b default https://github.com/okteto/recipe-app
$ cd recipe-app

In the folder, we have an application prebuilt alongside a Dockerfile. As it stands, there is no manifest readily available for deploying the application to Kubernetes. We are going to create a helm chart for the application but before then, let's build the image and push it to Okteto's build registry.

Building the application image

We will be building the image for this application from the Dockerfile to Okteto's container registry. Before building the image, set the Okteto context:

$ okteto context

Next, run the command to build the application:

$ okteto build -t okteto.dev/recipe-app:latest

The command above builds and pushes the application's image allowing us to pull this image from our namespace easily.

Creating a helm chart

To create a helm chart, we'll use the Helm command-line tool. In the application directory, run the command to create the helm chart:

$ helm create charts

The command above creates a new folder containing:

chart/
├── Chart.yaml
├── charts
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ ├── hpa.yaml
│ ├── ingress.yaml
│ ├── service.yaml
│ ├── serviceaccount.yaml
│ └── tests
│     └── test-connection.yaml
└── values.yaml

The Chart.yaml contains basic information about the Helm Chart. Change the name and description to:

name: recipe-app
description:  A recipe application built on FastAPI

In the list of files above, we're majorly concerned with _helpers.tpl, service.yaml, deployment.yaml and values.yaml in this article.

The _helpers.tpl contains variables to be defined in our normal k8s manifest. Instead of repeating variables such as annotations, labels, etc., in multiple manifests, they are placed in the _helpers.tpl file.

Update the _helpers.tpl file to this:

{{/*
Expand the name of the chart.
*/}}
{{- define "chart.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" }}
{{- end }}

{{/*
Create a default fully qualified app name.
We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec).
If release name contains chart name it will be used as a full name.
*/}}
{{- define "chart.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- if contains $name .Release.Name }}
{{- .Release.Name | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}
{{- end }}

{{/*
Create chart name and version as used by the chart label.
*/}}
{{- define "chart.chart" -}}
{{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" }}
{{- end }}

{{/*
Common labels
*/}}
{{- define "chart.labels" -}}
helm.sh/chart: {{ include "chart.chart" . }}
app.kubernetes.io/name: {{ include "chart.name" . }}
{{ include "chart.selectorLabels" . }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

{{/*
Selector labels
*/}}
{{- define "chart.selectorLabels" -}}
app.kubernetes.io/name: {{ include "chart.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end }}

{{/*
Create the name of the service account to use
*/}}
{{- define "chart.serviceAccountName" -}}
{{- if .Values.serviceAccount.create }}
{{- default (include "chart.fullname" .) .Values.serviceAccount.name }}
{{- else }}
{{- default "default" .Values.serviceAccount.name }}
{{- end }}
{{- end }}

The deployment.yaml manifest contains the instructions for deploying your application to Kubernetes. It comes prefilled and fetches the values from the _helpers.tpl and values.yaml file. Update the containerPort in the container section to 8080:

containers:
  - name: {{ .Chart.Name }}
    securityContext:
      {{- toYaml .Values.securityContext | nindent 12 }}
    image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
    imagePullPolicy: {{ .Values.image.pullPolicy }}
    ports:
      - name: http
        containerPort: 8080
        protocol: TCP

Lastly, let's look into the values.yaml file. This stores the image name, replica count, service configuration data, etc. Update the image repository and tag value from:

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

image:
  repository: $IMAGE_REGISTRY/recipe-app
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"

In the code block above, replace $IMAGE_REGISTRY with:

okteto.dev/recipe-app if you used the Okteto registry
Your docker hub username if you pushed your image to docker hub.

Next, under the serviceAccount heading, set the create variable to false as we're not interested in creating a service account:

serviceAccount:
  # Specifies whether a service account should be created
  create: false
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: ""

Next, change the service type and port to:

service:
  type: LoadBalancer
  port: 8080

We have successfully configured our application's helm chart. The next step is to deploy it to Okteto.

Deploying to Okteto

To deploy our application to Okteto, return to the base directory in your terminal and run the command:

$ helm install recipe-app chart/

We get a response from the console:

NAME: recipe-app
LAST DEPLOYED: Mon Dec 13 19:09:29 2021
NAMESPACE: youngestdev
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export NODE_PORT=$(kubectl get --namespace youngestdev -o jsonpath="{.spec.ports[0].nodePort}" services recipe-app-chart)
  export NODE_IP=$(kubectl get nodes --namespace youngestdev -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

This tells us our application has been deployed. In our Okteto dashboard, we can see the deployed application:

Development environments for Helm applications

Helm chart powered applications can also be remotely developed in Okteto. Let's create a development container to verify this:

$ okteto init

Select the deployed application:

 i  Using youngestdev @ cloud.okteto.com as context
This command walks you through creating an okteto manifest.
It only covers the most common items, and tries to guess sensible defaults.
See https://okteto.com/docs/reference/manifest/ for the official documentation about the okteto manifest.
Use the arrow keys to navigate: ↓ ↑ → ←
Select the resource you want to develop:
  ▸ recipe-app-chart

The okteto.yml manifest is created and we can start our development container by running the command:

$ okteto up

 i  Using youngestdev @ cloud.okteto.com as context
 ✓  Persistent volume successfully attached
 ✓  Images successfully pulled
 ✓  Files synchronized
    Context:   cloud.okteto.com
    Namespace: youngestdev
    Name:      recipe-app-chart
    Forward:   8080 -> 8080
    Reverse:   9000 <- 9000

root@recipe-app-chart-okteto-c88fff58f-pt8c8:/app#

We have verified that our application can indeed be developed locally. In our dashboard, the state of the application has changed to In Development:

Let's start our application remotely:

$ python3 main.py

INFO:     Uvicorn running on http://0.0.0.0:8080 (Press CTRL+C to quit)
INFO:     Started reloader process [80] using statreload
INFO:     Started server process [82]
INFO:     Waiting for application startup.
INFO:     Application startup complete.

The development environment updates the application on every file change. Let's change the welcome message in app/api.py:

@app.get("/", tags=["Root"])
def get_root() -> dict:
    return {
        "message": "Welcome to your Okteto app powered by Helm charts live in development mode!"
    }

Okteto automatically synchronizes the changes, and the application is now updated:

We have successfully deployed a helm chart powered application as well as developed it using Okteto's remote development environment.

Conclusion

In this article, you learned how to build an application's image and push it to Okteto's build registry and docker hub. You also learned how to create helm charts for your application for deployments to Kubernetes. The application deployed using helm charts was also developed remotely by creating a development environment in Okteto.

Sign up on Okteto today to improve your development process experience using development environments and preview environmemts!

The code used for this article can be found on GitHub.

Developing a Rasa chatbot in Okteto

Abdulazeez Abdulazeez — Mon, 07 Feb 2022 18:16:52 +0000

Rasa is a Python framework for training and building an AI-powered chatbot integrated into various platforms.

Training and building AI-powered applications such as chatbots can be expensive. It requires high computational power and supported firmware. Okteto provides you with a development environment where you can train, build and deploy your models remotely on the Cloud.

In this article, we’ll show you how you can build a simple rasa chatbot, Oktebot, remotely in Okteto.

Want to see this built live? Watch the recorded live-stream on our Youtube channel!

Prerequisites

To follow this tutorial, you should have:

An Okteto Cloud account (It’s free! )
Okteto CLI installed
Basic knowledge of Python

Setting up

We’ll start by creating a project directory to house our application:



$ mkdir oktebot
$ cd oktebot

Building Oktebot in Okteto’s development environment

Now that we have created the project directory, the next step is to sign in to our Okteto account via Okteto CLI from our local terminal:



$ okteto context use https://cloud.okteto.com

In the project directory, we’ll create an Okteto manifest as the first step in creating our development container:



$ okteto init

The first prompt asks us to select the language we'll be working with:

This is to enable Okteto provide the necessary toolings for our remote development session.

In the prompt from the command above, select Use default values:



Select the resource you want to develop:
  ▸ Use default values

In the newly created manifest file, okteto.yml, modify the image name:



image: rasa/rasa

We have successfully created the manifest file. The next step is to start our development container and select Python as the default language in the prompt:



$ okteto up

The okteto up command creates a new development container in your dashboard from the parameters included in the okteto.yml manifest file and then starts a remote development session:




i  Using youngestdev @ cloud.okteto.com as context
 ✓  Persistent volume successfully attached
 ✓  Images successfully pulled
 ✓  Files synchronized
    Context:   cloud.okteto.com
    Namespace: youngestdev
    Name:      oktebot
    Forward:   8080 -> 8080
    Reverse:   9000 <- 9000

root@oktebot-okteto-7bbddd5c59-d7bmx:~#

In the remote development container, we’ll create a new rasa bot in the project directory:



root@oktebot-okteto-7bbddd5c59-d7bmx:~# rasa init

In the prompt in the remote terminal, select the current directory and train the initial model:



? Please enter a path where the project will be created [default: current direct
ory] 
? Directory’/app’ is not empty. Continue? (Y/n) Y
? Do you want to train an initial model? Y

Once the training is complete, the rasa tool prompts us to ask if we’d like to speak to the trained assistant:



Do you want to speak to the trained assistant on the command line? Y

Let’s speak with the trained assistant:

Training Oktebot

The data folder contains our bot's training data and responses in our project folder. There are three files currently present:

nlu.yml: This file contains the sample data for Natural Language Understanding.
stories.yml: This file includes example conversations with the bot to train the assistant to respond correctly depending on the preceding text.
domain.yml: This file defines the scenario in which the bot acts. This file defines intents from our NLU files and accompanying responses.

Now that we have successfully created our chatbot, let’s train the bot with our data. In the data folder, create two new files from your remote development container terminal:



root@oktebot-okteto-7bbddd5c59-d7bmx:~# touch {chat,faq}.yml

The newly created files will contain the intent and examples for training our bot similar to nlu.yml. The chat.yml file will house the intent for when a user starts a conversation with the bot, and faq.yml will contain the training data for when a user asks a question.

In the chat.yml file, add the following:



version: "3.0"

nlu:
  - intent: chat/hello
    examples: |
      - How can we help
      - we're glad we can help
      - please hold on while I get you an engineer
      - glad you love okteto

  - intent: chat/bye
    examples: |
      - do come back next time

  - intent: chat/sales
    examples: |
      - the sales rep will respond in a moment
      - you can pay using your credit card too
      - schedule a meeting with our sales team

In the code block above, we have defined three conversation intents in our chatbot. The examples listed are used to train the bot to respond appropriatelys to a similar message.

In faq.yml, add the following:



version: "3.0"

nlu:
  - intent: faq/more_resources
    examples: |
      - how much does the developer pro plan cost
      - I'll like to increase my bandwidth
      - What plans can give more benefit than the free plan
      - I'm hitting my limits easily. What can I do

  - intent: faq/plan_expires
    examples: |
      - what happens after my plan expires
      - can i renew my subscription

  - intent: faq/application_status
    examples: |
      - what happens to my applications after 24 hours
      - how can i check my deployment

  - intent: faq/restart_application
    examples: |
      - how can i restart my application
      - my application is asleep

In the code block above, we have defined three frequently asked questions ( FAQ ) intents in our chatbot. The examples listed are used to train the bot to respond to a similar message properly.

With the natural learning understanding files populated, let’s update the rules.yml guiding the chatbot. In rules.yml, add the following:



version: "3.0"

rules:

- rule: Say goodbye anytime the user says goodbye
  steps:
  - intent: goodbye
  - action: utter_goodbye

- rule: faq
  steps:
    - intent: faq
    - action: utter_faq

- rule: chat
  steps:
    - intent: chat
    - action: utter_chat

Lastly, let’s update the stories in stories.yml:



version: "3.0"

stories:

- story: faq
  steps:
    - intent: greet
    - action: utter_greet
    - intent: faq
    - action: utter_faq

- story: chat
  steps:
    - intent: greet
    - action: utter_greet
    - intent: chat
    - action: utter_chat

To wrap up the training data, let’s update the domain.yml file in the project directory:



version: "3.0"

intents:
  - greet
  - chat
  - goodbye
  - affirm
  - deny
  - faq

responses:
  utter_greet:
  - text: "Hi! How can I help you today?"

  utter_chat/hello:
  - text: "Hi, welcome to Oktebot. How may I be of help?"

  utter_chat/bye:
  - text: "Thanks for stopping by!"

  utter_chat/sales:
  - text: "The sales rep will respond in a moment"

  utter_cheer_up:
  - text: "We hope you enjoy the Okteto platform!"

  utter_did_that_help:
  - text: "Did that help you?"

  utter_happy:
  - text: "Great, carry on!"

  utter_goodbye:
  - text: "Bye. See you soon!"

  utter_faq/more_resources:
  - text: "You can request for more resources by either changing your plan or contacting the team at support@okteto.com"

  utter_faq/plan_expires:
  - text: "Your account automatically reverts to the free developer plan once the previous plan expires. You can renew to avoid that"

  utter_faq/application_status:
  - text: "Your application automatically goes to sleep after 24 hours of inactivity on the free plan only"

  utter_faq/restart_application:
    - text: "You can restart your application from the dashboard or wake them by visiting the endpoint"

session_config:
  session_expiration_time: 60
  carry_over_slots_to_new_session: true

By updating the domain.yml, we have updated the intent and responses our bot returns.

Retraining our bot

After populating our sample training data, the next step is to train the bot. Run the command in your development environment shell:



root@oktebot-okteto-7bbddd5c59-d7bmx:~# rasa train
Your Rasa model is trained and saved at 'models/20220113-053154-formal-sequence.tar.gz'.

Now that we have retrained our bot, we can test it from the shell:



root@oktebot-okteto-7bbddd5c59-d7bmx:~# rasa shell

We have interacted with the bot in the screenshot above, and it works according to the trained data. We can now exit the development container and start it whenever we introduce a model before deploying it.

The chatbot files created in our development environment are now available locally. This is as a result of the synchronization feature.

Conclusion

This article taught you how to train, build, and test a Rasa chatbot remotely using Okteto’s development environment. You also learned how Okteto synchronizes from the development environment to your local environment and vice versa.

Now that you have learned how to train and develop a rasa chatbot in Okteto, create a personal virtual assistant using rasa in Okteto and share it with us on our slack channel.

Sign up on Okteto today to improve your development process experience using development environments and preview environmemts!

You can find the code used for this article on GitHub.

Fundamental Kubernetes Concepts Everyone Needs To Know

Arsh Sharma — Wed, 02 Feb 2022 14:30:08 +0000

Ready to get your hands dirty and start using Kubernetes? If you recall, in the last article we talked about what K8s is and how it works internally. Let’s see Kubernetes in action in this one!

In the Kubernetes world everything is an object. To put simply, an object is something you create in Kubernetes to give it a configuration of sorts so that it knows how to run and serve your application. Once you create K8s objects describing your application, the controllers work to ensure that the object's current state matches the described desired state.

There are many Kubernetes objects, some of which you already would have come across if you tried the Okteto Quick Start Guide. We’ll talk about three very important objects in this article: Pods, Deployments, and Namespaces. Trying out the things mentioned in this tutorial series yourself is highly recommended if you really want to be comfortable using K8s. In case you're looking to get that hands-on experience with these concepts without having to do the setup work - don't worry we've got you covered for free with Okteto Cloud!

Pods

Pods are the smallest and most fundamental of objects in Kubernetes. Instead of running containers directly on nodes, Kubernetes runs them inside pods. So think of a pod basically as a wrapper for your containers. A pod usually runs a single container but it can have multiple containers too. What's important to remember is that all the containers of a pod will run on the same node, sharing the same network and resources. Another important thing to remember about Pods is that they are immutable. While you can change the image being used to run the container in the Pod, you can not update fields like the Pod name or the namespace it’s in.

You would usually containerize your application's front-end and back-end parts and have these containers run in separate pods. This is what we saw in the Quick Start Guide. If you open a terminal and run

kubectl get pods

you would see these pods. Additionally, you’ll see another pod running a MongoDB container which is used as the database for our application.

Each pod has a unique IP address assigned to it. While you can’t ping this IP address from outside the cluster, it can be pinged from within.

Let’s do something exciting shall we? Let’s launch a pod and use that to ping our existing frontend pod. To create an object in Kubernetes, a Pod in this case, there are two ways: declarative and imperative. The declarative way involves writing a YAML file describing the object, whereas the imperative way involves using kubectl. kubectl is a command-line tool that allows you to talk to your Kubernetes cluster. Let’s use the imperative way here and run:

kubectl run temp-pod --image=busybox -it -- /bin/sh

This command does a couple of things for us. kubectl run creates a Pod named “temp-pod” and runs a container inside it using the “busybox” image. The -it is used to give us access to a shell inside this Pod and we also specify that we want to run /bin/sh as the first command in this shell. You should also be able to see this pod on your Okteto dashboard. Now let us get the IP address of the frontend pod so we can ping it. To do that, in another terminal, run:

kubectl get pods -o wide

The kubectl get command can be used to get all kubernetes objects of a particular type. Here we use it to get all pods. The -o wide flag tells it to provide us with even more details like the IP addresses of the Pods. Once you copy the IP address of the pod, go back to the shell inside the “temp-pod” and run

wget -O- <IP Address>

You should see an output like:

Connecting to 10.8.6.136 (10.8.6.136:80)
writing to stdout
<!DOCTYPE html>
<html>
  <head>
    <title>Movies</title>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0"/>
  <link rel="icon" href="favicon.png"><script defer src="app.770412f1098441c2c698.js"></script></head>
  <body>
    <div id="root"></div>
  </body>
</html>
-                    100% |************************************************************************************************************|   353  0:00:00 ETA
written to stdout

How cool, right? To destroy this pod you can simply select it in your Dashboard and click on “Destroy”. If you want to go the kubectl route then you can run kubectl delete pod temp-pod in your terminal. The kubectl delete command works for all Kubernetes objects and takes in the object type and object name as arguments.

Deployments

So you might be wondering why Kubernetes doesn’t run containers directly instead of running Pods. This is because Pods are meant to be ephemeral and having containers in Pods enables easy replication - which is one of the most important features of K8s.

A single pod is just meant to run a single instance of your application. You would never create individual pods to serve your application. Why? Because that would mean if the traffic suddenly increases, your Pod will run out of resources and you will face downtime. Instead you create a bunch of identical pods. If one of these pods goes down or the traffic increases and you need more pods, Kubernetes will itself bring up more pods. This management of multiple similar pods is done by the deployment controller when you create a Deployment object.

I think you can now see now why it’s recommended to create a Deployment instead of Pods. The Deployment object will further create and manage the Pods for you. If you look closely at your dashboard you’ll see that api and frontend are actually Deployments. This is why when you did kubectl get pods the pods were not called api and frontend and instead had some random string added to the end. This helps tell that the pods were created by the deployment and not us directly.

Let’s not take my word for it and verify that Pods are indeed actually managed by their Deployments :)

Go to your terminal and see the name of the pod created by the api deployment. After that delete the pod by running

kubectl delete pod <api pod name>

Now run kubectl get pods again and you’ll see that another pod is coming up in its place with a different name. This is because Okteto told Kubernetes to create a deployment which ensures that one api pod runs at all times. You can also see this in the YAML used to create the deployment from your dashboard:

Namespaces

If you took a closer look at your Okteto dashboard, you’d see that there is something called “Namespace” in the top right corner. If you click that, you’ll also see the option to create a new namespace.

Namespaces in Kubernetes are a way to partition your cluster into multiple virtual clusters. You always deploy K8s objects (like Pods, Deployments, etc) in a particular namespace. Deploying different objects in different namespaces allows you to isolate different projects on the same cluster.

Let’s see this in action. Click on “New Namespace” in the dropdown shown above and enter a name - I’m going to go with “golang-rinkiyakedad”. Now switch to this namespace from the same menu and deploy using the same steps you followed in the Quick Start Guide, except that use https://github.com/okteto/go-getting-started as the repository URL this time.

Once the deployment process is complete, head over to the URL shown under “Endpoints” in the dashboard and you should see a webpage showing “Hello world!”.

This means you can now work on two completely different projects and both are running on the same cluster. Pretty cool, right? When using Kubernetes directly, we specify the namespace under the metadata section of an object’s YAML. You can see this by selecting the “hello-world” deployment and seeing its YAML:

You can read more about how to manage your namespaces in Okteto by heading over to the Documentation.

So this was it for this article, we started by taking a look at the most fundamental Kubernetes object - Pods. From there we discussed how serving your application using a single pod is not ideal and how you should be leveraging the Deployment object for this instead. Finally, we took a look at Namespaces and saw how they allow you to divide up your Kubernetes cluster and enable deploying multiple different applications. I hope you now have a much better idea about these three very important Kubernetes objects!

In the next article, we’ll see how storage works in K8s clusters and take a look at some other important Kubernetes objects. Until then, feel free to experiment with the apps we deployed on Kubernetes in this article :)

The "Kubernetes for Developers" blog series has now concluded, and you can find all the posts in this series here.

Getting Started with Kubernetes as a Developer

Arsh Sharma — Thu, 27 Jan 2022 15:45:00 +0000

Are you tired of listening to everyone in DevOps talk about “Kubernetes” while you're still struggling with how to pronounce it? Unless you started programming today, I’m pretty sure you have heard the word but most likely as a developer you haven’t gotten the chance to learn about it - maybe because it seems intimidating or maybe because you aren’t sure how it’s useful for you.

Let me take you on a journey from being a developer clueless about Kubernetes to one who can understand all the mumbo jumbo the infra team talks about. In the process, you’ll also start appreciating its beauty and usefulness in increasing developer productivity. We’ve got a lot to cover over the course of this series, so let’s jump right in!

The Death Of “It Works On My Machine!”

It's important to have an understanding of containers before talking about Kubernetes. Containers are executable packages of software that contain all the code and dependencies necessary to run an application anywhere. And by anywhere I literally mean anywhere - my laptop, your laptop or even on “the cloud”.

Are containers starting to sound similar to virtual machines? Well they're not, and in fact they're even better! Why? Because unlike VMs, containers do not contain operating system images. This means they're much more lightweight! To create and run containers locally you would use a container engine like Docker.

Containers grew in popularity because they truly embraced the ideology of write once, run anywhere. Because of how fast and easy it is to deploy containers, they increased developer productivity significantly. A fun fact is that Okteto also utilizes these containers to give you a live preview of the changes you make while developing locally.

But as more and more companies started using containers a new problem arose. How do you manage thousands of containers running on distributed systems? And that’s where Kubernetes saved the day!

Kubernetes To The Rescue!

Kubernetes, often abbreviated as K8s, is a container orchestration platform. Let me explain this in very simple terms.

Let’s say you have your app which you have containerized. So you run a bunch of containers to serve your app to users. But how do you manage these different containers? The situation is complicated even more by the fact that these containers needn’t necessarily be running on the same machine!

This is where K8s comes to the rescue. It makes deploying, managing, and scaling containerized workloads a breeze! I want to explicitly call out here that K8s is NOT a container engine like Docker. Rather it is a container orchestrator.

As a developer you won’t need to worry about “how” K8s does all this orchestration. You probably also will not have to set up a K8s cluster for your application. But what you would mostly be doing is interacting with a cluster set up for you by the infrastructure team. So it becomes important to be familiar with the K8s objects you’ll be interacting with. That’s what we’ll be focusing on in the articles in this series.

Before we do that, let’s have a high level idea about the architecture of Kubernetes so that you’re not totally clueless about what is happening under the hood.

Kubernetes Under The Hood

In the Kubernetes world a machine is called a node. A K8s “cluster” is nothing but a group of nodes that run your containerized application. These nodes may be bare metal servers in your home or instances you’re running on a cloud provider. These nodes are also of two types: worker and master.

The worker nodes are the ones where your application’s containers would actually be running. Kubernetes actually uses an object called Pod to run these containers but more on that in the next article. Three essential things running on a worker node in a Kubernetes cluster are:

Container runtime: This should be no surprise since a container runtime is what is actually responsible for running containers. Kubernetes supports multiple container runtimes including Docker and containerd.
kubelet: This is the agent which is responsible for communicating with the Kubernetes control plane running on the master node. It is responsible for executing any instructions it receives from the control plane. It also makes sure that containers are running in the pods properly.
kube-proxy: This is a network proxy running on each node. Not going into much detail, you can think of it as being responsible for network communications within the cluster as well as outside the cluster. We’ll be exploring how all these communications happen between pods in a future article.

The master node is the one which has all the components of the Kubernetes control plane running on it. You can also set up multiple master nodes for high availability. Following are some important control plane components you should be familiar with:

kube-apiserver: This exposes the Kubernetes API which we can use to talk to our K8s cluster. This can be thought of as the frontend for the Kubernetes control plane.
etcd: This is the distributed key value store where all cluster related data is stored. For security reasons it is only accessible through the API server. This also helps ensure that the data stored in etcd is consistent.
kube-scheduler: This is responsible for scheduling pods on available worker nodes. While scheduling it takes into consideration resource requirements of the pod and any other constraints that we specify.
kube-controller-manager: A controller in K8s is responsible for observing an object and making sure that the current state of that object matches the desired state that we specified. There are various controllers in K8s for different objects. All these are combined into a single binary which is the kube-controller-manager.
cloud-controller-manager: This is the component which lets you link your cluster to a cloud provider. This binary contains all the cloud provider specific controllers. So when something like a node termination happens in the cloud provider then this component will be responsible for handling that.

Conclusion

And this covers all the basics of the Kubernetes architecture. The really cool thing is that while it's good to have this knowledge, as a Developer you probably won’t have to worry about any of this at all, especially if your team is using development environments like those provided by Okteto.

When you use Okteto you're able to develop from the comfort of your favorite IDE while at the same time you’re able to see changes you make to your app live without having to commit, build, push, or deploy! You get to see a deployed preview of your changes exactly as users would see in production since Okteto deploys on an actual Kubernetes cluster.

In the next article, we’ll start diving deeper into common Kubernetes objects. We will explore the Pods I mentioned briefly here and see how they can be managed using a Deployment - which is another important Kubernetes object. So while you wait for the next article in the series, why don’t you go give Okteto a try and see the magic for yourself? 🙂

The "Kubernetes for Developers" blog series has now concluded, and you can find all the posts in this series here.

Building Docker Images Faster for Webpack

Pablo Chico de Guzman — Fri, 17 Dec 2021 07:58:33 +0000

At Okteto we are very passionate about increasing developer productivity. We were looking for ways to improve our container build times when we came across an amazing project, BuildKit. BuildKit helps us build Docker images faster than ever.

But when getting started we found that there were very few practical examples on how one could optimize their Dockerfiles with Buildkit - so we thought why not change that? This article is going to be about how you too can optimize your Docker builds using Buildkit caches!

The Why

The first question which arises is, why even bother with optimizing your Dockerfiles? Well, the thing is that containers have revolutionized how we build, ship, and run our applications these days. So much so that containers are now heavily integrated into the development cycle and are built over and over - manually or in CI pipelines for testing and live previews.

The biggest quality of life improvement that comes with better image build times is faster testing and review cycles. The quicker everyone can see and test the changes they make, the more the productivity of the team would increase! We have first-hand witnessed this for our website, but more on that later.

The Standard Dockerfile for Webpack

Before we look at how we can speed up build times using BuildKit, let's first see how a standard Dockerfile for Webpack should look like.

# Dockerfile

FROM node:16 as build

WORKDIR /usr/src/app

COPY package.json yarn.lock ./
RUN yarn install

COPY . .
RUN yarn build

FROM nginx:alpine
COPY --from=build /usr/src/app/dist /usr/share/nginx/html
EXPOSE 80

This Dockerfile uses a build step to build the final artifacts, and then, it copies the artifacts to an nginx image.

In order to optimize the Dockerfile instructions cache, we are purposefully first copying package.json and yarn.lock to install the runtime dependencies. We don't copy over everything else in this same step since most of the commits don't change the yarn dependencies, allowing this step to be cached in those cases leading to better build times! But this is already a commonly known best practice and BuildKit would help us optimize the process even more.

The next thing we do is to COPY all our remaining files from our local folder to our WORKDIR. Our changes would be made to one of these files so this means that yarn build is always executed unlike the yarn install instruction above.

Remember to configure your .dockerignore file. In this case, adding .git or node_modules to your .dockerignore file will dramatically reduce the time to send your build context to the docker daemon. This is even more relevant if your build is running on a remote server.

Optimizing the Standard Dockerfile

Now that we've looked at how a standard Dockerfile for Webpack looks like, let's see how we can leverage BuildKit caches to further reduce our build times. BuildKit enables us to configure cache folders for the RUN instructions in our Dockerfile.

Contents of the BuildKit cache directories persist between builder invocations without invalidating the instruction cache. BuildKit also takes care of compatibility - our builds would work with any contents of the cache directory. This is necessary since another build may overwrite the cache files or GC may clean it if more storage space is needed.

In our case, we will use BuildKit caches to persist the yarn cache and the webpack cache.

# Dockerfile.buildkit

FROM node:16 as build

WORKDIR /usr/src/app

COPY package.json yarn.lock ./
RUN --mount=type=cache,target=/root/.yarn YARN_CACHE_FOLDER=/root/.yarn yarn install

COPY . .
RUN --mount=type=cache,target=./node_modules/.cache/webpack yarn build

FROM nginx:alpine
COPY --from=build /usr/src/app/dist /usr/share/nginx/html
EXPOSE 80

What this means is that yarn install and yarn build will be much faster. This is because their contents will be cached now onwards instead of them being run from scratch every time like earlier.

Please note that we've not covered the installation process for BuildKit in this article since it's fairly simple and is documented well here.

Performance Evaluation

The improvement in build times we saw for our website after using BuildKit was phenomenal! Have a look yourself.

The first graph shows the performance improvement we saw whenever we changed a dependency of our website and the second one shows the boost we got from using BuildKit when making code changes.

This means if you're building your images 100 times a day, you save more than 1 hr 23 mins of build time every day!

We hope you too can now appreciate how powerful BuildKit is. A change of only two lines of code in your Dockerfile can dramatically decrease your image build times! We hope this article was useful and you too are now able to optimize your Docker builds.

Happy coding!

Using Github Actions and Okteto Cloud to Preview your Changes

Abdulazeez Abdulazeez — Tue, 20 Apr 2021 11:04:15 +0000

Preview environments serve an important role when performing code reviews for an incoming change or addition to an application's codebase. It is a fantastic way for technical and non-technical members of your team to assess and give feedback on the changes made to your application.

In previous posts of our series on FastAPI you have learned how to build a FastAPI application, deploy the application to Okteto and add a database to it using Okteto stacks. In this article, you will learn how to automatically create a preview environment for your pull requests, using Github Actions and Okteto.

What Are Github Actions

GitHub Actions are event-driven task automation tools that runs a series of command after an event has occurred. These events and commands are contained in a workflow file. The workflow file is responsible for the orderly execution by GitHub Actions.

Creating A GitHub Action Workflow

GitHub Actions are created and managed from the Actions tab in a repository. Create a new workflow from the Actions tab:

There are a number of available templates on the GitHub Actions page. However, click on the set up a workflow yourself link. This opens a new page with a default workflow, let's rewrite the workflow file:

Start by defining the name of the workflow, and the event which should trigger the execution of the workflow file:

name: CRUD App Preview Deployment

on: 
  pull_request:
    branches:
      - main

In the code block above, we have set the name of the workflow, and the event to trigger the workflow. The workflow file is executed when a pull request is made to the main branch. Next, let's define the series of tasks to be executed. These tasks are called jobs in GitHub Actions.

Add the instructions below to the existing code in the workflow file:

jobs:
  preview:
    runs-on: ubuntu-latest
    steps:
    - name: checkout
      uses: actions/checkout@master

    - name: Login
      uses: okteto/login@master
      with:
        token: ${{ secrets.OKTETO_TOKEN }}

    - name: Create namespace
      uses: okteto/create-namespace@master
      with:
        namespace: pr-${{ github.event.number }}-namespace

    - name: Deploy application
      uses: okteto/deploy-stack@master
      with:
        build: "true"
        namespace: pr-${{ github.event.number }}-namespace

    - name: add comment to PR
      uses: okteto/notify-pr@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        message: "Preview environment available at https://fastapi-pr-${{ github.event.number }}-namespace.cloud.okteto.net"

In the code block above, we defined the job preview which runs on the ubuntu-latest environment. The steps to be executed under this job is defined under the steps heading. Let's go over these steps.

Replace namespace in the code block above with your Okteto default namespace.

Steps

In our preview job, we have five tasks to be executed.

checkout: This step checks out the repository using the actions/checkout@master actions, so that the repository is accessible by the entire workflow.
Login: This step logs into your Okteto account. This task makes use ofsecrets.OKTETO_TOKEN, which holds the value of your Okteto token. You'll learn how to create the secret in the next section.
Create Namespace: This step creates a new namespace using the okteto/create-namespace@master action.
Deploy Application: This step uses the action okteto/deploy-stack@master to deploy the application using the okteto stack file defined in the repository. Once again, we have witnessed the adaptability of Okteto stacks.
add comment to PR: This step adds a comment on the pull request discussion indicating a link to the deployed application. It makes use of the okteto/notify-pr@master action.

Adding Your Okteto Token To GitHub

Before adding your Okteto token to GitHub, retrieve your Okteto token from your dashboard settings:

The workflow file needs your Okteto account token to function properly. Follow the steps below to add your okteto token to your GitHub repository:

i. In your repository, navigate to the Settings tab and click on the Secrets link on the menu by the left:

ii. Click on New Repository Secret

iii. Create a new secret OKTETO_TOKEN and set the value to the token you copied from your dashboard.

You can learn more on how to store and manage GitHub secrets on their official documentation.

Building The Preview Environment

With the secret in place, let's go on to create a pull request from the mongodb-crud branch into the main branch to see the workflow in action:

Immediately the pull request is created, the workflow kicks into action:

To monitor the progress of the workflow in action, navigate to the Actions tab. The current workflow is listed like in the image below:

Click on the workflow currently under execution. In the workflow page, click on the preview job to view the execution and logs of each step:

The tasks undergoing execution are listed:

With all the necessary details put in place, the execution completes successfully:

Return to the pull request thread to view the comment made by github-actions bot:

Deleting Preview Environment Namespace

The preview environment ceases to be of use after the pull request has been merged. As such, there is no point in keeping the namespace created by the workflow earlier as newer pull requests will create new namespaces. Okteto provides an action to automatically delete a namespace.

Repeating the steps followed in creating a workflow above, create a new workflow preview-close to automatically destroy the namespace after the pull request has either been merged or close:

name: Delete Preview Namespace

on:
  pull_request:
    types:
      - closed

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@master

      - name: Login
        uses: okteto/login@master
        with:
          token: ${{ secrets.OKTETO_TOKEN }}

      - name: Delete namespace
        uses: okteto/delete-namespace@master
        with:
          namespace: pr-${{ github.event.number }}-namespace

Remember to change namespace to your Okteto namespace.

With the workflow in place, let's merge the pull request and verify that the Delete Preview Namespace workflow was executed:

Navigate to the Actions tab and click on the workflow undergoing execution:

The namespace has been deleted successfully:

Conclusion

In this article, you built a workflow for creating a preview environment when a pull request is made to the main branch and another workflow to delete the namespace containing the preview environment after the pull request has either been closed or merged.

Once again, the deployment of the preview environment was made possible by the stack manifest we have been using from the first post in the series. This way, you are reusing the same manifest for development, deployment, and preview environments.

The complete code used in this article can be found in our GitHub repository