Install SigNoz via Docker Compose 💿

SigNoz is an open-source observability platform that’s perfect for this job, and it’s easy to deploy locally using Docker. Make sure you’re on a server or local machine with Docker installed and at least 4 GB of memory allocated to Docker, this ensures all required services can run smoothly without resource errors. Begin by opening your terminal and running:

git clone -b main https://github.com/SigNoz/signoz.git && cd signoz/deploy/
cd docker
docker compose up -d --remove-orphans

This will pull all the required images (if not already present) and spin up multiple coordinated containers, each serving a part of the observability platform, such as the UI, collector, storage database (clickhouse in this case), and query service. Verify containers are running:

docker ps

You should see containers like signoz/signoz-otel-collector, signoz/clickhouse-server, and signoz/signoz. Next, open your browser and visit:

http://localhost:8080

You should see the SigNoz dashboard ready to receive and visualise trace data from your instrumented applications. If anything doesn’t work as expected, for example, if containers fail to start or the UI isn’t accessible, be sure to consult the dedicated Signoz documentation for detailed troubleshooting and setup guidance.

Build a Simple Node.js Dice App 🎲

Before you can add tracing to your application, you’ll need something to instrument, and for this purpose, a simple dice roller service is perfect. It’s lightweight & easy to understand. The idea is to build a small Node.js server using the popular Express framework, which will respond to HTTP requests by returning random dice roll results. This gives us a nice, testable endpoint that we can later trace with OpenTelemetry. Create a folder for your project:

mkdir dice-app
cd dice-app
npm init -y
npm install express

Now that you have your project set up, you’ll want to create your actual application code. Make a new file in this folder named app.js, and save the following code into it:

const express = require('express');
const app = express();
const PORT = 3000;

app.get('/rolldice', (req, res) => {
  const rolls = parseInt(req.query.rolls) || 3;
  const results = Array.from({ length: rolls }, () =>
    Math.floor(Math.random() * 6) + 1
  );
  res.json(results);
});

app.listen(PORT, () => {
  console.log(`Server listening at http://localhost:${PORT}`);
});

Now we will run the application using the command below:

node app.js

You should see the message “Server listening at http://localhost:3000” confirming that it’s up and running. To test it, you can use your browser or a command-line tool like curl. For example, try running:

curl "http://localhost:3000/rolldice?rolls=5"

This sends a GET request to your server asking for 5 dice rolls. The server will respond with a JSON array of 5 random numbers between 1 and 6, simulating the roll of 5 dice. This is a simple but effective way to demonstrate a working service that can generate meaningful traffic.

Add OpenTelemetry Packages 📦

You now want automatic tracing. Install the needed OpenTelemetry libraries. These OpenTelemetry packages let you add tracing to your Node.js app: @opentelemetry/sdk-node is the core SDK to set up and manage tracing, @opentelemetry/auto-instrumentations-node automatically captures spans from popular Node.js libraries with minimal setup, and @opentelemetry/exporter-trace-otlp-proto sends collected trace data in the OTLP (protobuf) format to backends like the OpenTelemetry Collector or observability platforms. Use the following command:

npm install \
  @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-proto

Configure Tracing ⚙️

This code sets up OpenTelemetry tracing in a Node.js app by creating a NodeSDK instance configured to automatically capture spans from common libraries (like HTTP and Express). Create tracing.js in your root folder, where the dice roll app exists, with the following content:

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-proto');

const exporter = new OTLPTraceExporter({
  url: 'http://localhost:4318/v1/traces'
});

const sdk = new NodeSDK({
  traceExporter: exporter,
  instrumentations: [getNodeAutoInstrumentations()],
  serviceName: 'signoz-demo-dice-app'
});

sdk.start();

We capture spans from common libraries using getNodeAutoInstrumentations(), and to export those spans to an OTLP-compatible backend (like the OpenTelemetry Collector or SigNoz) at http://localhost:4318/v1/traces using the OTLPTraceExporter. By calling sdk.start() we initialise the tracer, enabling end-to-end tracing of requests in the signoz-demo-dice-app service for performance monitoring and debugging. This sets the service.name attribute for all traces, helping SigNoz group telemetry under “signoz-demo-dice-app”

Start the App with Tracing 🏁

OpenTelemetry must load before your application logic. To confirm so, run:

node --require ./tracing.js app.js

This command makes sure the tracing setup runs first by pre-loading tracing.js, so when app.js starts, tracing is already enabled for the whole app.

Send Some Test Traffic 🚦

To see tracing in action, we generate a few HTTP requests to our running app using these curl commands:

curl "http://localhost:3000/rolldice?rolls=10"
curl "http://localhost:3000/rolldice?rolls=2"
curl "http://localhost:3000/rolldice"

Each command simulates a user accessing the /rolldice endpoint on your server (running locally on port 3000). The optional rolls query parameter tells the app how many dice rolls to simulate.

View Data in the SigNoz Dashboard 📊

In SigNoz, you can now visualise these traces in the UI, analyse the duration and flow of requests, identify performance bottlenecks, or spot errors. This automatic capture ensures you don’t need to manually add tracing code for basic HTTP interactions; it just works out of the box once your instrumentation is set up. Return to:

http://localhost:8080

Navigate to the Traces tab. Under Traces, you can inspect details like timestamps, durations, and spans that show how each request flowed through your service.

You can view the Services. In this, you should now see “signoz-demo-dice-app” listed. Selecting our service from the panel will help you view a graphical representation of Latency, Rate, Apdex, Key Operations, etc.

Troubleshooting Checklist ✅

What’s Next? 🤔

Once you have basic tracing set up, you can further enhance your observability by adding metrics using the OpenTelemetry Metrics SDK to monitor things like request counts and latencies; capturing and correlating logs alongside traces for full context during debugging; deploying in a secure setup with authentication and encryption to protect your telemetry data; and adding custom spans in your code (for example, to trace critical workflows like a credit card payment process) to get deep, business-specific visibility into your application’s behavior.

Resource for You! 📚

• https://signoz.io/docs/instrumentation/opentelemetry-express/

• https://signoz.io/blog/distributed-tracing/

• https://signoz.io/blog/distributed-tracing-span/

Thanks for Reading ❤️

This setup sets the anchor for robust observability. From here, you can evolve your tracing, logs, metrics, and even multi-service pipelines, all with SigNoz as your single source of truth. I hope this walkthrough made the setup process clear and approachable. If you found this helpful, consider sharing it with your team so everyone can benefit from improved observability practices.

Understanding Multi-Container Setup and the Role of Volumes

When working with Kubernetes, splitting components into multiple containers provides modularity, cleaner deployment, and fault isolation. In my case, the Go-based backend was responsible for talking to the Kubernetes API and fetching logs, while the frontend container displayed the logs in a simple browser interface. Volumes played a key role in this setup, not for sharing application state but for persisting logs between restarts. When the backend fetched logs, they could be optionally saved to a mounted volume for easy backup or future parsing. This structure also opened possibilities for adding sidecars in the future to handle tasks like log parsing or storage. Multi-container pods ensure shared networking and volume space, making communication and data exchange between containers easier. Instead of exposing services externally for container-to-container communication, they can directly interact through shared localhost or volumes. It’s one of the best practices in Kubernetes for tight coupling and internal service dependencies.

Using the Kubernetes API from Inside the Container

Accessing the Kubernetes API securely from inside a pod required some configuration. Initially, I tried to directly call the API server using curl, but I faced authentication issues and SSL errors. After reading this guide, I realized that I needed a ServiceAccount, Role, and RoleBinding to enable secure access. I used a Go script to call Kubernetes APIs, relying on the token mounted inside the pod at /var/run/secrets/kubernetes.io/serviceaccount. This helped authenticate the API requests correctly. I also had to adjust the script’s environment variables using Docker’s ENV configuration instead of relying on shell scripting within the pod. The curl commands still didn’t work initially, but I fixed them using insights from another blog. Once these fixes were done, the Go backend was able to pull logs from pods successfully, proving that my setup and permissions were correct.

Creating the Backend in Go with a Command Executor

The first backend version was a simple Go program that ran a shell command and displayed its output on the /api/logs endpoint. To test the basic idea, I used the ls command inside the container and displayed the results on a webpage. This gave me confidence that the API server could run shell commands and serve output dynamically. Later, I replaced the ls command with actual Kubernetes API calls using the Go client SDK to fetch pod logs. I implemented routes /api/namespaces and /api/pods?namespace=X to allow users to list available namespaces and pods dynamically. The backend followed a basic RESTful structure, returning JSON for each API call. Error handling was added to gracefully return messages when the API was unreachable or the pod log was not found. This created a reusable base that I could later expand upon for more advanced log inspection features.

Frontend in HTML, Bootstrap, and JavaScript

To make the logs viewable, I built a very lightweight frontend using HTML, Bootstrap, and plain JavaScript. It called the Go API endpoints and displayed the responses in a browser interface. The design was kept minimal to ensure fast load times and simplicity. Initially, I ran the frontend locally using python3 -m HTTP server, but that wasn’t scalable. So, I containerized it using Nginx, added a Dockerfile, and set up proper routing to make calls to the backend using cluster IPs. Relative URLs were updated to reflect container-to-container communication using service names defined in Kubernetes. I also added a refresh button that would fetch the latest logs without reloading the whole page. This small interaction made the frontend feel much more dynamic and usable.

Automating the Build with GitHub Actions and Docker Hub

To keep things easy, I automated the container build process using GitHub Actions. Each push to the main branch would trigger a workflow to build the Go backend and frontend containers, tag them with both latest and version numbers, and push them to Docker Hub. I configured secrets for Docker Hub credentials in GitHub to avoid leaking sensitive data. The same workflow also handled tagging using Git commands to ensure consistent version tracking. This meant I could test changes locally with Docker Compose and push them confidently knowing the images were versioned correctly in the registry. With the new images available, I could then update my Kubernetes manifests and redeploy the containers quickly. Automation reduced human error and helped maintain consistency across environments.

Bringing It All Together with Docker Compose

To make testing easier before deploying to Kubernetes, I created a docker-compose.yml file that defined all three services: the Go backend, the frontend with Nginx. Each container had its own port, and the compose file handled network communication between them. This setup allowed me to run the entire application with a single docker-compose up command, making local development and testing significantly faster. I mapped ports to localhost so I could hit the endpoints and browser frontend from my laptop. The logs being pulled from Kubernetes were now shown in the browser in real-time. With this working setup, I could validate the entire end-to-end pipeline from Kubernetes API to user interface. Docker Compose was particularly helpful during early prototyping and debugging phases before moving everything into a cluster.

Adding a Dashboard with Builder.io and Design Collaboration

To give the app a more polished user interface, I teamed up with Sanskriti Gupta, who helped craft the design for a new dashboard. Using Builder.io, I built a visually appealing dashboard layout that could later fetch real data. The current dashboard uses dummy data, but it’s ready to be integrated with the Go API endpoints. Builder.io’s drag-and-drop interface made it easy to convert a design prototype into production-ready HTML/CSS components. The dashboard container was also dockerized and added to the docker-compose.yml setup. With the frontend and backend all running as separate containers, the system now felt modular and production-ready. Adding future features like log filtering, alerts, or even log storage would be much easier within this structured layout.

Finalizing Kubernetes Configs and Making Deployment Easy

Once the application was running smoothly with Docker Compose, I transitioned it to Kubernetes by creating a consolidated set of configuration files. Instead of defining separate deployments for the frontend and backend, I opted for a single pod manifest that ran both containers side-by-side in a multi-container setup. I also created ConfigMaps for managing environment variables cleanly and applied Role, RoleBinding, ClusterRole, and ClusterRoleBinding to ensure the backend container could securely access the Kubernetes API. These permissions enabled the backend to list namespaces, pods, and fetch logs directly from inside the cluster. After validating each component individually, I compiled everything, pods, configmaps, roles, bindings, and services, into one combined YAML file. This made deployment extremely simple, allowing anyone to deploy the app using a single curl command followed by kubectl apply -f -, with no need to manually edit anything. The final structure is clean, portable, and ready for production-like Kubernetes environments.

Final Touches: Nginx Config, Relative URLs, and Refresh Functionality

One last challenge was making sure that services could talk to each other inside Kubernetes without relying on localhost. I updated all frontend API calls to use the internal Kubernetes service names like http://api-service:8080 instead of http://localhost. I also edited the Nginx config to route traffic appropriately and avoid 404s on refreshes. The refresh button on the frontend was tied to JavaScript logic that hit the /api/logs endpoint every few seconds or on demand. With this, users could see the log update in near real-time. It helped validate that logs were truly coming from running pods and not cached or static. The end product is a clean, interactive logging dashboard that’s powered by Kubernetes, built using Go, and delivered via modern frontend tools.

Let’s try it!

Just head over to https://github.com/kaiwalyakoparkar/pod-logger or run the following commands inside your local terminal that has a connection to your Kubernetes cluster via kubectl

curl -LO https://github.com/kaiwalyakoparkar/pod-logger/blob/main/api/kubernetes/combined.yaml

Next, run this command to apply the Kubernetes pod configurations

kubectl apply -f podlogger.yaml

You should be able to access the podlogger dashboard at http://<your-cluster-ip>:30080

Thank you for reading ❤️

Thank you so much for reading this blog and joining me in this small side-project journey. The major aim of this project was to polish my Kubernetes knowledge and make something useful and fun that has medium complexity. I feel really nice as this project is towards the end of the idea that I had in my mind, and with all of your feedbacks, I will be working on more of the improvements into this. You can try out the project by heading over to my GitHub and following the steps I mentioned above

What and Why of KCNA?

KCNA stands for Kubernetes and Cloud Native Associate exam. This exam is facilitated by CNCF (Cloud Native Computing Foundation) as a part of Linux Foundation training. As the name suggests this certification revolves around testing your knowledge in Kubernetes and cloud-native. This certification confirms the user's knowledge about Kubernetes as a technology and the cloud native ecosystem as a whole. This certification is categorized as pre-professional certification and aims to help to provide a robust foundation for the professional cloud journey for the person.

This certification validates a candidate's fundamental understanding of Kubernetes and cloud-native technologies. It encompasses various areas such as deploying applications using essential Kubectl commands, comprehending the architecture of Kubernetes (including containers, pods, nodes, and clusters), grasping the cloud-native landscape and associated projects (such as storage, networking, GitOps, and service mesh), as well as understanding the principles of cloud-native security. Completing the KCNA exam demonstrates a candidate's proficiency in these key areas.

So from this, I hope you are not able to get a clear vision of how one getting this certification can help someone validate their cloud-native and Kubernetes skills and get those opportunities in the cloud-native ecosystem. Now that we know about the intent of the certification we can move forward with more details of the certification.

Though the exam costs $250 now. You can always get good deals on sales and even free sometimes through programs like LiFT scholarships etc. It would help if you kept an eye on it.

Uniqueness of KCNA Exam:

Some factors make this exam unique. One among them is strict proctoring during the exam. You can read more about it on this page. Although every exam taker is abided by the confidentiality agreement I will only able to share the resources, and information that are disclosed to the public. The certification is valid for 3 years.

Curriculum of the Exam:

The curriculum of the exam is very nicely constructed by giving appropriate importance to the appropriate modules and introducing almost all the cloud native concepts. The curriculum equally weighs upon the theory of things and practical implementation of the subject. So if you have a practical application with your theoretical study this exam might become relatively easy for you. This exam is MCQ-based and a total of 60 MCQs are asked in the exam. To pass the exam you have to attain a 75% result. The exam should be completed in 90 mins

The curriculum consists of the following components (The detailed curriculum can be found here. Kindly check for/if any revisions to the curriculum)

1. Kubernetes Fundamentals (46%)

2. Container Orchestration (22%)

3. Cloud Native Architecture (16%)

4. Cloud Native Observability (8%)

5. Cloud Native Application Delivery (8%)

Resources for the Exam

Now that we know about the exam and the curriculum. It's time to share with you the resources I followed to prepare for the exam. I have also made my notes public so you can use them for reference, study, or quick revision (recommended). The external resources could be

1. https://www.exampro.co/kcna - Free lectures and 1 free practice test

2. https://github.com/moabukar/Kubernetes-and-Cloud-Native-Associate-KCNA

3. https://notes.kaiwalyakoparkar.com/kcna

4. https://blog.bradmccoy.io/how-to-pass-your-kcna-exam-cf98cfa7d70f

Tips for the Exam

These are some of my tips while you prepare for your exams

1. Try to get as much hands-on practice as you can. Learned a new concept? Try to implement at least the Kubernetes one. Create pods, deployments and play around with it.

2. Give yourself enough time to understand. This is a very conceptual technology and understanding how everything works with each other.

3. Try to deep dive. Although the resources seem simple overviews try to learn a bit deeper into the concept. This will help you during exams as well as with other concepts.

4. Try to solve as many mock exams as you can. Multiple websites help you with sample questions. Take advantage of them.

5. Believe in your preparation. You got this 💪

Conclusion

Well, that's it for this blog, In the upcoming blogs I will try to pick up the topics from the curriculum and make them easier for you. Do join CNCF and Kubernetes communities to receive help during your preparation. You can also join my discord community and I would be happy to help you with your preparation. See you in the next blog 👋

Thank you so much for reading 💖

Connect: https://link.kaiwalyakoparkar.com/

What is FluentD:

As I mentioned it is an open source logging tool for cloud-native applications. Instead of saying it logging tool we can mention it as an open-source data collector that also helps you unify the data in order to make more sense of it. FluentD comes will a lot of unique features which really help while you are working with different sets of tools. All the features will be introduced in the further part of the blog.

Why do we log data:

Before jumping directly into FluentD, let's consider a simple scenario first to better understand why we need logging and appreciate what FluentD offers us.

Let's say you have a microservice application deployed on Kuberenetes Cluster and applications are written in different languages for example some in Javascript, python different databases, message brokers, and other services. Now as these applications communicate with each other they generate some data also called logs. And each application will generate this data in different formats depending on the languages and plugins you are using.

Now these data can be anything. You might need to log for compliance or logging specific data depending on the industry you are working in or the product you are working on.

These logs can also be for ensuring the security of your cluster and server (access logs) and can help in detecting suspicious access to your application data.

The logs can be also used like always in the traditional way to find an error and debug your application in case anything goes wrong

Now that we know why we need logging, let's see how is the data logged.

How is data logged?

Once the data is sent by the application it is generally stored in 3 ways

• File - The log data can directly be written to files. The issue with the method is that it is not humanly accessible and there can be a lot of log files which makes it impossible to go through files. Also, as mentioned before these files may be of different formats for different applications.

• Log into DB - The logs can be stored in a log database like Elastic Search so that it can be visualized easily with the help of different applications, or bundled visualizers. But in this case, Each application should be configured to log the data to elastic search.

• Third-party application - We can use Third-Party applications to log the data generated from the application but we can't control how they log the data making it inconsistent when the applications are written in different languages and structures.

  

How does FluentD solve this?

Now that we know how the data is logged and what can be the shortcoming in all the above scenarios. It would be easier to understand how FluentD comes as a solution.

• FluentD acts as a Unified logging layer which means no matter how many ways it gets logs in from source applications. It will convert all the logs into a singular unified format which can be distributed for the use of analysis, alerting, etc.

• FluentD collects data from different data sources Data sources like apps, access logs, system logs, and databases collect & Process into a unified format and then these logs are sent and used at the destination for Alerting analysis, archiving

How does it work?

Now let's see how FluentD works, first of all as we have seen in previous tutorials and tools, it is similarly deployed on the cluster you will be collecting logs. FluentD collects the logs from every application on the server. This also includes the logs from the 3rd party applications installed on the server.

After receiving the logs from the application, FluentD converts them into a unified format. Conversion to a unified format helps to work on logs coming from different applications and types. In addition to the conversation about the unified format, you can also enrich the data with additional information like information about the pod, namespace, container names, etc. FluentD also helps us modify the data being logged. After the conversion and necessary filtering and modification, the logs are sent to the destination. This can be anything like the one mentioned. The interesting part is that you can choose where your logs go. So you can define what destination a particular type of log goes to. This is called "routing"

Features of FluentD

• Not tied to any specific backend: This feature gives flexibility to FluentD to function with all types of backend services

• No vendor lock-in: Because FluentD not being dependent on the backend there is no vendor lock-in.

• Apart from this saves data on the hard drive until fluent parses and sends the data to the destination. Data will still be there if the server restarts and will pick up the execution where is was halted. Even if it facilitates this, it doesn't need additional storage configuration.

• It will keep on trying to push the logs to the destinations in case the destination (eg: database) fails and will keep on trying until the destination is available

How to configure

• We have to install the FluentD deamonset. We can find the installation guide here

• FluentD hence runs on the Kubernetes node and thus receives the logs from the applications residing on those nodes

• We have to configure the FluentD using the configuration file stating the rules, source, and destination configurations respectively. We use FluentD plugins to configure the working of FluentD on the cluster

Fluentd plugins are classified as:

• Input: What are the sources and types of input you want to log and can be of different types like http, tcp, syslog etc

• Parser: How data is processed in key-value pair example csv, tsv, json

• Filter: You can enrich the data as I discussed above using record_transformer

• Output: You can configure the destination where the logs go example elastic search, mongo

• Then we Use tags to group the logs. We essentially use the source block to bring the logs in the input and parse them then use filter block to help us with enriching and modifying the logs

    # All apps with tag myapp to be parsed as json
    <filter myapp.*>
    ...
        <parse>
            @type json
            ...
        </parse>
    </filter>
  

  Similarly, we use match block to define the destination where we desire to send the logs

    # All logs from service with tag myservice should go to elasticsearch 
    <match myservice.*>
        @type elasticsearch
        ...
    </match>
  

Difference in FluentD and Fluent-Bit

FluentD is similar to Fluent Bit in terms of functionality but the difference is that Fluent Bit is lightweight and used for high efficiency and low cost. Fluent Bit is known as a "High scale low resource", and is preferred for containerized applications

Conclusion:

Although there are many logging tools and we will be learning about them as well in the future but that's it for the introduction to FluentD in this blog. In upcoming blogs, we will be looking into how you can use FluentD with a demo.

Resources:

• How Fluentd simplifies collecting and consuming logs | Fluentd simply explained

• Introduction to Fluentd: Collect logs and send almost anywhere

• FluentD Docs

Thank you so much for reading 💖

Connect: https://link.kaiwalyakoparkar.com/

So this talk was targetted for:

1. Students: To help them understand and self-reflect on whether its the thing they want to do in the long run

2. DevRel Professionals: To understand how students and beginners pursue them as DevRel which might help them understand what can they do better/differently to better contribute to the community

3. Organisations/ Companies: To understand what you can do better while building ambassadorship and other programs around students and communities.

Wrong Keywords ⚠️

What do you see in this picture? Haha, it's me and friends during the KubeCon NA 2022 after-parties. We all love to take photos and post them on social media to share our joy and experience with everyone and there is nothing wrong with it. But have you wondered what keywords get reflected from these images if a beginner looks at them and knows that you are working as a DevRel? Following are some of the keywords that I could find

• Enjoyment

• Fun parties

• Travel

• Cool events

• Amazing lifestyle

• Less work

So sharing images has some negative effects too. Does that mean we shouldn't share the fun images of our memories? Absolutely you should but moving ahead we will see what other things would benefit and could stop creating misconceptions

It's important for me to tell my journey into DevRel which can help students understand the dimensions DevRel can be described into. I will keep it short, I joined communities that advocated open source and started learning it. While learning I used to help out other learners if I knew certain things or with the resources that could help them. Eventually, I started participating in the community events like monthly calls and other events and live streams the community used to host. After attending the many times I tried to take responsibility and tried hosting them myself. In a similar manner, I tried applying all these learning and experience in other parts (eg: CFPs, workshops, talks, etc). All I wanted to do it learn -> build -> share -> teach -> help -> explore and in the end I realized that what I was doing is also called Developer Relations or Developer Advocacy. By the way, this can be also applied for eg: You can learn, teach and talk about XYZ tech/ tool you like a lot (like I talk a lot about open source and GitHub :P). Now that you know my journey it would be easier for you as a student to navigate your journey until now.

I went around communities and social media and tried to collect some statistics around the common questions that students had for Developer Relations. Let's take a look at them.

The statistics are quite shocking, right? the uncertainties and misconceptions can be clearly reflected in these statistics. These are the stats, let's look at some real conversations I had.

Following are screenshots from the students I have been interacting with within discord communities

These chats really show how the social media and the posts the DevRel share have a great impact on the beginner and student communities.

This is my personal opinion but this is the way I see DevRel, you can totally be an amazing Developer Advocate without being under the organization title. Also, you can be on totally different job titles for most of the crowd, the goal is to become a software engineer, so you can be a software engineer by job title and can still teach and advocate about the technology and tool you like and that's how this role works. You can create your own job description in DevRel (This is where many organizations and companies fail to recognize if there is really a need for DevRel in the team and what should be the job description confusing the students in the community)

I know as a student you would want to be there and do what everyone besides you is doing but that might not be a good option every time. Why? because oftentimes we need to ask ourselves if that is really the thing we want to do. Also following the crowd reduces your freedom to explore around and experiment with different things. A while back Aditya Oberai wrote an amazing article on Dev.to about "Everyone can do DevRel (But Should they)". You should definitely take a look at it. It is a great resource for self-reflection [Following image has a clickable link]

I think the title is self-explanatory. If we look at the current tech industry, there are multiple trends that come up regularly to keep developers and engineers hooked for a while but running behind the trends continuously won't give you chance to understand it to the root additionally it will further confuse one on what's going on in tech world and especially the rise of questions like "Is their future in XYZ?" or "Can we get a job with XYZ". These questions are totally valid but getting these questions continuously can deviate you from your goal. There is an amazing article about the same written by Divya Mohan which you should definitely check out. Divya writes about the "DevRel influencer trend" which is really great perspective to think about in social media trends and tech influencers. [The following image has a clickable link]

Now, what is this? This is a simple test I came up with to enable students and beginners to evaluate things before taking up roles or responsibilities. This is an acronym for Goal -> Learning -> Growth always check if the opportunity matches your career goal and is joining the program or role enabling you to escalate towards that goal. Next is learning, see what new things are you learning with that opportunity. If you are not going to learn anything then I would highly recommend waiting for a little for another better opportunity. And the last one is growth, considering the factors that will change after the completion of the opportunity. Can you see the growth during the time period? Now measuring growth is highly subjective and I can't really tell about how you should measure your growth but the important factor can be aligning your goal with it.

There was a very good question tweeted some time ago which led me to think about this question. After the economic crises in the tech industry, many questions arose as many DevRels (known and well-known) at all seniority levels were let go by multiple companies. Let's take a look at the tweet and the gem replies by wonderful people in the community

Now that we have talked so much about DevRel and misconceptions let's talk a bit about programs students can take part in. This section is interesting dependent so the programs I mention might not actually be helpful for your goals but are worth giving a shot or exploring more about. These programs and communities can be seen as a benchmark for student programs and organisations can study their structures to improve their own programs and add value to the applicant.

And yeah, that was pretty much it. I really hope you'll find this blog helpful and will be able to decide for yourself if you should really pursue DevRel or at least know the truth about it. Again, the definition and job description change from organization to organization so you should definitely consider the above-discussed points to better make decisions and find guidance regarding the same. I will add some of the resources and the tweets mentioned which might help you as you go through other comments and impressions on the post.

Resources:

• My introduction to this talk

• Everyone can do DevRel (But Should They) - Aditya Oberai

• How can Devrel enable engineering - Aditya Oberai (Blog)

• How can Devrel enable engineering - Aditya Oberai (YouTube Video)

• https://twitter.com/JJarzebowski/status/1626566708927381510?s=20

• DevRel influencer trend - Divya Mohan

• https://twitter.com/taylor_atx/status/1575218433632804864?s=20

• https://twitter.com/ghumare64/status/1617175435015774208?s=20

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

What is ArgoCD?

ArgoCD is known as a declarative GitOps tool which is based on Kubernetes. Let's try to break this down. "GitOps" is a process where you take the code you have written and pushed to the Git registry (eg: GitHub, GitLab, Bitbucket) and take it to the deployment and this is mainly done and implemented as automation. The word "declarative" means that the deployment has exactly the same architecture that you want and have decided on. So if there was a case that something gets changed in the deployment then it will revert back to the previous state (the one which you have mentioned)

CD workflow without ArgoCD:

So whenever the application is pushed to the git repository, there are certain steps it goes through to reach the deployment. These steps are automated and known as CI/CD pipeline. So once the code changes are pushed they are tested, the image is built, pushed to the DockerHub or other registry, Manifest files are updated and finally through kubectl apply... it is applied to the Kubernetes cluster.

But in this case, we have to face and resolve challenges like:

• Install and setup tools like kubectl

• Configuring access to Kubernetes

• Configuring access to could providers

• Several security challenges

• No visibility of deployment status

CD workflow with ArgoCD:

So in a general scenario the above-mentioned workflow is used, but while working with Kubernetes we might need to change this workflow. It is essential to know that according to the set best practice for the Git repository, we should have two separate repositories for Code files and application configuration (k8s manifests).

The main advantage is there can be a time we want to change only the config files but don't want the test -> to build etc workflow to run as the configs can be changed independently of the application built. Having this as a reference now ArgoCD (which is installed on your Kubernetes Cluster) keeps track of the state you mentioned in the configuration repositories.

So if were to use the earlier CI/CD pipeline then it would have been too complex to manage and configure. Once the application is built and up the changes are reflected in the configuration files. These changes are detected by ArgoCD and pulled into the cluster.

Note: ArgoCD works on the pull method and not like the usual push method

Advantages of using ArgoCD:

• Git as a single source of truth:

  This means that if any changes are to occur in the Kubernetes cluster then the git repository is a place to validate and check if everything is going as mentioned in the manifests and any instance that is out of instructions is rolled back.

• Easy rollback:

  This is a very essential feature of ArgoCD as it helps us to revert to the previous state if there was any problem or misconfiguration in the cluster.

• Cluster disaster recovery:

  This means if one of my servers were to go down then I can create another cluster with ArgoCD and point it to the same repository then the process for recovery becomes much more efficient and fast

• K8s access control:

  We can manage the cluster access directly through git so we don't have to worry about giving access to the cluster to an external tool.

Let's try it out!

ArgoCD is super easy to install and configure. We will be looking at it through an example. I will be using Minikube for my Kubernetes Cluster.

I will be using this repository for this demo purpose and you can use the same

1. Install ArgoCD into your cluster using the following commands

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

1. Now that we have installed the argocd in the argocd namespace we can now create a yaml file with the following code. I will name the YAML file as application.yaml.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: wmd-argo-application
  namespace: argocd
spec:
  project: default

  source:
    #Your repo link here
    repoURL: https://github.com/kaiwalyakoparkar/practical-devops.git
    targetRevision: HEAD
    #Location where the manifests are stored
    path: ArgoCD/dev
  destination: 
    server: https://kubernetes.default.svc
    namespace: wmd

  syncPolicy:
    syncOptions:
    - CreateNamespace=true

    automated:
      selfHeal: true
      prune: true

1. Create a dev folder and place your deployment and service files into it like below. (Notice that it's the same path which I have mentioned in above application.yaml file.

1. Let's create a namespace for our application as we have mentioned in the manifest files. (Again the manifest files like deployment.yaml and service.yaml are already present on the repo so you can check them out there

# You can give any name to your namespace and update respective files
kubectl create namespace wmd

1. Now we have to apply the application.yaml file to the cluster. We can do that using the kubectl apply command like below

kubectl apply -f application.yaml

1. Let's go and check out it on the ArgoCD dashboard. To see the dashboard run the following command on your terminal

kubectl port-forward svc/argocd-server 8080:443 -n argocd

and now you can go to http://localhost:8080 to access the ArgoCD dashboard

1. In the Username field enter admin and to generate a password run the following commands into the terminal

 kubectl get secret argocd-initial-admin-secret -n argocd -o yaml

and you will get output something like:

We are not done yet, copy the password in this case mine will be VktPYkNUZGZRcjlNVk1ibQ== now put this password into another command to decode it and obtain the real password. Run the following command to decode it

# Change after echo with your password
echo VktPYkNUZGZRcjlNVk1ibQ== | base64 --decode

Now copy the password that is obtained (Remember to omit % at the end of the password obtained) and put it into the ArgoCD dashboard

1. Now you will be able to view the application in the dashboard

Click on the application name and you are able to see a beautiful map of your deployment

You can see every possible information about the cluster here including the health of the pod, cluster and service. ArgoCD pulls the changes every 3 minutes this can be changed using webhooks and other methods.

And done 🎉 you have successfully configured and implemented ArgoCD to your cluster now whenever you want to change anything in the deployment then you can directly change the manifest and push the code to git repository and changes will be reflected in ArgoCD automatically.

Resources:

• ArgoCD documentation

• ArgoCD Tutorial for Beginners | GitOps CD for Kubernetes

• What is ArgoCD

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

What is Rust

Rust is a programming language with a lot of potentials. Rust became popular because of its similarities with C++ language with some extra flexible and highly efficient features. Rust quickly became one of the popular languages as it's trusted for great performance (Super fast and memory efficient), reliability, and productivity (Good error messages, documentation support, integrated package manager, etc) while building software.

Why is Rust becoming popular?

Apart from all its great features, Rust became popular to it's highly flexible and fitting nature across different domains. Some of them are:

1. Command Line: Building and distributing of command line tool is extremely easier due to Rust's robust ecosystem and also helps in maintenance for the same.

2. WebAssembly: This concept of taking web apps to the next step is truly revolutionary and Rust helps us work with Web Assembly to efficiently work with Web Applications.

3. Networking: Rust becomes a popular choice for building network services as it provides reliability and resource footprints needed for predictable performance

4. Embedded: Many of the embedded software developers prefer low-level languages like C etc but Rust helps these developers to use it as low-level language without giving out the high-level language features

Installation

Installation is pretty simple for Rust, if you are using Linux or mac you can simply learn the following curl command

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

you will get a prompt something like the below press one and hit enter and that's it, your rust is installed.

If you want to check if it's installed correctly you can run the following commands:

rustc --version

cargo --version

What is cargo?

Cargo is a package manager for Rust, if you have used and worked with JavaScript and Python then it's similar to the native npm and pip we use. You can use some of the cargo commands to run, and build your code

//This command initializes the rust project
cargo init

//This command is used to run your rust program
cargo run

//This command is used to build your rust program (Creates /target folder)
cargo build

//This command is used to build release ready command executable
cargo build --release

Creating a rust project

Now that we are done with introductions and basics, let's try to create the first hello world program with Rust.

Step 1: Go to the preferred destination on your file structure and create a folder with your project name here we will take it as hello, and initialize your terminal

Step 2: Run cargo init this will create some folders and files needed.

Step 3: Navigate inside src/ folder and you should see main.rs file. This is the file we will do the changes

Step 4: Add the following code to the main.rs file

fn main() {
    println!("Hello World");
}

Step 5: Into the terminal navigate to the location of main.rs file

Step 6: Run cargo run and you should be able to see the output as Hello World.

And that's it, you have successfully created your first Rust program. In the upcoming blogs, I will try to go deeper into the basic programming with Rust where we will see about variables, conditionals, loops, and other language-specific things one needs to remember.

Resources:

• Rust Documentation

• Rust Crash Course | Rustlang

• Graphics and images are not made by me and rights remain with the respective entity

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

What is Prometheus 🤔

Prometheus is used as a monitoring tool for highly dynamic container environments or even bare metal servers. Okay so with day to day increasing complexity of the applications it is becoming difficult to handle everything manually and needs automation. For example, if you have many services and object running on the server there is no insight into what is going on hardware level or application level. There might be cases when a service goes down and that causes other services to malfunction. In such cases, you should be able to quickly find the cause and solve it.

In a regular scenario, it won't be easy as you will have to trace a long way back to find out the service at the root which is causing trouble and fix it. So Prometheus constantly monitors all the services, and alerts the admins or individual users when crash. Prometheus also helps you to detect these problems beforehand (eg: resource depletion, memory shortage, ram/ memory usage)

Prometheus Architecture ✨

Prometheus server:

This is actually responsible for monitoring work. Prometheus server is comprised of 3 different components

• Data Retrieval Worker: This component pull the matrics data from the application and services

• Time Series Database: This is a database that saves all the matrix data.

• HTTP Server: This component accepts the queries and provides the data from Time Series Database to The web UI (eg: Grafana)

(You can see how these components are put in architecture from the image below)

What are Targets 🎯:

Targets are any objects which are monitored by Prometheus. These targets include Linux/Windows server, Apache Server, Single Application, Servies, or Database. And these targets have units for monitoring. For eg units for Linux servers can be CPU states, Memory usage, etc.

What are Metrics 📊:

Prometheus provides a human readable format for metrics collected from the targets. Metrics entries are separated by TYPE and HELP attributes. HELP attribute is used to describe what the matrics are and there are 3 types of metrics

• Counter: These metrics keep track of how many times a particular error was caused or alerts were sent.

• Gauge: This metric keeps track of what is the current value of the unit is.

• Histogram: This matrix keeps track of how long and how big the size of the request was.

Target endpoints and exporters 🚛:

Some services have a default endpoint exposing data to prometheus but many services need another component and that component is an exporter. Exporter is a service or a script that fetches the data from the matrix, converts them to a format that Prometheus understands, and exposes this converted data on its own /metrics endpoint.

Advantages of Alert Manager 🔔:

An alert manager is used to check the rules set by the admin or the user and triggers when any of the given rules is reached. The alert manager then sends the alerts and signals on the provided channels like email, slack, discord, etc.

Common characteristics of Prometheus 📝:

• Reliable: Prometheus is highly reliable as you are able to get a clear insight on what is going on inside your services and application

• Stand-alone and self-containing: Prometheus doesn't need any outer service to support its functioning.

• It also works even if other parts of the infrastructure are broken. It is meant and supposed to work as a separate service.

• Prometheus doesn't need any extensive setup for implementation. It has it's own helm chart which makes it absolutely easy to configure and use it for monitoring on your infrastructure and applications

• Prometheus is less complex compared to other monitoring tools.

Setting up Prometheus on K8s ⚙️:

1. Create a separate namespace called monitoring

    kubectl create namespace monitoring
   

2. Add Prometheus repo to helm:

    helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
   

3. Update the helm repo list

    helm update repo
   

4. Install Prometheus operator on your cluster using helm:

    helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring
   

5. Port-forward Grafana dashboard service to access the Prometheus metrics:

    kubectl port-forward svc/prometheus-grafana 3000:80 -n monitoring
   

6. Visit http://localhost:3000 to access the Grafana dashboard

7. Once on the dashboard, you can use the following username and password to login as they are the default for everyone at the start and ofcourse you can update them if you want.

    username: admin
    password: prom-operator
   

And that's it, you have successfully added Prometheus as a monitoring engine for your infrastructure and modify the Grafana dashboard according to your will and preference to suit your needs. The most essential parts of Prometheus are time series data and time series database, types of metrics you can expect. If you dig deep into above topics then you will have much deeper understanding how you can modify Prometheus at each step to suit your specific use case.

References 📖

• Prometheus Documentation

• Setup Prometheus Monitoring on Kubernetes using Helm and Prometheus Operator

• Writing a Prometheus exporter from IDE to deployed in 20 minutes

• How Prometheus Monitoring works | Prometheus Architecture explained

• kaiwalyakoparkar/practical-devops

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

What is Helm?

Helm is a tool that helps in defining, upgrading, and managing the deployments that are needed in your Kubernetes cluster. Helm also works as a template engine which makes it really helmful (intended pun - helpful 😅) when you are working across teams with lots of files and configurations. Let's see some feature understanding everything I just mentioned in detail.

Features of Helm

1. Package Manager and Charts:

Helm is used to package yaml files. These yaml files are deployment and config files for the application you want in your Kubernetes Cluster. This makes it easier to distribute these files as packages in public for private repositories.

For example, if you want to use Elastic Stack. For including it in your cluster you will have to write the deployment yaml files, create secrets, configmaps, Kubernetes user with Permissions, and multiple Services. And anyone who wants to use the Elastic stack will have to repeat this process again. What if someone packaged everything ready into a template format so that it becomes more manageable for everyone? That is indeed done. These packages and called Helm Charts. These charts can be shared via repositories.

2. Templating Engine

Let's say you have an application with multiple microservices running. The config yaml files for these microservices are identical and the only thing changes is name, image name etc. In the ideal case, you will create separate files with exact same code for every microservices. Helm helps you create templates of these exact same code converting it into just one file and all the variable properties go under the values file. Let's see how these files look like

#Template for pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: {{ .Values.name }}
spec:
  containers:
  - name: {{ .Values.container.name }}
    image: {{ .Values.container.image }}
    port: {{ .Values.container.port }}

#values.yml
name: my-app
container:
    name: my-app-container
    image: my-app-image
    port: 9001

Following is the logical diagram for the working of template and config files

3. Release Management

One of the other prominent feature of helm is release management. Helm version comes in 2 parts helm cli and helm server (also called as Tiller). So the cli sends the request to the server (which runs inside the kubernetes cluster) and upon request Tiller creates the components like pods and services inside Kubernetes cluster. This offers the release management feature.

When you create a deployment Tiller keeps a copy with itself for future references creating a release history and when you run something like help upgrade <chartname> for upgrading version for exampleversion: 1.14.2 then the current deployments are updated instead of removing the deployments and starting new once. This helps in seamless roll-in and roll-out feature

Downside of Helm:

Security issue caused by Tiller:

Although Tiller has amazing use cases but it has too many permissions to your Kubernetes Cluster like CREATE, UPDATE, DELETE and hence raises a big security threat. Thus in the Helm version 3, the Tiller has been removed and is now just helm binary.

So this takes the release management feature from Helm and makes it bit more difficult.

Helm Commands - Cheatsheet

You can use this cheatsheet for popularly used Helm commands

#Helm chart creation
helm create <name>

#Helm install
helm install <name> <repo-name>

#Listing version
helm list <flag>

#Pulling helm charts
helm pull <chart URL | repo/chartname>

#Pushing helm chart
heml push <name> <repo-name>

# add a chart repository
helm repo add <chart-name> 

#generate an index file given a directory containing packaged charts
helm repo index <chart-name> 

# list chart repositories
helm repo list <chart-name> 

# remove one or more chart repositories
helm repo remove <chart-name> 

# update information of available charts locally from chart repositories
helm repo update <chart-name> 

# search a keywork in chart
helm search repo <keyword>

And that is all for helm. There is surely more you can deep dive into helm but as a starter having the above knowledge is enough. Checkout following resources :)

References 📖

• Helm Documentation

• What is Helm?

• What is Helm in Kubernetes? Helm and Helm charts explained

• kaiwalyakoparkar/practical-devops

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

➡️ What is Kyverno 🤔 ?

According to the Kyverno official documentation, it is described as follows

Kyverno is a policy engine designed for Kubernetes. With Kyverno, policies are managed as Kubernetes resources and no new language is required to write policies. This allows using familiar tools such as kubectl, git, and kustomize to manage policies. Kyverno policies can validate, mutate, and generate Kubernetes resources plus ensure OCI image supply chain security. The Kyverno CLI can be used to test policies and validate resources as part of a CI/CD pipeline.

Documentation

but what are all these "policies" we are talking about? To simplify let's take an example :

We all have been to schools/ colleges/ universities at some point in our life, some might be pursuing it right now (like me :D) and we have various rules we need to keep in mind while attending the school & colleges. These rules can be seen as policies in the "Kubernetes" school or college. So if you want to restrict/ validate/ mandate some properties, or features your deployment should have or shouldn't have you can mention that using Policies and Kyverno helps us in the creation of the policies which validate your deployment and send errors if the requirement is not matched. So as you might have guessed, this helps you get total control over what goes into your deployment and whether it is up to the guidelines you have created.

➡️ Architecture of Kyverno ⚙️

Let's look into the architecture. Though understanding every part of architecture is not at all essential at this point but knowing where everything goes and how the workflow goes can help you better visualize and implement. Let's take a look at the images below

As seen that Kyverno acts as a middleman when you are trying to apply the manifest files to your clusters. It verifies it and upon passing applies it to the requested section in the deployment. Enough theory let's try it out

➡️ Hands-on time 🤩!

Now we will be doing a simple nginx container deployment. But this time we don't want :latest image of nginx so we won't be allowed to deploy if the image has :latest tag and allow only if another tag :1.14.2 so let's start.

Installations 💻 :

1) First of all we need will be using helm in this tutorial so it's essential that you have helm installed. Then go ahead and create a Kubernetes cluster on any cloud service provider of your choice, in this tutorial I will be using minikube

2) Now let's add Kyverno repo to the helm. Run the following command in terminal

helm repo add kyverno https://kyverno.github.io/kyverno/

3) We have to now add Kyverno to our deployment cluster. Run the following 2 commands

# This is not mandatory command, this installs the pods security standards implemented by Kyverno. I have included it because it can be valuable practice in long run :)
helm install kyverno-policies kyverno/kyverno-policies -n kyverno

helm install kyverno kyverno/kyverno -n kyverno --create-namespace

# Output for the above command:
NAME: kyverno
LAST DEPLOYED: Tue Dec 20 14:31:48 2022
NAMESPACE: kyverno
STATUS: deployed
REVISION: 1
NOTES:
Chart version: 2.6.5
Kyverno version: v1.8.5

Thank you for installing kyverno! Your release is named kyverno.

4) You can verify if it's successfully added by running the following kubectl command

kubectl get deploy -n kyverno

you should get something like this 👇

NAME      READY   UP-TO-DATE   AVAILABLE   AGE
kyverno   1/1     1            1           98s

If you get this then you have successfully installed Kyverno and you are ready to work with it.

Creating, Testing & Managing Policies ✨ :

1) Now create a folder named Kyverno on your computer and add files named nginx.yml which will be our deployment file and my-policy.yml which will have the policy we are trying to apply. Add the following yml configuration code to it. (Can be also found here)

-- This is code for nginx.yml (Notice here the image tag is 1.14.2)

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

-- This code is for my-policy.yml (You can see different policy templates here, the one we are customizing and using here is this)

# This is original policy file from the kyverno docs
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
  annotations:
    policies.kyverno.io/title: Disallow Latest Tag
    policies.kyverno.io/category: Best Practices
    policies.kyverno.io/severity: medium
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/description: >-
      The ':latest' tag is mutable and can lead to unexpected errors if the
      image changes. A best practice is to use an immutable tag that maps to
      a specific version of an application Pod. This policy validates that the image
      specifies a tag and that it is not called `latest`.      
spec:
  validationFailureAction: audit
  background: true
  rules:
  - name: require-image-tag
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "An image tag is required."
      pattern:
        spec:
          containers:
          - image: "*:*"
  - name: validate-image-tag
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Using a mutable image tag e.g. 'latest' is not allowed."
      pattern:
        spec:
          containers:
          - image: "!*:latest"

1. Now edit the spec section of the configuration file in my-policy.yml as below (on line 16 to be specific)

spec:
  validationFailureAction: enforce
  background: true
  failurePolicy: Fail

1. We are done with the edition, now let's try to see if Kyverno stops us if we are trying to deploy nginx:latest for this update nginx.yml so it looks as follows:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

1. Now apply the my-policy.yml using the following command

kubectl apply -f my-policy.yml

You will get output similar to

clusterpolicy.kyverno.io/disallow-latest-tag created

1. Now apply the nginx.yml using the following command. (Remember as we have edited it to nginx:latest this should not get deployed and we should get an error)

kubectl apply -f nginx.yml

You should get an error message similar to

Error from server: error when creating "nginx.yml": admission webhook "validate.kyverno.svc-fail" denied the request: 

policy Deployment/default/nginx-deployment for resource violation: 

disallow-latest-tag:
  autogen-validate-image-tag: 'validation error: Using a mutable image tag e.g. ''latest''
    is not allowed. rule autogen-validate-image-tag failed at path /spec/template/spec/containers/0/image/'

Wohoo 🎉 you successfully created a policy that doesn't allow :latest tags on the image

1. Now change the tag in the nginx.yml file to :1.14.2

image: nginx:1.14.2

and now lets try to apply the nginx.yml file again and this should get deployed as the image no longer has :latest tag

kubectl apply -f nginx.yml

And the output for this should be

deployment.apps/nginx-deployment created

That's it, that's how you enforce the policies and manage them using Kyverno. You can use multiple pre-made policies or you can custom create your own too. And that is all for this blog. Would definitely like to know your feedback in the comments below. Until next time 👋

References 📖

• Kyverno Documentation

• Kyverno Overview -- Defining Kubernetes Cluster Policies

• kaiwalyakoparkar/practical-devops

• The above images are not created by me and are taken from the internet. The credit for this images go to their respected creators :)

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

What is CFP?

CFP stands for "Call for Papers" or "Call for proposals". These are types of announcements made by organizers to start accepting the talk ideas from people. The concept of CFP is really simple, whenever there is an open CFP, you are made to submit your idea, you write about yourself, and your topic in brief, and try to pitch your talk idea to the organizers. And then upon CFP selection, you are invited to give a talk at that particular event or conference. Now let's start with our 7 steps

➡️ Understand the audiences

Attendees :

It shouldn't be about you, it should be about the audience. For example "My 5 tips to ...." talks about you, instead, this should focus more on what the attendees would gain from the session. Understand who will your attendees be and try to make your description more specific for those people. Your description shouldn't be in generic terms. Understanding your audience more can help you find some amazing angles to put forward your ideas and generate curiosity for that specific segment of the attendees.

Organisers :

Now you should think about who is going to select the CFPs and what they want to see. One of the things they want is to have their attendees have a great experience and they will be looking for things that would help in providing that experience. Your description to your talk should demonstrate the potential to engage the audience and give them a great experience while attending your talk.

➡️ Why you?

This is one of the factors to highly consider while creating your CFP. See self-validation is very important but you should think about why should "you" be the person to give this talk. And your CFP should reflect the same things too. You should be clearly able to demonstrate why you are the most suitable person to give a talk among all the other people. You can mention all the points that you think differentiate you from others in your bio and description.

➡️ Research is important

Ofcourse you should know about the topic you are talking about. But the research I am referring to here is knowing more about the conference/event you are trying to submit your talk to. You should know what conference that is and what types of talks would be there (maybe from the past talk list). Most of the conferences will have the themes they are looking to get talks on so be on the lookout for them. If the organizers have organized the conference before then you can visit the past talks, read the descriptions and see what themes and types of talks they prefer having the most. Even if you are presenting the same topic you like, you can find different angles to present the same idea.

➡️ Let's write

The biggest thing to remember is that whatever you write is likely going to be on website, newsletter or other promotional content and there sometimes won't be easy ways to change that. Will that put pressure on you while writing? To be honest it might but don't worry that might actually help you boost your confidence. So for eg instead of writing "If this talks gets selected I will talk about ..." you can be more firm like "In this talk xyz will be talking about....". At this point you can look into yourself and your background and see if you can include it in some way. Take a look at the following description from my talk at KubeCon NA 2022

Are you a student trying to pursue cloud-native? Are you perplexed and interested in learning how to build a career in cloud-native? Attend the panel discussion to learn how hackathons can help you advance in cloud-native development. Hackathons are an excellent way to hone collaborative abilities, communication skills, and engineering skills all while keeping it fun, beginner-friendly, and a great experience over weekends. The panel will demonstrate how students can contribute to CNCF projects while participating in hackathons, specifically cloud-native hackathons. The panel is made up of students who have competed in over 145 global hackathons collectively in the past 12 months (winning a collective of 33 out of them and 5 together as a team) The panelists are also mentors, judges, and organizers at student hackathons and will share their experience as an organizer with those folks who are willing to bring the cloud-native culture via hackathons to their local community. The panelists will demonstrate how organizing CNCF hackathons could help attract more young people and students to contribute."

➡️ It all starts with a title

It's obvious that if it's a blog, youtube video, talk proposal, organisers and audience likes compelling content. While writing proposals 80% of your efforts should be expected just for title (Sounds weird but many researchers say the same). Re-iterate over and over on your title and you will start feeling that your titles are getting better and better. Some of the studies say that you should at least write 25 titles on the same topic description to start getting grip and understand what actually would work. Also while doing so you need to think about what impression will it create on the 2 types of audiences we talked before.

➡️ Get Feedbacks

This is self explanatory, feedbacks are indeed important to quickly testing if your thoughts are being conveyed properly to another person. Get feedback on your proposal from at least one person and get it as descriptive as possible so you can see what impression your writing is making and if that matches your expectations. Best ways to ask for feedbacks is to be specific what feedback you want. So rather getting your typo mistakes as a feedback the other person knows where they have to check on your thoughts. You can then work back and forth on improving the writeups.

➡️ Network with Organisers

Okay, this might be debatable based on if it's ethical or unethical to connect with organizers. But I feel networking doesn't hurt anyone, on the other hand, it helps you understand the organizers more and get to know what they really want and this supports one of the points mentioned above. You want to help organizers.

References 📖

• The art of writing conference proposals

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com

History

- Bare metal servers

It is typically a single computer server which is used by only one consumer or tenet. Each server offered for rental is a distinct physical piece of hardware that is a functional server on its own.

- Virtual Machine

As you might have already used virtual machines for trying out differnt operating systems. Virtual machines helps your softwares to share same physical resources instead of seperate physical resources for each software which would increase the cost drastically.

- Containers

Containers are similar to virtual machines conceptually. But the key factor is that containers run the program in isolated environments.

Monolithic v/s Microservices

There are multiple resources revolving around monolithic and microservice so I will try to make it as simpler and shorter as possible (because that is not really main scope of this blog and would need a dedicated article on itself), So let's say you have an application which has frontend, backend, database etc and you containerize your entire application in one container then that is called as a monolithic architecture. So if your container goes down your entire instance of that application goes down. Now the reverse is that you containerize each part of your application and connect them with each other, now this each containerized part of application is called as microservice. (See the image below for better understanding)

What is Orchestration?

Orchestration has multiple definitions. You can think of it as a automation process which helps us in deploying and managing the application. So the orchestrator will keep looking for anything wrong with your deployment and try to self heal, scale to keep your production damages to it's lowest. You can picture it as the orchestrator in an orchestra who is responsible to create a melody and monitor it continuously.

What is Kubernetes?

Kubernetes also known as k8s (Fun fact: It is called k8s becuase it has 8 letters between K & S in word Kubernetes) is widely termed as Container orchestrator but Kubernetes is not just container orchestrator which means it helps you orchestrate the containers and provide additional features like

• Deploy your application
• Enable zero downtime updates (Also called rolling updates)
• Helps scale your application dynamically with increasing or decreasing traffic
• Self heals the containers and other services.
• Run it on our own machine/cloude
• Run it on public cloud providers
• Helps migrate from one cloud provide to other
• It can also replicate services, scale those services
• You can also use Volumes (Much more about volumes in upcoming blogs)
• One of the prominent feature is load balencing

There are many more such features provided by Kubernetes apart from once mentioned above that seperates it from being just the 'container orchestrator'.

Kubernetes Cluster

Cluster is the outer most box which holds everthing. Cluster is simply a collection of Control Plane and Worker nodes. (Refer the diagram below with the explaination in the blog to build good intuition of the architecture)

KubeCtl (CLI)

This is a command line tool provided to us so we can communicate with our control plane do apply and do the changes. Optionally if you don't want to work with cli there are also few gui provided you can take a look into. KubeCtl must be installed on your local machine in order to talk to the API server in the control plane.

Control Plane

1) API Server: All the communication will happen via api server. It listens to requests on HTTPS and port 443

2) Controller Manager: So if the command is to create 5 pods then controller will take care of this but controller manager will handle and take care of the controller. It has 4 functions

• Desired state: Sees whats the desired state of the server being told by the API server for the controller
• Current State: Constantly checks if the operations meet the desired state
• Differences & Make changes: Listen to the changes & make the changes as being requested by api server

3) Scheduler: This is responsiple for physically scheduling the processes. It inspects the worker nodes and schedules the things accordingly.

4) etcd: It's the database that contains the infomation about the cluster so if the API server wants to get the information about the cluster the it will communicate with etcd.

Worker node

1) Kubelet: Communicates with Container Runtime and with Control Plane API server. Whenever a new worker node is created and attached to the control plane, kubelet is installed on it.

2) Kube-Proxy: Communicates with Control Plane API server. Kube proxy is responsible for networking. This will allocate ip addresses to the worker node/ nodes

3) Container Runtime:

• Pod: It is the smallest scheduling unit. It monitors the health of the container, reinitiates one if one dies etc. This is similar to the controller manager (in the bigger picture). Containers are inside a pod
• Container: It's a simple container running your application or service inside it. Container is a isolated environment to build and run your application. You can read more if you like in my Docker blog

Steps to run applications on Kubernetes

1) Create microservices

2) Containerize your microservices

3) Put container in pods

4) Deploy these pods to controllers

K8s DNS

This concept is pretty much understandable if you have worked with docker compose or other sorts of networking based communications between containers and services. If you haven't then don't worry. K8s DNS has some ip addresses for every pod and container so that they can communicate with each other, share information. From the previous application example you can imagine it as a way for your frontend containers to talk with your backend containers etc.a

All required installations

1) Docker Desktop

2) Kubectl

3) Minikube

Command Cheatsheets

Minikube commands

$ minikube start

$ minikube status

$ minikube dashboard

$ minikube docker-env

# will switch to bash prompt of minikube
$ minikube ssh

Kubectl commands

$ kubectl version --client

$ kubectl get pods

$ kubectl get nodes

# Shows information about the cluster
$ kubectl config view

# get everything like pods
$ kubectl get all

$ kubectl get deployments

$ kubectl create -f <pod-config yaml file>

# Get more info in wide format
$ kubectl get pod <pod-name> -o wide

# Get more info in yaml format
$ kubectl get pod <pod-name> -o yaml

# Port forwarding like docker
$ kubectl port-forward nginx-pod 8080:80

# Gets the replica sets
$ kubectl get rs view

# Get services
$ kubectl get services

# Apply the configurations to the k8s cluster
$ kubectl apply -f <file_name>.yml

# See the rollout history of the deployment
$ kubectl rollout history deploy/<name-of-deployment>

# Rollback to previous versions of the deployment
$ kubectl rollout undo deploy/<name-of-deployment> --to-revision <no-of-revision-from-history-command>

Well that's it, that is pretty much that goes around in kubernetes. You will understand and love it more once you build and deploy your application on it. Trust me best way to understand and learn kubernetes is through hands-on practice. Want to build an application and deploy it to your own cluster? Keep an eye on my blog page and there might be something for you in coming future 😉

References

• Kubernetes Tutorial for Beginners | What is Kubernetes? Architecture Simplified!
• Kubernetes Course - Full Beginners Tutorial (Containerize Your Apps!)
• Kubernetes Tutorial for Beginners – Basic Concepts & Examples

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://link.kaiwalyakoparkar.com/

What is Docker?

Docker is a tool which helps you run you application in isolated environment. Docker creates a isolated environment often called "container" where you run your application without getting affected by external factors. This helps in solving the major problem and often a joke "But this works on my computer". You can easily share images to spin up containers and it would work exactly the same as it would run on the machine it was built on. This is very effective tool while deploying your application to production

Steps to Containerize your application

In this section we will see 3 essential steps you need to follow in order to containerize your application

Dockerfile

This file is often referred as "recipe" for your container. This is a simple file which contains all and each step to setup and run your project. This file needs every detail from packages you install to the command you run in order to run that specific application. We will look more into how you can build your own dockerfile in the coming sections

Docker Image

Image is what you build out of your dockerfile. Image is easily sharable and storable. So if you want someone to try out your application you can just send them this docker image and they would be able to run the application exact same way without setting up anything on their local machines. Or even you can use these images to push your application in the production. You can think this a "class" from the "object oriented programming" reference.

Docker Container

Container is the running instance of an application. Containers are the built and setup using docker images. So whenever you get an image and you run it then a 'container' is created with all the information and this is the step where your application is actually running. You can create multiple containers from single image. You can think this as "object" from the "object oriented programming" reference.

Build your first Dockerfile

Every step in the docker file acts as a layer for next step while building the image out of it. Let's take a simple docker file as an example.

FROM node:alpine
COPY . ./
RUN npm install
CMD ["npm", "start"]

This is a dockerfile for a simple nodejs api script.

• FROM : This specifies the base os image on which your application needs to run. This is one of the essential fields you need to mention in your dockerfile
• COPY: This is simple copy command which has 2 preceding arguments. 1 - the files you need to copy, in this case all so . and where you need to copy so in this case ./ root directory
• RUN: You add a command here which you want to execute during the building of the container. In this case I did npm install because well I need node_modules folder to run my nodejs application
• CMD: This is where you add the command you need to run after the container is created and set up. You can keep on adding the commands in this array. If it's only one command then you don't necessarily need to put it in the array format.

Basic Docker Commands

Status Checking Commands

#Check docker version
$ docker -v

#See all the images in docker
$ docker image ls #[OR]
$ docker images

#See the runnig containers
$ docker container ls

#See all the containers
$ docker container ls -a

#See the running docker processes
$ docker ps

#See all the docker processes
$ docker ps -a

#Inspect a docker container
$ docker inspect <container-name>/<container-id>

#Inspect a docker image
$ docker inspect <image-name>/<image-id>

#See all the networks on host
$ docker network ls

Execution Commands

# Pull an image from dockerhub
$ docker pull <image-name>

# Run the image (if not present on device then it will pull and run)
$ docker run <image-name>

# Run the image with specific version
$ docker run <image-name>:<version>

# Run the image with attached linux command (Command comes after image name)
$ docker run <image-name> echo hello

# Run the image in interactive mode
$ docker run -it <image-name>

# Run the image in detached mode (in background)
$ docker run -d <image-name>

# Run the appliation running in the container into your machine with port forwarding
$ docker run -d -p <local-port(eg: 8080)>:<service-default-port> <image-name>
eg:
# You can now acces ngix on https://localhost:8080
$ docker run -d -p 8080:80 nginx

# Start Container
$ docker start <container-name>/<container-id>

# Stop Container
$ docker stop <container0name>/<container-id>

# Remove image
$ docker rmi <image-name>/<image-id> -f

# Remove container
$ docker rm <container-name>/<container-id>

# Get the logs of the running container
$ docker logs <container-id>

Building and Deploying Commands

# Build your on docker file
$ docker build -t <image-name>:<image-version> <dockerfile-path>

# Push the image to docker hub
$ docker push <hub-user>/<repo-name>:<tag>

Networking in Docker

When you install docker it create 3 networks automatically

Bridge:

• It is the default network that gets attached with the container.
• It is a private and internal network created by docker on host.
• Every container gets a internal ip address and containers can access each other using this internal ip address.
• To access any container from external you need to map the port of the container to ports of docker host
• You can run multiple web containers on same docker host and on the same port

None:

• In this type the container is not connected to any network.
• This means it has no connections with external networks nor other containers on the same docker host.
• And the container will run in totally isolated network.
• Use the following command to attach this network to your container

  $ docker run <image-name> --network=none
  

  

Host:

• To access the container externally you can attach the host network parameter to the container and it takes out any network isolation between docker host and docker container.
• So if you have web app container with port 5000 then it can be accessed at same port expertally without the port mapping.
• Now this means you can't have multiple containers running on the same docker host and on the same port as port are now common to all the containers on the host network
• Use the following command to attach this network to your container

$ docker run <image-name> --network=host

eg of the host: Taking same example as nginx from above

# with port mapping http://localhost:80
$ docker run -d -p 80:80 nginx

# without port mapping, host networking http://localhost:80
$ docker run -d nginx --network=host

User-define networks

When we create containers on same docker host there is only 1 bridge created connecting all the containers by default. (eg: 172.17.0.1) and you want to create a new bridge maybe with ip (182.18.0.1) on the same host you need to do it through thte command

$ docker network create \
    --driver bridge \
    --subnet 182.18.0.0/16
    custom-isolate-network

Docker Compose

Docker compose is a feature provide by docker host to connect and spin up multiple containers with mostly different images but the application is dependent on both the images quickly.

For example frontend image eg: voting and backend database in mongodb so let's try creating a docker compose file for it

version: 2
services:
    voting:
        image: local-fe-voting
        network: 
             - frontend
    db:
        image: mongo
        network: 
            - backend

#This will create different networks on same docker host
networks:
    frontend:
    backend:

Docker Engine/ Architecture

Let's see the docker architecture and how it runs applications in containers under the hood. When you install docker on your computer you essentially downloading 3 different components

Docker Deamon

It is a backgroud process that manages docker objects like images, containers, volumes etc

REST API

It is a programming interface used to talk to the docker deamon and provide instructions. You can use this api to create your own differnt docker tools

Docker CLI

And this is a CLI that we have used until now to perform action. It uses REST API to talk to the docker deamon. Now the thing to note here is docker cli need not to be on same host. It can be on different computer and can still communicate with remote docker engine. Use the following command to do so

$ docker -H=<remote-docker-engine>:<port-number>

#example with nginx remote docker engine
$ docker -H=10.123.2.1:2375 run nginx

Container Orchestration

With simple docker run command you create instance of your application but that's just one instance what if you wanted to create multiple instance. In that case you will have to run docker run command multiple time. Not just this you will have to closly monitor the health of each container and spin up new instance if one already running likely goes down. And what about the health of docker host? What if the docker host goes down, in that case the containers hosted on that host becomes inaccessble too. Orchestration is set of tools and scripts that helps us to host the containers in the real production environment. Generally Container Orchestration solution have multiple docker hosts that can host containers. So even if one fails, application is still accessible to others. The following is the command used in docker swarm

$ docker service create --replicas=100 nodejs

There are multiple orchestrations solutions available now a days

• Docker Swarm
• Kubernetes
• Mesos

Well we deep dived quite a bit into the details of docker from simple commands to architecture but that's it for this blog. See you in the next one :D

References:

• Docker Tutorial for Beginners - What is Docker? Introduction to Containers
• Docker Tutorial for Beginners - A Full DevOps Course on How to Run Applications in Containers

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya

Beginning of the story ⏱

Let's go a bit back on how I ended up attending HackCon India. When it was announced that HackCon will take place in India for the first time everyone was very excited and so was I. GitHub Education being the sponsor of the event and me being GitHub Campus Expert I got an amazing opportunity to represent at HackCon as a GitHub Campus Expert. And we were in charge of planning the activities, games, and some sessions at our booth. During these activities I found some common misconceptions and worries the community leaders, organisers and the community members had. So I would be diving these blog into several section and each section will have a learning that came with my experience.

Start of the HackCon 🎉

Being joined by around 200 hackers/organisers HackCon started around 8am with Keynote session from Mike Swift (CEO of MLH) followed by many other community leaders/builders and hackathon organisers.

During one of the session from Sagar Uprety he mentioned that how Nepal not having community or hackathon culture how he organised, inspired to organise hackathon and gave the meanings to hackathon way beyond just winning prizes. So there comes two learnings from this

Learning 1: Always have a bigger vision behind the activity you conduct 📈

While your vision can be getting people started with hackathons, open source and that's the reason you organise hackathon that's totally okay. You don't specifically need bigger and flashy prizes/ swags. Sagar during the later conversation also mentioned how he inspired one of his connection to organise a hackathon in their classroom with ~40+ students. So this explains that the vision and your passion to achieve the vision that matters when you organise any event. Now the incident from this gives me my second learning

Learning 2: Inspire your connections and help them leverage. ✨

You might have lot of connections on social media but are they really a connection if they are not collaborating and helping each other grow? Sagar in some chats mentioned that during his earlier events he connected with lot of people and when he was planning to organise first GitHub Field Day Nepal he reached out to these highly passionate connections and got them into the organising team giving them exposure and proper platform to utilize thier passion

Moving forward from the Sagar's talk I personally talked with many other aspiring community leaders and they mentioned that their college is not supportive and they don't know where to start. So this inspired me to help them with their situation as this has been exact case with lot of communities and following is the learning and the suggestions I gave them

Learning 3: Network - Inspire - Collaborate 🤝

So not being supported by your college might put you in tough spot. But you don't need to start big with extravigant fests and events you can just start by delivering session about the things you know. Deliver the sessions in your and other colleges/schools in your region and spread a word about your community. So this is networking - Spreading knowledge and awareness about your community. Next comes inspire, whereever you visit for session always inspire people in that college/school to do the same. Inspire them start community, teach others this way you are also helping your connections grow personally (As from learning 2). Now collaborate - Collaborate with these bunch of higly inspired and passionate people to spread the wings of your community. Sooner you will realise that you have walked long way in building your community and your community stands on strong foundation 'without college support'.

During my further conversations I found some members who had misconceptions about community building and I was asked "Then how do you earn through this?" and that brings me to my next learning and answer I told them.

Learning 4: Community Building is not about making money 🎗

Community building is a process where you represent a underrepresented or unpreviledged group of people which are facing same problems and you solve these problems together. If you look at community building from money making point of view then I would highly recommend you to reconsider the vision you have kept forward for you community. Of course community building and management will help you in you career but solving problems collectively should be your aim and not other way around.

The next amazing community person I had chat with was Kartikey Rawat and we discussed some problems while making the next leader for your community and the next two are learnings from it.

Learning 5: Your community aims can differ, they should differ 🦋

If you are building a community it's not mandatory to start your own from scratch. You can look for communities that share same vision, problem as you are trying to solve and you can directly get involved with the community and contribute. If you aims differ only then I would recommend you to start your own community.

Learning 6: There is no 'Politics' in 'Communities' 🚫

Imagine a scenario where there are two communities in the same college/school with same vision and instead of collaborating they do things like keeping sessions at the exact same time on the same topics and try to compete with each other. This is not what I call community. There should be collaboration between communities to share expeirence and help each other grow and solve their shared problems.

While attending the talks and sessions I interacted with lot of interesting community leaders and one of them mentioned how they are struggling in passing on their community leadership and many people pitched in and had great conversation the following learning demonstrates that

Learning 7: Leaders job is to create new leaders 💼

Leadership can't be cultivated in single night you have to give it proper time and attention. Creation of new leader starts from the moment the member joins the community. So as the community leader it's your role to deligate correct responsibilities and create enough opportunities for everyone to take up the stage and cultivate their leadership. Being given the opportunity from the start really helps them try new things, fail and learn.

And all the above learnings were my takeaways from the HackCon. Was it only all about talks and sessions? No. We at GitHub Education booth conducted some interesting activities and gave away some swags involving polaroid photos, stickers, pens, notepads, mugs, bags and exclusive yoga mats ❤️

Overall the experience was great and the organising team did a wonderful job managing the entire event. At the end I was glad that I didn't return back with just swags 😃

References:

• All the images taken in this blog are present openly on social media

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya

🤔 What are GitHub actions?

According to GitHub Documentation:

It helps automate, customize, and execute your software development workflows right in your repository with GitHub Actions. Read more

So basically GitHub actions help you create a workflow and automate it in your repository itself. Workflow means steps you take while going building software and deploying it. Eg: When I get a pull request to my project, I run tests on it, I check if it's according to semantics, I check for any kinds of errors that might occur while deploying. Once done I merge it then update the version, re-build and deploy it. Now this seems to be a long process and takes a lot of time and energy out of me. What if there was a way to automate all these processes and cut it down to, I get a PR -> (They somehow gets checked with all sorts of things I want) -> I merge it -> (Somehow does all the re-build and deploy stuff). Here the 'somehow' work is done by GitHub actions.

You just have to make a .yml once and it will do all the tasks on every pull request and issue as you prefer. Also creating a .yml file is not a big task as it looks, there are lots of templates for different kinds of automation already available online. Simply copying and pasting them does the trick too (unless they have additional secrets etc to it).

Enough of theory and explanation. Let's get writing our first GitHub action.

✍ Writing your first GitHub action

So, by now I hope you have a clear understanding of what are GitHub actions and why are they so useful while building software. In this section, we will be writing our first and simple action. An action that welcomes and provides resources to people when they create a PR or issue. This action comes in handy as you possibly can't be only 24/7, but this will help your repo to be interactive to some extent.

📂 Creating a file:

You have to create a .yml file inside of a .github/workflows folder. (make sure the .github folder is in the root directory of your project.). You can name your action file anything you want. In this case, I will be naming it greetings.yml. Refer to the image below for a clear understanding of the folder structure.

🛠 Writing yml code

Copy and paste the following code into the greetings.yml file

name: Greetings

on: [pull_request, issues]

jobs:
  welcome:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v1
        - uses: EddieHubCommunity/gh-action-community/src/welcome@main
          with:
            github-token: ${{ secrets.GITHUB_TOKEN }}
            issue-message: '<h3>Hello 👋, Thank you very much for raising an issue 🙌. The maintainers will get back to you soon for discussion over the issue!</h3>'
            pr-message: '<h3>Yeah! You did it 🎉. Now, Relax 😉 -> Grab a drink ☕ -> And wait for the maintainers views on your contribution. Meanwhile you can discuss on other issues and solve them 😀</h3>'
            footer: 'If you would like to continue contributing to open source and would like to do it with an awesome inclusive community, you should join our <a href="https://discord.gg/jvdcY2NkXa">Discord Server</a>- we help and encourage each other to contribute to open source little and often 🤓 . Any questions let us know.'

The above code is pretty simple. We name the action using the name tag. Then we specify when should the action run. In this case, we want it to run on pull requests and issues hence mentioned in the on tag. Then we move ahead with jobs. You can add multiple jobs to action, you can also link jobs in each other to achieve the flow. We add the job name as a tag itself. Provide base os info in runs-on (To be honest, I generally just copy-paste this required stuff). Here we only have one job so we add the steps we need GitHub to follow after every pull request and issue. We link other deployed actions using uses property. And with that, we add messages for pull requests and issues in the form of key-value pair. And you are done 🎉. Once this file is merged in the main or default branch your actions will start running.

You can create many such actions on your own. To know more about how you can create your own custom action and what all actions are offered by GitHub as a template can be found here

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya

1) Pre-Selection phase and

2) Post-Selection phase.

This will help you get a clear picture of how GitHub makes its program different and ideal for building and community growth. Let's get to it.

What is GitHub Campus Expert Program?

It is a program to help college/university student leaders build, grow and expand their communities. GitHub provides tools, training, sponsorships, etc to help the community overcome their struggles. GitHub Campus Experts are trained with public speaking, events management, and exercises to analyze your community. This program selects student leaders twice a year (in two cohorts). Once in February and in August.

Now that you have an idea about what is GitHub Campus Experts program is, we can get started with the pre-selection phase and post-selection phase.

Pre-Selection Phase:

GitHub opens the application twice every year. You can check the progress of the application here. The Pre-Selection phase is divided into 2 parts. Essay and video resume. This helps the GitHub Education team to understand more about you and your community. The essay part consists of 3-5 questions which are based on the analysis of your community struggles, aim, etc. Once your essays gets submitted and selected you head to video resume part. You have to record 3-5 min video focusing on certain points such as introduction, the aim of community, and similar things. After submitting the video resume you just have to wait for the result to come out.

If your essays get selected then only you will be proceeding to the video resume stage

Personal tips for getting through the pre-selection phase:

1) Have a clear aim statement about your community.

2) Try to keep your essays focussed and around the aim of the community.

3) Be particular about the point you are trying to convey.

Post-Selection Phase:

This is the most important phase. because in this phase you go through training to understand and develop yourself and your community. Once you are selected by your essays and video resume you will be invited to GitHub Campus Experts GitHub organization and to an onboarding event. Where you will be explained about the program and training methods and will get to meet other new campus experts. After the onboarding, you will have your own private GitHub repo in the organization where you will update your training essays. You will be provided with all the templates and materials for your training. You will be trained for public speaking, git and github, community analysis, how to grow community, how to become a good leader, community ethics, etc. And you will have to write comprehensive essays following the training with your community into focus. There are in total 6 modules which you have to complete before a certain deadline (This deadline can be extended by communicating with the program manager). The training videos are pre-recorded which means you can watch them whenever and wherever you want. Once you complete your essays they will be reviewed by the Campus Experts team and you'll be suggested updations (if any).

You will be submitting these essays for review in the form of a pull request so once your pull request is merged you will get "GitHub Campus Experts" badge on your github profile. What next? Now you are almost there, Next you have to create your campus experts profile which will be visible on the github campus experts website. You will be provided with spreadsheets, issue templates to get support from the team for all your needs.

My take on GitHub Campus Experts program

I personally really like the program. The differentiator of this program from other program is that upon selection it does not just give you a tag but provide you with the training, guidance, and support you need to develop yourself and your community. You are told about the ethics & values the term communities carry and what makes the term 'community' stand out.

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya

Okay as explained by me in my last blog that I have been assigned a project which I would be working on and going through a couple of k8ssandra doc and reference videos I found that it would be beneficial if I learn Cassandra before k8ssandra. So I started searching for resources for learning Cassandra 'the right way'. After going through a couple of resources these are my learnings:

What is Apache Cassandra?

Apache Cassandra is an open-source NoSQL distributed database. Which provides features like scalability, distributiveness, elasticity, fault-tolerant, hybrid, etc.

The most interesting thing I found about it is that it doesn't have any master node which has all the data but it uses distributed architecture to store the data. So whenever the data is added (be that be by any medium) it locates the nearest node (This node is selected randomly on the basis of few factors). The nearest node accepts the data and passes it on to the correct node of its index. To explain it better if we are storing students names in Cassandra cluster okay, so say suppose we make 6 nodes and distribute the name according to this [A-D], [E-H], [I-L], [M-P], [Q-T], [U-X], [Y-Z]. Now if the data contains a name that starts from "M" but the nearest node located was [U-X] then the data would be passed on to the [M-P]. But the process does not stop here yet. Imagine a condition if [E-H] node goes node or crashes so the users which are having names from E-H would be having a really tough time, so what's the solution? The solution is really interesting and it amazed me a lot as well. So the solution is every node follows the data partitioning approach. This means the node will replicate itself in several other nodes. Let's understand this with a diagram. Here as you can see the A data is replicated in two other nodes. So now if Node 1 goes down still we have a copy of its data to be served. So this architecture becomes self-healing and more reliable. And you can have multiple node rings over several cloud service providers (Azure, Google Cloud, AWS, or local infra). Also wherever the data is updated in any of the rings it instantly gets updated in all other rings making all the rings contain the exact same data which can be assessed from any geographical location according to convenience

Resources I follow to learn Cassandra

Written resources

• Official Documentation
• Wikipedia Page
• Tutorial's Point Tutorial

Video resources

I am learning a lot of new things every day so if you think I have explained something wrongly please do make a comment and let me know. Also if you know any resources which helped you with them don't forget to link them down.

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya

What is Kubernetes and why should you care about data on it (In lame terms)?

If you are not familiar with Kubernetes then I will try to explain it in lame terms. Consider it as a tech (I know it's a tech already). But when it was built then it was build keeping statelessness in mind. But after some time it was found that we can obtain statefullness in it. And that what our community does. It organises sessions and talks to spread awareness and dig deep into this topic.

So what is Rap lyrics on Kubernetes?

As you might know that the unique thing about our community is that it has a bit of artistic/musical touch to it. Our rapper Bart Farrell raps for our every session and speaker. So we have the the rap lyrics that we host on some platforms. So now what we are trying to do is writing these lyrics on database (which one we will discuss ahead) and then run that database on kubernetes (Makes sense?).

Tech stack we are using

We (team) had discussion about the tech stack we are going to use. If you are looking forward to contribute then we are open to suggestions and discussions. we are going to use this primarily

1. Spotify API (To host and fetch the rap lyrics)
2. k8ssandra (as a db to write the rap onto it)

Architecture we are following:

So, if this excites you and you would like to contribute to it then you can go to our Slack and then join #genius-rap-to-k8s-database channel so that you can discuss and contribute to the project.

And that's all for this blog. I learned many thing and got opportunity to learn many interesting things with this project. If you liked reading this blog then make sure you like this blog and subscribe to the newsletter for constant updates about the project.

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya

My Week:

This week was as always interesting and with lots of fun. We (team) had a discussion over many things. As the weekly task (Which I talked about in the last blog) I spent time with my family watching movies and taking a walk in a garden. We are going to come up with many great initiatives so this week was entirely into the discussions and planning of those.

I was allotted a transcript to be looked after for this week. Its topic was "It's just a SQL - Crash course on Synapse Serverless for T-SQL ninjas"). In that manner, I got an opportunity to explore more on Synapse Serverless SQL. I learned many things like why is it used, how to cut down cost-effectively, how the difference in the file format impacts the processing cost of the service directly etc. And this is a great way to learn.

I am fortunate that personal growth is given equal importance in this community. Every intern is allocated with certain transcripts which they have to filter for that we have to watch the recording of the session. In this manner, we also learn about the different concepts and add value to the community simultaneously.

I have been also assigned an interesting project which is aimed at running raps on Kubernetes. About which I will be talking in the next week's blog. So make sure you subscribe to the newsletter and I will meet you in the next one :)

Thank you so much for reading 💖

Like | Follow | Subscribe to the newsletter.

Catch me on my socials here: https://bio.link/kaiwalya