Devops Solutioning Archives - Page 11 of 18

Group-Based Authorization in GitLab

Why Group-Based?

In an organization, there are multiple projects, and every project has multiple users every user has a different role to perform, based on the role whether he is owner, maintainer, developer, reporter, or guest we assign the role to that user, but the main problem is that when we have to use those users to the different project then we have to do all the same task again. There is a better way to manage users in GitLab by creating groups and assigning those groups to the project.

What is GitLab Group?

In GitLab, we use groups to manage one or more related projects at the same time. We can use groups to manage permissions for your projects. If someone has access to the group, they get access to all the projects in the group. We can also view all of the issues and merge requests for the projects in the group, and view analytics that shows the group’s activity. We can also create subgroups in a group.

Deploying Azure Policy using Terraform Module

While working on Azure, you might come across a requirement that says the resources being deployed should be in accordance with the organization’s policies. Suppose you might want to grant a particular or a set of permissions on the resource group or on the management group so that the owner of it should be restricted like denying deploying of resources by enforcing resource tagging, region enforcement, allowing approved Virtual machines (VM) images, and many more.

In this blog, we will try to resolve these issues by applying Azure policies.

First, let’s get familiar with the azure policy.

The azure policy is a service that has been designed to help you enforce different rules and to act based on the rule’s effect on your Azure resources. You can use it to create, assign and manage policies. Azure policy evaluates your resources for non-compliance with assigned policies and performs the assigned effect.

Trigger Jenkins Job using AWS Lambda triggered by S3 Event

The problem that we faced:

There was a cron scheduled in our environment at a particular time which used to run at 8AM. This cron read data from the s3 bucket and used to succeed but failed when there were no objects present.

Problem this Integration solves:

Eliminates the need of keeping a scheduler in the system. Lambda will work as a Scheduler.
No manual intervention will be required in case the file from one service is delayed by a minute or an hour due to any reason.
Data exchange and processing between teams become more efficient and less error-prone.
Eliminates the need of checking the presence of files on S3. It all gets automated.

Continue reading “Trigger Jenkins Job using AWS Lambda triggered by S3 Event”

Kubernetes CSI: Container Storage Interface – Part 1

Introduction

There are different application categories in the general application world, but we usually define them in two major types, i.e., stateless and stateful applications. In Kubernetes, this distinction becomes especially important when designing and managing workloads.

To have a clearer perspective, we can say that API-based applications are generally stateless, and databases are stateful. In simple words or definition, a stateless application is an application that doesn’t save or persists the client data. On the other hand, a stateful application saves data about each client and uses it for other requests. Continue reading “Kubernetes CSI: Container Storage Interface – Part 1”

Pod Priority, Priority Class, and Preemption

While deploying the deployment manifest, we found that some of the critical pods are not getting scheduled whereas others are getting scheduled easily. Now, I wanted to make sure that the critical pod gets scheduled first over other pods. I started exploring pod scheduling and then came across one of the native solutions for Pod Scheduling using Pod Priority & Priority Class. So in this blog, we’ll talk about Priority Class & Pod Priority and how we can use them for pod scheduling.

Pod Priority

It determines the importance of a pod over another pod. It is most helpful when we need to schedule the critical pods, which are unable to schedule due to resource capacity issues.

Priority Class

It is a non-namespace object. It is used to define the priority. Priority Class objects can have any 32-bit integer value smaller than or equal to 1 billion. The higher the value, the higher will be the priority.

Pod Preemption

It allows the higher-priority pods to evict the lower-priority pods so that higher-priority pods can be scheduled, which is by default enabled when we create PriorityClass.