Forem: Aditya Joshi

Extending Kubectl with Plugins

Aditya Joshi — Sat, 12 Nov 2022 17:16:03 +0000

Plugins are software extensions that can be loaded on a program to improve its functionality. kubectl is a tool that allows you to perform literally any and all Kubernetes-related tasks. This tool is used to make a list of all pods in the cluster and debug nodes. kubectl’s functionality can be extended with the help of the plugin. You can create kubectl plugins to solve some of the use cases that are complex in nature.

But what is the kubectl plugin?

A plugin is a standalone executable file, whose name begins with kubectl-. To install a plugin, move its executable file anywhere on your PATH. Krew is the package manager for kubectl plugins as well as Kubernetes SIG that aims at solving the package management issue for kubectl.

Criteria to be a plugin

There are two important criteria to qualify as a kubectl plugin

Plugin binary name must start with kubectl- followed by the name of your plugin. Ex kubectl-decode, kubectl-count .
The plugin binary must be present in the PATH variable so that kubectl can identify it as the plugin.

Usecase

We will be creating a kubectl plugin that will decode the Kubernetes secrets. We all know that Kubernetes stores the Secrets in the base64 decoded format and if have to see the values of those secrets we need to extract the base64 encode value and then decode with plain text.

Kubernetes secret stored in base64 format

Expectation

Let's first set up the expectations/expected output from the plugin we will develop. we want the plugin to return the base64 encoded secrets in plain text. Also, it should support a way to specify the Kubernetes namespaces.

Implementation

For this article, we are going to create this plugin using the shell script but the same can be done using any programming language.

We want this plugin to work like how a normal kubectl command works, where the user specifies the operation (create, update, delete and get) and the resource (pod, deployment, configmap, secret), also user can provide the namespace over which he wants to perform that operation, but if no namespace is provided default namespace is considered.

I have made a video on creating kubectl plugins using GoLang

We will create a text file with the name kubectl-decode , where decode is the name of our plugin.
Next, will use the kubectl command itself to get the secret and with the help of go-template, we can iterate over the secrets and decode them.
Put the plugin in the PATH variable so that kubectl can recognise it as the plugin.

#!/bin/bash
if [ $# -lt 1 ]  
then  
  echo "invalid argument "  
  exit 1  
fi  
NAMESPACE="default"  
if [ "$2" = "-n" ]  
then  
   if [ $# -eq 3 ]  
   then  
     NAMESPACE=$3  
    fi  
fi
kubectl get secrets "$1" -o go-template='{{range $k,$v := .data}}{{printf "%s: " $k}}{{if not $v}}{{$v}}{{else}}{{$v | base64decode}}{{end}}{{"\n\n"}}{{end}}' -n "$NAMESPACE"

Sum up

When we make use of this kubectl, we can simplify tedious tasks to be very simpler. kubectl plugins may look complex to you but trust me they will make your life much easier.

There are some shortcoming that comes with the bash-based plugins but those can be easily solved when you will use any programming language like go, java, or nodejs.

In this article we learned the basics of the kubectl plugin and what it takes to be a kubectl plugin, and also saw how we can create a kubectl plugin.

Resources

[Implementation] A full implementation for this pattern in this GitHub repo
[Video] A detailed video explanation can be found here.
[GoLang] implementation can be found here

Thanks for reading and I hope you find this useful!

GraphQL with NodeJs and MongoDB

Aditya Joshi — Sat, 05 Dec 2020 16:23:54 +0000

What is GraphQL - A Query Language for APIs?

GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data.
GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.

Most applications today need to fetch data from a server where that data is stored in a database. It's the responsibility of the API to provide an interface to the stored data that fits an application's needs.

GraphQL is often confused with being a database technology. This is a misconception, GraphQL is a query language for APIs - not databases. In that sense it's database agnostic and effectively can be used in any context where an API is used.

A more efficient Alternative to REST

REST has been a popular way to expose data from a server. When the concept of REST was developed, client applications were relatively simple and the development pace wasn't nearly where it is today. REST thus was a good fit for many applications. However, the API landscape has radically
changed over the last couple of years. In particular, three factors have been challenging the way APIs are designed:

1. Increased mobile usage creates the need for efficient data loading

Increased mobile usage, low-powered devices, and sloppy networks were the initial reasons why Facebook developed GraphQL. GraphQL minimizes the amount of data that needs to be transferred over the network and thus majorly improves applications operating under these conditions.

2. Variety of different frontend frameworks and platforms

The heterogeneous landscape of frontend frameworks and platforms that run client applications makes it difficult to build and maintain one API that would fit the requirements of all. With GraphQL, each client can access precisely the data it needs.

3. Fast development & expectation for rapid feature development

Continuous deployment has become a standard for many companies, rapid iterations and frequent product updates are indispensable. With REST APIs, the way data is exposed by the server often needs to be modified to account for specific requirements and design changes on the client-side. This hinders fast development practices and product iterations.

Over the past decade,REST has become the standard (yet a fuzzy one) for designing web APIs. It offers some great ideas, such as stateless servers and structured access to resources. However, REST APIs have shown to be too inflexible to keep up with the rapidly changing requirements of the clients that access them.

GraphQL was developed to cope with the need for more flexibility and efficiency! It solves many of the shortcomings and inefficiencies that developers experience when interacting with REST APIs.

Schema & Type System in GraphQL

GraphQL uses a strong type system to define the capabilities of an API. All the types that are exposed in an API are written down in a schema using the GraphQL Schema Definition Language (SDL). This schema serves as the contract between the client and the server to define how a client
can access the data.

Once the schema is defined, the teams working on frontend and backends can do their work without further communication since they both are aware of the definite structure of the data that's sent over the network.

Frontend teams can easily test their applications by mocking the required data structures. Once the server is ready, the switch can be flipped for the client apps to load the data from the actual API.

GraphQL has its own type system that's used to define the schema of an API. The syntax for writing schemas is called Schema Definition
Language(SDL).

Here is an example of how we can use the SDL to define a simple type called Person:

type Person { name: String! age: Int!}

This type has two fields, they're called name and age and are
respectively of type String and Int. The ! following the type means that
this field is required.

The schema is one of the most important concepts when working with a
GraphQL API. It specifies the capabilities of the API and defines how
clients can request the data. It is often seen as a contract between
the server and client.

Generally, a schema is simply a collection of GraphQL types. However,
when writing the schema for an API, there are some special root types:

type Query { \... } type Mutation { \... } type Subscription { \... }

Mutation

In REST, any request might end up causing some side-effects on the
server, but by convention it\'s suggested that one doesn\'t use GET
requests to modify data. GraphQL is similar - technically any query
could be implemented to cause a data write. However, it\'s useful to
establish a convention that any operations that cause write should be
sent explicitly via a mutation.

Why do we need GraphQL?

With traditional REST API calls, we didn't have the ability for the
client to request a customized set of data. In contrast, GraphQL allows
clients to define the structure of the data required, and the same
structure of the data is returned from the server. This prevents
excessively large amounts of data from being returned. However, it also
adds a layer of complexity that may not be applicable for simple APIs.

Moreover, maintaining multiple endpoints is difficult in REST
architecture. When the application grows, the number of endpoints will
increase, resulting in the client needs to ask for data from different
endpoints. GraphQL APIs are more organized by providing structured types
and fields in the schema while using a single API endpoint to request
data.

What is Graphql-compose?

Toolkit for generating complex GraphQL schemas in Node.js.
Graphql-compose provides a convenient way to create GraphQL Schema. This schema is completely compatible with
GraphQL.js.

graphql-compose -- provides a type registry with a bunch of methods for
programmatic schema construction. It allows not only to extend types but
also to remove fields, interfaces, args. If you want to write your graphql
schema generator -- graphql-compose is a good instrument for you.

provides methods for editing GraphQL output/input types (add/remove
fields/args/interfaces)
introduces Resolvers -- the named graphql fieldConfigs, which can be
used for finding, updating, removing records
provides an easy way for creating relations between types via
Resolvers
provides converter from OutputType to InputType
provides projection parser from AST
provides GraphQL schema language for defining simple types
adds additional types Date, JSON

Moving to the code

Let's start developing. First, we will create a new folder and initialize
our package.json file. Then add the following packages with the command
listed below:

npm init --y npm i express graphql express-graphql mongoose graphql-compose-mongoose graphql-compose

our folder structure is like this

Now in the server.js, we will set up a basic express server and will import the graphqlHTTP from express-graphql.
We will also set up /graphql route and will define the graphql middleware and will set the graphql graphqlSchema.
The beauty of the graphql-compose is that it will auto-generate the graphql scheme, mutations, and query for us based on our mongoose schema.

Let's create our mongoose models, we'll be creating a book model and user model

Now it's time to create GraphQL Scheme for the user model, where all the queries and mutations are defined.

you can see that the definition of all the resolvers is automatically generated by the graphql-compose-mongoose plugin like findById, findOne, createOne, etc. You can find all the build-in mongooseResolvers

This is how our GraphQL Scheme for book looks like

and now its time to build our schemas

Once this is done now its time to run our application
node start src/server.js and navigate to http://localhost:5000/graphql
you can insert the data using the mutations

To get the data use a query like this
.
You can find the documentation on the GraphQL playground
Link to source code link

Hyperledger Fabric 2.2 Tutorial

Aditya Joshi — Fri, 04 Dec 2020 04:19:20 +0000

Hyperledger Fabric v2.2

Overview

This article shows how to setup a Hyperledger Fabric Network (HLF) v2.2, deploy chaincode, invoke, and query chaincode. We first give a high-level walk-through of the process, and later use Test Network provided in HLF examples to demonstrate the whole process. The script provided in Test Network makes bringing the blockchain Network along with Fabric CA servers much easier and we can use the crypto-material to perform the demonstration.

High-level Walk-through

Generating crypto-material from the organizations and orderer (Org1, Org2, and Orderer) using Fabric CA server.
Generating channel artifacts eg. system channel genesis block, channel transaction, channel genesis block, etc,).
Updating anchor peers.
Creating a channel.
Joining the channel.
Deploying chaincode on the channel.
Invoke or query the chaincode.

Prerequisites

Golang
Docker
Nodejs

Bring Up Network

Here we first download the HLF binaries along with fabric examples. We will be using the Test network provided in the fabric examples. Our network will consist of Two Organization with one peer each, One orderer node, Three CA server (one for each organization and third for orderer), Two couchdb instances for state database(one for each peer)

Download the fabric binaries.

curl -sSL https://bit*.ly/2ysbOFE *|** bash -s -- 2.3*.0 1.4.*9
Set the environment variable

cd fabric-samples && export PATH=$PWD/bin:$PATH
Once step 2 is completed, go to the test-network folder.

cd test-network
Run the command and pass the options according to your need. To check all the available options run ./network.sh help

help command

To start the network with Fabric CA Servers, CouchDB and creating a channel mychannel.

-ca: Use Certificate Authorities to generate network crypto material
-c: Name of channel to create (defaults to "mychannel”)
-s: Peer state database to deploy: goleveldb (default) or couchdb
up — Bring up Fabric orderer and peer nodes. No channel is created.
up createChannel: Bring up fabric network with one channel.
createChannel: Create and join a channel after the network is created

./network.sh up createChannel -ca -c mychannel -s couchdb

if everything goes well that at the end you can see something like this.

we have completed step 1 to step 5 in the **High-level Walk-through **section of this article.

Next step to deploy chaincode, in the example repository there are multiple chaincode

-ccn: Chaincode name. This flag can be used to deploy one of the asset transfer samples to a channel. Sample options: basic (default), ledger, private, sbe, secured
-ccl: Programming language of the chaincode to deploy: go (default), java, javascript, typescript
-verbose: Verbose mode

You can explore all the available options in the help section

./network.sh deployCC -ccn basic -ccl go -verbose

once the chaincode deployment is successful you will get output like this

Now over chaincode deployment is done and we will now invoke and query the chaincode. we will be using nodejs SDK to interact with the blockchain network.

cd ../asset-transfer-basic/application-javascript && npm install

node app.js

This script will register the user **appUser *into the FileSystemWallet and will invoke the *InitLedger** function of the chaincode and this function will create 6 records into the ledger. After this it call the function *GetAllAssets **and this function returns all the records stored in the ledger, we can access the CouchDB via the fauxton UI ( peer0.org1=> ***http://localhost:5984/_utils/# and **peer0.org2=> **http://localhost:7984/_utils/#). After that it call **CreateAsset **which add a new record into the ledger.

And we have out HLF network up and running.

Summary

I hope this article provides insight into Setting up Fabric Network v2.2 using the Fabric CA Servers along with CouchDB as the state database.