Forem: Gitlab Meetup Community

Challenges in Cloud Native

Gitlab Meetup Community — Sun, 30 May 2021 14:26:48 +0000

'Dynamicity' is quickly becoming a buzzword in the computer industry. Microservices, functions and serverless functions are gaining popularity and are much sort-after cloud-native technologies influencing our world. This rocketing fame and enthusiasm to learn sometimes unintentionally wraps up the challenges of cloud-native technology. An organization trying to adopt cloud-native technology not only looks for innovation and engineering but also keeps a check on eradicating the challenges that come with it.

Let us discuss some of the 'popular' challenges:

Security

Tools play a vital role in the security aspect of building cloud-native apps.
Establishing and maintaining the balance in security during production deployment is a hectic task faced by most employees. Poor analytics and false-positive alerts also contribute to the security imbalance.
The 4 Cs in Cloud-Native Security - Cloud, Cluster, Container and Code forms a layered security approach in computing. The software systems are much secured with this approach.

Dynamic data storage

Redundant storage of data without data leak is a challenge for any organization - A challenge in Cloud Native as well.
Application shut down would lead to burning up all the internal data, though having an immutable infrastructure.
External storage of data, thereby offering data as a service is the advantage of Cloud Native Environments.
This makes it easier for a single storage unit to be shared among multiple applications or services.

Delivery Pipelines

The introduction of code from a local environment to the required platform causes delays, alongside developing and testing such them.
Introducing CI/CD into the cloud environment produces a look-alike of the production conditions and decreases the distance between the pipeline and your apps.

Merging the services

Compromising on service and quality isn't a forte for cloud-native technologies. To achieve this goal, the cloud-native workloads have to uninterruptedly work together, thus making it a single service.
Deployment techniques play a major role in the integration of service. One of the widely used methods is Container.
Quite obviously, serverless functions might serve as a quick alternative.

Management

Management of the deployed services and their constant monitoring requires a logical approach to handle any failures.
The continuous monitoring of the application environment to detect any anomaly is seamlessly carried out by Dynamic baselining in cloud-native technologies.

Though cloud-native applications have a constant boost in their value every passing day, they're complex to handle. Creating the right flow chart to handle the business challenges to experience the reliability, scalability, and persistency to deliver an efficient cloud-native architecture creates a clear picture and high usage.

Check out the video for a demo of Cloud Native Development with GitLab

Gitlab 13.11 : With Kubernetes Agent and Pipeline Compliance

Gitlab Meetup Community — Sat, 24 Apr 2021 12:26:03 +0000

Our customers are scaling their DevOps practices and with growth comes the need for even greater efficiencies and automated controls. The GitLab Kubernetes Agent is now available on GitLab.com to help you benefit from fast, pull-based deployments to your cluster, while GitLab.com manages the necessary server-side components of the Agent.

Compliant Pipeline Configurations let you define enforceable pipelines that will run for any project assigned a corresponding compliance framework, even custom ones.

We also have a host of features to improve pipeline efficiency and measurement, to provide On-call Scheduling, and even more security enhancements. These are just a few of the 50+ significant new features and improvements in this release.

Controls to help you grow safely and efficiently

Controls can keep your automation on track as you grow and scale while simplifying compliance efforts. The GitLab Kubernetes Agent is core to GitLab's Kubernetes integrations and is now available on GitLab.com. The Agent-based integration supports pull-based deployments which are preferred by security and quickly becoming a popular method for Kubernetes deployment practices.

The agent also supports Network Security policy integration and alerts which enables fine-tuned RBAC controls within your clusters. Compliant Pipeline Configurations let you enforce a higher degree of separation of duties and reduce your business risks by defining enforceable pipelines that will run for any project assigned a corresponding compliance framework.

At the same time, Custom Compliance Framework Labels allow you to use your own requirements beyond the usual ones like PCI, HIPPA and such. The new Admin Mode increases security and control of your GitLab instance by requiring admin users to reverify their credentials before running administrative commands. Audit reports are easier now too with a new export feature in your self-managed GitLab instance to see, all in one place, what groups, subgroups, and projects users have access to.

Speedier pipelines

“Speedy, reliable pipelines” is one of our core product themes, and we’ve delivered on that promise this month with a host of pipeline improvements.

The Pipeline Editor helps you get to work even faster and stay more productive once you begin. The new Empty State enhancement will allow new users to begin working with the pipeline editor on a new, blank pipeline file without having to create a config file first.

The ability to configure multiple cache keys in a single job will help you increase your pipeline performance and you can measure these improvements from the CI/CD dashboard, where a new DORA 4 graph will show lead time for changes via time for code to be committed and deployed to production.

As a related note, metrics on DevOps Adoption are now available at the group level allowing users to understand how GitLab's DevOps capabilities are being adopted.

Securing your software supply chain

Security pros will be happy to see the addition of the Semgrep flexible rule syntax to extend and modify custom detection rules, a popular request from GitLab SAST customers. We've also added support for custom certificates and email alerts for key expirations.

You can now improve your security posture by enforcing SAML for Git activity. The new On-call Schedule Management routes alerts received in GitLab to the on-call engineer in the schedule for that project.

This will be particularly helpful as we mature our security alerts in the future, providing a valuable incident management capability with end-to-end visibility across the entire DevOps process.

Read on for more features, performance enhancements and changes! To preview what's coming in next month’s release, check out our Upcoming Releases page and our 13.12 release kickoff video.

Don't forget to check this link for a quick demo!

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hplp6opfpywirwur2vmz.png "Official Website")

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/00qhd8v9ma2t2l2xv4xh.png "Twitter")

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/aqq6pi897bk687d3kwwa.png "Meetup Community")

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/8u4886rik46g1bvvrx8d.png "LinkedIn")

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/btpzfoja85ps8d28nx7c.png)

A peek into Kubernetes Ingress

Gitlab Meetup Community — Tue, 13 Apr 2021 16:41:34 +0000

If you are a beginner and looking to set your foundation right concerning Kubernetes Ingress, then here's all that you need to know to hold on firm conceptual base.
Most of us might know what Kubernetes is but quite sure of what Kubernetes Ingress is and its use. So let's get an introductory handshake with the topic.

Introducing Kubernetes Ingress

In simple words, we can imagine Ingress to be an obedient access object that checks Kubernetes services from outside the Kubernetes Cluster. The set of rules determines a regulated flow of inbound connections leading to services.

We can consolidate Kubernetes to do a few frequent activities like Directing traffic, virtual hosting based on the name, lets you use reachable URLs, applies the brake on SSL and TLS.

Load balancers offer a helping hand to ingress in handling the inbound traffic and keep the firewall policy alive throughout the operation. Edge router can serve as a good alternative too. The service on the node are secured enough and does not expose the services.

Why K8s Ingress?

The environment requires the help of Ingress to configure and manage the needs of content-based routing, authentication and support inside the K8s cluster.

Ingress Controller

The Ingress Controller in the Kubernetes Ingress API is the load balancer for the external traffic, dealing with L4-L7 Network Services. It reads the resources information of Ingress and processes the data as required besides configuring the HTTP/HTTPS load balancer minding the ingress resources.

Spotting the differences

NodePort

If you want the exposure of a service on a static port number in a non-productive environment, then NodePort will be a good option. It appears as a configuration setting during the declaration of the YAML service.

Load Balancer

An external load balancer takes precedence and brings out services to the internet. Since the Ingress controller, by itself has load balancing application policies the latter is preferred over the Load balancer.

ClusterIP

The most preferred option for internal service access - ClusterIP. As the functionality goes, it uses an internal IP address for the service access. ClusterIP can usually be used as debugging during development, testing, internal traffic, etc.

For the implementation of Ingress, all you need to do is, configure your Ingress Controller with your cluster. This configuration takes care of resource information processing and regulating the traffic based on the protocols. Choose the right configuration to expose your application on the internet, then you are all set!

Meetup Announcement - Edition 03

Gitlab Meetup Community — Sat, 13 Mar 2021 15:53:28 +0000

Hey there Learning enthusiasts!

Looking for a fresh start in Functional Programming in Haskell?
Don't worry! We have got you covered!

Gitlab Community Coimbatore is excited to host our upcoming meetup on 27th March, 2021.

All eyes here! This event is going to be a "Podcast" in conversation with 'Mr. TamizhVendan S', Principal Software Engineer at Ajira Tech.

About the speaker:

TamizhVendan, a functional programming enthusiast and a Full-Stack solution provider has authored "F# Applied & F# Applied II", a practical guides for web development.

He's also a the founder and head coach of an E-Learning portal called Learn CS in Tamil focused on coaching young coding blood in Software development and Computer Science.

Tamizh is also a Freelance IT trainer for F#, Clojure & Haskell since more than a decade now. Apart from his passion for coding, he's also an active blogger who's concepts are very much attention seeking to the beginners.

Link of the blog: https://www.demystifyfp.com

Topic of discussion: Functional Programming - Haskell for beginners

Date: 27th March, 2021.

Click here and enroll yourself for the event!

We are enthusiastically looking forward to have him with us for the event.
We would like to extent a warm welcome to you all for the event. Set up a firm base, brainstorm and traverse through the basics of Haskell.

Cheers to all our attendees and hoping to see you all on D-Day!

Reminder: all attendees are expected to adhere to the GitLab Code of Conduct.

DevOps Deployment Strategies

Gitlab Meetup Community — Sun, 28 Feb 2021 17:54:30 +0000

When there's software, there are deployment strategies. Organizations develop various plan - of - action and follow different deployment methods, ultimately aiming to achieve their constructive business goals. However, we have a few most talked about DevOps strategies that shoot the automation levels to their next step. We shall have a brief explanation of different deployment strategies here.

Recreate Deployment

The Recreate Deployment strategy works almost like a traffic signal. It stops the ongoing application's version deployment, deploys a newer application version and changes the course of the application. This diversion towards the latest version is lead by the Load balancer. Depending on the size and type of application, this technique takes about a few minutes and is simple to handle also renews all the applications' state.

Ramped Deployment

The deployment strategy follows an array approach in deploying a newer version. For example, if a Kubernetes has more than 2 clusters operating, a new version of a Cluster is deployed by shutting down the instances of previous versions one-by-one. Hence it is also termed as Rolling Update Strategy. Since the steady release of instances in the version, it is easier for applications to take care of data rebalancing.

Blue/Green Deployment

Parallelism plays a crucial role in the Blue/Green deployment. An up to date version will be created in parallel with the old one. The instances of the cluster are processed for further testing. Once the testing results scores a top card, the previous version is replaced by the new one.

Canary Deployment

The production deployment carries off a gradual rollover from an older to a newer version of the cluster, when we have no tests performed. Canary deployment pays attention to the performance, though the slow re-roll of the instances is a factor.

A/B Deployment

Are you looking to test the application for mobile users? A/B Deployment strategy would serve as a better choice. We can refer to this more like a sister of Canary deployment, yet has its uniqueness while deploying the mobile apps and conditionally differ in version bottleneck concerning geolocation, language, browser version operating system, etc. Analogous version deployment and an absolute command over the bottleneck distribution are eye-catching advantages. However, we do have a rough time troubleshooting the errors and effective load balancing.

Shadow Deployment

As the name goes, one deployment version shadows the other. When we have an incoming request for the first version, the traffic can be redirected to the second version. Sounds cool for a new feature deployment and performance testing right? Nevertheless, there's no deployment happening until the stability and performance is met. The complexity of the setup impacts the wallet and also requires a mock service in certain cases.

Choosing the right deployment for your task requires a thought. In common scenarios, during staging or development, Recreate or Ramped deployment is recommended. While during the production, Ramped or Blue/Green deployment is a good choice. If you want to migrate a new database technology, then Shadow deployment can check your priority list. In case of lacking test, Canary or A/B deployment can be your alternative.

Getting a basic grip over Kubernetes Cloud Native Security

Gitlab Meetup Community — Fri, 19 Feb 2021 17:52:41 +0000

Security is a work of fingers to the brain for most Cloud developers who love to experience the Cloud. Kubernetes Cloud-Native Security is no different from this. Securing the containers by foreseeing the potential risks of the cluster would be the main focus area.

But what is the basis of Kubernetes Cloud-Native security?🤔

The 4C's below are the four areas of security to be worried about for the protection of Kubernetes Cloud-Native applications:

Code: Code is the "Point - to - Conquer" for the hackers. The encryption techniques and the concept of handshake protocol must hold the code tight enough from the hawk eyes during the production phase.
Container: The Container is secured by avoiding irrelevant permission access for the users. The uninterrupted vulnerability checks of the container silver lines the container security.
Cluster: The security of the applications and the Kubernetes API Components requires configuration. Cloud-Native applications may serve a loophole to shake the wall of security since it runs on microservices and APIs.
Cloud: The key computation happens in the Cloud, which is dependable and becomes vulnerable at the same time if not configured correctly. Hence the cloud provider makes sure of providing the security recommendations to run the workloads.

Best practices for the Kubernetes Security

Ensure that your etcd is secured with Firewall, TLS and Encryption.
Run your Kubernetes nodes on a separate network.
Update your Kubernetes to the latest version regularly.
Authorise your Audit log to ensure that the "forbidden" status message takes a call during the unauthorised attacks.
To prevent a vulnerable attack on the nodes that contain the code, secure or lock your kubelets.
Make sure you identify your process running unexpectedly with the help of Process whitelisting.
Cluster Networks must be observed in the Containerised applications to set the seal on Network Traffic, in turn securing Communications.
Integrate your Kubernetes with a Third Party Authentication Provider for an added security.

So are you interested to learn more about Kubernetes Security? Tune in to our series where we shall be discussing the layers of security in detail during the forthcoming weeks.

Kubernetes Components and Architecture

Gitlab Meetup Community — Wed, 10 Feb 2021 17:16:54 +0000

Most of us are well aware that Kubernetes is a 'Container Orchestration Tool'. Naturally, it shoulders the responsibility of learning Kubernetes components and architecture, adhering to its working. This open-source platform that deploys and manages the containers is of great help during your productivity that is economical and undoubtedly a future proof solution. But how does the architecture help in achieving all these goals?

To make our understanding better, let us consider an analogy for the Kubernetes - "The Kubernetes Kingdom"!

Feel like catching a fleeting glance of Kube? Then you ought to check his out.

As we are all aware, the purpose of using Kube is to host your application in the form of containers to automatically deploy your application's instances as many as you require. Here in the Kube Kingdom follows the working principle according to the 'Master-Slave Architecture'. On the Slave side, we have the hard-working Labourers and the monitoring Supervisors forming the Worker Nodes which deploy the applications and carrying the containers with the consent of the Master node.

On the other side of the architecture, we have the King playing the role of master, who guides and is the prime decision-maker for all the deployments. The Master node manages the Kubernetes cluster concerning different nodes and the destination of the containers. Let's get into the detail of the components of the master node.

kube-apiserver: This API Server plays the role of Chief Minister who primarily is the component that manages and establishes communication among all the elements in the Master node. The kube-apiserver is responsible for operational orchestration of all the components. Exposing the Kubernetes API, kube-apiserver is the frontend of Kubernetes control plane, thus managing and deploying more instances.
etcd: As a Chief Administrator in the kingdom etcd holds the back-up(database) of all the cluster data in the form of Key-Value pairs. They're highly consistent and maintain even the smallest data of the worker nodes.
Kube-scheduler: The kube-scheduler guides the juvenile pods to its new node to run them, thus qualifying to be a Manager for the Supervisors. It schedules the pods considering the availability of the space, its destination and the capacity.
Control Manager: Now since we have a Kingdom, we are bound to have different Provincial Administrators, which in this case are: Node Controller, Replication Controller, Endpoint Controller and Service Account & Token controllers. Though logically different, they run as a single process.
Kubelet: Kublet works as a Secretary who directly report to the Chief-Minister-kube apiserver. It runs on the node of every cluster monitoring the cluster's functionality on every pod.

Takeaway notice points:

A network proxy called kube-proxy works on every node of your cluster that executes Kubernetes Service Concept.
The software responsible for running the containers is Dockers. A few other container runtime software is CRI-O and Containerd.
Looking out for Kube Cheatsheet? Check out this blog

Highlights of the Gitlab 13.8

Gitlab Meetup Community — Mon, 01 Feb 2021 07:19:24 +0000

As the next step of advancement, Gitlab is all set with its 13.8 version providing its users with deployment frequency dashboard, pipeline editor, CI lint tool and many more features simplifying the work life.

The visual pipeline has been the talk over the version which had its primary aim of contributing towards the high degree of flexibility with the CI/CD. It certainly spurts the DevOps performance taking it up to a new level.

Let us traverse a few key highlights of the version in detail:

The Pipeline Editor: Seeking to configure your pipeline? The pipeline editor provides your best chance of grouping up the prevailing, and the upcoming CI features onto a unique location, hence shooting up the convenience level to the rookies and the experienced developers.
The CI validation comes with a brand new package of indicator scrutinizing the configuration validity.

Take a look at the pipeline editor MVC
Validation of the test failure: The pipeline execution of the merge request, allows you to monitor the count of test failures on the Test Summary Merge Request Widget. This feature provides you with accurate results in case of a distorted test.
However, the test feature accepts feedback with a motive of providing an extended UX.
Graphical representation of pipeline configuration: Having a tough time getting your head over the pipeline's behaviour? 13.8 has it sorted out by introducing a visual representation of .gitlab-ci.yml configuration which improves the understanding, in turn, contributes to the better performance of the pipeline.
Monitoring the deployments: Designed to monitor the deployments are the deployment frequency charts that are into effect from the project level.
So these DORA metrics for the Gitlab would enable you to monitor and make improvizations on your team.

Apart from these highlights, 13.8 has taken a step forward in emailing an issue, addressing a multiline issue, working on MR widgets and swiftly rebasing an MR branch. Gitlab 13.8 has made itself available even for the Kubernetes.

The future releases are on track to provide its users with access control. The propositions made concerning the access control includes: Attaching Grafana pods to Gitlab OAuth services and adding the ability to configure the Gitlab pages access control manually.

With the above-boosting enhancements on the line, we are sure to expect a charged release in the future not very far away.

Notability of Database in Version Control

Gitlab Meetup Community — Mon, 25 Jan 2021 13:45:51 +0000

Database Lifecycle Management is a big cheese to pull off a dependable database creation and relocation. But when Version Control Systems come into the picture, DDL - Data Definition Language shouldn't be a near miss to handle the database migrations.

To get a grip over the databases in Version Control Systems a fun rollercoaster ride though. Starting with why we need Version Control for database and its benefits, it goes a long way down.
Let us understand the need for the version control system in the database.

Why use Version Control?

The database needs to be monitored of the changes right from the version of source control. The version control systems should have the ability to establish a consistent work culture when the database developments progress at a faster pace. It should store, control and deploy the database.

All these changes made in the database by the Database Administrators are made aware of to the development team to enable smooth functioning in the intellectual set of minds. Whether it is the updates of a database or a new database creation, version control is a smart choice.

Coming to the square one, we have one question in mind: What are the notable changes that you can do in the version control?

Most common changes you can have in the database are based on:

A fixed set of data
Changes in the table using the DDL Scripts
Changes in the schema objects using the same DDL Scripts

These "Based-Ons" can be subjected to changes depending on the recent upgrades and requirements.

"Git" into action

Developer's thought would ultimately like to deliver a dashing and a user-friendly application. This quest requires an updated database - Obviously, a newer version of the database. Git would be a great start towards achieving this integration.

Working with DevOps platforms such as Gitlab would have you steering the right direction to achieve the updated database SQL scripts. The Git repos would help you carry-off the Continuous Integration and Continuous Delivery process.

Git for database helps you store the information instead of rewriting them, the database changes cannot be concealed from git, shares your workload and can operate serverless. Rather than storing the data in the form of files, Git forms an attractive silver lining by storing them in the form of snapshots.

A brief insight on CI/CD for Database

Gitlab Meetup Community — Mon, 18 Jan 2021 08:05:43 +0000

DevOps has boosted its outreach with the developers and is bound to reach new heights in the coming years for its flexible work culture and its unique combination of software DEVelopment and OPerations. Keeping automation as its MasterCard, they focus on the automation aspect of the culture that is CI and CD.

So how are these two concepts a well-built bridge for the Software Delivery considering the change in the system's database?

Developers are aware that databases are versatile and require a server to maintain the current state, which means they are vastly stateful and can cost your job if messed up. With this statement, we can infer that if you're a techie and an extensive explorer of databases, you ought to have a sense of solicitude towards the DBAs of your firm.😉

On a serious note, it is comparatively safer to fix a bug in an application rather than ruining the database. But if you want your database to grow with the business, then changing and deploying database with consistency is essential. At this instance, the Continuous Integration and Continuous Delivery plays a crucial role.
To attain an appreciable level of code delivery and monitoring the changes in the database, knowing the working of the CI/CD is essential.

A Quick tip:Take a look at this to understand the working of CI/CD

Now that we are good enough to handle CI/CD, it's time to explore more about the CI/CD for Databases.

When there is a schema change involved in the database, the Database Administrator would make changes and update the development changes to the developers' team. After the tests with the new updates, the DBA will send it out for delivery to the production stage.

The database changes are reflected in every software release. Although the developers and the database administrators follow an independent lifecycle, the Continuous Delivery process is put into efficient effect based on defined scenarios.

Though a tedious process, the database changes are comparatively slower, yet an essential aspect in the Continuous Integration and Continuous Delivery and also beneficial in surging the organizations' profits.

Tune in! More to explore with respect to the topic!

`Follow our community for more updates`

GitLab Patch Release: 13.7.3

Gitlab Meetup Community — Sun, 10 Jan 2021 18:55:35 +0000

Releasing version 13.7.3 for GitLab Community Edition and Enterprise Edition.

This version resolves a number of regressions and bugs in this month's 13.7 release and prior versions.

GitLab Community Edition and Enterprise Edition

Available in GitLab Core, Starter, Premium, and Ultimate:

Important notes on upgrading
This version does include new migrations, and for multi-node deployments, should not require any downtime. Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-reconfigure file, which is only used for updates.

Updating

To update, check out our update page.

GitLab subscriptions

Access to GitLab Starter, Premium, and Ultimate features are granted by a paid subscription.

Alternatively, sign up for GitLab.com to use GitLab's own infrastructure.

`Follow our community for more updates`

Giveaway Alert - Edition 02

Gitlab Meetup Community — Mon, 04 Jan 2021 13:14:03 +0000

Gitlab Meetup Community makes a distinctive attempt of KNOWLEDGE WITH A FASCINATING GIVEAWAY!

😀

Thrilled to earn your giveaway? Mark the following points in your 'TO-DO list':

It's our pleasure inviting you to the meetup session happening on 9th of January, 2021. REGISTER and become an interactive ATTENDEE of the session.
Follow us on Twitter, Substack and Dev.to platforms.

As an attempt to boost our followers and attendees to take away a wonderful bag of information alongside Gitlab Goodies, we have decided to have 4 lucky enthusiasts among the attendees as the goodie winners.

So what's the wait for?

HURRY UP WE ARE WAITING FOR THAT 4 LUCKY WINNERS AT THE END OF THE SESSION!