Using Shipa.io to simplify Kubernetes adoption

11 min readFeb 5, 2021

Kubernetes is undoubtedly one of the fastest growing open source projects of modern times. It was designed by Google (based on Borg) and was initially released over 6 years ago (in 2014). At that time, containers were growing in popularity with the release of Docker in 2013— which has not invented the concept of “containers” but made it more accessible to the broader community.

One of the beauties of Kubernetes is that developers can run applications in the same scalable ecosystem that has been used by Google for many years. The downside, though, is the complexity that arises when deploying a simple application that should scale. It is not enough to just build the application itself, but developers also have to spend time and write a variety of YAML templates that define Kubernetes resources. It shouldn’t be like that, and it doesn’t have to be.

In this article, we’ll have a closer look at shipa.io and how it can help developers to get off the ground faster, stop writing YAML templates and start shipping applications to Kubernetes.

What is shipa.io?

Shipa is an Application Management Framework designed to take the infrastructure management burden off the developers’ shoulders. With Shipa, Developers can finally focus on building their applications and shipping them without having to become Kubernetes experts.

To make a comparison with Docker, think how much abstraction Docker brings to Developers. They can easily run “containers” without fully understanding Linux kernel features such as namespaces and cgroups. All they have to do is to build a Docker image and run the command docker run (with a few options/flags). And that’s the exact kind of abstraction that Shipa brings to Developers, but in the Kubernetes space. Let’s see how with a little demo.

Prerequisites

If you would like to follow along, you will first need to deploy your own Kubernetes cluster. This article will leverage Amazon EKS, but Shipa can be deployed to any Kubernetes cluster (Minikube, EKS, GKE, AKS, RKE, OKE and even On-Premise). Read the Installation Requirements documentation to understand some of the requirements, such as container runtime, CPU, memory and networking.

Secondly, you will need to download the Helm command-line tool as we will be using Helm to install Shipa on Kubernetes.

Installing Shipa

Installing Shipa on Kubernetes is as easy as 1, 2, 3:

Create a namespace for Shipa’s components:
$ kubectl create namespace shipa-system
Set an email address and password to log in to Shipa:
$ cat > values.override.yaml << EOF auth: adminUser: myemail@example.com adminPassword: mySecretAdminPassw0rd EOF
Add Shipa’s Helm repository and deploy Shipa:
$ helm repo add shipa-charts https://shipa-charts.storage.googleapis.com $ helm install shipa shipa-charts/shipa -n shipa-system —-timeout=1000s -f values.override.yaml

You can watch Shipa being deployed by listing all the pods in the shipa-system and shipa namespaces:

$ kubectl get pods --all-namespaces -w | grep shipa

Once Shipa’s components are up and running, install the Shipa CLI in your system:

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

To verify that Shipa has been installed successfully, run shipa version.In this article, I will be using version 1.2.0 (the commands and outputs might look different depending on when you’re reading this and which version you’re using).

Adding a Target to Shipa

Before you start interacting with Shipa using the CLI, you need to configure a target (which basically tells the CLI where to find Shipa’s backend in your Kubernetes cluster). To configure a target, you first need to obtain the IP address (or DNS name) of Shipa’s Nginx server. To do that, run the following:

The code above obtains the DNS name of the Elastic Load Balancer (if running on AWS) that is serving traffic to an Nginx server, which, in turn, serves traffic to Shipa. The output of the shipa target-add command will look similar to:

New target shipa -> https://XXXXXXXXXXXXXX.us-east-1.elb.amazonaws.com:8081 added to target list and defined as the current target

PS: Note that you can run either shipa target-add or shipa target add

Accessing the Shipa Dashboard

After a few minutes, you should be able to access the dashboard. Copy the shipa target address without the port (https://XXXXXXXXXXXXXX.us-east-1.elb.amazonaws.com) and paste it in your Web Browser address bar, setting the port to 8080 (i.e. https://XXXXXXXXXXXXXX.us-east-1.elb.amazonaws.com:8080). You should see the following:

In the page above, you should see Go to my Dashboard. Click on that link. The link will take you to the Dashboard and you will have to input the email address and password you set earlier.

Once you log in, this is how your Dashboard should look like:

In the main page, you will find information about your Kubernetes setup. In my case, my Kubernetes cluster is running on AWS (as highlighted by the yellow circle) and has 7 nodes. It also tells me where my applications are running. My cluster has been deployed to the Northern Virginia region, so that’s why you see a green circle on the east coast of the United States on the map.

Now that Shipa is all set up, let’s see how we can deploy applications to our cluster.

Adding a Platform

Shipa supports running applications written in multiple programming languages, which they call platforms. But before you can start using the CLI to configure your Shipa backend, you will need to also log in with the CLI using the email address and password you set earlier. Run the command shipa login and provide your email and password.

The first step before you can create an application on Shipa will be to add a platform using the command:

shipa platform add <PLATFORM>

Where <PLATFORM> can be go, java, python, ruby, etc. Check their documentation for all available platforms.

In this article, we will be deploying a Golang application, so let’s add the go platform:

$ shipa platform add go

Creating our first application on Shipa

Before you can deploy an application to Shipa, you need to tell Shipa the name of your application, the platform it requires as well as the team that owns the app.
When you installed Shipa, it automatically created two teams: shipa-admin-team and shipa-system-team.You can list the available teams using the comand:

$ shipa team list
+-------------------+------------------+------+
| Team              | Permissions      | Tags |
+-------------------+------------------+------+
| shipa-admin-team  | app              |      |
|                   | machine          |      |
|                   | team             |      |
|                   | service          |      |
|                   | service-instance |      |
|                   | plan             |      |
|                   | pool             |      |
|                   | cluster          |      |
|                   | volume           |      |
|                   | volume-plan      |      |
|                   | webhook          |      |
+-------------------+------------------+------+
| shipa-system-team | app              |      |
|                   | machine          |      |
|                   | team             |      |
|                   | service          |      |
|                   | service-instance |      |
|                   | plan             |      |
|                   | pool             |      |
|                   | cluster          |      |
|                   | volume           |      |
|                   | volume-plan      |      |
|                   | webhook          |      |
+-------------------+------------------+------+

Role-based access control (a.k.a RBAC) can be easily implemented in Shipa to give the necessary permissions to different teams. Let’s create a Golang application named hello-worldthat will be owned by theshipa-admin-team:

$ shipa app create hello-world go -t shipa-admin-team
App "hello-world" has been created!
Use app-info to check the status of the app and its units.

Deploying the Application

At this point, the application has been created (but not deployed) and even assigned an URL:

$ shipa app list
+-------------+-----------+--------------------------------------+
| Application | Status    | Address                              |
+-------------+-----------+--------------------------------------+
| dashboard   | 1 running | http://dashboard.<ELB>.shipa.cloud   |
+-------------+-----------+--------------------------------------+
| hello-world | created   | http://hello-world.<ELB>.shipa.cloud |
+-------------+-----------+--------------------------------------+

PS: The dashboard application was deployed as part of Shipa’s installation scripts.

There are a couple of things to note here:

Both the dashboard and hello-world apps sit behind the same Elastic Load Balancer, but have different subdomains
Both URLs are CNAME records in the shipa.cloud DNS zone.

First, the fact that both applications sit behind the same Elastic Load Balancer and have different subdomains means that Shipa is leveraging Ingress Controllers and Ingress resources. Secondly, the shipa.cloud DNS zone is not managed by you, meaning that this zone is not create in your AWS account’s Route53. Read this page if you wish to add your own subdomain.

Now it’s time to deploy our app. First, git clone the following repository: https://github.com/renansdias/golang-sample-app.git and cd into golang-sample-app. Now run:

$ shipa app deploy -a hello-world -f . Uploading files (0.02MB)... 100.00% Processing....... ok
go version go1.15.6 linux/amd64
Installing Go stable...
warning: ignoring symlink /home/application/src/current
go get .: path /home/application/src/current is not a package in module rooted at /home/application/src/current
Procfile not found. Using default Procfile
go build -o shipa-app
go: downloading github.com/gorilla/mux v1.6.2
please wait...
---- Pulling image to shipa ----
 ---> Process "web" found with commands: ["./shipa-app"]---- Rolling out deployment ----
 ----> Step 1:
 -----> Set target:
         all processes => 1 units
 -----> Update deployment 1:
          web => 1 units---- Updating units [web] ----
 ---> 0 of 1 new units created
  ---> hello-world-web-1-5c95f9d789-tl9xb - Successfully assigned shipa-system/hello-world-web-1-5c95f9d789-tl9xb to ip-10-0-106-135.ec2.internal [default-scheduler]
 ---> 1 of 1 new units created
 ---> 0 of 1 new units ready
  ---> hello-world-web-1-5c95f9d789-tl9xb - Pulling image "ad916f22c6ddf40138458a5a88688420-835229251.us-east-1.elb.amazonaws.com:5000/shipa/app-5126d4f8d07945c0a200721e821ef11c-hello-world:v1" [kubelet, ip-10-0-106-135.ec2.internal]
  ---> hello-world-web-1-5c95f9d789-tl9xb - Successfully pulled image "ad916f22c6ddf40138458a5a88688420-835229251.us-east-1.elb.amazonaws.com:5000/shipa/app-5126d4f8d07945c0a200721e821ef11c-hello-world:v1" [kubelet, ip-10-0-106-135.ec2.internal]
  ---> hello-world-web-1-5c95f9d789-tl9xb - Created container hello-world-web-1 [kubelet, ip-10-0-106-135.ec2.internal]
  ---> hello-world-web-1-5c95f9d789-tl9xb - Started container hello-world-web-1 [kubelet, ip-10-0-106-135.ec2.internal]
 ---> 1 of 1 new units ready
 ---> Done updating units
  ---> New routing settings:
        version: 1, total weight: 1OK
running autoscale checks

The command shipa app deploy basically sends the repository files to Shipa’s API, which builds an image that can run Golang binaries, and uploads it to Shipa’s own Docker registry (running on the same Kubernetes cluster). The Docker registry is sitting behind the same Load Balancer as the API, but listening to traffic on port 5000. Finally, Shipa creates Kubernetes resources to run and expose your application to the Internet.

To access the application, you will first need to get its address using the command: shipa app list. Alternatively, you can also run:

$ kubectl get ingress -n shipa-system | grep hello-world

And you should see the same URL. Copy the URL, head over to your Web Browser and paste the URL in the address bar. This is what you should see if you executed all steps correctly:

There it is! And if you want to access the Dashboard, you can easily do so by swapping hello-world for dashboard in the URL:

Visualizing Application Details

Another great feature that Shipa has is the ability to see lots of details about each one of your applications. In the dashboard, click on Applications on the left panel:

You will then see the applications you have deployed and the applications that have been deployed as part of Shipa’s installation, such as the dashboard:

Click on the hello-world application to see more information about it. The first thing you will see is the metadata of the application:

Here you will find a lot of useful information about the application, such as who owns it, which namespace it’s running on, how much CPU and memory it’s using, the URL that can be used to access it, as well as environment variables. You should also be able to see transactions such as requests per second, average response time, request latency and so on:

When it comes to monitoring, Shipa also displays basic monitoring information for the application such as CPU usage per container, memory usage per container, number of open connections and so on:

Finally, you can also find information about the application lifecycle:

On the left-hand side there’s information about the application’s timeline (when it was created, deployed etc), which can be extremely valuable for auditing. And on the right-hand side, you can see application logs and perform rollbacks. I love the fact that developers can easily roll back applications with a few clicks using Shipa’s dashboard. That’s a much better approach and less error-prone then using kubectl rollout to obtain the history of revisions and perform a rollback.

In summary, I think Shipa did a great job at elegantly displaying all this information. If Developers relied purely on kubectl, it would require them to know tens of commands to find all that out.

Conclusion

It is truly impressive how much burden was taken off my shoulders just to deploy two simple applications. I mean, did you even notice you didn’t write a single Dockerfile and you were able to containerize an application and run it on Kubernetes? Also, if you’re familiar with Name-based Virtual Hosting you know the setup is not something an inexperienced Kubernetes user can grasp within a minute or two. It takes time to fully understand how these components work together in a cluster. Moreover, I still think it’s valuable for Developers to understand how Kubernetes works, but that shouldn’t be a blocker to get started.

I am personally super excited about what the future holds for Shipa as I do believe it is a technology that makes Kubernetes tremendously accessible to many Developers. And don’t forget, like Kelsey Hightower once said: stop scripting and start shipping!