Forem: Bruno

Deploying Remix apps on Kubernetes

Bruno — Tue, 23 Aug 2022 17:00:00 +0000

Remix, as stated in their website, is a JavaScript full stack web framework that lets you focus on the user interface and web standards to deliver a fast, slick, and resilient user experience.

As the framework is getting a lot of attention from the community (over 18k stars on Github), I decided to try it out myself for fun, and deploy the end result to Kubernetes using Shipa to demonstrate how easy it would be for those migrating to Remix to deploy their apps to an actual Kubernetes cluster without hassle.

For those who don’t know what Shipa is or does, it is a tool that simplifies the way you deploy, secure, and manage applications across cloud-native infrastructures. In the same way that Remix abstracts a lot of complex concepts from modern web development (routing, hydration, cache, server side rendering, etc.), Shipa abstracts all the hard concepts from the Kubernetes world, so you can focus your time and energy into building your actual application rather than learning Kubernetes.

The basics

Instead of learning about all the objects you need to define to get your app up and running in a K8 cluster (deployments, services, ingress, secrets, helm charts, etc.), the only thing you really need from your app is a Docker image. With that on hand, Shipa will take care of the rest. It will generate all the underlying definitions required to deploy your app, and it will even create a public URL endpoint you can visit to access your running/test application.

Is that magic? How can I do that?

For the sake of this example, I followed one of Remix’s starting tutorials and created a Docker image for it. The final code is actually available in their official repo, even with the right Dockerfile, so all the credit really goes to the Remix team 🙂. With that in my hands, the rest is a piece of cake.

Requirements:

Install docker on your computer and create a free account
Follow the Remix tutorial and create your own app (the framework it’s really impressive and easy to use, so have some fun there if you have more time!)
Copy the Dockerfile available at https://github.com/remix-run/remix/blob/main/examples/jokes/Dockerfile to generate your container image

The only change I did for the sake of this example is to actually generate a new empty DB on every build of the image. This is not something you should do when using an actual production DB, but I intentionally did it just to load the file as part of the container for testing purposes.

NOTE: I forced an ENV variable with the DATABASE_URL where I intent to store the DB and ran the prisma commands to generate a new empty database from the schemas the code has.

Sign up in Shipa Cloud (it is free)
Create a Kubernetes cluster in the provider of your preference (GKE, EKS, AKS, etc.)

You could even use minikube or k3s, but you will need to expose your local cluster to the internet to be able to connect them to Shipa (out of the scope of this quick test)

Now it is your turn:

With the codebase on your machine, Go to the Terminal and cd into the folder with the project. In my case cd ~/remix-blog
Build the Docker image locally by running docker build . -t NAME:TAG. In my case, docker build . -t dechegaray/remix-blog

The . provides the context to the command from where to look the Dockerfile. If a different path is needed, just adjust that relative path there docker build ./deploy/Dockerfile -t NAME:TAG
The -t command just gives a tag name to your image, so you can locate it easier.

NOTE: The build process is really fast compared to other frameworks I have used in the past, so Kudos to the Remix team for having a keen eye there.

Push the built image to your docker hub by running docker push REPO/IMAGE_NAME:TAG, making it publicly available. In my case docker push dechegaray/remix-blog

Go to your Shipa account using the dashboard

Connect your cluster to Shipa (instructions here)

Create an app on Shipa and provide your container image’s URL. In my case, docker.io/dechegaray/remix-blog (you can use container images from any registry, I am using Docker as an example in this case)

Set the required environment variables for this application (if any). If you were using a real database running on an external service (i.e. Mongo Atlas , AWS, Google Cloud, etc), you could just pass the auth information as environment variables here.

**NOTE: **This application uses a SQLite database to persist jokes and users created by the application. In an actual production setup, this DB should be stored in a separate volume or service; however, just for the sake of the demonstration, I decided to load the DB file into the container running the app, which means that every time the pod of the app is created, the DB will appear as it is initially loaded into the container “empty”.

Click “deploy” and wait for Shipa to complete the process.

That’s it! Your app should appear as running, and if you click on it, you should see all the information that Shipa prepared for you. Easy, right?

Your app is already deployed to your cluster, and you should have enough information to monitor/debug it from Shipa (without the need to use kubectl). Visit the app’s details and have fun seeing all the details Shipa provides. Some of those details are listed below:

Instantly accessible URL endpoint (click on it to actually see your app running)

**Hack: **As you can see, Shipa generates a URL served through http not https by default, so because of it, the original code that creates your cookie session on Remix won’t work, as it is requesting only secure sites on production. To bypass that behavior, you can do 2 things:

1) Add a CNAME on shipa using https if you have one available, OR

2) For testing purposes, disable the secure cookies when creating your session:

I did it by adding an extra condition that forces the secure property to be false if intended. Then, I added the environment variable to my app on Shipa to make the condition truthy, and that’s it. My app is now fully ready to accept sessions.

Resource and Transaction metrics!!

Logs directly from Kubernetes (say what???). Start using your app and see how logs start appearing there.

Even a timeline with the history of your app (if you redeploy your image with new changes, you will see them there as well).

There is a LOT more to see there, so feel free to explore your app and see all the info Shipa has captured for you.

Simple, right? Your first Remix application actually deployed to a Kubernetes cluster without any hassle. And you didn’t have to learn anything about Kubernetes (maybe just figuring out how to create a cluster, but other than that, everything seems pretty simple)

You might wonder, “Yep, this is cool, but how do I integrate this into my development flow?”. Well, it is really up to you and your development processes, but we have done a lot of work to support the most common CIs out there, so you could create a Github action that builds your Docker image (as you are probably already doing), and then use Shipa’s Github Action provider or Shipa’s CLI to deploy it to your cluster.

Just so you can picture it better, imagine having your Docker image ready in your registry of preference and just doing:

// Install shipa CLI

curl -s https://storage.googleapis.com/shipa-client/install.sh

// Adding shipa API

shipa target add shipa-cloud https://target.shipa.cloud -s

// Signing into your account

shipa login ${{ secrets.SHIPA_USERNAME }} ${{ secrets.SHIPA_PASSWORD }}

//Deploying your app

shipa app deploy -a ${{APP_NAME}} -i ${{APP_IMAGE}} -k framework

And that’s it. Every new version of your image will be deployed to a specified cluster (staging or prod), so you can already imagine the endless possibilities there.

Check our blog for more examples of running Shipa from a CI

Conclusion

If you have the time and haven’t done it yet, take a look at Remix, it is definitely an interesting JavaScript framework that’s worth checking out, as I believe it is there to improve our lives as developers and create pretty interesting users experiences. AND you already know how to deploy it to Kubernetes 🙂

Similarly, if you are struggling with Kubernetes, or want to have a solid developer platform that simplifies a lot of hard concepts and scales properly, take a look at Shipa. We are confident that once you try it out, you will be able to focus more on actually building your application rather than adapting to all the numerous changes of the cloud industry.

Rolling out a 3-tier app as SaaS

Bruno — Wed, 15 Jun 2022 15:48:35 +0000

TL;DR

I wanted to launch an application and offer it as SaaS
I chose Kubernetes for its scalability, but I didn’t want to deal with its complexities
My goal was to launch my service as fast as possible and operationalize it easily without letting infrastructure related complexities get in the way.

Background

I love what we are working on here at Shipa, and I couldn't be more proud of all the great things the team is constantly delivering, but one thing I like is having personal projects. These help me keep up to date with technology and learn new things.

I try to keep the investment in those projects at a minimum and under control. That goes across both the timing and the resources invested.

My most recent project is related to the experience when defining cloud-native applications. I see so many DevOps teams spending time having to create and manage templates for developers to deploy their applications. In my opinion, this:

Creates toil for the DevOps team.
Slows down the onboarding of new applications.
Shift left won’t effectively happen because creating infrastructure-level definitions is often complex for developers and diverts time from where they add value.
Too many duplicated charts because there is no practical way to share application definitions with other teammates or teams.

The list goes on, so I decided to put together a product that people could use to:

Build their application definition without dealing with any underlying Kubernetes complexity
Save it and share it with their teammates or publicly
Export that application design to be used with different IaC tools or pipelines

Application Architecture

The application is initially simple, and I have broken it down into different components:

Description:

Frontend: A React application with a drag and drop interface. The interface allows users to define applications and policies using a drag and drop experience. In addition, users can save, share, and search for saved definitions in a global repository.
Backend: A Golang service exposed through an API. Calls are received from the frontend service and, based on the payload, generate the application or policy definition based on the provider selected. The Backend service also manages the saving and sharing of definitions.
Database: I chose MongoDB to store and serve the necessary data because I wanted to learn MongoDB (one of the advantages of personal projects!)
Auth: I’m using Shipa to serve the authentication. As long as users have a Shipa account, they can log in to save and share their definitions.

Hosting My Application

I wanted a scalable infrastructure to host my application and its different services, so I chose Google Kubernetes Engine (GKE).

While spinning up a GKE cluster is effortless, deploying multiple services, exposing them to external users, securing them, and monitoring them can be daunting. As mentioned before, I aim to launch as quickly as possible and spend the least amount of time dealing with infrastructure.

I will also need to:

Configure network policies so my backend API only accepts requests from the frontend service
Set up monitoring, so I can quickly identify potential issues and security violations
Integrate activities and events into Slack, so I can know quickly if something happens.
Set up dev and a production environment, so people see less of the bugs I introduce :)

Setting up all the above directly with Kubernetes would be time-consuming because I would be dealing with ingress controllers, deployment definitions, setting up Prometheus, exposing services, complex network policies using Calico, certificate generation, and more.

I would be spending time on infrastructure rather than on my application, releasing it, getting feedback, pushing fixes, and monitoring utilization. That’s less than ideal.

To remove that, I decided to use Shipa to host my application, which means I’m my own customer!

Deploying My Application

GKE Cluster

I already have a Google Cloud account and gcloud configured on my terminal, so creating a cluster is straightforward. Here is a sample command you can use:

gcloud beta container --project "project-name" clusters create "appcluster" --zone "us-west1-a" --no-enable-basic-auth --cluster-version "1.22.8-gke.201" --release-channel "regular" --machine-type "e2-standard-2" --image-type "COS_CONTAINERD" --disk-type "pd-standard" --disk-size "100" --metadata disable-legacy-endpoints=true --scopes "https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" --max-pods-per-node "110" --num-nodes "3" --logging=SYSTEM,WORKLOAD --monitoring=SYSTEM --enable-ip-alias --network "projects/project-name/global/networks/default" --subnetwork "projects/project-name/regions/us-east1/subnetworks/default" --no-enable-intra-node-visibility --default-max-pods-per-node "110" --enable-network-policy --no-enable-master-authorized-networks --addons HorizontalPodAutoscaling,HttpLoadBalancing,GcePersistentDiskCsiDriver --enable-autoupgrade --enable-autorepair --max-surge-upgrade 1 --max-unavailable-upgrade 0 --enable-shielded-nodes --node-locations "us-west1-a"

The command above will create a cluster with 3 nodes with 2 vCPU and 8GB of memory each. The command also enables network policy for the cluster.

If you copy the code above, make sure you change it to use your project name.

Once the cluster is running, you can use the command below to configure kubectl:

gcloud container clusters get-credentials cluster-name --zone us-west1-a --project project-name

Connecting Shipa

With my cluster running and my Kubectl configured. It’s now time to connect it to Shipa.

I already have my Shipa Cloud account, but if you don't have one yet, you can sign up for free here.

Because I used Shipa as my application management platform, I don't need to worry about installing ingress, Prometheus, RBAC, and more. Once you connect Shipa to the cluster, those will be taken care of automatically.

Creating my framework

Shipa uses the concept of Policy Frameworks to connect to your cluster, so head over to Frameworks to create the first one and click on Create.

To keep the initial setup simple, keep the default setting of “Deploy applications with reasonable defaults” and click Next.

Enter the framework name, select the available Plan, and the pre-created team shipa-team. Click on Create

You can customize these settings by creating a new resource limit plan or adding more teams and users to your account. I’m the only one managing this project, so the default options work for me.

Shipa automatically creates a namespace for each framework you connect to a cluster, so when I deploy my application, Shipa will use the namespace based on the policy framework I select.

Connecting to my cluster

With your framework created, click on Clusters and then Create.

Here I selected the frameworks I created and entered my Kubernetes control plane address. Click on Generate Command

Shipa generated a kubectl command. Once I ran it on my terminal, Shipa installed an agent in my cluster, created the namespace for each framework, and started showing up on my Shipa dashboard.

Deploying MongoDB

Connecting my cluster to Shipa only took me a couple of minutes and saved me an enormous amount of time because I didn't need to deal with ingress install, config, Prometheus, RBAC, and more.

I click on Applications and then Create to deploy the first service.

I deployed my MongoDB service first, and it was pretty easy.

I entered the application name, the MongoDB image URL (mongo:latest), and picked the framework I wanted to use to deploy my application. There were more options I could use, such as binding a volume to it, but I wanted to keep things simple and release fast.

The deployment only took a few seconds, and I got some great info immediately, such as logs and the Internal DNS my other services can use to communicate with MongoDB, all without having to kubectl my way to configure things.

I also got the complete Metadata of my MongoDB application, some initial monitoring information, and the dependency map of my deployment:

Deploying the Backend

I clicked again on Applications and Create.

Once again, I entered my application name (backend), the image URL, and picked a framework. Now, I need to enter an environment variable so my backend application can connect to my MongoDB service.

I had to select the “Set environment variables” option in the deployment screen and hit Next.

I created 2 env variables and entered the values for each. Once done, I clicked on Deploy

One point to notice is that because Shipa gives me the MongoDB service Internal DNS, it was just a couple of clicks to copy the address and paste it here as a value for one of my variables!

In the same way as before, I get all the necessary information about my application.

So lets now head to the last service

Deploying the Frontend

I clicked on Applications and followed the same process as the steps before for my frontend application:

Exposing My Application

Even though Shipa creates an external URL you can give to users to access your application, that was not what I had in mind to provide my users with.

I then created a Domain using Google called defineyour.app and added a CNAME for my application called you.defineyour.app

Connecting this to my frontend application was easy. In the Applications page, I clicked on my frontend service, Configure, and CNAME.

All I had to do was select HTTPS and enter the CNAME I created on Google Domains. Shipa automatically generated the certificate and added that endpoint to my frontend service.

In just a few minutes, the CNAME was propagated, and I could access my application through that CNAME. All without dealing with cert-manager, certificate generation, and more, which is usually a pain.

Setting Up Alerts

I wanted to quickly set up alerts for my services so if anything goes wrong, I can act fast.

I could create an alert by clicking on the service name and selecting the Integrations tab.

I selected Slack as a provider, but if whatever you use is not on the Provider list, you can use Shipa’s CLI to create a webhook for your incident tool. Here is an excellent example of how to create a webhook to Microsoft Teams

Releasing my Service

Now that I have all my services running, the frontend is accessible through a custom CNAME, and I have my alerts in place, it was time to give people the address of my app so that they could give it a try.

As people access my services, I can see the app's performance, logs, history, and more. Again, all without dealing with Kubernetes complexity and focusing all the time I have on my applications.

Moving Forward

The next step for me now is to set the Network Policies, which I can do through Shipa, and integrate this into a pipeline, which I will probably use GitHub Actions

Conclusion

I went from having a few container images to launching a complete service as SaaS in just a few minutes without dealing with underlying infrastructure complexities. It was amazing to see how far Shipa has come as a product and how awesome of a product the team is delivering.

As we enter a weird period in the market and companies focus on doing more with less, enabling application teams to deliver faster, manage applications better, and keep those applications secure without complexities will make you an essential resource in your organization and being my own customer, has proven to me again that this is a much easier and better way to do it.

Deploying WordPress on Kubernetes

Bruno — Mon, 13 Jun 2022 21:00:17 +0000

Onboarding applications on Kubernetes can be complex.

Understanding how deployment sets work, volumes, env variables, services, and networking works on Kubernetes can often take away the time from developers and impact application delivery.

Also, sharing application definitions with other teams can help speed up onboarding of new applications, new developers, and more.

Because of that, I started a personal project to help developers onboard their applications on Kubernetes, share those definitions with their teams, and publicly if desired.

I’m building the project on top of shipa.io APIs. The purpose is to give developers a way to go from application definition to management without dealing with the underlying Kubernetes complexity.

I’m just starting with this (I don’t even have a name for it yet), and bugs will be found :) but I wanted to get it out there early, get feedback, and see what could be added to help solve a big problem for different teams.

You can find the application available here: https://you.defineyour.app/search

Please, give it a try, share some feedback, and share it with your teammates!

Application deployment design

Bruno — Mon, 16 May 2022 23:48:47 +0000

Hey folks

I have heard many times that deploying applications on Kubernetes can be a complex task for developers because it involves a lot of infrastructure related knowledge.

Because of that, I started building this side project:

Project Demo

Would you use something like this in your team?

From 0 to Hero on Kubernetes with Nana Janashia

Bruno — Wed, 04 May 2022 00:49:54 +0000

Join Nana Janashia and Bruno Andrade on May 11th at 10 AM PT / 1 PM ET as they discuss how you can go from 0 to Production-ready clusters without all the Kubernetes and infrastructure-related complexity

Developer led Kubernetes experience

Bruno — Wed, 04 May 2022 00:43:42 +0000

It’s no secret that Kubernetes is complex, and hence, many organizations rely heavily on building a DevOps team to implement and manage it.

While Kubernetes enables you to build a scalable infrastructure where you can run your applications at scale, it introduces a dependency on the DevOps team, poor developer experience, and an increase in costs.

These are points that many development-led teams don’t want to deal with, especially in organizations where delivering your application is the top priority, you need a developer self-service model, and you want to make sure both complexity and costs are under control.

You can do that today by implementing an Internal Developer Platform. We will use Shipa as the Developer Platform, and you can create a free account here.

Requirements

A Shipa Cloud account
A Kubernetes cluster

Getting Started

You can get started by creating a Framework. This is how Shipa will connect to your cluster and allow you to deploy applications without all the complexity Kubernetes introduces.

Create a Framework by clicking on the Frameworks option on your left menu, then click on Create

Although you can use Frameworks to enforce policies, we will keep things simple for this example. Choose the Deploy applications with reasonable defaults option and click on Next.

You can later create multiple frameworks to help you isolate applications, which is excellent if you plan to build a multi-tenant environment.

Enter the Framework name and the resource limit plan (you can use the pre-created shipa-plan), and choose the default team (shipa-team). Click on Create

With your Framework created, connect it to your Kubernetes cluster.

Click on the Clusters menu option and then on Create

Select the Framework (or Frameworks) you created and enter your Kubernetes API endpoint, which you can get by running the following command from your terminal (assuming you are connected to your cluster):

kubectl cluster-info | grep 'Kubernetes' | awk '/http/ {print $NF}'

That’s it! You have a developer platform connected to your Kubernetes cluster without dealing with any Kubernetes complexity. Let’s deploy an application. Click on the Applications menu option and then on Add Application.

You can quickly test the application process and experience by entering an application name and selecting the default team and framework you just created.

You can use a sample image for the application image by clicking on the TEST WITH SAMPLE IMAGE button.

Clicking on Deploy will get the deployment process started, and, in a few seconds, you will see your application available and running.

By clicking on the application name, Shipa will give you complete information about your application, status, metrics, history, and more:

Shipa automatically creates a URL endpoint you can use to access your application.

That’s it. In just a few minutes, you can connect to any Kubernetes cluster and start deploying and managing applications without dependency on a large and specialized Kubernetes team!

Free session on JavaScript apps on Kubernetes

Bruno — Wed, 23 Mar 2022 19:13:36 +0000

Hey folks

On March 24 at 10 AM PT / 1 PM ET we will have a free tech session to show how you can easily deploy and manage your JavaScript apps on Kubernetes.

The following topics will be covered:

Building a developer-friend pipeline to deploy your JavaScript application
Monitoring, managing, and alerting for your applications
Manage access and communication to your application and in-between services.
Breakthrough the dependency on the DevOps team to manage your apps through a self-service model.

You can sign up here:

A Developer focused CI/CD pipeline for Kubernetes

Bruno — Tue, 30 Nov 2021 01:54:38 +0000

As Kubernetes becomes the key target environment across many organizations, it automatically becomes an essential topic for developers.

However, Kubernetes was created for operations and, unless you spend a considerable amount of time learning and specializing yourself, it is still challenging to use. Developers should rather focus on delivering applications instead, and a developer or application-focused platform is needed to enable that.

This quick tutorial will teach you how to set up a developer-focused pipeline you can use to deploy and manage your applications on Kubernetes without dealing with the underlying infrastructure-related complexities.

For this tutorial, you will need:

A GitHub repository (you can fork this example repo)
A Shipa Cloud account (you can sign up for free here)
A Kubernetes cluster (You can see the list of supported cluster providers here)

The Components

GitHub Actions

GitHub Actions is an event-driven automation platform that allows you to run a series of commands after a specified event has occurred. For example, when a commit is made to your staging branch, you want to build, test, and deploy the changes to your staging environment. With Actions, you can automate tasks within your development lifecycle, all within GitHub.

Shipa

Shipa is an application platform that enables developers to deploy and manage cloud-native applications. It has a free tier. Developers from small to large enterprises use Shipa today to manage their cloud-native application lifecycle and is quickly becoming the application platform of choice for Kubernetes.

Kubernetes

Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management. It was originally designed by Google and is now maintained by the Cloud Native Computing Foundation.

Connecting Shipa to your cluster

We will use Shipa as our application platform. You can create a free account on Shipa here.

Once you sign up, you can connect Shipa to your Kubernetes cluster. Shipa uses a policy framework to connect to different clusters.

These policies can be as detailed as we want and cover topics such as ingress, networking, container registry control, and more. For our example, we will keep it to a minimum.

Creating a Policy Framework

Once you log into your Shipa Cloud dashboard, go to Frameworks and click on “Create Framework”. This will open up a modal where you can create your first policy:

Keep the selection on “Basic” and click on Next.

Here, just enter the name you want to give this policy framework. For Plan, you can select the pre-created “shipa-plan” option.

You can also select the pre-created and available Team “shipa-team”. Click on Create

Connecting the policy framework to your cluster

Now, click on Clusters, and then “Add Cluster”. This will open up a new modal.

Here, you just need to enter the cluster name and select the framework you created in the previous step:

Clicking on “Next” will prompt you to enter your cluster information, so Shipa can connect to it and bind the policy to your cluster.

For Shipa to connect to your cluster, you will need to enter:
The Cluster IP
A service account token. You should use one created specifically for Shipa
The CA Certificate Shipa should use to connect to your cluster

You can get the information above by following the documentation available here.

Another (quicker) option is to copy and run this script

The script above will create the required service account and display both the token and the CA certificate you can copy and paste into the modal.

You don’t need to enter any information on step 3 of the “Add Cluster” modal. Shipa will automatically install and configure an ingress controller in your cluster for you.

Click on “Create”

The cluster connection process will take approximately 60 seconds to complete. Once complete, you will see your cluster available on the Shipa dashboard.

GitHub Actions

Configuring Secrets

For GitHub Actions to leverage Shipa to deploy your applications to Kubernetes, you will need to enter 2 GitHub Secrets. To create a secret, just click on the “Settings” menu in your GitHub repository and then “Secrets” on the left menu.

You will need to create 2 secrets:

SHIPA_HOST
SHIPA_TOKEN

For SHIPA_HOST, you can enter: https://target.shipa.cloud:8081

For SHIPA_TOKEN, you need to use the Shipa CLI to find your token. You can install the Shipa CLI by running the following command:

curl -s https://storage.googleapis.com/shipa-client/install-cloud-cli.sh | bash

With the Shipa CLI installed, you should add your Shipa target and log in. You can do it by using the following commands:

Adding target:
shipa target add cloud-production target.shipa.cloud -s

Logging in:
shipa login

Display token:
shipa token show

Defining the Application

With your GitHub Secrets defined, we can then define a sample application to test the deployment.

If you forked the sample repository, you can see the following sample application definition.

app:
  name: app1
  teamowner: shipa-team
  framework: estabilis-dev

app-env:
  app: app1
  envs:
    - name: CR_ENV1
      value: test-1
    - name: CR_ENV3
      value: test-3
  norestart: true
  private: false

network-policy:
  app: app1
  ingress:
    policy_mode: allow-all
  egress:
    policy_mode: allow-all
  restart_app: false

app-deploy:
  app: app1
  image: ghcr.io/stefanprodan/podinfo:6.0.3
  port: 9898

The code above will:

Deploy an application named app1
Assign it to shipa-team as the owner of the application
Use the policy framework to enforce controls. Make sure you change this field to reflect the policy framework you created on the steps before. Otherwise, your deployment will fail.
Will create a couple of sample environment variables
A sample network policy will be created
A sample application called Podinfo will be deployed and exposed on port 9898

As you can see from the code above, this does not require you to deal with infrastructure deployment definitions on Kubernetes, ingress controller configuration, and more. This is, rather, a very application-level definition.

Creating the Action

Once the application definition is in your repository, you can create an Action.

Click on “Actions” then on “set up a workflow yourself”

Shipa has a published GitHub Action that you can leverage to deploy your application. You can copy the file below into your Action definition:

on: [ push ]

jobs:
  deploy_dev:
    runs-on: ubuntu-latest
    name: Deploy Dev Applications
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy Dev Application
        uses: shipa-corp/shipa-gh-action@0.0.1
        env:
          SHIPA_TOKEN: ${{ secrets.SHIPA_TOKEN }}
          SHIPA_HOST: ${{ secrets.SHIPA_HOST }}
        with:
          shipa-action: './dev-app/dev-app.yml'

  deploy_prod:
    runs-on: ubuntu-latest
    name: Deploy Production Apps
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy Prod Application
        uses: shipa-corp/shipa-gh-action@0.0.1
        env:
          SHIPA_TOKEN: ${{ secrets.SHIPA_TOKEN }}
          SHIPA_HOST: ${{ secrets.SHIPA_HOST }}
        with:
          shipa-action: './prod-app/prod-app1.yml'

This definition will:

Check out the application definition
Connect to your Shipa Cloud account using the Host and Token secrets defined before
Deploy your application

Once you save the file, GitHub will start the action and perform the deployment.

Application Dashboard

One of the common issues developers face when deploying on Kubernetes is understanding and managing their applications. Since applications on Kubernetes are a group of independent object definitions in the cluster unless you spend a considerable amount of time learning about each object and how to support it, it becomes complex to manage applications post-deployment,. and as a result, you start depending on the DevOps team to help you support your applications.

Shipa will also help you here.

Once the deployment is complete, head back to your Shipa dashboard and click on “Applications”.

Here you will see your application listed and, if you click on it, you will see all details your need to understand and support your application, including the endpoint you can use to access your application:

Shipa will also give you a detailed view of your application dependency map and network policy. You can see both by clicking on the “Application Map” icon

Conclusion

In just a few steps, you have set up an application-focused pipeline. This will allow you and your team to quickly adopt Kubernetes without spending time dealing with the underlying infrastructure complexities.

Not only that, but you have set up a free pipeline. Who doesn’t like a developer-friendly free pipeline? :)

Creating a local dev environment for Kubernetes with $0 cost

Bruno — Fri, 12 Nov 2021 17:35:11 +0000

Embracing any new technology stack can certainly be a journey. No matter if this is your first time using Kubernetes or you have been on the Google Borg Team.

This post will show you how to create a Kubernetes cluster, add it an application platform (Shipa), and start deploying applications with $0 cost.

We will leverage minikube and a free Shipa Cloud account.

Kubernetes Pre-Reqs

The first part is for us to create a local Kubernetes Cluster, where you can deploy applications to. A quick and free option we will use is minikube on your local machine.

If you are using a Mac, installing minikube can be accomplished by leveraging Homebrew.

Once Homebrew is installed, run:

brew install minikube

If using a new variant of Mac OS, an easy hypervisor to use for minikube is HyperKit. You can set minikube to leverage HyperKit. If you have not installed HyperKit before, Homebrew can take care of that also for you. Potentially you might have to install the machine driver if the brew formulae does not have it as a dependency.

brew install docker-machine-driver-hyperkit #optional
brew install hyperkit

Once HyperKit is installed, you can wire minikube to leverage HyperKit.

minikube config set driver hyperkit

Lastly, depending on your machine size you can make dedicate more resources to minikube. For example I would like 8 gigs of memory dedicated to minikube.

minikube config set memory 8128

Now you are all set to start your minukube cluster.

minikube start

With minukube up and running, you can run a kubectl command to validate. Homebrew would have also laid down kubectl for you if installing minkube from Hoembrew.

kubectl get nodes

Now you are all set to create your Shipa Cloud account.

Getting Started with Shipa Cloud

Our goal is to deploy and manage our applications without dealing with the underlying complexities that Kubernetes impose, so we will use Shipa Cloud for that.

You can sign up for a free account here

There are a few core concepts to work through. The first item that you will need to define is a Framework. A Shipa Framework is the lifeblood of your Shipa Configuration housing all the controls and policies.

Shipa Cloud -> Frameworks + Create Framework -> Basic

Creating a basic Framework for the example, just name your Framework “myfirstframework”. By default, you have access to a Plan and Team. The defaults for the example are fine.

Once you click Create, your Framework will be available.

Wiring Your Kubernetes Cluster to Shipa Cloud

You will need a few pieces of authentication from your minikube instance to connect it to Shipa Cloud.

Shipa Cloud will need an accessible address to your cluster, a Kubernetes authentication token, and CA Certificate.

Public URL – ngrok

If you run the cluster-info command on your local minukube instance, you will get a local to your network address.

kubectl cluster-info | grep 'Kubernetes' | awk '/http/ {print $NF}'

Leveraging a service like ngrok, you can expose your local instance, more specifically the Kubernetes API. This guide on ITNEXT is really good for getting started. For evaluation purposes only, you can also expose the Kubernetes API. We will be doing that for this example.

Sign up and Install ngrok

You can sign up for a free account with ngrok. Installing the ngrok client is easy with homebrew by running:

brew install –cask ngrok

Once installed, you can head to the ngrok setup page and run the authorization command e.g “Connect your account:”

Then: ngrok authtoken <your_token>

Once that is connected, you can leverage an HTTP proxy for the Kubernetes API

kubectl proxy --disable-filter=true

Then can fire up ngrok to front the traffic over your localhost and the default Kubernetes API Port e.g 8001.

ngrok http 8001

Grab the HTTP forwarding address and can save that for the Shipa Cloud Cluster configuration.

Kubernetes Auth Token

Creating an authorization token based off a Kubernetes role is straightforward. The Shipa Documentation for connecting a cluster gives the needed manifest to create the role and base the token off of.

Create the shipa-admin-service-account.yaml file with the following content:

Then apply the manifest.

kubectl apply -f shipa-admin-service-account.yaml

With the service account created, you can grab the authorization token. Can re-run the below command when it is time to copy and paste into Shipa Cloud.

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep shipa-admin | awk '{print $1}')

You can also grab the CA Certificate for service account by running the following command. Similarly can re-run when needed to copy and paste into Shipa Cloud.

kubectl get secret $(kubectl get secret | grep default-token | awk ‘{print $1}’) -o jsonpath='{.data.ca\.crt}’ | base64 –decode

Adding the Cluster

Once you have the three needed pieces, you can add the cluster to Shipa Cloud.

Shipa Cloud -> Clusters + Add Cluster

Can name the cluster “myminikube” and leverage your framework you created earlier e.g “myfirstframework”.

Click Next and fill out the the connectivity information [HTTP address, token, and certificate] that was just created.

Once you click Next, your Cluster will be available!

Once your cluster is available, the world is your oyster and you are ready to start deploying your apps without all the Kubernetes related complexity.

Leveraging Shipa Cloud to help drive engineering efficiency across the application stack is now possible. With the wide paintbrush that Shipa Cloud offers, the art of the possible is great.

Nodejs App From Code To Kubernetes Cluster

Bruno — Tue, 02 Nov 2021 00:50:27 +0000

TL;DR

Ketch automatically builds Docker images from your application source code
Ketch saves you time by creating all the required components to run your application on Kubernetes and exposing it through an endpoint without you dealing with infrastructure

The Pressure to Deliver

Many of us now have to deploy our applications on Kubernetes.

While this is great and introduces you to an opportunity to learn new technologies, the reality is that you are often swamped with work, under pressure to deliver your applications, and you want to go from ‘code to application’ as fast as possible.

What conflicts with that goal is that Kubernetes introduces different infrastructure-level concepts and requirements that take our time away from delivering our application code.

Most of us had an opportunity to experience Heroku. From a developer’s perspective, the experience was great, and we could go from ‘code to application’ fast and without dealing with infrastructure complexity.

So how can we get the same level of experience but on top of Kubernetes, giving our Ops team the freedom to adopt Kubernetes but still maintain an application layer on top of it to guarantee developer experience?

This article will show you how you can get a starter NodeJS server deployed on Kubernetes. The goal is to not deal with infrastructure complexities and not even have to build a Docker file, going from ‘code to application.’

Prerequisites

You need NodeJS installed to start development
Docker in your local machine
You need to be logged into your container registry
Access to a Kubernetes cluster and kubectl configured
Ketch installed and available in that cluster
Ketch CLI available in your local machine
You have a framework created in Ketch where you will deploy your application.

For the Kubernetes cluster, I will be using a GKE (Google Kubernetes Engine) I have set up, but you can use local clusters directly from your laptops, such as K3s or Minikube.

For Ketch, once you have your cluster available and kubectl access configured, you can quickly install Ketch by following the instructions here

Step 1: Initializing the Node Application

First, create a separate directory.

From within the directory, you can initialize the project with npm (Node Package Manager).

Running npm init will prompt you with basic configuration questions, such as your project name, version, and others. Keeping the default values is good enough for our sample application.

❯ npm init
This utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help init` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.json file.

Press ^C at any time to quit.
package name: (nodejs-sample) 
version: (1.0.0) 
description: 
entry point: (index.js) 
test command: 
git repository: 
keywords: 
author: 
license: (ISC) 
About to write to /Users/brunoandrade/ketch/apps/nodejs-sample/package.json:

{
  "name": "nodejs-sample",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Is this OK? (yes) 

~/ketch/apps/nodejs-sample ❯

Step 2: Installing Express

Next, you will install Express. You will leverage the Express framework to build web applications and APIs. Use npm to install it.

❯ npm install express -save

added 50 packages, and audited 51 packages in 2s

found 0 vulnerabilities

The code above imports the Express module using a require function to return an object to configure your application.

Step 4: Deploying the Code

This is the fun part, having your application deployed directly from code into Kubernetes. Ketch will automatically build the Docker image for you, push it to your container registry of choice, create the required Kubernetes objects to run your application, and create an endpoint where you can access your application.

If you are using Kubernetes directly, you would need to learn and deal with services, deployments, and more, but because you are using Ketch, you will do it all without dealing with any of that!

ketch app deploy nodejs-sample . -i shiparepo/nodejs-sample:0.1 -k dev-framework

Breaking down the command above:

You use App deploy to deploy your application
Nodejs-sample is the name of the application
The ‘.’ is the path to your application source code
‘-i shiparepo/nodejs-sample:0.1’ is the name and version of the image I want Ketch to use when creating and pushing the Docker image to my registry.
Use the framework you created before with the ‘-k dev-framework’ flag

Step 5: Checking your Application

Now, you can check your application deployment status and endpoint by running the ketch app list command.

❯ ketch app list
NAME             FRAMEWORK         STATE          ADDRESSES        BUILDER                                                         
nodejs-sample    dev-framework     1 deploying    http://nodejs-sample.35.230.16.206.shipa.cloud    heroku/buildpacks:20

In the result, you can see that Ketch automatically configured the ingress controller and created the endpoint for your application.

Step 6: There is No Step 6 🙂

You have successfully deployed a sample NodeJS application on Kubernetes!

The team is excited about enabling developers to focus on their application code instead of infrastructure. We would love it if you could show your support by starring the project on GitHub and sharing this article with your teammates.

Deploying applications on Kubernetes using TypeScript

Bruno — Sat, 16 Oct 2021 23:32:10 +0000

There is no doubt that YAML has developed a reputation for being a painful way to define and deploy applications on Kubernetes. The combination of semantics and empty spaces can drive some developers crazy.

As Kubernetes advances, is it time for us to explore different options that can support both DevOps and Developers in deploying and managing applications on Kubernetes?

Using code to define ... code ...?

Pulumi: Modern infrastructure as code for developers, a.k.a the new kid on the block.

Pulumi targets the widespread infrastructure as code (IaC) space but using a different approach. It allows developers to define infrastructure using their language of choice, such as TypeScript, JavaScript, Python, and others, instead of a proprietary language, such as HCL, from our friends at HashiCorp.

It is an exciting approach that can benefit teams when scaling the management and evolution of infrastructure since it’s easier to find folks in your group who can help write, manage, and extend the infrastructure as code definitions using existing languages.

Extending Ketch

Although the approach taken by Pulumi is intriguing, the way it deploys applications on Kubernetes today is very “infrastructure-focused.” What I mean by that is that Pulumi requires developers to define the entire Kubernetes manifest and object, as they would do with Helm, but using their preferred language.

While it may bring some initial benefits, it still requires developers to know how to define the objects in Kubernetes in detail.

Instead, by combining the application-focused approach from Ketch with the IaC model from Pulumi, developers can have an application-focused layer they can leverage to quickly deploy their applications without getting into the underlying infrastructure details exposed by Kubernetes.

We will go through the steps to deploy an application using Ketch and Pulumi but you can find additional details about the plugin here:

Provider documentation

Installing Ketch

You can find detailed information on how to install Ketch here

Installing The Ketch Provider For Pulumi

Download Ketch’s resource plugin for Pulumi here

Once downloaded, move it to your local Pulumi path:

mv pulumi-resource-ketch $HOME/.pulumi/bin

Now, add Pulumi to your PATH by using the command below:

export PATH=$PATH:$HOME/.pulumi/bin

Deploying an Application

With Ketch and the provider for Pulumi installed, you can now deploy a sample application.

For Ketch to deploy applications, we first need to create a framework. Frameworks in Ketch translate to a namespace in your cluster, and when deploying applications targeting that framework, they will be deployed to the created namespace.

Let’s initialize Pulumi, so we can get started. You can do this by running:

pulumi new typescript

As a result, Pulumi will create the file structure required for you to run Ketch and Pulumi:

Now, let’s create the Ketch framework definition file. You can edit the index.ts file and add the following content:

import * as pulumi from "@pulumi/pulumi";
import * as ketch from "@shipa-corp/kpulumi";

const item = new ketch.Framework("dev-framework", {
    framework: {
        name: "dev",
        ingressController: {
            className: "istio",
            serviceEndpoint: "1.2.3.4",
            type: "istio",
        }
    }
});

export const frameworkName = item.framework.name;

const app = new ketch.App("bulletin-app", {
    app: {
        name: "bulletin-app",
        image: "docker.io/shipasoftware/bulletinboard:1.0",
        framework: "dev",
    }
});

export const appName = app.app.name;

With the index.ts file updated, install the required npm package using the command below:

npm i @shipa-corp/kpulumi

Now, just run the command below to have both your framework and application deployed:

pulumi up

The output above shows that both the framework and the applications were deployed.

You can check the framework by using the command below:

ketch framework list

As mentioned above, when you create a framework, Ketch automatically creates a namespace for it in your cluster (you can also instruct Ketch to use an existing namespace instead)

You can also check the status of your application and the endpoint to access it by using the command below:

ketch app list

If we access the endpoint created above, we can see our application’s web interface:

Conclusion

By combining Ketch and Pulumi, you can improve the developer experience when deploying applications on Kubernetes.

We would love to hear your feedback and input to continue improving Ketch and build additional providers.

Support The Project

Help support Ketch by giving it a GitHub star!

Deploying a Python machine learning app on Kubernetes

Bruno — Sun, 12 Sep 2021 01:26:51 +0000

Build and deploy simple machine learning data science web app in Python using the streamlit library in Kubernetes, without knowing Kubernetes!

As a Data Scientist or Machine Learning Engineer, it is extremely important to be able to deploy our data science project using microservices and Kubernetes, as this helps to complete the data science life cycle and our infrastructure teams to continue evolving the infrastructure.

Traditional deployment of machine learning models can become a daunting and/or time-consuming task if you are new to microservices and Kubernetes, so the goal of this article is to enable you to quickly deploy an ML application without dealing with the underlying Kubernetes infrastructure complexity.

Requirements

To follow through this article, you will need:

A Kubernetes cluster
Ketch installed and configured. You can find more details here: https://learn.theketch.io/docs/getting-started
Since we will be deploying our application from the source, you need to log in through your terminal to your Docker registry.
Both Ketch and Kubernetes CLI configured in your terminal
A Ketch framework that we can use to deploy our application. You can find more information here: https://learn.theketch.io/docs/getting-started#creating-a-framework

Overview of our application

Today, we will be building a simple machine learning-powered web app for predicting the class label of Iris flowers as being setosa, versicolor and virginica.

This will require the use of three Python libraries namely streamlit, pandas and scikit-learn.

Let’s take a look at the conceptual flow of the app that will include two major components: (1) the front-end and (2) back-end.

In the front-end, the sidebar found on the left will accept input parameters pertaining to features (i.e. petal length, petal width, sepal length and sepal width) of Iris flowers. These features will be relayed to the back-end where the trained model will predict the class labels as a function of the input parameters. Prediction results are sent back to the front-end for display.

In the back-end, the user input parameters will be saved into a dataframe that will be used as test data. In the meantime, a classification model will be built using the random forest algorithm from the scikit-learn library. Finally, the model will be applied to make predictions on the user input data and return the predicted class labels as being one of three flower type: setosa, versicolor or virginica. Additionally, the prediction probability will also be provided that will allow us to discern the relative confidence in the predicted class labels.

Web application code

You can find the complete application code available on https://github.com/brunoa19/ml-iris-app

Okay, so let’s take a look under the hood and we will see that the app that we are going to be building today:

import streamlit as st
import pandas as pd
from sklearn import datasets
from sklearn.ensemble import RandomForestClassifier

st.write("""
# Simple Iris Flower Prediction App
This app predicts the **Iris flower** type!
""")

st.sidebar.header('User Input Parameters')

def user_input_features():
    sepal_length = st.sidebar.slider('Sepal length', 4.3, 7.9, 5.4)
    sepal_width = st.sidebar.slider('Sepal width', 2.0, 4.4, 3.4)
    petal_length = st.sidebar.slider('Petal length', 1.0, 6.9, 1.3)
    petal_width = st.sidebar.slider('Petal width', 0.1, 2.5, 0.2)
    data = {'sepal_length': sepal_length,
            'sepal_width': sepal_width,
            'petal_length': petal_length,
            'petal_width': petal_width}
    features = pd.DataFrame(data, index=[0])
    return features

df = user_input_features()

st.subheader('User Input parameters')
st.write(df)

iris = datasets.load_iris()
X = iris.data
Y = iris.target

clf = RandomForestClassifier()
clf.fit(X, Y)

prediction = clf.predict(df)
prediction_proba = clf.predict_proba(df)

st.subheader('Class labels and their corresponding index number')
st.write(iris.target_names)

st.subheader('Prediction')
st.write(iris.target_names[prediction])
#st.write(prediction)

st.subheader('Prediction Probability')
st.write(prediction_proba)

Copy and create this code using the name iris-ml-app.py

Application requirements

For our application to run, we will need to ensure that requirements are in place.

Application libraries

Let’s start with the Python libraries we need:

Create a file called requirements.txt in the same directory as the application code above. Here is the content of the file:

streamlit
pandas
scikit-learn

These 3 lines will have Ketch install these libraries when the Docker image is built for our application.

Exposing port

By default, the Python streamlit library exposes our application through port 8501, so we will need to ensure Kubernetes understands that it should use this port for our application.

To do that, create a file called ketch.yaml in the same directory as the previous files. Here is the content of the file:

kubernetes:
  processes:
    web:
      ports:
        - name: iris-app
          protocol: TCP
          port: 8501
          target_port: 8501

The content above will tell Kubernetes to assign port 8501 to our application process. Save the file

Application Process

Last, we need to define how our application should be started once its deployed. For that, create a file called Procfile in the same directory as the previous files. Here is the content of the file:

web: streamlit run iris-ml-app.py

The command above will tell Ketch that it should use the streamlit library to run our Iris app code created before. Save the file

Deploying and running the application

Now that we have:

Our iris-ml-app.py code
Our requirements.txt file with all library dependencies
The ketch.yaml file assigning a port to expose our app
A Procfile to tell Ketch how to start our application

We can then deploy our application. You can deploy your application using the command below:

ketch app deploy iris . -i shiparepo/iris:latest -k dev

This command will:

Create and deploy our application using iris as the application name
The "." indicates that it will use the source code and files available in the directory where you are running this command from
It will automatically create a Docker image and store it in my registry with the name iris. Keep in mind that you should adjust this to reflect your docker registry name
It will use the dev framework previously created to deploy our application

The deployment process will take a couple of minutes as it will create and store the Docker image in your registry.

Once the deployment is finished, you can see your application status using the command below:

ketch app list

As part of the output of the command, you can see that Ketch also automatically created the endpoint address where you can access your application. Accessing that, we can see our Iris application ready to be used:

Conclusion

That's it!

You have deployed your Python machine learning application on Kubernetes without having to deal with the underlying complexities that Kubernetes might introduce.

By using Ketch, you get your applications and models deployed quickly while allowing your infrastructure team to continue the adoption of microservices and Kubernetes.