While working with a client, we needed to be connected with VPN all the time, it is when we noticed there was always a delay in response when browsing the internet on my system because all the traffic was going through a VPN tunnel to the VPN server located in the far region and this was the case for every employee working for that client. So, what is the solution for this if you are a cost-conscious company? You want minimal use of resources and improve overall network performance. You do split-tunneling, which we will be discussing in this blog, and how you can achieve it.
What is Split tunneling?
Split Tunneling is a powerful feature in OpenVPN that allows clients to decide which traffic should be sent through the VPN tunnel and which traffic should be sent directly to the Internet. This means that the client can choose to route only specific traffic through the VPN, such as traffic destined for a corporate network, while allowing other traffic to bypass the VPN. This can be useful for increasing the speed and reliability of internet access for certain types of traffic, and for conserving bandwidth on the VPN server.
In the IT industry, the need for migration can raise several questions in your mind. Like what will be migrated and what measures should be taken to perform the particular migration. And the major concern is whether there are any chances of losing data. Losing even a tiny fraction of the data in transition can impact the performance of the application. So, in that scenario there are several measures that need to be kept in our mind while performing any sort of migration is taking a backup of the data, software configuration, and if any plugin is required for the software so that should also be checked. Apart from that migration should always take place when the least traffic comes on the application.
So, recently we got a requirement where we had to upgrade a self-managed Gitlab Community Edition(CE) from 11.11 to the latest version i.e., 15.4.
While upgrading Gitlab to any other version you might face many problems related to incompatible versions. So, for a successful upgrade, we’ll discuss the GitLab requirements for the upgradation and will also share the analyses that we found while following through this blog post.
As organizations move more of their operations to the cloud, the need for secure and compliant infrastructure becomes increasingly important. With the rapid pace of cloud adoption, it’s crucial to have a tool that can help you ensure that your cloud infrastructure is configured securely and in compliance with best practices. So in today’s blog, we will be talking about a solution for all these problems which is Checkov.
What is Checkov?
Checkov is a tool that helps developers and operations teams ensure that their infrastructure is secure and compliant with best practices. It does this by automatically scanning infrastructure as code (IaC) and runtime environments for issues that could potentially lead to security vulnerabilities or compliance failures. Checkov works by scanning code written in various IaC languages (such as Terraform, CloudFormation, and ARM templates) and looking for patterns that could indicate security or compliance risks. It can also be integrated into a continuous integration/continuous deployment (CI/CD) pipeline, allowing it to scan code automatically as it is being developed and deployed.
Kubernetes is one of the most popular projects around container orchestration but it’s quite interesting that Kubernetes itself has no code to run or manage Linux/windows containers. So, what is running the containers within your Kubernetes pods?
Yes… Kubernetes doesn’t run your containers
It’s just an orchestration platform sitting above container runtimes. No code to run a container and to manage the container’s lifecycle on its own, instead, dockershim was implemented (in kubelet ) for talking to Docker as container runtime. I will talk about dockershim in the later section of the blog.
Also, docker has grown and matured over the last few years and has gained a stack of components like runc (open container initiative), containerd (CNCF project). OCI (est. in June,2015) splits docker into two parts:
1) to handle docker cli & processing requests and 2) to handle container running functions i.e runC.
In this blog, we will see how we can deploy the Elasticsearch, Fluent-bit, and Kibana (EFK) stack on Kubernetes. EFK stack’s prime objective is to reliably and securely retrieve data from the K8s cluster in any format, as well as to facilitate anytime searching, analyzing, and visualizing of the data.
What is EFK Stack?
EFK stands for Elasticsearch, Fluent bit, and Kibana.
Elasticsearch is a scalable and distributed search engine that is commonly used to store large amounts of log data. It is a NoSQL database. Its primary function is to store and retrieve logs from fluent bit.
Fluent Bit is a logging and metrics processor and forwarder that is extremely fast, lightweight, and highly scalable. Because of its performance-oriented design, it is simple to collect events from various sources and ship them to various destinations without complexity.