Forem: adhanaAshu

Nginx Basics

adhanaAshu — Sat, 14 Jan 2023 09:48:37 +0000

what is Nginx?

primarily one of the fastest web servers but can also be used as a proxy, reverse proxy, API Gateway, content cache and load balancer.
Its usage as a reverse proxy and load balancer is what makes it stand out.
NGINX efficiently handles tasks that might slow down your web server, such as negotiating SSL/TLS or compressing and caching content to improve performance.

Elements of Nginx configuration file

Nginx is very simple to install and once installed you can start by editing the config file which will usually exist in /etc/nginx or /usr/local/etc/nginx
nginx.conf is the text-based configuration file for Nginx.
It contains elements called Directives and Contexts. Directives are written like key-value pairs on each line ending with semicolons(;) Context on the other hand are top-level directives that apply to different kinds of incoming traffic.
- events – General connection processing
- http – HTTP traffic
- mail – Mail traffic
- stream – TCP and UDP traffic
Some directives use { } to group directives together these are called blocks. One of such important directives is the Location [modifier] [URI]{ ... } this directive is used to route the incoming traffic to various file systems.
Examples of a few directives are given below.

# These are directives key value; like pairs
user             nobody;
error_log        logs/error.log notice;
worker_processes 1;

Every time you make any changes to the nginx.conf , the nginx must be reloaded to take effect. you can use the command nginx -s reload

Few important directives to discuss

include directive: This directive includes another file inside the config file. include mime.types is one of the popular usages, a web server needs to know what kind of data is incoming, and this data is embedded into the headers of the incoming requests. nginx, suggest using this directive to break down your config files into simpler manageable files.
```
http { 
include mime.types; 

    server {
        . . .
    }
}
```

location block:This directive routes the requests to the correct location within the file system by matching the URI against the parameter . It is one of the most important directives to learn. each URL is matched against the location block to determine what content it will serve.

# the uri : / is the parameter to the location block.
# users visiting localhost:8080/ would be served content from this block
http {
    server { 
            .
            .
            location / {
                ...
            }    
            .
            .
    }
}

root directive: The parameter /draft gets appended to the root location folder.

URL gets matched against /draft here and then nginx serves content from the location /users/rocky/site/draft/

# users visiting localhost:8080/draft would be served content from this block
http {
    server { 
            .
            .
            location /draft {
                root /users/rocky/site; 
            }     
            .
            .
    }
}

alias directive: The parameter /test gets dropped and the nginx serves content from /users/rocky/site/draft . It allows us to remap URLs to a different directory completely other than the root location. It is useful for serving static files from a different directory

 # users visiting localhost:8080/test would be served content from this block
http {
    server { 
            .
            .
            location /test {
                alias /users/rocky/site/draft; 
            }    
            .
            .
    }
}

try_files directive: This directive recursively search for files in a specific order and serves the file located first. we've mentioned here =404 meaning we don't let it run forever, if the server doesn't find the index.html in a single pass, it would throw the error 404.

# users visiting localhost:8080/draft would be served content from this block
http {
    server { 
            .
            .
            location /draft {
                try_files /drafts/index.html /default/index.html =404;
            }  
            .
            .
    }
}

redirect and rewrite directives: if a user wants to go to /final but we want the page to redirect to /draft it is very simple to do. Look at the below example to achieve this.

http {
    server { 
            .
            .
            location /final {
                # 307 is a http redirect code 
                # we are redirecting from final to draft
                # users visting localhost:8080/final 
                # would be redirected to localhost:8080/draft
                return 307  /draft
            }  
            .
            .
    }
}

In the previous example if you observe the URL changes from /final to /draft but what if we don't want the URL to change, this kind of behaviour is where we can make use of the rewrite directive. Look at the below example to achieve this

http {
    server { 
            .
            .
            # anybody visiting localhost:8080/final 
            # will be redirected to /draft 
            # but the url will remain the same i.e. localhost:8080/final
            rewrite ^/final? /draft break; 
            location /draft {
                ...
            }  
            .
            .
    }
}

These are just a few of the directives to get you a bit familiar with nginx. Users can go through the nginx docs to learn in-depth about the intricacies of the nginx here

References

Laith Academy at youtube.

Helm and Helm Charts

adhanaAshu — Tue, 20 Dec 2022 08:16:30 +0000

Overview

what is Helm? It is a package Manager for Kubernetes, just like apt is for ubuntu.

Let's say we have an application running on the Kubernetes cluster, to setup Logging using say, Elastic Stack, we need to create Stateful set for database, ConfigMap for external configuration, Secret for storing secrets, Services for the dashboard and finally a user with permissions. The amount of work required for the standard setup of a logging service is huge and it is pretty much the same for everyone out there. Why not just bundle up all the YAML files and made them available to other users? Helm calls this bundle of YAML files Helm Charts

Helm Charts

Helm Charts are just Bundles of the YAML Files, which can be shared with users through Registries like Helm Hub. Users can create their own Helm Charts with Helm, this would also allow them to package the deployment in the dev environment and use the same in the prod environment or vice versa. Or you can also download and use the existing Helm charts, cutting down your deployment time.

Helm is also a Templating Engine, in deployments where multiple microservices exist, there would be multiple yaml files for each microservice, Using helm we can replace multiple similar YAML files with a single template file kind of like a blueprint, which takes values from values.yaml see the below example

Example Template file

The values are coming from the value.yaml file below

Next up, we can see the structure of a Helm Chart

my_chart/
 Chart.yaml
 values.yaml
 charts/
 templates/

my_chart is the name of the chart.

Chart.yaml contains metadata information

values.yaml contains the values for the template files

charts contains the chart dependencies

templates contains the template files

helm install <chartname> injects the values from values.yaml into the template files and creates the Kubernetes manifests to be deployed.

Let's Assume that we are using the helm templates but the values inside the yaml file are something that we would like to change, in that case, we can define our own .YAML file and pass it while installing the helm chart as below

helm install --values=my-values.yaml <chartname>

Release Management

Helm version 2 comes in the form of a client i.e. helm CLI and a server component i.e. Tiller. It runs inside the Kubernetes cluster and deploys the components inside the cluster. It also keeps a history of chart executions, each time a new chart is Installed or upgraded, providing the rollback feature in case of deployment failure However this makes Tiller a big security concern, Hence in Helm version 3, Tiller was removed. So the Release Management feature although available in version 2 is not available in the latest releases.

References

What is Helm in Kubernetes? Helm and Helm Charts explained | Kubernetes Tutorial 23

Vagrant for begginers

adhanaAshu — Tue, 06 Dec 2022 12:33:31 +0000

Introduction

Vagrant, a open source project to create and maintain VMs, was supposedly a side project by Mitchell Hashimoto and the company name Hashicorp was found around it. It is mainly used to create portable development environments. Vagrant cloud containes these ready-to-run vagrant boxes, which can be setup within minutes, provided, you have installed Vagrant and other utilities required along with it.

Vagrant can create VMs through configuration files or bootstrapped scripts, which can be easily automated using tools like bash, ansible, chef, puppet etc.

What are we going to do ?

The Idea here is to learn about the basic capabilities of vagrant, this can help the readers take up medium or maybe advanced topics to further their expertise.

For simplicity's stake we assume everyone has installed vagrant , if not there you go!. We are going to start up a VM, inside which apache server would be serving up a site.

Just to be clear, we are going to start up not just a VM with some basic configurations but then we are going to install apache2 ; a web server and then host a simple website on it, we are going to make the site available inside your network, meaning it can be easily accessed through not just the host machine but also your mobiles or other laptops if they're connected to your wifi or router. At the end, we are going to see how all of this can be automated .Good deal ! read up ahead.

*Note: * Although we are hosting a website to learn vagrant, It's actually used to setup devlopment environments and shouldn't be used to setup Production environments.

Setting up the tools

Well, the only tools you require is Vagrant and a VM provider, fun fact! vagrant supports multiple VM providers vmware, virtualbox , docker etc. So you can go ahead with this tutorial, if you have any of these VM providers installed already. Although i wouldn't prefer Docker, because of two reasons, reason 1 being, most of the config is done on dockerfiles and second we would deviate from the core lessons that vagrant has to offer.

so our first command is going to be vagrant init ubuntu/jammy64 this creates a Vagrantfile that contain configurations for our VM, it's written in ruby, but you wouldn't need to learn it. ubuntu/jammy64 is the box name. *Box * in vagrant are usually the name of the linux distros, or names people give their VMs and then upload it to vagrant cloud. Where you can share and use these boxes. Similar to images in Docker.

vagrant up downloads the box and then boots it up, vagrant ssh would log you inside the box and logout will simply log you out of the box.

Installing the web server

Now that we are able to bring up the VM, next we will manually try to install the apache server on it. before that we are going to perform the below actions.

We are going to update our system dependencies using sudo apt update . This is standard practice to keep your system updated.
The command to install apache from the apt repository for ubuntu is sudo apt install apache2 , you could easily get this from google, if you want to try installing something else.
We can just typesystemctl status apache2 in the terminal to check the status of the apache server. It should already be running
You can try sending a request to the site, using curl -v localhost:80. curl is a terminal based tool to check the status of websites. It will send some text back , what we're looking for is 200 OK this lets us know that site is up and running at port 80.

Networking.

Well, both the VM and the web server are up and running but this site can't be accessed on the host machine. what's the point you may ask? and... you're right, a site that is only available on the local machine isn't useful at all.

Now comes the networking, There are a number of ways to make this site available to local network or even the internet. you can go through this link for basic or even advanced usage of networking with vagrant Networking Vagrant.

We are going to make our site available on our local network through something called port-forwarding. We are going to map one of the ports on the host machine to port 80 of the VM i.e. ( host:4567 -> VM:80),
The traffic sent to host:4567 will be directed to port 80 of the VM.

config.vm.network "forwarded_port", guest:80, host:4567

this single line should do the trick inside the vagrant file. Do this change to the Vagrantfile, save it and do vagrant reload. you can try visiting localhost:4567 , voila ! you will see the default page of apache server , now the only thing left is to replace apache default webpage to custom simple html and css based website. you can simply paste the content of your website inside the folder /var/www/html/. how would you do this ? Your root directory, where Vagrantfile is created, is the directory that gets mounted as /vagrant inside the VM so you can move files to this root directory and then move this files to /var/www/html inside the VM.

TL;DR

Now we are all set, you can vagrant destroy which will delete the VM and all of its content.

Vagrant will take a config file:Vagrantfile and spin up a VM. Below you can view our Vagrant file to understand what all actions it will perform.

Vagrant.configure("2") do |config|

# Initial linux distro 
  config.vm.box = "ubuntu/jammy64"

# commands to be executed once the VM is provisioned
  config.vm.provision "shell" , inline: <<-END 

# update the system dependencies
  apt-get update

# Install the apache webserver
  apt-get install -y apache2

# copy over website content to where apache keeps the default site content.
  if ! [ -L /var/www ]; then
    rm -rf /var/www/html
    cp -r /vagrant/website/  /var/www/html
  fi
  echo "Container provisioned at $(date)! Welcome "
  END
# port forwarding to make the site accessible out of the VM
  config.vm.network "forwarded_port", guest:80, host:4567
end

if you run vagrant up with Vagrantfile same as the above code, you would be able to do achieve all the things that are discussed in this blog.

References

https://www.tutorialworks.com/linux-vm-vagrant/

Concurrency and Channels in Go

adhanaAshu — Mon, 05 Dec 2022 10:17:29 +0000

Introduction

Concurrency essentially makes a go program run faster by improving the response time and improving the resource utilization. Goroutines and channels are the programming constructs used in go achieve concurrency, goroutines are cheap, lightweight threads whereas channels let goroutines talk to each other.

while writing looping code you tell your computer to execute a few line of codes again and again, whereas while writing concurrent code you tell your computer to bring his friend, another computer , to execute this other piece of code while your computer keeps on doing his work. Goroutine is that other computer except that it's not a computer and well guess what it's not a thread either. One another thing to note here is that the other computer is running independently from your computer. If they wanted to talk to each other they would have to use something called a channel in go. Let us now see the nuances of goroutine and channel

goroutines

The word "go" needs to be appended to any named or anonymous function and that function becomes the goroutine. simple demonstration below

func printhi() { fmt.Println("hi")} 

func main() {

  // named function 
  go printhi()
  // Anonymous function
  go printHello() { fmt.Prinln("Hello")}() 

}

Here printhi and printHello are supposed to run at the same time, while the main function is also running. If executed there's a high chance neither hi nor Hello is printed on the stdout because the program runs only till the main function is running i.e. here main doesn't wait for goroutines to end and simply ends.

Features of goroutines

They are lightweight and cheap , in comparison to threads
Thousands of independent goroutines can be multiplexed onto a single thread
Named or Anonymous functions can be made to run as goroutines
If a single thread is blocked, the other goroutines on the thread are moved onto another unblocked thread, by the go runtime.

channel

Channels can be visualized as a box, now if it's a unbuffered channel then it will only hold a single item, meaning if A goroutine puts 1 inside the box, goroutine B can not put anything inside it until the existing 1 is taken out of the box, this causes blocking. Unbuffered channels on the other hand can hold items until they're full, blocking for unbuffered channels occurs when either it's full or empty.

Getting used to the blocking mechanism is a lil bit tricky for beginners, in simpler terms the program sleeps and waits for something to wake it up.That something can be another goroutine or main function.

Let us see in which cases blocking of program occurs ,we will take 2 goroutines ( send and receive ) and 1 channel (ch)

ch contains 1 inside it and send wants to put 2 inside ch, it will cause a block
ch is empty and receive wants values from ch , it will cause a block

A rookie mistake would be to just simply send and receive data from the channel from the main program. what happens is one of them causes blocking and since we don't have any other goroutine besides the main function running, nothing unblocks the main program itself and hence *DEADLOCK * occurs.

Let us know, see the code for creating a channel and sending, receiving values from it

// channel is created using "make" 
// this here is a unbuffered integer channel
// int can be replaced by bool, string or anything that the user wants.
ch := make(chan int) 

// this here is a buffered integer channel of size 2 
ch := make(chan int , 2 ) 

// this is how you can insert a value inside a channel
ch <- 1 

// this is how you can take values out of a channel
number := <- ch

// The direction of arrow indicates the flow of data.

The buffered channels are channels of a fixed size, items can be added until all the space gets occupied inside a channel and in the same way, items can be retrieved until the whole channel is empty, the data follows the first-in, first-out fashion.

The concurrency concept of go is non exhaustive and as much as i want to write more about it , I'm afraid i don't want to clutter up everything in the same article

References

Go Web Programming by Sau Sheong Chang , Manning Publications

Swagger-as a documentation tool

adhanaAshu — Fri, 11 Nov 2022 19:23:49 +0000

Hi so this is my first post here on DEV. I've heard about Swagger so many times and everytime i want to use it, to contribute to Open source, i get so confused. Most of the blogs suggest how it is so great for lot of things development,testing,documentation and whatnot. i wish i can just explore swagger for say, one of it's feature maybe for writing api documentation. I get overwhelmed by the blogs that i get online and finally i just drop the idea . Please drop by and say hi,I would love to hear how other people learnt it or are learning it as self taught programmers.